Butthur Develop: How to win?
So let's start with the definitions. The development is a special kind of bathert, which manifests itself in the form of a complete denial of the possibilities for improving the product of a developer without his participation (hereinafter referred to as BR ). It leads to various types of sabotage and degradation of the product itself. This article is an attempt to highlight the problem and look for opportunities to solve it.
A bit of context. We are engaged in services to accelerate sites. Usually this work on the client side and a little server tuning. Sometimes you have to embed in someone else's server code to solve performance problems. If there is a development team at the client, we regularly meet with the bathert at them.
For the formation of BR need three sides. Next, we describe them together with the interests that lead to the situation of the bathert.
')
The first side is the development team, which should have a sufficient history of interaction with the project code (for example, development from scratch or long-term support). Their main interests are: to maintain their own authority, self-esteem and remain in the project, to prove their indispensability.
The second side is another development team invited to solve local problems: refinement of a component, project auditing, performance problem solving, consulting. Their interests: to successfully carry out a project, get a case, improve the reputation, additional sales of services.
The third party is the owner or project manager, who invited the second team to solve a local task. His interests are: to improve the quality of the project, solve problems for users, increase project revenues (without losing control and retaining all the strengths, including the development team).
The nature of the developers velvet is different. For example, it can be self-reliance and correctness of decisions. In some cases, it is the fear that it will be replaced by more advanced developers who were able to correct problems in the project. Sometimes - the inability to learn and accept new approaches and technologies. In any case, batherth leads to problems for all parties involved.
Difficulties arise when trying to interact with development teams. The first team (the old-timers of the project) is not interested in the success of the work of the invited team (or does not want to believe in it). Result: sabotage all actions. This process begins with delaying the transfer of access to the project's program code and ends on blocking the introduction of changes. Access denial is easily motivated by security issues, implementation of changes is blocked based on the evaluation of code changes that are “wrong”, “unnecessary” and “unprofessional”.
Further, the project manager is informed about the complete failure of the invited team and the need to roll back all changes.
The project manager faces a difficult question of trust: on the one hand, the team that is immersed in the project has a significant trust limit (the project does work). On the other hand - the invited team, with whom he works for the first time, the trust limit of which is obviously lower.
If the manager has sufficient technical background and is able to understand the real state of affairs - well. However, the story does not end there. Next, he will have to push his team to accept the changes and "sprinkle ashes on his head." This may in turn cause new problems.
If the manager cannot independently understand the details of the dispute, then most likely he will choose the path of least resistance - to abandon the project with an invited team and accept the point of view of his developers. This option is the least controversial, but it leads to the failure of the initial task (revision of the project, audit).
I have no definite answer here. I can offer only a few methods.
Method number 1 - communication . From the very beginning, you need to establish effective communication between the development teams, explain to all parties the goals and objectives of the project. Here, feedback and understanding of the process by all parties is important. Uncertainty breeds fear and mistrust.
Method number 2 - disable emotions . We are all human and we can react emotionally. This is especially true when it comes to your child (software code). All arguments in disputes should be based on objective data and logic (if there are clear criteria and metrics in your project - excellent). In no case can not become personal and lose the business tone of communication.
Well, the last one, which is a method of prevention, not treatment - insure the risks. If you know in advance about the problem of bathert, you can provide for this risk in the contract, warn the customer, etc.
Have you met the developers bathert in your practice (from any side)? How did you fight?
Where can I meet the BR?
A bit of context. We are engaged in services to accelerate sites. Usually this work on the client side and a little server tuning. Sometimes you have to embed in someone else's server code to solve performance problems. If there is a development team at the client, we regularly meet with the bathert at them.
For the formation of BR need three sides. Next, we describe them together with the interests that lead to the situation of the bathert.
')
The first side is the development team, which should have a sufficient history of interaction with the project code (for example, development from scratch or long-term support). Their main interests are: to maintain their own authority, self-esteem and remain in the project, to prove their indispensability.
The second side is another development team invited to solve local problems: refinement of a component, project auditing, performance problem solving, consulting. Their interests: to successfully carry out a project, get a case, improve the reputation, additional sales of services.
The third party is the owner or project manager, who invited the second team to solve a local task. His interests are: to improve the quality of the project, solve problems for users, increase project revenues (without losing control and retaining all the strengths, including the development team).
The nature of the developers velvet is different. For example, it can be self-reliance and correctness of decisions. In some cases, it is the fear that it will be replaced by more advanced developers who were able to correct problems in the project. Sometimes - the inability to learn and accept new approaches and technologies. In any case, batherth leads to problems for all parties involved.
What is the problem?
Difficulties arise when trying to interact with development teams. The first team (the old-timers of the project) is not interested in the success of the work of the invited team (or does not want to believe in it). Result: sabotage all actions. This process begins with delaying the transfer of access to the project's program code and ends on blocking the introduction of changes. Access denial is easily motivated by security issues, implementation of changes is blocked based on the evaluation of code changes that are “wrong”, “unnecessary” and “unprofessional”.
Further, the project manager is informed about the complete failure of the invited team and the need to roll back all changes.
The project manager faces a difficult question of trust: on the one hand, the team that is immersed in the project has a significant trust limit (the project does work). On the other hand - the invited team, with whom he works for the first time, the trust limit of which is obviously lower.
If the manager has sufficient technical background and is able to understand the real state of affairs - well. However, the story does not end there. Next, he will have to push his team to accept the changes and "sprinkle ashes on his head." This may in turn cause new problems.
If the manager cannot independently understand the details of the dispute, then most likely he will choose the path of least resistance - to abandon the project with an invited team and accept the point of view of his developers. This option is the least controversial, but it leads to the failure of the initial task (revision of the project, audit).
How to treat?
I have no definite answer here. I can offer only a few methods.
Method number 1 - communication . From the very beginning, you need to establish effective communication between the development teams, explain to all parties the goals and objectives of the project. Here, feedback and understanding of the process by all parties is important. Uncertainty breeds fear and mistrust.
Method number 2 - disable emotions . We are all human and we can react emotionally. This is especially true when it comes to your child (software code). All arguments in disputes should be based on objective data and logic (if there are clear criteria and metrics in your project - excellent). In no case can not become personal and lose the business tone of communication.
Well, the last one, which is a method of prevention, not treatment - insure the risks. If you know in advance about the problem of bathert, you can provide for this risk in the contract, warn the customer, etc.
Have you met the developers bathert in your practice (from any side)? How did you fight?
Source: https://habr.com/ru/post/344574/
All Articles