Как избежать неправильного оценивания проектов


Насколько точные у вас эстимейты?
Мы очень тщательно проанализировали проект и уверены в оценке.
А если у проекта будет фикс-прайс, вы готовы подписать такой контракт?
Упс...

Всем привет! Меня зовут Наталья, я Delivery Program Manager. Мне очень часто приходится сталкиваться со следующими вопросами:

  • Как рассчитать длительность нового проекта?
  • Как проэстимировать новый продукт, с которым мы еще никогда не сталкивались?
  • Как оценить проект с высоким уровнем точности?
  • Как сохранить актуальность оценки при изменениях в проекте?
  • Как оценивать в условиях неопределенности?
  • Как понять, что в оценке, которая предоставлена командой, что-то не так?

Частые дискуссии и обсуждения дают понимание, что тема оценки проектов актуальна для многих проджект-менеджеров, которые сталкиваются с вопросами оценки задач, спринтов, релизов или разработки всего продукта. В этой статье я дам несколько советов, как избежать головной боли (или хотя бы уменьшить ее) по поводу неправильных эстимейтов.

Мои знакомые менеджеры часто признают, что ошибки в эстимейтах являются одной из наиболее распространенных причин возникновения проблем в проектах.

Переоценка проекта может привести к проигрышу в тендере или к недоверию клиента. Частое непопадание в свои же эстимейты приводит к обоснованному давлению со стороны клиента для снижения оценки.

Недооценка размера и сложности проекта или каких-то его частей, некорректная оценка трудозатрат и сроков исполнения проектов — все это может оборачиваться овертаймами проектной команды, выгоранием или эмоциональным напряжением при изменениях скоупа и/или бюджета. Вдобавок все это может привести к неудовлетворенности заказчика и потере деловой репутации.

Многие знают о золотом треугольнике «скоуп — время — деньги», из которого рассчитывается качество проекта. Если исходить из этого, точность оценки зависит от нескольких факторов, как то:

  • количество предположений и допущений в скоупе работ;
  • корректная оценка требуемых ресурсов и правильный подбор специалистов для команды;
  • тщательность фиксирования критериев качества.

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

Процесс оценки

В этой статье мы рассмотрим общий процесс оценки проекта. Какие основные шаги нужно учитывать, если вы начинаете работать с новым проектом или к вам приходит запрос на изменение существующего?

Прежде чем ответить, как оценить проект, нужно понять, что мы оцениваем.

Первый шаг — определить Project & Product Scope

Для начала нужно определить скоуп выполняемых работ и ограничения. Для этого:

  1. Определяем одного или нескольких стейкхолдеров, которые могут выступать в роли владельца продукта (Product Owner).
  2. Обсуждаем с Product Owner скоуп продукта: что должно быть сделано, какой функционал ожидается, какие бизнес-потребности должен покрыть этот продукт. Таким образом мы формируем Product Scope.
  3. На основании Product Scope создаем скоуп проекта — Project Scope — то, как мы будем реализовывать требуемый функционал. На этом этапе можно предварительно оценить сроки и стоимость проекта (L0 estimates).
  4. Разница между скоупом продукта и скоупом проекта:
  5. Если нам нужны точные оценки длительности работ, то опускаемся еще на один уровень ниже — иерархической структуры работ (Work Breakdown Structure — WBS). Разделение задач на этом уровне позволяет правильно оценить временные ресурсы и стоимость проекта.

Основываясь на своей практике, могу сказать, что на первых двух этапах очень важно писать задачи не только In Scope, но еще и Out of Scope. Если вы хотите узнать, как Out of Scope — требования могут повлиять на проект, рекомендую посмотреть ролик Portfolio.

А еще важно проработать нефункциональные требования, которые также могут сильно повлиять на окончательное время исполнения проекта.

Следующий этап — собрать команду для оценки

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

Если проект нестандартный для PM или компании, нужно собрать группу экспертов (по технологиям и/или по доменной области), которые помогут в оценке.

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

Основные челленджи при оценке экспертами:

  • Привлечение экспертов, которые не имеют опыта в оценке работ по проекту. Они могут сказать, что нужно учесть при планировании (построить WBS), но не смогут оценить затраты по времени.
  • Эксперты-оптимисты недооценивают сложность работ и дают заниженные оценки.
  • Эксперты-перестраховщики сильно переоценивают проект и дают завышенные оценки.
  • Опора на оценку сеньоров, которые оценивают «под себя» и не могут давать оценку работ с учетом того, что на проекте будут мидл- или джуниор-разработчики/тестировщики.

Поэтому PM важно подбирать сбалансированную команду.

Когда у нас уже есть скоуп работ и группа экспертов, можно перейти к вопросу, как оценить проект.

В чем измеряется длительность проекта или задачи

Единицы измерения могут быть разными, и об этом важно договариваться с самого начала.

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

