Developing requirements for conflicting legislation
Many products focused on the international market are aimed at serving customers who are subject to different, often contradictory financial regulations and government laws.
Using the example of our project, I will tell you how well we coped with this and what practices we have developed.
I made a report on this topic at SECR-2016, the slides are attached at the end of the article.
')
In our situation, the general functionality demanded by all clients, for each of them, had its own rules imposed by financial and legal regulation. In this case, the most important thing is not to lose all these subtleties on the way from identifying these requirements to meeting customer needs.
Our application helps clients of one well-known investment bank to manage depositing and withdrawing pledges for clearing their transactions.
The application supports two business lines:
Clients are represented by three regions with a unique financial regulation:
Thus, the same feature should be made taking into account all the subtleties of each business line and region.
Initially, our team worked under the control of a very competent BA on the part of the customer, who led the application from the moment of his birth, and there were no particular problems.
But one day he quit and everything changed. They gave us two acrobat brothers from a consulting firm, who immediately developed vigorous activity, figured out something, set some tasks for us, were a gag in each barrel.
And at the UAT stage, there was a complete failure. Consultants so skillfully mixed the rules for repayment of collateral in the EUR and UK regions, that the resulting functionality was unacceptable for either one or the other. This, as well as other moments not taken into account by them, crossed out about six months of our work.
The consultants were expelled, and we were sent to float freely with the new PM.
I had to adjust our work with customers and with the project almost anew. And that's what we did:
Organizational changes
Previously, we worked with customers through BA, now, we work with them directly. Customers are five people. For each pair of business line + region. PM participates only at the stage of determining the work plan and sorting client clients by priority.
In the future, he does not interfere in the work process, following only the release calendar and being responsible for budgeting when we need to order revision from some adjacent system.
The rest of the work is done by the team, coordinating the requirements, filling the releases and conducting a demo directly with customers.
Due to this, we make the most effective use of the time of communication with customers, without intermediate stages and associated distortions. We manage to find out everything we need without delaying the development.
User stories
We began to ask not only the question “Why?”, But also “Who?” And “How?”. The specifics of customers' work under different regulators are different and it is vital to know how exactly the customers of those regions affected by it will use it.
For example, according to the rules of the UK regulation, you can repay debts only in the currencies in which they are exhibited. And it turned out that one of the clients uses a rare currency, the balance on which can be obtained only after the transaction day closes for this currency. So, suddenly, a whole new elephant came out and had to go to the subcontractors, change the schedule for providing balance.
Therefore, it is extremely important to know not just what customers do in different regions, but how exactly they do it.
Impact analysis
To manage requirements, we use JIRA + Confluence. Therefore, at the establishment of Story, we indicate the labels of all business lines and regions that are affected by the requirements described in it.
Due to the fact that JIRA is integrated with Stash, during the impact analysis, we first find all the tasks related to the search object, we see that these tasks affected and then, by commitments, the developers much more accurately identify the dependencies and unwanted impacts.
This method works much better than just optimistic search by code.
Integration
The IT landscape of an investment bank is vast and diverse. For this, you need to know exactly where that which sends your application to other systems will rest.
For example, the consulting consultants ignored this moment, limiting themselves only to the first level of integration and looked at what’s behind the system where our application unloads the movements of securities for the UK and EUR, there are two more, one for EUR, the other for UK.
As a result, it turned out that the British placed securities into the account, but they did not appear on the balance sheet.
Unpleasantness.
QA
To prevent undesirable effects, for each region and business line on which the feature should not affect, we introduced negative steps in the test, checking that for these customers everything will work just as before, despite the fact that their neighbors will receive a new or a modified feature.
UAT (user acceptance)
We began to do excess UAT. Previously, if we, for example, had 30 cases, we divided them equally between customers and it turned out to be six each. Now, each customer receives a complete set of cases that affect his combination line + region.
Those. with the same 30 cases, one could have 25 cases, another 20, and the third only 5, and so on. The more regions and lines affected the case, the more it was duplicated among customers. This, of course, increased their load on acceptance, but we were able to convince them of the benefits of this very approach.
Having applied all the methods described above, we have been working successfully for almost a year, we have had three releases and have not received a single UAT or PROD incident in all this time.
Using the example of our project, I will tell you how well we coped with this and what practices we have developed.
I made a report on this topic at SECR-2016, the slides are attached at the end of the article.
')
The essence of the problem
In our situation, the general functionality demanded by all clients, for each of them, had its own rules imposed by financial and legal regulation. In this case, the most important thing is not to lose all these subtleties on the way from identifying these requirements to meeting customer needs.
Initial data
Our application helps clients of one well-known investment bank to manage depositing and withdrawing pledges for clearing their transactions.
The application supports two business lines:
- Exchange Clearing (Listed Derivatives)
- OTC Clearing (Cleared Over-the-Counter)
Clients are represented by three regions with a unique financial regulation:
- US - USA
- EUR - Europe
- UK - United Kingdom
Thus, the same feature should be made taking into account all the subtleties of each business line and region.
Initially, our team worked under the control of a very competent BA on the part of the customer, who led the application from the moment of his birth, and there were no particular problems.
But one day he quit and everything changed. They gave us two acrobat brothers from a consulting firm, who immediately developed vigorous activity, figured out something, set some tasks for us, were a gag in each barrel.
And at the UAT stage, there was a complete failure. Consultants so skillfully mixed the rules for repayment of collateral in the EUR and UK regions, that the resulting functionality was unacceptable for either one or the other. This, as well as other moments not taken into account by them, crossed out about six months of our work.
The consultants were expelled, and we were sent to float freely with the new PM.
What we did
I had to adjust our work with customers and with the project almost anew. And that's what we did:
Organizational changes
Previously, we worked with customers through BA, now, we work with them directly. Customers are five people. For each pair of business line + region. PM participates only at the stage of determining the work plan and sorting client clients by priority.
In the future, he does not interfere in the work process, following only the release calendar and being responsible for budgeting when we need to order revision from some adjacent system.
The rest of the work is done by the team, coordinating the requirements, filling the releases and conducting a demo directly with customers.
Due to this, we make the most effective use of the time of communication with customers, without intermediate stages and associated distortions. We manage to find out everything we need without delaying the development.
User stories
We began to ask not only the question “Why?”, But also “Who?” And “How?”. The specifics of customers' work under different regulators are different and it is vital to know how exactly the customers of those regions affected by it will use it.
For example, according to the rules of the UK regulation, you can repay debts only in the currencies in which they are exhibited. And it turned out that one of the clients uses a rare currency, the balance on which can be obtained only after the transaction day closes for this currency. So, suddenly, a whole new elephant came out and had to go to the subcontractors, change the schedule for providing balance.
Therefore, it is extremely important to know not just what customers do in different regions, but how exactly they do it.
Impact analysis
To manage requirements, we use JIRA + Confluence. Therefore, at the establishment of Story, we indicate the labels of all business lines and regions that are affected by the requirements described in it.
Due to the fact that JIRA is integrated with Stash, during the impact analysis, we first find all the tasks related to the search object, we see that these tasks affected and then, by commitments, the developers much more accurately identify the dependencies and unwanted impacts.
This method works much better than just optimistic search by code.
Integration
The IT landscape of an investment bank is vast and diverse. For this, you need to know exactly where that which sends your application to other systems will rest.
For example, the consulting consultants ignored this moment, limiting themselves only to the first level of integration and looked at what’s behind the system where our application unloads the movements of securities for the UK and EUR, there are two more, one for EUR, the other for UK.
As a result, it turned out that the British placed securities into the account, but they did not appear on the balance sheet.
Unpleasantness.
QA
To prevent undesirable effects, for each region and business line on which the feature should not affect, we introduced negative steps in the test, checking that for these customers everything will work just as before, despite the fact that their neighbors will receive a new or a modified feature.
UAT (user acceptance)
We began to do excess UAT. Previously, if we, for example, had 30 cases, we divided them equally between customers and it turned out to be six each. Now, each customer receives a complete set of cases that affect his combination line + region.
Those. with the same 30 cases, one could have 25 cases, another 20, and the third only 5, and so on. The more regions and lines affected the case, the more it was duplicated among customers. This, of course, increased their load on acceptance, but we were able to convince them of the benefits of this very approach.
Total
Having applied all the methods described above, we have been working successfully for almost a year, we have had three releases and have not received a single UAT or PROD incident in all this time.
Source: https://habr.com/ru/post/315014/
All Articles