As a rule, the client turns to the IT company already with an idea. He has a lot of plans and ideas about what the product should be, but the customer does not always understand the technical side of the issue well. Our task is to go hand in hand with the client from the idea to a clear plan of action.
We conduct interviews
The first thing we do is ask the client the key questions. The answers will give us an idea of how and where we will move on.
Questions:
- 1. Who is the target audience of the product? Here we find out the portrait of a potential client: gender and age, geography, income level, and so on.
- 2. What problem does the product solve? And does the future application really cover the pain of users?
- 3. We will find out how the client sees earnings on the product, if monetization is generally assumed by the project. For example, profitability may not be taken into account for a social project. What effect is expected from the product?
- 4. We find out what the client wants to get from the application. It can be earnings, simplification of business processes, growth or PR of the company, practical benefits and so on.
- 5. Has the client studied the market? It is important to understand what decisions the competitors had, what of this we can take into account, and what to do differently. If the customer has not carried out monitoring, we take this task on ourselves.
- 6. Who will promote the product? We will find out if the client has their own marketing capacities or will need recommendations from us.
Discussing roles in the system
It is important for us to understand who will use the product and what roles users will have. For example, there are two roles in the system for accounting for passengers in transport and accounting for drivers’ working hours:
– Driver role;
– the Passenger role.
User stories will change depending on the role. That is, the interface and functionality of the software.
So, before launching the application, the driver needs to enter his identification number, medical parameters (pulse, pressure, presence of alcohol in the blood) and immediately before entering the route line, press the “start” button. Accordingly, the passenger will have a different user history.
We discuss with the client how many “roles” are needed, and how they will interact in the system. We also determine which applications are needed (web and mobile applications, admin panel, and so on).
Making up a set of artifacts
We create an individual pool of artifacts for each project.
MindMap is a mental map of features. Here we indicate which applications will be required inside the project, prescribe roles (administrator, moderator, and so on), and how the roles interact with the future application.
User stories. We reveal how each role interacts with the system.
The BPM diagram clearly shows how the roles interact with the system and each other. This artifact helps to avoid holes in business processes. When we see a schematic interaction in front of us, it immediately becomes obvious which important processes in the application were not involved.
Design concept. We definitely recommend our clients to make this artifact. It consists of 2-3 versions of the screen of the future product.
Each artifact is approved by the customer. At this stage of work, we communicate closely with the client: every day we discuss together the prepared parts of the business process in order to achieve the best result.
Before starting work
After the completed path, we get a set of works for the analytics and design stage. Before starting the next stage, we look at the features again together with the client and, if necessary, reduce them for a minimum working product. This is the MVP of the future project.
P.S.: It is very convenient to highlight MVP using colors on MindMap. Thus, you and the client see a complete picture of the features and what is the minimum working product.
So in the discovery phase, we are designing a future application together with the client.
Web product development and clients.
Development is a process that can take several months. To make it easier for the customer to track the progress of work, you can divide the stage into two—week segments – sprints. After each such sprint, the intermediate result is shown to the client, edits and suggestions are accepted. Then a new sprint starts and so on. Before starting development, each feature is evaluated. Several specialists are engaged in this at once: frontend and backend developers, QA engineer, IOS or Android mobile developer. At the time of evaluation, a detailed study of the architecture for a specific functionality takes place, the timing of implementation is discussed, the task is decomposed into several subtasks and taken to work.
How development works
That’s it, now you can move on to the code. The backend developer starts his part of the project, then frontend and mobile development specialists join him. In parallel, a QA engineer is working with them, who will have to test the product — at this time he is compiling checklists for future verification. When the feature is ready, according to these sheets, developers can check the functionality themselves before giving the QA developments. He is already testing the features in more detail, completing the stage with a detailed report.
Now there is something to show the customer. At the end of the sprint, the results are demonstrated and feedback is collected. After that, a retrospective is held with the team to take into account all the comments on the next sprint.
This is how the product will grow: the necessary functionality is created with constant quality control. When all the features are ready and agreed, the combat servers and infrastructure are being prepared, and then the product is launched into operation.
Support after the launch of the web product
Even after the project is implemented, it is important to keep in touch with the customer — to provide technical support, monitor servers, monitor performance, monitor free space.