На созвоне обсуждают маршрут согласования договора. В задаче написано: убрать лишний этап, потому что документы слишком долго доходят до подписания. Формулировка выглядит простой: сократить маршрут и не задерживать сделку.
Через несколько минут выясняется, что для продаж это ускорение типовых договоров, а для юристов — потеря контроля по отклонениям от шаблона. Потом подключается бухгалтерия и уточняет, на каком этапе должны появляться реквизиты для оплаты. Разработчик задает практический вопрос: “По какому условию система должна пропускать этап?”
И вот здесь становится видно, что обсуждают не одну кнопку и не один этап. Обсуждают ответственность: кто решает, что договор типовой; что считать отклонением; где фиксировать причину ускоренного маршрута; можно ли оплатить документ, если часть данных появилась позже.
Я чаще сталкивалась с такими ситуациями в согласовании договоров и в работе с документами. Вроде бы задача техническая: изменить маршрут, добавить поле, настроить статус, поправить доступ. Но за ней быстро появляются разные ожидания от процесса. Одним нужно быстрее довести документ до результата. Другим — сохранить проверку, историю, корректность данных и возможность потом объяснить принятое решение.
В такие моменты аналитик оказывается между несколькими сторонами. Не как человек, который должен всех помирить, и не как тот, кто выбирает победителя. Его работа — разобрать противоречия в требованиях, перевести их в понятные правила и не передать в разработку задачу, где недоговоренность уже спрятана внутри.
Когда задача попадает к аналитику слишком рано
Иногда запрос приходит уже в виде готового решения: “убрать согласующего”, “сделать поле обязательным”, “открыть доступ руководителям”, “добавить статус”. Такие формулировки удобны тем, что выглядят конкретно. Но конкретность здесь может обмануть.
Например, фраза “убрать согласование юристов” может означать разные вещи. Кто-то говорит только о договорах без изменений. Кто-то включает туда все документы по небольшим суммам. Кто-то считает, что проверка нужна только при правках в условиях оплаты. Если это не проговорить, разработчик получит короткое требование, но не получит правила, по которым система должна работать.
То же самое с обязательными полями. Пользователь просит убрать лишнее заполнение, бухгалтерия просит добавить реквизиты, руководитель хочет отчет по подразделениям и суммам. В описании задачи это легко превращается в спор о форме. На деле нужно понять, какие данные нужны сразу, какие можно подтянуть из справочника, а какие допустимо заполнить перед оплатой или закрытием документа.
Я стараюсь в таких задачах не начинать с интерфейса. Сначала нужно понять, какую рабочую ситуацию пытаются исправить. Договоры зависают на этапе согласования? Документы уходят на оплату без основания? Пользователь не понимает, что делать на своем шаге? Руководителю не видно, где документ остановился? От ответа зависит не только форма, но и маршрут, роли, статусы, история и приемка.
Почему просто записать пожелания всех сторон опасно
Бывает соблазн пройти по участникам, собрать их требования и аккуратно положить в один документ. Формально все мнения учтены. Но если требования не сверить между собой, описание задачи может получиться противоречивым.
Договор должен проходить быстро, но каждое отклонение нужно проверять вручную. Пользователь должен заполнять минимум полей, но отчет должен быть точным. Руководитель должен видеть ход процесса, но не все вложения можно показывать его роли. Исключения нужны, но никто не назвал человека, который имеет право их подтверждать.
На встрече такие просьбы часто звучат отдельно и не мешают друг другу. Сложность появляется, когда их нужно превратить в один маршрут. Разработчик спрашивает: “Какой статус ставим после пропуска этапа?” “Кто видит кнопку?” “Что делаем, если файл изменили после выбора типового сценария?” “Что писать в истории?”
Если на эти вопросы нет ответа, разработка начнет вытаскивать противоречие наружу уже в процессе работы. Часть решений будет приниматься на ходу. Часть вернется на приемке. Часть проявится после запуска, когда пользователи начнут задавать вопросы сопровождению.
Где обычно прячутся спорные места
Самые сложные места редко выглядят сложными сразу. Они прячутся в словах, которые участники считают понятными.
“Согласовано”. Для одного участника это значит “я посмотрел и не возражаю”. Для другого — “после этого документ можно отправлять клиенту”. Для третьего — “документ можно передавать в оплату”. Если не уточнить смысл статуса, в системе появится одна отметка, которую все читают по-разному.
“Типовой договор”. Слово удобное, но опасное. Типовой — это договор по утвержденному шаблону? Договор без правок? Договор до определенной суммы? Договор с определенным контрагентом? Пока это не описано, маршрут нельзя надежно автоматизировать.
“Срочно”. Часто этим словом пытаются объяснить исключение. Но системе нужно правило: кто подтверждает срочность, где остается след, можно ли потом проверить причину обхода.
“Доступ руководителю”. Руководителю может быть нужен только статус и срок, а не полный комплект вложений. Если не разделить эти вещи, можно либо закрыть полезную информацию, либо открыть лишнее.
Что я уточняю до описания решения
В таких обсуждениях я начинаю с причины, а не с предложенного варианта реализации. Вопрос простой: “Какую проблему мы этим закрываем?”
Когда участники отвечают на него, разговор становится предметнее. “Нужно обязательное поле” превращается в “мы не хотим оплатить договор без основания”. “Уберите юристов из маршрута” превращается в “нам нужен быстрый путь для типовых договоров”. “Откройте доступ руководителям” превращается в “руководителю нужно видеть, где документ остановился”.
После этого можно обсуждать варианты. Иногда достаточно изменить момент заполнения поля. Иногда нужно разделить маршрут на типовой и нетиповой. Иногда требуется отдельное правило для отклонений от шаблона. Иногда проблема решается не доступом ко всему документу, а отдельным статусом или отчетом.
Задача аналитика здесь не в том, чтобы придумать компромисс за всех. Я собираю варианты, показываю последствия и фиксирую, где нужно решение владельца процесса. Если владелец не назван, это тоже результат обсуждения, который нужно вынести отдельно.
Пример 1. Ускорить договоры, но не потерять проверку
На одном обсуждении сначала казалось, что вопрос только в лишнем этапе маршрута. Продажи просили убрать юридическое согласование для части договоров. Юристы возражали, потому что уже были случаи с измененными условиями оплаты и ответственности.
Если записать требование как “убрать юристов из маршрута”, неразобранное противоречие переедет в реализацию. Если оставить полный маршрут для всех, менеджеры продолжат воспринимать процесс как тормоз и будут искать обходные пути.
После уточнений стало понятно, что стороны говорят о разных наборах документов. Продажам нужен короткий путь для договоров без изменений. Юристы говорят о документах, где меняют условия оплаты, сроки, ответственность или используют нестандартные формулировки.
Дальше разговор пошел уже не вокруг фразы “убрать согласование”, а вокруг правил. Что считается типовым договором? Какие признаки отклонения нужно указать в карточке? Кто подтверждает, что документ можно пустить по короткому маршруту? Что делать, если файл изменили после выбора типового сценария? Где хранится причина ускоренного маршрута?
После такого разбора решение становится описываемым. Типовые договоры идут быстрее. Отклонения от шаблона уходят на проверку. Исключения подтверждает определенная роль. Причина остается в истории документа.
Пример 2. Меньше полей для пользователя и больше точности для учета
Второй частый случай — карточка документа. Пользователь видит длинную форму и просит убрать часть обязательных полей. Бухгалтерия просит эти поля оставить, потому что потом именно по ним закрывают документы и строят отчетность.
Если обсуждать это как “удобно против правильно”, разговор быстро заходит в тупик. Я обычно разбираю путь документа по этапам. Что нужно заполнить при создании? Что должно появиться до согласования? Что обязательно до оплаты? Какие данные система может подтянуть сама?
Иногда оказывается, что часть полей действительно не нужна на первом шаге. Пользователь может создать документ быстрее, а обязательная проверка включается перед передачей в бухгалтерию. Иногда поле остается обязательным, но меняется подсказка или источник заполнения. Иногда нужна не новая обязанность для пользователя, а автозаполнение из договора, контрагента или подразделения.
Такой разбор помогает не спорить о количестве полей вообще. Обсуждается конкретная точка процесса, где данные становятся необходимыми.
Пример 3. Разработка готова начинать, а правила еще не собраны
Бывает, что задачу уже хотят отдать в разработку. Встречи прошли, общее направление выбрали, срок нужен. Но при проверке описания остаются вопросы: какой статус ставить после обхода этапа, кто подтверждает исключение, что увидит руководитель, нужно ли подключить бухгалтерию, кто владелец спорного решения.
В такой момент аналитик может выглядеть человеком, который задерживает движение. Но если начать работу с плавающими правилами, задержка появится позже. Только она будет дороже: переделки, спорная приемка, обращения после запуска.
Я в таких случаях фиксирую не общее “есть вопросы”, а конкретные пункты. Например: “не определено условие короткого маршрута”, “не выбран владелец исключения”, “не согласовано, какие данные видит руководитель”, “не понятно, какой статус проверяем на приемке”. С таким списком проще вернуться к руководителю или владельцу процесса.
Вопросы, которые помогают разобрать требование
Я обычно держу под рукой несколько вопросов. Они помогают быстро понять, где действительно спорное место, а где просто неудачная формулировка требования:
- какую проблему закрывает это требование;
- что случится, если сделать проще;
- для каких документов правило обязательно;
- кто принимает решение в спорной ситуации;
- кто подтверждает исключение;
- где в системе должен остаться след решения;
- что пользователь должен понять без отдельного объяснения.
Ответы на эти вопросы иногда показывают, что дело не в настройке системы. Не хватает владельца решения, согласованного правила или общего понимания статуса.
Рабочие замены в описании задачи
Я стараюсь не переносить в описание задачи фразы, которые звучат понятно только на встрече.
Вместо “убрать лишнее согласование” лучше написать, для каких документов этап пропускается и кто отвечает за признак типового сценария.
Вместо “если срочно, можно обойти маршрут” лучше описать, кто подтверждает срочность, где фиксируется причина и видно ли это в истории документа.
Вместо “руководитель должен видеть документы” лучше уточнить, что именно нужно видеть: статус, срок, сумму, вложения, комментарии, историю согласования.
Вместо “сделать проще” лучше определить, какой шаг вызывает лишнюю нагрузку и какие данные можно получить автоматически.
Что фиксировать после обсуждения
Самая частая потеря решения — созвон закончился, участники разошлись, а через неделю каждый помнит договоренность немного по-своему. На приемке такие различия всплывают особенно болезненно: вроде бы обсуждали одно, а проверяют уже другое.
После обсуждения я фиксирую не только итоговую формулировку. Нужны открытые вопросы, владелец решения, исключения, последствия выбранного варианта, влияние на роли и доступы, а также то, что проверяем на приемке.
Например, по договорному процессу фиксация может быть такой: типовые договоры идут по короткому маршруту; признаки нетипового договора перечислены отдельно; отклонения от шаблона отправляются юристам; реквизиты для оплаты обязательны до передачи в бухгалтерию; срочное исключение подтверждает руководитель направления; причина исключения остается в истории документа.
Это не текст ради текста. Такая фиксация защищает договоренность от разного прочтения. А еще помогает разработке, тестированию и сопровождению работать с одним набором правил.
Где аналитик не должен решать за владельца процесса
У аналитика есть граница ответственности. Он может разобрать противоречия, подготовить варианты, показать последствия и зафиксировать открытые вопросы. Но он не должен единолично решать, чей аргумент важнее.
Не аналитик определяет, кто имеет право обойти согласование. Не аналитик выбирает допустимые исключения. Не аналитик решает, что важнее в конкретном процессе: скорость, контроль, юридическая проверка или удобство пользователя. Он может показать цену каждого варианта, но бизнес-решение должно оставаться у владельца процесса и ответственных подразделений.
Если владельца нет, это не мелочь. В такой ситуации я прямо фиксирую: решение не принято, владелец спорного пункта не определен, разработку по этой части начинать рискованно.
Что проверить, прежде чем отдавать задачу в разработку
Перед передачей описания задачи я проверяю несколько вещей:
- кто принимает финальное решение по спорным правилам;
- какие подразделения затронуты и все ли участвовали в обсуждении;
- какую проблему закрывает каждое спорное требование;
- какие исключения нужны и кто их подтверждает;
- что изменится в ролях, доступах, статусах и истории документа;
- что именно проверяем на приемке.
Если на эти вопросы нет ответа, аккуратная формулировка в описании задачи не спасет. Разработка все равно упрется в эти места.
Признаки, что расхождение еще не разобрали
- участники одинаково говорят “согласовано”, но имеют в виду разные действия;
- решение есть только в устной форме;
- нет владельца спорного правила;
- исключения описаны словами “иногда”, “срочно”, “по ситуации”;
- часть заинтересованных сторон не участвовала в обсуждении;
- разработка уже началась, а правила продолжают меняться.
Что я не утверждаю
Я не утверждаю, что аналитик должен решать конфликты за бизнес. Это не его роль.
Я не считаю HR, бухгалтерию, юристов, продажи или пользователей источником проблем. Обычно каждая сторона защищает свою ответственность.
Я не предлагаю превращать каждое обсуждение в большой регламент. Для простых изменений достаточно короткой фиксации. Но спорные правила нельзя оставлять на уровне “потом разберемся”.
Я не говорю, что все нужно согласовывать бесконечно. Иногда правильное решение — упростить маршрут. Вопрос в том, чтобы сделать это осознанно и понятно для всех затронутых сторон.
Финальный вывод
В работе с документами аналитик часто видит то, что не помещается в короткую формулировку задачи. Один участник просит ускорить маршрут. Другой думает о проверке отклонений. Третий смотрит на данные для оплаты и учета. Разработчик спрашивает, какое условие нужно реализовать. И если общего правила нет, система не сможет угадать его за участников.
Практическая польза аналитика здесь в том, чтобы вытащить расхождение наружу до разработки. Понять, что стоит за требованием. Проверить, кого затрагивает решение. Сформулировать варианты. Зафиксировать владельца, исключения и последствия.
Тогда в разработку уходит не спор, замаскированный под задачу, а рабочее правило, которое можно реализовать, проверить и сопровождать.