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

Привет! Меня зовут Яна Мотрий, я старший системный аналитик в Контуре. Моя команда развивает сервисы для партнёрской сети: внутреннюю PRM, где сотрудники Контура ведут партнёров, и личный кабинет, куда заходят сами партнёры.

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

Статья будет полезна системным аналитикам уровня middle+, а ещё — аналитикам из заказной разработки, которые присматриваются к продуктовым командам или бизнес-анализу.

Контекст про партнёрскую сеть Контура и задачу

У нас в Контуре есть партнёрская программа, участниками которой могут стать как физические, так и юридические лица. Всё устроено стандартно: юрлицо или физлицо становится партнёром, предлагает наши продукты клиентам или коллегам и получает вознаграждение. 

Все регистрации и оформления происходят в Панде — самописном сервисе для управления партнёрами, который мы запустили в 2023 году. Им пользуются как сотрудники, которые работают с партнёрами, так и сами партнёры. 

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

Однажды пришёл руководитель реферальной программы с размытой идеей по автоматизации процессов. 

Моё первое действие в задаче такого типа — не начать проектировать решение, а найти ответ на вопрос: «какую проблему мы решаем и актуальна ли она?». Поэтому я начала с изучения процессов в работе с реферальными партнёрами. Нужно было разобраться, кто и как регистрирует их, как устроена их работа и вознаграждение. 

При этом заказчик сразу сказал, что у физлиц процесс сложный и запутанный, поэтому заниматься ими сейчас не стоит. Зато по юрлицам всё было прозрачно, так что автоматизировать работу мне предложили именно с ними.

Но мне стало интересно, что за сложности есть с физлицами, так что я продолжила копать. 

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

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

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

Ещё коллеги показали, как вручную заполняют анкету для бухгалтерии и отправляют её письмом.

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

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

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

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

Нашла неудобный процесс и проверила, стоит ли браться за автоматизацию

Прежде чем что-то предлагать, я оценила, будет ли ценность от изменений. Рассуждала так.

🤔 С одной стороны, у задачи есть очевидная бизнес-ценность: реферальные партнёры — канал привлечения новых клиентов в Контур, поэтому любая задержка или ошибка в оформлении партнёра стоит компании времени и денег.

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

🤔 Плюсы были и для самих команд. Бухгалтерия и поддержка занимаются множеством разных задач — регистрация партнёров была лишь одной из рутинных. Если решение ускорит эту работу, у команд освободится ресурс на более сложные задачи.

🤑 Ну, и конечно, мы с заказчиком рассчитали прирост регистраций реферальных партнёров после автоматизации. По нашим данным, он составил бы 30%. 

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

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

Собрала карту процесса и описала все узкие места

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

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

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

После каждого этапа создавала новые декомпозированные схемы — так лучше понимала процесс на каждом шаге.

После интервью и декомпозиции всех этапов сформировала верхнеуровневое видение результата:

— Какие есть проблемы.

— Как их можно решить.

— Как поменять процесс организационно.

— Как поменять его технически.

— Что и как можно автоматизировать.

Из общей идеи «где-то можно что-то автоматизировать» получился конкретный список проблем и вариантов их решения.

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

Предложила 3 варианта решений и организационные изменения

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

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

— только Панда; 

— биллинговая система и Панда пополам;

— только биллинговая система.

Считаю, предлагать всегда нужно 2–3 альтернативы с честной оценкой рисков, затрат и сроков. Это позволит перевести дискуссию с заказчиком из плоскости «можно/нельзя» в плоскость осознанного управленческого выбора.

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

Собрала сценарий взаимодействия между сервисами и выступила связующим звеном между командами

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

Дальше углубилась в частности 👇

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

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

Согласовала работу с персональными данными. Договорилась с безопасниками, как будем хранить данные о зарегистрированных партнёрах и кому сможем их показывать. 

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

— Какие есть эндпоинты.

— Как проходит авторизация.

— Что приходит на вход и что возвращается на выходе.

— Где какие проверки происходят.

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

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

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

В итоге процесс упростился: часть этапов теперь происходит автоматически и не требует включаться бухгалтеру или сотруднику поддержки 👇

Вывела продукт в продакшен

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

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

Так как процесс изменился — как организационно, так и в плане инструментов — сотрудников нужно было обучать работать по-новому. И эту часть я тоже решила взять на себя. В конце концов, кто может знать процесс лучше аналитика, который его проектировал? 🙂

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

Результат: с получаса на одного партнёра до минуты на всех

Уменьшили вовлечение команд в регистрацию партнёров и упростили процесс буквально до двух кликов в PRM-системе.

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

⭐ Поддержка тоже стала подключаться к процессу в разы реже. Один шаг долго оставался ручным: паспортные данные партнёра нужно было сверять человеку. Ошибка в одной цифре — и Социальный фонд возвращал сведения на перепроверку. 

Сначала это целиком делала поддержка, а позже подключили нейросеть, чтобы распознавать данные. Теперь, если модель уверена — человек не нужен. А если уверенность ниже порога — просим поддержку проверить.

10 рекомендаций из моего опыта: как действовать, если к вам пришла размытая задача

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

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

1. Валидируйте актуальность и бизнес-ценность до детальной проработки. Первый шаг в «размытой» задаче — задать вопрос «какую проблему решаем, и актуальна ли она?». Если ценность неочевидна, исходную проблему можно пересмотреть и решить, есть ли ценность у задачи или нет.

2. Двигайтесь от общего к частному. Сначала соберите весь контекст и опишите жизненный цикл задачи целиком. Это поможет не утонуть в деталях на старте и покажет полную картину.

3. Зафиксируйте «как есть» и проверяйте гипотезы дёшево. Объективно опишите текущее состояние — это защита от ложных предположений. Ценность гипотезы проверяйте интервью и метриками за недели, а не разработкой MVP за месяцы.

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

5. Презентуйте разные варианты решений, а не единственный «идеальный». Предложите 2–3 альтернативы с оценкой рисков и затрат, а техническую реализуемость оценивайте вместе с разработчиком.

6. Формализуйте постановку, границы и контракты интеграций. Письменно зафиксируйте требования, границы и API-контракты — это снизит риски разночтений при разработке. 

И показывайте черновики на ревью разным ролям: это проверка качества и снижение bus factor.

7. Делайте «дешёвые» чек-пойнты видимости. Лучше рано показать схему, драфт или прототип и получить обратную связь, чем принести готовое и услышать «это не то». Промежуточный показ — инструмент управления рисками.

8. Жёстко валидируйте состав MVP. Каждую часть проверяйте вопросом: «Можно ли выпустить без этого и всё ещё получить ценность?». Если да — уносите в следующие итерации.

9. Сопровождайте разработку, защищая приоритетную аналитическую работу. Обновляйте постановку по ходу реализации. А неблокирующие вопросы собирайте списком и разбирайте разом: они не должны вытеснять аналитику по другим задачам.

10. Планируйте безопасный релиз и замыкайте цикл знаний. Продумайте поэтапную раскатку, мониторинг и сценарий отката, заложите ресурс на обучение пользователей. 

После релиза сравните метрики с целями и проведите ретроспективу — она превращает прошлую неопределённость в знания.