Product development: two years of work on the mobile application of Otkritie Bank / Redmadrobot's blog

Hello, Habr! We already wrote about how in November last year we started work on the largest update of the Otkrytie mobile bank for its entire existence. In this article we will talk about the processes - about how we develop the product together with the Discovery Digital.

From Waterfall to Agile

Two years ago, we went to the AppStore and Google Play.
Then in the “Discovery” they lived on the waterfall system and had not yet split up large features in order to introduce them in parts, and the first major update happened a few months after the launch, when it became possible to open deposits directly in the application. But gradually, the length of iterations began to decrease, and the transition to Agile made it possible to improve the product almost continuously.

One product and two teams

Today, the majority of the digital products of the bank are responsible for the special division of Otkritie Digital, and Redmadrobot has a dedicated team of 10 people, which, together with Otkrytie, has been working on the bank’s mobile application since its very first version.


Discovery Office Digital

The Discovery and Redmadrobot teams sit in different offices, but this does not interfere with the super-dense interaction on the product.


Redmadrobot office

Anton Poderechin, Redmadrobot iOS developer
“For the first six months, we regularly landed in the office of Digital Discovery, it happened, I worked there 3-4 days a week. This was necessary for tight synchronization, plus security did not allow access to some test environments from the outside. Now both teams constantly go to each other for meetings, but no more ”

Some time ago, we switched to a special sprint pulse (a work schedule for every 2 weeks, according to which the team releases product updates), which is convenient for both teams - now everyone who “supplies” any features for a mobile application works in part of this sprint pulse. At the start of each sprint, we synchronize, saying goals, tasks and how exactly they will be implemented during the sprint. Syncaps take place between teams every week. Sprint can include both the implementation of one or several new features, and tasks on R&D - whether it is changing the pin code of the card or analyzing the technologies for scanning and recognizing documents available on the market. Now, application updates in the store appear every two to three weeks.

Veronika Vasilieva, Project Manager, Redmadrobot
“The bank has a release policy when updates are released on the production environment, and we try to get into them when we need some improvements on the backend, because if we do not roll out our update on time, then the client will have nothing to connect to server side and have to wait a few weeks or months until the next release. When we decide to add any functionality, we always weigh how exactly it is best to do so that it is as convenient as possible from the point of view of implementation for all participants in the process. For two years, we learned how to work with the bank as if in fact we are a single team ”

In Redmadrobot, product development - the area of ​​responsibility of the art director, team leader, analyst and project manager, the latter projects the team work - plans to load developers, designers, testers and is responsible for financial performance.
The team has a rotation principle aimed at ensuring that all its members develop professionally - developers regularly switch to new interesting tasks (about once every six months), designers grow into art directors and are included in product management.

Arthur Sakharov, CTO, Redmadrobot (@mc_murphy)
“We have rules inside the company - regular assessments, rotation, etc. And we do not change this practice, including in product teams. Yes, during rotation, there is a partial loss of efficiency - any new person needs time to get used to the project, but we and Otkritie understand that risks are worked out in this way - stagnation threatens with the loss of valuable specialists who always want to develop. It is for these types of people that we at Redmadrobot are building our infrastructure, which allows us to saturate the production with various projects, technologies and keep movement around them. ”

Demo days

Once a month in the “Discovery” a demo is held - this is a four-hour event at which all teams involved in the development of digital products of the bank (not just mobile ones), in an informal setting, talk about their work for a month in the format of short presentations. This is a broadcast of experience to all digital teams, and a demonstration of products to top management. We participate in the demo with two teams - the product owner from the “Discovery” side talks about the performance of the application, and Redmadrobot - about new features.

Danila Berezin, Project Manager, Redmadrobot
“You have to understand that you can’t just say on the demo that for a month we refactored and fixed bugs. No one from the outside will understand this. Thus, the need for a presentation on a demo has always been some criterion in determining the sprint scout and the mandatory presence of features that are significant for the user. ”


Opening Digital and Redmadrobot teams after the demo day

We liked the demo days so much that we borrowed this practice and now we are conducting similar ones events inside Redmadrobot - in this way we organize the informing of employees about all the company's products.

Roadmap and review

Every year, together with the Opening of Digital, we shift the list of business tasks to the product component (that is, see how to “map” the requirements of the bank and our application) and then approve the document - this is how the roadmap of the mobile product and business is formed. Once a quarter, the Redmadrobot team reviews all the features of the application in order to prioritize and determine what will be included in future releases.


Digital Opening Office