Если говорить о Scrum-командах или быстрых приблизительных оценках, то для эстимирования можно использовать сторипойнты в числах Фибоначчи, размеры футболок, степени двойки.

Если разложить оценку в сторипойнтах в виде формулы, то получится:

Сторипойнт = длительность задачи × сложность задачи × неопределенность

Более детально можно ознакомиться с техникой, почитав о Planning Poker.

При этом длительность проекта можно рассчитать, используя такие метрики, как velocity и capacity команды: первые спринты рассчитываются исходя из capacity, после 3-го спринта уже достаточно статистики по средней velocity команды, чтобы оценить, сколько спринтов необходимо для завершения разработки продукта.

Более детально об опыте работы в Scrum-командах я расскажу в отдельной статье.

Если мы рассчитываем фикс-прайс-проекты, нам нужно как можно точнее оценить планируемое время в днях или часах. Однако это непростой и небыстрый способ.

Нюансы работы с фикс-прайс-проектами будут разобраны в отдельной статье, где я расскажу, как это работает на практике.

Как измеряются проекты

Идеально делать разработку и, соответственно, оценку работ в 3 этапа:

  1. Подготовка дизайна будущего продукта.
  2. Построение архитектуры продукта или системы и описание функциональных/нефункциональных требований.
  3. Разработка самого продукта на основе уже готовой архитектуры.

Первый пункт оценить проще, чем оценить всю работу с нуля, как и дать оценку по разработке на основании готовой архитектуры. Но и вероятность того, что клиент согласится на такую разбивку работ, пока мала. Чаще всего клиент приходит с пожеланиями «сделай мне то — не знаю что, но прямо сейчас». Варианты быстрой оценки есть тут.

На этом этапе может быть достаточно L0 estimates, которые можно рассчитать, используя ROM (Rough Order of Magnitude), особенно если это влияет на годовое планирование и приоритизацию roadmap продукта. При этом очень важно помнить, что, указывая приблизительные оценки, нужно акцентировать внимание на допущениях, которые могут увеличить длительность проекта.

Неопределенность оценок в начале обсуждения нового проекта хорошо отображается через конус неопределенности. И даже если PM при оценке проекта добавляет 30% к верхнеуровневой оценке, это не гарантирует ему выполнение проекта в срок. В каких случаях менеджер добавляет время на уже проведенную экспертами оценку, ранее хорошо было описано тут.

Методы оценки проекта, которые мы используем в командах

МетодПреимуществаОграниченияРекомендации
Экспертная оценка
  • используется предыдущий опыт для более точной оценки;
  • можно покрыть достаточно большой спектр проектов;
  • можно достаточно быстро получить предварительные оценки;
  • также можно получить количественные оценки.
  • необходимо найти эксперта в доменной области или в разработке похожих проектов;
  • точность оценки зависит от компетентности эксперта;
  • можно достаточно быстро получить предварительные оценки;
  • субъективность метода.
  • декомпозировать задачи до уровня WBS;
  • привлекать нескольких экспертов и сравнивать результаты их оценки;
  • дополнительно использовать другие техники, например PERT.
Метод PERT
  • используется в проектах, где предсказать продолжительность проблематично. Для расчета используется оценка 3 значений: оптимистического (наилучшего), ожидаемого (вероятного) и пессимистического (наихудшего);
  • устанавливается последовательность выполнения действий и их взаимосвязь;
  • часто используется в инновационных проектах.
  • громоздкость схемы сетевого графика;
  • требует много времени и средств на поддержание в актуальном состоянии;
  • связи и последовательность действий не всегда бывают точно отображены;
  • используются только зависимости «финиш — старт».
  • использовать как хороший инструмент визуализации целей и задач;
  • совмещать с другими техниками;
  • привлекать экспертов для оценки задач.
Метод «по аналогии»
  • установление аналогии позволяет использовать известные части прошлых проектов;
  • обычно является менее дорогостоящим, чем другие инструменты;
  • оценка по аналогии предпочтительна в том случае, когда детальная информация о проекте отсутствует.
  • субъективная оценка, основанная на гипотезах;
  • аналогию нельзя использовать при исследовании объектов и систем управления принципиально новых объектов, процессов, ситуаций, не имеющих аналогов в базе знаний;
  • необходимо учитывать черты как сходства, так и различия между неизвестными и известными элементами.
  • накапливать базу знаний и описанных case study;
  • документировать оценки проекта, к которым привлекаются внешние эксперты (метод экспертной оценки). При недостатке аналогичных проектов подобная статистика может помочь для верхнеуровневой оценки.
Метод Use Case Points
  • удобен для описания функциональных требований к системе;
  • дает возможность провести быструю оценку;
  • хорошо подходит для несложных алгоритмов.
  • неудобен при описании нефункциональных требований системы;
  • необходимо знать стандартные сценарии работ;
  • точность зависит от эксперта (аналитика).
  • использовать для несложных систем, в которых можно прописать алгоритмы действий.

