Представим такую ситуацию: на проекте описывается крупный процесс, в котором участвуют несколько подразделений, десятки ролей, согласования, интеграции и разные варианты завершения.
Аналитик проводит встречи, собирает требования и постепенно дополняет техническое задание. Документ уже занимает несколько десятков страниц, но передать его в разработку пока нельзя: не согласованы исключения, не определен один из маршрутов, остаются вопросы по правам и отчетности.
Через неделю появляется новая информация. Приходится менять раздел, который считался почти готовым. Затем к обсуждению подключается еще одно подразделение и предлагает другой порядок работы.
Заказчик ждет на согласование полное техническое задание, да и вообще уже хочет видеть готовый функционал. Разработчики же, в свою очередь, ждут финальную согласованную версию. Аналитик пытается одновременно удерживать весь процесс и довести описание до состояния, когда ни у кого не останется вопросов.
Такой момент может не наступить.
Чем крупнее процесс, тем выше вероятность, что отдельные его части будут уточняться уже во время реализации. Пока команда пытается подготовить идеальное техническое задание целиком, согласованные решения устаревают, сроки сдвигаются, а объем документа продолжает расти.
В таких ситуациях я предпочитаю принимать требования по частям. Не отдельными случайными абзацами, а законченными блоками, каждый из которых дает понятный результат и может быть передан в дальнейшую работу.
Приемка по частям не означает работу без общей картины
Иногда дробление требований может восприниматься как отказ от целостного проектирования.
Аналитик начинает описывать первую попавшуюся форму, затем отдельный отчет, после этого — права пользователя. В результате каждый фрагмент сам по себе выглядит законченным, но вместе они не складываются в единый процесс.
Такой подход действительно опасен.
До начала приемки отдельных блоков нужно определить хотя бы общий каркас:
- цель автоматизации;
- границы процесса;
- основных участников;
- ключевые объекты учета;
- начальную и конечную точки;
- основные состояния;
- внешние системы;
- ограничения проекта.
Этот уровень не требует детального описания каждого поля и исключения. Но он помогает понять, как блоки связаны между собой и какой результат должен получиться в итоге.
Например, при автоматизации договорного процесса заранее нужно определить, что конкретно входит в проект: создание проекта договора, согласование, подписание, контроль исполнения или только часть этого цикла. Это необходимо для однозначного понимания результата обеими сторонами - заказчиком и исполнителем.
Почему большой документ трудно принять целиком
Объемное техническое задание, описывающее процесс целиком, можно согласовать, если процесс стабилен и участники действительно готовы принять решение по всем разделам.
Но на практике разные части созревают с разной скоростью.
Например, порядок регистрации заявки уже понятен. Поля известны, роли определены, примеры собраны.
Маршрут согласования пока обсуждается между двумя руководителями. Отчетность зависит от показателей, которые еще не утвердили. Интеграция требует отдельной встречи с внешним подрядчиком.
Если считать документ единым неделимым результатом, готовая часть будет ждать самую неопределенную.
За это время могут измениться и уже согласованные решения, и тогда придется возвращаться снова на этап согласования тех отдельных требований, которые ранее уже были зафиксированы и согласованы. Есть вероятность погрязнуть в бесконечном процессе обсуждений с нулевым результатом.
Приемка блоками позволяет зафиксировать зрелые части отдельно, не создавая видимость полной определенности там, где ее еще нет.
Блок должен заканчиваться рабочим результатом
Самая удобная граница блока — не количество страниц и не раздел спецификации, а результат, который понятен пользователю.
Лучше формулировать блок через действие, то есть, часть процесса:
- сотрудник создает и отправляет заявку;
- руководитель рассматривает заявку и принимает решение;
- исполнитель получает согласованное поручение;
- система контролирует срок исполнения;
- руководитель видит результаты процесса.
Каждый блок в таком случае отвечает на вопрос: какую законченную работу сможет выполнить пользователь после реализации?
Пример: как разделить договорный процесс
Предположим, компания внедряет работу с договорами в 1С:Документообороте (мне проще приводить такие примеры, так как я специализируюсь на направлении автоматизации документооборота).
Если пытаться принять весь процесс одним документом, в него одновременно попадут карточка договора, файлы, маршруты согласования, полномочия, электронная подпись, контроль исполнения, остальные документы договорного характера, интеграции и отчеты. Это очень большой объем для разового внедрения, даже если часть требований покрывается типовым функционалом.
Такой объем можно разделить на несколько блоков.
Блок 1. Создание проекта договора
- кто может инициировать договор;
- какие реквизиты заполняются;
- какие файлы прикладываются;
- как выбирается контрагент;
- что считается готовностью к запуску согласования;
- какие проверки выполняются перед отправкой.
Результат блока: инициатор может создать корректную карточку и подготовить ее к рассмотрению.
Блок 2. Согласование договора
- как определяется маршрут;
- кто участвует в согласовании;
- что происходит при замечаниях;
- как обрабатывается возврат на доработку;
- когда согласование считается завершенным.
Результат: договор проходит утвержденный маршрут и получает зафиксированный итог.
Блок 3. Подписание
- кто принимает решение о подписании;
- какой файл считается финальным;
- как фиксируется способ подписания;
- как хранится подписанный экземпляр;
- что происходит при отказе контрагента.
Результат: в системе хранится согласованный и подписанный документ с понятным статусом.
Блок 4. Контроль исполнения
- какие обязательства контролируются;
- кто отвечает за исполнение;
- как фиксируются сроки;
- какие напоминания нужны;
- когда договор можно завершить.
Результат: ответственные сотрудники видят обязательства и сроки, а договор не закрывается раньше времени.
Блок 5. Отчетность
- какие показатели нужны руководителю;
- по каким разрезам проводится анализ;
- какие данные должны быть заполнены в предыдущих блоках;
- кто видит отчеты;
- как часто ими будут пользоваться.
Результат: руководитель получает согласованную информацию о договорах и состоянии процесса.
Такие блоки можно принимать последовательно. При этом общая схема договорного процесса остается единой.
Граница блока должна быть видна заказчику
Фраза «первый блок принят» ничего не дает, если участники по-разному понимают его состав.
В решении полезно прямо указать:
В блок входит создание договора, заполнение реквизитов, проверка обязательных данных и отправка на согласование.
В блок не входят работа с иными документами договорного характера, интеграции с учетными системами, отчеты. Эти сценарии рассматриваются в следующем блоке.
Такая запись защищает обе стороны.
Заказчик видит, что именно он принимает. Разработчик понимает, где заканчивается текущий объем. Аналитик может обоснованно перенести новые вопросы в соседний блок, а не добавлять их в уже согласованный раздел.
Не все зависимости можно отложить
Но важно учитывать, что дробление не должно приводить к тому, что важные сквозные решения принимаются слишком поздно.
До детальной приемки блоков стоит определить решения, которые влияют сразу на весь процесс:
- единые роли;
- основные статусы;
- структуру ключевых объектов;
- правила нумерации;
- общие права доступа;
- принцип хранения файлов;
- источник нормативно-справочной информации;
- границы интеграции;
- правила ведения истории изменений.
Если согласовать карточку договора, а затем в отдельном блоке решить полностью изменить модель контрагентов или структуру видов документов, первую часть придется переделывать.
Поэтому перед приемкой блоков полезно выделить отдельный набор архитектурных и процессных решений. Они могут быть описаны кратко, но должны служить общей основой.
Как определить порядок блоков
Не всегда нужно двигаться строго от начала процесса к концу.
Порядок зависит от рисков и целей проекта.
Чаще всего первым стоит принимать блок, который:
- дает понятный пользовательский результат;
- имеет минимальное количество внешних зависимостей;
- позволяет проверить основные проектные решения;
- нужен для начала разработки следующих частей;
- содержит наиболее стабильные требования.
Иногда полезно начать не с самого первого шага процесса, а с наиболее рискованного.
Например, если весь проект зависит от интеграции с внешней системой, сначала нужно подтвердить состав данных и техническую возможность обмена. Иначе команда подробно опишет внутренние формы, а позже выяснится, что необходимую информацию получить невозможно.
Как оформлять блок требований
Единого обязательного формата нет. Формат больше зависит от способа ведения документации на конкретном проекте. Блок может быть разделом спецификации, отдельным документом, группой требований в реестре или задачей верхнего уровня в проектной системе.
Главное — сохранить связи.
Для каждого блока полезно указывать:
| Раздел | Что фиксируется |
| Название | Завершенный пользовательский или процессный результат |
| Цель | Какую задачу решает блок |
| Границы | Что входит и не входит |
| Сценарии | Основной ход работы и значимые исключения |
| Участники | Роли и владельцы решений |
| Зависимости | Какие блоки и внешние решения влияют на результат |
| Открытые вопросы | Что еще требует уточнения и блокирует ли это приемку |
| Критерии приемки | По каким признакам блок можно считать реализованным |
| Статус | Подготовлен, на согласовании, принят, принят с замечаниями |
| Версия и дата | Какая редакция была принята |
Версия блока важнее даты последнего изменения файла
При частичной приемке особенно важно управлять версиями.
Если в одном общем документе постоянно меняются разные разделы, участникам сложно понять, какая редакция конкретного блока была согласована.
Поэтому я фиксирую:
- номер или дату версии;
- статус блока;
- дату приемки;
- кто подтвердил решение;
- что изменилось после предыдущей версии.
Изменения в принятом блоке не должны незаметно появляться при редактировании соседних разделов.
Если решение пересматривается, это оформляется как изменение требований: с причиной, влиянием на разработку и повторным согласованием.
Что передавать в разработку
Принятый блок должен быть достаточен для начала работы команды, но не обязательно содержать все требования проекта.
Разработчику нужно понимать:
- какой результат ожидается;
- кто выполняет сценарий;
- какие данные используются;
- какие проверки обязательны;
- что происходит при ошибке;
- как будет проверяться результат.
Если после передачи разработчик вынужден заново выяснять цель блока, приемка требований блока была формальной.
При этом вопросы технической реализации могут оставаться внутри команды разработки. Заказчику не нужно согласовывать каждую служебную операцию, если она не влияет на его работу и ограничения процесса.
Не дробить процесс слишком мелко
У приемки по частям есть обратный риск — превратить проект в десятки микроблоков.
Например:
- создание карточки;
- заполнение даты;
- выбор организации;
- прикрепление файла;
- проверка обязательности;
- нажатие кнопки отправки.
Каждый блок потребует отдельного описания, встречи, протокола и статуса. На управление границами уйдет больше времени, чем на сам анализ.
Как уже писала выше, я считаю блок достаточно крупным, если по его результату пользователь выполняет завершенное действие, а заказчик может оценить пользу независимо от технических деталей.
При этом блок должен оставаться достаточно компактным, чтобы решение по нему можно было принять за одну или несколько предметных встреч, а не обсуждать месяцами.
Распространенные ошибки
Делить по структуре документа. Раздел «Интерфейс» или «Права» редко дает самостоятельный бизнес-результат.
Начинать без общей схемы. Блоки принимаются отдельно, но используют разные термины, роли и состояния.
Не фиксировать, что не входит. После приемки заказчик считает соседний сценарий частью блока, а команда разработки — новым требованием.
Передавать блок с блокирующими вопросами. Разработка начинается на предположениях, которые позже приходится пересматривать.
Ждать ответа на все мелкие вопросы. Один текст уведомления задерживает приемку основного процесса.
Менять принятый блок без повторного согласования. Решение постепенно расширяется, но участники считают, что объем не изменился.
Принимать только текст, а не сценарий. Документ формально согласован, но пользователи по-разному понимают будущую работу.
Создавать слишком много блоков. Управление документацией становится тяжелее самого проекта.
Как понять, что дробление получилось удачным
Хорошее разделение можно проверить несколькими вопросами.
- Понятно ли, какой результат дает каждый блок?
- Может ли заказчик принять по нему самостоятельное решение?
- Известно ли, что не входит в его границы?
- Не придется ли переделывать блок из-за уже известных решений соседней части?
- Достаточно ли информации для начала разработки?
- Можно ли проверить результат после реализации?
Если блок нельзя объяснить без постоянных ссылок на несогласованные разделы, граница выбрана неудачно.
Если для его приемки приходится обсуждать весь процесс целиком, дробление существует только на бумаге.
Приемка по частям не снижает требования к качеству
Цель подхода не в том, чтобы быстрее согласовать недоработанный документ.
Каждый блок должен быть понятным, непротиворечивым и достаточным для своего результата.
Меняется не качество описания, а момент приемки. Команда не ждет, пока одинаково подробно будут проработаны все части большого процесса.
Готовое решение фиксируется и передается дальше. Неопределенные блоки продолжают обсуждаться отдельно.
Так аналитик меньше времени тратит на постоянное обновление огромного документа, заказчик принимает решения по понятным частям, а разработка может начинать работу раньше.
