🕕 🚺 🧒🏾 Startup inside the corporation 😋 🧒 👉🏼

Hi, my name is Andrey Vanin and I am developing and launching brokerage and fintech products. Today is exactly a year since I work in BCS, where in a team of eight people we are developing the fintarget.ru project.

Below is a (not) big story about how to implement a startup in a huge company, release it to the market and at the same time not burn out among tons of memos and approvals.

Intro

Forget about all Agile manifestos and creating a comfortable work environment if you want to achieve results. In the management of hopeless projects, it is not the presence of the PlayStation office and the obligatory scrum rituals that come to the fore, but the team’s ambitions and personal motivation.

If your developer wants to be the best, he will not play air hockey and he does not care if there is a rest room in the office (there is a spoiler). If your project wants to achieve respect, he will learn to walk on his head and solve any problem, whether it be another inconceivable job of replacing a broken chair or the need to coordinate a process that is not there.

If the front-end provider has an outstanding mortgage - offer him a choice - either PS4, or plus a bonus in the amount of the same amount. Your task is not to be a nanny in the project, but to ensure the result in such a way that both the team and the customer are satisfied. Even if it’s not possible.

On your marks

I joined the company in early April 2019. Two developers sat in the office, a customer and half a project manager who had never before been involved in development projects. We had to quickly develop a system from scratch from scratch, which they tried to do three or four times before, but in five years no one was able to bring a sane and user-friendly product to the market.

On my desk was a printout of a presentation of five slides - how everything will be fine, how it will look, theoretical architecture, how much money it should bring and how much money it will take. And not a word about the product, not a single mention of related units, not a single process and understanding how all this should take off.

But the deadline was announced - to release in September. And we sat down to work.

Double pivot

The first version of the product implied the creation of an internal infrastructure without its own front-end solution. It was assumed that the product will be presented on the shelf of the mobile application, and my two developers will only support the backend and the logistics of information flows. This approach guaranteed the failure of the project already in June, as in the parallel business direction the application team began to undergo significant changes and its backlog until the end of the year was very foggy. And we decided to make an MVP product on the current web front of the company. This was the first turn.

The simplest solution in this situation is to outsource the UX designer and layout designer, draw pencil layouts, get the design and give it to development. But only independent startups can. We are a startup within a large company, where the designer cannot pay in cash, and all front work must be done through coordination with marketing and lawyers. It was more difficult, but did not stop the development of the kernel, so we went into marketing.

Almost immediately, the problem of stratification of the overall picture arose - marketing did not know what we were doing technically, and the developers did not understand how it all should have looked. Before the May holidays, we first opened confluence and sat down to describe the screens.

Until mid-May, a detailed understanding of how the product should work existed only in my head and on about fifty pages describing the algorithms and screens. It was a big risk (the trick was done by professionals! Do not repeat - it is dangerous!), But at the same time each member of the team knew what to do and was loaded with work two months in advance.

The project smoked, coordinating the next version of the architecture and the interaction of the systems, the team lead went inside and started picking the code, and the third developer (hired with me on the same day) almost a month understood the integration mechanisms. And that was the hardest part. The company has two dozen systems, with six of which we needed to integrate.
At some point, it became clear that the appointed team lead did not fit into the pace of the team and had to be replaced. The second developer took his place, and for the vacant vacancy we took a programmer with a background of a candidate of physical sciences. Looking ahead, I’ll say that it saved us.

However, almost immediately it became obvious that we also won’t be able to fit into the internal web circuit, and the customer agreed on the only saving solution at that time - we create our own web-based product front with our branding and support team. Inside the department, we hastily announced a competition for the name of the product and ultimately chose the option that was voiced by the very first, since there was one good domain in my personal piggy bank, and there was nothing better for everyone to vote and creative. So the brand fintarget.ru appeared. And that was the second, key turn.

About team

Millions of books on development management give you standard teamwork templates and standard processes, forgetting that each team is unique and requires an individual approach.

Many factors can influence work and communication in a team: age, marital status, and even preferences in music. Nevertheless, almost never the products pay attention to this, and, as a rule, focus on side factors - the location and size of the table, the blinds on the windows, headphones with ventilation and other little things that are "not annoying."

The stars came together and we managed to find a chain of relationships in which each and everyone always had something to talk about other than work. And when you have built communication - you can calmly deal with the distribution of roles.

At the stage of debugging team processes, we have formed such a hybrid scheme that it does not fit into any of the existing templates.

First , we abandoned the analyst. Absolutely. The role of the analyst is distributed between the team lead and the product owner, and the detail of the processes is modernized and fixed during the testing of the service. This is the continuous improvement of the product that the proponents of Edge love to talk about.

Secondly, we have erased the line between the powers of the product manager in the person of the customer and the product owner. Two employees perform two roles online, without delimiting authority and not being afraid of responsibility in decision-making. It was especially interesting to watch developers who saw how the owner and manager hoarsely argued about CJM or page layout. This, incidentally, greatly influenced the involvement of the team.

Thirdly , at the kernel development stage, we completely abandoned sprints with a hard backlog and used an iterative approach based on refinement and addition of functionality during development. Remember how jpeg images were loaded in the browser at the beginning of the century? That's about the same way we developed the product core.

Fourth, we (forcedly) strictly delimited the functionality of the developers. A separate developer, “microservice”, was assigned to each sector, which was responsible only for its segment. We have five such segments in the project: integration with internal systems, integration with exchange systems, kernel product algorithms, OpenAPI, and the front.

And fifthly , all the resources of the project manager of our department that we had were aimed solely at managing external teams responsible for finalizing the systems with which we needed to integrate, and at implementing all the procedures for coordinating and integrating a startup into the company's infrastructure.

This project hero for three months spent more than one and a half hundred different services, described and documented a dozen new processes, and it was he who in practice refuted the popular theory of the impossibility of making startups within large companies.

This approach allowed us to plan the task pool, fix all the requirements for MVP, and as a whole, when it became clear that the mechanism worked, I, as an oouner, went on vacation almost calmly. It was July, and as it is written in one famous project management novel, when all processes are defined, tasks and deadlines are known, you just have to watch.

On the first of August we had the core of the system assembled, almost all the preparatory work was done, the beta version of OpenAPI was assembled, the front was drawn and made up and there was still a week left to polish the algorithms and wait for the front-end to work, which was “just to” collect everything This is a working MVP.

Event trees

It is possible to collect the startup project infrastructure in a closed test loop as much as you like, but the project will never take off without integration with the company's key systems. This is the main problem of work of startups within corporations: more than 80% of projects die without finding the opportunity to integrate and comply with all corporate requirements and regulations.

There are several such systems in the brokerage business: trading and accounting systems, integration buses, CRM, a catalog of services, and a dozen more systems and mechanisms that are very strictly regulated and monitored by information security services.
Integration without exaggeration was the most serious test for the project and the team, and we had to kill a total of about three man-months of work on it.

A key role in this process was played by the rule “first break all the rules”. We initiated several parallel integration scenarios at once - from the most official (through the Project Passport, coordinating the architecture, creating a test circuit and transferring all the instructions for the release policy and support) to the most unofficial one - we develop in the combat circuit, closed from the outside and test the system on our own brokerage accounts.

The details of this story deserve a separate article, but the key that has been achieved consists of several points:

. « – – crm– – – – », , ,
- « - », « » .
The “preprod” testing approach has greatly increased the involvement of developers, made it possible to test UX in practice before releasing the product to the outside world and, most importantly for the project, to debug the correct operation of the system algorithms on real market and client data.

And most importantly - never consider wasted time on parallel processes during integration. As in advertising budgets, you still never know which half of the budget you spent in vain. Just build a tree of options and start the processes: some branches will disappear by themselves as hopeless, some will merge into one, and when one of them leads you to the result, it will be only your Champion Path. Because in another project, the same scenario may not work.

What is the result

The working MVP of the project was assembled at the end of August, in parallel, a version of the emulator for accrediting the program at NAUFOR was implemented and a hundred and fifty pages of supporting documentation for registering software were written. The first real transactions on the system to the joyful screams of the team took place on August 31. Legal changes to company documents and client regulations came into force on September 1, and before the system was accredited, we had time to debug and lick the interfaces.

In MVP, we had neither currency accounts, nor futures, nor even our own brokerage account, but the key task was completed - the infrastructure was implemented, the preprod became a prod, the customer service was implemented.

On September 17, Fintarget software was added to the register of accredited auto-follow programs, and the very next day we saw the first customers connecting to the system. There was still a lot of work to expand the functionality and bring the MVP to the state of a full-fledged and self-sufficient product, but this is a completely different and less interesting story: releases, sprints, backlogs and endless client analytics.