Разработка требований для противоречащих законодательств
На примере нашего проекта я расскажу как мы отлично с этим справились и какие практики выработали.
С докладом на эту тему я выступил на SECR-2016, слайды приложены в конце статьи.
Суть проблемы
В нашей ситуации, общий функционал, востребованный всеми клиентами, для каждого из них имел собственные правила, навязанные финансовым и юридическим регулированием. В таком случае самое важное не растерять все эти тонкости по дороге от выявления этих требований до удовлетворения клиентских потребностей.
Исходные данные
Наше приложение помогает клиентам одного известного инвестиционного банка управлять внесением и изъятием залогов для осуществления клиринга их сделок.
Приложение поддерживает две бизнес линии:
- Биржевой клиринг (Listed Derivatives)
- Внебиржевой клиринг (Cleared Over-the-Counter)
Клиенты представлены тремя регионами с уникальной финансовой регуляцией:
- US — США
- EUR — Европа
- UK — Соединенное Королевство
Таким образом, одна и та же фича должна быть сделана с учетом всех тонкостей каждой бизнес-линии и региона.
Изначально, наша команда работала под управлением очень грамотного BA со стороны заказчика, который вел приложение с момента его рождения и особых проблем не возникало.
Но однажды он уволился и всё изменилось. Над дали двух братьев-акробатов из консалтинговой фирмы, которые сразу развили бурную активность, что-то выясняли, ставили нам какие-то задачи, были в каждой бочке затычкой.
А на этапе UAT нас ждал полный провал. Консультанты настолько мастерски смешали правила погашения залогов в EUR и UK регионах, что полученный функционал оказался неприемлем ни для одних ни для других. Это, а также прочие неучтенные ими моменты, перечеркнули около полугода нашей работы.
Консультантов выгнали, а нас отправили в свободное плавание с новым PM’ом.
Что мы сделали
Пришлось налаживать нашу работу с заказчиками и с проектом практически заново. И вот что мы предприняли:
Организационные изменения
Раньше, мы работали с заказчиками через BA, теперь, мы работаем с ними напрямую. Заказчиков пять человек. Для каждой пары бизнес линия + регион. PM участвует только на этапе определения плана работ и сортировки клиентских хотелок по приоритету.
В дальнейшем он не вмешивается в процесс работ, следя только за календарем релизов и отвечая за бюджетирование, когда нам нужно заказать доработку у какой-то смежной системы.
Всю остальную работу делает команда, согласуя требования, наполнение релизов и проводя демо напрямую с заказчиками.
Благодаря этому мы максимально эффективно используем время общения с заказчиками, без промежуточных этапов и сопутствующих искажений. Мы успеваем узнать всё что нам нужно, не задерживая разработку.
Пользовательские истории
Мы стали задавать не только вопрос «Зачем?», но и «Кто?» и «Как?». Специфика работы клиентов под разными регуляторами отличается и жизненно важно знать как именно будет использовать новые возможности клиенты тех регионов которые это затрагивает.
Например, по правилам UK регуляции, погашать долги можно только в тех валютах в которых они выставлены. И оказалось, что один из клиентов использует редкую валюту, баланс по которой может быть получен только после того, как для этой валюты закрывается операционный день. Так, внезапно, вылез целый новый слон и пришлось идти к смежникам, изменять расписание предоставления баланса.
По этому крайне важно знать не просто что делают клиенты в разных регионах, но и как именно они это делают.
Impact analysis
Для управления требованиями мы используем JIRA + Confluence. По этому при заведении Story мы указываем метки всех бизнес-линий и регионов на которые влияют описываемые в ней требования.
Благодаря тому, что JIRA интегрирована со Stash, при проведении анализа воздействия, мы сначала находим все задачи связанные с объектом поиска, видим что именно эти задачи затрагивали и потом уже по commit’ам разработчики гораздо точнее выявляют зависимости и нежелательные воздействия.
Данный метод работает гораздо лучше чем просто оптимистичный поиск по коду.
Интеграция
IT-ландшафт инвестиционного банка обширен и разнообразен. По этому нужно точно знать, где упокоится то, что посылает ваше приложение другим системам.
Например, братья-консультанты проигнорировали этот момент, ограничившись только первым уровнем интеграции и просмотрели что за системой куда наше приложение выгружает движения ценных бумаг для UK и EUR, стоят ещё две, одна для EUR, другая для UK.
В итоге получалось что англичане ценные бумаги на счет клали, а на балансе они не появлялись.
Неприятненко.
QA
Чтобы предотвратить нежелательное воздействие, для каждого региона и бизнес-линии на которые фича не должна влиять, мы ввели негативные шаги в тесте, проверяющие что вот именно для этих клиентов всё будет работать так же как раньше, не смотря на то что их соседи получат новую или измененную фичу.
UAT (приемка пользователями)
Мы стали делать избыточный UAT. Раньше, если у нас, допустим, было 30 кейсов мы делили их поровну между заказчиками и получалось по шесть на каждого. Теперь же, каждый заказчик получает полный набор кейсов которые влияют на его комбинацию линия+регион.
Т.е. при тех же 30 кейсах, у одного могло быть 25 кейсов, у другого 20, а у третьего всего 5 и так далее. Чем больше регионов и линий затрагивал кейс, тем больше он дублировался среди заказчиков. Это, конечно, увеличило на них нагрузку при приёмке, но мы смогли убедить их в пользе именно такого подхода.
Итог
Применив все описанные выше методы, мы успешно работаем уже почти год, провели три релиза и не получили ни одного UAT или PROD инцидента за всё это время.
Комментарии (1)
amarao
11 ноября 2016 в 16:44
0↑
↓
А где разработка-то?Здравствуйте, меня зовут Вася и я пишу КОД.
Спрашивайте меня вопросы.
