Cooperation agreement. Necessity or whim?
When cooperating with programmers, it is important to agree “ashore” on the rules of interaction. I offer you a set of such rules, accumulated over the years of project management. Some points may seem obvious to you, some will arouse interest or rejection, some will surprise you, but all of them, one way or another, have been worked out in practice and tested in battles. So you can safely adapt them for yourself and use.
This agreement is designed to establish a trusting business climate when working together on projects and solving related problems.
If the specialist understands that the task is set incorrectly, then he clarifies it to the degree of one-to-one correspondence with the customer.
The specialist offers possible solutions that may be useful for the project, but are overlooked by the customer.
The specialist follows the recommended design methods, pays attention to the cleanliness and ergonomics of interfaces, adheres to development standards, in the implementation environment adopted on the project.
If the task can be solved in different ways (affecting the cost of the solution), then the specialist must agree on the implementation option with the customer before starting work.
The specialist prefers to make the most of the typical features of the system instead of software improvements.
Changes to typical vendor configurations (if necessary) should be made as sparingly as possible. As a basis for changes, it is preferable to use well-known freely distributed ready-made libraries.
The use of paid libraries and other embeddable code protected by the rights of third parties must be agreed with the customer.
The specialist assigns the final cost of the stage of work or the entire solution before the start of work on the stage (project).
The specialist keeps within the deadlines that he announces, and independently notifies the customer about the readiness of the work.
The specialist regularly communicates with the customer, demonstrates to him the intermediate results of the work and, if necessary, corrects the direction of development.
The specialist answers the customer’s questions in a timely and to the point. If the answer to the question requires time, then the specialist notifies the customer of the time frame necessary for him to answer.
The specialist chooses cooperation and dialogue instead of criticism and teaching.
The specialist independently tests his solutions and makes adjustments to them if bugs are found.
The specialist documents the development and comments on the program code.
If, in the process of working on a project, a specialist sees “non-optimal” or obvious errors in the already implemented functionality, then he informs the customer about this and, with his consent, eliminates them for an additional fee. fee.
The specialist retains the efficiency of changes previously made to the product (unless otherwise follows from the task). Checks the serviceability of existing mechanisms in case of functional intersection.
After the introduction of changes into commercial operation, the specialist is ready to promptly eliminate the identified shortcomings associated with the loss of efficiency of the mechanisms caused by the changes.
The specialist does not restrict the customer’s access to the software, program code, databases, files and services used for the operation of the software or integrated with it, does not encrypt data, and does not set passwords or other restrictions.
For violation of the clauses of this agreement or ignoring them, the specialist may receive a warning from the customer. In case of repeated systematic violations, the specialist is removed from the project.
I use it in several formats. None of them I consider a priority. It all depends on the scale of the project, the experience and qualifications of the programmer, as well as the degree of mutual trust between the PM and the specialist.
You can use all three points in the desired combinations according to the situation.
Important! My observations show that hard-skill programmers who do not have developed socially oriented skills are more likely than others to disappear after becoming familiar with such “burdensome” conditions.
So if your style of work as a project manager allows you to have such people on your team, then be careful with this convention – you may miss out on the silent geniuses.
Good luck with your use of convention and breakthrough ideas!
