Під час оцінки програмних проєктів вендор завжди стикається з однією і тією ж проблемою: частина майбутньої роботи лежить у зоні невідомого. Нові інтеграції, незнайомі API, архітектури, з якими команда ще не працювала — усе це створює невизначеність, яка ускладнює формування точних оцінок. Замовник очікує конкретних цифр, а розробник не має достатньо даних, щоб ці цифри обґрунтувати. У результаті виникає спокуса або завищити буфер “на всяк випадок”, або, навпаки, занизити оцінку, щоб виглядати конкурентно.
Але невизначеність — це не синонім некомпетентності. Це лише відсутність інформації. І завдання зрілої команди полягає не в тому, щоб вгадати тривалість роботи, а в тому, щоб системно заповнити інформаційні прогалини і зробити оцінку обґрунтованою.
Коли spike уже запізно
Багато інженерних практик пропонують боротися з невизначеністю через дослідницькі задачі — spike stories. Такий підхід справді працює, коли проєкт уже запущений, і команда може виділити день-два на перевірку гіпотези.
Але на етапі пресейлу, коли клієнт лише описує ідею або майбутню систему, spike перетворюється на дороговартісну інвестицію без гарантій, що контракт узагалі відбудеться.
Тому в пресейлі важливо не розробляти, а зрозуміти. Завдання цього етапу — перетворити “невідоме” на “передбачуване”, не витрачаючи тижні на дослідження.
Типи невизначеності
Якщо розкласти проблему по категоріях, стане видно, що невизначеність буває різною:
Технічна. Нова бібліотека, ERP-платформа або API без документації.
Доменна. Бізнес-логіка клієнта ще не сформована або описана лише частково.
Комунікаційна. Невідомо, хто ухвалює рішення, наскільки швидко команда замовника реагує на уточнення.
Кожен тип вимагає окремого методу зменшення ризику: технічну можна пом’якшити через аналогії з минулими проєктами, доменну — через діапазонні оцінки (“від” і “до”), а комунікаційну — через поправочні коефіцієнти, що враховують швидкість реакції клієнта.
Як оцінювати, не знаючи напевне
Зрілі команди не бояться діапазонів. Формулювання на кшталт “від 2 до 4 тижнів, залежно від уточнення API” звучить не менш професійно, ніж “3 тижні рівно”. Більше того, воно створює довіру: замовник бачить, що команда розуміє, де саме лежить невизначеність.
У деяких випадках допомагає параметрична оцінка — коли є вимірювані параметри (кількість екранів, інтеграцій, ролей користувачів), і можна використати дані з попередніх проєктів. Якщо аналогій немає, працює експертна оцінка: внутрішня група досвідчених інженерів визначає верхню та нижню межу з урахуванням факторів ризику.
Головне — не ховати невизначеність за «запасами». Прозора модель оцінки завжди краща за гарні, але порожні цифри.
Коли відсутність експертизи — не проблема
Відсутність внутрішньої експертизи більше не є критичною. Адже що таке експертиза? Це не конкретна людина з десятьма роками досвіду в SAP, а структуроване знання про систему, процес або технологію.
І якщо раніше отримати це знання можна було лише через консультантів або глибокі дослідження, то сьогодні воно доступне миттєво. Сучасні великі мовні моделі (LLM) здатні відновити контекст:
вони знають, як побудовані модулі SAP, як налаштовується Salesforce, які обмеження має NetSuite API, які кроки потрібні для інтеграції через OAuth.
Це не усуває роль інженера, але різко знижує бар’єр входу. Експертиза більше не є монополією людей, які “одного разу це робили”. Її можна відтворити на основі глобальних знань — швидко, структуровано і в межах пресейлу.
Двофазний процес замість вгадування
Традиційно оцінка виглядала так:
Отримали задачу.
Спробували оцінити за аналогією.
Додали буфер “на всяк випадок”.
Сучасний підхід інакший:
Фаза 1 — відновлення експертизи.
За допомогою LLM команда формує розуміння технології: архітектура, обмеження, типові патерни інтеграції. Це етап реконструкції знання.Фаза 2 — власне оцінка.
Після відновлення контексту можна розбити задачу на складові та оцінити їх звичними методами. Діапазон невизначеності різко зменшується — не через удачу, а через системне відновлення знань.
Такий процес не лише точніший, а й економічно доцільний: пресейл стає керованим дослідженням, а не здогадкою.
Що це дає клієнту
Оцінка базується на знанні, а не на припущеннях.
Процес прозорий: зрозумілі допущення і межі.
Вендор демонструє інженерне мислення, а не просто комерційний підхід.
Навіть у новій сфері команда швидко відновлює потрібну експертизу.
Компетентність як здатність відновлювати знання
LLM не замінює експерта — вона робить експертизу відтворюваною.
Справжня зрілість команди сьогодні вимірюється не роками досвіду, а швидкістю, з якою вона здатна відновити контекст і прийняти обґрунтоване рішення.
Тому оцінка невизначеності — це не ризик і не слабкість. Це ознака зрілої інженерної культури, здатності керувати знанням, а не вгадувати час.
Якщо ваш проєкт містить складні або невідомі компоненти, не варто чекати, поки з’явиться “той самий експерт”. Важливіше знайти партнера, який уміє перетворювати невідоме на систему. Обговорімо, як це зробити саме у вашому випадку?
Comments are closed