Повышение точности оценок

  1. Повысить точность оценок поможет разбивка работ до уровня задач или активностей. Тогда можно будет точно указать последовательность работ, стоимость каждой работы, проанализировать, какие роли должны быть в проекте, и построить критический путь по работам, которые принесут максимальную пользу проекту. С такой детальной оценкой мне удалось выиграть не один тендер.
  2. Также важную роль в оценке играют допущения или предположения. Именно в допущениях мы можем указать, как и насколько могут вырасти оценки при воздействии различных факторов. Например, если нам нужен компьютер с определенной конфигурацией для определенных работ, то такие работы могут быть начаты не раньше, чем будет закуплена техника.
  3. При планировании и оценке можно и нужно использовать не максимально возможную, а среднюю скорость работы, используя метрики Agile-команд. Таким образом, мы избежим неприятных неожиданностей в плане того, что ребята из команды могут заболеть или почти полным составом уйти в отпуск на Новый год.
  4. Также можно провести оценку проекта, используя разные методы, и сравнить полученные результаты. Средний результат можно использовать как оценку проекта.

Предполагаемая длительность проекта на основании полученных оценок

Длительность проекта можно рассчитать по следующему алгоритму:

  • определить скоуп выполняемых работ в текущем релизе*;
  • приоритизировать выполнение задач*;
  • проанализировать зависимости между задачами;
  • составить план проекта с учетом необходимой последовательности задач;
  • проставить все праздники и выходные дни;
  • распределить задачи среди всех участников команды.

* На этом этапе уже готово.

После этого очень высока вероятность того, что придется начать планирование и расчеты заново.

В PMBoK эта последовательность зациклена, потому что при добавлении факторов расчета (таких, как человеческий ресурс или бюджет) они же становятся и ограничениями проекта.

Основные ошибки при расчете длительности проекта:

  • не учитываем праздники и отпуска;
  • не закладываем 20% времени, которое тратится на коммуникацию внутри команды и с заказчиком;
  • не добавляем резерв на риски (а порой и риски не просчитываются);
  • не добавляем резерв на сложность и комплексность задач;
  • не учитываем зависимости от third party.

И теперь, когда у нас есть план выполнения проекта, мы отмечаем на графике Milestones & Deadlines. Следующий шаг — начинаем думать, как сокращать сроки, потому что не вписываемся в дедлайн или бюджет :)

Сокращение длительности проекта

Часто клиент требует уменьшить эстимейты по задаче, эпику или в целом по релизу.

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

Критический путь

«Критический путь — непрерывная последовательность задач в плане-графике от его начала и до конца, требующая наибольшего времени».

Критический путь определяет продолжительность проекта, поэтому является главным аргументом для обоснования продолжительности и основным инструментом ее сокращения.

Все задачи на критическом пути не имеют резерва времени выполнения, и срыв сроков выполнения любой такой задачи — это риск срыва сроков реализации проекта в целом.

Один из вопросов на интервью: Если вам удалось в 2 раза уменьшить длительность каждой задачи текущего критического пути, то как изменится длительность всего пути?

Правильный ответ: минимально. Даже если вы нарисуете на экране ноутбука сокращение длительности проекта в 2 раза, в реальности вы вряд ли получите эти сроки.

Очень хорошая книга по этой теме — «Критическая цепь» Элияху Голдратта. Книга идет очень легко, можно прочитать за вечер или два.

Мониторинг критического пути

  1. Постоянный контроль и проверка критического пути и статуса задач на нем.
  2. Контроль и проверка статуса задач, близких к критическому пути, — так называемых околокритических задач.
  3. Работа с рисками, связанными с критическими и околокритическими задачами.

И все же как можно сократить длительность проекта? Оптимально выбрать один из следующих вариантов:

  1. Перенести часть задач на другой релиз.
  2. Нанять более сильную команду для реализации проекта.
  3. Увеличить команду до старта проекта.
  4. Предложить POC или MVP.

Идеально получается редко. Чаще всего заказчик просит сократить длительность проекта по максимуму без ухудшения качества, без сокращения скоупа и без увеличения команды.

Для сокращения длительности критического пути можно использовать методы «Ускорение» или «Сжатие», если на вашем проекте это возможно.

МетодИдеяНедостатки
Fast Tracking («Ускорение»)Задачи на критическом пути выстраиваются параллельно, а не последовательно, хотя планировалось выполнять их последовательно.
  • повышенные переработки, что приводит к увеличению стоимости;
  • разработка «заглушек» или «костылей», что тоже приводит к увеличению стоимости;
  • увеличение рисков.
Crashing («Сжатие»)Увеличение количества людей на задачах критического пути за счет других задач проекта.
Стоит помнить о пословице «9 женщин не родят ребенка за 1 месяц».
В любой задаче есть предельное количество исполнителей, после которого длительность не сокращается, а начинает увеличиваться.
  • неоптимальность распределения задач, что приводит к росту стоимости и снижению эффективности;
  • увеличение объема коммуникаций;
  • удвоение исполнителей задачи может привести к блокировке выполнения этой задачи.

