Это документ, описывающий процесс командной разработки, который я написал на своей первой менеджерской позиции, через полтора месяца работы. Привожу в оригинале, убрав только одну главу, относящуюся целиком к работе конкретной компании.
(21.12.2020)
“Образ будущего” - это различные отдельные аспекты целевого состояния наших процессов и принципов работы.
Описание носит фрагментарный, а не исчерпывающий характер и призвано показать в общих чертах ту концепцию взаимодействия, к которой я двигаю систему.
Это нужно, чтобы другие тоже могли ознакомиться, задать свои вопросы, внести правки и пожелания.
Визуализация и скрытая работа:
Большая часть процессов визуализирована в Jira
Скрытая работа минимальна
Результаты фиксируются в задачах или комментариях
Колонки на досках носят однозначный и понятный характер
Исполнители задач стараются самостоятельно, без указки и напоминаний, поддерживать актуальный статус своих задач
Мы сходимся во мнении, что приведенная в порядок, понятная доска - это гораздо удобнее, чем постоянно отвечать на вопросы о том, каков статус задачи
Децентрализованное взаимодействие в команде:
За исключением колонки to do, на доске почти нет задач, у которых нет исполнителя
Задачи переходят от исполнителя к исполнителю, каждый следующий знает, у кого он взял задачу, и у кого уточнять детали
В случае возникновения проблем, все стараются напрямую связаться и выяснить необходимую информацию
Уточненную на словах информацию фиксируют комментарием в задаче
Децентрализованное взаимодействие в команде №2:
Тестировщик знает, кто работал над задачей, которую он тестирует, в случае необходимости задает вопросы напрямую
Обнаружив баги и составив их список, тестировщик передает задачу конкретному разработчику, который над ней работал
Разработчики берут свои задачи из reopen самостоятельно, без указания тимлида или иного менеджера
Разработчики стараются всегда, когда это возможно, решать задачи, вернувшиеся из тестирования, в приоритете над плановыми задачами
Снижение коммуникационных издержек:
Рабочие вопросы, которые можно решить без руководителя/руководителей, решаются напрямую между коллегами на местах
То, что можно решить без совещания - решается без совещания
Если краткий созвон/прямой диалог/переписка на 5 минут с двумя-тремя людьми позволяет обойтись без совещания - мы предпочитаем сделать именно так
Если решение вопроса через комментарии в задаче затягивается, мы предпочитаем связаться напрямую и обговорить всё, а не ждать ответов. Результаты таких обсуждений мы фиксируем в комментарии
Мы используем разовые совещания для организации совместного обсуждения 3 и более лиц по спорным вопросам, и в таких совещаниях мы заранее уведомляем участников о том, что будет обсуждаться
Мы используем регулярные совещания, если это самый удобный инструмент для решения регулярно возникающих вопросов (актуализация статусов проектов, отчет о проделанной работе и т.п.)
Мы не используем совещания ради совещаний, или чтобы просто все были в курсе, что делают другие. Для этого мы используем другие инструменты (демо, презентации, встречи по обмену опытом и т.д.)
Разделение сфер ответственности:
Колонки на досках разделены таким образом, что не перемешиваются сферы ответственности
Все точно знают, за какие колонки они отвечают
Все имеют общее представление о том, кто отвечает за другие колонки
Разработчикам и тестировщикам понятно, где находятся задачи для них, если они освободились, и какую брать следующую, без вопросов к руководителю
На досках нет областей (колонок, бэклога и т.п.), за которые не отвечает никто, или отвечают сразу все
Разделение сфер ответственности №2:
Мы сходимся во мнении, что лучше всего организованная команда - это та, в которой рабочие вопросы решаются и без руководства
Мы стремимся к тому, чтобы для ежедневной работы требовалось минимум микроменеджмента или чтобы он не нужен был вовсе
Разработчики самостоятельно несут ответственность за свои задачи и ведут их через весь цикл от “To Do” до “Done”
Тимлиды поручают выполнение задач из To Do, занимаются кадровыми, организационными и административными вопросами, архитектурными вопросами и технической валидацией задач, но не контролируют вручную задачи отдела во всех колонках доски
Product owner’ы отвечают за продуктовые гипотезы и идеи, за проработку, постановку и приемку задачи
Product owner’ы в общем случае не руководят процессами разработки и не участвуют в них
PO получают развернутую информацию о ходе разработки в том случае, если есть плановые сроки и они нарушаются
Крупные проекты и кросс-командные задачи:
В крупных проектах и задачах, особенно если они включают работу сразу нескольких отделов, требуется роль проектного менеджера
Проектным менеджером могут выступать PO, team lead одного из задействованных отделов, проектный менеджер, аналитик или иной сотрудник, вплоть до разработчика, который определен как компетентный для данного проекта, и готов взять на себя ответственность за координацию работ по проекту
Для того, чтобы PM/PO были в курсе хода выполнения многокомпонентных задач или задач из другого отдела, мы организуем краткие регулярные планерки-статусы (полчаса и менее, раз в неделю)
Крупные и кросс-командные задачи мы объединяем в одну иерархию таким образом, чтобы все подзадачи проекта были связаны с корневой задачей, в которой содержится бизнес-постановка
Для крупных кросс-командных проектов мы практикуем создание временных рабочих групп из сотрудников разных отделов, которые активно координируют работу друг с другом напрямую (сидя рядом, в общем чате проекта или иным удобным способом)
(восьмой пункт я скрыл, так как он относится к локальным особенностям бизнеса той компании, к тому как готовится постановка задач, у кого визируются изменения по безопасности и т.п.)
Постановка задач в разработку:
Мы стараемся придерживаться общих правил/рекомендаций в описании задач
Общие правила/рекомендации по описанию задач задокументированы в виде памятки или инструкции
Мы не завышаем приоритеты своих задач, понимая, что таким образом мы мешаем другим и можем нанести ущерб результатам общей работы
Заказчики понимают смысл приоритета и несут ответственность за выставленный приоритет
В основном, мы берем задачи в работу в порядке выставленного приоритета
Мы можем отходить от приоритета в рамках здравого смысла, например, когда приоритет задачи меньше, но ее можно сделать очень быстро
Работа с ошибками и инцидентами:
Инциденты устраняются в порядке приоритетов
Смысл приоритетов отражен в инструкции/памятке, нам понятен их смысл
Устраняя симптомы проблемы, мы всегда стараемся найти и устранить источник проблемы, чтобы она не повторялась
Если фундаментально решить проблему сейчас не получается, мы регистрируем задачу на фундаментальное решение, связываем ее с задачей по устранению симптомов и добавляем в эпик по оптимизации работы
Мы не бросаем задачи по фундаментальному решению проблем, а возвращаемся к ним через эпик по оптимизации, когда появляется возможность
В том, чтобы фундаментально решать проблемы и меньше заниматься рутиной заинтересованы как разработчики, так и владельцы продуктов
Демотивация и мотивация:
Лиды проводят one-2-one встречи с сотрудниками своего отдела, узнают их потребности, предложения, высказывают вопросы к их работе лично, а не публично
Управляющий персонал заботится о том, чтобы оградить рядовых сотрудников от демотивирующих факторов, которые мешают их работе:
Ущерб профессиональной гордости
Ущерб репутации отдела
Несправедливость по отношению к сотруднику или к кому-то из его коллег
Негатив от руководства
Необоснованные требования и давление
Нарушение договоренностей, особенно в финансовых вопросах
Явная нечестность и лицемерие
Невостребованность результатов труда
Мы профессиональны и не используем работу и особенно положение руководителя для того, чтобы самореализоваться на чьем-то фоне, обидеть или унизить кого-то
Мы готовы помочь другим разобраться с их проблемами, даже если это не входит в наши прямые обязанности