У этой статьи есть две темы: первая - продемонстрировать фреймворк 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 (Джефф Сазерленд), благодаря которой родились шаги для решения нашей проблемы.