We refuse some functionality at all if it has lost its relevance, but usually part of the planned is postponed and is simply implemented later, in the next update. Some features lie in the backlog for several months, since they require really complex and large-scale improvements on the bank side (for example, the auto payment function that we want to do for a very long time, just from this category). We always filter the functionality of the application with an eye on several parameters.

Large-scale update: maximum program and prioritization

In mid-2016, we decided to make a big redesign of our application. During the time that has passed since the launch of the first version of the product, business requirements and customer expectations have grown, platform capabilities and development tools have changed.


Of course, this is the “maximum program”, which we did not plan to fit into the first release. Here comes the moment when we need to prioritize. We were faced with the need to preserve all the functionality of the application, (hello, Captain Evidence! - but everyone remembers the epic failure with the launch of the new “Kinopoisk”), supplementing it with the highest priority from the list above.

Lean approach and startup mode

Our approach to major updates is based on the principle of lean - the launch of a product on the market that functionally does everything conceived, but is not necessarily polished to the end.

Grigory Matvievich ( fountainhead ), head of iOS development, Redmadrobot
“We immediately launch all the functionality, where each specific function will be workable, but without frills. In no case can we launch the bank application without transfers or without displaying accounts and other things that have become the de facto standard in mobile banking. At the same time, no one has canceled strict banking security requirements, tight deadlines and limited resources ”

In a sense, the team working on the Discovery app is a startup inside Redmadrobot, where work on the product is going very fast and is accompanied by constant brainstorming. The final list of functionality in the framework of a large-scale update, we formed on the basis of analytics, as well as the expertise of the entire team. Each core team member analyzed and compiled their own top strengths and weaknesses of the application. The general features featured were:

• Payments
• Patterns
• Transfer by phone number
• Transfer from card to card
• Chat
• Loyalty and product rates

All features candidates for release are run through three business focuses of the bank:

• Building an active customer base
• Increase Transaction Frequency
• Transition to digital

The application is covered by analytics, we constantly observe how the scenarios are passed, where users “fall off” and work on improving the product: we review some use cases, modify new features on the backend.

Anastasia Grafskaya, project manager, Otkritie Digital “
It is important to be aware that there is never an ideal product state - today’s ideal product will be different tomorrow, and its improvement will be achieved through constant updates. Thinking about how a mobile bank should develop, we always proceed from the user needs that it should cover. Solving real customer problems is our priority, and good business performance of a mobile product is always a derivative of a positive user experience. ”

Design from needs and user engagement

We think through the ways in which users come to some function in the application, and with the help of usability tests we make them the shortest and most logical. But we do not proceed from the fact that each user must discover every function, but from the fact that he will find what he needs, as the need arises.

Arthur Sakharov, Technical Director, Redmadrobot (@mc_murphy)
“Making an introduction where all the features of the application are detailed as much as possible or dumping absolutely all the functions on the main screen is not our method. That is, we do not solve the problem of attracting the attention of the user to all functions of the application at once. Our task is different - to calculate the user's need and the context in which he will try to close this need - and then place the function in this context ”

Suppose a bank client wants to reissue a card, goes to a mobile application and tries to find this function there. It is logical that most users will go into the information about their card, after that, most likely, the user will begin to see what additional information is there and see the function of re-issuing and ordering the card. Or the application itself should prompt the user about the expiration of the current card for a couple of weeks and offer an automatic reissue.

The approach to designing from needs suggests that the application can be quite complex in functions, but if you do not use them, they will exist unnoticed by the user. An example of such a product is Uber. When a user opens it for the first time, the application seems extremely simple. But if you start wanting more from him than just calling a taxi, you quickly get to the new features, and the two buttons turn into eight. And if you dig further to resolve some non-standard issue, a few more menus will appear.

Total

By combining technological and product-banking expertise, Otkritie Digital and I achieved a synergistic effect. The bank does not have to think about organizing and developing an effective inhouse product development process. We at Redmadrobot receive insights and expertise in fintech from the largest private bank in Russia. We work for one common goal - to make the most convenient mobile banking service on the Russian market. To minimize the number of actions that the user needs to do manually by transferring these tasks to IT systems through a mobile application.

Elisei Zakharov, Marketing and Mobile Application Development Manager, Digital Discovery
“The client of the bank is the center of the ecosystem. Each of us is in financial interaction with family and friends, the state, the employer, service providers, and the wider the range of transactional activities of the user that covers the mobile product, the better it is. It is impossible to build such a service in one month or even a year, but we are moving towards the goal, step by step. The next step is more tight integration with external systems and further development of the entire payment functionality of the “Discovery” application. Well, very soon - completely updated Android - stay tuned! ”