Итоги

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

Старайтесь делить скоуп продукта на относительно понятные части, которые проще оценить (WBS).

Не забывайте о допущениях и деталях Out of Scope, которые стоит прописать в контракте, особенно если у вас фикс-прайс-проект.

И не забывайте об идеальных сценариях, которые стоит предлагать клиенту: начать с фазы discovery (подробнее можно прочитать здесь или здесь), по результатам которой у вас будет написана документация и построена архитектура продукта, и только потом начинать фазу разработки. В моей практике были клиенты, для которых качество было очень важно и которые готовы были прислушиваться к мнению деливери-менеджера.

«И да пребудет с вами сила!»

Все про українське ІТ в телеграмі — підписуйтеся на канал DOU

👍ПодобаєтьсяСподобалось3
До обраногоВ обраному7
LinkedIn



78 коментарів

Підписатись на коментаріВідписатись від коментарів Коментарі можуть залишати тільки користувачі з підтвердженими акаунтами.

Не совсем понятно про выходные и праздники. Если проект занимает 1000 человеко-часов, то даже если у вас 3 новых года и куча других праздников плюс заболевший разраб, то на 1000 человеко-часов это никак не повлияет (за исключением случаев, когда после праздника голова болит, тогда часы считают 2:1).
Опять же по скоупу, что мы хотим продать заказчику. Например написание тестов и их поддержка могут занять 20-50% времени разработки. Могут не купить. Ожидание ответа от заказчика, когда пишете ему письмо с вопросами, а заказчик неделю ответить не может, а без этого работа стоит. Опять же работа со службой безопасности. С какой скоростью вы можете получить доступ к рабочим ресурсам. Тут тот случай, когда Новый год может иметь значение: на стороне заказчика все гуляют, работа стоит, а всего то и нужно заапрувить доступ на сервер или прокинуть защищённое соединение. Работы на пол часа, но без участия заказчика или его службы безопасности ждать можно те же самые 1000 часов.
Видимо нужно как то прописывать ответственность заказчика, ведь если проект стоит по их вине, то они должны как то это компенсировать.
Кстати по затратам на сами эстимейты. Если проект взрослый, то эстимейтить его можно и месяц и два. Меня всегда интересовало, кто за это платит, ведь контракт ещё не подписан, а уже толпа народа месяц работает.

Статья познавательная, спасибо)
Поправте ссылку:

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

дякую за уважність, виправили.

