Чому проєкти з розробки ПЗ виходять за початкові терміни
Строки зсуваються не через погану команду, а через незаписаний обсяг, невідому поведінку чужого API та 'маленькі' доповнення посеред спринту.
BILPP
Кожен, хто вже замовляв кастомний софт, чув на старті фразу на кшталт “приблизно вісім тижнів”. А потім, по факту, тижнів виявляється дванадцять чи чотирнадцять. Реакція буває однакова: “команда неправильно порахувала”. Іноді так і є. Але частіше причина не в арифметиці, а в тому, що на момент оцінки просто не існувало інформації, яка з’явилася тільки під час роботи. Нижче — чотири джерела цього зсуву і що з кожним із них реально можна зробити до того, як воно стане проблемою.
Обсяг, якого ніхто не записав
Найчастіша причина зсуву термінів — не помилка в оцінці, а те, що оцінювали різні речі. Замовник мав на увазі “особистий кабінет з історією замовлень і сповіщеннями”, команда почула “особистий кабінет” і уявила форму входу та список замовлень. Обидва боки узгодили термін для різних проєктів, а виявилось це тільки під час роботи.
Виправляється це не кращою оцінкою, а письмовою фіксацією обсягу до старту: які екрани, які ролі, що явно не входить у цю фазу. Без такого документа “оцінка” — це число, прив’язане до уявлення, яке існує тільки в голові однієї людини.
Інтеграції: поведінка чужого API стає відомою тільки тоді, коли хтось у неї подивився
Найнебезпечніша частина оцінки — не власний код, а системи, з якими він має розмовляти. ERP, платіжний провайдер, бухгалтерський сервіс, стороння CRM — кожна з них може мати документований, стабільний API, а може мати ендпоінт, який технічно існує, але востаннє оновлювався кілька років тому і поводиться не так, як написано в документації, а може не мати API взагалі.
Різниця між цими трьома сценаріями — це різниця в тижнях, а не в днях, і дізнатися, який саме сценарій ваш, можна тільки одним способом: хтось має відкрити цю систему і спробувати реальний запит. Оцінка, зроблена до цього кроку, — це оцінка з відкритим питанням усередині, навіть якщо цифра в комерційній пропозиції виглядає остаточною.
“Одне маленьке доповнення” рідко лишається маленьким
Посеред спринту з’являється прохання: “а можна ще одну кнопку — експорт у Excel”. Саме по собі воно й справді маленьке. Проблема в тому, що за три місяці таких прохань накопичується півтора десятка, і кожне з них поодинці виглядало непомітним, а разом вони — окрема фаза роботи, якої не було в початковому обсязі.
Це не привід відмовляти в змінах — бізнес-потреби справді змінюються під час проєкту. Це привід називати їх тим, чим вони є: новим обсягом, який або йде в окрему ітерацію з окремим терміном, або свідомо витісняє щось інше з поточної фази. Мовчазне “звісно, додамо” без цього рішення — і є механізм, яким тримісячний проєкт стає п’ятимісячним.
Чому короткі ітерації ловлять помилку на другому тижні, а не на десятому
Якщо команда показує робочий, клікабельний результат кожні два-три тижні, неправильне припущення видно одразу: замовник дивиться на екран і каже “ні, менеджер не повинен бачити закупівельну ціну” на другому тижні. Виправити це — робота на день.
Той самий проєкт, зібраний за моделлю “одна велика доставка через чотири місяці”, ховає ту саму помилку до самого кінця. Виправлення на дванадцятому тижні означає переробку шарів, які вже побудовані поверх неправильного припущення, — а це вже не день, а нова фаза.
Частину ризику прибрати не можна — і це варто визнати чесно
Є спокуса пообіцяти, що discovery і короткі ітерації прибирають зсув термінів повністю. Це неправда, і обіцянка такого штибу довіри не додає. Якщо стороння система не має документованого API, а команда, яка нею володіє, відповідає на технічні питання через тиждень, — це затримка, яку неможливо було передбачити на етапі оцінки, бо інформація фізично не існувала раніше.
Різниця не в тому, чи трапляється такий ризик, а в тому, що з ним роблять: виявляють його на другому тижні через реальний тестовий запит чи через два місяці мовчання. Перше — нормальна частина проєкту. Друге — ознака процесу, який не перевіряє припущення, поки вони не стали проблемою.
Що з цього виходить на практиці
| Джерело зсуву | Коли зазвичай проявляється | Що знижує ризик |
|---|---|---|
| Незаписаний обсяг | На старті, непомітно | Письмова фіксація обсягу до роботи |
| Невідома поведінка чужого API | Під час першої спроби інтеграції | Ранній технічний тест, а не оцінка “на око” |
| Накопичені “маленькі” доповнення | Всередині спринтів | Явне рішення: нова ітерація чи заміна іншої задачі |
| Пізнє виявлення помилки | В кінці довгої фази без релізів | Робочий продукт кожні 2-3 тижні |
Ми будуємо роботу саме навколо короткого циклу зворотного зв’язку — не тому, що це усуває будь-який ризик, а тому, що воно переносить момент, коли помилка стає видимою, з кінця проєкту на другий-третій тиждень, коли її ціна ще низька. Це стосується як власних продуктів, наприклад Estegre, так і проєктів на замовлення в межах індивідуальної розробки.
Про те, як заздалегідь відрізнити партнера, що дійсно так працює, від того, хто лише каже про це на дзвінку, — у сусідньому матеріалі: як обрати партнера з розробки програмного забезпечення.
Термін, названий до того, як хтось подивився в чужий API, — це не термін. Це місце, куди пізніше впишеться затримка.
Якщо у вас уже є розуміння систем, з якими новий продукт має інтегруватися, — це саме та розмова, яка варта короткого дзвінка, а не ще одного раунду оцінок наосліп.