Managing people is actually making them do better
Preface
Maybe a new friend learned that I was prepared to leave the job in the early stage. Later, after several rounds of conversations and communication with colleagues, I discussed the decision back and forth with my partner and stayed for the time being to continue working. This process is also a lot of thought for me. Maybe I am still not confident enough or fearful. I don't want to be too entangled so far, but the resume is still public. Maybe this is riding a donkey to find a horse. At the same time, I think that I can always pay attention to the external situation to ensure that I have the ability to migrate, and I am fully prepared even if I leave at any time. Back to the main story, this time I want to talk about my role as the leader of the project testing team after I stayed, so I want to talk about [Management] experience.
New change
I have always said that I am a person who does things and is not suitable for leading people or being a leader. But then I slowly discovered that the word [to bring people] has many meanings. If it is at a high level, you can be a master to teach others one or some skills. But for me, I don't have the ability to become a master. I'm just a grassroots or grassroots person with little experience and experience, so in my definition, there is only one thing: cooperation. In fact, when we work together, we all want to be respected. We don't want to do things with someone who is high above and leaning on the old and selling the old. So I think this is not a question of managing people, but a question of [how so many of us do one thing well]. So, based on this starting point, I disassembled the problem and the matter and got the following three experiences:
Work experience
1. The division of labor is clear, and tasks are dismantled to personal responsibility.
Because our system applications currently have PCs and small programs, with multiple backends: administrators, merchants, platform operations, etc.; as the most familiar with existing functional systems, I can clearly understand which tasks are important and those that have complex business processes. . According to the iterative functional requirements and business changes, the key points of each test can be decomposed, so from the beginning, the division of labor is like this: pre-explain who is responsible for the use cases of this iteration, each person is responsible for the corresponding modules, and what are the key points of the test . Therefore, the above sub-union will be announced in the test group, and it is explained that if you find any omissions, you can add them in time. After that, for new iterative requirements, the person responsible for the corresponding module has been following up and actively communicating with the product and development to understand the requirements. When all the development reviews are completed, the test cases will not be edited, so that it has been in order. In progress, there will be neither too much conflict nor too much duplication of work.
One point to note here is the most taboo in the division of labor: you can't think of yourself as important, and assign the heaviest to yourself every time. You must believe that TAs can test the modules assigned to TAs until they come back online, otherwise Will be exhausted and unpleasant.
2. Let TA be responsible for their commitments.
After the division of labor is determined, until the normal functions are launched, there will still be unexpected bugs from time to time, especially the bugs that appear in online use. At this time, the market will feedback in time, and the test needs to determine the severity of the problem, and then promptly contact the operating market Communicate, if it is serious, it needs to be repaired and launched online, otherwise, it will be used as a minor repair and optimization to be launched together with other defects. Boredom is that in the face of any feedback, we all need to locate the problem in a timely and fast manner. In this process, the market will know which test can provide timely feedback and response to these situations, develop the habit of [dependence], and they will know who to look for and get feedback faster. This process of working together to deal with problems back and forth will quickly reveal how well each person is capable. As if it is obvious to all, I understand the strengths and weaknesses of them, so internally and externally, I need to communicate with them intangibly and tangibly. For example: for a period of time, I took a 4-day vacation to go home, and I made work arrangements and explained to the corresponding person in charge before that, and I asked the TA to handle it during this period. When I was at home, I was asked when I would go to work. A certain test will only pass on the problem and cannot help them solve it. I can't do anything at this time, I just respond well and I will go to work the day after tomorrow. Inside the test, I can’t question and rebut other people’s comments like this, because it’s my responsibility to come back. I can’t make them like me or do better than me, I can do After coming back, I made a return to all the problems that were solved, and gave feedback and processing time one by one. In the follow-up, they still need to continue to follow up and give feedback, and I need them to understand: this is the responsibility of together, the responsibility of testing.
3. Let TA make mistakes, don't think about taking on and avoiding pits for TA.
Because those who come out to work after graduation or are in the internship period may have a lot of passion for work and study, they cannot limit their motivation, and actively encourage them to learn more and understand more. When I just came in, I was a little afraid of doing it, but I didn't dare to do it for fear of making mistakes. I used to be like this. I often need to ask clearly and confirm before I dare to start. They also showed that they want to learn more as soon as possible and learn more about the tools available at work. Sometimes I want to tell them a lot, but then I found that it would be better to talk about it when it was needed. Some said it in advance, but they didn't think of it when necessary. Sometimes I feel that I have worked too much, thinking about avoiding being scolded for stepping on the pit in advance for them. But later I found out that I was always worried, because they always need to be on their own, and I can bear the burden when backing the pot, but to really learn from it, I still need to think and reflect on my own to get the results. These are the avoidances. The experience of stepping on the pit.
4. I have to break down my tasks and lead by example.
Because I personally feel that I have a kind of toil, I have to deal with everything to be assured, because I am always afraid of omissions and big mistakes in the things they deal with; but it turns out that no matter how well I control, there are always unexpected bugs, and then I Still need to back the pot. Later, I got used to it, and I thought, they handled this piece at the beginning, even though I have seen it roughly, there are problems in the follow-up online, I still need to take it down and solve it right away. The sensible people see these are unexpected The problem is not tugging braids. After experiencing some requirement changes that I didn't know, I found out that only the TAs knew. I would know about it, and then let the TAs update the document so that any subsequent changes can be synchronized in time and will not be inconsistent with the outside world.
Then before each iteration starts testing, I will first divide the work, divide the main module and logic, and rotate next time. Everyone is responsible for the modules in their hands, and if there are linkages, they need to communicate or connect in series to test. In fact, after handling affairs, outsiders will clearly see which person is capable of doing things, so I don’t need to teach them what responsibility is, what is closed loop, and I don’t want to be a mentor. I will show it to TAs and be the market. Feedback to us if there is a problem, our test is not to pass on the problem, we need to locate the problem, to think about why it is like this: whether there is a problem with their operation, whether it is a data problem, why there is a problem with the data, etc., the problem is located, and the developer is asked to solve it in time , When will the solution be completed, give feedback to the market, the development process is completed, the normal process returns to see if there are any problems, until the online use of market feedback is no problem.
The above is just my personal opinion of working in a group during this period. More practical experience is still to be accumulated by myself. Keep going.