Добро пожаловать в Орос IT.
Please Войти!

Создать аккаунт

Главная/Блог/Как правильно организовать работу со сроками

Как правильно организовать работу со сроками

Максим Шаламов

11-08-2021 12:56

Как правильно организовать работу со сроками

В последнее время я много собеседую PM и PO. И выделил одну общую проблему, которая встречается у большинства. Это работа со сроками.

Как чаще всего выглядит работа со сроками

Как обычно это все выглядит: PO приносит задачу со сроками сверху, PM смотрит на нее и бьет на задачи, которые обычно сам и оценивает. Дальше уже людям (исполнителям) прилетают задачи с оценкой и дедлайном (кроме редких исследовательских задач). И что мы получаем? Обычно сорванные сроки, аврал и падение качества продукта, что в свою очередь еще больше замедлит выпуск нового функционала. Дальше споры по срокам, текучка и скатывание качества проекта на дно. Наверное бывают люди, которые умудряются в такой ситуации сохранять качество и попадать в сроки, но я таких не встречал. Все проекты, работающие по такой схеме, приходилось с большим трудом реанимировать или вообще переписывать. О нежелание людей работать над такими проектами и говорить не стоит. Давайте поговорим о том, как правильно работать со сроками. Полезно будет почитать всем.

Нельзя ставить сроки без команды

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

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

Вы работаете командой и каждый должен делать свое дело.

Как мои команды работают со сроками

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

Итак, разбиваем все поступающие требования условно по сложности и критичности. Постановку больших (делать больше 1,5 месяцев) и/или критичные фичи смотрю я (как CTO) и лидеры компетенций, которые будут задействованы (front, back и т.д.).

Цели у этого шага:

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

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

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

В вашем случае вы должны использовать людей, которые понимают как устроен ваш проект и хорошо умеют прикидывать сроки (тим или техлиды).

Как только вы понимаете, что в целом задача понятна и ожидания по срокам приемлемые, алгоритм действий следующий:

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

С небольшими и не критичными фичами, все просто:

PM и тех\тимлид принимают постановку, задают вопросы и верхнеуровнево обсуждают возможности взять такую задачу и ее длительность;
согласовав верхнеуровневые детали, PM и тим/техлид(ы) декомпозируют постановку на задачи, определяют приоритет и порядок выполнения;
вся команда оценивает задачи;
корректируется роадмап проекта, который показывается PO, лидерам компетенций и CTO (если есть);
дальше работа ведется либо по роадмапу, либо постановка уходит на доработку.

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

Если у вас остались вопросы, вы можете воспользоваться формой для связи или оставить комментарий ниже.

Теги:

Управление Agile