Проєктний менеджер багатьом здається супергероєм: найкращий друг команди, вірний радник замовника, знає англійську від народження, вміє доносити інформацію жестами, миттєво додавати задачі в тасктрекер і гасити пожежі на проєкті голими руками. Але чи повинен він, на додачу, мати досвід розробки?
Диявол у деталях
Завдання проєктного менеджера далекі від написання коду, але для того, щоб заслужити повагу команди й довести проєкт до логічного завершення, PM зобов’язаний не просто виступати в ролі поштового голуба, доносячи повідомлення замовника команді, а цілком взяти в свої руки управління розробкою.
Проблема в тому, що для цього треба вникати. Я знаю кілька ситуацій, де проєктний менеджер припустився помилки саме через прогалини в матчастині, а покарання понесла вся команда.
Кейс перший. Не відстояв інтереси команди
PM вибрав неправильну систему контролю версій. Точніше, не допоміг вибрати правильну.
Що таке система контролю версій? Якщо проводити аналогію з комп’ютерними іграми, то це можливість будь-якої миті зберегтися, і, якщо щось не вийшло, пройти рівень із контрольної точки заново.
Наш замовник у минулому мав досвід розробки (як потім виявилося, йому було десь за 50) і, виходячи зі свого досвіду, з двох варіантів систем контролю версій (консервативної SVN і сучасної GIT) він вибрав SVN, аргументуючи тим, що буде, час від часу заходити й перевіряти, як іде робота. Це сильно гальмувало розробку і псувало настрій всій команді, тому що більш наворочений GIT у десятки разів зручніший, та й звичний. Чи треба говорити, що ми просили PM-а вплинути на думку замовника?
Коли стадія планування закінчилася, і ми розпочали активну роботу, виявилося, що питання і не порушувалося. Думаю, якби проєктний менеджер розумів всю важливість правильної системи контролю версій, він не проігнорував би наше прохання.
Кейс другий. Влетіли в копієчку
Не менш цікавим випадком стала ситуація, коли PM прийняв у роботу ряд задач, пов’язаних з аудіо-плеєром на сайті. Одним із критеріїв приймання було те, що на сайті весь час (не зупиняючись) мала грати музика, а сайт спочатку був спроєктований так, що даний функціонал без милиць і шишок створити було неможливо.
Чи коштував цей плеєр витрачених на нього часу й сил так і залишилося загадкою. Можливо, поясни проєктний менеджер замовнику все спочатку, той би передумав і вибрав простіший варіант реалізації, але цього не трапилося і розробка влетіла клієнту в копієчку.
Кейс третій. Немає доступів — немає роботи
Постійному клієнту команди знадобився маленький хотфікс на сервері у вихідні дні. Відносини із замовником були настільки хороші, що розробник був не проти у свій вихідний день витратити пару годинок на роботу. Всі начебто домовилися, після чого менеджер проєктів мав дістати доступи до сервера й передати програмісту.
Однак, не розуміючи всієї серйозності поставленої задачі, PM просто забув це зробити. Не отримавши даних, програміст вирішив, що задача відпала й добре провів вихідні.
Ранок понеділка вийшов незручним, адже коли менеджер прийшов за результатом, повисла довга пауза. Який, власне, може бути результат, якщо потрібних доступів фахівець так і не отримав?
То що має знати проєктний менеджер?
Насправді PM — це людина, яка вміє всього потроху, але, в першу чергу, вона має бути ефективним комунікатором.
Що потрібно, щоб бути хорошим PM-ом:
- вміння швидко й ефективно розбиратися у предметній галузі проєкту;
- розуміння життєвого циклу створення ПЗ;
- знання методологій побудови процесу створення ПЗ;
- вміння аналізувати потреби замовника та його бізнесу;
- вміння планувати свій і чужий час;
- вміння стояти на своєму та просувати інтереси замовника чи команди;
- вміння мотивувати працівників;
- навички тайм-менеджменту;
- навички управління фінансами у проєкті;
- навички керування командою;
- навички управління зовнішніми та внутрішніми комунікаціями.
На цьому список тільки починається, адже щоб побудувати ефективні комунікації потрібно розуміти тих, хто пише код, що «розширюється і підтримується», і розуміти основні терміни.
- знати як зберігаються дані на проєкті;
- чим відрізняється frontend від backend;
- чим мови програмування відрізняються одна від одної;
- як відбувається деплой проєкту (хоча б куди);
- розуміти, що таке HTTP і JSON формат;
- знати основні етапи розробки програм залежно від сфери;
- вміти гуглити.
Дані навички допоможуть менеджеру бути ближчим до команди та зведуть до мінімуму ситуації відсутності доступів до сервера й репозиторій, обіцянки виправити неполадки за годину (якщо фактично роботи на весь тиждень), скоротять кількість невірних оцінок, а також дадуть зрозуміти команді, що їх PM не просто листоноша, а такий же IT-шник, як і вони самі.
Як підтягнути матчастину?
Підбиваючи підсумки, хочу сказати, що технічні знання для проєктних менеджерів важливі. Проте відсутність досвіду в розробці – не вирок. Вихідці з інших сфер, виявляючи допитливість і запопадливість, можуть ставати прекрасними управлінцями в IT-сфері.
Щоб заговорити однією мовою з програмістами, потрібно виявити бажання розібратися в їхній справі. Хорошою практикою є проходження курсів (можна вивчити основи якоїсь мови програмування, або одразу пройти курс з технічних знань для нетехнарів). Буде корисним читання книг з архітектурних підходів, відвідування тематичних заходів і хакатонів.
Не соромтеся ставити питання своїй команді, адже краще тричі запитати, ніж один раз помилитися зі строками й оплатою. Пам’ятайте, ваша головна задача — працювати зі своєю командою пліч-о-пліч і досягати максимального розуміння в будь-якій ситуації!