Как сэкономить до 2-3 часов в день руководителям от рутины микроменеджмента? Как синхронизировать команды, чтобы стейкхолдеры понимали, кто чем занимается?

Как минимизировать вероятность появления хаоса в проекте разработки и не скатиться в бездну технического долга?

Своим опытом автоматизации рабочих процессов делится Олег Пузанов — Co-founder и CSO в Mad Devs.

Олег 15 лет программирует и управляет бизнесом. Он также имеет большой опыт работы в качестве основателя стартапов в Центральной и Юго-Восточной Азии.

В Mad Devs отвечает за стратегическое развитие: непрерывное обучение команд, поиск новых ниш и направлений для развития компании, отслеживание современных тенденций в технологиях.

Олег Пузанов экспериментирует с разными подходами в развитии бизнеса, создавая конкурентные преимущества на основе знаний и навыков команды. Об одном из таких подходов он и расскажет в этой статье.

Обратите также внимание на другие материалы Kraftblick.Media по теме:

Как в Netpeak 7 лет управляют отделом продаж на удаленке: контроль, общение, мотивация, корпоративная культура.
Как сократить время на обсуждения и митинги? Опыт построения визуальной коммуникации в Genesis.
Как убедиться, что все члены вашей маркетинговой команды четко понимают цель и направление работы.
Как сервисно-продуктовая компания автоматизировала ключевые процессы, выросла до 250 человек за 4 года и считает рентабельность в один клик. Опыт Symfa Inc. Часть 1.

В этой статье вы прочитаете:

• Как мы автоматизировали асинхронные стендапы
• Как с помощью ворклогов анализируем работу команд и выявляем проблемные места
• Как мы настроили Базовые Процессы Разработки ПО и алертинг

Как мы автоматизировали асинхронные стендапы

Процессы в Mad Devs строились по remote-first подходу с самого основания компании в 2016 году, т.е. еще до того, как это стало мейнстримом в IT.

Команды были гибридными, а разница во времени с некоторыми коллегами могла достигать до 14 часов.

И чтобы и сотрудники, и стейкхолдеры понимали, кто чем занимается и могли делиться между собой информацией, одной асинхронной коммуникации было мало.

Так возникла необходимость обеспечить прозрачность процессов. О том, как была решена эта задача, мы и поговорим далее.

Итак, для слаженной работы распределенной команды или группы команд мы обозначили несколько важных принципов:

1. Синхронизация действий каждого участника и оповещение о проблемах — это асинхронные текстовые стендапы и напоминания о них.
2. Учет затраченного на работу времени — это ворклоги и аналитика по ним.

Используя подход “все ходы записаны”, мы обеспечиваем и поощряем прозрачность, а показывая открыто, куда уходит время, мы можем в любой момент заглянуть в ворклоги в прошлом, чтобы понять что и когда было реализовано.

Начну с синхронизации.

Как стендап-бот облегчил работу команды

В идеальном мире команды собираются на стендап во время звонка либо встречаются в оффлайне. Но чтобы проводить их регулярно, все члены команды должны быть в офисе (или онлайн) единовременно.

Когда в команде больше 5-7 человек и находятся они в разных странах, в разных часовых поясах и начинают свой рабочий день в разное время, единовременные стендапы практически нереальны, даже с учетом Google Meet и Zoom.

Например, в одном из наших крупных проектов, над которым мы работаем более 5 лет, есть специалисты из Южной Кореи, США, Польши, Украины и Кыргызстана. Как их свести воедино?

Как показывает практика, мы не первые, кто столкнулся с такой проблемой, и решение писать асинхронные стендапы было придумано до нас.

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

На тот период (2016 год) уже был Geekbot, которым мы и пользовались, а других хороших альтернатив не было.

Но этот бот только развивался и имел проблемы, которые нам периодически мешали. Например, пока сотрудники писали стендап, их могло просто выкинуть из приложения, либо оплата не проходила.

Поэтому было принято решение разработать собственный стендап-бот — Comedian.

Задачи, которые он должен был выполнять: в поверхностной конкретике оповестить команду о том, что делаем, получить обратную связь от коллег и ответить себе/команде на вопрос “а не занимаюсь ли я бесполезными делами?”

Т.е. бот должен синхронизировать усилия команды без лишних звонков или встреч, экономя общее время. И он с ним прекрасно справляется до сих пор.