Есть непопулярное мнение, что можно жить замечательно и без таких оценок (движение #NoEstimates). Т.е управление проектами конечно ведется, но решения принимаются другим способом без необходимости делать «временные» оценки. Оставлю тут ряд источников для ознакомления с темой:

www.infoq.com/...​vasco-duarte-noestimates
www.youtube.com/watch?v=HfLzMpaV110 (Асхат Уразбаев #NoEstimates: Безоценочная разработка)
blogs.msdn.microsoft.com/...​the-path-to-no-estimates
softwaredevelopmenttoday.com/noestimates
xebia.com/...​sting-without-estimation

За отсылку к «Критическая цепь» Элияху Голдратта — спасибо. Многие менеджеры её не читали, а стоило бы.

Оно непопулярное потому, что у большинства крупных заказчиков в том или ином виде существует такой механизм, как бюджетирование. И бюджет на разработку никто не выделит без гарантий исполнителя сделать определённый объём работы за выделенную сумму денег.

Оценки нужны, если у комманды ещё нет статистики — т.е когда запускается новые проект, новая команда или меняются важные условия. Но для долго живущих проектов такие оценки постепенно теряют смысл (например оценки полученные по историческим данным за 3-5 итераций скрама часто аналогичны или даже иногда точнее новых оценок сделанных методом покера). Часто достаточно точную оценку можно сделать просто по количеству юзер сторейс. Чтобы дать гарантии (а другими словами взять на себя риски за свою попытку угадать пропускную способность комманды) нет необходимости делать новые оценки нового куска работы — накопленная статистика может быть не менее точным механизмом оценок.

накопленная статистика может быть не менее точным механизмом оценок

Может, не вопрос — и, более того, классическая теория даже рекомендует в этом случае использовать именно исторические данные.

Но — для этого на проекте или портфеле проектов должен быть конвейер более-менее однотипных задач. Что не гарантировано даже на долгоживущих проектах.

более-менее однотипных задач

это слишком сильное требование. достаточно более менее стабильного распределения сложности между задачами и отсутствия сверхтяжелых задач — outliers (предварительное биение задач на более мелкие это решает — это на самом деле самое важное) и достаточного количества задач в скопе (десятки и сотни задач). Дальше статистика сделает своё дело.

Поставить оговоренный объём функционала в рамках бюджета и сроков

За которые спросят как за гарантии :)

В ряде случаев упереться рогом в контракт и не идти навстречу заказчику, даже если по факту сам продолбал, может оказаться Пирровой победой.

Если к тебе очередь из заказчиков стоит, которые ещё и не охвачены единым «сарафанным радио» — может, и прокатит. В иных случаях испорченная репутация может оказаться гораздо дороже, тем твои инвестиции в отношения с заказчиком.

Так проблема зачастую, как раз, не в местных, а в забугорных со стороны заказчика. Enterprise он такой enterprise...

Хм. У меня нет такой статистики, но личный опыт говорит об обратном. Те пару раз, где мне везло и я попадал на проекты с отсутствие эстимейтов, это были проекты с лидом от заказчика и полным управлением проектом с их стороны. Я сейчас как раз на таком. У задач нет эстимейтов. Пару раз я сам волновался, что долго сижу над задачей без видимого прогресса и говорил свои ожидания по завершению по своей инициативе. Ещё пару раз меня лид спросил нужна ли мне помощь в задаче и что меня тормозит. Это все, что можно сказать о эстимейтах, которые у меня были за последний год... остальное время контроль это — частое закрытие задач или подзадач, периодические репорты (чем занят) и грамотный лид. И задачи у нас абсолютно разные с большим количество исследовательский задач. Некоторые занимают дни, некоторые недели и даже месяцы (бьются нами на мелкие подзадачи во время исполнение). Я потому с такой уверенностью и говорю о применимости такого подхода, что вижу это работающим каждый день. Может и не везде применимо, но точно не только для «однотипных задач». Как раз в большей степени, где много исследовательских задач и «точные» эстимейты слишком дорого и сложно.

По сути, зависит от гибкости, с которой менеджмент со стороны заказчика может распоряжаться бюджетом.

Если выделен щедрый бюджет на R&D и есть адекватный лид — конечно, вполне возможна и такая ситуация, как вы описали.

Ещё зацикленность есть в том, что есть две оценки, идеализированная, когда мы бидимся за проект (или просто делаем предложение к нашему годовому портфолио, не зная, какие проекты в конце концов будут отобраны), но ещё не знаем, кто точно и когда будет на нем работать. И когда мы уже выиграли проект, и начинаем делать более реальный план, с реальными людьми и датами.

Все верно:
Иногда мы делаем оценки на хайлевел (L0), чтобы выбрать те проекты, с которыми будем работать в этом году. А потом, когда выставлены приоритеты, мы делаем детальные оценки.

Я рада, что у вас есть такой опыт.
Однако не все проекты такие.

Если уж упоминаем «Элияху Голдратта», то лучше сразу направлять мысль в сторону «Критической цепи» (как метода), где критическая цепь — модификация критического пути учитывающая доступность ресурсов на момент старта задачи.

Насколько точные у вас эстимейты?
Мы очень тщательно проанализировали проект и уверены в оценке.
А если у проекта будет фикс-прайс, вы готовы подписать такой контракт?
Упс...

Это логически неверный и манипулятивный вопрос. Между «проект займет 100 часов» и «проект стоит 100 гривен» находится еще несколько шагов, связанных с ресурсами, рисками и расписанием, закупками. В статье несколько раз совершен прыжок веры между часами и маржинальностью.

почему вы решили, что во фразе «проанализировали» не учтены ресурсы, риски и т.д.?

потому что дальше идет целая статья только о часах на исполнение

А почему вы считаете что эти вещи не связаны? Если мы говорим о подписании контракта, у нас уже есть готовая сумма, расчитанная на основании оценки проекта, подобранной команды (которая влияет на итоговую длительность проекта), и рейтов.
Нередкие случаи, что команда готовит эстимейты под T&M model, а потом не успеваем в заявленные сроки. И желание клиента подписать фикс прайс проект — не редкость. Поэтому когда мы учавствуем в тендере — желательно быть уверенными в своих оценках.

А где я написал, что вещи не связаны?
Еще раз по порядку. Я именно об этом и пишу, что задается вопрос об эстимейтах времени, потом вы начинаете говорить о «готовой сумме» ни откуда ни возьмись. Если хотели написать статью об оценках задач — нет проблем, но возникающие тут и там по ходу статьи деньги требуют дополнительного текста, откуда ж они взялись.

Даже сейчас вы пишете

команда готовит эстимейты под T&M model, а потом не успеваем в заявленные сроки.

Причем тут оценка активности задач к коряво составленному расписанию проекта? Один из вопросов, которые я часто задаю на собеседованиях — команда оценила проект на 100 часов, старт проекта 1 января. Через сколько будет поставка? 90% отвечают — через 100/8 дней, некоторые даже выходные забывают вычесть. Вот и тут все смешалось также.

Подытоживая, на мой взгляд, статья немного сумбурная.

Мне кажется, вы пропустили пункт о расчете длительности проекта.

Неможливо неправильно оцінити проект якщо дедлайн відсутній. ;)

