П "ять спостережень про планування

У цій короткій статті будуть деякі міркування про загальні проблеми затримки термінів проектів. Частина з них лежить на стику між технологіями планування і технологіями розробки. Якщо ви стикалися з тим, що після середини проекту кожен крок не особливо наближає його до завершення - знайте, план був так собі. Більш конкретно під катом.

Чому потрібно шукати проблему в плані

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

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

Тепер ще далі заглибимося в конкретику.

Які бувають проблеми і що робити

Кривизна аналізу для складності синтезу

Неправильне розбиття на завдання веде до складності їх подальшого об'єднання в результат. Що означає неправильне розбиття? Це те розбиття, в якому всі зроблені завдання не утворюють кінцевий продукт, і в кінці з'являється завдання «» Інтеграція «». Її термін спрогнозувати неможливо, не знаючи проміжних деталей. Але вона є, і її треба робити.

Мораль - не варто відкладати інтеграційні ризики на кінець проектів. Якщо у вас є, наприклад, API, використовуйте відповідні інструменти для розробки - наприклад mock-сервіси (заглушки, тестові дані тощо).

Overplan => overtime

План не повинен бути складніше системи, система не зможе бути реалізована по ньому. Це випливає з того, що щоб «» зрозуміти «» (відобразити) одній системі іншу, перша повинна бути не меншою складності, а в нашому випадку - продукт повинен бути складніше плану. Інакше план не буде реалізований, тобто (якщо слідувати плану) план реалізовує не той продукт (що в ТЗ наприклад).

Мораль - критерієм достатності деталізації плану є міра розкиду його термінів. Якщо вона нижче планки допустимого, план можна брати в роботу.

R&D у плані

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

Мораль - все, наслідки чого не можна оцінити прийнятно точно - не повинно бути присутнім в плані проекту, терміни якого предмет оплати.

Оцінка не за (трьома) точками

Яка ймовірність помилитися в одній точці (даті) і яка в інтервалі (дат)? Природно, під точкою розуміють якийсь промінь (вліво), але і тоді ми маємо ймовірність з розряду «» зустріти динозавра «»: або до точки будемо, або після (ймовірність 50% - це відсутність інформації в прикладному випадку). Виходячи з цього, інтервальний термін проекту завжди точніше конкретної дати - він менш ризикований. Звичайно, інтервал ніхто не пише в договорах, там можна записати правий край для впевненості. Якби ви оцінювали все відразу по максимуму (а не середнє по трьом точкам з коефіцієнтами), то неминуче зіткнулися б з неефективністю на конкурентному ринку.

Мораль - краще зважити різні оцінки в одну, ніж вірити одній оцінці (завдання).

Білка в колесі або завдання-голови-Горинича

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

Всі ваші недовіджалися пару разів і недопідтягнулися трійку разів на тренуваннях - це мілісекунди і секунди від першого місця!

Уявіть, що кожна задача не дороблена до кінця: щоб доділити до кінця наступну залежну, вам потрібно доробити вже дві.

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

Висновок про ідеальний план

Підсумовуючи всі моралі кожної історії, ідеальний план виходить мало не суперечливим:

  1. План зростає органічно, від малого до великого, а не від частин до цілого.
  2. План повинен бути простіше того, що по ньому реалізується (інакше план нереалізуємо),
  3. У плані одного проекту (мова не про серії) не повинно бути фатальних подій,
  4. Інтервальні оцінки дають велику надійність просто за своїм визначенням,
  5. У плані не повинно бути боргів, все що використовується в подальшому, повинно бути працездатним.

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

Всім успішних проектів.

COM_SPPAGEBUILDER_NO_ITEMS_FOUND