Чого розробники очікують від РМ-а, а РМ – від розробників?

Чого розробники очікують від РМ-а, а РМ – від розробників?

13 March 2023

  • Автор: Виктория Зименко

  • Складність: норм

  • Час: 7 хв

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

Тож, ми у статті «поглянули на проблему з обох боків» — коротко подали завдання розробників та РМ-а на проєкті. Крім опису обов’язків, ми розповіли, яким чином проєктному менеджеру слід ставити завдання та яку інформацію надавати, аби команда працювала злагоджено та чітко.

Поради засновані на практичному досвіді спікерів курсу TechMind: Project/Product Manager-а Дениса Шаматажи та Tech Lead-а Леоніда Неугодникова.

Яка роль PM на проєкті

Чого розробники очікують від РМ-а, а РМ – від розробників?

Завдання РМ-а —  реалізувати ідею замовника разом із командою. Для цього РМ має використовувати усі свої навички менеджера, керуючи різноманітними складовими проєкту. Сфери відповідальності проєктного менеджера є наступними:

  • Бюджет: скільки грошей слід витратити, аби розробити реліз.
  • Терміни: наскільки швидко РМ зможе одержати необхідну функціональність. В деяких проєктах нема чітких термінів. В інших ставлення до термінів може бути вкрай важливим, тому що дати «зав’язані» на маркетингу чи PR-процесах замовника.
  • Функціональність постачання: РМ-у слід жваво приймати рішення щодо функціональності, коли хтось із власників або інвесторів раптом каже: «Робіть що завгодно, але до середи ми маємо піти у продакшн».
  • Очікування: проєктному менеджеру доводиться мати справу не лише з очікуваннями замовника, але й з керівництвом та командою.
  • Взаємодія у команді: забезпечення ефективності та злагодженості роботи усіх учасників команди також є завдання РМ-а.
  • Ресурси: усвідомлення, скільки людей слід залучити до кожного конкретного моменту та забезпечення проєкта цими ресурсами.
  • Планування завдань: все, що стосується класичного Scrum-а: планування, постачання, демо, ретроспективи. Визначення найближчого скоупу, донесення його до команди, фасилітація та мінімізація ризиків;
  • Звітність за проєктом: керування документацією.

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

Що точно має робити Tech Lead

Чого розробники очікують від РМ-а, а РМ – від розробників?

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

  • Командний code review: дозволяє уникнути поняття «code owner», тому що всі, хто залучені до розробки, бачать код та усвідомлюють, що відбувається. Якщо хтось захворіє, знайти заміну буде простіше. Саме лід несе відповідальність за якість коду, тому він детально підходить до питання code review та ухвалює, що слід зробити, аби code review зміг потрапити до продакшну.
  • Підтримка якості коду: за допомогою code review, а також автоматичних інструментів, які перевіряють якість коду за заданими метриками.
  • Планування завдань/строків, тобто естімети у класичному розумінні. Ліду або розробнику слід брати участь у плануванні завдання разом з РМ-ом, тому що навіть у найпростішого технічного завдання можуть виникнути несподівані наслідки. Лід може передбачати потенційні проблеми ще до того, як вони виникнуть.
  • Вибір технологій/архітектури: з чого складатиметься додаток, як взаємодіятимуть його компоненти.
  • Узгодження технічної взаємодії: Tech Lead вирішує, коли фіча вважається готовою до тестування, що повинні перевіряти QA, які компоненти коду слід обов’язково покривати юніт-тестами.
  • Менеджмент технічного обов’язку: Техборг — це рішення, яке спочатку працювало добре, проте зараз його потрібно правити, бо воно не підходить до поточного стану проєкту. Технічний обов’язок з’явиться у будь-якому разі, це просто етап розвитку, наслідок того, що код написаний людьми. Тому одне із завдань ліда — це менеджмент техборгу на проєкті.
  • Розподіл завдань: крім того, що не можна звалювати серйозні завдання на джуна, є ще поняття експертизи: лід знає, хто в команді краще працює з платіжними системами, хто більше розуміється на обробці картинок, а кому краще довірити техборгі — і відповідно розподіляє завдання.
  • Підтримка необхідного клімату у команді: лід взаємодіє з учасниками команди розробки поряд із РМ-ом та стежить, аби усім було комфортно працювати, ніхто не залишився поза увагою.
  • Інтерв’ю потенційних працівників: яким би досвідченим не був рекрутер компанії, саме лід є тою людиною, яка поставить необхідні технічні питання претенденту та прийме остаточне рішення щодо нового співробітника.

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

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

Як РМ-у ставити завдання розробникам

Чого розробники очікують від РМ-а, а РМ – від розробників?

Аби розробники правильно зрозуміли завдання та виконали його добре, важливо не просто «якось описувати» вимоги, а й враховувати декілька умов. Так стане простіше працювати, а процес створення продукту рухатиметься швидше.