Согласна :) И при этом бывают кейсы, когда клиент заявляет о необходимости реализовать весь скоуп и просит просчитать время, а уже только потом появляется дедлайн. И тогда мы возвращаемся к золотому треугольнику и обсуждаем что будет меняться при изменении времени: бюджет или скоуп работ.

В бізнесу немає необхідності в дедлайні. Звучить дивакувато, але з їхньої точки зору їм готове рішення потрібне ще на позавчора, та ваші дедлайни в якомусь там майбутньому не змінять вже нічого. Ви вже про*рали всі полімери, навіть не починавши думати про проект. Плюс, зараз потрібен MVP (minimal viable product), бо все змінюється швидко, що було актуальним позавчора, завтра може вже бути застарілим лєгасі. Ще нюанс, будь-який айтішний продукт лише автоматизує якийсь процес. Його можна виконати й без автоматизації, але це трохи довше або дорожче.

Смотря о каком бизнесе мы говорим. Если у клиента нет стратегического планирования на ближайший год-пять-семь, то скорее всего надо будет на позавчера. Тогда мы смотрим какой скоуп минимально нужно и можно сделать, чтобы он был жизнеспособным. Это стартовые условия.
При этом есть клиенты, которые планируют заранее, и у которых есть дедлайн: до какой даты мы должны выпустить продукт, который позволит быть конкурентноспособным на рынке. Этот продукт может быть не идеальным, но удовлетворяющим требования пользователей. В этом плане мне очень нравится книга «Психбольница в руках пациента».

Если у клиента нет стратегического планирования на ближайший год-пять-семь

Планування в сучасній економіці стало майже неефективним. Тим паче на такий довгостроковий термін, як 7 років. Тому все треба на позавчора.

При этом есть клиенты, которые планируют заранее, и у которых есть дедлайн: до какой даты мы должны выпустить продукт, который позволит быть конкурентноспособным на рынке.

Продукт особливо не впливає на конкурентоспроможність. Це може й було років 30 тому, але не зараз. Сучасний світ конкуренції виглядає трохи іншим, ніж десятки років тому. Зараз створюється ринок під продукт, а не навпаки. Простий приклад — спінери. Інший — фітнес-трекери.

думаю, одна из сложностей в том, что сначала клиенту презентуют процесс( «аджайл, гибкость, скрам — вы же слышали, правда? вот, у нас такое!» ) и обещают полный контроль. А потом уже обсуждают ограничения(например, фиксед скоуп или фиксед прайс). И менять процесс — гарантированно встретить аргумент «а ваши продажники мне обещали». Вот, и идут на «авось пронесет».

Почему на фиксед прайс проектах не использовать вотерфлов, зачем пихать агайл везде?

Потому что вотерфолл (классический, а не тот, которым клеймят и стращают религиозные адепты аджайла) работает только на небольших проектах на несколько сотен человеко-часов максимум. На больших масштабах просто невозможно один раз всё просчитать и запланировать.

С другой стороны, за всеобщей популяризацией аджайла забыли, что в основе того самого аджайла лежит итеративно-инкрементальный подход, прекрасно работающий и для так называемых plan-driven проектов, если только не заниматься неистовым отрицанием любого планирования наперёд как «вселенского зла».

Правильно приготовленный RUP из недавнего прошлого, или тот же Team Software Process вполне подойдут для фикс прайс проектов.

Более того, и сами аджайл методологии эволюционируют в сторону понимания того, что Scrum и Kanban подходят далеко не под все типы проектов, и что в каких-то случаях предсказуемость и правильная работа с рисками не менее важны, чем скорость поставки бизнес-ценности: disciplinedagiledelivery.com/...​ess/risk-value-lifecycle

На больших масштабах просто невозможно один раз всё просчитать и запланировать

Все залежить від кількості невідомих елементів. Якщо у вас детальна специфікація, можна запланувати на декілька людино-років — і все буде гаразд.

Не сочтите за троллинг, но это только по учебнику так. Даже самая хорошо написанная спецификация довольно быстро перестаёт быть адекватной реальным потребностям — по крайней мере, если мы говорим о разработке коммерческого софта. Термин и подход rolling wave planning ещё задолго до популяризации agile придумали умные люди и вовсе не зря.

Возможно, я вас удивлю, но итеративно-инкрементальный подход применялся ещё в конце 80х в СССР при разработке программного обеспечения бортовых ЭВМ спутников. И уже тогда на вотерфолл смотрели как на какой-то книжный академизм, который не взлетит в реальной жизни.

Нет, это был, конечно, не аджайл с двухнедельными спринтами, но итерации в 2-3 месяца работали очень даже хорошо.

Могу предположить, что там не в методологии дело.

комбинации фиксед прайз, низкого рейта и агайла

