Один из часто задаваемых на тренинге вопросов — «как оценить, сколько времени уйдет на выполнение задачи Х?». Вопрос беспокоит не только бизнес-аналитиков, но и коллег на других позициях. Больше всего он актуален для менеджеров проектов. Я же хочу поделиться своим опытом и рассказать о некоторых техниках, которые довелось использовать при оценке трудоемкости задач по бизнес-анализу.
Зачем нужна оценка
Для начала — несколько общих фраз об оценке трудоемкости. Почему бизнес-аналитики, разработчики, тестировщики и другие роли не любят озвучивать оценку по задачам? Причина проста — оценка воспринимается как обязательство или, как еще любят говорить в аутсорсинговой среде, “commitment”. Очень часто фраза «на эту задачу требуется пять–семь дней» воспринимается руководителем как «через пять дней будет готово». А кто хочет брать на себя риски — проще попытаться уйти от ответа. Оценка по определению неточная, это прогноз, построенный на основе имеющейся информации.
Как повысить точность своих оценок? Для начала нужно начать их давать, отслеживать точность, проводить анализ причин отклонения. Чем больше мы оцениваем, тем выше точность (если мы относимся к этому процессу осознанно и делаем выводы).
Худшая оценка — ее отсутствие (с точки зрения того, кому она нужна как входная информация для планирования). Давая оценку, мы снижаем неопределенность. Даже если оценка грубая, это лучше, чем ничего.
Методы оценки
Перейдем от общих слов к практике.
Первый метод оценки — оценка по аналогии. На вопрос «сколько времени займет написание требований к подсистеме Х» вы можете закатить глаза и вспомнить, сколько времени ушло в прошлый раз на похожую задачу. Это самый грубый метод оценки. Ее точность повышается, если вы работаете с похожими проектами в неизменном контексте (методология, перечень заинтересованных лиц, команда разработки, инструменты для управления требованиями).
Повысить точность оценки по аналогии крупной задачи можно путем декомпозиции ее на более мелкие и оценки уже их. К такому методу можно прибегать, когда вашему руководителю оценка задачи кажется завышенной. Разбейте задачу на подзадачи, оцените каждую, и вы либо сможете убедить руководителя в правильности исходной оценки, либо сами увидите несоответствие прогнозу. Чем больше задача, чем больше неизвестных факторов, тем сложнее оценить, поэтому едим слона по кускам. Например, сколько времени займет подготовка документа «Видение»? Ответить сложно. Разобьем документ на разделы, для каждого разделе определим пул работ, и вот на выходе у вас и план работ, и общая оценка.
Следующий метод — параметрическая оценка. Например, вам нужно написать SRS (Software Requirement Specification), содержащий 20 юзкейсов. По вашему опыту (привет метод оценки по аналогии), написание одного юзкейса занимает в среднем полтора дня. Путем несложных расчетов получаем, что все юзкейсы вы напишите через 30 рабочих дней. В данном случае в роли параметра выступает трудоемкость написания одного юзкейса. Таким параметром может быть количество экранных форм, бизнес-процессов, которые вам нужно описать, количество сущностей при составлении словаря данных и т. д.
Третий метод — оценка по трем точкам, он же Pert. Мы определяем оптимистическую, пессимистическую и реалистическую оценки (по любому из вышеперечисленных методов) и применяем магическую формулу:
Оценка = (оптимистическая + пессимистическая + (4 х реалистическая))/6.
Вместо «4» вы можете подставить любой другой коэффициент, не забывая синхронно изменять значение в знаменателе.
Экспертная оценка используется, если вы делегируете право определить оценку человеку, который это сделает лучше вас или вместе с вами. Но что делать, если экспертов несколько? Тут на помощь нам приходить метод Дельфи. Предположим у нас есть список задач и группа экспертов, которым поручено оценить трудоемкость. Эксперты независимо друг от друга оценивают задачи, их оценки анализируются: если все эксперты дали одинаковый или незначительно отличающиеся оценки, мы получили согласованный результат. В противном случае, эксперты получают информацию, какие есть альтернативные мнения и могут обосновать свою точку зрения. После этого проводиться очередной раунд независимой оценки. Те, кто работают по Scrum скажут: «Да ведь это же planning poker!» Да, planning poker в Scrum — реализация метода Дельфи. По этому методу можно организовывать работы экспертов по любым вопросам, не только для оценки трудоемкости.
Пример использования метода Дельфи и декомпозиции. В моей команде количество бизнес-аналитиков варьировалось от 3-х до 6-ти. Основным объектом оценки были юзер стори. Работу с каждой мы разделяли на три активности: выявление, специфицирование, обсуждение + согласование. До сессии группового планирования БА-задач мы независимо оценивали трудоемкость по каждой истории, которую нам предстояло описать. Во время сессии сравнивали полученные оценки. Если они значительно расходились, обсуждали оценки каждой составляющей, проясняли причину расхождения и проводили переголосование. Если для кого-то задача была проще в силу наличия экспертизы в вопросе, то он/она получала эту юзер стори и принималась его/ее оценка трудоемкости (мягкая реализация принципа «если готов сделать за такое время, возьми и сделай :).
Следующий метод — метод набегающей волны (Rolling Wave). Интуитивно понятно: чем больший объем работы мы оцениваем, тем выше неточность. Кроме того, между задачами, которые нам нужно оценить, могут быть зависимости (например, пока не будет сделана задача А, точно оценить трудоемкость задачи Б сложно). Тем не менее, просят дать оценку всего списка задач.
Предположим, вам нужно написать документ «Видение» (Vision). Вы определились со структурой документа, определили верхнеуровневый план работ и дали грубую оценку трудоемкости 35 дней. После чего в деталях расписали, что будете делать ближайшие 5 дней: выявлять ключевых заинтересованных лиц, формировать постановку проблем и определять перечень процессов, которые ваша система должна затронуть. Путем неимоверных усилий вы вложились в первоначальную оценку 5 дней. Но стало понятно, что 35 дней не хватит. Полученный опыт взаимодействия с заинтересованными (или не очень заинтересованными лицами), лучшее понимание границ системы позволяют вам переоценить трудоемкость оставшейся работы и подготовить детальный план на следующие 5–7 дней. И т. д.
Таким образом, метод предполагает, что у вас есть высокоуровневый план на длительный период и детальный — на ближайший период. Высокоуровневый план регулярно пересматривается по результатам завершения промежуточного этапа. Недостаток этого подхода — ваша первоначальная оценка может поменяться значительно (как правило, в сторону увеличения). Зато вы не откладываете печальную новость, что в срок все готово не будет, на финал. А значит, ваш руководитель может предпринять предупреждающие или корректирующие действия.
Чем больше раз вы пройдете путь «дал оценку — выполнил работу — сравнил план с фактом — проанализировал причины расхождений», тем лучше будете оценивать трудоемкость работ. Говоря о планировании, я вспоминаю книгу Де Марко «Вальсируя с медведями». В ней есть такой график:
По оси Х — даты, где дата N — сколько времени нам понадобится на выполнение проекта, если все будет хорошо), а по оси Y — вероятность, что проект будет выполнен. И т. к. у нас есть множество рисков, вероятность успеть в срок достаточно невысокая. Чем больше раз вы пройдете через указанный выше цикл, тем лучше будете понимать, с какими рисками можете столкнуться, а значит, какую поправку нужно применить к вашей оценке. В одном из моих проектов к вопросам выявления этой проблемы подходили системно. В JIRA накапливались данные по исходным оценкам трудоемкости задач и времени, которое в итоге на них ушло. Через два месяца выяснилось, что в среднем при оценке трудоемкости мои коллеги ошибаются на 25 % в сторону занижения. Применяя соответствующий коэффициент при планировании, мы смогли понизить количество вынужденных овертаймов и чаще укладываться в озвученные клиенту сроки.
Оценивайте, учитывайте риски, подбирайте подходящие под условия вашего проекта техники.
Comentarios