Custom web development: how to scale on an ever-growing project
As a rule, in the field of customized web development, all agencies only dream about clients, whose projects will grow twice each year in terms of turnover, regularly supply case studies that can boast, and earn awards for the agency profile ratings. These customers are leaders in their industry. These are either companies whose business is built on the web, or large offline networks, which, thanks to impressive investments, take leading positions on the web channel.
It seems that if you get a couple of such customers, you can rest on your laurels - stop selling and only control the ever-growing flow of tasks. But in reality, as the project grows, it will throw new and new challenges to you, which you will be able to cope with and save the client while working profitably, will be a very difficult task.
It is important to take proactive measures in time and incur additional costs associated with scaling. At first, this may adversely affect the profitability, but upon reaching certain volumes it will become clear that the initial investment was justified.
')
Here are the main challenges that the agency may face on such a project:
Not all agencies in the market have the competencies necessary to cope with all these challenges qualitatively. Today we will talk about the problem of scaling a team - the most difficult, in my opinion, aspect of working with a growing project.
I happened to work on several projects with explosive growth, including the largest online store of children's goods and the leading insurance company.
I participated in these projects, first as a manager and then as a manager of a management team, and I want to share my experience.
The role scheme is generally as follows:
In AGIMA, we use three-step management, when all tactical issues are solved within the framework of interaction within the project team, and strategic issues are brought to the level of account director and head of customer service department. Inside the project team has its own hierarchy, depending on the scale of the project, I will tell about it below.
Here is the typical role scheme within the project team on a small project:
There are two key roles in the project: the project manager (RP) and the team leader.
The ER communicates with the client, formalizes the tasks, backs up, determines priorities, makes plans and controls the tasks for compliance with the business logic. RP also communicates at all stages of work with the departments of design, design, analytics, system administration.
Timlid performs technical formalization of tasks, determines the technologies / tools used, conducts code review, releases releases, monitors the architectural integrity of the project, coordinates development teams.
The remaining resources can be connected to the project as needed and are highly interchangeable.
An important milestone in the growth of the project and a kind of paradigm shift occurs at a time when it is impossible to keep all the information in one head. One team leader cannot physically manage the entire architecture of the project, as it grows too fast. One manager does not have time to dive into all tasks and control all work.
There is a need for separation and duplication of duties of employees, and the standard role scheme is expanded and complicated.
One of the most difficult to scale units - RP.
As the project grows, it makes sense to introduce the classical pair account manager - project manager scheme, when one RP undertakes customer service, including product issues, and the second organizes the production process within the company.
However, such a scheme becomes a dead end with subsequent growth. Within one project there can be up to several dozen products, each of which requires close attention from the point of view of business processes. At the same time, there are situations when parallel development of different products leads to logical conflicts within the framework of the web application architecture or business logic, which entails extremely high risks.
Therefore, an ideal scheme in terms of further scalability is as follows:
Group Head (GH) manages the management team on the project and is responsible for budget control, profitability, team building (both managerial and direct executors) and resource allocation, decides on strategic issues of project management. He also conducts food control and monitors the absence of conflicts in parallel processes. He does not spend time on operational activities and monitoring the execution of each specific task.
Thanks to the introduction of this role, cases are eliminated when several large tasks are performed in parallel and, at the final stage, contradictions and logical conflicts are identified that, in the least successful case, result in full refactoring.
If necessary, the additional role of the Product owner is activated, to which GH delegates part of the product responsibilities. Most often, this employee is based on the client side and relays all the business wishes in the form of formalized tasks for execution.
Each RP in the team is responsible for its “piece” of the project, taking control of all current tasks for a number of products (ideally, these should be adjacent areas). The area of ​​responsibility includes the time and quality of all tasks within the development of accountable products.
The scheme is easily scalable and has a relatively low entry threshold, since when connecting a new RP, it does not need to cover the entire knowledge base of the project at a time, it’s enough to understand the principle of operation of “its” products.
It is important that each of the PM is responsible not only for the production process, but also well versed in the business logic of its products. Due to this, all management decisions are not only correct from the point of view of project management, but also useful for business and architecturally verified.
Separately, in some cases, the role of the project manager should be highlighted - this employee does not immerse into the product component or the production process, but prepares reports, is responsible for the workflow and also plays the role of the “first line”, ensuring continuity of communication and prompt responses to all customer and partner requests .
At the same time, the entire management team included collective motivation, tied to the management of client expectations, first of all - getting into project timings.
Conditions for receiving bonuses (for the month):
This scheme allows the entire management team to work effectively and correctly manage customer expectations.
As the project grows, a solid knowledge base accumulates, the number of nuances and peculiarities grows, and logical relationships become more and more complex and diverse. At some point, these factors begin to have such a strong influence that pre-release debugging takes time commensurate with the development and takes the same amount of resources.
To avoid this situation, we came up with the idea of ​​creating a full QA-team based on the testing team. The main difference lies in the fact that testing is carried out not only at the stage of development, debugging, release, but at all stages of the project:
Such an approach greatly reduces the risk of delayed debugging and delayed release.
Already when entering the second team leader on the project, the question immediately arises - what is the scheme of the distribution of responsibilities?
There are several options: either divide the project by activity, that is, for example, team Lean A focuses on architecture, code review and technical task formalization, and team Lead B is responsible for managing development teams and building releases, is responsible for uninterrupted operation and security. The second option is a food breakdown, in which each team leader is fully responsible for its own set of products within the project.
Both options are good in terms of resource utilization, but they carry great risks in terms of interchangeability.
For example, what to do if one of the Timblids got sick, went on vacation, or quit? It will be difficult to include a new team leader into the process, since the period of immersion in this role is extremely long.
Therefore, it is worthwhile to apply a hybrid scheme on a project, in which each team leader is engaged in his own tasks, but there are a number of activities in which all or at least two project teams are devoted.
Such activities include the most high-risk ones, for example: project architecture, uninterrupted operation, security, key products, which account for the most active sales, and whose performance is spelled out in the SLA.
This scheme undoubtedly reduces labor productivity, but removes most of the risks. It is necessary to find a balance between efficiency and interchangeability, outlining the list of the most crucial points.
Separately, it makes sense to connect timlids to alienated activities: to a product that is architecturally detached from the main part of the project, or an activity that can be performed in parallel. For example, it is quite possible to single out the layout language separately, which will fully take over the control of all front-line work; The roles of the QA team, design, and analytics are highlighted separately.
The more people involved in the project, the more actively you need to use tools to reduce the entry threshold for new employees, they also simplify the interchangeability of existing team members and reduce the bus factor.
Here are a number of tools that do well in almost all projects.
Design system
The design system is a comprehensive and up-to-date design kit and component library in the repository. It reflects the full set of standard elements on the project and allows you to collect new pages from these blocks. The design system not only contains a set of elements, but also describes their interaction, and also contains code examples.
The use of a design system makes it possible to significantly simplify the understanding of a new employee, be it a manager, designer or programmer, of the visual rules of a project, and apply existing solutions instead of constantly inventing new ones.
The use of such tools requires a large expenditure of resources for development and support. Also, many moral strengths are often spent on explaining to the client, why it is necessary to adhere to this system and for what reason, sentences like “Add a new green button on this page, as on N, which looks so beautiful” will be rejected.
Documentation
The larger the project, the more thoroughly each product and each feature should be documented, otherwise more and more time specialists will spend on debugging and figuring out how this or that functionality should work.
Documentation on projects makes sense to divide into 4 types:
All documentation should be aggregated in the online knowledge base (wiki) and kept up to date.
Git
To speed up the connection of new developers from other projects of the company, a standard approach to GitFlow is being introduced. In AGIMA, we use the “work with two main branches” approach.
Instead of using the master branch, two main branches of the project's history are used: master for releases and develop for merging the developed functionality from the feature branches.
Workflow
Another tool that regulates and standardizes the work of all team members is workflow by day.
Every week - the standard production cycle: releases are made strictly on Tuesdays and Thursdays; Wednesday - evaluation day; retrospective and new shipments planning takes place at the end of the week - on Thursday and Friday. This is an example of a workflow from one of the projects; a specific approach should be developed for each specific case.
In workflow, the client must also be involved, and unilaterally, such a system cannot work.
Equally important is the workflow on task statuses, which simplifies the transition of employees between projects. It should be identical on all company projects. In AGIMA, it looks like this:
Even if the project is perfectly organized documentation and all processes work like a clock, to provide all the risks associated with a lack of awareness of each individual artist, it is still impossible. To do this, organize regular events of different formats.
1. Grocery meetings
At such meetings, more experienced employees tell the team about specific products. It covers aspects of business logic, technical implementation and architecture. Awareness of each employee about the main nuances of products helps to put forward useful ideas and make the right decisions at all stages of implementation.
2. Infrastructure slices
The project grows dynamically, this entails the continuous development and expansion of infrastructure. Regular sections discuss current problems and challenges in infrastructure development, and discuss progress on the implementation of each of them.
3. Retrospectives and work planning
It is necessary to hold weekly meetings where the tasks implemented over the past week are discussed, errors are highlighted and work planning for the next accounting period takes place.
Thoughtful application of all the above tools and approaches will help build a coherent and resilient team that will easily scale with the future growth of the project.
Undoubtedly, the organization of such a system carries a number of difficulties and requires both deep competences within the agency and the willingness on the part of the client to invest in such decisions, which can sometimes be difficult in our developing market, but such efforts pay off and lead to long-term and fruitful cooperation and allow to produce the market is really quality products.
It seems that if you get a couple of such customers, you can rest on your laurels - stop selling and only control the ever-growing flow of tasks. But in reality, as the project grows, it will throw new and new challenges to you, which you will be able to cope with and save the client while working profitably, will be a very difficult task.
Project Growth and Related Difficulties
It is important to take proactive measures in time and incur additional costs associated with scaling. At first, this may adversely affect the profitability, but upon reaching certain volumes it will become clear that the initial investment was justified.
')
Here are the main challenges that the agency may face on such a project:
- The problem of scaling is the rebuilding of the team structure with increasing volumes.
- The need to understand the product and business objectives - without a strong product analytics, it is impossible to work effectively on a large project.
- Complicated software and server architecture - hand in hand with the growth of production volumes under the project, there is an increase in attendance, leading to the complexity of the architecture and the need to use highload solutions.
- High quality requirements.
- The need to ensure uninterrupted operation of 24 Ă— 7 and a high speed of response to incidents, including inappropriate time.
- High degree of responsibility for stopping sales.
- Monitoring and control of business indicators.
Not all agencies in the market have the competencies necessary to cope with all these challenges qualitatively. Today we will talk about the problem of scaling a team - the most difficult, in my opinion, aspect of working with a growing project.
I happened to work on several projects with explosive growth, including the largest online store of children's goods and the leading insurance company.
I participated in these projects, first as a manager and then as a manager of a management team, and I want to share my experience.
Roles on a small project and why you need to scale
The role scheme is generally as follows:
In AGIMA, we use three-step management, when all tactical issues are solved within the framework of interaction within the project team, and strategic issues are brought to the level of account director and head of customer service department. Inside the project team has its own hierarchy, depending on the scale of the project, I will tell about it below.
Here is the typical role scheme within the project team on a small project:
There are two key roles in the project: the project manager (RP) and the team leader.
The ER communicates with the client, formalizes the tasks, backs up, determines priorities, makes plans and controls the tasks for compliance with the business logic. RP also communicates at all stages of work with the departments of design, design, analytics, system administration.
Timlid performs technical formalization of tasks, determines the technologies / tools used, conducts code review, releases releases, monitors the architectural integrity of the project, coordinates development teams.
The remaining resources can be connected to the project as needed and are highly interchangeable.
An important milestone in the growth of the project and a kind of paradigm shift occurs at a time when it is impossible to keep all the information in one head. One team leader cannot physically manage the entire architecture of the project, as it grows too fast. One manager does not have time to dive into all tasks and control all work.
There is a need for separation and duplication of duties of employees, and the standard role scheme is expanded and complicated.
Management Team Structure
One of the most difficult to scale units - RP.
As the project grows, it makes sense to introduce the classical pair account manager - project manager scheme, when one RP undertakes customer service, including product issues, and the second organizes the production process within the company.
However, such a scheme becomes a dead end with subsequent growth. Within one project there can be up to several dozen products, each of which requires close attention from the point of view of business processes. At the same time, there are situations when parallel development of different products leads to logical conflicts within the framework of the web application architecture or business logic, which entails extremely high risks.
Therefore, an ideal scheme in terms of further scalability is as follows:
Group Head (GH) manages the management team on the project and is responsible for budget control, profitability, team building (both managerial and direct executors) and resource allocation, decides on strategic issues of project management. He also conducts food control and monitors the absence of conflicts in parallel processes. He does not spend time on operational activities and monitoring the execution of each specific task.
Thanks to the introduction of this role, cases are eliminated when several large tasks are performed in parallel and, at the final stage, contradictions and logical conflicts are identified that, in the least successful case, result in full refactoring.
If necessary, the additional role of the Product owner is activated, to which GH delegates part of the product responsibilities. Most often, this employee is based on the client side and relays all the business wishes in the form of formalized tasks for execution.
Each RP in the team is responsible for its “piece” of the project, taking control of all current tasks for a number of products (ideally, these should be adjacent areas). The area of ​​responsibility includes the time and quality of all tasks within the development of accountable products.
The scheme is easily scalable and has a relatively low entry threshold, since when connecting a new RP, it does not need to cover the entire knowledge base of the project at a time, it’s enough to understand the principle of operation of “its” products.
It is important that each of the PM is responsible not only for the production process, but also well versed in the business logic of its products. Due to this, all management decisions are not only correct from the point of view of project management, but also useful for business and architecturally verified.
Separately, in some cases, the role of the project manager should be highlighted - this employee does not immerse into the product component or the production process, but prepares reports, is responsible for the workflow and also plays the role of the “first line”, ensuring continuity of communication and prompt responses to all customer and partner requests .
At the same time, the entire management team included collective motivation, tied to the management of client expectations, first of all - getting into project timings.
- 10 working days before the beginning of the month, each RP himself allocates from three to five of his key tasks for the next month.
- 5 working days before the beginning of the month GH allocates two to four for each manager and sets deadlines: 1 - client deadline (50%), 2 - inner deadline (100%) and enter in the table.
Conditions for receiving bonuses (for the month):
- The manager receives 100% bonuses if all his tasks are completed within the internal period.
- The manager receives 50% of bonuses, if at least one of his tasks has left the internal term, but has been completed in the client's term.
- None of the managers receive bonuses if at least one task from the general list has not been completed in the client's term.
This scheme allows the entire management team to work effectively and correctly manage customer expectations.
Test not only the final code - QA-command
As the project grows, a solid knowledge base accumulates, the number of nuances and peculiarities grows, and logical relationships become more and more complex and diverse. At some point, these factors begin to have such a strong influence that pre-release debugging takes time commensurate with the development and takes the same amount of resources.
To avoid this situation, we came up with the idea of ​​creating a full QA-team based on the testing team. The main difference lies in the fact that testing is carried out not only at the stage of development, debugging, release, but at all stages of the project:
- QA are responsible for the quality of the product and its stylistic and logical conformity with other products and generally accepted rules on the project.
- QAs look at all the artifacts appearing on the project: primary formalization of the task, prototypes, specifications, design, and, of course, test the code and layout, write test cases, cover the existing and new functionality with a grid of autotests.
- Without validation of materials, the QA-team of the RP does not have the right to launch the next stage or send the materials for acceptance to the customer.
Such an approach greatly reduces the risk of delayed debugging and delayed release.
Timlides - efficiency or interchangeability?
Already when entering the second team leader on the project, the question immediately arises - what is the scheme of the distribution of responsibilities?
There are several options: either divide the project by activity, that is, for example, team Lean A focuses on architecture, code review and technical task formalization, and team Lead B is responsible for managing development teams and building releases, is responsible for uninterrupted operation and security. The second option is a food breakdown, in which each team leader is fully responsible for its own set of products within the project.
Both options are good in terms of resource utilization, but they carry great risks in terms of interchangeability.
For example, what to do if one of the Timblids got sick, went on vacation, or quit? It will be difficult to include a new team leader into the process, since the period of immersion in this role is extremely long.
Therefore, it is worthwhile to apply a hybrid scheme on a project, in which each team leader is engaged in his own tasks, but there are a number of activities in which all or at least two project teams are devoted.
Such activities include the most high-risk ones, for example: project architecture, uninterrupted operation, security, key products, which account for the most active sales, and whose performance is spelled out in the SLA.
This scheme undoubtedly reduces labor productivity, but removes most of the risks. It is necessary to find a balance between efficiency and interchangeability, outlining the list of the most crucial points.
Separately, it makes sense to connect timlids to alienated activities: to a product that is architecturally detached from the main part of the project, or an activity that can be performed in parallel. For example, it is quite possible to single out the layout language separately, which will fully take over the control of all front-line work; The roles of the QA team, design, and analytics are highlighted separately.
Interchangeability of team members
The more people involved in the project, the more actively you need to use tools to reduce the entry threshold for new employees, they also simplify the interchangeability of existing team members and reduce the bus factor.
Here are a number of tools that do well in almost all projects.
Design system
The design system is a comprehensive and up-to-date design kit and component library in the repository. It reflects the full set of standard elements on the project and allows you to collect new pages from these blocks. The design system not only contains a set of elements, but also describes their interaction, and also contains code examples.
The use of a design system makes it possible to significantly simplify the understanding of a new employee, be it a manager, designer or programmer, of the visual rules of a project, and apply existing solutions instead of constantly inventing new ones.
The use of such tools requires a large expenditure of resources for development and support. Also, many moral strengths are often spent on explaining to the client, why it is necessary to adhere to this system and for what reason, sentences like “Add a new green button on this page, as on N, which looks so beautiful” will be rejected.
Documentation
The larger the project, the more thoroughly each product and each feature should be documented, otherwise more and more time specialists will spend on debugging and figuring out how this or that functionality should work.
Documentation on projects makes sense to divide into 4 types:
- Interface specifications - a description of the behavior of the implemented functional (operation logic, field validation, a set of screens).
- Test cases (description of user scenarios and the results of their passage), based on them, auto tests are developed as necessary.
- Service specifications (description of interaction with web services, test data, examples of requests and responses).
- Code documentation (description of components, classes and their hierarchy, templates).
All documentation should be aggregated in the online knowledge base (wiki) and kept up to date.
Git
To speed up the connection of new developers from other projects of the company, a standard approach to GitFlow is being introduced. In AGIMA, we use the “work with two main branches” approach.
Instead of using the master branch, two main branches of the project's history are used: master for releases and develop for merging the developed functionality from the feature branches.
Workflow
Another tool that regulates and standardizes the work of all team members is workflow by day.
Every week - the standard production cycle: releases are made strictly on Tuesdays and Thursdays; Wednesday - evaluation day; retrospective and new shipments planning takes place at the end of the week - on Thursday and Friday. This is an example of a workflow from one of the projects; a specific approach should be developed for each specific case.
In workflow, the client must also be involved, and unilaterally, such a system cannot work.
Equally important is the workflow on task statuses, which simplifies the transition of employees between projects. It should be identical on all company projects. In AGIMA, it looks like this:
Maintain awareness of team members
Even if the project is perfectly organized documentation and all processes work like a clock, to provide all the risks associated with a lack of awareness of each individual artist, it is still impossible. To do this, organize regular events of different formats.
1. Grocery meetings
At such meetings, more experienced employees tell the team about specific products. It covers aspects of business logic, technical implementation and architecture. Awareness of each employee about the main nuances of products helps to put forward useful ideas and make the right decisions at all stages of implementation.
2. Infrastructure slices
The project grows dynamically, this entails the continuous development and expansion of infrastructure. Regular sections discuss current problems and challenges in infrastructure development, and discuss progress on the implementation of each of them.
3. Retrospectives and work planning
It is necessary to hold weekly meetings where the tasks implemented over the past week are discussed, errors are highlighted and work planning for the next accounting period takes place.
findings
Thoughtful application of all the above tools and approaches will help build a coherent and resilient team that will easily scale with the future growth of the project.
Undoubtedly, the organization of such a system carries a number of difficulties and requires both deep competences within the agency and the willingness on the part of the client to invest in such decisions, which can sometimes be difficult in our developing market, but such efforts pay off and lead to long-term and fruitful cooperation and allow to produce the market is really quality products.
Source: https://habr.com/ru/post/421055/
All Articles