Чи повинен PM вникати у процес розробки: розбираємо на прикладах

Чи повинен PM вникати у процес розробки: розбираємо на прикладах

23 March 2023

  • Автор: Дмитро Ховрич

  • Складність: ізі

  • Час: 4 хв

Проєктний менеджер багатьом здається супергероєм: найкращий друг команди, вірний радник замовника, знає англійську від народження, вміє доносити інформацію жестами, миттєво додавати задачі в тасктрекер і гасити пожежі на проєкті голими руками. Але чи повинен він, на додачу, мати досвід розробки?

Диявол у деталях

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

Чи повинен PM вникати у процес розробки: розбираємо на прикладах 1

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

Кейс перший. Не відстояв інтереси команди

PM вибрав неправильну систему контролю версій. Точніше, не допоміг вибрати правильну.

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

Наш замовник у минулому мав досвід розробки (як потім виявилося, йому було десь за 50) і, виходячи зі свого досвіду, з двох варіантів систем контролю версій (консервативної SVN і сучасної GIT) він вибрав SVN, аргументуючи тим, що буде, час від часу заходити й перевіряти, як іде робота. Це сильно гальмувало розробку і псувало настрій всій команді, тому що більш наворочений GIT у десятки разів зручніший, та й звичний. Чи треба говорити, що ми просили PM-а вплинути на думку замовника?

Чи повинен PM вникати у процес розробки: розбираємо на прикладах 2

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

Кейс другий. Влетіли в копієчку

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

Чи повинен PM вникати у процес розробки: розбираємо на прикладах 3

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

Кейс третій. Немає доступів — немає роботи

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

Однак, не розуміючи всієї серйозності поставленої задачі, PM просто забув це зробити. Не отримавши даних, програміст вирішив, що задача відпала й добре провів вихідні.

Чи повинен PM вникати у процес розробки: розбираємо на прикладах 4

Ранок понеділка вийшов незручним, адже коли менеджер прийшов за результатом, повисла довга пауза. Який, власне, може бути результат, якщо потрібних доступів фахівець так і не отримав?

То що має знати проєктний менеджер?

Насправді PM — це людина, яка вміє всього потроху, але, в першу чергу, вона має бути ефективним комунікатором.

Що потрібно, щоб бути хорошим PM-ом:

  • вміння швидко й ефективно розбиратися у предметній галузі проєкту;
  • розуміння життєвого циклу створення ПЗ;
  • знання методологій побудови процесу створення ПЗ;
  • вміння аналізувати потреби замовника та його бізнесу;
  • вміння планувати свій і чужий час;
  • вміння стояти на своєму та просувати інтереси замовника чи команди;
  • вміння мотивувати працівників;
  • навички тайм-менеджменту;
  • навички управління фінансами у проєкті;
  • навички керування командою;
  • навички управління зовнішніми та внутрішніми комунікаціями.

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

Що, на думку програмістів, повинен знати та вміти хороший PM:

  • знати як зберігаються дані на проєкті;
  • чим відрізняється frontend від backend;
  • чим мови програмування відрізняються одна від одної;
  • як відбувається деплой проєкту (хоча б куди);
  • розуміти, що таке HTTP і JSON формат;
  • знати основні етапи розробки програм залежно від сфери;
  • вміти гуглити.

Дані навички допоможуть менеджеру бути ближчим до команди та зведуть до мінімуму ситуації відсутності доступів до сервера й репозиторій, обіцянки виправити неполадки за годину (якщо фактично роботи на весь тиждень), скоротять кількість невірних оцінок, а також дадуть зрозуміти команді, що їх PM не просто листоноша, а такий же IT-шник, як і вони самі.

TechMind

Як підтягнути матчастину?

Підбиваючи підсумки, хочу сказати, що технічні знання для проєктних менеджерів важливі. Проте відсутність досвіду в розробці – не вирок. Вихідці з інших сфер, виявляючи допитливість і запопадливість, можуть ставати прекрасними управлінцями в IT-сфері.

Чи повинен PM вникати у процес розробки: розбираємо на прикладах 5

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

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

Дмитро Ховрич

Fullstack developer. Один із небагатьох розробників, хто готовий відповідати на запитання менеджера і може зрозуміло пояснити навіть найскладніші речі. Понад 4 роки в IT. Fullstack developer у аутсорсинговій компанії Instersog. Виступає на заходах та навчає студентів. Пише такими мовами програмування: C#, Javascript, Typescript, використовує технології: React JS, Angular, Node.JS, SQL, MongoDB, .NET та .NET Core. Працював у десятках проєктів, у тому числі у великих медичних та телекомунікаційних продуктах. Любитель мікросервісів. Викладач курсу Techmind.