Revision as of 18:10, 18 February 2021

Цель

Понять роль ПО в оценке 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
• Сравнения с решениями сделаными раньше
• Сравнения с чужим опытом
• Проведения эксперимента
• Использования практических стандартов и нормативов

Риски

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

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

По рискам мы:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

И снова Inverted Iron Triangle

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

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

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

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