December 19, 2014 at 14:27Improving mobile project management
Hello! Just note: this article will not describe any fundamentally new approaches and solutions. All the tricks, one way or another, are known to experienced IT managers. We want to share our experience and tell you which components of the project we considered mandatory and why.
Our company decided to hold retrospectives - meetings based on the results of a completed project to analyze and discuss the product creation process. The whole project team gathers at the meeting, and we discuss the successes and failures of a particular project, consider the possibility of applying successful solutions to 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 deal 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 fixing requirements. The creation of one universal document, which should cover all sides of the product requirements, requires the joint work of a large number of different people both from our side and the customer’s side, and it takes a lot of time. At the same time, it will be difficult and inconvenient for the developer to work with the resulting very voluminous document (there is too much “water” for the developer, it is difficult to look for answers to specific questions), but most likely the document will not be ideal: not all details will be described.
If we talk about mobile projects, which usually take 3-4 months in terms of the volume of work, then writing for them a single large and detailed ToR is not rational, since it will take about the same amount of time as working on the project itself. On the other hand, it is impossible to work without fixed requirements, and you have to find a compromise.
We decided that it would be much faster, more efficient and more useful for development to coordinate various aspects of the requirements in the form of separate documents (which, if necessary, could be assembled into a single ToR). The package of agreed documents before starting development should include the following:
First of all, the requirements should describe the introduction of the product 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 (the nature and relationship 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 a ready-made vision and data model, you can begin to develop the design of the application. Since the development of a good interface design always takes place in several stages, first you need to make screen sketches (= mockups, prototypes), since they can be done much faster than a full-fledged design, and they are cheaper. Screen flow can be built simultaneously with the development of sketches: for example, using Balsamiq, but in a large application it turns out to be too large, even if divided into separate diagrams by sections of the application, so for further work on the design it is better to have sketches separately.
Creating the design of absolutely all the 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 to the customer. On the other hand, if we are working on a full set of screens, then we complicate the task of making changes, coordinating and keeping all these screens up to date during the project.
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 a directory of all UI elements created in a single application style that is separate from the screen layouts themselves. The creation of such a system of elements allows us 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 need to 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, date field. 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 elements 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 to “cut” the finished design, and this also simplifies our lives.
In most projects, the ability to start application development depends on external factors: are the texts agreed, is the design ready, are the services provided. When creating client-server applications, the teams responsible for the client and server parts act independently. This applies not only to situations when these parts are developed by different companies, but also when teams are from the same company. In such cases, it is usually stipulated that it should be ready to start work on the client application, in what order and in what time frame separate services and so on will be needed. However, in practice, it often turns out that some task on which development depends is late. This leads to the problem of shifting the deadlines for the project.
At the start of the project, we make a work plan with dependencies, which we always keep up to date during the project. In this regard, we immediately provide for tasks that affect the overall duration of the project (coordination of certain steps with the customer, readiness of content, services, design, etc.), and when these tasks are delayed, we will necessarily rework the plan and notify the client.
To reduce risks, we proactively work with delayed deadlines: we analyze dependencies and draw up a plan of small tasks that precede the completion of dependencies on time. For example, if services are needed for development, we set the task as a blocker with testing and debugging services a few days before the start of dependent development tasks. Similarly, we plan the time for approval and correction of the design.
In each such task, one must take into account that external factors are also people :) who have other tasks, priorities and plans, and the more accurately the task is formulated and the timelines are set more accurately, the higher the likelihood that you will receive everything on time.
Our experience in developing mobile projects suggests that even the most diligently and accurately designed requirements and design, the most detailed explanations, descriptions and examples do not guarantee that the final product meets the customer's expectations. There is nothing more conducive to constructive discussion and the development of a common understanding with the customer than to watch and “touch” a working application. But postponing the discussion of the application until it is fully implemented is risky: the sooner the need for changes becomes clear, the cheaper it is.
To torment the customer in anticipation of the first version is not in our interests, so we decided to make intermediate demonstrations mandatory and conduct them more often than before.
A demo is a meeting with a customer and demonstrating to him the status of the project by working with the application according to implemented user cases or script. Holding regular demonstrations solves several problems at once:
In general, holding regular demos helps to maintain constant contact between the client and the development team, set an information base that improves the efficiency of written communication, motivate developers and satisfy client requests.
Also, during the demo or immediately after it, it is effective to coordinate the plan for the next iteration. This gives the customer the chance to painlessly change the requirements before we begin implementation, and at that moment when the vision of the functional is most clear.
To publish the application in the application store, you must have an active subscription in the development center of Apple or Google. Subscribing for a company for the first time may take several weeks; Subscription is paid once a year (for Apple) and takes several days. If at the time of publication of the application the client does not have an account ready, the publication deadlines shift, which can lead to a variety of consequences: loss of market share due to the publication of a competitor, disruption of the marketing company, violation of the contract and other unpleasant things.
We agree in advance with the client the issue of publication: from which account the publication takes place, 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 more. 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, we check that it will be active by the time the project is published.
We emphasize once again that all the “findings” described above are probably familiar to the reader even without us. This is just our own incomplete list of binding rules, felt on our own skin and replenished at the cost of mistakes and stepping on a rake.
Our company decided to hold retrospectives - meetings based on the results of a completed project to analyze and discuss the product creation process. The whole project team gathers at the meeting, and we discuss the successes and failures of a particular project, consider the possibility of applying successful solutions to 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 deal with the typical problems of mobile application development projects.
Development and approval of requirements
Problem
We realized that TK is often not suitable for us as a format for designing and fixing requirements. The creation of one universal document, which should cover all sides of the product requirements, requires the joint work of a large number of different people both from our side and the customer’s side, and it takes a lot of time. At the same time, it will be difficult and inconvenient for the developer to work with the resulting very voluminous document (there is too much “water” for the developer, it is difficult to look for answers to specific questions), but most likely the document will not be ideal: not all details will be described.
If we talk about mobile projects, which usually take 3-4 months in terms of the volume of work, then writing for them a single large and detailed ToR is not rational, since it will take about the same amount of time as working on the project itself. On the other hand, it is impossible to work without fixed requirements, and you have to find a compromise.
Decision
We decided that it would be much faster, more efficient and more useful for development to coordinate various aspects of the requirements in the form of separate documents (which, if necessary, could be assembled into a single ToR). The package of agreed documents before starting development should include the following:
- Vision - a description of the general idea of the final product in terms of the customer’s business industry, reflecting the main tasks that are solved through the application
- Data model - a logical definition of the objects that the application operates on and the relationships between them
- Sketches - graphic screen layouts showing the layout of interface elements
- Screen flow - diagram of transitions between application screens.
First of all, the requirements should describe the introduction of the product 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 (the nature and relationship 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 a ready-made vision and data model, you can begin to develop the design of the application. Since the development of a good interface design always takes place in several stages, first you need to make screen sketches (= mockups, prototypes), since they can be done much faster than a full-fledged design, and they are cheaper. Screen flow can be built simultaneously with the development of sketches: for example, using Balsamiq, but in a large application it turns out to be too large, even if divided into separate diagrams by sections of the application, so for further work on the design it is better to have sketches separately.
Design development and approval
Problem
Creating the design of absolutely all the 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 to the customer. On the other hand, if we are working on a full set of screens, then we complicate the task of making changes, coordinating and keeping all these screens up to date during the project.
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 a directory of all UI elements created in a single application style that is separate from the screen layouts themselves. The creation of such a system of elements allows us 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 need to 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, date field. 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 elements from the list, and so on.
As a result, our design concept includes:
- design of several (3-5) key application screens;
- system of interface elements;
- "Chips": behaviors, animations, and other ways to achieve a wow effect.
Another point that I would like to mention here additionally: we use the PNG Express plugin to “cut” the finished design, and this also simplifies our lives.
Project timing management
Problem
In most projects, the ability to start application development depends on external factors: are the texts agreed, is the design ready, are the services provided. When creating client-server applications, the teams responsible for the client and server parts act independently. This applies not only to situations when these parts are developed by different companies, but also when teams are from the same company. In such cases, it is usually stipulated that it should be ready to start work on the client application, in what order and in what time frame separate services and so on will be needed. However, in practice, it often turns out that some task on which development depends is late. This leads to the problem of shifting the deadlines for the project.
Decision
At the start of the project, we make a work plan with dependencies, which we always keep up to date during the project. In this regard, we immediately provide for tasks that affect the overall duration of the project (coordination of certain steps with the customer, readiness of content, services, design, etc.), and when these tasks are delayed, we will necessarily rework the plan and notify the client.
To reduce risks, we proactively work with delayed deadlines: we analyze dependencies and draw up a plan of small tasks that precede the completion of dependencies on time. For example, if services are needed for development, we set the task as a blocker with testing and debugging services a few days before the start of dependent development tasks. Similarly, we plan the time for approval and correction of the design.
In each such task, one must take into account that external factors are also people :) who have other tasks, priorities and plans, and the more accurately the task is formulated and the timelines are set more accurately, the higher the likelihood that you will receive everything on time.
Intermediate Demos
Problem
Our experience in developing mobile projects suggests that even the most diligently and accurately designed requirements and design, the most detailed explanations, descriptions and examples do not guarantee that the final product meets the customer's expectations. There is nothing more conducive to constructive discussion and the development of a common understanding with the customer than to watch and “touch” a working application. But postponing the discussion of the application until it is fully implemented is risky: the sooner the need for changes becomes clear, the cheaper it is.
Decision
To torment the customer in anticipation of the first version is not in our interests, so we decided to make intermediate demonstrations mandatory and conduct them more often than before.
A demo is a meeting with a customer and demonstrating to him the status of the project by working with the application according to implemented user cases 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 you to relax in the early stages of the project, when the deadline is still far away.
- The demo increases the transparency of the development process for the customer.
- When conducting a demo, it is possible to evaluate the effectiveness of the functional design of the application.
- When conducting a demo, the development team receives meaningful feedback.
In general, holding regular demos helps to maintain constant contact between the client and the development team, set an information base that improves the efficiency of written communication, motivate developers and satisfy client requests.
Also, during the demo or immediately after it, it is effective to coordinate the plan for the next iteration. This gives the customer the chance to painlessly change the requirements before we begin implementation, and at that moment when the vision of the functional is most clear.
Publication
Problem
To publish the application in the application store, you must have an active subscription in the development center of Apple or Google. Subscribing for a company for the first time may take several weeks; Subscription is paid once a year (for Apple) and takes several days. If at the time of publication of the application the client does not have an account ready, the publication deadlines shift, which can lead to a variety of consequences: loss of market share due to the publication of a competitor, disruption of the marketing company, violation of the contract and other unpleasant things.
Decision
We agree in advance with the client the issue of publication: from which account the publication takes place, 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 more. 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, we check that it will be active by the time the project is published.
We emphasize once again that all the “findings” described above are probably familiar to the reader even without us. This is just our own incomplete list of binding rules, felt on our own skin and replenished at the cost of mistakes and stepping on a rake.