We have already written how to form a team and with the help of what tools to monitor compliance with the processes. But what else is important to consider at all stages of project life?

For 10 years of work, we launched more than 50 projects with a development cycle of a year and formed a list of the most important and most often ignored moments when developing web projects.
')
What awaits you in the article:
Denote risks and tell you how to minimize them at all stages of the project life.

For whom the article is intended:
The article will be of interest first of all to project managers and to all who work in one way or another on launching web applications.

Disclaimer:
This article is not a panacea, but only a description of the measures and approaches that we use to minimize the risks of production processes (Evgeny Lobanov, Executive Director of AGIMA ).

Author's supervision

Designer supervision is a process for which each department is responsible at its own level. At all stages of the project’s life, different people and departments are responsible for it; only the analytics department, which plays the role of a strategist and monitors all external factors, remains unchanged.

8 of 10 projects we start with analytics, and on the basis of quantitative and qualitative research we form a design task. At all subsequent stages - design, design, layout and development - analysts conduct architectural supervision: the results should correspond to the analytical report. So we control the problems that arise for users when interacting with the product and its interface, and we can immediately evaluate the effectiveness of each subsequent stage. This process is monitored by the project manager and heads of relevant departments.

To account for and control processes, we have compiled a bypass list. The data from this sheet shows in which workshop and at what stage the project is located.

Bypass sheet

Our bypass list or project management protocol looks like this:
https://docs.google.com/document/d/1ZeFBUPewl47JkVk_WCPflchqw74Xt4His33sxfHONnY/

Of course, it is possible to coordinate and transfer the results of work by mail, but the feeling of responsibility is higher when you sign a real document. Therefore, we have introduced an offline process, when all responsible persons sign a paper bypass sheet.

This sheet is stitched together with the project passport in offline documentation and is updated with any changes. So we reduce the risks of returning the results of work to the previous stage.

Main details of each stage

Analytics

At the stage of analytics, individual in-depth interviews, surveys , direct or reverse card sorting , diary studies , the introduction of counters, yutest of the previous version of the site \ application and feedback analysis are conducted.

In the course of research, we make recommendations for improving the interface and product. Recommendations on the interface are accepted in 90% of cases, while recommendations on the product are accepted only in 10%. Without the implementation of product recommendations, it is impossible to improve business performance (and in the example below, you will understand why). Customers rarely follow them, because making such decisions is not in their competence. As an agency, we interact with representatives of the marketing department, and the improvements that we offer concern other business units.

For example, when developing the CASCO calculator, we recommended the insurance company to add a selection of a service station from the list: the user wants to be serviced at a verified official service or near the house. But the recommendation was not accepted because of the business model: the insurance must load the official service stations with a certain number of cars. This recommendation is user-friendly, but contrary to business: in some services it would be overkill, while in other vehicles it would not be enough.

Another example: we advised to make payment for the policy by id - it can be calculated and generated online - in the sales office. But for insurance, online and offline are different sales channels that do not interact with each other. That is, if the user formed an id online and paid for the policy offline, the profit would go to the offline department, but in fact it is not. This recommendation was also rejected.

Consider this nuance and manage customer expectations. The best way to implement recommendations and help in improving the product is to enter into direct communication with the business and understand the framework within which the client is ready to change the product itself.

Fix KPI for conversion in the context of different metrics and check the results by split testing. We prescribe these KPIs in the contract with the client.

Consider the metrics on the example of e-commerce. All bonuses are calculated from the sum of bonuses for each metric based on their growth. This is an example of analyzing key metrics with maximum bonus amounts for each:

	Metrics	Average conversion (2015 – year)	Coefficient	Bonus (max)
M1	check in	one%	0.2	160,000
M2	Account creation	1.58%	0.3	240,000
M3	Subscribe to newsletter	0.06%	0.1	80,000
M4	View item in the store	6.87%	0.2	160,000
M5	Browse phone the seller	6.12%	0.2	160,000
		Amount:	one	800,000

Conditions for receiving a bonus on one of the metrics:

Gain (P)	Bonus
<–5%	not
–5% <P <5%	50% of max bonus by metric
> 5%	100% of max bonus by metric

If there is no analytics, we start from the design stage. In this case, product supervision is the responsibility of the designers. They can play the role of the product owner.

Design

Design is based on an analytical report.

For the project manager, the main risk of this stage is the organization of a large flow of interviews with business and other departments that work on the product. All interviews are marked as Milestone and recorded on the timeplan. What should be done:

1. Clearly coordinate and record the dates of the interview with each representative of the business or other necessary units. Otherwise, they may be on vacation or not find time for an interview, so the risk of dependence on third parties should be minimized.
   
   
2. Following the results of all interviews, make a report and indicate the impact on the initial business requirements. Reconcile the report with the client and pre-specify milestown on the schedule. This minimizes disagreements within the client's team and solves the issues of changing the composition of the task, increasing the cost or development time (if any).

