Цю суперечку я чую стільки, скільки працюю в IT. Одні кажуть: менеджер зобовʼязаний уміти програмувати, інакше він не розуміє, чим керує, і розробники вішатимуть йому локшину на вуха. Інші відповідають: менеджер має керувати людьми й термінами, а код хай пишуть ті, хто вміє, інакше він почне лізти в кожен рядок і заважати. Найкумедніше, що мають рацію обидві сторони. Просто вони відповідають на різні запитання.
Моя відповідь коротка: писати код менеджеру не обовʼязково. Розуміти, як влаштована система, обовʼязково. Це різні навички, і плутати їх небезпечно в обидва боки.
Тренер не мусить грати краще за гравців
Візьміть футбольного тренера. Багато великих тренерів були посередніми гравцями, а деякі не грали на високому рівні взагалі. Ніхто не чекає, що тренер вийде на поле й забʼє гол краще за свого нападника. Але тренер, який не розуміє гри, не бачить, чому розвалюється захист, не відчуває, де команда втрачає темп, довго не протримається. Його робота не грати, а бачити гру цілком і ухвалювати рішення, яких гравцям з поля не видно.
Із менеджером у розробці те саме. Йому не треба писати код краще за програмістів. Але йому треба розуміти, з чого складається система, як повʼязані її частини, чому одна задача займає годину, а зовні схожа на неї потребує тижня.
Навіщо менеджерові технічні знання
Без базового технічного розуміння менеджер опиняється в становищі людини, яка купує машину й не знає, що таке двигун. Їй можна розповісти що завгодно.
- Відрізняти реальну складність від казки. Коли розробник каже «це займе три тижні, бо доведеться переробляти модель даних», менеджер має бодай приблизно розуміти, чи це правда. Не щоб викрити, а щоб поставити правильне уточнювальне запитання.
- Оцінювати разом із командою. Оцінки термінів без розуміння архітектури перетворюються на вгадування. Менеджер, який розуміє систему, бачить ризики заздалегідь: тут інтеграція із зовнішнім сервісом, тут старий код, тут міграція даних.
- Перекладати з мови клієнта на мову розробки й назад. Це, мабуть, головне. Клієнт каже «додайте кнопку», а менеджер має зрозуміти, що за цією кнопкою нова роль користувача, права доступу й три нові сценарії.
- Говорити з техлідом однією мовою. Не обовʼязково на його рівні, але принаймні зі спільним словником: база даних, API, деплой, міграція, кеш.
Є старий жарт про керівника, який просить програміста: «Зроби, щоб застосунок за фотографією визначав, де зроблено знімок, і ще щоб визначав, чи є на ній птах». Перше робиться за годину, друге колись потребувало дослідницької групи й пʼяти років. Збоку обидві задачі виглядають однаково. Менеджер, який не відчуває цієї різниці, постійно обіцятиме клієнтам неможливе або лякатиметься простого.
Менеджер не мусить уміти лагодити двигун. Але він мусить чути, коли двигун починає стукати.
Небезпека менеджера, який програмує
Тепер про інший бік. Я бачив багато менеджерів, які прийшли з розробки, і в них своя хвороба. Коли проєкт горить, у них сверблять руки. Вони сідають і пишуть код самі: так швидше, так надійніше. Цієї миті проєкт втрачає менеджера. Ніхто не розмовляє з клієнтом, ніхто не стежить за термінами, ніхто не бачить, що сусідня задача теж горить. Капітан спустився в машинне відділення й крутить гайки, а корабель іде без керування.
Друга хвороба дрібніша, але неприємніша: менеджер, який програмує, схильний навʼязувати команді свої технічні рішення. «Я б зробив отак». Команда перестає ухвалювати рішення сама й починає вгадувати, як зробив би начальник. Це той самий мікроменеджмент, тільки в технічній обгортці.
Найкращі менеджери, яких я зустрічав, уміли тримати цю межу. Вони могли відкрити код і прочитати його, могли зрозуміти схему бази даних і посперечатися про рішення на ревʼю. Але в робочий час їхні руки лежали не на клавіатурі розробника, а на штурвалі проєкту. Технічні знання вони використовували як зір, а не як інструмент.
Що змінюється з приходом AI
Зараз питання набуло нового виміру. З AI-інструментами менеджер, який не вміє програмувати, може за вечір зібрати працюючий прототип. Це чудово для того, щоб показати ідею, перевірити гіпотезу чи пояснити команді, що мається на увазі. Ми в Ingello активно цим користуємося: прототип за дні замість місяців змінює розмову з клієнтом.
Але тут-таки зʼявляється пастка. Прототип, зібраний за вечір, виглядає як готова система, і менеджерові здається, що лишилося трохи. А між демонстрацією і продакшеном лежить усе те, чого не видно на екрані: безпека, дані, навантаження, підтримка. Саме тут технічне розуміння знову стає критичним. Не для того, щоб писати код, а для того, щоб не прийняти декорацію за будівлю.
Що зробити завтра
Якщо Ви менеджер без технічного бекграунду, попросіть свого техліда провести для Вас годинну екскурсію системою: намалювати на дошці, з яких частин вона складається, де зберігаються дані, як вони рухаються, що з чим повʼязано. Ставте дурні запитання, це нормально. За кілька таких зустрічей Ви почнете чути стукіт двигуна. Якщо ж Ви менеджер із розробників, запишіть на тиждень, скільки годин Ви витратили на код, а скільки на управління. Якщо перша цифра більша за другу, подумайте, хто цей час стояв біля штурвала.
