Комментарии 12
А теперь как делают в реальности:
Оценка разработки (всевозможными методами, описанными в вашей статье)
Дальше 30% от разработки в человекочасах на тестирование
Дальше 30% от разработки в чч на исправление дефектов
Прибавляем 1 фулл тайм руководителя проектов на всю длительность проекта (это вы должны уже понять в 1-3 пп)
Добавляем 1-2 аналитиков на фуллтайм (плавающее привлечение не помогает на больших проектах)
Добавим 0.5 девопса и 0.5 ui/ux на весь проект
Закладываем 10-20% сверху всего этого на приемку/опытную эксплуатацию.
Если нужна гарантия, то растягиваем 1-2 разрабов с 20% загрузкой на год, еще добавляем 0.1 проджекта.
И даже на Pi умножать потом не нужно будет)
Из своей многолетней практики я извлёк убеждение, что только аналого-сопоставительный метод даёт реалистичные оценки. Если нет человека, который ранее руководил разработкой чего-то подобного – бессмысленно угадывать трудоёмкость, а если такой человек есть – то особо незачем. Разве что для бизнес-отчётности.
Оценка снизу-вверх, как всякий метод интегрирования, накапливает ошибки и теряет значимость через небольшое количество итераций.
Хорошим предметом для медитации после завершения проекта являются таблицы экспертной оценки трудоёмкости, заполненные до его начала. С неизбежностью обнаруживается, что, даже угадав общую сумму, промахиваемся мимо отдельных слагаемых, а следовательно, суммирование – это имитация оценки, а не реальный метод.
Спасибо за комментарий. Бесспорно! Если человек уже делал что-то подобное, тогда у него есть опыт и он может увидеть больше других, сделать оценку точнее! Но я бы всё таки рекомендовал даже таким опытным людям делать проверки своих оценок (в рамках расчётного метода). Если это конечно требуется, если такой потребности нет, то конечно нет смысла тратить время и ресурсы на формальные оценки.
Оценку снизу вверх тоже надо повторять, как и любые другие оценки. Т.е. её повторно проводят на разных этапах жизненного цикла разработки системы и этапов проекта.
Хорошим предметом для медитации после завершения проекта являются таблицы экспертной оценки трудоёмкости, заполненные до его начала. С неизбежностью обнаруживается, что, даже угадав общую сумму, промахиваемся мимо отдельных слагаемых, а следовательно, суммирование – это имитация оценки, а не реальный метод.
Это классное дополнение, спасибо!
Чем детальнее будет выполнена декомпозиция, тем более точной будет оценка.
В этой деятельности существует опасность эффекта фрактала, хотя и у оценки могут быть свои цели.
"КЛЮЧЕВАЯ ОШИБКА" - Это думать, что кучка миллиардеров, сделавших деньги на соцсетях и тиндерах умнее ракетостроителей.
ГОСТ Р 58302-2018 Управление стоимостью жизненного цикла. НОМЕНКЛАТУРА ПОКАЗАТЕЛЕЙ ДЛЯ ОЦЕНИВАНИЯ СТОИМОСТИЖИЗНЕННОГО ЦИКЛА ИЗДЕЛИЯ. Общие требования
5.1 Для оценивания стоимости ЖЦ используют следующие показатели:
- стоимость ЖЦ;
- стоимость владения;
- стоимость приобретения;
- стоимость эксплуатации;
- стоимость эксплуатации за календарный период времени;
- затраты на эксплуатацию в единицу календарного времени;
- остаточная стоимость изделия на расчетный год;
- стоимость утилизации;
- остаточная стоимость составных частей изделия и материалов послеутилизации;
- стоимость разработки.
ГОСТ Р 56136-2014 УПРАВЛЕНИЕ ЖИЗНЕННЫМ ЦИКЛОМ ПРОДУКЦИИ ВОЕННОГО НАЗНАЧЕНИЯ. Термины и определения
ГОСТ Р ИСО/МЭК 25021-2014 Информационные технологии. СИСТЕМНАЯ И ПРОГРАММНАЯ ИНЖЕНЕРИЯ. Требования и оценка качества систем и программного обеспечения(SQuaRE). Элементы показателя качества
ПС: И на риски, профессии, процессы, описание проектов и результатов тоже есть свой ГОСТ.
Спасибо за комментарий!
Я добавлю данные госты в статью, спасибо! Единственное, в них всё таки нет ответов на многие вопросы. Если брать ГОСТ Р 58302-2018, то по сути это набор показателей (видов затрат), которые надо учесть при оценки стоимости разработки.
Но например, есть показатель: "Затраты на обучение технического персонала", но нет ответа, а как оценить то эти затраты на обучение. Т.е. ГОСТ описывает, как сделать расчёт разных затрат, но не описывает, как их оценивать.
Берёте профстандарт и ваши требования к компетенциям на РМ, определяйте разницу между требуемым вам уровнем и средним уровнем приходящего работника (оценка нужна по профстандарту). Если вы знайте цену операций, на которую берете работника, то дальше проблем не будет. Ваш работник - это оборудование, если оно не соответствует требованиям (вашим), его нужно доработать/доучить. В авто сервисе используются стандартные наборы работ, на все автомобили... используйте тот же подход, это же технический персонал.
Hidden text
И что работает вот это вот все? Из моей практики ещё ни один проект не был выполнен во время, с теми ресурсами и затратами с которыми в него вошли, хорошо, если бюджет перезаложили раза в два, а если нет, то вся работа в убыток. Из рассказов коллеги у которого 50 крупных проектов за спиной в качестве или РП или руководителя проектного офиса только один вписался в бюджет и был сдан во время, потому что руководили разработкой там японцы.
Спасибо за комментарий.
Я могу лишь оперировать своим опытом и ответить "Да, работает", но есть нюансы. В самом начале статьи, в разделе базовой теории, я старался разделить понятие "оценка" и "планирование". Когда комментарии вы пишите, что ещё ни один проект не был сделан вовремя, то имеете в виду, что он не был выполнен согласно плана. Но оценка не равна плану, оценка это инструмент, которые помогает в дальнейшем планировать и правильно оценивать реальность этих планов. Плюс переоценку полезно делать на разных этапах жизненного цикла разработки и на разных этапах проекта.
В управлении проектами разработки ПО, планирование является кое чем большим, чем просто правильно сделанная оценка. Например, в гибких подходах разработки планируется каждый спринт и важно не забывать про управление рисками, которые всегда есть. Оценка не может повлиять на то, как команда или компания реагирует на риск. Можно конечно закладывать дополнительно время, но это не правильный путь. В общем, я хочу передать мысль, что важно не путать динамический процесс ведения проектов и оценку, как инструмент.
Цель оценки - не выполнить план, а развеять иллюзии, создать прозрачность. Например, в компании принято считать, что аналитик тратит около 4 ч/ч на подготовку требований для нового отчёта, но когда они посмотрели среднее время выполнения таких задач, то обнаружили, что это время 2.5. ч/ч. Очень простой пример, но на нём можно понять разницу между "интуитивными" оценками и сделанными на базе метрик.
Но вы правы, проекты действительно часто не выполняются вовремя. И на это есть 3 ключевые причины:
Изменение скоупа проекта (т.е. его содержания).
Недооценка объёма работы (сложности) и соответственно временных затрат ( и финансовых тоже).
Плохое планирование и управление рисками.
Хочу добавить ещё один важный важный психологический момент. Написанное ниже является моим субъективным мнением.
Не сделать проект вовремя - это не плохо, если изменился его скоуп, если не учли сложные моменты в начале работы, но сделали потом ретроспективу и вторую часть проекта учитывали ошибки.
Не плохо, даже если руководство до конца не может понять ситуацию на проекте, а управляющий менеджер не может её объяснить, но ищет способы всё обсудить со стейкхолдерами и выровнять баланс проекта. Другими словами поехали сроки, но проект важный и надо доделывать, учитывая прошлый опыт. Это жизнь, так бывает. В крупных и дорогих проектах очень много заинтересованных сторон и может быть очень сложно держать баланс.
Но плохо, если не сделали проект вовремя и забили разбираться почему именно, никому не хватило смелости или ответственности взять на себя вину за ошибки.
Кстати, бюджет закладывают часто не потому, что не могут корректно оценить проект, а скорее из за неточности бизнес целей и нежелания проходить повторную защиту бюджета на разных комитетах (актуально для крупных компаний).
В общем, причин почему проекты не делают вовремя целая куча, а вот успешность проекта измеряется не только сроками, но и разными другими факторами. А оценка, это просто инструмент для создания прозрачности и помощник в управлении. Наверное было бы странным, если бы разработчик (аналитик, архитектор, подставь нужное) не давал оценок по своим задачам...А если оценить очень сложно, для этого и есть описанные в статье методы.
Тут ещё есть большой плат который сложно спрогнозировать. Обычно ставят цель реализовать и внедрить фичу.
И вот реализовать (аналитика, разработка, тестирование) часто укладывается в план, а вот задеплоить у клиента это тот ещё квест с кучей неизвестных, типа нужные люди у клиента заняты или инфраструктура не готова, или доступы не все предоставили. И в итоге тут по времени и проезжает.
Да, спасибо за комментарий.
Связка делает подрядчик, отдаёт исходник клиенту, а деплой у клиента - вообще является организационно сложной и может быть крайне тяжело дать оценку. По моему опыту тут важно выстроить процесс т.е. сделать прозрачными все эти неизвестные факторы и договорится со всеми о правилах работы. Если процесса нет, то и оценка не получится.
Оценка стоимости разработки программного продукта, информационной системы, сервиса или задачи