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

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

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

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

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

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

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

    Хотите сообщить важную новость? Пишите в Телеграм-бот.

    Также не забудьте подписаться на наш Телеграм-канал.

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

    IT-миграция в ЕС - 2020
    24 ноября — 25 ноября

    IT-миграция в ЕС - 2020

    Dell Technologies Forum CEE
    26 ноября

    Dell Technologies Forum CEE

    HRgile.club
    2 декабря

    HRgile.club

    Минск

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

    Самые странные предметы для запуска DOOM: от пианино до теста на беременность
    Самые странные предметы для запуска DOOM: от пианино до теста на беременность
    Самые странные предметы для запуска DOOM: от пианино до теста на беременность
    Легендарный шутер DOOM вышел в 1993 году. В 1997-м разработчики открыли исходный код игры и, сами того не ожидая, дали толчок новой народной забаве — портировать DOOM на самые нереальные гаджеты. Вот небольшая подборка от The Next Web.
    1 комментарий
    Как разработчики манипулируют рейтингами в App Store
    Как разработчики манипулируют рейтингами в App Store
    Как разработчики манипулируют рейтингами в App Store
    Financial Times рассказывает, как разработчикам iOS-приложений удаётся получать более высокие рейтинги с помощью психологических уловок. Публикуем перевод.
    10 курсов, которые помогут подучить Python за день
    10 курсов, которые помогут подучить Python за день
    10 курсов, которые помогут подучить Python за день
    Python — один из самых популярных языков программирования. Его изучают для дальнейшего знакомства с пайтоновскими библиотеками Data Science и Machine Learning, для написания скриптов и автоматизации тривиальных задач или для веб-разработки. Изучение можно начать с 10 бесплатных ресурсов, которые собрал Hackernoon для новичков и не только. 
    Не Paint-ом единым. 22 курса по UX/UI-дизайну для продвинутых и не только
    Не Paint-ом единым. 22 курса по UX/UI-дизайну для продвинутых и не только
    Не Paint-ом единым. 22 курса по UX/UI-дизайну для продвинутых и не только
    Если вам нравится думать о том, как с минимальными затратами получить максимум эффективности, то проектирование пользовательских интерфейсов определенно вас заинтересует. DigitalDefynd сделал подборку 22 курсов по UX/UI-дизайну как для новичков, так и для продвинутых специалистов. 

    Обсуждение

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

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

    0

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

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

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

    Спасибо! 

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

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