Сейчас бот является частью большой системы, о которой дальше пойдет речь, но его первоначальная версия доступна в open source, как и другие наши проекты.

В бесплатной версии бот не имеет ограничений по пользователям и умеет:

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

Для некоторых команд такой простой бот — это бесплатная альтернатива Geekbot или Standuply, у которых есть лимиты на количество пользователей.

Изучить и самостоятельно использовать бота можно по этой ссылке.

Как с помощью ворклогов анализируем работу команд и выявляем проблемные места

Как мы настроили Базовые Процессы Разработки ПО и алертинг

Привыкнув регулярно писать стендапы и вести учет рабочего времени, команды усваивают самые базовые процессы работы. Мы их называем Базовыми Процессами Разработки Программного Обеспечения (далее БПРПО).

В них входят:

• Перелинковка задач, коммитов, веток и merge requests.
• Отражение реальных статусов задач.
• Регулярное фиксирование потраченного времени.
• Синхронизация планов относительно командных целей и т. д.

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

Таким образом нашими менеджерами устанавливается регламент работы, который контролирует:

1. Дедлайн на сдачу стендапов (в зависимости от часового пояса).
2. Ворклоги каждые N часов, с лимитом по времени максимум в N часов.
3. Соблюдение воркфлоу на Jira доске. Например, оповещения о том, какие задачи находятся долго в одном статусе или без ворклогов.
4. Адекватное ведение работы с кодом, с репозиторием и с процессом поставки кода.

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

Как это проверить? А как узнать о последствиях нарушений правил работы? Для этого мы создали настраиваемые алерты.

Алерты на ранних стадиях уведомляют наши проектные команды о постепенно возникающих проблемах в проекте в виде коротких сообщений.

Грубо говоря, это наш тимлид, который не спит и работает 24/7, потому что это не человек.

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

Система алертинга проработана, чтобы служить команде всесторонне, а не узконаправленно. Здесь используется не тот метод, когда “внимание, поймали нарушителя”, а проактивный подход, который плавно доносит команде, что определенные аспекты работы можно оптимизировать.

Ниже мы прикрепили скрины некоторых алертов, где определяется, все ли идет в правильном направлении.

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

И тогда уже сама команда предлагает варианты исправления ситуации. Когда люди знают о проблемах, они пытаются не только отреагировать на них, но и придумать решения, которые повлияют на проект лучшим образом.

Путем настройки алертов мы устанавливаем стандарты работы для целого отдела/проекта. В момент получения сообщения о “нарушениях” мы можем увидеть, насколько наша команда согласна следовать стандартам и были ли они реалистичны.

Если они не были настроены адекватным образом, то у коллектива есть возможность собраться и сообщить, кто с чем не согласен, а потом зафиксировать новые договоренности.

С помощью алертов мы можем следить не только за процессами, связанными со стендапами и ворклогами, но и за кодовой реализацией работ.

Система может также мониторить следующие процессы:

• отчет за вчера/неделю о коммитах в Slack
• забытые merge requests
• коммиты и ветки без ссылки на задачу
• задачи в прогрессе без ворклогов
• зависшие задачи в разных статусах
• приближение к лимиту по часам из Scope of Work и т.д.

Вот примеры некоторых алертов, которые мы используем в проектах:

Многие из “незначительных” проблем, с которыми сталкиваются компании, часто являются отражением более серьезных препятствий.

Когда проектные команды регулярно пишут асинхронные стендапы и ведут учет времени, у них появляется возможность следить именно за теми самыми “незначительными” недостатками в работе над проектом и узнать, на что обратить больше внимания.

Алерты в том числе и высвобождают время менеджеров от операционных задач.

Пытаясь следить за сроками, объемом работ и возможностью укладываться в бюджет, руководитель попадает в ловушку и часто не замечает, как закопался в операционных задачах.

Следить абсолютно за всем, что происходит, невозможно, но и перестать это делать было бы неверным решением.

В век автоматизации вручную анализировать огромный поток информации слишком ресурсозатратно. В этот самый момент алерты играют роль правой руки менеджера, автоматически раскрывая узкие места в работе.

Менеджер может анализировать алерты в виде отчетов, графиков и рекомендаций, т.к. они подсвечивают то, что нарушает процессы.

А во второй части материала мы расскажем о том, как научились определять стоимость будущей фичи и прогнозировать скорость сгорания финансов в проекте, а также заранее определять будущую убыточность проекта и принимать меры по пересмотру рейтов для клиента.