View source for PO - 08 - Оценка

= Цель = 

Понять роль ПО в оценке BI 

= Тезисы = 

== Оценка в общем, DoD & WBS ==

Причины почему реальность не совпадает с оценками? 

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

Первые два в принципе покрываются отвественностью ПО за постановку целей, за оценку и оптимизиацию value, за организацию и проведение refinement. 

На интересует третье:

Аксиома: команда отвественна за выдачу оценок (estimation), и PO не может и не должен навязывать свою оценку. 

Однако означает ли это что PO совсем не должно заботить насколько качественная оценка? Конечно же нет. 

1) PO в том числе отвечает что бы у команды был definition of done который бы устраивал пользователей, стейкхолдеров и споносоров. 

2) PO в праве требовать чтобы оценка учитывала DoD. 

Полезно составить DoD куда бы вошли все важные этапы: анализ, архитектура, дизайн технический, дизайн UI и UX, учет имеющейся codebase, собственно разработка, тестовое покрытие, поиск и отслеживание рисков, документация техническая, документация пользовательская, тестирование через реалистичные сценарии, интеграция, выпуск, мониторинг и поддержка на продакшн

ВАЖНО #1: При этом НЕ делать работу за них. Даже если знаем - намного лучше не дать им готовый ответ "вам нужно тестирование", а задать вопрос "а запланировали ли мы время, на то, чтобы убедиться что код работает". И не только потому что мы типа надругаемся над их автономностью, а потому что сделаем за них раз - сядут и ножки свесят, и еще отвественность на нас переложат. 

ВАЖНО #2: НЕ НАДО бояться требовать от команды соотвествия DoD. То что они "не могут" - это их проблема, должны подтягивать свой уровень. Одна из причин по которой у команд бывает "корона на голове" - как раз потому что PO не достаточно требовательны в соблюдении DoD. 

А когда всё равно нельзя оценить? 

Бывает такое, на то у нас и эмпирический процесс. 

Что важно помнить:

1) Буфер - это предосудительная практика. Показатель непрофессионализма. 

Правильно:
- Отражать уверенность в оценке давая её в диапазоне. Чем выше уверенность - тем уже диапазон. Cone of uncertainty.

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

2) Основная часть по подготовке к оценке должна проводиться на refinement! Если надо - следует создавать architecture spike and business spike

3) Методики типа PERT ( (optimistic + 4 * average + pessimistic) / 6 )

Пример подхода с неясными требованиями:

1) Выявить MVP ("без этих функций всё равно никому не надо") и оценить его.

2) Получить "другую" сторону оценки

Пример варианта. Выявить оптимальный (например "как у всех") и/или максимальный ("больше не о чем мечтать") варианты и оценить их тоже, получив cone of uncertainty.

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

ВАЖНО: Прирост точности оценки НЕ ЛИНЕЙНО зависит от вложенных усилий. Если сначала дополнительные усилия значительно уточняют оценку (e.g. потратить всего пять минут или потратить целый час вполне себе даст оценку точнее в 10 раз), то с какого момента дополнительные усилия не дадут (e.g. потратить одну неделю или две - не даст в два раза более точной оцеки). 

Граница - в тот момент когда у мы полностью ушли от цифр "от фонаря" и получили какие-то обоснованные оценки, например на основе:

* Построения плана работ/WBS
* Сравнения с решениями сделаными раньше
* Сравнения с чужим опытом
* Проведения эксперимента 
* Использования практических стандартов и нормативов

== Быстрые методы оценки в Agile ==

Традиционно в Agile методы оценки не включают в себя построение WBS, более того это считается анти-Agile практикой, потому что содержит в себе предсказательный элемент. 

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

Примерами Agile методов оценки могут быть Planning Pocker и White Elephant. 

Planning pocker - метод коллективной оценки, при котором команде даются PBI для оцеки, и команда оценивает каждый отдельно. 

При оценке PBI команда использует набор карточек с условной сложностью (например в идеальных командо-днях или в story points), причем карточки обычно делают на основе чисел фибоначи (1/2, 1, 2, 3, 5, 8, 13, 21...). Цифры не круглые и не регулярные умышленно, чтобы не создавалось иллюзии что это точная оценка и чтобы отразить что чем больше задача, тем меньше точность. Все члены команды имеют свою "колоду" и одновременно выкладывают карту, которая соотвествует сложности обсуждаемой PBI. Если оценки совпали - ок, если расходятся - то просят обосновать своё решение тех, кто выкинул минимальную и максимальные оценки. Делается это потому что нам не важно почему команда пришла к консенсусу - оценка это их внутрнее дело и их accountability. Важно чтобы ничего не упустили. Если больше 3-5 rounds не могут придти к согласию - карточка снимается с голосования от правляется на доработку. 

White elephant это более быстрая версия покера. Для работы нужна доска, на которой рисуется таблица, включающая с колонками соотвествующими карточкам покера (1/2, 1, 2, 3, 5, 8, 13...) и дополнительными колонками "too big" и "unknown". Люди по очереди могут или взять новый PBI и поместить его в колонку или передвинуть уже расположенный кем-то другим PBI, кратко объяснив почему. Если карточку не двигают - значит по ней есть консенсус. Если двигают больше чем установленный лимит (например 3-5 раз) - значит карточка сниматеся с голосования. 

