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

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

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

  • Когда вас просят провести оценку, определите точно, что от вас требуется – именно оценка или описание того, каким путём в данном случае можно добиться желаемого результата.
  • Цель – это описание желаемого результата. Обязательство (commitment) – это обещание предоставить в конкретные сроки конкретный функционал конкретного уровня качества. Обязательство может совпадать с оценкой, быть её агрессивнее или консервативнее, но необходимо понимать, что это не одно и тоже.
  • Не используйте точечные оценки каких-то параметров и результатов, используйте диапазоны значений. Избегайте использования искусственно зауженных диапазонов, чтобы не подорвать доверия к вашему эстимэйту.
  • Никогда намеренно не занижайте оценку. В любом случае последствия недооценки будут куда более суровыми, нежели в случае переоценки. Вопросы по переоценке аргументируйте необходимостью планирования и контроля, а не какой-то предвзятостью своей оценки.
  • Возникающие расхождения между тем, что выполняется согласно оценке и бизнес-целью проекта лучше разрешать на как можно более ранней стадии иначе это ставит под угрозу весь проект.
  • Рассмотрите точность своих оценок в рамках данного Конуса Неопределённости. Ваша оценка не может быть более точной в соответствующей точке, то есть фактически стадии проекта, где вы находитесь в рамках конуса в данный момент. Используйте диапазоны точности оценки дальнейшего развития проекта при проведении последующих оценок.
  • Включайте в ваши оценки не только кодирование и тестирование, но и затраты на другие виды деятельности, при разработке. Например:
  • - Обучение новичков на проекте - Развёртывание - Уточнение требований - Техревью - Работа над производительностью системы - Создание тестовых данных
  • Для проектов, длящихся более нескольких недель, закладывайте в оценки допуски времени и бюджета на отпуска, больничные, а также непроизводственную деятельность – обучение и митинги.
  • Никогда не давайте никаких оценок навскидку. Даже 15минутная оценка окажется гораздо точнее и аккуратнее.
  • Всегда документируйте допуски и предположения, добавленные в оценку.
  • Приводите в соответствие цифры в оценке к её точности. Например:
  • - «Этот проект займёт один год» - не совсем конкретно, но может быть для данной оценки достаточно точно. - «Этот проект займёт 7,214 человеко-часов» - предельно конкретно, но может оказаться совсем неточным.
  • Не думайте, что объём необходимых для реализации проекта усилий растёт линейно с увеличением масштабов проекта.
  • Основные приёмы в оценке

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

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

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

    Хотите сообщить важную новость?

    Пишите в наш Телеграм

    Горячие события

    Конкурс EY Entrepreneur Of The Year 2020
    31 мая

    Конкурс EY Entrepreneur Of The Year 2020

    EMERGE 2020
    1 июня — 3 июня

    EMERGE 2020

    Вебинар «Советы от рекрутеров: как найти квалифицированную работу в Европе»
    4 июня

    Вебинар «Советы от рекрутеров: как найти квалифицированную работу в Европе»

    Читайте также

    Как защитить видеозвонки. Советы экспертов
    Как защитить видеозвонки. Советы экспертов

    Как защитить видеозвонки. Советы экспертов

    За месяц число ежедневных активных пользователей сервиса для видеосвязи Zoom выросло в 1,5 раза — с 200 млн до 300 млн, хотя ещё в декабре их было лишь 10 млн. По мере роста популярности приложение стало привлекать хакеров, а в сети появилось столько новостей об уязвимостях Zoom, что на мессенджер обратило внимание ФБР. Издание Computerworld собрало небольшой список рекомендаций от экспертов по кибербезопасности о том, как защитить данные и участников видеоконференций от взломов, утечек и непрошенных гостей.
    Guardian: массовые мероприятия как топливо для эпидемии
    Guardian: массовые мероприятия как топливо для эпидемии

    Guardian: массовые мероприятия как топливо для эпидемии

    Коллективная статья семи журналистов Guardian о том, почему массовые скопления, рукопожатия, поцелуи и общие напитки виноваты в распространении коронавируса. Публикуем перевод материала с незначительными сокращениями.
    1 комментарий
    10 образовательных приложений, чтобы провести самоизоляцию с пользой
    10 образовательных приложений, чтобы провести самоизоляцию с пользой

    10 образовательных приложений, чтобы провести самоизоляцию с пользой

    Перевели подборку бесплатных приложений для удалённого обучения. для тех, кто устал от доомашнего спорта, документалок и сериалов.
    3 комментария
    Как локдаун помог интернету
    Как локдаун помог интернету

    Как локдаун помог интернету

    MIT Technology Review объяснили, почему резкий рост трафика не «сломал» сеть, а привёл к серьёзным качественным улучшениям.

    Обсуждение

    Александр Флахбарт
    Александр Флахбарт программист в BELHARD
    1

    Мне всегда нравилось, как американцы любят параллели проводить с какой-нибудь бытовой фигнёй, как в данном случае с майками. У меня бы так никогда не получилось.

    0

    А книга, из которой взята информация, продается у нас и называется "Сколько стоит программный продукт". Кстати, очень рекомендую почитать. Полезно будет всем, но особенно менеджерам проектов.

    Anonymous
    Anonymous разработчик в RichBrains
    0

    Хоть раз в полгода на этом, сайте обсуждается не "кризис" в IT и другое гомно, а что-то полезное.
    Спасибо!

    Спасибо! 

    Получать рассылки dev.by про белорусское ИТ

    Что-то пошло не так. Попробуйте позже