Improving mobile project management
Hello! Immediately, we note: this article will not describe any fundamentally new approaches and solutions. All techniques, one way or another, are known to experienced IT managers. We want to share our experience and tell you what components of the project we considered mandatory and why.
In our company, it is customary to hold retrospectives - meetings based on the results of a completed project to analyze and discuss the process of creating a product. The entire project team gathers at the meeting, and we discuss the successes and failures of a specific project, consider the possibility of applying successful solutions in other projects and processes and come up with solutions to avoid failures, reduce risks and costs in future similar projects. At one of the last such meetings, we identified several practices and approaches that should help us cope with the typical problems of mobile application development projects.
We realized that TK is often not suitable for us as a format for designing and recording requirements. Creating one universal document that should cover all aspects of product requirements, requires the joint work of a large number of different people both from our side and from the customer’s side, and takes a lot of time. At the same time, the developer will find it difficult and inconvenient to work with the final very voluminous document (there is too much unnecessary for the developer of “water”, it is difficult to search for answers to specific questions), and the document most likely will not be perfect anyway: not all details will be described.
If we talk about mobile projects, which in terms of the scope of work usually fit into 3-4 months, then writing a single large and detailed TK for them is not rational, since it will take about as much time as working on the project itself. On the other hand, it is impossible to work without fixed requirements, and a compromise has to be found.
We decided that it would be much faster, more efficient and more useful to develop various aspects of the requirements in the form of separate documents (which, if necessary, could be collected into a single TK). The package of agreed documents before development should include the following:
First of all, the requirements should describe the product’s background for the user (in the form of user stories , user cases ) and the data model from the point of view of the user and the business (entities and relationships between them). To build a data model, it is necessary to analyze the server solution, if it already exists (for example, you are preparing a mobile application for a system that has a website).
Having ready vision and data model, you can begin to study the design of the application. Since the study of a good interface design always takes place in several stages, you first need to sketch screens (= mockups, prototypes), since they can be made much faster than a full-fledged design, and they are cheaper. Screen flow can be built at the same time as sketching: for example, using Balsamiq, but in a large application it turns out to be too large, even if you break it up into separate diagrams for application sections, so for further work on the design it is better to have sketches separately.
')
Creating a design for all screens of the future application takes a lot of time. On the one hand, I want to draw all the interface elements that will be used in the application, so that their appearance is not a surprise for the customer. On the other hand, if we are working on a complete set of screens, then we complicate the task of making changes, coordinating and maintaining all of these screens up to date as the project progresses.
As part of the work on the design concept, we decided to make a mandatory step the creation of a system of interface elements for the future application. This is separate from the screen layouts themselves a catalog of all UI elements created in the same style of the application. The creation of such a system of elements makes it possible not to work out specific screens, forms, lists, and so on, but only the elements from which the screens are assembled. Instead of editing and updating all screens, you should keep up-to-date the rules for displaying elements for each type, for example, single-line text, multi-line text, text input field, field for selecting a value, field with date . This catalog describes not only the colors of the elements and the fonts used, but also the method of entering information (calendar, keyboard, piker, custom input elements), how the elements appear on the screen, how to remove items from the list, and so on.
As a result, our design concept includes:
Another point that I would like to mention here additionally: we use the PNG Express plugin for “cutting” the finished design, and this also simplifies our life.
In most projects, the ability to start the development of an application depends on external factors: whether the texts are consistent, the design is ready, and the services are provided. When creating client-server applications, the commands responsible for the client and server parts act independently. This applies not only to situations where these parts are developed by different companies, but when teams from the same company develop. In such cases, it is usually stipulated that it should be ready to begin work on the client application, in what order and within what time frame certain services will be needed, and so on. However, in practice it often turns out that some task, on which the development depends, is late. This leads to the problem of a project deadline.
At the start of the project, we make a work plan with dependencies, which during the project is always kept up to date. In this regard, we immediately envisage tasks that affect the overall duration of the project (coordination of certain steps with the customer, content readiness, services, design, etc.), and when these tasks are delayed, we must rework the plan and notify the client.
To reduce risks, we proactively work with time delays: we analyze dependencies and draw up a plan of small tasks that anticipate dependencies on time. For example, if development requires services, we set the task for the blocker with testing and debugging services a few days before the start of dependent development tasks. Similarly, we plan time to agree on and correct the design.
In each such task, it is necessary to take into account that external factors are people too :) who have other tasks, priorities and plans, and the more accurate the task is formulated and the more accurate its deadlines are set, the higher the probability that you will get everything on time.
Our experience in developing mobile projects suggests that even the most diligent and well-developed requirements and design, the most detailed explanations, descriptions and examples do not guarantee that the final product will meet the customer's expectations. There is nothing more conducive to constructive discussion and developing a common understanding with the customer than to look at and touch the running application. But postponing the discussion of the application until the moment when it will be fully implemented is risky: the sooner the need for changes becomes clear, the cheaper they are.
It’s not in our interest to wait for the customer while waiting for the first version, so we decided to make intermediate demonstrations mandatory and hold them more often than before.
A demo is a meeting with a customer and a demonstration of project status to him by working with the application on the implemented user case or script. Holding regular demonstrations solves several problems at once:
In general, conducting regular demo helps to maintain constant contact between the client and the development team, set the information base that improves the efficiency of written communication, motivate developers and satisfy the client's requests.
Also during the demo or immediately after it, it is effective to coordinate the plan for the next iteration. This gives the customer a chance to painlessly change the requirements before we begin to implement, and at the moment when the vision of the functional is clearest.
To publish an application in the app store, you must have an active subscription in the Apple or Google development center. Subscribing to a company for the first time may take several weeks; The subscription is paid once a year (for Apple) and takes several days. If the client is not ready for an account by the time the application is published, there is a shift in the publication time, which can lead to a variety of consequences: loss of market share due to the publication of a competitor, disruption of the marketing company, breach of contract and other unpleasant things.
We agree in advance with the client on the issue of publication: from which account the publication occurs, who is responsible for this, what needs to be provided for publication. To prepare for publication, we use a specially compiled checklist so as not to forget about screenshots, descriptions, categories, and so on. We include in the work plan the managerial task of joint preparation with the client for publication; if necessary, we help in registering an account. If you already have an account, check that it will be active by the time the project is published.
We emphasize once again that all the “finds” described above are surely familiar to the reader without us. This is just our own incomplete list of mandatory rules, felt in our own skin and replenished with the price of mistakes and stepping on rakes.
In our company, it is customary to hold retrospectives - meetings based on the results of a completed project to analyze and discuss the process of creating a product. The entire project team gathers at the meeting, and we discuss the successes and failures of a specific project, consider the possibility of applying successful solutions in other projects and processes and come up with solutions to avoid failures, reduce risks and costs in future similar projects. At one of the last such meetings, we identified several practices and approaches that should help us cope with the typical problems of mobile application development projects.
Elaboration and harmonization of requirements
Problem
We realized that TK is often not suitable for us as a format for designing and recording requirements. Creating one universal document that should cover all aspects of product requirements, requires the joint work of a large number of different people both from our side and from the customer’s side, and takes a lot of time. At the same time, the developer will find it difficult and inconvenient to work with the final very voluminous document (there is too much unnecessary for the developer of “water”, it is difficult to search for answers to specific questions), and the document most likely will not be perfect anyway: not all details will be described.
If we talk about mobile projects, which in terms of the scope of work usually fit into 3-4 months, then writing a single large and detailed TK for them is not rational, since it will take about as much time as working on the project itself. On the other hand, it is impossible to work without fixed requirements, and a compromise has to be found.
Decision
We decided that it would be much faster, more efficient and more useful to develop various aspects of the requirements in the form of separate documents (which, if necessary, could be collected into a single TK). The package of agreed documents before development should include the following:
- Vision - description of the general idea of ​​the final product in terms of the customer's business industry, reflecting the main tasks, the solution of which is implemented through the application
- The data model is a logical definition of the objects with which the application operates, and the relationships between them.
- Sketches - graphic sketches of screens showing the location of interface elements
- Screen flow - a diagram of transitions between application screens.
First of all, the requirements should describe the product’s background for the user (in the form of user stories , user cases ) and the data model from the point of view of the user and the business (entities and relationships between them). To build a data model, it is necessary to analyze the server solution, if it already exists (for example, you are preparing a mobile application for a system that has a website).
Having ready vision and data model, you can begin to study the design of the application. Since the study of a good interface design always takes place in several stages, you first need to sketch screens (= mockups, prototypes), since they can be made much faster than a full-fledged design, and they are cheaper. Screen flow can be built at the same time as sketching: for example, using Balsamiq, but in a large application it turns out to be too large, even if you break it up into separate diagrams for application sections, so for further work on the design it is better to have sketches separately.
')
Design study and coordination
Problem
Creating a design for all screens of the future application takes a lot of time. On the one hand, I want to draw all the interface elements that will be used in the application, so that their appearance is not a surprise for the customer. On the other hand, if we are working on a complete set of screens, then we complicate the task of making changes, coordinating and maintaining all of these screens up to date as the project progresses.
Decision
As part of the work on the design concept, we decided to make a mandatory step the creation of a system of interface elements for the future application. This is separate from the screen layouts themselves a catalog of all UI elements created in the same style of the application. The creation of such a system of elements makes it possible not to work out specific screens, forms, lists, and so on, but only the elements from which the screens are assembled. Instead of editing and updating all screens, you should keep up-to-date the rules for displaying elements for each type, for example, single-line text, multi-line text, text input field, field for selecting a value, field with date . This catalog describes not only the colors of the elements and the fonts used, but also the method of entering information (calendar, keyboard, piker, custom input elements), how the elements appear on the screen, how to remove items from the list, and so on.
As a result, our design concept includes:
- design of several (3-5) key screens of the application;
- system interface elements;
- "Chips": behaviors, animations and other ways to achieve the wow effect.
Another point that I would like to mention here additionally: we use the PNG Express plugin for “cutting” the finished design, and this also simplifies our life.
Project Time Management
Problem
In most projects, the ability to start the development of an application depends on external factors: whether the texts are consistent, the design is ready, and the services are provided. When creating client-server applications, the commands responsible for the client and server parts act independently. This applies not only to situations where these parts are developed by different companies, but when teams from the same company develop. In such cases, it is usually stipulated that it should be ready to begin work on the client application, in what order and within what time frame certain services will be needed, and so on. However, in practice it often turns out that some task, on which the development depends, is late. This leads to the problem of a project deadline.
Decision
At the start of the project, we make a work plan with dependencies, which during the project is always kept up to date. In this regard, we immediately envisage tasks that affect the overall duration of the project (coordination of certain steps with the customer, content readiness, services, design, etc.), and when these tasks are delayed, we must rework the plan and notify the client.
To reduce risks, we proactively work with time delays: we analyze dependencies and draw up a plan of small tasks that anticipate dependencies on time. For example, if development requires services, we set the task for the blocker with testing and debugging services a few days before the start of dependent development tasks. Similarly, we plan time to agree on and correct the design.
In each such task, it is necessary to take into account that external factors are people too :) who have other tasks, priorities and plans, and the more accurate the task is formulated and the more accurate its deadlines are set, the higher the probability that you will get everything on time.
Intermediate Demos
Problem
Our experience in developing mobile projects suggests that even the most diligent and well-developed requirements and design, the most detailed explanations, descriptions and examples do not guarantee that the final product will meet the customer's expectations. There is nothing more conducive to constructive discussion and developing a common understanding with the customer than to look at and touch the running application. But postponing the discussion of the application until the moment when it will be fully implemented is risky: the sooner the need for changes becomes clear, the cheaper they are.
Decision
It’s not in our interest to wait for the customer while waiting for the first version, so we decided to make intermediate demonstrations mandatory and hold them more often than before.
A demo is a meeting with a customer and a demonstration of project status to him by working with the application on the implemented user case or script. Holding regular demonstrations solves several problems at once:
- Preparation for regular (every 2-3 weeks) demo mobilizes the team and does not allow to relax in the early stages of the project, when the deadline is still far away.
- Conducting a demo increases the transparency of the development process for the customer.
- When conducting a demo there is an opportunity to evaluate the effectiveness of the functional design of the application.
- When conducting a demo, the development team receives a meaningful review.
In general, conducting regular demo helps to maintain constant contact between the client and the development team, set the information base that improves the efficiency of written communication, motivate developers and satisfy the client's requests.
Also during the demo or immediately after it, it is effective to coordinate the plan for the next iteration. This gives the customer a chance to painlessly change the requirements before we begin to implement, and at the moment when the vision of the functional is clearest.
Publication
Problem
To publish an application in the app store, you must have an active subscription in the Apple or Google development center. Subscribing to a company for the first time may take several weeks; The subscription is paid once a year (for Apple) and takes several days. If the client is not ready for an account by the time the application is published, there is a shift in the publication time, which can lead to a variety of consequences: loss of market share due to the publication of a competitor, disruption of the marketing company, breach of contract and other unpleasant things.
Decision
We agree in advance with the client on the issue of publication: from which account the publication occurs, who is responsible for this, what needs to be provided for publication. To prepare for publication, we use a specially compiled checklist so as not to forget about screenshots, descriptions, categories, and so on. We include in the work plan the managerial task of joint preparation with the client for publication; if necessary, we help in registering an account. If you already have an account, check that it will be active by the time the project is published.
We emphasize once again that all the “finds” described above are surely familiar to the reader without us. This is just our own incomplete list of mandatory rules, felt in our own skin and replenished with the price of mistakes and stepping on rakes.
Source: https://habr.com/ru/post/246289/
All Articles