Как IT компании построить прозрачные процессы, чтобы у стейкхолдеров не возникало вопросов, куда потрачены деньги. Опыт Mad Devs (130+ человек). Часть 1
Как сэкономить до 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 часов.
И чтобы и сотрудники, и стейкхолдеры понимали, кто чем занимается и могли делиться между собой информацией, одной асинхронной коммуникации было мало.
Так возникла необходимость обеспечить прозрачность процессов. О том, как была решена эта задача, мы и поговорим далее.
Итак, для слаженной работы распределенной команды или группы команд мы обозначили несколько важных принципов:
- Синхронизация действий каждого участника и оповещение о проблемах — это асинхронные текстовые стендапы и напоминания о них.
- Учет затраченного на работу времени — это ворклоги и аналитика по ним.
Используя подход “все ходы записаны”, мы обеспечиваем и поощряем прозрачность, а показывая открыто, куда уходит время, мы можем в любой момент заглянуть в ворклоги в прошлом, чтобы понять что и когда было реализовано.
Начну с синхронизации.
Как стендап-бот облегчил работу команды
В идеальном мире команды собираются на стендап во время звонка либо встречаются в оффлайне. Но чтобы проводить их регулярно, все члены команды должны быть в офисе (или онлайн) единовременно.
Когда в команде больше 5-7 человек и находятся они в разных странах, в разных часовых поясах и начинают свой рабочий день в разное время, единовременные стендапы практически нереальны, даже с учетом Google Meet и Zoom.
Например, в одном из наших крупных проектов, над которым мы работаем более 5 лет, есть специалисты из Южной Кореи, США, Польши, Украины и Кыргызстана. Как их свести воедино?
Как показывает практика, мы не первые, кто столкнулся с такой проблемой, и решение писать асинхронные стендапы было придумано до нас.
Такой процесс облегчает работу командам, но зачастую сопровождается кучей рутинного микроменеджмента: напоминаний о стендапах, контроле их сдачи и т.д. И чтобы избежать этой рутины, на рынок начали выпускать стендап-боты.
На тот период (2016 год) уже был Geekbot, которым мы и пользовались, а других хороших альтернатив не было.
Но этот бот только развивался и имел проблемы, которые нам периодически мешали. Например, пока сотрудники писали стендап, их могло просто выкинуть из приложения, либо оплата не проходила.
Поэтому было принято решение разработать собственный стендап-бот — Comedian.
Задачи, которые он должен был выполнять: в поверхностной конкретике оповестить команду о том, что делаем, получить обратную связь от коллег и ответить себе/команде на вопрос “а не занимаюсь ли я бесполезными делами?”
Т.е. бот должен синхронизировать усилия команды без лишних звонков или встреч, экономя общее время. И он с ним прекрасно справляется до сих пор.
Сейчас бот является частью большой системы, о которой дальше пойдет речь, но его первоначальная версия доступна в open source, как и другие наши проекты.
В бесплатной версии бот не имеет ограничений по пользователям и умеет:
- Коммуницировать с вами, предлагая выбор действий:
- Выставлять статус на рабочий день:
- Напоминать команде о ежедневных стендапах, отмечая тех, кто пропускает дедлайн. Он также отправляет прямое сообщение менеджеру, если кто-то не успел написать стендап вовремя.
Для некоторых команд такой простой бот — это бесплатная альтернатива Geekbot или Standuply, у которых есть лимиты на количество пользователей.
Изучить и самостоятельно использовать бота можно по этой ссылке.
Как с помощью ворклогов анализируем работу команд и выявляем проблемные места
Здесь спрятан премиум контент.
Для доступа к нему нужна регистрация (это бесплатно)
Как мы настроили Базовые Процессы Разработки ПО и алертинг
Привыкнув регулярно писать стендапы и вести учет рабочего времени, команды усваивают самые базовые процессы работы. Мы их называем Базовыми Процессами Разработки Программного Обеспечения (далее БПРПО).
В них входят:
- Перелинковка задач, коммитов, веток и merge requests.
- Отражение реальных статусов задач.
- Регулярное фиксирование потраченного времени.
- Синхронизация планов относительно командных целей и т. д.
Существование согласованных процессов гарантирует, что в работе минимизируется вероятность появления хаоса и проект не скатиться в бездну технического долга.
Таким образом нашими менеджерами устанавливается регламент работы, который контролирует:
- Дедлайн на сдачу стендапов (в зависимости от часового пояса).
- Ворклоги каждые N часов, с лимитом по времени максимум в N часов.
- Соблюдение воркфлоу на Jira доске. Например, оповещения о том, какие задачи находятся долго в одном статусе или без ворклогов.
- Адекватное ведение работы с кодом, с репозиторием и с процессом поставки кода.
Несмотря на то, что процессы выстраиваются ради избавления от препятствий в работе, коллеги не всегда будут следовать им.
Как это проверить? А как узнать о последствиях нарушений правил работы? Для этого мы создали настраиваемые алерты.
Алерты на ранних стадиях уведомляют наши проектные команды о постепенно возникающих проблемах в проекте в виде коротких сообщений.
Грубо говоря, это наш тимлид, который не спит и работает 24/7, потому что это не человек.
Все алерты контролируются и настраиваются через нашего стендап-бота, о котором мы писали выше. Но в рамках большой системы, когда есть данные в том числе и о ворклогах, бот гибок, поэтому могут быть настроены разные алерты для помощи менеджерам и команде.
Система алертинга проработана, чтобы служить команде всесторонне, а не узконаправленно. Здесь используется не тот метод, когда “внимание, поймали нарушителя”, а проактивный подход, который плавно доносит команде, что определенные аспекты работы можно оптимизировать.
Ниже мы прикрепили скрины некоторых алертов, где определяется, все ли идет в правильном направлении.
А остальная часть работы по оптимизации процессов проходит либо в рамках асинхронной коммуникации, либо созвона, где принимается решение об изменении подхода к работе и т.д.
И тогда уже сама команда предлагает варианты исправления ситуации. Когда люди знают о проблемах, они пытаются не только отреагировать на них, но и придумать решения, которые повлияют на проект лучшим образом.
Путем настройки алертов мы устанавливаем стандарты работы для целого отдела/проекта. В момент получения сообщения о “нарушениях” мы можем увидеть, насколько наша команда согласна следовать стандартам и были ли они реалистичны.
Если они не были настроены адекватным образом, то у коллектива есть возможность собраться и сообщить, кто с чем не согласен, а потом зафиксировать новые договоренности.
С помощью алертов мы можем следить не только за процессами, связанными со стендапами и ворклогами, но и за кодовой реализацией работ.
Система может также мониторить следующие процессы:
- отчет за вчера/неделю о коммитах в Slack
- забытые merge requests
- коммиты и ветки без ссылки на задачу
- задачи в прогрессе без ворклогов
- зависшие задачи в разных статусах
- приближение к лимиту по часам из Scope of Work и т.д.
Вот примеры некоторых алертов, которые мы используем в проектах:
Многие из “незначительных” проблем, с которыми сталкиваются компании, часто являются отражением более серьезных препятствий.
Когда проектные команды регулярно пишут асинхронные стендапы и ведут учет времени, у них появляется возможность следить именно за теми самыми “незначительными” недостатками в работе над проектом и узнать, на что обратить больше внимания.
Алерты в том числе и высвобождают время менеджеров от операционных задач.
Пытаясь следить за сроками, объемом работ и возможностью укладываться в бюджет, руководитель попадает в ловушку и часто не замечает, как закопался в операционных задачах.
Следить абсолютно за всем, что происходит, невозможно, но и перестать это делать было бы неверным решением.
В век автоматизации вручную анализировать огромный поток информации слишком ресурсозатратно. В этот самый момент алерты играют роль правой руки менеджера, автоматически раскрывая узкие места в работе.
Менеджер может анализировать алерты в виде отчетов, графиков и рекомендаций, т.к. они подсвечивают то, что нарушает процессы.