The most important thing is that programmers do not understand how to communicate with the customer and with each other. How to build a continuous quality product development process. How to plan your work day and sprints.
And all this ultimately translates into disrupted deadlines, overtimes, constant showdowns over who is to blame, and customer dissatisfaction - where and how everything is moving. Quite often, all this leads to a change in programmers, or even entire teams. Loss of a customer, deterioration of reputation, and so on.
At one time, I just got on such a project, where all these charms were.
Nobody wanted to take responsibility for the project (a large service marketplace), the turnover was terrible, the customer just tore and thrashed. The CEO once came up to me and said that you have the necessary experience, so here's the cards in your hands. Take the project for yourself. You screw up, we will close the project and kick everyone out. It will turn out, it will be cool, then lead it and develop it as you see fit. As a result, I became a team lead on the project and everything fell on my shoulders.
The first thing I did was design a workflow from scratch that matched my vision at the time and wrote a job description for the team. It was not easy to implement. But somewhere within a month everything settled down, the developers and the client got used to it, and everything went quietly and comfortably. In order to show the team that this is not just a "storm in a glass", but a real way out of the situation, I took on the maximum amount of responsibilities, removing the unpleasant routine from the team.
A year and a half has already passed, and the project is developing without overtime, without "rat races" and all kinds of stress. Someone in the old team did not want to work like that and left, someone, on the contrary, was very keen that transparent rules appeared. But as a result, everyone who is in the team is very motivated and knows the huge project in full, with both the front-end and the back-end. Including both the codebase and all business logic. It has even gotten to the point that we are not just "rowers", but we ourselves come up with many business processes and new features that the business found to its liking.
Thanks to this approach on our part, the customer decided to order another marketplace from our company, which is good news.
Since this works on my project, maybe it can also help someone. So, the process itself that helped us save the project:
Teamwork process on the project "My favorite project"
a) In-house team process (between developers)
- All tasks are created in the Jira system
- Each task should be described as much as possible, and perform strictly one action
- Any feature, if it is complex enough, is broken down into many small swaps
- The team works on features like a single task. First, we do all together one feature, send it for testing, then take the next one.
- Each task is marked, for the backend or frontend it
- There are types of tusks and bugs. You need to indicate them correctly.
- After completing the task, it is transferred to the status of code review (this creates a pull request for your colleague)
- Whoever completed the task immediately tracks their time for this task.
- , , , , , .
- , , ( ), , - . —
- ,
- ,
- , , . ,
- : To Do → In Development → Code Review → Ready deploy to dev → QA on dev → (Return to dev) → Ready deploy to prod → QA on prod → Done
- , . , , .
- . , .
- .
- , .
- , , , , .
- , , , , . ( ) . , /.
- ( 12.00)
- , , , . . , . , , .
- , . .
- , , , , .
- . .
- . , , . . , , , .
- , . . .
- , , . .
- Every day, the developer must write in the client's chat about what tasks he worked on yesterday and what tasks he will work on today
- The workflow is based on Scrum. Everything is broken down into sprints. Each sprint lasts two weeks.
- Sprints create, fill and close a team lead.
- If the project has strict deadlines, then we try to approximately estimate all tasks. And we collect a sprint from them. If the customer tries to add more tasks to the sprint, then we set priorities and transfer some other tasks to the next sprint.
b) The process of working with the customer
- Each developer can and should communicate with the customer
- The customer should not be allowed to impose his own rules of the game. It is necessary in a polite and friendly manner to make it clear to the customer that we are specialists in our field, and only we must build work processes and involve the customer in them
- , , - , - (). . , , , .. , , , , , , .
- /-/ .. /, .
- . , , -, /.
- , . , , . .
- , . . , .
- , , . , . , . , . .
- , , . , . , .
- If the customer begins to come up with different tasks from his head, begins to fantasize and explain on the fingers, then we ask him to provide us with a page layout and flow with logic that should fully describe the behavior of the entire layout and its elements.
- Before taking on any task, we must make sure that this feature was included in the terms of our agreement / contract. If this is a new feature that goes beyond our initial agreements, then we must definitely evaluate this feature ((estimated lead time + 30%) x 2) and indicate to the customer that it will take us so much time for it, plus the deadline is shifted by two times the estimate. Let's make the task faster - great, everyone will benefit from this. If not, then we are insured.
c) What we do not accept in the team:
- Optionalness, lack of assembly, forgetfulness
- „ “. , , , .
- , . , , :)
- . , , . , , — . -, .
- .
- ! - - , .
And a number of other questions / theses that I sometimes ask my customer to remove all misunderstandings:
- What are your quality criteria?
- How do you determine if a project has a problem or not?
- Violating all our recommendations and advice on changing / improving the system, all risks are borne only by you
- Any major changes to the project (for example, all kinds of extra flows) will lead to the possible appearance of bugs (which we will, of course, fix)
- It is impossible for a couple of minutes to understand what kind of problem occurred on the project, and even more so to fix it immediately
- We work on a specific flow product (Tasks in Fat - Development - Testing - Deploy). This means we cannot respond to the entire stream of requests and complaints in the chat
- Programmers are just programmers, not professional testers, and cannot ensure the proper quality of project testing
- , , ( )
- ( ), ,
- — ,
- , , , ,
- , , , ,
- .
- , ( ),
As a rule, the customer immediately realizes that everything is not so simple in software development, and desire alone is clearly not enough.
In general, that's all. I leave behind the scenes a lot of negotiations and the initial debugging of all processes, but as a result, everything worked out. I can say that this process has become a kind of "Silver Bullet" for us. New people who came to the project could immediately get involved in work from the first day, since all the processes are described, and the documentation and architecture in the form of diagrams immediately gave an idea of what we are all doing here.
PS I would like to clarify that there is no project manager on our side. It is on the customer's side. Not a techie at all. The project is European. All communication is in English only.
Good luck to everyone on projects. Don't burn out and try to improve your processes.
The source is on my blog .