Ещё раз. Степень неопределенности очень сильно мешает давать точные и

Question

Ещё раз. Степень неопределенности очень сильно мешает давать точные и

правильные эстимейты.
Чем она выше - тем больше шансов, что твои эстимейты - фигня.

Поэтому в большинстве случаев люди стараются сначала взять время на ресерч/детализацию/дизайн етк, что бы минимизировать степень неопределенности, а потом взять время на имплементацию.

Но, даже в ситуациях когда этого сделать по каким-то причинам невозможно.
Есть два кейса.
Первый - есть эстимейт "на это нужно два месяца".
Второй - нет эстимейта совсем.

В первом случае при любом отклонении от плановой работы (появилась новая информация, изменились требования, обновились зависимости, риски выстрелили, что угодно) команда смотрит на новую информацию и задается вопросом "исходя из вот этой новой инфы - старый эстимейт ещё актуален, или нужно его обновлять?".
Если нужно его обновлять - команда идёт с этим к бизнесу (или лицу принимающему решения) и говорит: приключилось вот такое и такое говно, нам нужно ещё столько-то времени что бы это исправить.

И тут лицо, принимающее решение, садится и думает, что для него сейчас лучше - сдвинуть дедлайн, сделать featurecut, делегировать часть работы другим исполнителям, или ещё чего.
И действует исходя из того, как сейчас полезнее бизнесу.

Во втором случае, в принципе непонятно, когда и что будет сделано.
Потому что нету эстимейтов. Ну, окей, возьмём в пример приведенное вами "вот вам два месяца, что сделаете то сделаете".
В итоге те самые возникшие риски, новые требования, проблемы зависимостей и прочее-прочее доходит до бизнеса не сразу, как только стало о них известно, а через два месяца, когда предпринимать уже что-то бессмысленно.
Потому что не сделали.

#programming #qa #russian #software

0

02.05.2021

1 ответов

22 просмотра

Roman (rpwheeler) · Accepted Answer

Я тут выступлю от противного, как "убийца эстимейтов", Грубо упрощая, до того как я беру задачу в тестирование, я не знаю насколько программисты нафакапили, или насколько идея фичи вообще реализуема. Через какое-то время тестирования я могу сказать: — ок, это релизится. — всё плохо, критические проблемы — время на фичу удваивается. — это вообще никуда не годится, так дело не пойдёт, фичу надо делать другим путём, а не так как вы сначала придумали. Ну и это не только я могу сказать, магии в этом нет. Если вам эстимейт "спринт" так же хорош как "два спринта", лишь бы не "три спринта" — окей. Но "убивать" фичу которая была в разработке два спринта до "нужно всё по новой" тоже доводилось. А бывало и такое что мы вообще не были уверены что исходная задумка продукта пройдёт. Через пять месяцев разработки он во что-то упирался (вот в ту память, например, и ещё в производительность хуже того что было), и замораживался, уходя в неизвестность. Хотелки бизнеса вполне могут быть нереализуемы, но приступая к ковыряниям мы не всегда можем сразу это сказать.

207 похожих чатов

Ещё раз. Степень неопределенности очень сильно мешает давать точные и

1 ответов

Похожие вопросы