Junior Project Manager — одна з найспірніших позицій у сфері IT. Вважається, якщо вже ставити людину керувати проєктом — це обов’язково має бути досвідчений управлінець, який виріс із Middle to Senior розробника й ідеально розуміється на технічних нюансах. Ось тільки програмісти частіше інтроверти, ніж екстраверти, а коли в команді 10 синьйорів, хтось має почути кожного й ухвалити виважене рішення. До того ж, розробники вважають за краще рости не в PM-и, а в тімліди та СТО.
Щодо технічних знань, згодні, ми навіть маємо окремий курс, який задумувався для того, щоб PM міг комунікувати з розробником без додаткових уточнюючих питань, але в іншому вважати, що менеджером не може стати людина без досвіду в IT — неправильно. Просто новачків очікують помилки, завжди, й це так у кожній професії.
До нас на курс DAO PM приходять люди з різним бекграундом, після чого влаштовуються на свою першу роботу… Факапити й рости. Для цієї статті ми попросили друзів IAMPM, зараз уже проєктних менеджерів із досвідом, розповісти про свої помилки на позиції Junior PM.
Найсміливіші PM-и не засоромилися відкрити нам дверцята своїх шаф зі скелетами. А ми їх відсортували за кісточками й розбили за категоріями, щоб було цікаво й повчально читати. Одразу попереджаємо: факапи — не завжди щось смішне, але ж ми сюди прийшли не тільки за веселощами.
Частина 1. Факапи під час роботи з клієнтами
Клієнти теж люди, хто б що про них не говорив. А люди бувають різними: довірливими й підозрілими, справедливими й упередженими, щедрими й не дуже. А ще клієнти бувають зі специфічними вимогами, які знаходяться за межею добра і зла. Саме такий персонаж і відкриває наш список випробувань для Junior PM-ів.
Історія 1. Коли від PM-а нічого не залежить
Зараз ця дівчина давно вже успішно працює в IT, але на початку своєї кар’єри вона зіткнулася з незвичайним замовником, який відмовився співпрацювати не тому, що менеджерка мала недостатньо досвіду, а просто тому, що вона — дівчина. І тут можна було б сказати, що у всьому винні чоловіки, якби не один маааленький нюанс: замовник і сама була дамою із Сінгапуру.
Висновок: коли справа доходить до ринку IT, ейджизм і ґендерна дискримінація мають місце (як би всі не говорили про толерантність). Просто змиріться.
З іншого боку, краще одразу поставити хрест на співпраці, ніж працювати з клієнтом із наступної історії.
Історія 2. Повчальна
За часів своєї Junior PM юності, один із наших друзів загубив лист, у якому було твердження клієнта, що треба робити місячне доопрацювання. Клієнт виявився з категорії суворих бізнесменів, тож після місяця роботи над проєктом почав усе заперечувати.
Висновок: фіксуйте будь-яке зітхання замовника, що стосується фінансової сторони, а також зміни й уточнення вимог. Іноді корисно вести бортовий журнал проєкту, де можна швидко знайти інформацію про важливі зміни, а також прикріпити скріншоти листування або посилання. До речі, диктофон і запис відеодзвінків теж чудові інструменти в боротьбі за справедливість. Тільки попередьте замовника про те, що ви це робите наперед, а не постфактум.
Не всі замовники погані. Іноді вони просто не можуть виразно донести свої думки про завершальне бачення продукту. Про це розповідає третій кейс.
Історія 3. Коли PM-у доводиться виконувати роль бізнес-аналітика
Ця історія про відважного PM-а, який очолював команду розробки в їхній славній битві з проєктування фінансового сервісу. Замовник хотів, щоб продукт умів усе (або майже все). Для цього, в міру реалізації функціоналу, він вигадував покращення та просив їх впроваджувати.
— А давайте додамо модуль бухобліку? — генерував замовник нову ідею.
— Звісно! — PM вже почав декомпозувати завдання на майлстоуни.
Як тільки модуль бухобліку було додано, замовник поспішав з новим проханням:
— Хочу модуль для підрахунку KPI співробітників компанії!
— Я знаю, кому це доручити! — Відважному PM-у подобався такий підхід, зрозумілі завдання, все чітко й по поличках.
Від модуля до модуля ці двоє все більше розуміли один одного, поки одного прекрасного дня замовник не вирішив, що світ готовий бачити його маленький шедевр зі світу фінансових продуктів. У цей момент проєкт зіткнувся з реаліями ринку: таке рішення ніхто не хотів купувати. Продукт робив дуже багато, але не вирішував проблем потенційних користувачів. В результаті рішення померло, не отримавши й сотні клієнтів.
Висновок: звичайно, PM не завжди має виконувати обов’язки продакта. Деколи аутсорсингу навіть на користь, що клієнт робить щось важливе й систематично платить. Гроші-то капають. Але як це потім позначиться на репутації менеджера, та й самої компанії? Відповідь очевидна.
Тому краще не допускати розробки заради розробки. Дізнайтеся основну мету, з досягненням якої проєкт вважатиметься успішним. Свого роду acceptance criteria, але тільки не для фічі, а для проєкту загалом. Тоді, виконуючи майлстоуни, можна буде коригувати дії відповідно до кінцевої мети. Краще провалити план і зробити новий, ніж провалити проєкт і повністю його поховати.
Історія 4. Проблеми комунікації
Просто перечитуйте те, що ви пишете. Хоч інколи.
PM поговорив сам із собою і ще більше заплутав замовника
Висновок: краще поставити 1 питання і отримати відповідь, ніж змішувати опис ситуації зі списком уточнень, тим самим збиваючи людину з пантелику. Відповідаючи на такий лист, замовник може упустити частину питань, їх доведеться задавати знову, вкотре дратуючи клієнта.
Якщо в ході листування клієнт погодиться на інше рішення, потрібно зберігати всі його апруви, оскільки трапляються ситуації, коли факт наявності затвердженого ТЗ може бути сприйнятий як аргумент на користь команди розробки.
Про це є наступний випадок.
Історія 5. Істеричний замовник
Цього разу нашому другу пощастило: душка-клієнт з невеликим проєктом, який швидко затвердив ТЗ і дизайн, не затримував платежів і вчасно надсилав контент для роботи. Через 3 місяці команда здала проєкт у термін і додаток опинився в Google Play. Здавалося б, хепіенд, але ні. Рівно за 2 години після релізу клієнт вже обривав телефон і засмучувався, що на Xiaomi його бабусі 2005 року додаток не запускається.
Замовник був упевнений, що софт працюватиме на будь-якому девайсі, а аргумент про те, що в ТЗ було прописано мінімальну підтримувану версію ОС, він просто ігнорував. Істерика тривала 3-4 місяці й дуже псувала настрій як керівництву, так і проєктному менеджеру. Начебто й зробили все правильно, але не так.
Висновок: завжди детально обговорювати з клієнтом, на якому обладнанні й софті працюватиме продукт. Особливо важливо проговорювати очікувану підтримку версій програмного забезпечення. Замовник — не професіонал у розробці й може не знати нюансів. Цінність команди полягає в тому, щоб підказати йому, які можуть виникнути труднощі й обмеження.
Історія 6. А раптом клієнт визнає мене настирливим?
Всім менеджерам аутсорсу знайома ситуація, коли не хочеться писати замовнику з дрібних питань. У той же час, якщо від його відповідей залежить реалізація продукту — потрібно брати себе в руки й писати/дзвонити/діставати бідолаху з-під хвилі важливих завдань та іншого пінгу.
Ось дивно? Не відповідає. Може тому, що PM писав клієнту тиждень тому?
Висновок: якщо клієнт не відповідає — постарайтеся знайти його будь-якими способами, але не за тиждень. А ще поставте на пошту плагін, наприклад, mailtrack — він допоможе зрозуміти, коли листа відкрили. При нагоді можна довести клієнту, що листа він не просто бачив, а ще й відкривав кілька разів.
Це у випадку, якщо з якихось причин оперативним каналом спілкування залишилася пошта. Краще, звичайно, затвердити з клієнтом сценарій, в якому вказано порядок дій команди, якщо вона не може продовжувати роботу без відповіді на низку питань.
Наприклад:
- Команда зупиняє проєкт і йде на інший до з’ясування обставин.
- Рішення залишається за помічником клієнта (контактні дані) або за PM-ом, і воно не повинно оскаржуватися в подальшому.
Такий сценарій дозволяє компанії підстрахуватися від непередбачених простоїв.
Частина 2. Факапи під час роботи з командою
Щоб стаття не вийшла односторонньою, ми дізналися думку спеціалістів із команди розробки про задачі PM-a, реалізація яких викликає в них максимальну кількість смутку й печалі.
Біль 1. Овертайми
На годиннику 15:45, до мітингу з керівництвом компанії залишилося рівно 15 хвилин. PM-у в Telegram прилітає повідомлення від клієнта: «Люди, потрібно за сьогодні пофіксити ось ці баги, оскільки завтра вранці показую продукт інвесторам». PM негайно вирішує, що правки займуть від сили 2 години, тому пише замовнику «ок» і вирушає на мітинг. На зустрічі PM дізнається про нові задачі та KPI, так що через годину повністю забуває про обіцяні правки, акурат до наступного повідомлення замовника.
О 20:00 клієнт нагадує про себе: «Як ваші справи, вже можна тестувати?» PM хапається за голову (ніхто нічого робити й не починав), перепрошує перед замовником, і каже, що все вже робиться, але завдання виявилося складнішим, ніж здавалося спочатку.
Після цього весь вечір команда присвячує багфіксу. При цьому команді менеджер каже, що замовник зі своїми правками з’явився тільки тепер і не заплатить, якщо вони зараз швидко не пофіксять баги.
Висновок: ставте будильник, наклеюйте стикер на ноут, створюйте задачу з 2 слів з дедлайном за годину, але не змушуйте команду працювати понаднормово, якщо є хоч найменша можливість так не чинити. А ще — не брешіть. Цю історію нам розповів не PM, а розробник, який у спілкуванні з клієнтом випадково з’ясував правду про те, коли насправді надійшло завдання з багфіксу.
Біль 2. Як щодо взяти на себе трохи відповідальності?
Наступна сумна історія трапилася з PM-ом, який, очевидно, тільки почав вникати в деталі проєкту й не до кінця розібрався з тим, що відбувається довкола.
Висновок: Якщо PM працює на проєкті — нехай про це пам’ятає… і не забуває підняти проєкт.
У команді в кожного є свої ролі й всі один від одного очікують на відповідну поведінку. Але якщо керівництво вирішило не посвячувати PM-а в процеси компанії, а він ще надто юний і соромиться ставити зайві питання, то може трапитися вищеописана ситуація. Парочка подібних переписок допоможе PM-у освоїтися на новому проєкті, але краще б про свої обов’язки знати заздалегідь.
Біль 3. Коли PM живе у своєму вигаданому світі
Команда буде лояльніше ставитися до PM-а, який називає речі своїми іменами: стадіон так стадіон, мокап так мокап. В іншому випадку нормою можуть стати повідомлення наступного виду:
Висновок: з командою краще бути на одній хвилі, так і завдання стають зрозумілішими, і зворотний зв’язок змістовнішим. Продавати мокап за дизайн — це спеціалізація зовсім іншого напрямку (наприклад, sales відділу), але сьогодні не про це.
Частина 3. Як ніколи не помилятися
Ніяк. Навіть якщо ввібрати досвід усіх проєктних менеджерів у світі, виявиться, що саме сьогодні з’явився замовник з унікальними, небаченими досі заскоками. Натомість, спираючись на чужий досвід, можна отримати загальне уявлення про те, що таке проєктний менеджмент і чи підходить він бажаючим «увійти в IT». З цією метою ми створили спецпроєкт «Виживання PM-a», де розповіли про основні категорії замовників, різницю між фреймворками на прикладі наметів у лісі й зібрали базові поради новачкам. Проєкт розвивається силами PM-ів, що вижили, які діляться своїми історіями й роблять внесок у спільну справу.
Менеджери, пам’ятаєте, ви не самі!