The most important thing is that after all the interviews all parties should have a single vision of the product. This will save you from a lot of problems in later stages.

Some prototypes are not enough (even if they are interactive or there is a full TK) - there should be a specification for prototypes and a description of the mechanics of work. This will allow you to think through all the technical aspects in advance, both for the layout stage and for the back-end development, as well as minimize errors when finalizing the labor cost estimate.

To ensure that the acceptance of the final work is painless, develop user cases at the design stage and coordinate them with the client in advance. The user case must contain all possible scenarios of user behavior when interacting with the interface.

For example:

Design

The design is based on prototypes and descriptions of the mechanics of the interface based on the design results. The most important thing at the design stage is to draw in detail all the states of the layouts, the states of all elements, check the content for relevance, as well as draw all the micro-animation, etc.

It is important that the output, in addition to the actual layouts in all states, is a web guide (UI-KIT), for example . Be sure to update and validate the Terms of Reference after the design phase. This will minimize the risks and think through all the points that at subsequent stages can block the planned course of the project:

- increase / decrease in content in blocks of the layout,
- changing the content for which you need illustrations or icons,
- the appearance of a new state for any interface element,
- the appearance of an additional interface template,
- non-compliance with functional or business requirements,
etc.

The basic rules for accepting layouts in our AGIMA are here .

Layout

Determined with the functional blocks, agreed on a visual design language. Go to the layout.

What is important to track at this stage:

1. The most obvious: pixel-perfekt testing of layout for compliance with the layout. We at AGIMA do this on all projects. At the same stage, a check for cross-browser compatibility, coding and semantics occurs.
2. Discuss AJAX events with back-end programming tmlids. At the exit, a timlid transmits a list of elements that interact via AJAX.
3. Correct tab crawling (except custom-elements) in all web forms.
4. Check all forms for validation (e-mail, phone - with reg exp).
5. Pagespeed - be guided by the indicator> 85 ..
6. All inputs are necessarily wrapped in <front>.
7. In blocks with dynamic content or with editing from the CMS, both very large and very small text should fit.
8. Separate semantic blocks: in div.top_menu there should not be a div with a phone or basket. These are different components, you need to avoid their nesting.
9. If the project is on bitrix , observe the bitrix component structure .
10. Use BEM , LESS .
11. Build the project structure together with the back-end development team.

Connect to the task of developers back-end immediately - this will allow you to minimize the risks of fine-tuning the layout at the integration stage.

In addition to the layouts, make sure to also type in the UI-KIT ( example ) - this will allow you not to “produce” style classes for identical elements, which will greatly simplify the support or development of the project and control the appearance of new interface design elements.

Development

This is the final and most time-consuming stage. Development is also programming (integration of layout in templates, development of necessary modules, API for data exchange with external systems of the customer, etc.), and testing, setting up servers and even deploying the entire infrastructure (if needed).

There are a lot of risks at this stage, we will designate only the most important ones, to which attention should be paid:

1. Initially correct server architecture (replication, balancer, load distribution on the database and APP). Even before the development stage, you need to understand the real workload and capabilities of the customer’s server resources, the requirements for uninterrupted operation, and the procedure for measuring the loss of customer profit during downtime. Perhaps the client needs services for SLA or functional continuity.
   
   
2. Automate the user cases that you described at the design stage, if you plan to continue to support the project. This will save resources when transferring tasks between development and testing.
   
   
3. If the project requires integration with the customer’s internal systems, minimize the risks of third-party influence on the project’s progress. Generate Mailstone to provide you with the documentation (API) and running services. Documentation and stubs (and better working web services) you should have before you start the integration. Manage customer expectations.
   
   
4. Provide at once all the nuances of storing personal data in accordance with the Federal Law-152.
   
   

Take care of the safety of dev-platforms and stage.

• Test / stage site is closed by HTTP authorization;
• All custom components, templates and service scripts are located in / local /;
• / bitrix / admin / is not available to regular users;
• / git / closed for access from the browser;
• in / upload / php interpreter is disabled;
• At the root of the site there are no extraneous scripts, folders, backups or dumps, phpmyadmin, phpinfo and others;
• The absence of critical vulnerabilities on the site (tools TDB, examples: https://xakep.ru/2010/04/13/51777/ );
• No extra / harmful code on the site:

#!/bin/bash contractor="xxx" #    pattern="authorize(\|debug\|backup\|print_r\|console.log(\|$contractor" grep -nir --exclude-dir='upload' --exclude-dir='bitrix' --exclude-dir='.git' $pattern ~/www > ~/log/gDebug.log 

We conduct pen-testing of our dev-environments every six months.



At the end of each stage, conduct testing: UX, pixel perfect, functional, load, integration - this is the most necessary minimum for large projects.

The processes in our company are constantly refined and optimized. In the articles we described the main “base” on which our production projects are built with the production of more than 2500 man-hours.

Manage your risks, fix agreements and control the entire process, from analytics to development. We will tell about other project management secrets in the following articles. Stay tuned!