Как проектировать поток: стандарты входа, WIP-лимиты и наблюдаемость
Проектирование потока начинается со стандарта входа: никакая задача не стартует без заполненного мини-брифа на одну страницу (кто клиент, какая проблема, что считается «готово», срок, риск, метрика успеха, владелец). Это дисциплина, а не бюрократия: «пустой» вход порождает петли согласований, которые сжирают дни. Для потока вводятся WIP-лимиты — одновременно в работе не больше N задач на команду и не больше одной «тяжёлой» — это не про «медленнее», это про отсутствие переключений контекста и локальных очередей. На уровне времени применяем простую арифметику: считаем lead time от «вход» до «готово», cycle time на ключевых шагах, отклонения и повторные открытия. Для предсказуемости вводим SLA/SLO: «ответ на заявку — 4 часа в рабочее время», «подготовка оффера — 2 дня», «ошибки класса А — MTTR ≤ 4 часа», и измеряем исполнение по 90–95-му процентилю. Наблюдаемость процесса — не менее важна, чем наблюдаемость сервиса: журнал состояний (кто взял, когда, что сделал), структурированные события по ключевым переходам, дешёвые дашборды для людей (не «гирлянда метрик», а 3–5 ответов: «сколько в очереди», «где затык», «кто дежурный», «какие риски горят»). Решения фиксируются в «дизайн-заметках» на один экран: проблема, варианты, trade-offs, решение, как откатывать. Для сложных веток — «ранбук» (как поступать в нестандартных случаях), чтобы команда не тратила часы на обсуждения по кругу. Особое внимание — «инцидентам потока»: любая пауза > X часов без движения эскалируется владельцу процесса, а причины классифицируются (данные/люди/системы). Раз в неделю проводится короткое ретро процесса: какие шаги ещё можно убрать, где автоматизировать, что мешало выполнить SLA. Итог — предсказуемый, короткий и прозрачный конвейер, который не нуждается в «героизме» и не зависит от единичных людей.
Автоматизация в MI2OP23 — инструмент, а не цель. Мы начинаем не с набора платформ, а с топа рутин, которые чаще всего ломаются или отнимают время: копирование данных между системами, ручные сводные отчёты, запуск шаблонов писем, «сверки» из Excel, статусы в мессенджерах, которые теряются в шуме. На каждую рутину составляется карточка: вход/выход, частота, объём, риск ошибки, текущая стоимость (часы × ставка), стоимость задержки. Затем применяются простые классы решений: 1) no-code/low-code склейки (коннекторы/вебхуки/боты) с логом и правами доступа; 2) шаблоны документов/писем с автоподстановкой данных; 3) централизованные формы/инбоксы вместо «спросить в чате»; 4) мини-сервисы/скрипты с версионированием и журналом; 5) правила и валидаторы на входе (маски, списки, обязательные поля), чтобы мусор не попадал в систему. Для любой автоматизации задаются гвард-рейлы: кто владелец, где хранится код/схемы, как откатывать, где смотреть логи, как мониторить ошибки (алерты не «кричат», а приходят по порогам и SLO). В проде практикуется «прогрессивное включение»: сначала 5–10% кейсов (ручная верификация), потом 50%, потом 100% — с явной точкой «возврата» и метрикой пользы (сколько часов освобождено, сколько ошибок снято, насколько сократился lead time). Там, где автоматизация не окупается, мы улучшаем интерфейсы: чек-листы, готовые шаблоны, упорядоченные базы знаний с «тремя кликами до ответа». На уровне безопасности — принцип наименьших привилегий, ревизия доступов, сквозная аутентификация сервисов, хранение секретов в vault. На уровне экономики — ежемесячный «отчёт пользы»: список автоматизаций, их эффект (часы/деньги/ошибки), план отключения неиспользуемых ботов/скриптов. Так исчезают «одноразовые чудо-скрипты» и «магия» из чатов, остаются аккуратные и управляемые инструменты.