Компания хочет разрешить клиенту переносить запись на обслуживание без звонка оператору. Изменение выглядит небольшим, но требует участия команд сайта, расписания, клиентской базы и уведомлений. У каждой свой план. Работа последовательно стоит в четырёх очередях, хотя никто не отказывается её делать.
Разделить приложение на дополнительные сервисы здесь недостаточно. Сначала полезно понять, почему одно клиентское действие требует именно таких передач. Возможно, часть зависимостей действительно необходима. А возможно, система годами повторяла удобный для отделов способ работы, который теперь стал дорогим для продукта.
Конвей писал о коммуникациях, а не о прямоугольниках оргструктуры
В статье «How Do Committees Invent?» Мелвин Конвей связывает устройство создаваемой системы со структурой коммуникаций организации. Здесь важны именно коммуникации: линии подчинения показывают только часть связей. Две команды могут иметь разных руководителей и ежедневно принимать решения вместе. А люди в одном департаменте — общаться исключительно через заявки.
Это полезная закономерность для анализа, но не инструкция предсказывать каждый модуль по штатному расписанию. На архитектуру влияют также существующие данные, требования безопасности, ограничения продукта и накопленный код. Новое название отдела не отменяет эти условия.
Для переноса записи интереснее выяснить, кто понимает весь сценарий, кто вправе изменить правило и кто может выпустить результат. Если все три ответа указывают на разных людей, одного общего совещания может не хватить.
Найти цену передачи работы
Возьмите несколько завершённых изменений и восстановите их путь: от сформулированной задачи до использования клиентом. Отдельно отметьте работу и ожидание. Где уточняли смысл требования? Где ждали свободного специалиста? Где готовое исправление задержалось до общего выпуска?
Не каждое согласование лишнее. Изменение правил хранения персональных данных требует компетентного решения. Но одно дело — получить решение по новому риску, другое — повторно запрашивать разрешение на уже согласованный тип изменения. Во втором случае полезнее сделать правило доступным и проверяемым, чем каждый раз собирать тех же людей.
Посмотрите также на полномочия. Команда может знать, что нужно сделать, но не иметь права менять контракт, данные или порядок выпуска. Тогда ещё один разработчик не уберёт очередь. Нужен ответ на вопрос, кто вправе делегировать решение и в каких пределах.
Такую карту следует строить без рейтинга «медленных отделов». Задержка часто объясняется тем, что общая команда обслуживает несовместимые приоритеты нескольких продуктов. Если просто перенести ожидание за пределы измеряемого этапа, отчёт улучшится, а клиент получит функцию в тот же день, что и раньше.
Организовать работу вокруг результата, не раздавая всем всё
Для нашего примера можно собрать устойчивую команду, способную менять сценарий записи: интерфейс, соответствующие правила и проверки. Специалисты по расписанию участвуют в решениях напрямую, а обычный выпуск не требует отдельного проекта в каждом техническом слое. Такой выбор взаимодействий под желаемую архитектуру часто называют обратным манёвром Конвея.
DORA предлагает оценивать слабую связанность команд через практические возможности: изменять, проверять и выпускать свою часть без постоянной синхронизации с соседями. Само количество сервисов эту возможность не доказывает. Подход полезен и для модулей одного приложения.
Однако команде записи не обязательно самостоятельно строить почтовую инфраструктуру, систему входа и базу данных. Повторяемые технические возможности можно получать через внутреннюю платформу. Значимая автономность — возможность решить продуктовую задачу в понятных границах, а не обязанность знать и обслуживать все технологии компании.
У границы должен быть и технический смысл. Пока несколько команд напрямую меняют одни таблицы, независимые планы будут сталкиваться в данных. Нужно договориться о владельцах правил и способах взаимодействия. Иногда достаточно модульного разделения и контрактов; переезд на отдельные серверы — другое решение.
После реорганизации старые зависимости не исчезают
Перевести людей под одного руководителя можно быстрее, чем передать знания, доступы и поддержку. Если новую команду считают самостоятельной с первого дня, а важные операции по-прежнему умеет выполнять только прежний специалист, зависимость стала менее заметной, но не меньшей.
Для перехода нужен перечень обязательств: кто принимает обращения, кто обслуживает старый интерфейс, кто исправляет дефекты и когда ответственность действительно передаётся. Переходный совместный выпуск допустим. Бессрочная необходимость каждый раз договариваться со всеми означает, что желаемая независимость ещё не достигнута.
Есть и цена чрезмерного разделения. Если клиентский сценарий постоянно пересекает новые границы, команды создадут дополнительные согласования, обмен данными и способы восстановления. Иногда объединение тесно связанных обязанностей даст больше, чем дальнейшее дробление.
Редкие специалисты тоже не появляются от смены структуры. Их можно привлекать к совместной работе на ограниченный период, обучать команду или предоставлять понятную общую услугу. Задача — уменьшить необходимость постоянного ручного участия, а не спрятать человека за ещё одним каналом заявок.
Проверять гипотезу следующим изменением
Начинать разумнее с одного потока работы, чем с перестройки всей компании. Для записи на обслуживание заранее определите, какие решения команда теперь принимает сама и какие зависимости сохраняются. Затем пройдите следующий реальный выпуск, включая поддержку после запуска.
Сравните время ожидания, число необходимых передач, объём переделок и способность устранить сбой. Количество сообщений в чате само по себе ничего не говорит: полезный разговор может предотвратить ошибку. Важнее, требуется ли обязательное участие соседей для каждой обычной доработки.
Если срок сократился только благодаря ручному вмешательству руководителя, новая схема пока не работает самостоятельно. А если команда выпускает изменение в согласованных границах, соседи понимают контракт и клиент может перенести запись, появляется основание расширять подход. Именно этот результат стоит искать за словами о соответствии архитектуры структуре компании.