Кейс - Регламентация взаимодействий вместо описания процессов при передаче проекта в эксплуатацию Проблема: При завершении многолетнего проекта с участием десятка команд разработки необходимо было организовать их вывод. Традиционный подход через описание процессов «AsIs ToBe» был невозможен: команды отказывались описывать чужие зоны ответственности, а старые процессы теряли актуальность. Идти на эскалацию?
Решение: Сменил парадигму: вместо вопроса «кто должен выполнять процесс?» перевел к модели «кто какую услугу оказывает и на каких условиях».
Я, как руководитель проекта, инициировал регламентацию взаимодействий:
- Выявил 40 точек контакта между отделами на основании существующих процессов
- Организовал серии встречи, где стороны формулировали свои требования:
- Со стороны заказчиков услуг — фиксировали требования к образу результата и SLA
- Со стороны исполнителей — определяли необходимые входные данные и условия работы
- Выявил и устранил расхождения между ожиданиями и возможностями
- Зафиксировал форматы данных, SLA и зоны ответственности в регламентах
Итог:
- Перевод в эксплуатацию состоялся без тотального описания процессов
- Исполнители самостоятельно выстроили внутреннюю работу, ориентируясь на согласованные условия взаимодействия
- Удалось избежать конфликта и бюрократизации
Принцип: Фокусируйтесь на результате каждого взаимодействия внутри сложных кросс-департаментных процессов: находите заказчиков для формирования требований к итогу работы, договаривайтесь с исполнителями об условиях. Исполнители сами организуют внутреннюю работу в своей зоне ответственности.
· 15.11.2025
Вы абсолютно правы в ценности сквозных процессов. Я — их сторонник, что подтверждает, например, моя работа над E2E-процессом исполнения заказов (OMS). Однако мой кейс не о том, нужны ли они, а о том, как их эффективно выстраивать.
Опыт показывает, что описать идеальный сквозной процесс «сверху вниз» за один раз без ошибок — невозможно. Мы пошли итерационным путем: рассматривали участки как «черные ящики» — сервисы, которые должны договориться о взаимодействиях. Это не отмена E2E, а практичный метод его сборки. Буду честен - углубляться в описание e2e процесса мы не собирались, и в этом не было необходимости в реальных условиях с ограниченными ресурсами.
Что касается самостоятельности исполнителей — здесь речь не о сборке бургеров, а о сложных процессах с квартальным циклом, где работают высококвалифицированные специалисты. Наша задача была не устранить контроль, а сменить его форму: мы установили четкие «правила дорожного движения» (SLA, форматы данных), а внутри них дали экспертам свободу выбрать оптимальный путь. Это переход от микроменеджмента к управлению по результатам, который и позволил нам быстро и безболезненно вывести команды с проекта.
Ваш скепсис понятен, но именно этот подход помог нам не «уронить показатели», а обеспечить стабильный переход.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён