Як не PM нафакапить на новому проекті

Стаття написана у співавторстві з Мері Ротарь , Co-Founder IAMPM.

Привіт, я Павло Устинов, зараз працюю PMO в Solar Digital. З 15 років роботи в IT-сфері останні 7 керую проектами. За цей час вже навчився бачити обставини, які з великою ймовірністю завалять як мінімум дедлайн, а то й поставлять під питання доцільність подальшого співробітництва з замовником.

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

Поради і кейси з статті однозначно допоможуть junior PM заздалегідь «підстелити соломку», щоб не набити всі шишки на першому ж проекті. Досвідчені РМ'и теж, думаю, знайдуть для себе щось корисне: завжди цікаво дізнатися, як справляються з труднощами колеги.

Який проект вважати успішним

У проджект-менеджменті успіх управління проектом передбачає, що всі обмеження — Cost, Scope, Time, Quality — виконані в обумовлених обсягах і строках. Робота вважається завершеною, якщо зроблена:

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

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

Тому замість того, щоб концентруватися на тому, як управляти проектом, постарайтеся домогтися найкращого результату. І як наслідок — максимального моральної винагороди: коли те, що ми зробили, має успіх.

Успіх управління проектом vs успіх продукту

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

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

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

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

Чому проекти провалюються

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

Ось хвилинка суворих реалій проектного менеджера: тільки 34% IT-проектів виконується в строк, з запланованим бюджетом та обсягом робіт. Продукт запустили — і замовник задоволений результатом.

Решта 66% проектів частково неуспішні або є провальним: 51% проходять з відхиленнями від початкових умов, а що залишилися 15% взагалі кидають.

У моїй практиці були різні кейси. Один проект, пов'язаний з обладнанням, запустили до закінчення розробки самого обладнання. У підсумку проект трапився, але запускати його не на чому, тому закрили як є. В іншому фінтех-проекті пройшли 100500 державних перевірок, але до запуску технічно досконалого проекту змінилася правова база країни і продукт став не потрібен.

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

Погане знамення на проекті

Тут поговоримо не про прикмети або забобони, а, скажімо, про погані симптоми, на які варто звертати увагу. І враховувати наслідки, які вони можуть принести.

Найпоширеніші симптоми біди на проекті:

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

Якось на одному з Fixed Price проектів замовник раптом вирішив безконтрольно підвезти багато змін і доповнень. Заодно додав в проект дизайнера і розробника. Дизайнер виявився дуже старанний і зробив багато чудових макетів. Так обсяг роботи виріс і довелося довго переробляти те, що тепер стало неактуально.

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

Потік нестабільних вимог треба зупинити і розкласти на roadmap, інакше ви просто перепишіть продукт.

2. Проблеми з ресурсами . Наприклад, потрібно залучити додаткових фахівців, а це не передбачено бюджетом або вони зайняті. Тоді робота на проекті буде йти неритмічно, уривчасто.

Хороший приклад — роботи на неосновному внутрішньому проекті, який використовується замість bench будь-якому члену веб-студії. Уявіть, як зручно: як тільки звільнився якийсь ресурс — для нього є робота на проекті. Коли потрібен розробник на іншому проекті — оперативно надали людей.

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

3. Жорсткі терміни , в які неможливо вкластися. Часто Junior PM'и намагаються проявити себе перед замовником, погоджуючись на завідомо нереальні дати виконання робіт, тому що вважають, що швидкість виконання одно професіоналізм.

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

Тут мій досвід малює дві картини.

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

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

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

Фактори, що знижують ефективність команди

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

Коли РМ неправильно вибудовує внутрішньокомандні процеси — бути біді. Ось найпоширеніші помилки в управлінні:

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

Поширена помилка в побудові внутрішньокомандних процесів — це класичний кейс «Бігаємо по личкам». В команді є спринти/плани по навантаженню, але замовник або бос пише розробникам в лічку «дрібні поліпшення», або easy tweaks. І потім дивується, чому за три дні роботи по спринту/планом нічого не зроблено.

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

