Чому технічна правота IT-фахівця — це ще не аргумент

Є ситуація, яку більшість IT-фахівців — розробників, техлідів, архітекторів — переживали хоч раз: ти підготував рішення, пояснив логіку, показав аргументи. Технічно — все правильно. І все одно: «давайте подумаємо», «не впевнений», «давайте лишимо як є».

Це не завжди означає, що рішення погане. Часто це означає, що подача не дала людині достатньо, щоб взяти на себе рішення. Є конкретний механізм: будь-яке рішення, навіть раціональне, проходить через емоційну оцінку. «Мені зрозуміло», «мені не страшно», «я довіряю цій людині» — ці фактори впливають на прийняття рішення навіть там, де все обгрунтовано технічно. Технічна правота IT-фахівця — необхідна умова. Але не достатня.

Ситуація 1. Презентація рішення на груповому мітингу або design review

Сценарій: архітектурне рішення або технічний вибір потрібно представити на мітинг зі стейкхолдерами або командою. IT-фахівець готує матеріал, пояснює логіку, показує компроміси.

Де ламається: є спостереження з аналізу комунікацій — будь-яка презентація тривалістю більше 30 секунд без зворотного зв’язку від аудиторії несе ризик: людина, яка недостатньо занурена в контекст, запам’ятовує менше 20% сказаного. Це не питання уваги — це питання того, чи є у людини внутрішній мотив слухати прямо зараз.

Що змінює ситуацію: не починати з рішення. Починати з питання, яке ставить людину в позицію учасника, а не слухача. «Як зараз виглядає найбільший ризик у поточному підході?» або «Що для тебе найважливіше при виборі між цими двома варіантами?» Відповідь показує, що людину насправді хвилює — і дозволяє побудувати пояснення навколо її контексту, а не навколо своєї логіки.

Слабка подача: 10-слайдова презентація без єдиного питання до аудиторії.

Сильна подача: одне точне питання на початку → аудиторія виражає свій контекст → рішення подається як відповідь на озвучений контекст.

Ситуація 2. Захист технічного рішення перед менеджментом або бізнесом

Сценарій: потрібно обґрунтувати вибір технології, пріоритет рефакторингу або рішення що несе технічний борг. Менеджер або CPO каже: «це дорого», «навіщо зараз», «у нас немає ресурсу на це».

Де ламається: перша реакція більшості IT-фахівців — пояснити аргументи детальніше. «Ні, ти не розумієш, ось дивись: якщо не зробимо зараз, то через 6 місяців...» І далі — ще більше технічних деталей. Це часто не допомагає, а посилює опір.

Важлива закономірність: коли людина каже «дорого» або «навіщо зараз» — це не логічне заперечення. Це сигнал про незакритий мотив. Що саме її хвилює? Ризик зриву дедлайну? Непрозорість витрат? Нерозуміння наслідків якщо не зробити? Поки відповідь невідома — будь-який аргумент потрапляє в порожнечу.

Що змінює ситуацію: замість нових аргументів — уточнення. «Коли кажеш що це дорого — маєш на увазі бюджет на цей квартал, чи щось інше?» або «Що для тебе найважливіше зрозуміти перш ніж прийняти рішення?» Відповідь дасть реальний мотив — і рішення можна подати саме через нього.

Слабка подача: IT-фахівець пояснює технічні наслідки того, чого «не розуміє» менеджер.

Сильна подача: питаєш, що насправді стоїть за «ні» — і відповідаєш на це, а не на те, що сам придумав.

Ситуація 3. RFC або tech spec, яке «завернули» без чіткого пояснення

Сценарій: написав RFC або технічну специфікацію, відправив на ревью. Повернули з коментарями «давайте ще обговоримо», «є питання по підходу» — або взагалі без конкретики.

Де ламається: RFC часто написані для технічної аудиторії і оптимізовані під технічну правильність. Але люди, які ухвалюють рішення, не завжди читають RFC як технічний документ. Вони шукають відповіді на питання: чому зараз? які ризики якщо не робити? що зміниться для моєї команди?

Є спостереження: якщо документ починається з рішення — більшість читачів без достатнього контексту пробігають очима і не занурюються в деталі. Це не питання якості документу — питання того, чи є у читача причина читати уважно.

Що змінює ситуацію: структурувати RFC не від «ось рішення і аргументи», а від «ось поточна проблема і її ціна — варіанти — обраний підхід і чому». Читач, який бачить опис своєї проблеми на першому рядку, стає значно більш залученим і дає якісніший фідбек.

Слабка подача: RFC відкривається з технічного рішення. Мотив читати — незрозумілий.

Сильна подача: RFC відкривається з опису ситуації знайомої читачу. Далі — ціна бездіяльності. Далі — варіанти. Далі — рішення.

Ситуація 4. Онбординг нового рішення або процесу для команди

Сценарій: потрібно перевести команду на нову бібліотеку, новий процес ревью, нову угоду про бранчінг. IT-фахівець пояснив, відповів на питання, всі погодились. Через тиждень — половина команди робить по-старому.

Де ламається: навіть якщо людина погодилась публічно — це не означає, що вона внутрішньо прийняла зміну. Є принципова різниця між «погодився від поваги до авторитету» і «зрозумів, чому це краще особисто для нього». Перше дає формальне виконання. Друге — реальну зміну поведінки.

Є спостереження, яке добре описує цю ситуацію: навіть якщо ти авторитетна людина в команді — якщо доносиш зміну тільки через аргументи і позицію, частина команди приймає це формально, але без внутрішньої переконаності. При першій складній ситуації — повертаються до звичного.

Що змінює ситуацію: перед поясненням нового рішення — запитати, що зараз незручно або займає зайвий час у поточному підході. Людина, яка сама озвучила біль, значно більш рецептивна до рішення що цей біль знімає. Технічно те саме рішення — але прийнято через власний висновок, а не через директиву.

Слабка подача: «З понеділка використовуємо новий процес, ось чому це краще.»

Сильна подача: «Що зараз найбільше заважає у поточному флоу?» → команда озвучує → «Ось рішення яке це вирішує.»

Загальний знаменник

У всіх чотирьох ситуаціях механізм один і той самий. Технічна правота IT-фахівця не проходить не тому що рішення неправильне. Воно не проходить тому що людина, яка повинна його прийняти, не відчула зв’язку між рішенням і своїм контекстом.

Це не означає «маніпулюй» або «продавай ідеї». Це означає: перш ніж пояснювати своє рішення — зрозумій, що важливо для людини прямо зараз. І побудуй пояснення навколо цього.

Технічна правота IT-фахівця — необхідна умова. Але не достатня.