подозреваю, что два последних фактора тут играют решающее значение. Если «базис» в виде итеративно-инкрементального подхода более чем совместим с fix price и является одним из инструментов раннего обнаружения рисков, то «надстройка» в виде agile не совместима с fix price от слова «совсем», ибо попытка натянуть адаптивный подход на условия, где он не нужен и даже вреден — очевидно, приведёт к эпик фейлу.

Если же брать «абстрактный проект в вакууме», то:

Профессиональный бизнес-анализ, тщательная проработка и документирование требований.
Строжайший контроль change request’ов и предотвращение scope creep.
Качественный риск анализ с реально работающими и воплощающимися в жизнь стратегиями предотвращения и смягчения последствий рисков.

В идеале — фикс прайс на каждый этап.

Для ясності додам приклад. Якщо ми робимо емулятор x86 процесора — в нас є детальна специфікація по регістрам, структурі команд, адресації пам’яті й т.д. Таку задачу можна доволі точно оцінити та реалізувати, навіть якщо вона займе людино-роки. Бо невідомих елементів — мінімум.

Любопытный момент: а почему нефункциональные требования не прояснили на старте?

Да, слова аджайл мы тогда не знали, Дима :). Однако, было примерно так:

1. Были алгоритмисты (очень много), которые по стандарту, придуманному программерами, рисовали алгоритмы бортовой системы управления полетом КА (космического аппарата), исходя из его предназначения. Там было все и управление ориентацией объекта и коррекция орбиты и решение множества всяких служебных задач, включая управление многочисленными системами и устройствами аппарата. Алгоритмы рисовали сверху вниз — от самых высокоуровневых (типа дистетчера задач) до самых низовых. Начинали сверху — общая логическая схема режима функциониррования системы управления, согласовывали и сразу отдавали программерам. Потом переходили к детализации и по мере готовности отдавали программерам. При необходимости корректировали общую схему режима и тут же передавали ее программерам

2. Программеры работали параллельно с алгоритмистами. Их тоже было много. И они тоже выкатывали новые версии софта на комплексный стенд отработки практически раз в два дня. В крайнем случае — не реже раза в неделю. Новые вресии содержали пустышки в тех местах, где еще было не готово. К каждой версии прилагался список пунктов программы отработки, которые имело смысл прогонять на стенде. Здесь надо отметить, что программу отработки с описанием тест-кейсов выпускали и обновляли алгоритмисты по мере выкатывания алгоритмов. Таким образом тестировщики (испытатели) на комплексном стенде имели актуальный план действий.

3. Задача максимум тестировщика — установить, где дефект — в алгоритме или в коде. Тестирование было автоматизировано — специальная наземная ЭВМ в соответствии с пунктами программы отработки по своим алгоритмам запускала тестовые последовательности стимулирующих воздействий на датчики или их имитаторы, снимала с борта телеметрию и сравнивала с эталонными данными. Здесь надо отметить, что алгоритмы бортовой и наземной машин проверочной машин рисовали одни и те дже алгоритмисты. Они же придумывали все возможные и невозможные тестовые ситуации и включали их программу отработки системы управления. Поскольку поначалу ничего не работало либо вообще, либо работало не так, тестировщикам приходилось отыскивать — где ошибка. После того, как определили место ошибки — дефект отписывался в бортовом журнале испытаний и на стенд вызывали виновника торжества. Если своими силами отыскать не удавалось, вызывали алгоритмиста и он в бортжурнале писывал частную методику поиска отказа или брал вопрос на проработку до конкретной даты и давал рекомендации, как проводить испытания дальше с учетом этой проблемы. Учитывая темп поступления завершенных алгоритмов и программ, а также фиксы ранее обнаруженных дефектов, реально все работали параллельно. Особо отмечу — отыскание места ошибки было обязательно. Делать обходные маневры было запрещено. Изделие с невыясненными до конца причинами отказов при испытаниях к полету не допускались.

4. Пара слов об управлении проектом. Поскольку не только софт, но и железо для системы управления создавалось и изготавливалось на заводах параллельно, был общий сетевой график по изделию, в котором отражались обязательства многочисленных участников этого дела. Глобально было несколько клюевых вех, отражавших зрелость конечного продукта. От стендовых прототипов до финальной готовности к летным испытаниям таких этапов могло быть до десяти и больше. В конце каждого этапа выкатывался релиз полностью отработанного софта с ограниченным функционалом, необходимым для отработки задач следующего этапа. Весь функционал необходимый для летных испытаний появлялся только к финалу. Внутри каждого этапа, как я уже писал, функционал наращивался и отрабатывался инкрементально. Своего рода канбан... Надо также сказать, что вместе с софтом на комплексном стенде отрабатывалось и многочисленное железо, которое тоже делалось и доводилось до ума инкрементально от макета до пригодного к работе в условиях реального полета образца. Железо конечно релизилось реже... :)

