Данные советы взяты из книги Стива МакКоннела, опубликованной в рамках серии Microsoft Best Practices. Эта книга общепризнанна в качестве ценного источника знаний и рекомендована всем тем, кому приходится заниматься оценкой проекта – менеджерам проектов разработчикам, тимлидам и т.д. Разумеется, данные советы, перечисленные в этом посте, не являются исчерпывающими, и рассматриваются в первую очередь в их первоначальном контексте. Но, тем не менее.
Концепции критической оценки
Когда вас просят провести оценку, определите точно, что от вас требуется – именно оценка или описание того, каким путём в данном случае можно добиться желаемого результата.
Цель – это описание желаемого результата. Обязательство (commitment) – это обещание предоставить в конкретные сроки конкретный функционал конкретного уровня качества. Обязательство может совпадать с оценкой, быть её агрессивнее или консервативнее, но необходимо понимать, что это не одно и тоже.
Не используйте точечные оценки каких-то параметров и результатов, используйте диапазоны значений. Избегайте использования искусственно зауженных диапазонов, чтобы не подорвать доверия к вашему эстимэйту.
Никогда намеренно не занижайте оценку. В любом случае последствия недооценки будут куда более суровыми, нежели в случае переоценки. Вопросы по переоценке аргументируйте необходимостью планирования и контроля, а не какой-то предвзятостью своей оценки.
Возникающие расхождения между тем, что выполняется согласно оценке и бизнес-целью проекта лучше разрешать на как можно более ранней стадии иначе это ставит под угрозу весь проект.
Рассмотрите точность своих оценок в рамках данного Конуса Неопределённости. Ваша оценка не может быть более точной в соответствующей точке, то есть фактически стадии проекта, где вы находитесь в рамках конуса в данный момент. Используйте диапазоны точности оценки дальнейшего развития проекта при проведении последующих оценок.
Включайте в ваши оценки не только кодирование и тестирование, но и затраты на другие виды деятельности, при разработке. Например:
- Обучение новичков на проекте
- Развёртывание
- Уточнение требований
- Техревью
- Работа над производительностью системы
- Создание тестовых данных
Для проектов, длящихся более нескольких недель, закладывайте в оценки допуски времени и бюджета на отпуска, больничные, а также непроизводственную деятельность – обучение и митинги.
Никогда не давайте никаких оценок навскидку. Даже 15минутная оценка окажется гораздо точнее и аккуратнее.
Всегда документируйте допуски и предположения, добавленные в оценку.
Приводите в соответствие цифры в оценке к её точности. Например:
- «Этот проект займёт один год» - не совсем конкретно, но может быть для данной оценки достаточно точно.
- «Этот проект займёт 7,214 человеко-часов» - предельно конкретно, но может оказаться совсем неточным.
Не думайте, что объём необходимых для реализации проекта усилий растёт линейно с увеличением масштабов проекта.
Основные приёмы в оценке
Выберите какой-то элемент, типичную задачу или что-нибудь в этом роде, которые бы являлись значимой мерой объема работ в данной среде.
Соберите исторические данные о предыдущем опыте работы над подобными проектами в вашей компании. Производительность труда вашей организации в предыдущих проектах - лучший индикатор для оценки проекта от объёма работ, «чужие», то есть средние данные по индустрии в данном случае куда менее надёжны и адекватны.
После завершения каждого проекта сразу подводите статистические данные о длительности разработки в целом и поэтапно.
Так или иначе, лучше избегать внесения «экспертных» поправок и мнений в оценку, подготовленную на основе расчетов.
Для создания task-level оценок необходимо стараться привлекать тех людей, кто непосредственно будет их выполнять
Создавайте сразу как самый оптимистичный, так и наиболее пессимистичный варианты оценок, чтобы полностью представлять картину возможных последствий
Оценку новых проектов проводите в сравнении с похожими предыдущими проектами, желательно при этом разбивая эстимейт на как минимум пять частей.
Учитывайте важность различных элементов функционала заказчика. Допустим, составляя подобную «майку» расчёта важности той или иной функции для потребителя проекта.
(В данном случае имеется в виду использовать шкалу размеров маек, принятую в США – от S самый маленький, до XL самый большой. Верхняя таблица служит для получения цифрового числа важности элемента в зависимости от затрат, приходящихся на его разработку. Пример: если функция не имеющего особого значения (S) обходится в разработке большими затратами (XL) получаем вес -7). Определив значимость каждой функции, получаем нижнюю табличку, так сказать картину полезности функционала)
Попросите каждого члена команды оценить части проекта в индивидуальном порядке и замет просмотрите их эстимейты. Важно их не усреднить просто для конечной оценки, а найти консенсус, устраивающих всех.
Используйте специальный софт для оценки проекта, для проверки вменяемости вашей ручной оценки. Правда, не воспринимайте результат автомата, как какое-то божественное откровение. Пример подобного софта - http://www.construx.com/Page.aspx?nid=68
Первым делом оцениваете масштабность проекта, его размер, так сказать. Потом уже, исходя из этих знаний, прикидывайте, сколько потребуется на это затратить усилий и средств.
Проводите переоценку на каждом этапе разработки. Ориентируйтесь при оценке оставшейся части проекта на актуальные данные, а не запланированные.
Заранее обсуждайте возможность и ваши действия по переоценке проекта в процессе разработки с заказчиком.
Некоторые аспекты составления графика работ при оценке.
Не сокращайте время разработки в оценке, не увеличивая адекватно оценку необходимых усилий, количества человек и т.д.
Чем больше команда, тем больше необходимо закладывать время на менеджмент и координацию усилий
В больших командах больше путей коммуникации, а поэтому больше шанс возникновения недопонимания, а вследствие чего и ошибок.
Чем меньше сроки реализации проекта, тем больше работы запаралелливается. Чем больше задач пересекается и накладывается, тем больше шанс разработать новый кусок кода на основе дефектного старого, и потом переделывать уже сразу два.
Сокращайте расходы при необходимости за счёт удлинения проекта и проведения разработки меньшей командой.
Сочетайте расписание проведения различных видов деятельности согласно выбранному подходу к разработке (например, грамотно распределяйте нагрузку на тестеров в течение процесса разработки).
7 отличных курсов по финансам. Уплыть «с галеры» и основать свой стартап
Если вы посмотрели «Волк с Уолл-стрит» и хотите, как Леонардо ди Каприо прогуливаться по яхте с бокалом вина в руках, но не знаете, с чего начать, подборка курсов Digitaldefynd станет для вас отличным стартом. Здесь представлены как платные, так и бесплатные программы, которые помогут вам освоить финансовое моделирование. Они подойдут не только для начинающих слушателей, но и для экспертов.
Не Paint-ом единым. 13 курсов по UX/UI-дизайну для продвинутых и не только
Если вам нравится думать о том, как с минимальными затратами получить максимум эффективности, то проектирование пользовательских интерфейсов определенно вас заинтересует. DigitalDefynd сделал подборку курсов по UX/UI-дизайну как для новичков, так и для продвинутых специалистов.
Релоцировались? Теперь вы можете комментировать без верификации аккаунта.