Які складові мають бути у задачі, аби розробник виконував роботу з ентузіазмом та розумінням:

  • Тіло завдання — Це найважливіший пункт. Коли РМ каже, що завданням є “змінити колір кнопки на екрані”, розробнику може бути незрозуміло: “На який колір поміняти, на якому екрані, яка кнопка?” Тіло завдання має бути вичерпним, включати definition of done або сценарії, що відрізняють виконану задачу від невиконаної. Чіткі критерії дозволять зрозуміти, що завдання виконано, причому, виконано правильно.
  • Терміни — на коли задвання має бути виконаним.
  • Пріоритети — розуміння того, в якому порядку розробнику слід виконувати щоденні завдання.
  • Взаємодія з іншими учасниками команди — бекенду важливо розуміти хто розроблятиме фронтенд на цій фічі, аби обговорити та зрозуміти, як створювати роботу в цілому.
  • Усвідомлення сенсу завдання — як лід, так і розробник здатні зрозуміти потенційні проблеми та ризики фічі. Тому завжди слід доносити до розробників сенс завдання: яку потребу бізнесу чи проблему користувача вирішує продукт. Інакше можна отримати декілька багів, яких можна було б уникнути з самого початку за умови належної комунікації.
  • Буфер часу на баги/інфраструктуру — люди помиляються просто тому, що вони люди, тому баги з’являться в будь-якому випадку – це неминучий процес розробки. РМ слід передбачати запас часу на усунення багів.
  • Прозорість процесу — одна з найважливіших речей. Якщо процес не дуже гарно налаштований, тоді в rework можуть прилітати тікети тримісячної давності без жодного опису. Такий процес є непрозорим, а розробнику незрозуміло, яким чином працювати із завданнями.

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

Досвідчений РМ має два статуси: звичайний та важливий (завдання поза чергою). Коли всі завдання у high-пріоритеті, то відбувається знецінення, тому що все одразу не може бути терміновим.

Що РМ-у та розробникам слід усвідомлювати у галузі знань один одного

Чого розробники очікують від РМ-а, а РМ – від розробників?

Які знання розробників важливо розуміти РМ-у

Суперечки щодо того, чи потрібна РМ технічна експертиза та яка саме, ніколи не закінчаться, тому що кожен, хто сперечається, може навести приклади успішних/неуспішних РМ-ів.

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

Що обов’язково знати:

  • Технології – те, з чим безпосередньо працює команда: наприклад, Android або IOS-розробка. Якщо менеджер розуміється на базових нюансах, предметно розуміється на тому, що відбувається, то немає потреби пояснювати прості речі.
  • Ризики та обмеження технологій: яке рішення можна виконати, а яке – не можна. Коли РМ розбирається в технології – у цьому є декілька переваг: розуміння, чи правильно розробник дає естімейт; мінімізація ризиків, тому що РМ здатний оцінити якісь технічні нюанси вже на етапі узгодження; здатність РМ-а самостійно обговорювати із замовникам майбутні фічі знімає зайве навантаження з розробників.
  • Версійність і як все влаштовано: РМ-у не потрібно глибоке знання на технічному рівні. Достатньо концептуального розуміння – навіщо використовувати різні версії або як додаток взаємодіє з сервером. Це допомагає РМ краще розумітися на роботі та спілкуватися з девелоперами.
  • Загальна інфраструктура: що таке “клієнт-сервери”. Майже всеу сучасній розробці – це «клієнт-сервери». РМ слід знати, що «клієнт» – це все, що бачать користувачі, наприклад, мобільний додаток, браузер або гаджет з програмним забезпеченням, а сервер – це якесь віддалене місце, де відбувається більша частина логіки, взаємодії з користувачем та напрями користувача всередині програми.
  • Зони відповідальності кожного учасника: якщо РМ розбереться, хто що вміє і де чия відповідальність – це допоможе знизити кількість конфліктів: РМ розумітиме, наприклад, чи варто приходити до розробника з проблемами логіки користувача та іншими питаннями.

TechMind

Що обов’язково знати розробнику з того, що знає РМ

  • Як працює процес: які кроки проходить фіча від розробки до користувачів.
  • Як менеджер оцінює роботу: допомагає зрозуміти, як бути ефективним та за якими метриками РМ вважає розробника корисним.
  • Для чого потрібні мітинги: які проблеми РМ намагається вирішити поточними мітингами (тобто розуміти мету).
  • Які проблеми вирішує продукт чи конкретна фіча: взагалі для кого вона розробляється.

Три поради РМ-у, як знайти спільну мову з командою розробки

Чого розробники очікують від РМ-а, а РМ – від розробників?

Менеджмент стресу

РМ і сам може бути втомленим, проте важливо зменшувати стрес у своєї команди, аби учасники ніколи не думали, що РМ у панічному стані і завтра все закриється.

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

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

Відкритість до діалогу та прагнення завжди бути на боці команди, відстоювати «своїх хлопців» дуже допомагає як команді, так і самому РМ у роботі над проєктом.

Вирішення конфліктів

Якщо РМ не планує дізнаватися про все за допомогою осяянь, то краще заздалегідь домовитися з командою: «Коли щось не подобається – прийди розкажи, постараюся вирішити питання. Якщо бентежить якась ситуація чи команда — витягни це завдання на ретроспективу, де ми обговоримо, наскільки добре чи погано пройшов певний відрізок часу».

Важливо, аби розробники завжди розуміли, що можна сказати: “Я втомився – допоможи мені”, або “Я хочу у відпустку”, а не покладалися на те, що РМ читає думки та сам здогадається про проблему.

Розуміння цінності задачі

Будь-який учасник команди обурюватиметься, якщо бачитиме, що його робота нікому не потрібна: інтерфейс, код або щось ще. Розуміння, яку вигоду приносить твоє конкретне завдання, дуже підвищує продуктивність.

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

Короткі підсумки

В ідеальному світі кожен виконує свої завдання і всі розуміють одне одного з першого погляду. Насправді ж конфлікти все-таки трапляються: через дедлайни, технічний обов’язок, некоректні Т3 та інші неприємні апдейти. Проєктний менеджер та тимлід — саме ті люди, які мають вести команду до мети, незважаючи на усі форс-мажори.

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

баннер на чекліст

Виктория Зименко

Пройшла шлях від копірайтера до Product Marketing Manager-a. Вміє у метрики та покращення процесів. Знає, де знайти лідів на вебінар і що з ними потім робити. Любить менторити підростаюче покоління фахівців.