Как узнать дату завершения любого проекта. Метод путешественника
Пустой экран, на котором светится пустая таблица. Миллион идей в голове, но не понятно, как же их изложить. С утра руководитель дал задачу: посчитайте, когда мы закончим проект. Как это считать? Ещё и руководство требует как всегда «Срочно». И с какого потолка достать эту дату? Может, лучше рвануть в путешествие?..
Обычно подобными задачами занимается руководитель проекта. Но в нашей небольшой команде его не было. Придётся обходиться своими силами.
Какие только способы не шли в ход. Брали трудозатраты из задач предыдущего проекта, считали количество людей, какие задачи предстоит выполнять на каждом этапе проекта, учитывали отпуска... Мы убили целый день на то, чтобы сказать к вечеру начальству точную дату. Которая, конечно же, им не понравилась.
Мы практически ткнули пальцем в небо, чем подписались на большой риск. На эту дату будут завязаны договорные отношения с заказчиком. И при нарушении компании придётся выплатить немаленькие штрафы. Ну и прощай премия, если это твоя вина.
С тех пор прошли годы. Наш опыт пополнился разными способами оценки проектов. Как из теории, так и на практике. Мы, команда разработки Moroz Team, хотим поделиться простым подходом для вычисления даты завершения любого проекта.
Эта статья поможет вам определить дату завершения проекта прямо сейчас, повысить личную квалификацию в области оценок и улучшить свою репутацию в организации.
Отправимся в путешествие и найдём способы оценки проекта
Хотелось бы, конечно, отправиться в путешествие к морю и приключениям. Но в этот раз наше приключение будет поиском заветной даты. А нашим путешествием будет маршрут из точки А в точку Б.
Дата начала проекта — это точка А. Дата завершения — это конечная точка Б. А оценка проекта будет временем, которое нужно для преодоления маршрута.
Значит начать нам нужно с оценки маршрута. Т.е. нам нужно оценить объём работ, чтобы понимать, когда проект может быть завершён. Получим оценку, прибавим её к дате старта (к точке А) и получим заветную дату завершения проекта.
Как же узнать, сколько времени займёт весь маршрут?
Способ 1. Экспертная оценка
«Эй, водила, дорогу покажешь?» — можно спросить у таксиста, который знает каждую улочку в этом городе. Он подскажет самый быстрый способ добраться к цели на основе своего опыта.
В случае оценки проекта вы можете найти эксперта, который уже имеет большой опыт с аналогичными проектами. Важно, чтобы опыт был актуальным и действительно значимым.
Специалисты с большой базой опыта, знатоки своего дела обладают внутренней интуицией и чувствуют подводные камни. Так хирурги, которые провели сотни операций, могут с первого взгляда на пациента дать точный диагноз. И часто даже не могут объяснить на словах, как именно они это делают. Интуиция!
Плюсы и минусы:
+ Быстро
- Субъективно
- Сложно найти хорошего эксперта, который действительно будет заинтересован в качественной оценке
Советы:
- Дайте эксперту время на расчёт оценки. Так вы избежите импровизированной оценки и снизите степень субъективности
- По возможности привлеките несколько экспертов. Например, прогноз погоды из разных источников может дать вам больше уверенности в вопросе: нужно ли взять с собой в поездку зонт и резиновые сапоги.
Способ 2. На основе опыта
Вы или кто-то другой уже преодолевали подобный маршрут. А значит есть данные о том, сколько времени может занимать такой маршрут. Например, сервисы вроде Яндекс Карт, 2ГИС подскажут вам маршрут с учётом опыта других пользователей и собранных данных.
Иначе говоря, кто-то из вашей отрасли, вашей организации или даже ваша команда уже реализовывала похожий проект. Возьмите реальные данные из своего или чужого опыта. Чем ближе этот опыт непосредственно к вам, тем и точнее будет оценка.
Плюсы и минусы:
+ Более объективные данные, основанные на реальном опыте
+ Избавляет от необоснованного оптимизма, т.к. учитывает реальные узкие места
- Не для всех проектов по итогам учитывается реально затраченное время
- Оценка может быть неактуальна в текущих реалиях (от изменения состава команды до смены политической обстановки)
Советы:
- Пересчитайте оценку, опираясь на ваши текущие условия. Например, если изменился состав команды, используйте актуальную скорость команды.
- Опирайтесь не на воспоминания и предположения, а на реальные данные. Отчётность, данные из трекера задач или трудозатрат и др.
Способ 3. Расчётный
Самый сложный, но самый надёжный способ: это посчитать всё. Изучить карту, нарисовать свой маршрут, взять среднюю скорость, накинуть время на пробки, аварии, поиск места для парковки и другие препятствия на пути. Сложить всё вместе и получить ту самую оценку.
В теории существует много разных методик, практик и подходов. Но все они сводятся к простым шагам для расчёта оценки:
- определить состав задач
- оценить сложность каждой задачи
- помножить на скорость команды
- добавить накладные расходы
- рассчитать итоговую дату
Плюсы и минусы:
+ Выше точность
+ Индивидуальный подход именно к вашему проекту, вашей команде и ситуации
- Сложность расчёта, потраченное время
Шаг 1. Определить состав задач
Проще преодолеть путь, разбив его на шаги. И оценить проще небольшие куски маршрута, чем весь маршрут целиком.
Определите состав задач, необходимый для завершения проекта. Если в проекте участвуют несколько специалистов, советуем устроить обсуждение с командой. Ваши коллеги помогут убрать ненужные задачи и включить важные, которые вы могли упустить при самостоятельном планировании.
Чем меньше будут нарезаны задачи, тем проще вам будет их оценить. Для этого отлично подходит WBS — иерархическая структура работ проекта. Она представляет собой иерархию задач. Каждая большая задача делится на более мелкие до тех пор, пока последний уровень не станет понятным и простым для оценки.
В случае разработки ПО процесс определения списка задач не так прост. Нужно понимать потребности заказчика, понимать предметную область, составить требования, определить функциональную структуру и в идеале ещё и спроектировать хотя бы основную часть системы. Чем больше шагов вы пройдёте, тем точнее будет ваша оценка.
Советы:
- Мелкие задачи не только удобнее оценивать. Их оценка будет более объективной, точной
- Старайтесь на этом этапе не переполнять список «бантиками» (задачами, которые не позволяют достичь цели)
- Подумайте, какие задачи вы могли упустить. Обычно именно из-за таких и ломаются все расчёты. Посмотрите на предыдущие похожие проекты — они могут дать вам подсказку
Шаг 2. Оценить сложность каждой задачи
На вашем маршруте могут быть разные участки. Один ровный, чистый с ограничением в 100 км/ч. Другой настолько утоп в ямах и грязи, что преодолеть его можно только пешком в резиновых сапогах выше колена. Назначьте каждому участку свой уровень сложности. Другими словами, оцените сложность каждой задачи.
Задачи могут быть оценены в неделях, днях, часах или в условных величинах (например, в story point'ах). Выбирайте вариант, который ближе и понятнее вам. В одной из следующих статей расскажем, чем же лучше именно оценка в story point'ах. Если вам интересно, подпишитесь, чтобы не пропустить.
Дайте возможность оценить задачи тем, кто будет их делать. Оценка от специалиста точно будет ближе к реальности. В разработке ПО возьмите совет от Стива Макконнелла:
Советы:
- Составьте 2 варианта оценки: оптимистичную и пессимистичную. Так вы будете лучше понимать ситуацию. И реальный срок станет вам понятнее
- Если оценка задачи выглядит слишком большой, вернитесь на предыдущий шаг и по возможности разбейте её на более мелкие. После разбиения ваша оценка может сильно измениться (и чаще всего, в бóльшую сторону).
Шаг 3. Получить скорость команды
В случае преодоления маршрута скорость вашего передвижения может зависеть от способов передвижения. Пешком, на велосипеде, на метро или на автомобиле. А может даже на ракете или с помощью телепортации как в сериале «Звёздный путь».
В проекте ваш способ передвижения — это ресурсы вашей команды. Её скорость — это реальный объём выполненной работы за определённый промежуток времени.
Если вы не знаете скорость своей команды, вы можете:
1) получить скорость на основе имеющихся данных. Для этого стоит выполнить предыдущие шаги для оценки задач и посчитать, сколько сделала команда, например, за последнюю неделю.
2) рассчитать примерно. Например, в вашей команде 10 человек и каждый будет закрывать по 2 story point'а в день; или по 1 задаче на 4-6 часов.
3) провести пару этапов реальной работы над проектом и оценить скорость на основе этого опыта. Если у вас есть такая возможность, советуем ей воспользоваться мы и Майк Кон:
Советы
- Используйте реальные данные в приоритете. Только за их отсутствием обращайтесь к примерной оценке.
Шаг 4. Добавить накладные расходы
Если ваш путь долгий, то вы будете не только двигаться. Возможно, вам понадобится заехать на заправку, перекусить или даже поспать. А может придётся постоять в пробках или ваше средство передвижения сломается по пути.
В проекте всё то же самое: невозможно работать 8 часов в день каждый рабочий день. Встречи и общение с командой, отпуска, болезни, кофе-брейки или просто отсутствие вдохновения. Всё это может повлиять на процесс работы. Если, конечно, ваша команда не состоит из роботов, способных работать круглосуточно, или из одного чата GPT.
Не витайте в облаках и будьте реалистами. Учитывайте реальное время работы команды. Всё остальное (от 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 года! На это могут влиять разные факторы. Старайтесь их избегать:
- Хаотичный процесс работы, отсутствие организованности и согласованности действий
- Необоснованный оптимизм
- Пристрастие (намерение сместить оценку в ту или иную сторону)
- Субъективность и импровизированные оценки
- Бюджетные процессы, подрывающие эффективную оценку (особенно требующие согласования итогового бюджета в широкой части конуса неопределённости)
- Завышенные ожидания от применения новых средств или методов разработки
- Упрощение оценки при её передаче на верхние уровни управления, при формировании бюджета и т.д.
Не бойтесь ошибиться. Просто уточняйте оценку по мере появления новых знаний о нём.
Ну и в качестве позитивной нотки в заключение: поздравляю всех с днём рунета!)
А как же ChatGPT? Он же знает всё на свете. Спрашиваешь его: "У меня сложный проект, 10 человек в команде, пилим блокчейн на ноукоде" и он должен выдать нужную дату. Не так разве?
А то тут надо знать про WBS, накладные расходы и всё вот это из PMBoK...
Прежде чем рассчитать что-то, этот чат требует всё то же самое, что нужно и для самостоятельного расчёта. Да и его оценку я бы отнесла скорее к способу "на основе опыта", т.к. скорее всего он сделает свои выводы на основе скормленных ему данных. Посчитать самому будет точнее)
В России PMBoK не нужен - метод тыка работает лучше всего.))
когда же закончиться мой проект по безделью...
Если составить план и определить скорость, с которой безделье вам начинает надоедать, то можно получить дату) но при плохо исследованном внутреннем мире можем ошибиться где-то в 4 раза)
Хаха - безделье никогда не надоедает. Я ж говорю - нам PMBoK не нужен.))
Что делать, если в процессе проект разрастается с учетом новых хотелок от стейкхолдеров?
Главная задача проекта - это удовлетворить заказчика. Если хотелки позволяют закрыть его потребности и его удовлетворить, то принимать их с распростёртыми объятьями. А если они мешают этому процессу, то и такой вопрос решаемый. Всё зависит от установленных рамок, договоренностей и имеющихся ресурсов. Дата завершения может измениться, конечно, но и стейкхолдера-заказчика это может устраивать
Если речь про Agile или вообще продуктовый подход, где есть бэклог и степень неопределенности снижается очень медленно, то движуха там - это нормально.
В этом случае нет необходимости оценивать вообще все задачи и пытаться узнать дату завершения всего проекта. Мы узнаем только объем бэклога в текущем состоянии. Хотя груминг бэклога никто не отменял))
Но посчитать реальную длину спринта очень даже можно и нужно. А если ещё есть фикс этапы с датами, то тоже не помешает и там прицелиться.
Хорошо, что есть инструменты, которые помогают все эти хитрые рассветы делать точно и оперативно)
как-то лекцию ПМ яндекса слушал, у них там шутка (которая не шутка), что надо "серьезно, по науке расчитанную"оценку еще потом на число пи умножать, потому что проект пойдет не прямо, как по плану, а по дуге (такова жизнь))))
Да, у каждого свои приколы на этот счёт имеются) Видимо, Яндекс - не исключение
в бытности аспирантом запомнил поговорку, ходившую среди сотрудников: если ученый что-то обещает - дели на Пи, а время - умножай. а если большой ученый, то на Пи квадрат)
Многие любят эту константу. На Хабре тоже про неё говорят)
Когда на марсе жить начнем?
Думаю, что у товарища Маска есть уже план и подобная дата)
а я бы хотела завершить проект по поиску смысла жизни, пока она не закаончилась
Какие глубокие сегодня комментарии)
Может, это не конечная цель? Как у самурая: нет цели, есть только путь)
Интересно было бы поговорить об этом. Я был бы рад, если бы ты написала на аккаунт в телеграмм myushmi. Только напомни пожалуйста, что ты с vc. Наш разговор очень поможет развитию продукта, который мы сейчас создаем