Форматы работы

Когда подходит. Сотрудники по-разному видят проблему, данные передаются вручную или непонятно, с какого участка начинать.

Входные материалы. Один-два реальных примера, используемые документы, список участников и описание того, что руководитель не может увидеть или проверить.

Что делаю. Восстанавливаю фактическую последовательность действий, точки ожидания, повторный ввод, владельцев решений и источники данных.

Что фиксируем. Текущий процесс, первопричины проблемы, границу первого этапа и вопросы, которые нельзя решить одной настройкой системы.

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

Роль заказчика. Дать примеры, собрать владельцев процесса и подтвердить, где описание соответствует практике, а где остаётся гипотезой.

Не входит. Настройка Битрикс24, 1С или другой системы, перенос данных и обещание точной стоимости всего проекта.

Когда подходит. Система уже работает, но статусы, уведомления, обмен данными или отчёты не помогают управлять процессом.

Входные материалы. Доступ к согласованному контуру, проблемные примеры, регламенты, текущие интеграции и ожидаемое поведение.

Что делаю. Сопоставляю процесс с настройками, воспроизвожу обычные и ошибочные сценарии, проверяю права, данные, события и наблюдаемость.

Что фиксируем. Причины дефектов, влияние на работу, приоритеты исправлений, зависимости и безопасный порядок изменений.

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

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

Не входит. Автоматическое исправление всех замечаний; состав, срок и стоимость изменений оцениваются после аудита.

Когда подходит. Задача понятна, но до настройки нужно определить этапы, ответственность, данные, исключения и роли программ.

Входные материалы. Подтверждённый процесс, примеры документов и данных, ограничения действующих систем, правила доступа и критерии результата.

Что делаю. Проектирую сущности, связи, состояния, события, проверки, обработку ошибок и границы обмена между системами.

Что фиксируем. Схему будущей автоматизации, владельцев данных, первый выпуск, порядок проверки и решения, отложенные на следующие этапы.

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

Роль заказчика. Назначить владельцев решений, подтвердить правила процесса и принять компромиссы, влияющие на пользователей и данные.

Не входит. Настройка production, миграция данных и скрытое расширение границ; сначала принимается архитектура.

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

Входные материалы. Принятая схема, тестовые примеры, разрешённые доступы, план отката и представители пользователей для проверки.

Что делаю. Настраиваю согласованный контур, добавляю проверки и журналирование, переношу только утверждённые данные и готовлю инструкции.

Что фиксируем. Версию решения, изменённые объекты, тестовые сценарии, ограничения, резервную копию и способ восстановления.

Критерий приёмки. Обычные и проблемные примеры проходят по согласованным правилам, а ответственный видит ошибку и следующий шаг.

Роль заказчика. Предоставить тестовые случаи, участвовать в приёмке, обучить владельцев процесса и отдельно разрешить production-публикацию.

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

Когда подходит. Решение уже принято в эксплуатацию и нужно разбирать инциденты, обновлять правила или выпускать небольшие изменения.

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

Что делаю. Сначала подтверждаю причину, затем предлагаю минимальное изменение, проверку, откат и обновление документации.

Что фиксируем. Очередь работ, решение по каждому запросу, фактическое изменение, результат проверки и новую границу поддержки.

Критерий приёмки. Изменение воспроизводимо, проверено на затронутом сценарии и не выдаёт общий health-check за доказательство исправления.

Роль заказчика. Назначить приоритет, обеспечить пользователя для проверки и вовремя принимать решения, которые меняют бизнес-правило.

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

Если причина проблемы непонятна - начните с диагностики. Если существующая система ведёт себя неверно - с аудита. Когда будущий порядок уже определён - с проектирования или ограниченной настройки.

Посмотреть конкретные технические работы