x

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

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

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

Максим Шаламов
11-08-2021 12:56
Как правильно организовать работу со сроками
В последнее время я много собеседую PM и PO. И выделил одну общую проблему, которая встречается у большинства. Это работа со сроками.

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

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

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

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

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

Сейчас я расскажу о том как это работает у меня и как это можно адаптировать к различным конфигурациям.
Итак, разбиваем все поступающие требования условно по сложности и критичности. Постановку больших (делать больше 1,5 месяцев) и/или критичные фичи смотрю я (как CTO) и лидеры компетенций, которые будут задействованы (front, back и т.д.).
Цели у этого шага:
  • понять реализуемо ли это в текущих реалиях;
  • оценить полноту описаний;
  • если имеются ожидания по срокам, на начальном этапе их скорректировать. Например, если ожидается релиз через месяц, а делать минимум два, то нет смысла прорабатывать архитектуру фичи, декомпозировать на задачи, делать оценку и встраивать в роадмап. Нужно либо сразу корректировать ожидания, либо менять набор функциональности;
  • зафиксировать критичные для реализации вещи (например вместо удаления данных помечать их как удаленные, при выключенном интернете работать в офлайн режиме, требования для синхронизации данных между хранилищами и тд);
  • не отвлекать команду, на обсчитывание не утвержденных идей.
Важно: на этом этапе не выставляются точные сроки, можно лишь говорить о том насколько бизнес ожидания разумны.
Важно: делать прикидку от момента старта работ, а нет от момента начала обсуждения. Обсуждения затянутся, что повлечет сдвиг сроков и ненужные нервы.
В вашем случае вы должны использовать людей, которые понимают как устроен ваш проект и хорошо умеют прикидывать сроки (тим или техлиды).
Как только вы понимаете, что в целом задача понятна и ожидания по срокам приемлемые, алгоритм действий следующий:
  • все требования (естественно зафиксированные в письменном виде, как правильно описывать задачи можете почитать тут), передаются команде, чтобы каждый смог ознакомиться;
  • через пару дней собираемся в составе PO, команда, лидеры компетенций (если есть), где PO рассказывает всем о задаче и ожидаемом эффекте. Команда может задавать любые вопросы. На те, на которые нет ответа, записываются и забираются на доработку;
  • PO и аналитики отвечают на все вопросы, убеждаясь что команде все понятно;
  • дальше PM, техлиды и лидеры компетенций (если есть) делают декомпозицию требований на задачи, расставляют приоритеты задач и очередность выполнения. Обсуждают контракты в местах интеграций;
  • после чего проводится оценка задач всей командой (у нас сторипоинты и упрощенная версия покера);
  • затем составляется роадмап (если это новый проект), либо корректируется текущий роадмап;
  • бизнесу презентуется роадмап и либо берется в работу, либо возвращается на бизнес доработку с целью изменить постановку задачи для уменьшения сроков реализации.
С небольшими и не критичными фичами, все просто:
  • PM и тех\тимлид принимают постановку, задают вопросы и верхнеуровнево обсуждают возможности взять такую задачу и ее длительность;
  • согласовав верхнеуровневые детали, PM и тим/техлид(ы) декомпозируют постановку на задачи, определяют приоритет и порядок выполнения;
  • вся команда оценивает задачи;
  • корректируется роадмап проекта, который показывается PO, лидерам компетенций и CTO (если есть);
  • дальше работа ведется либо по роадмапу, либо постановка уходит на доработку.
Помните, что в команде каждый должен делать свое дело. Нужно доверять друг другу и расти вместе. Не надо пытаться по непонятным причинам делать работу других людей. Работайте как команда и все у вас получится.
Если у вас есть какие-то вопросы или пожелания вы можете воспользоваться формой для связи с нами:
Теги:
УправлениеAgile

Комментарии

Чтобы оставить комментарий, пожалуйста, авторизуйтесь

Подписывайтесь на обновления

Последние статьи из нашего блога