Під час оцінки програмних проєктів вендор завжди стикається з однією і тією ж проблемою: частина майбутньої роботи лежить у зоні невідомого. Нові інтеграції, незнайомі API, архітектури, з якими команда ще не працювала — усе це створює невизначеність, яка ускладнює формування точних оцінок. Замовник очікує конкретних цифр, а розробник не має достатньо даних, щоб ці цифри обґрунтувати. У результаті виникає спокуса або завищити буфер “на всяк випадок”, або, навпаки, занизити оцінку, щоб виглядати конкурентно.
Але невизначеність — це не синонім некомпетентності. Це лише відсутність інформації. І завдання зрілої команди полягає не в тому, щоб вгадати тривалість роботи, а в тому, щоб системно заповнити інформаційні прогалини і зробити оцінку обґрунтованою.
Коли spike уже запізно
Багато інженерних практик пропонують боротися з невизначеністю через дослідницькі задачі — spike stories. Такий підхід справді працює, коли проєкт уже запущений, і команда може виділити день-два на перевірку гіпотези.
Але на етапі пресейлу, коли клієнт лише описує