How to manage the giants Vol.3: the full life cycle of the project

    image

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

    Over 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 points in the development of web projects.

    What awaits you in the article:
    We outline the risks and tell you how to minimize them at all stages of the life of the project.

    Who the article is intended for: The
    article will be of interest primarily to project managers and everyone who is working 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 apply to minimize risks in production processes (Evgeny Lobanov, AGIMA Executive Director ).

    Author's supervision


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

    8 of 10 projects we start with analytics, and on the basis of quantitative and qualitative research we formulate a design assignment. At all subsequent stages - design, design, layout and development - analysts conduct field supervision: the results should correspond to the analytical report. So we control the problems that users experience 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 the heads of the relevant departments.

    For accounting and process control, we compiled a workaround. The data in this sheet shows in which workshop and at what stage the project is.

    Bypass sheet



    image

    Our workaround or the protocol of the project is as follows:
    https://docs.google.com/document/d/1ZeFBUPewl47JkVk_WCPflchqw74Xt4His33sxfHOnnY/

    Of course, you can also coordinate and transmit the work results by mail, but the sense of responsibility is higher when you sign the real document. Therefore, we introduced an offline process when all responsible persons sign a paper bypass sheet.

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

    The main details of each stage



    Analytics



    image

    At the analytics stage, individual in-depth interviews, surveys , direct or reverse card sorting , diary research , implementation of counters, the test of the previous version of the site / application and feedback analysis are conducted.

    In the course of research, we make recommendations to improve the interface and product. Interface recommendations are accepted in 90% of cases, but product recommendations - only in 10%. Without the introduction of product recommendations, it is impossible to increase business performance (and in the example below you will understand why). Customers rarely follow them, because making such decisions is not their responsibility. We, as an agency, interact with representatives of the marketing department, and the improvements we offer relate to other business units.

    For example, when developing a CASCO calculator, an insurance company, we recommended adding the STO choice from the list: the user wants to be served in a trusted official service or near the house. But the recommendation was not accepted because of the business model: the insurance should load the official service stations with a certain number of cars. This recommendation is convenient for the user, but contradicts the business: in some services it would be too much, and in other cars it would not be enough.

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

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

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

    Let's consider metrics using e-commerce as an example. All bonuses are calculated from the amount of bonuses for each metric based on their growth. This is an example of an analysis of key metrics with maximum bonus amounts for each:

     


    Metrics


    Average conversion (2015th year)


    Coefficient


    Bonus (max)


    M1


    registration


    1%


    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 products in the
    store


    6.87%


    0.2


    160,000


    M5


    View
    Seller Phone


    6.12%


    0.2


    160,000


     


     


    Amount:


    1


    800,000



    Bonus conditions for one of the metrics:

    Growth (P)


    Bonus


    <–5%


    not


    –5% <P <5%


    50% of the max bonus
    metric


    > 5%


    100% of the max bonus
    metric



    If there is no analytics, we begin with the design phase. In this case, the designers are responsible for product supervision. They can perform the role of product owner.

    Design



    image

    Designing 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 the business and other departments that work on the product. All interviews are marked as milestones and are recorded on the timeline. What should be done:

    1. Clearly coordinate and fix the dates of the interview with each representative of the business or other necessary unit. 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. Based on the results of all interviews, write a report and indicate the impact on the initial business requirements. Coordinate the report with the client and indicate in advance the milestone on the schedule. This minimizes disagreements within the client’s team and resolves issues of changing the composition of the task, increasing the cost or development time (if any).

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

    Prototypes alone are not enough (even if they are interactive or have 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 for both the layout stage and the back-end development, as well as minimize errors in finalizing the assessment of labor costs.

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

    For instance:

    image

    Design



    image

    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 state of the layouts, the state of all elements, check the content for relevance, and also draw all the micro-animation, etc.

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

    - increase / decrease the volume of content in the layout blocks,
    - change the content for which illustrations or icons are needed,
    - the appearance of a new state for any interface element,
    - the appearance of an additional interface template,
    - a mismatch with functional or business requirements,
    etc. Here are the

    basic rules for accepting layouts in our AGIMA .

    Layout


    image

    Decided on the functional blocks, agreed on a visual design language. We pass to imposition.

    What is important to track at this stage:

    1. The most obvious: pixel-perfect layout testing for layout. We at AGIMA do this on all projects. At the same stage, there is a check for cross-browser compatibility, encoding and semantics.
    2. Discuss AJAX events with team leaders on back-end programming. At the output, the timlid transmits a list of elements that interact via AJAX.
    3. Correct tab traversal (except for custom elements) in all web forms.
    4. Check all forms for validation (e-mail, phone - with reg exp).
    5. Pagespeed - target a score> 85 ..
    6. All inputs are necessarily wrapped in .
    7. Blocks with dynamic content or editing from the CMS should fit both very large text and very small.
    8. Separate semantic blocks: in div.top_menu there should not be a div with a phone or a recycle bin. These are different components, their nesting must be avoided.
    9. If the project is on bitrix , follow the bitrix component structure .
    10. Apply BEM , LESS .
    11. Form the structure of the project together with the team lead of back-end development.

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

    In addition to the layout, be sure to impose UI-KIT ( example ) - this will allow you not to “produce” style classes for the same elements, which will greatly simplify the support or development of the project and control the appearance of new interface design elements.

    Development


    image

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

    There are a lot of risks at this stage, we will identify only the most important ones that need to be addressed:

    1. Initially, the correct server architecture (replication, balancer, load balancing on the database and APP). Even before the development stage, you need to understand the real load and resources of the customer’s server resources, the requirements for uninterrupted operation and the procedure for measuring customer loss of profit during downtime. Perhaps the customer needs SLA or functional continuity services.

    2. Automate user cases that you described at the design stage if you plan to continue supporting 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. Form milestones for providing you with documentation (API) and working services. You should have documentation and stubs (and better working web services) before you start the integration. Manage customer expectations.

    4. Immediately provide for all the nuances of storing personal data in accordance with Federal Law-152.

    Take care of the safety of dev sites and stage.

    • Test / stage platform is closed by HTTP authorization;
    • All custom components, templates, and utility scripts are located in / local /;
    • / bitrix / admin / is not accessible to ordinary users;
    • / git / is closed for access from the browser;
    • PHP interpreter is disabled in / upload /;
    • At the root of the site there are no extraneous scripts, folders, backups or dumps, phpmyadmin, phpinfo, and more;
    • The absence of critical vulnerabilities on the site (tools TDB, examples: https://xakep.ru/2010/04/13/51777/ );
    • There is 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 once every six months.

    image

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

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

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

    Also popular now: