Пустой экран, на котором светится пустая таблица. Миллион идей в голове, но не понятно, как же их изложить. С утра руководитель дал задачу: посчитайте, когда мы закончим проект. Как это считать? Ещё и руководство требует как всегда «Срочно». И с какого потолка достать эту дату? Может, лучше рвануть в путешествие?..

Обычно подобными задачами занимается руководитель проекта. Но в нашей небольшой команде его не было. Придётся обходиться своими силами.

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

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

С тех пор прошли годы. Наш опыт пополнился разными способами оценки проектов. Как из теории, так и на практике. Мы, команда разработки Moroz Team, хотим поделиться простым подходом для вычисления даты завершения любого проекта.

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

Отправимся в путешествие и найдём способы оценки проекта

Хотелось бы, конечно, отправиться в путешествие к морю и приключениям. Но в этот раз наше приключение будет поиском заветной даты. А нашим путешествием будет маршрут из точки А в точку Б. 

Дата начала проекта — это точка А. Дата завершения — это конечная точка Б. А оценка проекта будет временем, которое нужно для преодоления маршрута.

Значит начать нам нужно с оценки маршрута. Т.е. нам нужно оценить объём работ, чтобы понимать, когда проект может быть завершён. Получим оценку, прибавим её к дате старта (к точке А) и получим заветную дату завершения проекта.

Как же узнать, сколько времени займёт весь маршрут?

Способ 1. Экспертная оценка

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

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

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

Плюсы и минусы:

+ Быстро

- Субъективно 

- Сложно найти хорошего эксперта, который действительно будет заинтересован в качественной оценке

Советы:

• Дайте эксперту время на расчёт оценки. Так вы избежите импровизированной оценки и снизите степень субъективности

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

Способ 2. На основе опыта

Вы или кто-то другой уже преодолевали подобный маршрут. А значит есть данные о том, сколько времени может занимать такой маршрут. Например, сервисы вроде Яндекс Карт, 2ГИС подскажут вам маршрут с учётом опыта других пользователей и собранных данных.

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

Плюсы и минусы:

+ Более объективные данные, основанные на реальном опыте

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

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

- Оценка может быть неактуальна в текущих реалиях (от изменения состава команды до смены политической обстановки)

Советы:

• Пересчитайте оценку, опираясь на ваши текущие условия. Например, если изменился состав команды, используйте актуальную скорость команды.

• Опирайтесь не на воспоминания и предположения, а на реальные данные. Отчётность, данные из трекера задач или трудозатрат и др.

Способ 3. Расчётный

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

В теории существует много разных методик, практик и подходов. Но все они сводятся к простым шагам для расчёта оценки:

1. определить состав задач

2. оценить сложность каждой задачи

3. помножить на скорость команды

4. добавить накладные расходы

5. рассчитать итоговую дату

Плюсы и минусы:

+ Выше точность

+ Индивидуальный подход именно к вашему проекту, вашей команде и ситуации

- Сложность расчёта, потраченное время

1. Определить состав задач

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

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

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

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

Советы:

• Мелкие задачи не только удобнее оценивать. Их оценка будет более объективной, точной

• Старайтесь на этом этапе не переполнять список «бантиками» (задачами, которые не позволяют достичь цели)

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

2. Оценить сложность каждой задачи

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

