Привет! Я хочу рассказать про свой опыт в самоорганизующейся команде. За полтора года в ней было от 3 до 5 разработчиков, я не занимался их наймом, но все процессы и разработку построил с нуля. Расскажу, что такое самоорганизующаяся команда, какую пользу она приносит для компании, команды, и ее участников.
Самоорганизующаяся команда
В команде нет разделения на специализации, роли и кого-либо кроме разработчиков. Нет отдельных людей на клиент (front-end), сервер (back-end), инфраструктуру, тестирование, управление проектами. Каждый разработчик участвует в каждой итерации цикла разработки программного обеспечения: получение задачи, прояснение требований, написание кода, тестирование, развертывание, мониторинг, поддержка. Задачи распределяются таким образом, чтобы не образовывалось экспертов в какой-то области.
Команда сама выбирает технологии, занимается их исследованием (насчет релевантности, например), внедрением и поддержкой — Go или Python, Jenkins или Github Actions, нужен ли Kubernetes. Критериями для выбора технологий могут быть: размер проект, скорость разработки, хочется ли команде разнообразия в работе, смогут ли его поддерживать новые разработчики в будущем (интерес к технологии у общества, количество специалистов, популярность).
Составление бэклога, приоритизация задач и подзадач, распределение задач между участниками команды, митинги, ретроспективы — ответственность команды.
В задачи руководителя команды, помимо участия в разработке, входит: мотивировать и заботиться об участниках, убирать препятствия на пути команды, улучшать процессы.
Еще о процессах
Хочу описать процессы, которые не относятся напрямую к самоорганизующимся командам, но относятся к командам вообще. Но их было в разы быстрее, эффективнее и приятнее настраивать и соблюдать именно в самоорганизующейся команде.
В команде не было ежедневных митингов по рабочим моментам и ретроспектив. Я стремился сделать разработку прозрачной и документированной, как будто мы на удаленной работе без возможности созвониться, даже находясь в офисе. Описание пулл реквестов с объяснениями и примерами, документация процессов, инструментов, технологий и гайдов.
Не было 1-to-1 митингов, хотелось иметь мгновенную обратную связь. О том, что кому-то что-то не нравится или нравится — было правило сообщать сразу, не только руководителю команды, а и всем ее участникам. Я старался выстроить процесс открытости и ранней обратной связи. Сообщать о проблемах, важных новостях и изменениях нужно сразу. Если к тебе подходит один из разработчиков и хочет уволиться по каким-то причинам, которые он мог бы обсудить намного раньше (и следовательно попытаться решить), стоит задуматься над его компетенцией (или желанием, или seniority). Это ментально сложный процесс, людям свойственно «забивать», можно спросить первым, и если кому-то найдется что-то ответить, напомнить, что он должен был сообщить сам.
Тоже самое с дедлайнами и эстимейтами — только когда это действительно необходимо, ведь работа делается за весь отведенный на нее срок.
Для постановки задач нет отдельного человека, либо это звонок с командой, либо сообщение в соответствующий канал связи (почта, чат) на всех участников команды.
Классно иметь модель ветвления по типу Trunk-based, когда код сразу попадает на сервера, нет отдельных веток для пред-master (develop) и релизов как это предусматривает GitFlow Workflow. У нас была одна ветка master, если пулл реквест смерджился, значит, тесты написаны, функциональность проверена на deploy preview (feature branch, review app) — ничего не затягивается. Один пулл реквест — один коммит в master — один релиз.
Плюсы
Для разработчика быть в такой команде значит:
заниматься разными задачами, используя разные технологии в разных областях, а это не скучно и развитие в ширину,
приобретается понимание всего цикла разработки программного обеспечения,
растет ответственность за проделанную работу, так как работа не «скидывается» на других людей на промежуточных этапах (тестирование, развертывание, мониторинг).
Для команды и компании:
каждый может поучаствовать в прояснении требований к задачам, технических и архитектурных решениях, что привносит видение ситуации с разных сторон,
нет проблем с отпуском, больничным, увольнением и уходом, так как нет задач или участков программного обеспечения, в котором разбирается только один разработчик,
нет проблем с переходом на удаленную работу команды, если это необходимо.
Минусы
Не всем разработчикам комфортно в самоорганизующейся команде, кому-то не интересно развиваться в ширину, кто-то привык к меньшей ответственности на работе.
Ценности при разработке, от банального стиля кодирования, до инструментов и технологий. Чем больше зона ответственности у разработчика, тем больше у него убеждений на тот или иной счет. Ценности конфликтуют в любых командах, особенно в начале разработки. А в самоорганизующихся и подавно, ведь спектр задач и технологий у каждого из разработчиков шире. Конфликты и недопонимания неизбежны, важно находить win-win решения (либо компромиссы), открыто решать проблему, чтобы ни у кого не оставалось обиды за спиной.
Непривычно для менеджмента и бизнес-людей — они привыкли к общению по задачам и прогрессу только с руководителем команды.
Вывод
Я сделал следующий вывод для себя:
участники команды разносторонне развиваются, поэтому получают удовольствие от процессов и работы,
на каждом участнике команды лежит одинаковая ответственность, это сплачивает и приносит результат.
Спасибо за внимание, буду обновлять статью, если что-то забыл упомянуть. Если у вас есть вопросы или вы хотите что-то обсудить, жду в комментариях или личных сообщениях.
