8 типів менеджерів, які дратують розробників

Стаття написана у співавторстві з Константин Кулаксиз, Front-end Developer у DataArt і Мері Ротар, співзасновницею IAMPM. У статті ми розповімо реальні історії з нашої практики.

Дисклеймер: Project менеджери потрібні, важливі, і можуть бути дуже класними спеціалістами, без яких працювати було б важко, а часом і неможливо. Але за 15 років сумарного досвіду у нас накопичилось чимало негативних кейсів, про які ми сьогодні і поговоримо. Історії, написані від першої особи, сталися з кимось з нас у далекому (або не дуже) минулому.

Наші супергерої — це не конкретні люди, а збірні образи, втілення деструктивних моделей поведінки, які притаманні деяким Project менеджерам. Іноді у своєму PM ви можете впізнати відразу кількох антигероїв з цієї статті — або, якщо пощастить, жодного. Загалом, усі персонажі вигадані, а збіги випадкові...

Міт-мен

Міт-мен — це менеджер, все життя якого присвячене зустрічам. Колись він прочитав, що збори допомагають команді працювати ефективніше, і звів цю рекомендацію в абсолют.

З таким менеджером, часу на роботу просто не залишається. Щодня як мінімум пару годин витрачається на всілякі міти, на яких присутня вся команда, хоча по факту потрібні 1-2 людини. Міт-мен вважає своїм обов’язком надіслати запрошення всім членам команди, зібрати їх та почати говорити з кожним окремо.

Якось працював з таким персонажем, і приводи для зустрічей іноді були просто абсурдними.

Вранці ми зібралися, обговорили на стендапі завдання на день, випили кави, поспілкувалися, сіли за роботу — і за годину-дві отримуємо запрошення на міт. На зустрічі запитують: «Ну, що ти встиг зробити? А що тобі заважало зробити більше? Може, тобі щось потрібно від колег?» Так і хочеться сказати: «Ну, якщо потрібно, то я підійду до колеги й запитаю!» Якщо кожного в команді з 5+ осіб опитувати на мітах — вже, вважай, мінус година-півтори часу, яке можна було витратити на розробку.

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

Ще один особливий талант Міт-мена — не переривати в процесі командної зустрічі діалог двох розробників, які вирішили зануритися у свої проблеми. Це ж подовжує міт, ура! Потрібно більше зустрічей богу мітингів!

Інкогніто

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

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

У результаті сенс феномена проєктного менеджменту проявляється тільки якщо на проєкті щось іде зовсім не за планом — часто саме через відсутність PM-а. У цьому випадку Інкогніто ще й дивується, чому з ним ніхто не радився раніше. Та тому що робота стоїть, тебе немає на зв’язку, а її треба робити! При знайомстві з менеджерами типу Інкогніто виникає питання: навіщо вони взагалі потрібні, якщо можна призначити головним ліда, і все буде добре?

ХЗ-мен

Це менеджер, який не знає, як правильно формулювати завдання і які для них існують критерії оцінки. Під формулюванням завдання ми маємо на увазі створення таска в Jira (або іншій системі контролю завдань) та його грамотний опис.

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

На жаль, ХЗ-менеджери досить поширені. Тому, щоб розробники не впадали в ступор, коли вони бачать завдання, існують такі перевірені часом підходи, як написання Acceptance Criteria та Definition of Done.

Хтось може сказати, що DoD — це загальні вимоги до якості, а не обов’язок менеджера, і тим не менше, потурбуватися про те, щоб цей список DoD був хоча б прикріплений до завдання і формалізований, а розробник про це просто не забув — все-таки повинен PM. Якщо в компанії DoD немає, PM має потурбуватися про його організацію. Менеджер може, як мінімум, попросити найрозумнішого розробника, щоб він це зробив. Як би там не було, DoD на проєкті повинен бути, інакше працювати складно.

Задрот-мен

Це звання отримують менеджери, які намагаються натягнути методологію на глобус. Зрозуміти, хто такий Задрот-мен, найкраще допоможе реальна історія, яку я чув від колег.

Є проєкт, досить велике мобільне застосування (кількість користувачів обчислюється сотнями тисяч). Розробка ведеться за Scrum: стандартні двотижневі спринти, планування, оцінки — все, як належить у найкращих домах Лондона та Парижа.

