background
Everything has a background so let’s talk about the background first.
The business of the company consists of several parts, including A, B, C and D. Before this, there were only two leaders in total, which inevitably required one leader to take care of the development of multiple ends. Along with the expansion and expansion of the company, the original team establishment has gradually become bloated and difficult to handle, A leader is obviously unable to take care of so many iterative task and personnel allocation, and new ways of the two leader is responsible for A client and B side respectively, the original two leader is responsible for C and D respectively, The distribution seems to have nothing to do with me.
The group I am in is terminal D. The new leader is not familiar with the current business, and the focus of the task is that Terminal D needs to merge the existing business in region V of the company, which needs to be re-developed and integrated. Since I am familiar with the current D-side business, I can only rush to the shelves, so the requirements of subsequent iterations are basically under my control (no reason, but I have to work π).
do
Requirement review
In the stage of pure brick moving, there is also a requirement review, but we will not pay too much attention to details. Most of the time, we will listen to a general idea, and then check the PRD to deduct details. There is no need to discuss with others or express our own opinions in the review meeting, because there is a leader above. But when I came to do this, I found it was completely different. At any time in the meeting, you will be called by others, such as: “how to achieve the logic of this point”, “is this design reasonable”, “does this point need client support” and so on. It is common to get stuck at the beginning, and sometimes even make a random answer in order to answer the question of the day, obviously the whole process of panic. Later, I reflected on what I lacked in the whole process. Several problems were found:
- I am not familiar with the previous business and cannot think about the whole problem when referring to relevant business points. This makes up for the previous PRD, at least knowing the general logic of this business point.
- There is no pre-review of PRD before the meeting. PRD meeting is more like a discussion. The premise of discussion is that the participants know the context of the event and what they will talk about in advance. You can’t follow someone without knowing what they’re saying beforehand.
Task split, personnel allocation
For the new demand point is usually a large surface, need to split into thin points and lines, the benefits of doing so are 1. It’s not easy to miss details. 2. It is convenient to evaluate the working hours. If a task is longer than three days, we should consider whether it can be smaller.
Evaluate the available manpower. Not everyone has nothing to do. Allocate tasks reasonably so that the manpower can be fully utilized. And of course that’s not the only criterion, when you assign people you need to think about relevance, the relevance of the current task to the person who did it before, and if the person who did it before should be assigned as much as possible because he’s more familiar with it, and maybe the reader thinks that’s the right thing to do? However, IN my work, I did encounter that unfamiliar people were asked to do unfamiliar things. The reason was that it was beneficial to get familiar with the overall business, but I personally thought that the disadvantages outweighed the advantages. Another point is that some tasks are only suitable for one person to complete, such as the sequential logic. For modules with stronger independence, teamwork can play a greater role, not the more people the better.
Plan design, pk with PM
The implementation difficulties in the requirements were proposed in advance for scheme design, such as:
- For complex business logic, flowchart or sequence diagram can be drawn in advance to clarify the logic context, so as to facilitate the follow-up development to avoid missing logic.
- For the technical difficulties, carry out the scheme research in advance. There are often multiple implementation schemes for the same result, and various implementation schemes often have their own advantages and disadvantages. Therefore, it is necessary to weigh which one is more suitable for the current implementation requirements, etc.
For unreasonable or high implementation cost and low cost performance points, timely put forward to discuss with PM or even PK, sometimes need to argue, “this function can not be done” that is for a reason.
scheduling
Scheduling should be combined with the manpower situation, each end time. Sometimes the manpower is not enough, and the deadline required by PM is very urgent. At this time, the problem will be thrown out and PM can determine the priority by himself. Even with such a small amount of manpower on his neck, he can only choose the urgent thing to do first.
To determine the time of joint adjustment with each end, usually each end is developed at the same time, for example, to determine the time of joint adjustment with the back end, this part of time needs to be reserved.
Emergency response and handling
- PM requirements change
It is estimated that everyone has encountered the PM’s temporary change, which is inevitable. If it is the demand change of the business side, it should be changed or should be changed (if the change is too big, we can only feedback back and redo the demand review again). If the PM wants to “show off”, sorry about the next iteration.
- A Bug to follow up
Bugs are better if you don’t have them. I won’t go into the details. For online bugs, a detailed description should be provided after the solution, including the cause of the bug, the impact of the bug, whether the emergency hotfix is needed, and the solution of the bug, etc.
- Everyday tool man
No matter who has a problem, the first time to find you, but also have to take the trouble, sometimes several people at the same time. There’s no way, of course, to smile.
Pre-release preparation
- Code review, the standards of each family are different, so I won’t go into details.
- Fill in the release plan and what content has been released for subsequent tracking
Work after release
The release of the project does not mean that it is finished, but also need to follow up the follow-up acceptance, whether there are bugs and so on. Of course, the project is not naked, there is access to the monitoring system, after the release of monitoring data need to pay attention to the feedback, timely detection of anomalies.
feeling
Disadvantages:
This set down to tell the truth to code point code, that is really no time. Time is wasted on the bits and pieces. The brain needs to multi-task, different tasks need to switch back and forth, heart tired!
Advantages:
- Global control ability has been significantly improved. Most of the time before moving bricks was limited to local areas. Now after the horizon is relaxed, the global understanding of things has been greatly improved, and the things that different horizons can do are of course different. It also solves the problem that has been bothering me for a long time. Why do some newly recruited leaders quickly get started with the business so easily after they just come to work? Personally, I think the global vision is quite important.
- Learn to be active and positive thinking, which I think is the biggest harvest, growth is always your own business, do not wait for someone to train you, to give full play to their own subjective initiative, think about how to use their existing resources and tools to improve their work efficiency. And don’t think, “I’ll think about that when I get there.” It’s usually the other way around, and most of the time you got there because you had the ability.
- As a leader to communicate upward and downward, communication is the most time-consuming and laborious work with emotional intelligence. Up what to weigh the things need to be pushing up, there are some things you can do your own decision, but not sure what must upward feedback and seek solutions, this is not to wrong not back pan (of course this is one reason for the large π), the policy makers view wider resources more contacts with more solutions more, of course, If we hide our problems or are too shy to talk about them, the fryer will turn ugly. When communicating down, you need to control your emotions, be specific, clearly assign and communicate tasks, and remember to be bossy and condescending (anyone who has been treated this way knows how uncomfortable it is).
- How do you make your soldiers move bricks happily and smoothly? I’ve seen this happen many times before, where the task has already started and the people below come up to you and ask, “What should I do?” As a competent leader, this should not happen. Before the task starts to develop, it is necessary to split the task carefully. During the process, we should think about the details that need to be paid attention to and whether there are any difficulties in implementation. If there are any difficulties, we should put forward the plan in advance for discussion in the group and make sure that there are no directional mistakes at the beginning of development. When writing business code, the most annoying thing is that something interrupts me and leads to discontinuity of thinking. Therefore, I make myself the entrance of a team. I first pass everything from myself, and then I allocate or solve it myself according to the situation of my subordinates.
- Don’t show your shyness, which is very important for me. I think it is the basic quality of a leader. No matter you are right or wrong, if you are wrong, you should admit it freely. As a leader of a team, everyone at the bottom takes you as the target of their behavior. No matter what is right or wrong, everyone at the bottom needs a target. Only with a target can they have the direction and motive force to move forward.