Ну вот как то так... Даже не знаю, ка это назвать. Могу только подчеркнуть — сотни предприятий, участвовавших в создании космической техники все работали примерно так и по такому жизненному циклу. И параллельно, не дожидаясь, когда смежник закончит свою часть. Пользовались заглушками, макетами, матмоделями, но не стояли и не ждали готовых комплектующих. Можно ли это назвать ватерфолом? Не думаю...

И да — забыл отметить. Это был типичный Time & Material. Если где-то и было бюджетное ограничение, то ближе к пуску его все одно снимали. Премии и всякие стимулирующе-мотивирующие плюшки только росли...

У меня есть опыт успешного завершения вотерфольных проектов длительностью в год: в срок, в бюджет, и в скоуп. ПОэтому все зависит от уровня детализации, количества неизвестных \ неучтенных факторов, и просчетов зависимостей.

Это была именно разработка чего-то с нуля, или, например, интеграция / кастомизация?

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

Любопытно...А хороший опыт разработки чего-то подобного в прошлом у вас был?

И насколько стабильными / динамично изменяющимися были требования?

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

Я бы процентом буфера на и known & unknown unknowns померялся :) Кроме шуток, интересно знать, сколько закладывали, и как продавали заказчику.

У меня есть опыт успешного завершения вотерфольных проектов

А сколько всего их было и сколько проваленных? Люблю ПМ-ов, за умение обобщать по «одному» примеру. Это как обобщать выигрыш в лотерею. Хорошо бы знать процент успешности и реальную сложностью проектов. Ну и учитывая, что Вы (как и я) в аутсорсе, то будем честны, тут есть тенденция превращать месячные проекты в годовые и потом можно успешно вписаться в срок, в бюджет, и в скоуп. Поэтому, что Вы продали клиентам, как годовой проект, мало о чём говорит на самом деле. Ещё я видел как успешно «сданные» проекты клиенты потом не могли использовать. Много простора для скептицизма.

суть вопроса в том, как с агайлом комбинируется фиксед прайс

Никак. Если под «агайлом» понимать те методологии, которые обычно понимают под этим словом (Scrum, Kanban etc.). Они изначально были придуманы для совершенно других условий; по сути, Виктор очень ёмко эти условия описал:

Агайл создан для проектов, где ничего не известно и кастомер постоянно докидывает что-то

Очень чётко написали как раз. 👍
У себя я например в догонку сразу все предложения по идеализации (ака поиск лучшего решения) прошу набрасывать в беклог. Дальше уже ищем удобный случай продать это клиенту анализируя какая там будет ценность, попадёт ли в market fit и т.д.

Интересно, кто платит за такое счастье? :)

Легко комбинируется если верить тому же автору Скрама, где он предлагает фиксировать кол-во ФП на спринт, и позволять заказчику что-то докидывать только путём выбрасывания чего-то другого. Он это в книге еще смешно обозвал «бесплатными изменениями». На практике конечно такого я например не делал, тк даже перетасовка тасков между беклогом и активным спринтом всегда означает какие-то потери.

Точно! Иногда выбрасывание чего-то из продукта ведет к множественным переделкам в других местах. Ибо любая система — не есть простая сумма входящих в нее компонент. Впрочем, для многих менеджеров это не вполне очевидно... )))

Ну почему же везде? Я работаю и с вотерфол проектами.
Многие мои клиенты работают по вотерфол-аджайл. Т.е. сначала делается оценка по вотерфол проекту, но потом работаем «по скрам». И от того, как мы оценим проект в начале, будет зависеть успеем ли мы вообще в дедлайн, с учетом меняющегося скоупа. Тоже интересный опыт :)

Вотерфол — это когда дизайн не начинается, пока не утверждены все требования, а девелопмент не стартует, пока не утвержден весь дизайн, а тестирование не начинается, пока не готов весь код. Полагаю, реально это имеет место разве что в строительстве. Где колышек в землю не вобъешь без получения разрешения землеустроительных инстанций, а строительство не начнешь, пока не будет утверждена вся проектная документация, ну а дальше — понятно, нельзя строить 5-й этаж, до того, как будет построен четвертый :) .... Для фиксед прайс имеет значение только одно — чтобы требования, определяющие объем работ, были зафиксированы вместе с договорной ценой до начала работ. Подчеркиваю — до начала работ! И всякое изменение требований после старта проекта должно приводить к пересмотру бюджета и сроков. В этом вся суть фиксед прайса. К вотерфолу это не имеет ни малейшего отношения. Тем более, что более-менее детальный WBS, из которого вытекает бюджет и цена проекта, с самого начала включает эволюционный жизненный цикл со всеми возможными вариантами максимального распараллеливания работ.

Сторипойнт = длительность задачи × сложность задачи × неопределенность

Поправочка)
Story Points include:
* The amount of work to do — EFFORT
* Complexity of the work — COMPLEXITY
* Any risk or uncertainty in doing the work — RISK

Сторипоинт ну ни как не может в себя включать длительность задачи ;)

Підписатись на коментарі