Питання про те, чи потрібен проєкту менеджер, я чую регулярно, і майже завжди воно звучить із надією. Клієнт рахує бюджет, бачить рядок «менеджмент проєкту» і думає: а може, без нього? Програмісти ж самі все розуміють, задачі можна ставити їм напряму, а дзвінки проводити самому. Зекономимо пʼятнадцять відсотків і житимемо щасливо.
Чесна відповідь: так, прибуткові проєкти без виділеного менеджера існують. Я сам брав участь у кількох. Але в цього «так» є дуже важливе «але», і в ньому весь сенс статті.
Джазовий квартет і симфонічний оркестр
Джазовий квартет чудово грає без диригента. Четверо музикантів чують одне одного, переглядаються, імпровізують, і виходить музика. Ніхто не махає паличкою, але це не означає, що диригування немає. Воно є, просто розподілене між усіма: саксофоніст кивком показує, що зараз його соло, барабанщик веде темп, піаніст подає сигнал до фіналу. Функція диригента нікуди не зникла, вона розчинилася в музикантах.
А тепер посадіть без диригента симфонічний оркестр із вісімдесяти людей. Скрипки не чують валторн, литаври вступають на такт раніше, і за хвилину прекрасна партитура перетворюється на шум. Музиканти при цьому можуть бути найкращими у світі. Проблема не в майстерності, а в координації.
З проєктами все так само. Маленька команда надмотивованих професіоналів може працювати без окремого менеджера, бо роль менеджера в ній «розмазана» по всіх учасниках. Але розмазана не означає відсутня. Хтось однаково спілкується з клієнтом, хтось стежить за термінами, хтось вирішує, що важливіше сьогодні. Просто це роблять ті самі люди, які пишуть код.
Що насправді робить менеджер
Багато хто думає, що менеджер проєкту це людина, яка ставить задачі й питає «ну що, готово?». Якби це було так, його справді можна було б замінити нагадуванням у календарі. Але справжня робота менеджера складається з речей, які невидимі, поки їх роблять, і дуже помітні, коли їх перестають робити.
- Перекладає мову клієнта мовою команди й навпаки. Клієнт каже «хочу, щоб було зручно», програміст чує «треба переробити архітектуру», менеджер зʼясовує, що насправді потрібна одна кнопка.
- Захищає команду від хаосу. Клієнт пише пʼять ідей на день, і якщо всі вони одразу потрапляють до програмістів, робота не рухається взагалі.
- Стежить за грошима й термінами. Не наприкінці проєкту, а щотижня, поки відхилення ще мале.
- Бачить ризики раніше, ніж вони стають проблемами.
- Тримає пріоритети бізнесу у фокусі, коли команда захопилася технічно цікавою, але марною задачею.
Якщо у Вашій команді хтось із фахівців робить усе це, добре й із задоволенням, окремий менеджер Вам справді може не знадобитися. Якщо не робить ніхто, Ви не зекономили на менеджері. Ви просто перестали керувати проєктом.
Коли без менеджера виходить
З мого досвіду, проєкт без виділеного менеджера буває прибутковим, коли сходиться кілька умов. Команда маленька, до чотирьох-пʼяти людей. Люди в ній досвідчені й уже працювали разом, тож їм не треба домовлятися про базові речі. Один з учасників, найчастіше провідний розробник чи архітектор, бере на себе спілкування з клієнтом і любить це робити. Клієнт сам розуміє, чого хоче, і вміє це формулювати. Обсяг робіт зрозумілий і не змінюється щотижня.
Зверніть увагу, що в цьому списку багато «якщо». Це як їхати автівкою без навігатора: рідним містом легко, незнайомою країною можливо, але з пригодами.
Коли це небезпечно
Три ризики, які я бачу найчастіше, коли менеджера прибирають заради економії.
Перший: хаос у комунікаціях із клієнтом. Клієнт пише одразу трьом розробникам, кожен розуміє своє, обіцянки даються різні, і за місяць клієнт певен, що йому пообіцяли одне, а зробили інше. І він, до речі, матиме рацію.
Другий: втрата фокусу на пріоритетах бізнесу. Програмісти, залишившись без зовнішнього фокусу, схильні робити те, що цікаво технічно. Гарну архітектуру, ідеальний рефакторинг, модну бібліотеку. Усе це може бути правильним, але не тоді, коли клієнтові за два тижні треба запускати продажі.
Третій: вихід за межі бюджету. Без людини, яка щотижня звіряє план і факт, перевитрата накопичується непомітно. Кожна задача «трішки довша», і в сумі проєкт виявляється на третину дорожчим. Економія на менеджері в пʼятнадцять відсотків зʼїдається за пів проєкту.
Середній шлях
Ми в Ingello часто використовуємо гібридну схему. На невеликих проєктах роль менеджера виконує архітектор, який і так найкраще розуміє систему й бізнес клієнта. Йому допомагають інструменти: спільний трекер, автоматичні звіти щодо термінів і бюджету, зрозумілий процес приймання. Рутину, яку раніше робила людина (нагадування, зведення, збирання статусів), роблять боти. А частину роботи, яка раніше вимагала довгих погоджень, ми знімаємо формальним описом системи через Fractal: коли схема даних та екранів описана заздалегідь, сперечатися про деталі доводиться значно менше.
Це не скасовує менеджменту. Це зменшує його обсяг до того, що справді потребує людського судження.
Висновок від практика
Якщо Ви думаєте, чи прибирати менеджера з проєкту, поставте собі одне питання: хто конкретно робитиме його роботу? Не «хтось розбереться», а конкретне імʼя. Якщо таке імʼя є і ця людина готова й уміє, пробуйте. Якщо імені немає, Ви не економите, а берете кредит, який доведеться повернути з відсотками у вигляді переробок, зірваних термінів і зіпсованих стосунків із клієнтом.
Квартет може грати без диригента. Але тільки якщо кожен музикант у ньому трохи диригент.
