If you say that your team is better than others, what is the reason? Because everyone has outstanding professional ability? Because you know great processes?
Or some other reason?
Have you encountered the following problems?
1. Your developer completed a feature, only tested the main process, and it looks good. So it is marked as done and forwarded to QA testing. QA found a serious bug and just clicked the cancel button halfway through the normal process.
2. Your developer is assigned to a subtask to develop an API, and the API requirements are written in detail. He finished quickly and started doing integration tests with the caller. At this time, he found that what he did was very different from the original expectations of the caller.
3. Still your developer, he wants to fix a bug. He checked the existing code and found it to be ugly. But it's easy to fix, if he just wants to fix the problem, it's just two lines of code change. However, the code is still ugly, and it will still be very complicated to change the function in the future, unless it is refactored. He silently chose a simple modification without discussing it with anyone.
4. Your QA person is testing a new function, the function and the description of the requirements are 100% consistent, but he feels that some parts are not smooth when using it. He passed the functional test.
5. Every time our developers want to run the entire development environment, they have to update the code from 4 code bases, click to build in 4 projects, and then start 3 application servers and start the database. They slowly get used to this kind of trouble.
6. We have a developer. In Shanghai, we have an American colleague who is QA. There is a time difference of almost half a day between the two. The developer in Shanghai is about to get off work, and the functions at hand can be tested by QA in the United States with some finishing work left. Estimated 30 minutes more. The developers decided to get off work and resume get off work the next day. So American QA waited an extra day for the test. But nobody but this developer knows that.
7. Your UI developer has made a beautiful HTML prototype that 100% shows the UI effect the designer wants. But the UI library used in the prototype conflicts with the one used in the existing application. Either the engineer needs to spend a lot of time refactoring the existing code, or the UI developer redoes his prototype using a different library.
In all of the above examples, did anyone violate the process? No, unless we write all the above cases into the process. Given time, I can also list hundreds of situations that are not specified in the process. So there can be no single process that can prescribe all situations.
But can they do it differently?
#1, he can choose to complete a simple smoke test before submitting the problem to QA test; he can also choose to run through all the processes like QA first to ensure that QA can't find bugs.
#2, he can choose to read only the description of the product manager; he can also choose to discuss it with the caller before development.
#3, he can choose to fix the bug as soon as possible; he can also choose to raise the problem of the code to discuss whether to refactor.
#4, he can choose to only listen to the product manager; he can also choose to put forward feedback from the user's point of view.
#5, he can choose to endure this tedious manual work; he can also choose to build a script to do it automatically.
#6, he can choose to leave work on time at a regular rhythm; he can also choose to stay for an extra half an hour and let QA test early.
#7, he can choose to implement the UI effect as soon as possible; or discuss it with the developer before doing it.
If they keep abstracting their ideas, it is: always consider the work of downstream personnel, think like users, improve everything that can be improved, and so on. These ideas are not professional skills or processes, but these ideas constitute your team culture and make your team different.
The new team generally does not have the same way of thinking, everyone has their own perspective and foothold.
A well-trained and experienced team, they encountered various scenarios, dealt with various problems together, and finally they established a tacit understanding.
It's the team's own tacit understanding, so they spend less time communicating the problem; they can reach an agreed course of action faster; they can react faster; they can find answers in fewer attempts.
It's a team with a strong style and it's very efficient!
Who will create the culture?
Usually the leader of the team.
If the leader can get into every detail of the project, care about every little thing. Then, each member of the team will naturally pay attention to every detail, because they know that their boss pays attention to this.
If the leader thinks about how to do the next link when doing each link, then the members will naturally learn to think more.
If leaders are always thinking about how to improve efficiency and reduce manual processes, they are asking this question all the time. Members also share this mindset.
If the leader always considers the problem from the user's point of view and tries, when the members think about the problem, they will ask themselves, like a leader, what would I do if I were a user?
Want to build a team with your own style? Try this:
1. Take the time to recall all the scenarios you have encountered, extract ideas for what the team members should think in those scenarios, and summarize them into short sentences.
2. These few words are the key words of your team culture.
3. Tell your team about these keywords.
4. Pay attention to the scenes related to these keywords in the future.
5. Encourage team members if their thinking fits with the culture you want.
6. If a team member’s thinking doesn’t align with the culture, point it out, tell them what you think, and the latter will do it for them themselves.
7. Have your members mentor newcomers in the same way.
8. Refine and improve keywords according to some scenarios that were not considered before.