Розробка вимог для суперечать законодавств

Багато продукти, орієнтовані на міжнародний ринок, націлені на обслуговування клієнтів, що знаходяться під дією різних, часто навіть суперечать фінансових регуляцій і державних законів.

На прикладі нашого проекту я розповім як ми відмінно з цим впоралися і які практики виробили.

З доповіддю на цю тему я виступив на 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 інциденту за весь цей час.


Джерело: Хабрахабр

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.