Когда говорят о микрокомандах, обычно подразумевают группу из 5–10 человек, которая собирается под разовую активность внутри компании. Такие команды в основном кросс-функциональные. То есть содержат внутри себя все функции для того, чтобы выполнять поставленные задачи или реализовать проект под ключ, без передачи промежуточных результатов работы специалистам других подразделений или команд.
Кросс-функциональность не обязательно означает, что за каждую функцию должен отвечать отдельный исполнитель, — такую команду собрать очень сложно. Чаще какая-нибудь функция делится между разными людьми. В команде, которая разрабатывает ПО, тестировщика может периодически подменять программист либо один программист другого.
Кросс-функциональная команда берёт на себя ответственность за выпуск конечной бизнес-ценности — например, нового мобильного приложения.
Монофункциональная команда, напротив, нацелена на выполнение одной функции — допустим, на поддержку бэкенда или на тестирование. Есть и более традиционные команды с одной функцией: бухгалтерия, HR, юридический отдел, департамент информационной безопасности.
Монофункциональные команды — это типичные бункеры, то есть команды, которые стремятся быть продуктивными внутри себя. Конечная бизнес-ценность для бункеров — абстракция. Даже если каждый бункер по отдельности продуктивен, это не значит, что компания в целом достигает нужного результата.
Зачем нужны микрокоманды
В цифровой экономике единственное по-настоящему универсальное конкурентное преимущество — скорость, с которой компания может реагировать на потребности своих клиентов и изменения рынка. Чем быстрее у компании реакция, тем она эффективнее. Традиционные оргструктуры вроде монофункциональных команд не вписываются в эту концепцию.
Микрокоманды, особенно agile-команды, — это «противобункерное» средство. Скорость и гибкость их главные плюсы. Работа микрокоманд сосредоточена на создании конечной ценности, а не на выполнении одной функции. Выигрывает та компания, которая постоянно работает над устранением бункеров, вовлекая их в общий поток создания ценности, в том числе с помощью микрокоманд.
Однако собрать микрокоманду — полдела. Важно ещё выбрать правильный инструмент для автоматизации её рабочих процессов.
Проблемы автоматизации
Монофункциональные команды легко встают на «рельсы» сервисных процессов, устоявшихся в организации. Часто они используют для решения задач тот же программный инструмент, что и остальные подразделения. Пример — ITSM-система, которой пользуются одновременно ИТ, АХО, служба безопасности и другие сервисные отделы.
Концептуально у микрокоманд задачи примерно такие же, как у больших команд, только проще, они не требуют такого количества бюрократии и могут меняться на ходу.
Микрокомандам, как правило, нужен собственный инструмент автоматизации рабочих процессов — ПО для управления проектами, выбор которого зависит от конкретного проекта. Главное, чтобы этот инструмент можно было быстро запустить, настроив под себя рабочее пространство (workspace) для совместной работы.
Каждой микрокоманде при этом требуется разная функциональность: канбан-доски, голосовая и видеосвязь, пространство для совместной работы с документами, предоставления доступа к документам для внешних участников, диаграммы Ганта, тайм-трекер и так далее. Иногда — всё вместе.
На рынке ПО для управления микрокомандами представлено большое количество облачных сервисов, от Trello и Asana до ClickUp и Basecamp. Но почти все эти продукты ориентированы на малый бизнес. То есть годятся для небольших компаний и стартапов, а для микрокоманд в составе крупных компаний — не очень. Потому что не каждая крупная компания готова покупать такое ПО и интегрировать его в свою экосистему. На то есть причины — чаще это политика безопасности, трудности интеграции с имеющимися корпоративными приложениями, корпоративными средствами коммуникации и каталогом пользователей, отсутствие у таких продуктов достаточной гибкости.
На самом деле в крупных компаниях микрокоманды постоянно обходят запреты и устанавливают себе нужное ПО. Так возникает теневой ИТ (shadow IT). Чем он плох:
- нет контроля со стороны ИТ-отдела;
- повышается вероятность инцидентов ИБ;
- при отказе сервиса и потере данных нет юридических рычагов влияния (отсутствует SLA).
Никому не нужен теневой ИТ, но в enterprise без него, по-видимому, никак. Запрет на использование сторонних сервисов, по сути, бесполезен.
Если руководитель собирает микрокоманду, ставит задачи, но не даёт возможности эти задачи решать, сотрудники либо решат задачу плохо (или хорошо, но используя инструменты за пределами корпоративной инфраструктуры), либо просто уходят к другому работодателю.
Есть два основных пути, по которым идут корпорации в решении проблемы теневых ИТ, используемых для менеджмента микрокоманд.
Интеграция облачных сервисов для управления микрокомандами в корпоративную инфраструктуру
Сценарий реалистичен, если предположить, что компания готова пересмотреть политику в отношении облачного ПО для микрокоманд. Впрочем, здесь сразу возникают технические и организационные трудности. Потому что чем больше инструментов автоматизации в компании, тем больше вероятность нагородить «зоопарк» прикладного ПО. А когда это ПО ещё и находится во внешнем облаке, то сложностей становится на порядок больше. Среди таких проблем можно отметить следующие.
- Низкий уровень безопасности. Облачные инструменты управления микрокомандами, находящиеся за периметром корпоративной инфраструктуры, как правило, не поддерживают достаточный для крупных корпораций уровень защищённости в силу того, что они ориентированы на стартапы и небольшие компании, для которых хранить пароли в гугл-таблице — это норма.
- Сложность администрирования. Каждую информационную систему нужно обслуживать и поддерживать. В крупных компаниях зачастую для этого требуется выделенный системный администратор.
- Ограниченная интеграция. Между ПО разных вендоров встроенная интеграция порой ограничена, поэтому требуется разрабатывать и поддерживать собственные механизмы интеграции и синхронизации данных. Это дорого, и работают такие надстройки не очень надёжно. При отсутствии интеграции возникают проблемы с передачей задач между подразделениями, дублированием данных и нарушением их целостности в консолидированных отчётах. Становится невозможной слаженная работа смежных подразделений — например, маркетингового отдела, который может работать в Trello, и разработчиков, использующих Jira.
- Разный UI. Удобно, когда задачи ставятся в единой системе, в которой сотрудники «живут» 90% рабочего времени — например, айтишники в ITSM-платформе. Но когда участник микрокоманды должен постоянно «выныривать» из привычного инструмента и «нырять» в другой, у которого свои законы и свой UI, об удобстве приходится только вспоминать.
- Усложнённая отчётность. У каждой команды свой формат отчётности. Но вышестоящее руководство требует отчёты в едином формате. Тогда менеджерам команд приходится тратить время на адаптацию аналитики, которая собирается во внешних облачных сервисах.
- Лишние действия. Как следствие двух предыдущих пунктов — генерация избыточного служебного трафика и лишние действия: постоянные уточняющие вопросы, эскалации по электронной почте и устно.
- Бункеры. Изоляция команд на уровне инструмента автоматизации процессов — одна из причин образования бункеров. Это возвращает нас к проблемам традиционных, монофункциональных команд.
- Ограничение на масштабирование лучших практик. Практики, хорошо работающие в кросс-функциональной команде в плане эффективности бизнес-процессов (например, WIP-ограничения в канбан-инструменте разработчиков), иногда невозможно внедрить в монофункциональной (например, в маркетинге) — в том числе потому, что разработчики и маркетологи «живут» в разных системах.
SimpleOne — корпоративная информационная система с функциями менеджмента микрокоманд
В SimpleOne реализуется автоматизация канбан-подхода к управлению и возможность создавать рабочие пространства для микрокоманд. Что будет входить в функциональность такой системы:
- функциональная канбан-доска (поддерживающая WIP-лимиты, сигналы вытягивания и разные классы обслуживания);
- инструменты для создания внутренних коллабораций: рабочий чат, интеграция с корпоративными сервисами, почтой и пр.;
- гибкое управление задачами с учётом их жизненного цикла;
- возможность привлекать внутренних и внешних исполнителей;
- интеграция с таск-менеджерами типа Slack, Trello, Asana и пр.;
- тайм-трекинг для планирования загрузки, учёта трудозатрат и отслеживания сроков выполнения задач;
- пуш-оповещение о событиях — например, о новых комментариях, изменениях в задаче, приближающемся дедлайне и т. д.
Также в воркспейсе будет предусмотрено собственное облачное хранилище для загрузки и совместной работы с документами и файлами, содержащими требования, артефакты, рабочую документацию.
Заключение
Мы уверены, что за микрокомандами будущее — неважно, самостоятельные это команды или в составе организаций. Вся цифровая трансформация движется в эту сторону. Производители программных решений для автоматизаций бизнес-процессов развивают свои ITSM, BPM и прочие системы как раз в контексте комплексного подхода, стремятся делать свои продукты удобными и для сервисных подразделений, и для микрокоманд.
Как вендор ESM-платформы SimpleOne, мы тоже активно развиваемся в этом направлении. Для нас создание полнофункционального инструмента для менеджмента микрокоманд в составе единого ESM-решения — приоритетная задача на ближайшее время.