Все хотят знать, сколько времени займёт проект. В этой статье мы объясним, как предоставить менеджеру одновременно точный и неопределённый прогноз, используя время цикла и подсчёт историй, а также дадим советы, когда следует вообще избегать оценки.
Селеста чувствовала давление. Её менеджер Барри хотел составить квартальный прогноз работы её команды. Задача усложнялась тем, что группа Селесты работала не над одним продуктом: Барри хотел получить прогноз сразу по трём. Каждый из них являлся частью другого проекта.
У программистов из группы Селесты не было достаточно информации для составления хоть какого-нибудь прогноза, тем более на целый квартал.
Селеста решила признаться Барри и посмотреть, к чему они придут. Она назначила встречу на следующий день и собрала данные.
Девушка прибыла в офис Барри ровно в 10 утра. Когда она постучала в дверь, Барри всё ещё говорил по телефону. Он жестом попросил её войти и поднял один палец, чтобы дать понять: он будет готов через минуту.
Она села в кресло для посетителей напротив его стола.
Барри повесил трубку и повернулся: «Что ж, обсудим сроки проектов, так?»
Селеста кивнула и сказала: «Да. Кажется, вот что можно сделать в такой ситуации».
Барри нахмурился: «Кажется? Мне нужны конкретные обязательства. Никаких „кажется”!»
Селеста села поудобнее: «Барри, на тебя давят, чтобы выпустить эти три продукта?»
«Как ты узнала? — Барри покачал головой. — Если послушать ребят из продаж и маркетинга, то случится катастрофа, если мы сейчас их не выпустим. Не знаю, что им ответить, кроме того, что всё будет».
«Но в прошлом месяце вы же обсуждали портфель проектов, — напомнила Селеста. — Я думала, продукт А был главным приоритетом».
«Так и есть, — сказал он. — И продукты B и C тоже являются главным приоритетом».
Селеста закатила глаза: «Но ты же знаешь, что может быть только один главный приоритет, не так ли?»
«Я это знаю, и ты знаешь, — сказал он. — Но мои коллеги не знают. Мне нужен прогноз, что ты можешь сделать — ну, обязательства — и тогда можно будет немного вздохнуть спокойно».
«Над каким продуктом нам работать в первую очередь?», — спросила Селеста.
«Продукт А, конечно, — сказал он. — Он самый окупаемый».
«Хорошо, вот что мы сделаем, — сказала Селеста. — Мы напряжёмся и выпустим А в течение месяца. Ваша задача — заставить этих милых людей посещать наши презентации каждую неделю. Они должны увидеть, что мы делаем за неделю. Если они не придут на демо, я отказываюсь давать им какую-либо информацию».
Барри откинулся назад: «Погоди. Я понял насчёт демо. А что в остальные два месяца? И почему ты не дашь им никакой информации?»
Селеста сказала: «Если бы мы работали только над одним продуктом, я могла бы рассчитать оценку на основе нашего цикла разработки. Для продукта А мы выпускаем три-четыре истории [код для пользовательских задач] в неделю. Но мы не знаем реального цикла разработки для продуктов B и C».
Барри кивнул: «Почему нет?»
«Продукты B и C запланированы через два и три месяца, — сказала Селеста. — Это довольно далеко для маркетинга. Проблема в том, что чем дальше работа, тем меньше „времени” отдел маркетинга работает с владельцем продукта для уточнения историй. Мы понятия не имеем, какие функции нужно будет реализовать через два и три месяца. Нам пришлось бы делать научно обоснованные предположения на пустом месте (scientific wild-ass guess, SWAG). Это нормально, мне нравится заниматься этим со своими ребятами, но нам нужно больше конкретики. Которой нет».
«Так почему ты дашь им никакой информации, если они не придут на демонострацию?» — спросил Барри.
«Если для них недостаточно важно наблюдать наш прогресс и обеспечить обратную связь, то им не слишком важна оценка по срокам, — сказала Селеста. — Они хотят, чтобы мы взяли на себя обязательства, не давая своих обязательств взамен. Почему я должна тратить время на оценку, если они не хотят вносить свой вклад?»
Барри согласился «продать» месячный «таймбокс» менеджерам, которые давят на него по установке сроков. Селеста будет следить, что команда сосредоточилась только на продукте A. И она назначила еженедельные встречи для демонстраций, чтобы команда показала свою работу и получила обратную связь.
Был бы у вас соблазн сделать всё иначе?
Оценка сроков — нетривиальная работа
Оценка сроков — это тоже работа. Многие команды закладывают проведение такой проуедуры в свой регулярный рабочий график. Тем не менее, точная оценка на квартал часто требует больше часа или двух работы.
Есть как минимум две проблемы оценки квартальной работы. Слишком часто требования не полностью определены и, как с командой Селесты, проведение оценки отрывает команду от срочной работы над проектом.
Проблема в том, что планирование разработки ПО не похоже на планирование дорожной поездки. Если в вашем городе больше одного светофора, то вы знакомы с колебаниями трафика. Я живу в пригороде Бостона, откуда поездка в аэропорт может занять и 20, и 90 минут. Чаще всего от 30 до 45 минут. Это существенная вариация для 13-километровой поездки.
И в такой поездке нет никаких инноваций. Я много раз ездила в аэропорт и знаю несколько способов добраться туда. У меня есть мобильные приложения, которые помогают найти самый быстрый маршрут даже по пути. Хотя некоторые варианты чуть более предсказуемые, ни один из них не может гарантировать, что эта конкретная поездка завершится за 20 минут.
Поездка в аэропорт происходит по предопределённому маршруту и с хорошо понятными препятствиями. Но разработка продукта — совсем другое дело. Это инновации. Другими словами, раньше мы не делали ничего подобного. Если бы было иначе, то нам не пришлось бы писать новое приложение или обновлять устаревшую систему — мы бы использовали старую.
Для разумной оценки у нас несколько вариантов. На самом деле три:
- Можно оценить порядок величины. Считаю, что это полезно для всего проекта. «Мы предполагаем от пяти до девяти месяцев работы. Узнаем лучше, когда ответим на эти вопросы и закончим эту часть сложной работы». SWAG хорошо подходит для таких оценок.
- Можно собрать достаточно информации о требованиях и предоставить разумную оценку. Команде может понадобиться поработать с пользовательскими историями, чтобы сделать прогноз с достаточно малым разбросом по времени.
- Есть вариант оценить работу на короткий отрезок, например, на неделю-две. Может оказаться, что итоговый прогноз не совсем правильный. Но обычно он достаточно близок к результату, чтобы не разочаровать людей, которые попросили сделать его.
Какой прогноз нужен менеджеру?
Я заметила, что менеджерам часто нужна оценка порядка величины. В этом случае команда может сделать прогноз и сообщить его следующим образом:
«Мы считаем, что этот проект займёт пять месяцев с 50% уверенностью в точности этого прогноза. В оценке восемь месяцев мы уверены на 80%. Десять месяцев — это 90% уверенности».
Это помогает менеджерам понять, что существует диапазон доверия. Если они хотят 100% уверенности, то для этого может потребоваться срок более 14 месяцев.
Можете использовать метод спирали: «Мы ориентируемся на первый квартал следующего года. Не знаем, когда именно в первом квартале, но думаем, что справимся». По мере продвижения проекта уточняете: «Обновляем оценку на срок где-то между серединой января и серединой марта». Узнав ещё больше, говорите: «Где-то в феврале, если не случится метели». Потом в январе можете сказать: «Третья неделя февраля».
Я бы ещё рекомендовала диапазон из трёх дат: «Оптимистичная дата — январь. Самая реалистичная — конец февраля. Самая пессимистичная — конец апреля».
В любом случае никогда не давайте однозначной оценки. Это искушает Святого Мерфи (из закона Мерфи) заняться вашим проектом и наделать гадостей.
В некоторых случаях и в некоторых командах заказчику могут потребоваться дополнительные сведения. Здесь вы можете обсудить с ним конкретные реализуемые функции, чтобы понять неопределённости.
Используйте время цикла вместо оценки
Я вообще не люблю прогнозы по сроку выполнения программных проектов или других IT-проектов, особенно Agile. Вместо этого предпочитаю, чтобы команда выпускала очень маленькие истории или оценивала работу по времени цикла.
Если вы не знакомы с терминологий:
- Пользовательские истории описывают, как клиент или пользователь использует продукт с одной функциональной целью («Хочу забронировать место» или «Нужно опубликовать данные умного города для удовлетворения требований прозрачности»). Истории отличаются от взгляда разработчика, который смотрит на продукт с точки зрения баз данных и API.
- Время цикла относится к общему времени, которое требуется команде для выпуска работы над одной историей. Это включает в себя и активное время разработки, и время простоя, когда работа чего-то ожидает.
Идея в том, чтобы понять среднее время, нужное для выпуска чего-то полезного (истории).
В случае Селесты она знала, что команда может выпускать от трёх до четырёх историй в неделю для продукта A. Для многих команд подсчёт историй работает так же, как другие методы оценки.
Если команда никогда не работала над подобным продуктом, то предыдущее время цикла не будет применимо к этому новому продукту. Команда может не знать, как уточнять и дробить истории, чтобы выпускать по нескольку в неделю. Кроме того, она может не знать о состоянии кода и наличии достаточного количества тестов. Если ваша команда работает над историями больше трёх дней, не утруждайте себя прогнозом. Сосчитайте истории и не пытайтесь сделать больше, чем обычно.
Когда команда начала справляться с историями за один-два дня, вы тоже не обязаны делать оценку. Часто простой подсчёт легче и более точен.
Почему бы не использовать скорость?
Вы заметили, что я рекомендую время цикла и подсчёт историй, а не скорость работы для оценки времени проекта. Потому что скорость — суррогатная величина.
Например, я каждый день хожу пешком, чтобы поддерживать себя в форме. Я иду по тому же маршруту каждый день, отслеживая свою относительную скорость. В хороший солнечный день я прохожу около 5,6 км в час. В дождливый или жаркий и влажный день скорость падает до 4 км/ч. В снег или гололёд могу вообще не выйти на улицу, в этом случае моя скорость равна 0.
Я иду по тому же маршруту. (Да, это скучно, но это моя проблема). Хотя я прохожу одинаковое расстояние, дорога занимает разное время в зависимости от условий. Здесь условия аналогичны кодовой базе и тестам вашей команды.
Если истории достаточно малы, скорость соответствует времени цикла. Но слишком часто менеджеры пытаются дать оценку для проектов с очень большими историями. Подсчёт будет проще: «Мы можем закончить одну или две истории за цикл. Какую одну или две истории вы хотите выбрать?»
Отказаться от оценки — это не обман
Когда Барри обсудил вопросы с коллегами, один из них заявил: «Отказаться от оценки сроков — это жульничество!»
Барри ответил: «Неправда. Вы же хотите, чтобы мы выпустили продукт, верно?»
Ответ был «Конечно. И B, и C».
«Проблема в том, что их нужно делать по очереди, — ответил Барри. — Если вам так нужен продукт А, какой смысл делать прогноз по остальным? Мы можем приступить к работе и показать наш прогресс. Когда мы сделаем достаточно, то повторим процедуру для B и C. К тому же, у вас будет время уточнить требования для B и С, чтобы подготовить нам истории».
Команда Селесты завершила основную часть проекта А за один месяц. Выпуск продукта B занял больше времени — ближе к двум месяцам. И поскольку компания получила достаточный доход от выпуска продуктов А и В, то снизила давление по выпуску продукта С.
Знайте, какая оценка нужна вашему менеджеру. Преподнесите её так, как ему нужно. И если у вас мало времени, приступайте к работе.
Оценка IT-проектов: уроки
- Не указывайте ни одной конкретной цифры или даты. Вместо этого дайте оценку порядка величины с указанием уверенности в своевременном выпуске. Или предложите краткосрочные оценки, основанные на факторах, находящихся под вашим контролем.
- Разделите задачи проекта на пользовательские истории, определяющие функциональность программного обеспечения. Затем сделайте свои оценки на основе количества пользовательских историй, которые вы можете обработать.
- Убедитесь, что вы понимаете требования, прежде чем брать на себя какие-либо обязательства.
Автор: m1rko
