preface

Programmers in mobile terminal development, including Android and ios, will have the opportunity to become mobile terminal team leader and take on certain management tasks after working for 3 years. In this article, the experience that serves as a group leader 1 years on oneself makes a summary, give the friend that needs some reference, pure individual sentiment asks much correction.

controllable

This is an important word, and my boss has repeatedly stressed to me that the core of project management is control.

The development time of a project is fixed, and even in most Internet companies time is not enough. From start to finish, the people involved in a project are not only the client side, but also the test and server side, as well as the product. Is everyone able to complete the task at hand? Frequent changes in requirements and unexpected technical difficulties in the early stage are uncontrollable factors. Any failure to do well may lead to the project being out of control and the final result is overdue.

As a group leader, we should start from the following aspects:

  1. A very important point is the assignment of tasks. To fully understand the characteristics of all members of the team, assign tasks to the right people. Also note that the development of a module is best arranged for two people to work together, rather than one person for each module.
  2. Task segmentation. It includes task time demarcation and task description, which are very challenging operations. How to accurately clarify the context of the task before development and write it out in the description so that relevant personnel can avoid stepping on pits is the key to controlling the task schedule. The task granularity should be fine enough to accurately control the completion of everyone in the following morning meeting.
  3. Task priority. Technical selection must be carried out in advance, the scheme can start. Basic tasks, the important requirements tasks in this version, will also come first. The principle is to focus first, then light.
  4. The morning session. Short weekly meetings are indispensable, with different priorities at different stages of development. In the middle stage of development, I focused on understanding the progress of each developer (including the server), communicating some technical problems, and timely reminding some overdue tasks as the group leader. In the later stage of development, it is mainly a clear change of the demand adjustment, for large changes should be discussed again. In addition, grasp the relevant test progress, urge testers to increase testing efforts.
  5. We should pay close attention to the development progress in real time. We can assist in the intervention of technical difficulties. If it fails to be solved for a long time, we should stop it in time and carry out the subsequent development. In the later stage, we should deal with this difficulty flexibly: for example, we should use special methods to avoid it temporarily, or negotiate with the product to put it into the next version.
  6. Two key nodes must be protected: the function block board and the 0bug. Function sealing board refers to the client to complete all development tasks, can be barrier-free delivery test, 0bug is the last line of defense for the release.

Do things first

You need to spend more effort than others to anticipate the unknowns: requirements irrationality, undescribed areas of the solution, and point them out before development. The server-side interface definition is adequate to meet development requirements and should be reviewed in advance. There are also obstacles to client development, including complex module programs, some technical studies, some pits and so on.

You need to be at least a day or two ahead of schedule to prepare and always be prepared for the worst.

Every morning, I need to know the task progress of the team members and the server side, and I need to run and go through each module of the APP at both ends when necessary. From my experience, most of the time, the progress of the task on the meditation path is not clear, obviously the function is not completed, he will say that he has completed, at this time if you do not point out in time will directly lead to 0 bug behind the node lost! Don’t trust the data too much. Trust your eyes.

There is also the WORK arrangement of THE UI, to communicate with the UI at the same time in advance to determine the task time, do not go to the client local development is almost completed, only to remember that there is no UI cut map to give the whole. UI cutout should be completed at least 1-2 days ahead of the client’s local development deadline so that all local development can be completed smoothly.

Steer the project forward

Everyone is doing his or her own job, and the server and product may be responsible for other businesses, so it is difficult for everyone to devote 100% of their energy to the project. There may be some conflicts where the project is stalled. We should take the initiative to organize a short meeting for everyone to participate in the discussion and solve the problem.

Result oriented

You’ve probably heard a lot about process-oriented and results-oriented, and sometimes you’re asked about it in an interview, but I won’t repeat the distinction. Suffice it to say, managing a project is absolutely results-oriented. I don’t care what happens in between, just tell me the result and whether you can keep your promise. This is also the group leader of their own requirements, since the boss is willing to give this responsibility to you, so everything to the results. It turns out there are still dozens of android and ios bugs. You can come up with a dozen reasons, but it doesn’t make any sense. If you had done a better job of breaking down tasks, if you had focused more on progress in the early stages of development, you wouldn’t have gotten where you are now. Look for reasons from yourself more. I believe in one sentence: any bad result is not what happens in the process, but what we do.

Some challenges

As a rookie team leader, I feel that the biggest challenges this year are mainly in the following two aspects: first, the subdivision of development tasks. Without sufficient accumulation of development experience and thorough understanding of requirements, this is still difficult to control, after all, it is not easy to clarify the ins and outs of a task before development. But it is important, and in my experience the quality of the task segmentation is directly related to the progress of the feature development.

Second, the early stage of the release of the schedule control, including demand changes and trade-offs, unable to solve the technical difficulties. The rule here is: release stability is the priority, and major requirements changes should not be introduced later! For example, the version will be released in 3 days, so you have to personally review the code submission in the next 3 days, and requirements changes are basically rejected. If there are still ideas and technical difficulties that have not been overcome, it is suggested to take special measures to temporarily avoid, and then pay back the technical debt.

The above is my experience of serving as the group leader for one year. Please forgive me if there is any mistake. Write so much for now, there are some other thoughts to continue to share, thanks.