Привет, Хабр! Меня зовут Анастасия Клевцур, я продакт модуля «Структура компании» в Битрикс24. Сегодня расскажу, как мы делали функционал кросс-функциональных команд — решение, которое позволяeт сотрудникам из разных отделов работать над общими проектами, не ломая привычную оргструктуру и не теряя управляемости процессов.

Зачем вообще командам место в структуре?

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

Этап 1: Исследование — идеи, референсы, рынок

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

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

Этап 2: Проектирование — не ломаем мозг, делаем как отдел, думаем о сценариях

Один из ключевых принципов, который мы взяли за основу: интерфейс команд должен быть настолько же знакомым и “интуитивным”, как работа с отделами. Команды — не новый параллельный мир, а ещё один элемент того же дерева: ты создаёшь команду по тому же мастеру, видишь её карточку также на структуре, настраиваешь роли и права привычным способом.

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

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

Этап 3: Разработка 

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

Технически структура компании представлена одним единым деревом, мы рассказывали о выбранной системе хранения еще до появления Команд. Такое решение позволило нам проработать API, которое перед выполнением добавляет к основному запросу подзапрос, отсеивающий команды, недоступные пользователю по правам. Добиться этого получилось благодаря таблице b_hr_structure_node_path, с помощью которой,  зная отделы и команды пользователя, мы можем на ходу проверять принадлежит ли команда к нужному отделу или команде.

Этап 4: MVP, фидбек от внутренних пользователей и реализация сложных сценариев

Пилот развивали итерационно: изначально сделали простое создание команд, иерархию (команды могут быть внутри отделов или других команд), базовые роли и простую интеграцию с чатами/каналами. В процессе поняли, что сила решения — в автоматизации, когда человек попадает в команду и автоматически добавляется во все чаты, каналы, командные коллабы.

Продемили коллегам — и получили массу идей. Почти сразу стало ясно: бизнес-процессы должны быть более гибкими. Всплыл классический кейс  согласования отпусков: в простой оргструктуре отпуск сотрудника согласовывает его непосредственный начальник. Но если речь идет о команде, то сначала «отпустить» сотрудника должен руководитель проекта. Этот сценарий оказался жизненно важным — теперь его сделали базовым: в командах отпуск можно проводить сначала через руководителя проекта, а затем через “линейного” руководителя отдела. 

Самым же неожиданным стал настоящий холивар вокруг названия. С одной стороны, термин «функциональные команды» интуитивно понятен бизнесу и маркетингу. С другой — «кросс-функциональные» точнее отражает саму суть и логику работы. После оживлённой внутренней дискуссии мы нашли компромисс: в интерфейсе оставили просто «Команды» для краткости и удобства, а в документации и описаниях используем уточнение «кросс-функциональные», чтобы подчеркнуть их природу. Это позволило сохранить простоту интерфейса, не искажая принципы работы функционала.

Этап 5: Релиз, обратная связь и доработки

Когда выпустили функционал в релиз, начали сразу собирать обратную связь и статистику использования. Команды пока не стали массовым кейсом: ими пользуются около 1 700 компаний из 300 000 активных порталов. Но для своей ниши инструмент оказался незаменимым: он решает задачи, которые невозможно решить чисто оргструктурой.

Самые востребованные сценарии, которые реально используют клиенты:

• HR-команда для согласования отпусков:
  Теперь сотрудник подаёт заявку на отпуск — и она сначала улетает руководителю проектной команды (человек, который реально знает ситуацию по проекту), а потом уже начальнику отдела, в котором числится сотрудник.

• Проектная команда для крупного клиента:
  Собирают команду из разных отделов, выдают все коммуникации, наделяют проектного менеджера правом согласовывать командировки, — и вся операционка клиента и его проекта ведётся централизовано.

• Экспертная группа для внутренней автоматизации:
  IT- и бизнес-специалисты из разных подразделений объединяются в команду для внедрения нового инструмента. Руководитель команды согласует закупки, обсуждения идут в отдельном командном канале.

Куда дальше?

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

Главный вывод:
Лучшие решения — те, что не ломают привычное поведение, а помогают ему стать более гибким. Команды в структуре компании помогают бизнесу адаптироваться под меняющуюся реальность без дополнительных сложностей для пользователей.

Пишите вопросы, делитесь фидбеком и предлагайте сценарии — мы открыты к общению!