The contradiction between the creation of new functionality and the correction of errors. Time is limited. The amount of work being done is the same. And if at the beginning of development mistakes are usually not paid much attention to, then by the middle and, especially, the third quarter of the project, mistakes become a serious factor affecting the opinion of all participants and stakeholders about the project. Including the developers themselves. At the same time, no one cancels the need to advance in functionality. Therefore, errors are best divided into fatal, critical, uncritical and low priority. Fatal ones are corrected before the new functionality is written. The critical ones are being edited for a new daily release. Uncritical ones accumulate and are corrected at the end of the next stage. Low-priority ones are ruled after the completion of the project by unidentified good elves.
From personal practice. The experienced business manager of the project drew the attention of the team leader and the architect to the fact that there are clearly a lot of errors in the developed product of increased reliability, that he understands everything, but even it becomes difficult for him to tolerate it. He suggested adding another well-tested tester to the project. The team leader, represented by the author of the note, asked the architect, who was acting as the technical manager of the project, about priorities: do we correct errors or continue to write functionality as quickly as possible. After the decision in favor of the speed of development, the team leader told the business manager of the project that the team could take another tester, but because of the lack of developers, it does not correct most of the errors found by the existing tester. That is, the new tester will only increase the pool of known errors, but not the number of their corrections. The quality of the code will remain the same. As a result, they refused to attract a new tester.
Everyone understood everything. The project was launched on time with code quality far exceeding the market average for large companies.
Accumulation of bad code due to postponing refactoring. An acute lack of time leads to the fact that time is allocated for refactoring only in a situation where the code is clearly difficult to refine. Moreover, when adding functionality to a given section of code leads to a large amount of work on debugging errors. If the project management is lucky and the team lead is good, then he will be able to track the most problematic parts of the code and inform when they will require refactoring and to what extent. Usually such sections are frequently updated code: a couple of lines were added within one task, another three within another, a line within the third and by the tenth edit in the vermicelli code. There is no one guilty among programmers. At the same time, it is very problematic to protect yourself from the formation of such vermicelli even with the help of CodeReview and an advanced team leader. Such code needs to be refactored from time to time, and the project has an acute shortage of time.
Conflicts. In projects with an acute shortage of time, they are very frequent. There is only one solution here — the software skills of the technical project manager should be and some should be very strong. Accordingly, before a developer moves from the position of a specialist developer to the position of a developer-manager, he needs to actively develop his human skills, communication skills and conflict resolution skills. Actually, the fact of the developer’s readiness for managerial activity is determined by the ability to negotiate with people by mutual consent.
Conflict resolution will greatly help understanding that conflict in the development team usually arises from the desire of participants to do better and faster work. At the same time, different solutions are used for this. Sometimes with different priorities for speed or quality. These are industrial conflicts, not personal ones. Such conflicts are best solved by training the parties and joint decision-making, rather than searching for the right or the guilty.
The predominance of tactical decisions over strategic ones and the growth of the coma of tactical decisions. The situation is very similar to the situation with refactoring and hiring staff. The project has final deadlines and there are intermediate ones. For the next intermediate period, they will definitely be beaten on the head, depending on tactical successes, and the final one will not be soon and it falls out of the planning horizon for some. This is not a specific person’s problem. This is a role-based disposition. The individual can only follow the role or try to overcome it. If you feel that the role strongly pushes the strategic goal, it is better to talk about this with the business manager of the project, outline the advantages and disadvantages of the solution options and do as the business manager of the project decides.
Business Project Manager
The business manager of the project is the most important person on the project. It is he who is the source of ideas, the point of contact with the final audience and the representative of users in the project. If there is a customer, he is also a representative of the customer’s interests. At the same time, it should be remembered that the project works for the end user — only the end user will decide whether the project was successful and whether it is possible to use the created product. In a startup, the role of a business leader is played by an entrepreneur, one of the founders of the startup.
The practice of work has shown that such a fundamental factor as time constantly puts pressure on the business manager of the project. In the case of a corporate project, these are strict deadlines set during the conclusion of the contract. Some integrators, even when selling a project, lay down a 20% lack of time, forcing developers to work these 20% of the time for free. In the case of a startup, this is money that must be paid to members of the development team. In the case of an invested startup, this is reporting to investors for unrealistic deadlines in the name of receiving investments. All other project management problems directly stem from this factor. The main ones were considered a little higher.
The quality of a business project manager is determined precisely by the ability to work under time constraints. Firstly, do not panic the development team by constantly changing priorities. Secondly, treat miscalculations with understanding and help solve emerging problems. Thirdly, to be able to build tactical business tasks so that the strategic goal of successful completion of the project is achieved.
Circumstances force the business manager of the project to sometimes make crazy decisions at first glance. Moreover, in the case of a group decision-making by the development team, these decisions are often supported, since it is simply unrealistic to implement other, formally correct and optimal ones in these specific conditions. A wise business project manager knows how to soften this blow of madness by explaining what is happening and showing that he understands everything perfectly.
Actually, when getting acquainted with a business project manager, it is necessary to find out exactly how well he understands the difference between theory and practice, how well he is able to combine an understanding of project management with situational decision-making. This is clearly seen in interviews, including from the questions that he himself asks.
In any case, whatever the business manager does during the project, it is necessary to be with him and help him. No matter how strange his actions and requests may seem. His actions are always aimed at the success of the project and he is guided only by this goal, and the success of the project is also your main goal.