Планирование — важная задача не только для тимлида или менеджера. Часто разработчику приходится отвечать на вопрос «когда это будет готово?».
В этой заметке я хотел бы разобрать подходы, которые эффективно использовать в ситуациях, когда что-то должно быть сделано кем-то к какому-то сроку. Например, выпуск релиза с фичей или передача готового функционала другой команде для интеграции. Или другая команда меняет структуру базы данных в соответствии со своими планами, и вам надо заранее к этому подготовиться. Или заканчивается поддержка старого интерфейса в совместно используемой библиотеке. То есть некие события в будущем, к которым нам надо что-то сделать на своей стороне. Но вообще, приёмы, которые я предлагаю в этой статье, подходят ко многим проектам, не только в разработке.
Есть несколько разновидностей вопроса «когда это будет готово?». Простые, например: «Когда нам нужно начать, чтобы успеть к концу ноября?». Или посложнее: «Можем ли мы подключить ещё разработчиков, чтобы успеть раньше?». Этот вариант мы тоже разберем.
Проблемы у разработчика начинаются уже с интерпретации вопроса. «Готово» — это готово к использованию, а не «почти готово». То есть, сделана реализация, есть тесты, проведена отладка, пройдено ревью, собран фидбек. Значит, для ответа на наш вопрос надо заложить все эти стадии тоже. Обычно разработчик отвечает что-то типа: «Будет готово, когда будет готово», — и аргументирует это тем, что много «неопределенности». ОК, а как тогда анонсировать фичи клиентам, заключать контракты, синхронизировать работу между командами и в целом вести бизнес, если по каждой фиче много «неопределенности»?
Другой вариант, не сильно лучше, — разработчик дает некую случайную оценку и менеджер умножает ее на три, чтобы подстраховаться.
При этом, в повседневной жизни люди прекрасно справляются с планированием. Например, не опаздывают на самолет. Но ведь там тоже много «неопределенности»: пробки на дороге, очереди в аэропорту. Давайте попробуем разобрать этот пример.
Итак, у нас есть «что» должно быть сделано — посадка на самолет, и «когда» — определенное время вылета. Вы не можете быть «почти» в самолете, когда он вылетает. Вы либо там, либо нет. Также вы не можете пройти мимо паспортного контроля. То есть, существуют некие стадии, которые нельзя проигнорировать. Точно так же, как тестирование и отладку нельзя выкинуть из скоупа работ по разработке.
ОК, попробуем прикинуть время прохождения паспортного контроля и других стадий в аэропорту. На каждой стадии есть «неопределенность». Например, размер очереди вы не знаете заранее. Учтем этот риск и заложим некий запас, исходя из худшего варианта. Так же поступаем и с другими стадиями.
Затем мы вычитаем из времени посадки на самолет время, которое мы заложили на прохождение всех стадий в аэропорту. Получаем майлстоун, который можно будет легко отслеживать — оптимальное время прибытия в аэропорт.
Далее нам надо определить, во сколько нужно выехать, чтобы попасть в аэропорт в это время. На дорогу тоже закладываем буфер, исходя из худшего варианта. Получаем время, когда нужно выехать.
Выходит такая схема: берем известное событие, например, дату релиза, и откладываем назад все стадии, которые надо выполнить, добавляя буферы на риски. Получаем дату начала работ.
Почему я предлагаю отсчитывать с конца? Во-первых, во многих случаях у нас есть дата или диапазон дат для окончания работ, и мы можем от этого отсчитывать. Во-вторых, важно сделать фокус на «последней миле» — это как раз те этапы, на которых проект (или задача) становится из «почти готового» «готовым». Эти этапы обычно расположены в конце цепочки (кстати, это еще один повод определить критерии готовности).
Наш пример с самолетом — это простой случай с одним исполнителем. Стадии были последовательны. Исполнитель не уйдет в отпуск в середине пути и не переключится на другой проект. Да и степень неопределенности все же была достаточно низкая. Но все же можно сделать еще некоторые наблюдения:
Проект в целом может быть новым для вас, но при этом состоять из частей, понятных для оценки. Например, часть «добраться до аэропорта» не сильно отличается от других случаев, когда надо доехать до какого-то места к определенному сроку. Поэтому, поделив проект на стадии, часть из них можно точно оценить на основе своего прошлого опыта.
Величина буферов зависит от цены неуспеха всего проекта. Например, я бы заложил x2 на дорогу в аэропорт. Но при этом в большинстве других ситуаций такой запас не нужен. Определяйте буферы соразмерно рискам не только отдельных стадий, но и проекта целиком.
Для некоторых стадий возможны запасные варианты. Например, альтернативные маршруты до аэропорта. Это тоже способ снижения рисков.
Составив свой план, вы можете определить зависимости от других исполнителей. Например, такси можно заказать заранее, к моменту выезда.
А теперь давайте усложним эту модель.
Во-первых, у нас может не быть конечной даты. Наоборот, нам надо ее определить в ходе планирования. В таком случае подход прежний, но мы не отсчитываем от какой-то точки, а просто складываем длительности всех стадий с учетом буферов и получаем общую длительность работ. Например, два месяца.
В этом случае не так важно, откуда отсчитывать стадии, с начала или с конца. Но я предлагаю делать это с конца, чтобы держать фокус на результате проекта.
Также у нас могут быть зависимости и ресурсы, необходимые для начала работ. Например, нужен исполнитель, а он пока занят на другой задаче. И еще мы можем ждать чего-то от другой команды. В этом случае мы узнаем дату, когда все необходимое для начала будет готово, добавляем некоторый буфер, потому что и тут могут быть задержки.
Если работаем в спринтах, то округляем, сдвигаем дату на начало следующего спринта. Прибавляем длительность работ и получаем предполагаемую дату окончания проекта.
Во-вторых, если проект длительный, то на него скорее всего наложатся другие задачи и отпуска. Чтобы уменьшить негативный эффект, можно планировать работы так, чтобы отпуск или другие задачи находились между стадиями, а не перекрывали их. Например, как в случае спринтов, округляем в большую сторону, сдвигая начало следующей стадии вправо. Может быть, исполнитель начнет задачу и до отпуска, но в планировании разумно исходить из худшего возможного варианта.
В-третьих, зависимости от других команд могут потребоваться не только для начала работ, но и позже, во время работы над проектом. Подход тот же — договариваемся о сроке, добавляем запас, выстраиваем работы под этот срок. В процессе периодически проверяем статус зависимостей.
Будет хорошо, если получится провести раннюю интеграцию с промежуточной версией. Это тоже можно обсудить на этапе планирования. Так мы обнаружим проблему заранее, и её исправление меньше повлияет на сроки поставки.
В-четвертых, на проекте может быть несколько исполнителей. Определите стадии, работа по которым может идти независимо. Их можно будет выполнять параллельно. Синхронизация и планирование делаются также, как в случае с зависимостями от других команд.
А может быть и другая ситуация, когда какие-то из этапов будут проходить через исполнителя, который станет бутылочным горлышком из-за своей загруженности. Это тоже надо учесть на этапе планирования. Например, можно попробовать заранее договориться об окне времени для вашего проекта. Либо придется заложить время на ожидание в очереди.
В-пятых, неопределенность бывает действительно высокой, но ее можно попробовать снизить. Например:
Планировать разные варианты реализации. Если не сработает основная гипотеза, то будет запасная.
Сузить область неопределенности. Вычленить те части, которые более понятны, чтобы сфокусироваться на анализе непонятных.
Провести прототипирование для проверки гипотезы, чтобы отбросить нерабочий вариант как можно раньше. Прототипирование может быть, как отдельным шагом в проекте, так и подготовительным, до начала проекта. Разница заключается в рисках — либо мы должны заранее проверить реализуемость проекта в целом, либо можем это отложить на более поздний срок.
Давайте подытожим. Вот основные шаги, которые стоит соблюдать при планировании проекта:
Определить критерии готовности.
Составить список стадий и майлстоунов. Можно это сделать, начиная с конца проекта.
Оценить каждую стадию. Добавить буфер для каждой стадии. Подбирать буфер с учетом рисков для стадии и для проекта в целом.
Определить зависимости между стадиями, спланировать параллельную работу с учетом этих зависимостей.
Выявить боттлнеки.
Заложить отпуска и переключения исполнителей на другие проекты.
Определить необходимые ресурсы и зависимости для начала работ, а также зависимости, нужные в процессе работы над проектом. Добавить их в план.
Да, существуют проекты, в которых гораздо больше неизвестных. А может быть, даже заранее неизвестна конечная цель и есть только направление. И в эту простую схему такие проекты не вписываются. Но проблемы с планированием встречаются и на более простых проектах, где изначально понятно, что надо сделать и примерно понятно, как сделать.
И еще один важный момент. Подготовить план недостаточно, важно контролировать его выполнение в процессе работы. Для этого и нужны майлстоуны. Они помогают увидеть проблему вовремя и внести корректировки в план по ходу работы. Например, что-то упростить, убрать из скоупа, попробовать переключить людей с других проектов или разгрузить исполнителей, сняв с них второстепенные задачи. К тому же, люди болеют или берут незапланированные отпуска. Под это тоже надо адаптировать план по ходу работы.
Основное, что я хотел сказать в этой заметке — планирование проекта строится на трех навыках: декомпозиции, анализе зависимостей и анализе рисков. Из них самый сложный, на мой взгляд, — это анализ рисков. И здесь у меня, к сожалению, нет какой-то готовой рекомендации, кроме как учиться на ошибках, своих и чужих.
Давайте хотя бы начнем думать о возможных рисках и тогда планирование будет более реалистичным. А при реалистичном планировании и результат будет ближе к ожиданиям.
Комментарии (18)
sshikov
18.11.2024 13:10Я удивляюсь, как можно писать о планировании работ, и вообще не упомянуть диаграмму Ганта? То есть, вы планируете, планируете - и даже не представляете, какие у вас зависимости между задачами? И даже не пытаетесь визуализировать, где у вас критический путь? И применить готовый софт типа MS Project, который вполне может учитывать многие упомянутые параметры.
Определить зависимости между стадиями, спланировать параллельную работу с учетом этих зависимостей.
Ну т.е. вот же, прямо оно. Неужели сейчас этому вообще не учат (меня этому учили в институте, причем я учился на инженера)?
peterzh
18.11.2024 13:10разработчик не знает, что такое Гантт, например. У него все зависимости в трекере проставлены)
а статья вполне работает для всех, кто дает сроки
MikeAlexeev Автор
18.11.2024 13:10Давайте чуть шире посмотрим на ситуацию. Я думаю, что у среднего разработчика нет навыков планирования. С этой проблемой я сталкиваюсь постоянно. И я хотел сформулировать некоторый минимальный, но достаточный набор приемов, которые можно брать и использовать.
Диаграмма Ганта, книги Голдратта и т.д. - это важно, но я хотел рассказать наиболее просто. И чтобы применить можно было даже к небольшой задаче. Ведь там тоже часто бывают промашки по срокам. Я не думаю, что софт типа MS Project стоит использовать, когда разработчику надо назвать срок готовности фичи, состоящей из трех-пяти задач.
Да, какие-то моменты в статье были под чуть больший масштаб, на вырост. Но я думаю это неплохо, когда логика планирования прозрачна для всех участников команды.Если же планирование является основной работой, как, допустим, у проджект-менеджера, то врядли ему поможет статья типа этой
sshikov
18.11.2024 13:10Ну давайте я чуть иначе выскажусь - на мой взгляд диаграмма Ганта это просто. И MS Project тоже. До определенного предела конечно - когда вы не занимаетесь рисками, т.е. не считаете вероятности, например. То что вы хотели еще дальше упростить - это все норм.
И когда у вас пять задач - то вероятно вам и критический путь очевиден без диаграммы. Но само понятие критического пути - это ведь тоже просто. Ну т.е. раз уж вы упомянули, что нужно определить зависимости, почему не визуализировать их в виде Ганта?
В общем, мой вопрос - он скорее из области образования. Почему в мое время простых инженеров учили планировать на коленке и рисовать Ганта (MS Project еще не существовал как класс), а нынешних простых разработчиков не учат? Может потому и навыков планирования нет, что не учат базе?
peterzh
18.11.2024 13:10хорошая статья, че минусуют? Все по делу. немного много букв, но кто сможет дочитает и сделает хотя бы половину из написанного, получит профит :)
про самолет образ понравился. Главное в неопаздывании на самолет - это как часто вы им летаете. Было время, я все время летал. У меня была сумка, которую я мог собрать за 10 минут - и я на пути в аэропорт. Аэроэкспресс по расписанию, контроль - точно к посадке, чтобы было не надо ждать и захожу последним, чтобы не топтаться в рукаве.
Все было рассчитано точно, до копеечки. И достигнуто было, увы не теорией, а только практикой. Вот и учи разработчиков и менеджеров не опаздывать теперь. Учу учу, а все равно продалбывают :)
G0ran
18.11.2024 13:10Пример с не опаздывают на самолет мне кажется немного скрывающий или упрощающий поднимаемую в статье проблему. Сама по себе эта задача уже является решенной и в ней все шаги (дорога в аэропорт, очередь на вход в аэропорт, паспортный контроль) известны и всего лишь нужно оценить понятные риски каждого шага, заложить буферы.
В разработке же мы довольно часто встречаемся с задачами, где порой не очень понятно под какие риски закладывать буферы и вообще какие риски сыграют роль в процессе реализации. При этом оценка первоначальная всё же ожидается, иначе, процитирую: а как тогда анонсировать фичи клиентам, заключать контракты... .
Хорошей практикой является, по возможности, давать оценивать задачи тому что ближе и лучше знаком с её контекстом, подводными камнями и у кого более полная картина о том что нужно вообще будет сделать.
MikeAlexeev Автор
18.11.2024 13:10Хорошей практикой является, по возможности, давать оценивать задачи тому что ближе и лучше знаком с её контекстом, подводными камнями и у кого более полная картина о том что нужно вообще будет сделать.
Да, но добавлю, что может быть и другой подход - оценивающий собирает подробности у тех, кто знаком с предметной областью, и строит план на основе этого. Почему так? Навыки планирования могут быть развиты у одного, а с предметной областью работает другой и за деревьями он не видит леса. Да и если проект крупный, то экспертов может быть несколько, а план в итоге один надо составить
zloddey
18.11.2024 13:10Более того, в сложных окружениях задачи вообще ведут себя фрактальным образом: любой шажок, который изначально казался совсем маленьким и простым, может резко вырасти в размерах и стать едва ли не больше изначальной оценки всей задачи. А потом ещё один шажок, и другой...
Не все подводные камни удаётся находить заранее, хотя в целом практика очень полезная.
MikeAlexeev Автор
18.11.2024 13:10Некоторый инструментарий все же у нас есть и на этот случай
Прототипирование. То есть некий дешёвый вариант проверить идею и увидеть проблемы или, наоборот, повысить уверенность и начать финальную реализацию
-
Ранняя интеграция, чтобы все компоненты можно было соединить как можно раньше и собрать фидбэк или вообще увидеть, что получается
100-процентной гарантии это конечно не даёт, но шансы на успех должно повысить. Я наверно дополню немного статью, спасибо
Shersh
18.11.2024 13:10Какой же неудачный пример с самолетом…
Давайте по другому, я даю вам задачу, вам надо приехать в Мухосранск и привезти 25 кг груза с собой, и ресурсов даю 10к рублей, и теперь задам вопрос «когда будет готово?»
Неизвестно летают ли самолеты в Мухосранск, сколько стоят билеты, сколько за багаж, есть ли самолеты рядом с Мухосранском и сколько там стоит и как оттуда добраться до Мухосранска, а может проще вообще на машине своей доехать…
MikeAlexeev Автор
18.11.2024 13:10Хорошо, что Вы приводите контрпример. Но является ли Ваш случай обычным или скорее исключением? У любого подхода есть область оптимального применения, и есть ограничения. Я указал это в статье:
Да, существуют проекты, в которых гораздо больше неизвестных
В Вашем примере с городом N надо собрать больше информации, например, связаться с кем-то из его жителей. В данном случае это и будет эксперт по проблеме, подскажет Вам варианты, как добраться. На основе этой информации построите план.
Любо провести эксперимент или серию экспериментов. Это подход, который предлагается для запутанных систем по модели Кеневин. Серия экспериментов не вписывается в бюджет, поэтому давайте лучше уточним информацию у жителей города N
Shersh
18.11.2024 13:10По личном моему опыту, это как раз обычный пример любого разработчика выше уровня middle.
В данном случае это и будет эксперт по проблеме, подскажет Вам варианты, как добраться. На основе этой информации построите план.
Хорошо. Вы построили план, согласовали его и потом выясняется что
* груз быстро-размораживаемый
* его нельзя везти самолетом по санпин нормам
И да, это выясняется уже во-время выполнения плана. И все прогнозы "когда это будет готово" уже не работают :)
Примерно в таком мире живут разработчики.
Я сознательно не беру здесь примеры с простейшими задачами, которые можно поставить на конвейер.MikeAlexeev Автор
18.11.2024 13:10Если работа связана с транспортировкой грузов, то наверно участники процесса должны знать, что существуют разные виды грузов со своими требованиям. Это часть профессии. В варианте, когда сегодня маляр, завтра экспедитор, потом кто-то ещё действительно будет много не учтенных рисков и план не сработает.
Что дальше? Исполнитель на полпути сломает ногу и из этого надо сделать вывод, что планирование не работает?
Я предложил способы, которые работали на разных проектах, в разных компаниях. Такого опыта, как Вы описываете, у меня не было. Бывало всякое, но как-то находились варианты.
Как Вы сами справляетесь с такими трудностями?
S-type
18.11.2024 13:10А как можно оценить время на разработку?
Проект в целом может быть новым для вас, но при этом состоять из частей, понятных для оценки.
Очень расплывчато. Что значит "понятных для оценки". Если речь про транспортную логистику, то всегда можно открыть карту с дорогой и вычислить путь с точностью до километра, можно посмотреть статистику по пробкам. А если разрабатывать программу - то карты нет! Что бы открыть код и сказать "ваша хотелка будет реализована через такое то время" понадобиться ... время. И, как показывает практика, "время на оценку времени" сопоставимо с "временем реализации" хотелки.
Иногда слышу "но, ты ведь делал что то подобное? давай будем считать, что время будет такое же". Но, если добавили какую то фичу для одного места программы (например, для документа определённого типа), абсолютно не факт, что это время будет как то сопоставимо с добавлением такой же фичи для других места программы. В других местах программы реализация такой же (с точки зрения пользователя) фичи может по сложности (и по времени) быть в разы больше или меньше.
MikeAlexeev Автор
18.11.2024 13:10Это хорошее замечание. Возможно стоит пересмотреть архитектуру или дизайн кода, если текущая реализация не соответствует новым требованиям. Я думаю, что это обычная история, когда существующую кодовую базу надо переосмыслить
То есть если ситуация, описанная Вами, повторяется регулярно, то это может быть симптомом.
Это я без всякого сарказма, если что. Сам регулярно сталкиваюсь с тем, что оценки по какой-то части продукта хронически неверные. Это повод подумать над рефакторингом
S-type
18.11.2024 13:10Из всего вышесказанного так и не понял:
А как можно оценить время на разработку?
Есть какая то чёткая методика - как взять код, и узнать время его исправления? На мой взгляд - такой методики нет. Есть только два пути - гадание и разбор кода. Анекдот помните - за постучать 5 копеек, а за то, что знать, где постучать - 5 рублей. Вот разбор кода, это, по сути, и есть выяснения места, где именно надо постучать.
И да, метод "гадания" очень нравится руководству.
AdrianoVisoccini
У меня ни разу не было такого, чтобы я планировал успеть на самолет к 15 часам, и был готов к тому что возникнет пробка, однако оказалось что пробка на конкретном участке МКАД устаревшей версии, если её апдейтить то аэропорт пропадает полностью и вместо него пустое поле, а если не апдейтить то при стоянии в пробке больше часа вылетает таймаут....