Comments 9
Я тогда и представить не могла, как можно оценить то, что не сделано и непонятно, как будет реализовано...
Простите, но вы и сейчас не представляете.
Для заказчика (это тот, кто деньги платит за работу над его продуктом), фактически, нет разницы 65% вероятность уложиться в прогноз по сроку или 75%: у него есть некий бюджет, и в этот бюджет он хочет уложиться. Денег на правый хвост распределения вероятности он не даст.
Разработчик не знает (как бы сам ни был уверен) сколько времени займет задача, менеджер не знает (сколько бы ни пытался высчитывать вероятности), никто не знает.
Игры в оценку сроков - это спектакль для заказчика, и только с этой точки зрения их имеет смысл рассматривать.
Если для этого спектакля вам требуются матрицы - ок, статистика на исторических данных (прошлый crud писали 4 дня, значит этот будут писать 4дня+-некий запас) - ок, если заверение разработчика (да тут на пару часов работы, тыщу раз так делал!) - ок, если гороскопы/гадание/назватьотбалды - тоже ок. В конечном счете это не имеет никакого отношения к реальному сроку выполнения.
Напрашивается вопрос: не отказаться ли тогда вообще от оценки сроков? И что говорить заказчику? "Когда будет готов продукт?" - "А хз" - получается вот так, зато честно?
А вопрос "Ну когда?" один из самых, если не самый частый.
Если откажетесь называть срок, вполне справедливо объясняя это тем, что не знаете будущего, то с вами не будут иметь дело, и уйдут к тем, кто врет, утверждая что знает будущее.
Из этого следует, что разумное поведение – устраивать такой спектакль (с матрицами, табличками, расчетами, или просто харизматичным менеджером), который убедит иметь с вами дело, и минимизировать материальные/репутационные/прочие риски/издержки для себя и заказчика.
Так и живем.
Работаю над проектом в лучших традициях методологий: матрицы оценок, груминг, стендапы, etc. Все больше убеждаюсь, что все это не более чем формальность. Есть четкий функционал, который надо сделать к концу года, согласованный с клиентом. Есть некий план задач, что нужно сделать для этого. И внутри этого периода всегда есть пространство для маневра: разные неожиданности, сложности, сделать хорошо или быстро... Поэтому дробить каждую из задач дальше не имеет смысла: сразу теряется гибкость к адаптации, затрудняются изменения, а народ теряет из виду цели работы и фокусируется на тикетах, которые со временем имеют свойство растягиваться.
А Вы разницу между словами "оценить" и "точно посчитать" ощущаете?
В Вашей логике даже самые простые действия реализовать нельзя. Например, нельзя точно оценить, сколько времени займёт поход в магазин за хлебом: ведь по пути можно встреть знакомых и поболтать, упасть и сломать ногу, попасть под автобус, наконец, вдруг может прилететь астероид и уничтожить человечество. Все эти события вполне вероятны.
Неплохо бы упомянуть старую классику:
метод pert: https://ru.wikipedia.org/wiki/PERT. Он как бы и предназначен для сложных нерутинных проектов.
Также можно упомянуть "новую классику":
покер планирования: https://ru.wikipedia.org/wiki/Покер_планирования
По поводу "груминга": есть ли оценка доп-нагрузки на всех, когда они слушают/оценивают в общем-то чужие задачи?
Аналитика и декомпозиция задач. Как определяется время разработки