OnAgile Learning Hub 💎

Продолжая тему с оценками, давайте посмотрим, в чем вообще проблема с ними. Почему в общем случае крайне сложно дать точную оценку?

(Применимо к оценке работ так называемого умственного труда, knowledge work).

1. В вариативной среде, которой свойственная большая неопределенность (например, создание нового продукта), при этом работая командой в несколько человек, физически невозможно заранее предугадать все факторы, которые возникнут в процессе работы и повлияют на ее длительность.

2. Требования, которые у нас есть на старте - не описывают будущий продукт на 100%, какими бы объемными и детальными они ни были. В отличие от, например, изготовления детали по чертежу или строительство дома по готовой проектной документации.

3. И самое главное - проблема в ДНК процесса оценки.
Когда нас просят что-то оценить, нам говорят буквально следующее «На основе информации, которая есть у вас сейчас и вашего опыта, когда, как вам кажется, вы могли бы это сделать?».
Мы говорим (применяя любую методику оценки), например, через 20 дней, или к 17 ноября. И это тот оценочный срок, который нас попросили назвать.

Но в ту же секунду, те кто нас спрашивает о сроках (заказчики), воспринимают его как дедлайн, под который мы только что сами подписались. Отсюда и возникают недоверие и напряженность в отношениях между заказчиками и командой. И, конечно, сорванные сроки.

Поэтому нужно искать кардинально иные способы прогнозирования сроков поставки результата.

Дальше будут еще два способа, как можно договариваться с заказчиками, не прибегая к привычной экспертной оценке.

И у меня вопрос - а как вы решаете проблему со сроками в своих командах? Напишите, пожалуйста, в комментариях.

www.tgoop.com/agilethinking/175

2.73K viewsDmitry Lobasev, edited  Jul 30, 2020 at 21:08

Продолжая тему с оценками, давайте посмотрим, в чем вообще проблема с ними. Почему в общем случае крайне сложно дать точную оценку?

(Применимо к оценке работ так называемого умственного труда, knowledge work).

1. В вариативной среде, которой свойственная большая неопределенность (например, создание нового продукта), при этом работая командой в несколько человек, физически невозможно заранее предугадать все факторы, которые возникнут в процессе работы и повлияют на ее длительность.

2. Требования, которые у нас есть на старте - не описывают будущий продукт на 100%, какими бы объемными и детальными они ни были. В отличие от, например, изготовления детали по чертежу или строительство дома по готовой проектной документации.

3. И самое главное - проблема в ДНК процесса оценки.
Когда нас просят что-то оценить, нам говорят буквально следующее «На основе информации, которая есть у вас сейчас и вашего опыта, когда, как вам кажется, вы могли бы это сделать?».
Мы говорим (применяя любую методику оценки), например, через 20 дней, или к 17 ноября. И это тот оценочный срок, который нас попросили назвать.

Но в ту же секунду, те кто нас спрашивает о сроках (заказчики), воспринимают его как дедлайн, под который мы только что сами подписались. Отсюда и возникают недоверие и напряженность в отношениях между заказчиками и командой. И, конечно, сорванные сроки.

Поэтому нужно искать кардинально иные способы прогнозирования сроков поставки результата.

Дальше будут еще два способа, как можно договариваться с заказчиками, не прибегая к привычной экспертной оценке.

И у меня вопрос - а как вы решаете проблему со сроками в своих командах? Напишите, пожалуйста, в комментариях.

BY OnAgile Learning Hub 💎