Керувати програмними проектами складно навіть за найкращих обставин. Команда має збалансувати конкуруючі інтереси зацікавлених сторін із обмеженнями ресурсів і часу, постійними змінами технологій і нездійсненними вимогами людей. Управління проектами передбачає управління людьми, технологіями, ризиками, вимогами, очікуваннями, постачальниками тощо. Це жонглювання багатьма м’ячами в повітрі одночасно.
Ось 20 практик, які, на мою думку, суттєво сприяють успіху в управлінні проектами. Вони застосовуються незалежно від того, чи є “проект”, про який ви думаєте, окремою ітерацією розробки, випуском продукту або цілою ініціативою з розробки. Ви можете відкинути ці практики як “традиційне управління проектами” і, отже, вони не стосуються вашого проекту з гнучкою розробкою. Але це не так. Гнучка команда все одно повинна виконувати ці дії (хоча іноді й під іншими назвами), але ітеративно та поступово, наприклад, проводити ретроспективу ітерацій, а не лише загальну ретроспективу проекту.
Я розділив двадцять практик за п’ятьма категоріями:
- Закладання фундаменту
- Планування проекту
- Оцінка робіт
- Відстеження вашого прогресу
- Навчання для майбутнього
Закладання фундаменту
Практика #1: Визначення критеріїв успіху. Переконайтеся, що зацікавлені сторони мають спільне розуміння того, що являє собою успіх проекту. Чіткі, кількісні бізнес-цілі передбачають конкретні критерії успіху, які повинні бути вимірюваними і відстежуваними. Не має значення, чи вклалися ви в графік і бюджет, якщо ці фактори не збігаються з бізнес-успіхом.
Практика #2: Визначення стимулів, обмежень та ступенів свободи проекту. Кожен проект має бути ретельно збалансований за обсягом, персоналом, бюджетом, графіком і якістю. Визначте кожен з цих п’яти аспектів проекту як обмеження, в рамках якого команда повинна діяти, як фактор, від якого залежить успіх проекту, або як ступінь свободи, яку ви можете регулювати в певних межах. Усі п’ять вимірів не можуть бути обмеженнями, інакше команда зазнає невдачі.
Практика #3: Визначення критеріїв релізу продукту. Заздалегідь вирішіть, як ви будете оцінювати, чи готовий продукт до релізу. Критерії випуску можуть враховувати функціональність, продуктивність, бізнес та якість. Ваші критерії повинні бути реалістичними, об’єктивно вимірюваними, задокументованими та узгодженими з тим, що “якість” означає для ваших клієнтів.
Практика #4: Обговорювати досяжні зобов’язання. Незважаючи на тиск, що змушує вас обіцяти неможливе, ніколи не беріть на себе зобов’язання, якщо ви знаєте, що не зможете його виконати. Переговори потрібні щоразу, коли є розрив між графіком або функціональністю, яку вимагають ключові зацікавлені сторони, і вашими найкращими прогнозами на майбутнє. Плануйте переглядати зобов’язання, коли змінюються реалії проекту (персонал, бюджет, терміни), матеріалізуються ризики або з’являється нова функціональність.
Планування проекту
Практика #5: Напишіть план. Найважче не написати план. Найскладніше – це планувати: думати, домовлятися, балансувати, запитувати, слухати і ще раз думати. Час, який ви витратите на планування, може зменшити кількість майбутніх сюрпризів. План проекту або ітерації не повинен бути більш детальним, ніж це необхідно для того, щоб команда могла успішно виконати роботу.
Практика #6: Декомпозуйте завдання з деталізацією до дрібниць. Розбиття великих завдань на кілька дрібніших допомагає точніше їх оцінити, виявити дії, які ви могли пропустити, і дає змогу детально відстежувати їхній стан. Добре працюють дюймові камінчики (невеликі етапи), які представляють завдання тривалістю від одного до трьох днів.
Практика #7: Розробіть робочі таблиці планування для спільних великих завдань. Якщо ваша команда часто виконує певні спільні завдання, розробіть контрольні списки діяльності та робочі таблиці планування для цих завдань. Ці допоміжні засоби допоможуть членам команди визначити та оцінити зусилля для кожного випадку великого завдання, яке вони вирішують.
Практика #8: Сплануйте доопрацювання після контролю якості. Більшість тестів та оглядів виявляють дефекти, або інші можливості для вдосконалення. Ваш план повинен включати доопрацювання, як окреме завдання після кожного заходу з контролю якості, а не ховати доопрацювання разом із завданням з виявлення дефектів.
Практика #9: Управління проектними ризиками. Якщо ви не ідентифікуєте та не контролюєте проектні ризики, вони контролюватимуть вас. Оцініть відносну загрозу, яку становить кожен ризик, щоб ви могли зосередити свої зусилля з управління ризиками там, де вони принесуть найбільшу користь. Щоб керувати кожним ризиком, виберіть — і відстежуйте — заходи пом’якшення, щоб зменшити ймовірність виникнення ризику або вплив, якщо він відбудеться.
Практика #10: Плануйте час для вдосконалення процесів. Щоб підняти свою команду на вищий рівень, вам доведеться інвестувати певний час у вдосконалення процесів. Не варто виділяти 100% часу членів вашої команди на проектні задачі, а потім дивуватися, чому вони не досягають прогресу в реалізації ініціатив з удосконалення.
Практика #11: Поважайте криву навчання. Визнайте, що ви можете відчути короткочасну втрату продуктивності, коли вперше спробуєте застосувати нові практики, методи, інструменти чи технології. Передбачте у своєму графіку додатковий час, щоб врахувати неминучі криві навчання, а не очікувати негайної вигоди.
Оцінка робіт
Практика #12: Оцінюйте на основі зусиль, а не календарного часу. Мені подобається спочатку оцінювати робочі години, пов’язані із завданням, а потім переводити ці зусилля в оцінку календарного часу. Я базую цей переклад на своїх записах про те, скільки ефективних годин я витрачаю на проектні завдання в день, перерви та іншу роботу, зустрічі та всі інші речі, які забирають час. Програмісти зазвичай присвячують проекту лише близько 60 відсотків свого номінального робочого часу.
Практика #13: Не плануйте для багатозадачних людей більше 80% їхнього часу. Переключення між завданнями значно знижує нашу ефективність. Надмірна багатозадачність призводить до неефективності комунікації та процесу мислення, що знижує індивідуальну продуктивність. Якщо деякі члени команди виснажуються, працюючи над надто великою кількістю завдань одночасно, встановіть чіткі пріоритети, щоб вони могли зосередитися на одній-двох цілях за раз.
Вправа #14: Запишіть оцінки і те, як ви їх отримали. Запишіть оцінки вашої роботи і те, як ви прийшли до кожної з них. Це полегшить процес захисту та коригування оцінок за необхідності. Це також допоможе вам покращити процес оцінювання. Навчіть команду методам оцінювання, таким як Wideband Delphi, замість того, щоб вважати, що всі інстинктивно вміють передбачати майбутнє.
Практика #15: Використовуйте інструменти оцінки. Базуючись на великих базах даних фактичного досвіду реалізації проектів, комерційні інструменти оцінки можуть представити спектр можливих варіантів розкладу та розподілу персоналу. Ці інструменти включають в себе кілька “факторів вартості”, які ви можете налаштувати, щоб зробити інструмент більш точним для моделювання ваших власних проектів.
Практика #16: Створіть буфери на випадок непередбачуваних обставин. Життя ніколи не йде точно за планом, тому в кінці кожного етапу розробки передбачайте резерв на випадок непередбачуваних подій та зростання вимог. Буфери на випадок непередбачуваних обставин – це не підстраховка, а радше розумне усвідомлення реалій, пов’язаних з невизначеністю.
Відстеження вашого прогресу
Практика #17: Записуйте фактичні дані та порівнюйте їх з оцінками. Якщо ви не фіксуєте фактичні зусилля і час, витрачені на кожну задачу, і не порівнюєте їх з вашими оцінками, щоб покращити майбутню оцінку, ваші оцінки назавжди залишаться припущеннями. Прагніть зрозуміти різницю між оцінками та фактичними результатами, щоб наступного разу виконати роботу краще.
Практика #18: Вважайте задачі завершеними лише тоді, коли вони виконані на 100 відсотків. Важко точно оцінити, яку частину великого завдання насправді виконано на даний момент. Однією з переваг використання дюймових камінчиків (inch-pebbles) є те, що ви можете розбити велику діяльність на кілька маленьких задач і відстежувати кожну маленьку задачу як виконану або невиконану – нічого середнього між ними.
Практика #19: Відстежуйте статус відкрито і чесно. Ви можете ефективно керувати проектом лише тоді, коли дійсно знаєте, що зроблено, а що ні, які завдання відстають від графіка і чому, а також які проблеми та питання залишаються невирішеними. Створіть культуру, в якій члени команди почуватимуться в безпеці, повідомляючи реальний статус.
Навчання для майбутнього
Практика №20: Проводьте ретроспективи. Ретроспектива – це можливість для команди поміркувати про те, як пройшов останній проект або попередня ітерація, і винести уроки для покращення своєї майбутньої роботи. Визначте, що пройшло добре, що не дуже, а також події, які вас здивували, і які є потенційними ризиками для наступного проекту.
Ці 20 практик управління проектами не гарантують успіху, але вони допоможуть вам отримати надійний контроль над проектом і переконатися, що ви робите все можливе для його успіху в непередбачуваному світі.
Оригінальна стаття – The Essential Practices for Project Management Success, переклад – Олександра Горлович, ревью – Іван Вільчавський. Оригінальні зображення від Eden Constantino з сайту Unsplash