Советы по проведению оценки

Данные советы взяты из книги Стива МакКоннела, опубликованной в рамках серии Microsoft Best Practices. Эта книга общепризнанна в качестве ценного источника знаний и рекомендована всем тем, кому приходится заниматься оценкой проекта – менеджерам проектов разработчикам, тимлидам и т.д. Разумеется, данные советы, перечисленные в этом посте, не являются исчерпывающими, и рассматриваются в первую очередь в их первоначальном контексте. Но, тем не менее.

Концепции критической оценки

• Когда вас просят провести оценку, определите точно, что от вас требуется – именно оценка или описание того, каким путём в данном случае можно добиться желаемого результата.
• Цель – это описание желаемого результата. Обязательство (commitment) – это обещание предоставить в конкретные сроки конкретный функционал конкретного уровня качества. Обязательство может совпадать с оценкой, быть её агрессивнее или консервативнее, но необходимо понимать, что это не одно и тоже.
• Не используйте точечные оценки каких-то параметров и результатов, используйте диапазоны значений. Избегайте использования искусственно зауженных диапазонов, чтобы не подорвать доверия к вашему эстимэйту.
• Никогда намеренно не занижайте оценку. В любом случае последствия недооценки будут куда более суровыми, нежели в случае переоценки. Вопросы по переоценке аргументируйте необходимостью планирования и контроля, а не какой-то предвзятостью своей оценки.
• Возникающие расхождения между тем, что выполняется согласно оценке и бизнес-целью проекта лучше разрешать на как можно более ранней стадии иначе это ставит под угрозу весь проект.
• Рассмотрите точность своих оценок в рамках данного Конуса Неопределённости. Ваша оценка не может быть более точной в соответствующей точке, то есть фактически стадии проекта, где вы находитесь в рамках конуса в данный момент. Используйте диапазоны точности оценки дальнейшего развития проекта при проведении последующих оценок.

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

- Обучение новичков на проекте - Развёртывание - Уточнение требований - Техревью - Работа над производительностью системы - Создание тестовых данных

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

Никогда не давайте никаких оценок навскидку. Даже 15минутная оценка окажется гораздо точнее и аккуратнее.

Всегда документируйте допуски и предположения, добавленные в оценку.

Приводите в соответствие цифры в оценке к её точности. Например:

- «Этот проект займёт один год» - не совсем конкретно, но может быть для данной оценки достаточно точно. - «Этот проект займёт 7,214 человеко-часов» - предельно конкретно, но может оказаться совсем неточным.

Не думайте, что объём необходимых для реализации проекта усилий растёт линейно с увеличением масштабов проекта.

Основные приёмы в оценке

• Выберите какой-то элемент, типичную задачу или что-нибудь в этом роде, которые бы являлись значимой мерой объема работ в данной среде.
• Соберите исторические данные о предыдущем опыте работы над подобными проектами в вашей компании. Производительность труда вашей организации в предыдущих проектах - лучший индикатор для оценки проекта от объёма работ, «чужие», то есть средние данные по индустрии в данном случае куда менее надёжны и адекватны.
• После завершения каждого проекта сразу подводите статистические данные о длительности разработки в целом и поэтапно.
• Так или иначе, лучше избегать внесения «экспертных» поправок и мнений в оценку, подготовленную на основе расчетов.
• Для создания task-level оценок необходимо стараться привлекать тех людей, кто непосредственно будет их выполнять
• Создавайте сразу как самый оптимистичный, так и наиболее пессимистичный варианты оценок, чтобы полностью представлять картину возможных последствий
• Оценку новых проектов проводите в сравнении с похожими предыдущими проектами, желательно при этом разбивая эстимейт на как минимум пять частей.
• Учитывайте важность различных элементов функционала заказчика. Допустим, составляя подобную «майку» расчёта важности той или иной функции для потребителя проекта. (В данном случае имеется в виду использовать шкалу размеров маек, принятую в США – от S самый маленький, до XL самый большой. Верхняя таблица служит для получения цифрового числа важности элемента в зависимости от затрат, приходящихся на его разработку. Пример: если функция не имеющего особого значения (S) обходится в разработке большими затратами (XL) получаем вес -7). Определив значимость каждой функции, получаем нижнюю табличку, так сказать картину полезности функционала)
• Попросите каждого члена команды оценить части проекта в индивидуальном порядке и замет просмотрите их эстимейты. Важно их не усреднить просто для конечной оценки, а найти консенсус, устраивающих всех.
• Используйте специальный софт для оценки проекта, для проверки вменяемости вашей ручной оценки. Правда, не воспринимайте результат автомата, как какое-то божественное откровение. Пример подобного софта - http://www.construx.com/Page.aspx?nid=68
• Первым делом оцениваете масштабность проекта, его размер, так сказать. Потом уже, исходя из этих знаний, прикидывайте, сколько потребуется на это затратить усилий и средств.
• Проводите переоценку на каждом этапе разработки. Ориентируйтесь при оценке оставшейся части проекта на актуальные данные, а не запланированные.
• Заранее обсуждайте возможность и ваши действия по переоценке проекта в процессе разработки с заказчиком.

Некоторые аспекты составления графика работ при оценке.

• Не сокращайте время разработки в оценке, не увеличивая адекватно оценку необходимых усилий, количества человек и т.д.
• Чем больше команда, тем больше необходимо закладывать время на менеджмент и координацию усилий
• В больших командах больше путей коммуникации, а поэтому больше шанс возникновения недопонимания, а вследствие чего и ошибок.
• Чем меньше сроки реализации проекта, тем больше работы запаралелливается. Чем больше задач пересекается и накладывается, тем больше шанс разработать новый кусок кода на основе дефектного старого, и потом переделывать уже сразу два.
• Сокращайте расходы при необходимости за счёт удлинения проекта и проведения разработки меньшей командой.
• Сочетайте расписание проведения различных видов деятельности согласно выбранному подходу к разработке (например, грамотно распределяйте нагрузку на тестеров в течение процесса разработки).
Источник | Оригинал

Новый рекламный формат в наших телеграм-каналах.

Купить 500 символов за $150