Чекліст PM на новому проєкті

Спершу зрозумійте, у якій ви ситуації

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

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

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

Дні 1–30: з’ясуйте, як робота тече насправді

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

Компанія й люди в ній

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

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

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

Продукт, процес і контракт

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

Аудитуйте процес, спостерігаючи за ним, а не читаючи про нього. У вікі написано Scrum; важливо ж, чи дає ретроспектива зміни, чи переживає оцінка спринт, чи може хтось щось завершити, не чекаючи на одну людину. Два тижні сидіть на кожній церемонії й не кажіть нічого, крім питань.

П’ять чисел, які можна зібрати лише зараз

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

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

Інструменти, документація й те, що знав попередній менеджер

Отримайте доступ до кожної системи, якої торкається робота, — трекер, вікі, чат, репозиторій, CICI/CDContinuous Integration / Continuous Delivery — автоматична збірка й доставкаКожен коміт автоматично складається і проганяється через тести (CI), а придатна збірка так само автоматично їде на сервери (CD). Сенс не в автоматизації як такій, а в тому, що поломку видно за хвилини, а не в день релізу.Докладніше в статті →Усі терміни, моніторинг, портал клієнта, якщо він є, — і позначте, яка з них справжня. Завжди є розрив між інструментом, яким процес нібито користується, і місцем, де рішення ухвалюють насправді; на більшості проєктів це тред у чаті. Оцініть документацію так само: не чи вона є, а чи зміг би нею скористатися інженер, який приходить наступного тижня, — і записуйте кожну прогалину в момент, коли на неї натрапили. Цей список вартий більше на третьому тижні, ніж будь-коли потім, бо за місяць ви перестанете помічати.

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

Дні 31–60: домовитися, що зміниться і з ким

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

Узгодьте, що означає успіх, письмово

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

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

Міняйте по одному

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

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

Налаштуйте комунікацію один раз

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

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

Дні 61–90: приземліть зміну й назвіть наступне

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

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

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

Сам чекліст

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

1–30 днів: Занурення та адаптація

1. 1.Ознайомлення з компанією та командою

   1. 1.1Прочитати Onboarding-документ або створити його, якщо немає.
   2. 1.2Провести знайомство з ключовими стейкхолдерами: менеджмент, команда, клієнти.
   3. 1.3Дослідити організаційну культуру, місію, цінності та структуру компанії.

2. 2.Аналіз проєкту та процесів

   1. 2.1Вивчити продукт, ключові технології, бізнес-модель.
   2. 2.2Ознайомитися з поточним беклогом, планами, roadmap.
   3. 2.3Провести аудит поточних процесів управління проєктами (Agile, Waterfall, Hybrid).

3. 3.Інструменти та документація

   1. 3.1Ознайомитися з використовуваними інструментами (JIRA, Confluence, Notion, Slack тощо).
   2. 3.2Оцінити якість технічної та проєктної документації.
   3. 3.3Визначити прогалини у процесах та задокументувати їх.

31–60 днів: Оптимізація та покращення

1. 4.Планування та стратегія

   1. 4.1Визначити ключові проблеми та зони для покращення.
   2. 4.2Узгодити цілі та KPIKPIKey Performance Indicator — число, що відстежує станЧисло, обране, щоб показувати, чи все йде добре. Вада вбудована всередину: щойно KPI стає ціллю, за яку винагороджують, воно перестає вимірювати те, заради чого його обрали.Докладніше в статті →Усі терміни для себе на випробувальний термін.
   3. 4.3Сформувати чіткий план дій на наступні місяці.

2. 5.Оптимізація процесів

   1. 5.1Внести коригування в управління ризиками.
   2. 5.2Оптимізувати ритуали командної роботи (мітинги, ретро, стендапи).
   3. 5.3Перевірити та покращити систему звітності та метрик.

3. 6.Налагодження комунікації

   1. 6.1Впровадити або адаптувати систему звітності: збори, дашборди, апдейти.
   2. 6.2Визначити ключові формати комунікації для команди та бізнесу.
   3. 6.3Запровадити best practices для роботи з командою.

61–90 днів: Вплив та масштабування

1. 7.Впровадження змін

   1. 7.1Презентувати результати аналізу та оптимізацій.
   2. 7.2Впровадити перші покращення в процесах.
   3. 7.3Запуск ініціатив з підвищення продуктивності команди.