Задачи могут быть оценены в неделях, днях, часах или в условных величинах (например, в story point'ах). Выбирайте вариант, который ближе и понятнее вам. В одной из следующих статей расскажем, чем же лучше именно оценка в story point'ах. Если вам интересно, подпишитесь, чтобы не пропустить.

Дайте возможность оценить задачи тем, кто будет их делать. Оценка от специалиста точно будет ближе к реальности. В разработке ПО возьмите совет от Стива Макконнелла:

Не уменьшайте оценки, полученные от разработчиков, — скорее вceгo, они и без того излишне оптимистичны.

Стив Макконнелл «Сколько стоит программный проект»

Советы:

• Составьте 2 варианта оценки: оптимистичную и пессимистичную. Так вы будете лучше понимать ситуацию. И реальный срок станет вам понятнее

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

3. Получить скорость команды

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

В проекте ваш способ передвижения — это ресурсы вашей команды. Её скорость — это реальный объём выполненной работы за определённый промежуток времени. 

Если вы не знаете скорость своей команды, вы можете:

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

2. рассчитать примерно. Например, в вашей команде 10 человек и каждый будет закрывать по 2 story point'а в день; или по 1 задаче на 4-6 часов.

3. провести пару этапов реальной работы над проектом и оценить скорость на основе этого опыта. Если у вас есть такая возможность, советуем ей воспользоваться мы и Майк Кон:

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

Майк Кон «Agile оценка и планирование проектов»

Совет:

• Используйте реальные данные в приоритете. Только за их отсутствием обращайтесь к примерной оценке.

4. Добавить накладные расходы

Если ваш путь долгий, то вы будете не только двигаться. Возможно, вам понадобится заехать на заправку, перекусить или даже поспать. А может придётся постоять в пробках или ваше средство передвижения сломается по пути.

В проекте всё то же самое: невозможно работать 8 часов в день каждый рабочий день. Встречи и общение с командой, отпуска, болезни, кофе-брейки или просто отсутствие вдохновения. Всё это может повлиять на процесс работы. Если, конечно, ваша команда не состоит из роботов, способных работать круглосуточно, или из одного чата GPT.

По моим наблюдениям и по мнению моих коллег, большинство работников, полностью занятых в проекте, могут уделять проекту от четырех до шести часов в день. Это соответствует данным о том, что участники уделяют работе над проектом от 55 % (Ganssle, 2004) до 70 % (Boehm, 1981) своего времени. Самый высокий показатель, по данным Кеннеди (Kennedy, 2003), у инженеров компании Toyota, где высокоэффективный процесс бережливого производства позволяет посвящать работе над целевым проектом до 80 % времени.

Майк Кон «Agile оценка и планирование проектов»

Не витайте в облаках и будьте реалистами. Учитывайте реальное время работы команды. Всё остальное (от 20 до 50%) — это накладные расходы.

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

Советы:

• Посмотрите график отпусков сотрудников в вашей команде. Сразу добавьте их к накладным расходам

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

5. Рассчитать итоговую дату

Зная скорость и путь (объём проекта), сможем рассчитать время по известной нам со школьных времён формуле: t = s / v

И добавим к ней наши накладные расходы. Пусть это будет x

Тогда можем посчитать так: t = s / v + x

Например, в моём проекте получилось 40 задач с общей оценкой в 80 story point'ах. Это мой объём, s.

Скорость моей команды, v = 20 sp в неделю.

В итоге по времени получилось 4 недели.

Добавлю 25% в качестве накладных расходов. И получу 5 недель. Ура!

Начало проекта + 5 недель = моя желанная дата завершения проекта.

Да, мы посчитали дату. Но это не точно

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

На этапе исходной концепции ваша оценка может ошибаться в 4 раза. Представьте, что вы оценили проект в 1 год. Реальной оценкой может стать 4 года! На это могут влиять разные факторы. Старайтесь их избегать:

• Хаотичный процесс работы, отсутствие организованности и согласованности действий

• Необоснованный оптимизм

• Пристрастие (намерение сместить оценку в ту или иную сторону)

• Субъективность и импровизированные оценки

• Бюджетные процессы, подрывающие эффективную оценку (особенно требующие согласования итогового бюджета в широкой части конуса неопределённости)

• Завышенные ожидания от применения новых средств или методов разработки

• Упрощение оценки при её передаче на верхние уровни управления, при формировании бюджета и т.д.

Не бойтесь ошибиться. Просто уточняйте оценку по мере появления новых знаний о нём.

Ну и в качестве позитивной нотки в заключение: поздравляю всех с прошедшим днём рунета! :-)