Как правильно оценивать сроки выполнения задач программистами. Часть 1

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

Зачем нужны оценки сроков выполнения проекта

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

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

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

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

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

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

Если программиста спросить про дату, к которой частная задача будет выполнена, то он может дать некоторую оценку. Но опытные менеджеры умножают эту цифру на 2 или даже 3, а мудрые менеджеры после этого добавляют ещё 30%. Во второй части статьи мы обсудим, почему такой подход работает и почему программистам не нужно становиться более пессимистичными.

Тема планирования очень обширная. Я не готов давать исчерпывающее описание всего процесса планирования. Я не буду строить модели, рисовать графики и диаграммы, постараюсь не использовать много страшных слов. Статья будет сведена к оценке со стороны исполнителя, моему опыту, наблюдениям и советам, полученным от более опытных коллег.

Как планирование отражается в проектном цикле

Озвучивание требований по фиче

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

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

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

Верхнеуровневая оценка реализации фичи

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

В более сложных случаях исполнители могут дать высокоуровневую оценку вроде «Ну… денёк может быть уйдет», «Чёт ад прям» или «Если получится ‘А’, то hold my beer, иначе это долго». Такая оценка опирается на исторические данные или аналогии, с которыми сталкивался исполнитель. Обычно никто не ожидает, что эта оценка окажется точной.

Планирование сроков и состава фичи

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

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

Уточнённая оценка

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

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

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

Финализация требований

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

После такого решения ответственный за фичу со стороны разработки может внести коррективы в оценку. Распилить функциональность — удовольствие не бесплатное. Хотя обычно сроки нивелируются за счёт принятия быстрых реализаций в коде, раз уж принимаются меры менеджерами, можно пойти им на встречу. Главное, чтобы это не превратилось в привычку.

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

Синхронизация с майлстоунами

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

Ретроспектива

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

Заключение

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

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

Как вы оцениваете сроки выполнения разных задач?