Раптом у середині спринта ламається логін. Замовник прибігає до менеджера: «У мене 100К користувачів, і ніхто не може увійти в систему, що робити? Давайте, хлопці, полагодьте». Менеджер: «У нас Scrum! Все розплановано, ми не можемо просто так взяти й полагодити логін! Якщо ти хочеш, щоб ми його полагодили, то давай спочатку сядемо, подивимося беклог, виберемо завдання, яке викинемо з цього спринта, а замість нього поставимо завдання по фіксу логіна».

Замовник в шоці, оскільки не розуміє, навіщо замість того, щоб прямо зараз сидіти і фіксити проблему, через яку бізнес втрачає гроші, потрібно витрачати час на Scrum-ігри.

Висновок: не варто беззастережно і неухильно дотримуватися всіх постулатів однієї методології як законів (особливо якщо ви зрозуміли її занадто буквально). Будь-яка методологія повинна враховувати ситуації, коли щось піде не так, і доведеться приймати швидке рішення.

А давайте так-мен

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

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

У мого товариша була ситуація, коли вони півроку писали CRM-ку на Angular, у проєкті були деякі проблеми, які менеджер планував вирішити переписуванням всього на Vue через пів року розробки! Як це може вирішити проблему — незрозуміло, але команда була «в захваті».

Менеджер має право рекомендувати технологічний стек на основі свого попереднього досвіду, але, знову ж таки, не варто забувати, що його голос має бути дорадчим, і остаточне рішення щодо технологій, які варто використовувати, залишається за розробниками. Тут можна зробити невелику поправку на випадок, коли в команді одні джуни, а PM має хороший технічний досвід — у такому разі команда має прислухатися до думки менеджера.

У моїх колег був досвід із адекватним менеджером. Розробники стояли перед вибором, як розвивати проєкт, написаний на старому Angular. Прийшов новий PM, попередній досвід якого був із командою, яка використовувала Vue, тому він запропонував: «Хлопці, у нас у минулій команді досить непогано працював Vue. Давайте, можливо, теж спробуємо?» Спілкування велося в дружньому ключі, своєї думки він не нав’язував. Розробники подумали, спробували й вирішили продовжувати проєкт на Vue.

Таска-мен

Менеджер, який не в змозі оцінити складність завдання і час на його виконання, а в якості бонуса нерівномірно розподіляє завдання в рамках команди.

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

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

Контроль-фрік

На відміну від Таска-мена, Контроль-фрік переймається тим, на що взагалі розробник витрачає час.

Я стикався з менеджером, який просив у окремій задачі фіксувати час, витрачений на code review. З одного боку, його можна зрозуміти. З іншого боку, мені взагалі не хочеться запам’ятовувати, скільки часу я витратив на код рев’ю, а скільки — на саме завдання, і фіксувати все це в різні тікети. Це зовсім не надихає.

Ще один приклад не налаштованих процесів — коли хлопці тиждень працювали, а в п’ятницю відстежували чотири години робочого часу у спеціальну задачу, яка так і називалася: «Трекінг».

Зрозуміло, менеджер повинен контролювати ситуацію на проєкті, але ставати наглядачем не потрібно. Поясніть команді причини, через які вам доводиться звітувати перед замовником за кожну секунду розробки (ви ж тому смикаєте людей, правда?), і разом знайдіть адекватне рішення, яке всіх влаштує.

Тому-що-мен

Ситуація, коли після співбесіди та зворотного зв’язку менеджер наполягає на кандидатові, який менше підходить на вакансію, тому що... тому що.

Реальний кейс: в компанію пройшли співбесіду семеро кандидатів. У результаті розробники висувають свою кандидатуру, яка, на їхню думку, найбільше підходить на зазначену посаду. А в один прекрасний момент менеджер незрозуміло чому (бюджет/діалог із клієнтом/інтуїція) пропонує взяти іншого. Чому? Тому що!

Чим менеджер керувався, пропонуючи таке рішення — велике питання. У результаті кандидат PM-а не впорався, оскільки просто не витягував цей рівень завдань. Довелося продовжити пошуки.

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

Я стикався і з іншою, досить специфічною ситуацією, де лід-розробник йшов із проєкту, і йому довго не могли знайти заміну. Коли лідові залишалося працювати кілька днів, з’явився кандидат, який у принципі підходив на його роль. Не ідеально, але підходив. А інших не було. У менеджера був напружений графік: треба було зарелізити багато фічів, і сидіти без розробника він собі дозволити не міг. У цьому випадку менеджер цілком виправдано став наполягати на заміні, і всі його зрозуміли.

На завершення

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