С точки зрения ПО важные моменты:

* при внесении карточки важно убедиться что команда понимает приносимое value и как это value поддерживает цели проекта.

* при оценке можно сразу следить за тем, что усилия по карточке соотвествуют её ценности. нет никакого резона делать PBI который обойдется дороже чем принесет пользы

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

Обратите внимание что оба метода ограничивают время на споры по items, по которым не удается найти консенсуса и предлагают использовать другой, более аналитичный/точный метод оценки в этом случае. Это важная "фича" и если её упустить - то методы превращаются или в пустую трату времени, или в называние цифры от фонаря, лишь бы все это закончить. 

== Особый случай - жесткая минимизация WIP ==

Частный случай аналитического подхода - это применение lean принципа жесткой минимизации WIP - задачи должны быть настолько маленькими, чтобы бы завершаться в один день. Это дает два преимущества:

* настолько простые задачи легко оценить интуитивно даже при некотором недостатке знания и опыта

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

Работа ведется в виде planning pocker (см выше), но всего с тремя карточками 1, NFC (no f.. clue, не знаю), TFB (too f... big, слишком много). Карточки NFC и TFB отправляются для дальнейшего refinement, пока они не станут "1". 

== Риски == 

Риск это событие которое '''может''' наступить и повлиять на наш план. Если событие наступит точно - то это '''issue''', а не риск. 

Если событие наступит '''скорее всего''' - то это не риск, а небрежное планирование в стиле "у меня есть план купить машину, но есть риск что я не выиграю в лотерею". 

По рискам мы:

* Оцениваем вероятность возникновения. Еще раз вероятность '''скорее всего наступит''' - это ТОЧНО не риск. 
* Оцениваем степень влияния. 
* Формулируем критерии как мы сможем обнаружить наступление риска.
* Назначаем отвественного за обнаружение и разрешения риска.
* Планируем наши действия в случае наступления риска.

Пример риска: Сотрудник может заболеть. 

Степень влияния: Работа заложенная на сотрудника не будет сделано. Если команда из двух человек - то это может удлинить сроки вдвое. 

Как узнаем: Сотрудник не пришел на работу по причине болезни (это если в управлении мудаки сидят)

А на самом деле, если вдумчиво, на вскидку:

* Есть сезоны когда риск заболевания повышается
* Есть факторы такие как хронические болезни, рискованное поведение (курящий или бухащий менее надежен)
* Есть поведение способствующее заболеванием (спортсмен может сломать ногу, заядлый болельщик часто ходит в места скопления народа) 

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

* Avoid: Риск можно устранить. Например в сезон гриппа можно организовать вакцинацию. А в случае хронических болезней - хорошо помогает диспанцеризация. 
* Mitigate: Можно устранить последствия риска. Например можно быть готовым подключить замену. 
* Transfer: Можно делегировать риск. Например сделав так что в этом случае рискует заказчик, а не мы. Ну или что пострадает заболевший. В случае заболевания это конечно выглядит не красиво, но скажем если мы рассмотрим ситацию при которой человек потеряет работу потому что заказчики начали просить то, что он не утрудил себя изучением - вполне себе вариант. 
* Accept: Можно принять риск. Например заложив в стоимость бюджет на покрытие штрафов от болезней.  

= Ну так если вообще не можем оценить. Не знаем, не понятно что оценивать = 

== Эмпирический процесс и колонны скрам == 

А значит имеем дело со сложной системой. И скрам четко говорит нам что:

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

б) Надо принять accountability и проявить смелость предложив способ решения, например:

* Вовлекая заказчика в процесс (см. принцип Agile - разработчики и бизнес '''совместно''' работают над решением) и совместно формулируя гипотезы для оценки

* Выдвигая обоснованные гипотезы и планируя короткие эксперименты по их проверке (inspection, fail fast!) и сразу закладывая что гипотеза может оказаться неверной, и делая прозрачным как мы об этом узнаем и что мы будем делать (adaptation!) 

== И снова Inverted Iron Triangle == 

И этот подход требует смены способа мышления. Примеры хорошо показывают что чаще всего люди строят минимальный план выполнение которого они уверены приведет к успеху и начинают искать время и ресурсы на его достижение. Это подход водопада. 

Подход agile прямо противоположный. Мы принимаем жесткое ограничение по времени и ресурсам, и выбираем как наилучшим образом мы можем сделать что-то полезное в этих рамках. Мы не ищем идеального решения. Мы предлагаем лучшее возможное решение в преложенных ограничениях!!! 

Неправильный вопрос себе: "Сколько ресурсов/времени мне нужно?". "Сделали ли мы все что нужно?". 

Правильный вопрос себе: "Сделал ли я то, то что доставит максимум возможного в отведенные рамки?". "Является ли это самым важным что надо получить?". "Если я не уверен точно - что именно и как именно я буду измерять что бы узнать что я не прав". "Что я буду делать если узнаю что выбранный вариант не доставляет ценности"? "Как быстро я об этом узнаю?". 

[[Category:Product Owner (курс)]]