Бесшовная авторизация в экосистеме звучит как «один логин на все», но на практике это десятки сценариев. Разные компании группы, меняющиеся роли и доступы дополняются уникальными требованиями к безопасности, согласиям и жизненным циклам пользователей. Ошибки в логике здесь превращаются в массовые обращения в поддержку и плавающие дефекты. Которые сложно воспроизвести и еще сложнее — перевести на язык бизнеса.
Чтобы развивать экосистему без хаоса, заказчику понадобилось усиление аналитиком-проектировщиком. Инфраструктурой пользовались страховые и инвестиционные компании, медицинские клиники, аэропорты, отели и туроператоры. Специалист iStaff-it закрыл полный цикл — от сбора бизнес-ожиданий до создания задач на разработку и сопровождение изменений в Agile.
Где чаще всего ломается «единый вход» в экосистеме
Проект развивался в контуре крупной страховой экосистемы. В единый пользовательский опыт укладывались сервисы группы из разных доменов — финансы, инвестиции, медицина, travel-направления и партнерские сценарии (клиники, аэропорты, отели, туроператоры и пр.)
На таком ландшафте авторизация — это не форма логина, а набор правил и договоренностей. Идентификация, роли, доверенные сессии, переходы между доменами, события и статусы — фиксировать нужно абсолютно все.
В таких системах проблемы редко лежат в одном месте — они «вылезают» на стыках команд и сценариев. Поэтому аналитика стартовала с того, чтобы описать зоны риска, где требования чаще всего противоречат друг другу или остаются недосказанными:
- Единые термины и роли. Один и тот же пользователь в разных сервисах может иметь разные статусы и права.
- Сессии и доверие. Что считается «активной» сессией, как она передается, когда требуется повторная проверка.
- Согласия и политики. Какие согласия нужны, где и как их запрашивать, как хранить и обновлять.
- Переходы и исключения. Что показываем пользователю при ошибках интеграций, истечении сессии, смене устройства.
- Границы ответственности. Кто владелец сценария на стыке двух систем, кто решает инциденты и кто меняет правила.
После фиксации этих узлов требования перестали быть пожеланиями и стали проверяемыми. Работа аналитика данных в IT позволила собрать понятный набор сценариев, исключений и точек контроля. Дальше их можно раскладывать на постановки и тестировать без бесконечных трактовок в каждой команде.
Как требования упаковывали в ТЗ и постановки, понятные разработке
На старте у стейкхолдеров обычно есть представление «как должно быть», но нет единого ответа на вопросы «что именно меняем», «как измеряем готовность» и «какие ограничения нельзя нарушать». Поэтому работа аналитика выстраивалась как последовательность: сбор входов, формализация, согласование, затем — упаковка в документы и постановки, которые можно взять в работу спринт за спринтом.
В рамках проекта специалист iStaff-it закрывал аналитические задачи:
- сбор, формализация и согласование бизнес-требований и функциональных требований;
- подготовка и согласование технических заданий и постановок на разработку;
- проработка вариантов изменений под требования бизнеса (включая альтернативные сценарии и компромиссы);
- оценка трудоемкости аналитических работ и планирование аналитической части;
- постановка задач команде разработки и сопровождение требований до внедрения.
Списки задач аналитики в IT — только верхний уровень. Главная ценность в том, что каждый пункт превращался в артефакт, с которым удобно работать: формулировки без домыслов, границы, критерии приемки, зависимости и точки согласования. Это снижает риск, что бизнес обсуждает одно, а в разработку уходит другое.
Процессы, сценарии и схемы — чтобы исключения не съели релиз
В экосистеме с большим количеством участников особенно важно описывать не только «счастливый путь», но и пограничные случаи. Без моделей процессов команда быстро начинает трактовать требования по-разному, а дефекты становятся системными — часть сценариев не учли, часть ошибок не обработали.
Чтобы этого избежать, наш Senior-системный аналитик описывал и согласовывал процессы на бумаге до того, как они становились кодом:
- описание и разработка схем бизнес-процессов (as-is / to-be по ключевым потокам);
- фиксация точек входа/выхода, ролей, статусов и событий, влияющих на доступ и сессию;
- разбор влияния изменений на соседние сервисы и зависимые интеграции;
- согласование логики с владельцами процессов и техническими стейкхолдерами.
Когда процессы разложены по шагам, обсуждение становится предметным. Можно пройтись по цепочке, найти «дыры», заранее договориться об обработке ошибок и исключений. Это напрямую влияет на качество реализации и тестирования: меньше сюрпризов на финише и меньше доработок в пожарном режиме.
Agile-контур — как требования не терялись между спринтами и согласованиями
Экосистемные продукты всегда меняются: появляются новые сервисы, уточняются правила безопасности, расширяются партнерские сценарии. Важно, чтобы изменения попадали в работу контролируемо — с приоритетом, оценкой, зависимостями и ясным объемом.
В проекте аналитик поддерживал дисциплину изменений в Scrum/Kanban и в инструментах команды:
- ведение задач и требований в JIRA — структура, статусы, связи, критерии готовности;
- актуализация документации в Confluence — единая база знаний, версии, решения и договоренности;
- оценка трудоемкости аналитики и помощь в планировании спринтов/потока;
- декомпозиция требований на задачи для разработки и сопровождение до релиза.
Так, команда получала управляемый бэклог: требования не расползались по чатам и созвонам, а проходили понятный цикл — от согласования до внедрения. А стейкхолдеры видели прозрачность по изменениям — что делаем сейчас, что отложили и почему.
Итог — 2 707 часов прикладной аналитики без «бумаги ради бумаги»
За 2 707 часов аналитик помог удержать экосистемный проект в управляемой зоне. Требования собирались и согласовывались без потери смысла, изменения проходили через прозрачный процесс, а разработка получала постановки, которые можно брать в работу по Agile-ритму. Параллельно аналитика связывалась с UX/UI, чтобы сценарии авторизации работали предсказуемо — и в нормальных переходах, и в исключениях.
Если вам нужен подбор сильного системного аналитика под проект (без найма в штат и без аутсорсинговых команд), обращайтесь к компании iStaff-it. Мы подключим специалиста в контур команды, заранее согласовав задачи, стек и процесс управления изменениями.
