У этой статьи есть две темы: первая - продемонстрировать фреймворк S.T.A.R. (Situation-Task-Action-Result), вторая – рассказать о моём опыте внедрения доски в цикл разработки технологий, позволяющий выполнять геофизическое исследование. Статья будет полезна для начинающих руководителей группы и тех, кто сталкивается с проблемами в приотизации задач.

STAR

STAR – это акроним от Situation, Task, Action, Result. Он отлично подходит для ответа во время технического интервью, позволяя быть сфокусированным. Например, вопрос может быть о примере ситуации в которой ты не успевал выполнить задачу в сжатый сроки, или о какой-нибудь твоей инициативе. По факту это план ответа:

Про STAR я узнал из этой статьи, но не стоит ограничивать зону применения только техническим интервью. Например, я использовал STAR для инфографики в момент презентации о внедрении приемочного тестирования. Ссылка на шаблон power point здесь.

И в этой статье раскрыть вторую тему мне поможет STAR, а заодно это будет примером использования.

Situation

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

Лето. Одновременно идут три проекта, в которых задействованы ещё две команды: группа по разработке электроники и группа по разработке прошивки (embedded developers). Руководители этих команд такие же начинающие тимлиды как и я: опыта у нас нет. По каждому из проектов мы собираемся отдельно на отчет. Сроки жмут, мы не успеваем. Проектные менеджеры перетягивают важность задач своего проекта.

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

Task

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

Action

Шаг 1. Уходим от трех независимых диаграм Гантта и вводим одну доску c задачами (Backlog, ToDo, In Progress, Pending, Done).
Шаг 2. Я актуализирую backlog, стараюсь максимально разбить крупные блоки на подзадачи. Насколько возможно оцениваю задачи в часах выполнения: (1, 2, 4, 8, 20, 40, 100). Во время оценки советуюсь с разработчиками. Задачи по разным проектам выделяю цветом.
Шаг 3. Текущая доска из odoo (erm-система), которой пользуемся не удобна в использовании, поэтому готовим список задач по необходимому минимуму улучшений. Вдохновение для этого черпаем из Trello. Например, я прошу внедрить сумму всех часов в колонке. В итоге доска становится похоже на эту:

Шаг4. Договариваемся, что собрание будет только одно один раз в неделю. На нем будут присутствовать сразу все заинтересованные менеджеры проектов. У нас будет лимит задач, который мы можем запланировать. Так в моей команде три разработчика и половинка меня. Значит в колонке ToDo после планирования на неделю должно быть задач на приблизительно 5дней * 8часов * 3.5людей = 140 часов. Кроме того, мы сразу обсуждаем задачи трех команд. Мы решаем, что важно сделать команде один сейчас, чтобы команда два смогла это использовать в след неделю и т.д.
Шаг5. В процессе планирования возникают конфликты приоритетов между проектами, поэтому последнее слово остается за одним единственным руководителем отдела R&D, и для меня приоритизация становится понятной и прозрачной. Я также не забываю про задачи поддержки кода, такие как переписывание legacy, убеждаю проектных менеджеров брать их периодически в ToDo.
Шаг6. На собраниях больше не обсуждаем кто конкретно из программистов будет заниматься такой-то задачей. Со своей стороны стараюсь увеличить bus factor и миксую задачи по проектам среди программистов. С некоторыми задачами лучше справляются конкретные программисты, но экспертизы в команде начинает хватать для того, чтобы любой мог выполнить хорошо почти любую задачу.
Шаг7. Договариваемся после того, как запланировали следующую неделю, уже не менять приоритетов. Однако, баги и задачи по поддержке уже выпушенных технологий чаще всего считаем самым высоким приоритетом и приостанавливаем текущий прогресс.
Шаг8. После нескольких недель смотрим насколько мы ошибаемся в оценке задачек. Начинаем понимать, что задачи, в которых задействованы кросс-команды требует больше времени. Периодически пересматриваем backlog, добавляем новые, удаляем неактуальные, выполняем дооценку.

Result

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

В конце хотел бы сказать спасибо книге Scrum (Джефф Сазерленд), благодаря которой родились шаги для решения нашей проблемы.

STAR о том как мы внедрили доску с задачам