2. 8.Оцінка ефективності

   1. 8.1Оцінити прогрес та отримати фідбек від команди та керівництва.
   2. 8.2Аналіз показників продуктивності: VelocityVelocityскільки вміщується у спринтСкільки команда реально завершує за спринт, усереднено за кілька. Це допоміжна величина для планування однієї конкретної команди й нічого більше: порівнювати velocity двох команд чи ставити її за ціль означає надійно отримати роздуті оцінки, а не більше роботи.Докладніше в статті →Усі терміни, Cycle timeCycle timeвід початку роботи до «готово»Час від моменту, коли роботу справді почали, до моменту, коли її завершили, — це lead time мінус очікування до того, як за неї взялись. Різниця між ними і є чергою, і поліпшення зазвичай ховається саме там.Докладніше в статті →Усі терміни, Quality metrics.
   3. 8.3Визначити наступні покращення на майбутній період.

3. 9.Довгострокова стратегія

   1. 9.1Визначити пріоритети на наступний квартал.
   2. 9.2Спланувати масштабування та покращення процесів.
   3. 9.3Запропонувати стратегічні ініціативи для росту проєкту.

Де план на дев’яносто днів іде не так

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

• Поставка за шість тижнів після приходу. Спершу стабілізуйте й діагностуйте паралельно, — але збережіть порядок і все одно зберіть базові числа за перші три дні.
• Цілком новий проєкт без історії. Немає чого слухати: це ситуація старту, і перший місяць — це будувати базу, а не вивчати її.
• Немає повноважень щось змінювати. Тоді результат — це вплив, а не план, і дев’яносто днів витрачають на здобуття права пропонувати, а не на пропозиції.
• Чекліст стає театром: усі клітинки позначені, діагноз не написаний, і третій місяць приходить із нічим, окрім заповненого списку.
• Ритуали міняють, не спитавши, навіщо вони існують. Щоденна зустріч, що виглядає безглуздою, часто є єдиним місцем, де говорять дві команди.
• Обіцянка дати на першому тижні, щоб продемонструвати впевненість. Тепер ви володієте оцінкою, зробленою до того, як щось знали, і в четвертому місяці вам її процитують.
• Зробити попереднього менеджера винуватцем. Усі в кімнаті рахують, що ви скажете про них, — і мають рацію.
• Плутати симпатію з довірою. Перше приємне в перший місяць і нічого не варте в шостий.

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

Коли це застосовувати

Пов’язані сторінки

• МенеджментРизик-менеджментРизик-менеджмент — це рішення наперед про те, що може піти не так, на що з цього варто витратити гроші вже зараз і хто помітить, якщо воно почнеться. Ризик — це ще не проблема, і саме тому з ним дешево мати справу. Сторінка починається з повної карти — сім груп і двадцять вісім рядків, які можна звірити з власним проєктом, — а далі: як оцінити ризик без вдаваної точності, чотири відповіді, практики, які справді зрушують число, і шість публічних провалів із контролем, якого в кожному бракувало.
• МенеджментМетрики та KPIМетрика — це число із записаним визначенням, за яким команда керує, а KPI — одна з небагатьох метрик, за якими команда чи компанія погодилася, щоб її оцінювали. Майстерність — у тому, щоб збудувати ланцюг від того, що команда може зрушити цього тижня, до того, що потрібне бізнесу цього року, тримати кожне число чесним під тиском і читати його, не обманюючи себе. Сторінка починається з готового набору метрик однієї команди; далі — слова й ланцюг, як записати визначення, закон Гудхарта й захисні метрики, одне число нагорі й дерево під ним, як читати число, чотири числа, що ввели в оману своїх власників, і де все це вироджується.
• МенеджментОрганізаційні структури управлінняОрганізаційна структура — це те, як компанія ділить роботу між підрозділами й хто кому підпорядковується, а отже — хто дає проєкту людей, гроші й рішення. Лінійна, функціональна й матрична — це не методології управління на кшталт Scrum чи Kanban. Це форма організації, всередині якої методології доводиться працювати, і вона визначає, скільки повноважень насправді має людина, що веде проєкт. Сторінка починається з усіх поширених структур поруч і п’яти питань, які покажуть, у якій із них ви працюєте, а далі — два питання за кожною структурою, класичні ієрархії, матриця і дев’ять її відомих збоїв, проєктні й продуктові команди, закон Конвея, компанії, що пробували обійтися без менеджерів, і де реструктуризація перетворюється на театр.