5 стереотипів про роботу PM'a, якими керуються джуни

Починаючи проект, менеджер усвідомлює власну роль у процесі: що потрібно робити, а що — ні, які очікування замовників і команди від менеджера і чого він сам чекає від співробітників. Однак іноді переконання РМ'а не збігаються з дійсністю і заважають налагодити нормальний робочий процес. Топ-5 помилок на початку кар'єри PM'а:

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

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

документацію непогано пишуть QA і DevOps, а реєструвати change requests можуть дизайнери і все ті ж QA;
провести демо може Junior React Developer, QA або BA, на худий кінець, Lead Developer.

2. Співробітники вміють «читати думки», а всі пояснення зрозумілі з першого разу. Частина інформації втрачається при передачі, але РМ цього не помічає: головне написати в чаті або поставити завдання в Jira. Коли так відбувається постійно, потрібно налагоджувати зворотний зв'язок, перевіряти, як виконавці зрозуміли завдання.

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

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

3. Інші знають про поставленому завданню стільки ж, скільки РМ. Це неправильна думка: обсяг знань про проект менеджера і команди потрібно час від часу синхронізувати, тому що розробники, наприклад, можуть знати більше або менше, ніж PM.

Найзручніше «насипати інформації на радіатор»:

на плануванні завдань, коли вся команда детально оцінює і докопується до суті;
на kick-out сесіях на початку спринту або ітерації;
в процесі рутинних UI Review, коли дизайнери дивляться, що виходить з UI розробників.

У той же час найлегше отримувати інформацію про те, що потрібно розробити, на воркшопах, BA-сесіях та UX/UI-демонстраціях. Не пропускайте ці мітинги, а то потім буде бо-бо!

4. PM — найрозумніший в команді. Менеджер, який «зірку впіймав» і не приймає чужий допомоги або рад, звужує бачення проекту виключно до власної точки зору.

C іншого боку, навіть якщо людина дійсно багато на себе бере, але справляється — напевно, проблема не така вже й проблема. Якщо PM'а сприймають нормально, він примудряється бути корисним і сфокусувати команду на результат, то й добре.

5. Команда вічно буде працювати в одному складі . Коли все налагодилося і процес йде, виникає самообман, що так буде завжди. Проте в середньому айтішник раз в 1,5-2,5 року змінює компанію. Тому в команді з 10 чоловік за два роки приблизно троє співробітників зміняться, і це потрібно враховувати при плануванні.

Бажано, щоб кодом володіло більше однієї людини. Для мене хорошим рішенням стало розподіл знань між командою та ведення документації. Приміром, на проекті SPA-програми, де класично задіяний один бекенд і один фронтенд, кожен з них буде володіти 100% коду своєї частини програми. Для підстраховки у мене ще буде крутитися Full Stack на повну або часткову зайнятість, плюс розроблена мінімальна документація. В цьому випадку навіть якщо хтось з фахівців піде, його буде не дуже складно замінити.

Як приймати новий проект

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

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

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

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

Pre-sale фаза — статус передпродажного циклу. Сейлз-менеджер продає безпосередньо послуги компанії, робить продажу, а проджект-менеджер забезпечує виробництво. Разом з менеджером з продажу РМ формує scope, кошторису і так далі. Треба виписати всі необхідні активності, порахувати — і запускати проект у роботу.
Після укладення договору. На цьому етапі вже все виписано і пораховано, залишилося прийняти новий проект і зробити його якомога краще.
На етапі формування вимог. Буває так, що клієнти почали писати вимоги по продукту, зрозуміли, що складно, потрібен бізнес-аналітик і менеджер, тому що проект явно не такий, як здавалося спочатку — і в такому вигляді віддали все в роботу. Тут треба засісти за збір і формування вимог . Пам'ятайте, опрацювати весь матеріал треба на однаковому рівні деталізації. Ваше завдання — знайти відповіді на всі «ніпанятна» і вирішити всі «приколи» проекту на самому старті.
«Як пощастить», Або етап «чорного ящика». Розробники вже два місяці пиляють код, життя б'є ключем, всі чимось зайняті, QA відсутня — а треба вже визначатися з роботами. І керівництво каже РМ'у: «Іди подивися, там новий проект, розберися».

