Чому технічна правота IT-фахівця — це ще не аргумент
Є ситуація, яку більшість IT-фахівців — розробників, техлідів, архітекторів — переживали хоч раз: ти підготував рішення, пояснив логіку, показав аргументи. Технічно — все правильно. І все одно: «давайте подумаємо», «не впевнений», «давайте лишимо як є».
Це не завжди означає, що рішення погане. Часто це означає, що подача не дала людині достатньо, щоб взяти на себе рішення. Є конкретний механізм: будь-яке рішення, навіть раціональне, проходить через емоційну оцінку. «Мені зрозуміло», «мені не страшно», «я довіряю цій людині» — ці фактори впливають на прийняття рішення навіть там, де все обгрунтовано технічно. Технічна правота IT-фахівця — необхідна умова. Але не достатня.
Ситуація 1. Презентація рішення на груповому мітингу або design review
Сценарій: архітектурне рішення або технічний вибір потрібно представити на мітинг зі стейкхолдерами або командою. IT-фахівець готує матеріал, пояснює логіку, показує компроміси.
Де ламається: є спостереження з аналізу комунікацій — будь-яка презентація тривалістю більше 30 секунд без зворотного зв’язку від аудиторії несе ризик: людина, яка недостатньо занурена в контекст, запам’ятовує менше 20% сказаного. Це не питання уваги — це питання того, чи є у людини внутрішній мотив слухати прямо зараз.
Що змінює ситуацію: не починати з рішення. Починати з питання, яке ставить людину в позицію учасника, а не слухача. «Як зараз виглядає найбільший ризик у поточному підході?» або «Що для тебе найважливіше при виборі між цими двома варіантами?» Відповідь показує, що людину насправді хвилює — і дозволяє побудувати пояснення навколо її контексту, а не навколо своєї логіки.
Слабка подача:
Сильна подача: одне точне питання на початку → аудиторія виражає свій контекст → рішення подається як відповідь на озвучений контекст.
Ситуація 2. Захист технічного рішення перед менеджментом або бізнесом
Сценарій: потрібно обґрунтувати вибір технології, пріоритет рефакторингу або рішення що несе технічний борг. Менеджер або CPO каже: «це дорого», «навіщо зараз», «у нас немає ресурсу на це».
Де ламається: перша реакція більшості IT-фахівців — пояснити аргументи детальніше. «Ні, ти не розумієш, ось дивись: якщо не зробимо зараз, то через 6 місяців...» І далі — ще більше технічних деталей. Це часто не допомагає, а посилює опір.
Важлива закономірність: коли людина каже «дорого» або «навіщо зараз» — це не логічне заперечення. Це сигнал про незакритий мотив. Що саме її хвилює? Ризик зриву дедлайну? Непрозорість витрат? Нерозуміння наслідків якщо не зробити? Поки відповідь невідома — будь-який аргумент потрапляє в порожнечу.
Що змінює ситуацію: замість нових аргументів — уточнення. «Коли кажеш що це дорого — маєш на увазі бюджет на цей квартал, чи щось інше?» або «Що для тебе найважливіше зрозуміти перш ніж прийняти рішення?» Відповідь дасть реальний мотив — і рішення можна подати саме через нього.
Слабка подача: IT-фахівець пояснює технічні наслідки того, чого «не розуміє» менеджер.
Сильна подача: питаєш, що насправді стоїть за «ні» — і відповідаєш на це, а не на те, що сам придумав.
Ситуація 3. RFC або tech spec, яке «завернули» без чіткого пояснення
Сценарій: написав RFC або технічну специфікацію, відправив на ревью. Повернули з коментарями «давайте ще обговоримо», «є питання по підходу» — або взагалі без конкретики.
Де ламається: RFC часто написані для технічної аудиторії і оптимізовані під технічну правильність. Але люди, які ухвалюють рішення, не завжди читають RFC як технічний документ. Вони шукають відповіді на питання: чому зараз? які ризики якщо не робити? що зміниться для моєї команди?
Є спостереження: якщо документ починається з рішення — більшість читачів без достатнього контексту пробігають очима і не занурюються в деталі. Це не питання якості документу — питання того, чи є у читача причина читати уважно.
Що змінює ситуацію: структурувати RFC не від «ось рішення і аргументи», а від «ось поточна проблема і її ціна — варіанти — обраний підхід і чому». Читач, який бачить опис своєї проблеми на першому рядку, стає значно більш залученим і дає якісніший фідбек.
Слабка подача: RFC відкривається з технічного рішення. Мотив читати — незрозумілий.
Сильна подача: RFC відкривається з опису ситуації знайомої читачу. Далі — ціна бездіяльності. Далі — варіанти. Далі — рішення.
Ситуація 4. Онбординг нового рішення або процесу для команди
Сценарій: потрібно перевести команду на нову бібліотеку, новий процес ревью, нову угоду про бранчінг. IT-фахівець пояснив, відповів на питання, всі погодились. Через тиждень — половина команди робить по-старому.
Де ламається: навіть якщо людина погодилась публічно — це не означає, що вона внутрішньо прийняла зміну. Є принципова різниця між «погодився від поваги до авторитету» і «зрозумів, чому це краще особисто для нього». Перше дає формальне виконання. Друге — реальну зміну поведінки.
Є спостереження, яке добре описує цю ситуацію: навіть якщо ти авторитетна людина в команді — якщо доносиш зміну тільки через аргументи і позицію, частина команди приймає це формально, але без внутрішньої переконаності. При першій складній ситуації — повертаються до звичного.
Що змінює ситуацію: перед поясненням нового рішення — запитати, що зараз незручно або займає зайвий час у поточному підході. Людина, яка сама озвучила біль, значно більш рецептивна до рішення що цей біль знімає. Технічно те саме рішення — але прийнято через власний висновок, а не через директиву.
Слабка подача: «З понеділка використовуємо новий процес, ось чому це краще.»
Сильна подача: «Що зараз найбільше заважає у поточному флоу?» → команда озвучує → «Ось рішення яке це вирішує.»
Загальний знаменник
У всіх чотирьох ситуаціях механізм один і той самий. Технічна правота IT-фахівця не проходить не тому що рішення неправильне. Воно не проходить тому що людина, яка повинна його прийняти, не відчула зв’язку між рішенням і своїм контекстом.
Це не означає «маніпулюй» або «продавай ідеї». Це означає: перш ніж пояснювати своє рішення — зрозумій, що важливо для людини прямо зараз. І побудуй пояснення навколо цього.
Технічна правота IT-фахівця — необхідна умова. Але не достатня.
15 коментарів
Додати коментар Підписатись на коментаріВідписатись від коментарівТому що норм технар пропонує цифри — терміни, бюджет та ризики.
Якщо він пропонує «правоту» — це скоріше менеджер, ніж технар.
Не є технічним завданням
Робиться інакше. Компанія в особі такого підписує відмову на бюджет і прийняття ризиків. Якщо що — з таким папером можна і потрібно до суду, можна реально багато струсити або трохи менше за достудебку.
Значить не час/не болить
Коли ти загинатимешся на операційному столі — підпишеш усі папери як миленький. Норм технар як лікар — зачекає, поки заболить. Самі прийдуть.
Технар тут взагалі ніяким боком
Схема з папером і підписом — реально буває потрібна. Але «можна до суду» означає що відносини вже закінчились. Стаття про те що відбувається до цього моменту.
«Норм технар пропонує цифри» — погоджуюсь. Але цифри теж треба комусь прийняти, і коли менеджер каже «дорого» — питання не завжди у цифрі. Іноді у тому, навіщо взагалі.
Ситуація 4 — хотів би почути як «ніяким боком». Техлід який вводить новий процес ревью і через тиждень половина команди робить по-старому — чия це зона відповідальності?
«Зачекати поки заболить» — ок для зовнішнього консультанта. Для внутрішнього архітектора це означає чекати продакшн інциденту.
Відомо що — брак управлінських рішень
Ну якщо менеджер підписується під ризиками та приймає їх — то це його особиста справа. У разі інциденту відчує на собі.
А до чого тут техлід? Якщо команда саботує процес — це питання до менеджера. Техлід приводить коня до водопою. А напоїти її — завдання менеджера.
Це для фахівця. Якщо ваш сімейний лікар хоче втюхати гомеопатію — він танцюватиме з бубном і презентуватиме з музикою кольору. А якщо йдете до норм лікаря із запаленим апендицитом — то різати до чотрової матері, не чекаючи перитоніту. Як би боляче це не було. Інакше може так заафектити на всю компанію, що призведе до банкрутства.
То ви як — приймете цукрову кульку чи підете до хірурга? До хірурга — дорого.
Апендицит це приклад який працює навпаки. Навіть хірург з підтвердженим діагнозом бере інформовану згоду перед операцією, і пацієнти регулярно відмовляються від необхідної операції: «informed refusal», окремий термін у медицині, трапляється частіше ніж здається. Підпис потрібен навіть при апендициті.
«Брак управлінських рішень» частково так, тільки цей дефіцит хтось закриває щодня, до того як рішення стає формальним. Про «підписався — його справа» —-згоден, коли підпис вже є. Стаття про момент до підпису: як довести людину від «дорого, навіщо» до готовності підписати. Папір сам не з’являється.
«Коня до водопою» — так, напоїти не в зоні техліда. Скільки кінь буде пручатись перш ніж підійде до води — залежить від того хто і як його туди привів. Це і є вся стаття.
Лол що? З комунікаціями у вас щось не так, видно професійну інформацію. Мало що відповідь не дана, то ще й суперечите самі собі.
То це завдання менеджера, а не технаря. Ось менеджер і повинен закрити угоду та прийняти ризики. Технар — пропонує і робить, менелжер — вибирає та приймає.
Стаття про інше — як можна прогнути технаря щоб той узяв на себе менеджерські завдання і трішки ризиків. Це працює — не питання, але тільки це створює новий ризик для бізнесу. Коли технар продає рішення замовнику, він може отримати нову угоду:
— Чувак, слухай, ти такий розумний. Нафіга нам ці довбоєби? Давай робити удвох.
Тобто компанія просто втрачає контроль на цьому роздоріжжі, а далі — мінус співробітник, мінус замовник.
Комунікаційна деформація — можливо. Повертаюсь до суті.
Технар пропонує і робить, менеджер вибирає і приймає — правильна схема на папері. Менеджер вибирає з того що йому принесли, і те як принесли — сильно міняє швидкість вибору. Та сама пропозиція чекає підпису тиждень або годину залежно від подачі. Хто вибирає — менеджер. Хто впливає на швидкість вибору — той хто приніс.
«Чувак ти такий розумний, нафіга ці довбоєби» — реальний ризик, тільки з іншої історії про продажі замовнику через голову компанії. Стаття про технаря і його власну команду, свого менеджера, той самий проєкт де він і так вже працює. Це різні ситуації. Ризик обходу клієнта закривається NDA і договором. Комунікація тут ні до чого.
Фахівець — не проповідник, не комівояжер і не фокусник. Він пропонує вирішити проблему — якщо замовник не хоче нічого міняти то він залишається зі своєю проблемою.
Уявіть що ви прийшли до доктора, він подивився і далі показує вам презентацію аби вмовити вас лікуватися. А якщо презентація не достатньо гарна пацієнт каже «не впевнений — давайте лишимо як є». Ну хай думає далі — це ж не доктору болить.
Чи ви викликали сантехніка: від розписав що треба ремонтувати, міняти, скільки це коштує — а ви такі «не впевнений — давайте лишимо як є». Ну і хай вода тече — думайте далі!
Я до чого: гарний фахівець не має умовляти замовників. До нього має стояти черга з проблемами. І хто ще не стоїть в черзі, а думає — то проблема ще не дозріла.
Чекаємо статей:
«Чому медична правота доктора — це ще не аргумент»
«Чому наукова правота сейсмолога — це ще не аргумент»
«Чому досвід оператора АЕС — це ще не аргумент»
Треба вміти правильно проводити презентації: от Лукашенко на мапі презентував звідки збиралися на нього нападати — а Зеленський мапи не дивився, презентації не робив — тому перед нападом розказував про шашлики.
Доктор, сантехнік, сейсмолог — всі вони зовнішні фахівці, до яких приходять. Стаття про тих хто всередині команди. Техлід не чекає поки прийдуть — він вже є у цьому проєкті, і рішення треба прийняти до того як щось зламається.
«Черга сама прийде» добре працює для фрілансера який обирає клієнтів. Але якщо ти внутрішній архітектор і RFC завернули — не можеш сказати «живіть далі зі своєю проблемою». Рішення треба взяти зараз.
Про «вмовляти» — погоджуюсь, не про це. Стаття про те щоб задати одне питання і зрозуміти де у людини реальний стоп. «Не зараз» і «не хочу» — різні причини і відповідь на них різна.
Лукашенко і Зеленський — це вже точно окремий матеріал.
Ну так техлід йде до свого менеджера якому репортит і каже — пробий рішення. Далі менеджер пробиває. У чому питання?
C-Level дивиться і каже — вигідно чи ні.
Техлід каже — якщо не буде аудиту безпеки, у нас злетить статус і ми втратимо контракт.
Менеджер показує — ось бюджет на аудит, ось контракт клієнта.
У чому pain point я так і не зрозумів.
«Комунікаційна деформація» — можливо. Повертаюсь до суті.
«Технар пропонує і робить, менеджер вибирає і приймає» — правильна схема на папері. Менеджер вибирає з того що йому принесли, і те як принесли — сильно міняє швидкість вибору. Та сама пропозиція чекає підпису тиждень або годину залежно від подачі. Хто вибирає — менеджер. Хто впливає на швидкість вибору — той хто приніс.
«Чувак ти такий розумний, нафіга ці довбоєби» — реальний ризик, тільки з іншої історії про продажі замовнику через голову компанії. Стаття про технаря і його власну команду, свого менеджера, той самий проєкт де він і так вже працює. Це різні ситуації. Ризик обходу клієнта закривається NDA і договором. Комунікація тут ні до чого.
Так-так, і це норма. Наприклад, потрібно пройти якийсь аудит з архітектури і менеджер чекає на результат аудиту. Звісно, якщо принесли документи на досвіді — чекатиме менше. Це скрізь так — у досвідчених людей швидше вони знають нюанси.
А до чого тут NDA? Тут NCA швидше, той же технар, отримавши доступ до тушки клієнта, може звільнитися і звалити до замовника. Саме тому із замовником говорить менеджер.
Ага — тобто ідеться про історію коли Техлід або Архітект розробили технічне рішення і тепер мають його «презентувати» команді та менеджменту.
Тепер я розумію що це цілком можливий сценарій — але тільки у продуктовій компанії і найбільш імовірно коли автор пропонує якусь свою ідею покращення. Тут справді має необхідність «продати» ідею усім зацікавленим сторонам. Бо інакше її можуть не зрозуміти, відхилити та вирішити «залишили як є».
Коли це аутсорс, де проєкт пишеться на замовлення — то там нема ідей які можуть прийняти чи відхиляти. Є план проєкту, я фічі які треба зробити — і нікому не треба доводити що їх треба робити. Так само як ніхто не погодиться аби замість запланованих фіч хтось робив якісь свої ідеї для покращення.
Якщо ти єдиний техлід чи архітектор на проєкті і ти пропонуєш рішення — як його можуть «завернути»? Його можуть критикувати, просити зробити простіше та швидше — але варіант «давайте лишимо як є» неможливий, а для іншого варіанта хіба що поміняти архітекта чи техліда.
Я дуже рідко бачив аби хтось збирав команду і робив живу презентацію ТЕХНІЧНОГО рішення. Для девелоперів зазвичай цілком достатньо технічного документа. А менеджмент не цікавлять технічні деталі — тільки гроші та час. Інша справа коли БА презентує вимоги бізнесу — тут справді треба вміти пояснити технічним спеціалістам що саме клієнт хоче і навіщо.
Продукт і аутсорс — справді різна динаміка, і тут згоден — у фіксованому скоупі «давайте лишимо як є» не варіант, є контракт і план.
Але ситуація 2 і 3 живуть і в аутсорсі теж. Аудит безпеки, рефакторинг, технічний борг — все це виходить за межі підписаного скоупу, і про нього ще треба домовитись з PM чи клієнтом. Навіть Andrey вище навів приклад: техлід каже без аудиту злетить статус, і йде до менеджера пробивати бюджет. Той самий момент «до підпису» з статті.
Про живі презентації технічного рішення — теж згоден, це рідкість. Частіше це вибір фреймворку, міграція, велика архітектурна зміна — рідкісні моменти де ставки високі а формат непідготовлений.
БА який пояснює технарям бізнес-вимоги — дзеркальна ситуація, той самий механізм в інший бік. Окрема стаття, чесно кажучи.
У меня подход простой и сложный одновременно. Найти решение, реализовать, проверить, если не подходит, не вписывается в рамки, то все по круг и так пока не получится. Без обсуждений, споров и вопросов. Или реализовать первое если работает удовлетворительно или так кажется, потом оптимизировать если будет смысл.
Якщо ти і є той, хто реалізує, і той, хто вирішує: підхід робочий. Цикл «зробив → перевірив → переробив» не вимагає нікого переконувати.
Але стаття про іншу ситуацію: коли рішення технічно правильне, а «так» чи «ні» залежить не від тебе.