Оценка — это не обещание. Одно из самых раздражающих недоразумений в IT — считать программную оценку твёрдым обязательством.
Знакомо всем. Вас бросают в легаси-кодовую базу, которую кто-то собирал полгода. Календарь забит регулярными встречами, параллельно нужно выпустить минорный релиз по другому проекту, а люди постоянно заходят с «один быстрый вопрос». Потом кто-то спрашивает: «Когда фича будет готова?»
Честный ответ: «Понятия не имею». Особенно если работа идёт с внешними API, без документации, и весь контекст живёт в голове одного сеньора.
Но так сказать нельзя. Поэтому вместо того, чтобы назвать случайную дату и порадовать менеджмент, относитесь к оценкам так, как они устроены: это гипотезы, а не обещания.
Реалистичный ответ звучит примерно так: «Целимся на пятницу. Это при условии, что объём не меняется, ключи от API я получаю сегодня и меня не затягивает тушение пожаров. Если приоритеты сдвинутся, сдвинется и дата».
Это не упрямство и не капризы. Так просто устроена реальность.
Неопределённость максимальна в первый день, и «подумать ещё немного» её не убирает. Инженер никому не должен идеальное предсказание. Но команде он должен сделать неопределённость видимой.
Математика простая: - больше объёма — новая дата; - больше встреч — меньше времени на фокус; - нет передачи дел — сначала нужна фаза исследования.
Оценки нужны не для гарантии идеального графика. Они нужны, чтобы управлять реальностью, а не надеяться, что всё само сложится.