Тут треба починати з базових питань: що відбувається і хто всі ці люди? Що це за проект? Де план або хоча б ТЗ? Як ми працюємо і відстежуємо прогрес? Які повноваження є у менеджера? (звільняти співробітників, наймати нових, впливати на рівень зарплати). Другим кроком буде повна і детальна ревізія проекту. Ну а далі складіть бэклог і поедайте його невеликими порціями в будь-яких кількостях.

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

Що повинно вийти в результаті?
Навіщо це робити: хто і коли буде використовувати продукт?
Коли потрібно робити проект і чому в цей час, а не інше?
Як довго повинна тривати розробка?
Хто і за допомогою яких засобів буде працювати над проектом, які конкретні люди?
Хто оплачує роботу?

Відповіді та вимоги варто зафіксувати у вигляді описів, діаграм, схем, технічних завдань, user story map.

Як не провалити існуючий проект

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

Є чотири кроки, які повинен зробити PM в існуючому проекті, щоб зрозуміти завдання і максимально швидко розібратися в ситуації:

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

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

Що робити, якщо все-таки «нафакапили»

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

У звичному розумінні слово «факап» — це якийсь промах з серйозними наслідками. Буває, що помилка невелика, а наслідки — суттєві.

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

Коли менеджер усвідомлює свій «косяк», у нього виникає бажання стати непомітним, сховатися. Таке відчуття з'являється тому, що для нашої культури характерно починати вирішувати проблеми з питання: «Хто винен?». Далі за «Хто винен?» випливає питання: «Хто це оплатить?». І вже в останню чергу запитують: «Що тепер робити?».

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

Як діяти РМ'у, якщо відбулася тотальна проблема, помилка, жорсткий конфлікт:

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

Ці три ключові дії допомагають виправляти ситуацію у випадку будь-якого «косяка», перетворюючи проблеми у безцінний професійний досвід.

Чинники успіху

Крім об'єктивних причин невдач, є фактори, що ведуть проект до успіху:

Залученість замовника . Чим більше ступінь залученості замовника в роботу над продуктом, тим прозоріше обговорення проблем і легше їх вирішувати. Можна наводити скільки завгодно метафор, коли люди діють на благо загальних цілей, але це не висловить і частини радості, коли замовник залучений в роботу і бачить її як є в правильному світлі.
Люди з топа моїх кращих замовників в основному володіють двома важливими властивостями:
1. У технічних проектах вони добре занурені в матчастину.
2. У проектах, пов'язаних з іншими проектами замовника, вони надають ефективну та своєчасну підтримку.
Підтримка вищого керівництва , в тому числі і в переговорному процесі. Робота йде легше, бо є додаткові люди, які стежать за перебігом подій, прискорюється вирішення внутрішніх і зовнішніх проблем.
Допомога досвідченого керівника на чолі проекту або Junior РМ у зв'язці з ментором. Досвід фахівця допомагає передбачати помилки до того, як вони виникли. Якщо є з ким обговорити проект — обговори. Як правило, старші керівники краще орієнтуються в тому, як прийнято поступати в тих або інших ситуаціях.

Крім того, старші товариші допоможуть опрацювати ризики і склади проектів в компанії.

Окремий потужний ресурс — це команда. І тут відповідальність менеджера, щоб створювати найкращі умови для роботи співробітників:

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

Підсумок

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

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

Опубліковано: 15/05/20 @ 07:00
Розділ Різне

SEO Блог