Для чего нужна оценка?

На днях я раздумывала об оценке. После фиаско сайта healthcare.gov и всех игр с планированием (многие из которых связаны с проблемами оценки), я задумалась, зачем мы выполняем оценку? (Повествование от лица Джоанны Ротман, автора оригинальной статьи)

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

Именно поэтому в посте об оценке я предложила использовать гибкие подходы. Вы можете разбивать процесс на итерации. Вы получаете больше информации и оцениваете небольшие порции. Так у вас больше шансов получить более или менее точную оценку.

ПО - не стройка, а обучение

Существует одна проблема с оценкой. ПО - не стройка. Мы не можем создавать ПО так же, как мы сооружаем здание или изготавливаем какой-нибудь продукт. Суть ПО заключается в командном обучении. Можно установить временные интервалы. Принять решение прекратить работу над конкретной задачей. Или утвердить критерий приемки/готовности выпуска и заявить “На данном этапе мы сделали достаточно”. 

Но нельзя сказать “Мы можем разработать это ПО за $Х за квадратный метр”. Мы прежде не создавали аналогичное ПО, поэтому не знаем, как оценивать. Иначе мы бы могли выполнить вполне точную оценку, поскольку у нас были бы данные предыдущих качественных оценок или небольшие фрагменты известных нам задач. 

Когда мы проводим оценку, остальные воспринимают ее так же, как и мы воспринимаем оценку в других сферах - особенно, в строительстве.

Мы оцениваем по следующим причинам:
Чтобы обеспечить информацию о размере/стоимости/дате завершения проекта по порядку величины, необходимую для планирования. Порядок величины означает, что мы хотим выделить достаточно времени для оценки - в точности которой мы уверенны - для облегчения планирования.

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

Существует альтернатива оценке

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

Если у вас всегда есть работающий продукт - тесты, документация и все необходимое - оценку проводить не нужно. Кроме того, вы получаете отличную возможность для обучения - если возникнет вопрос “Насколько трудна задача Х?”, вся команда собирается для обсуждения и объясняет “нужно выполнить историю №1, №2, ну и еще №3”
Затем добавляет “Мы полагаем, что нужны, по крайней мере, эти три истории. Являются ли они более важными, чем верхние истории из очереди?”.

Что делать?

Я не провожу оценку. Я выполняю работу по порциям, которые занимают от 5 минут до часа. Как правило, на мои задания уходит менее часа. Благодаря такому “порционному” подходу, в  этом году я вдвое увеличила свою производительность.

Я закончила одну книгу, а вторая находится в бета-версии. Много книг еще в процессе написания. Я, как и раньше, провожу семинары и тренинги, пишу посты. Отредактировала большое количество статей на agileconnection.com. Почему я столько успеваю?

Потому что задачи у меня маленькие. Поэтому мне не нужна оценка, я не трачу на нее время. Я работаю “потоково”. Я определяю приоритетность задач и занимаюсь самыми важным.

Зачем выполнять оценку?

Для чего нужна оценка? Задумайтесь. Вы проводили оценку, потому что были вынуждены? Или потому, что заказчики хотели раз в год выделять бюджет. Все это выдумки. Можно прекрасно обойтись без детальной оценки проекта.

Что касается выделения бюджета, определите для себя ценность проекта. Когда он должен предоставить ценность? И сообщите о сроках команде разработчиков. Все.

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

Подарите своему руководству книгу “Manage It! Your Guide to Modern, Pragmatic Project Management”, которая объясняет, как руководить проектами в любом жизненном цикле. Предоставьте им упорядоченный бэклог. Пусть поставляют продукт. Если они не вписываются в сроки или бюджет, они об этом сообщат. Они ведь ответственные люди.

Если вам нужна оценка порядка величины, хорошо. Для нее не потребуется несколько дней. Всего несколько часов. Не настаивайте, чтобы люди придерживались такой оценки. (Определение “оценки”? - “Догадка”. Я не шучу).

Если вы хотите знать, когда закончите проект, поскольку считаете, что уже приблизились к его завершению, задайте себе вопрос “Стоит ли жертвовать временем на завершение проекта ради оценки?”

Если хотите поучаствовать в поисках виноватого, помните, что руководство обязано принимать большую часть вины на себя. Почему? Потому что они устанавливают ограничения. Не верите? Прочтите пост об оценке.

Я понимаю потребность руководства в оценке. Мне нравятся оценки порядка величины по многим причинам. Но создание ПО отличается от путешествия в определенном направлении или постройки здания. Когда я куда-нибудь направляюсь, мне действительно нужны пошаговые инструкции. Чтобы построить здание, мне на самом деле необходима оценка. Но даже в таком случае я почти уверена, что она будет оптимистической. 

В процессе разработки ПО я хочу видеть рабочий продукт, ведь таким образом мы учимся. Обучение - вот что самое главное. А не оценка.

Источник