Author: cloudward
Note: This article belongs to the original, and any use must be approved by himself.
Do the most detailed project tracking
The project plan told us how to complete the project, but the implementation of the project plan is not always moving along a predetermined track. It can be sure that if there is no sound feedback mechanism, the planned execution will certainly deviate from the predetermined track, and the only measure to avoid the most detailed project tracking in the implementation of the project plan, and perform a slight deviation in the planned implementation When it is correct, it is correct, which is based on feedback in the control theory.
Macroscopically, heavy project management methods tend to spend more time for a detailed project plan to ensure the controllable execution of the later schedule. However, a meticulous plan cannot replace meticulous tracking.
1.1. Refinement task
Modern control theory tells us that the accuracy of control is based on the particle size of the controlled quantization. The more accurately controlled it, the more accurate it. This trend is corrected because this trend is corrected when rare offset. But quantification is not cost, excessive quantization will increase cost, so there is a trade-off between this.
Agile project management should be able to do random strain, cope with various possible conditions, and establish a segment of the task, and take high frequency detection on the task's status and timely adjustment. So what extent is the task is going to? This is not determined. Projects in different sizes may have different, but my experience tells you that if you can, let your task work as much as possible within one day.
1.2. Control the particle size of the task
The loss of the project plan is often due to the division of the project task is not clear enough, and the particle size is caused. I think this is the deep experience of me and many software practitioners.
Of course, a common rebuttle is "Not we don't want to refine the task, but the project is just beginning, many things are very vague, and you can't divide the task very well." In fact, there are two misunderstandings in this sentence, I want to explain from positive:
First, the task division is independent of the resolution of the product.
Here, I donate a word "resolution" to express the level of understanding of the product. Indeed, the more we have learned a product, the finer, the more you can divide how to complete this product is more fine. But in turn, even if a product is vague, is our mission, can we be divided? In fact, it can be like. Products from fuzzy to clear processes are also the process of problem decomposition. Each big problem can be broken down into many sub-problems, and for each child problem, it can be fully corresponding to the corresponding sub-task. Even if we use "blind touch" as a metaphor, we must figure out what the elephant is, and can always be broken down into part of the head, body, limbs, and tail. Several sections.
Second, the task is divided into the idea of solving problems.
The so-called task is to solve a specific problem, and how to solve this problem, from logically we first need to decompose the problem. Process of problem decomposition can correspond to the process of task division. For example: How to complete the project objective This big problem can be broken down into "How to complete the demand definition?", "How to complete the system design?", "How to achieve?", "How to ensure the quality?", And these sub-problems Can be further subdivided. Then the problem is clear, the task is clear.
Speaking of the granularity of the task, it often sees too rude practices, such as the project task allocation table, generally based on the functional module, and will be divided into sub-function. However, if you assign this sub-function to developers single, what progress you expect to know on the next day of the task assignment?
The granularity of the task is gradually refined, which is the necessary condition for establishing a meticulous tracking. It is recommended to control the particle size of the task within one day.
1.3. Who will divide the task? The segment of the task is not easy, because this subdivision reaction has gradually logically decomposed on solving problems. Therefore, the person who divides the task must be a person who truly understands the task, emphasizing this is very important.
Our common mistakes is to believe that the project manager is a header of a project group, and the work task should be assigned and monitored by him. However, in fact, we have seen this approach: "The project manager does not understand the details of the project!" If the project manager does not understand the details of the work, how can the project task be subdivided? " .
The problem is coming, "So you tell me who should divide the task?" My answer is: designers, developers, etc. All doing specific live leaders.
No one is more clear than the designer, which features which function modules, each module is divided into which classes and class methods, the difficulty of each method, and work hours that need to consume. No one is more clear than developers, there is currently no complete implementation, and how many bugs are waiting to go to FIX, and the time required to complete these tasks. OK, since they are the clearest, they should be divided by them. Because only the actual tasks are divided, our tracking and control can be applied to the idea.
The problem is coming again, "If they deliberately simplify the task?" First, you have to criticize this suspicion. The team's members should trust each other instead of mutual embankment, such a team can work together to success. Second, I tell you that this is also a way. Our products are ultimately in order to be able to define requirements as completion guidelines. If you check the completion of these tasks in a list of demand, you will naturally know if each task is truly contributed to the product defined by the requirements.
Case:
In the Milkyway project, the project manager COBO decided to let designers and developers to complete their own task list list. The first is that the designer lists its own design task list according to the list of demand definitions, and the list is reviewed to the demand personnel to find some of the work in time. Similarly, developers have issued a list of task lists after clearing their own work range and understanding, and the same task list must also be eye-catching in order to find out whether it can be overwritten in time. After the above confirmation, the COBO sensation task list is still very detailed, rich and true, even if there is a little error, it is easy to adjust.
1.4. The priority of the decision task is discussed before discussing this problem. I gave an actual case: case: The test department submitted 20 bugs for Jack yesterday, Jack first saw it, these bugs can be divided into three categories: first The class is an interrupted error, that is, the tester is interrupted by various reasons in the test, such as throwing an abnormality, no response, no reason to exit, etc., resulting in failure to test. The second category is an interface error. Many modules cannot properly display the form creation by many modules due to the user's information that cannot be obtained correctly. Third categories are verification logic errors within the program, such as those who are not necessarily recorded, must be entered.
In addition to repairing BUG, Jack today intends to write an email to Daniel writing an email to be responsible for controlling controls to clear a new demand. Because Jack discovers that the user tree on the left of your user management interface may need a function that can be quickly locked by the keyboard. Of course, several code issues that the project manager to take a check in the unit test will also be revised as soon as possible, and the project manager has arranged Tomorrow. Usually Jack is still very efficient, but now there is a lot, Jack does not know what you have given priority to those tasks.
In fact, the tasks in the project will always be more than your energy and resources. So how to complete the task to bring you success? The answer is to always subdivilize the task of your hand and schedule the priority of the task.
What determines the priority of the task? In your hand, there may be many tasks, what is the task should be dealt with? This is a universal problem. This issue has no standard answer, but there are some principles of judgment. As long as you master these principles, and you can use it in your project, you will become a high-performance person. Traditional project management is often used "Important and emergency, important but irresponsible, not important but urgent, not important, not urgent", "four quadrant principles" to guide individuals to deal with priority judgment guidelines, but this is more void, specific to Software project tasks, you can refer to some judgment guidelines: Principle 1: If this task is very easy, the resources and time consumes very little, then its priority is higher than those who are difficult to organize.
This principle actually reflects a "psychological tactics". The task does no matter whether there is or less accomplishment in the general meeting. Like the test answer, it is difficult to learn from the psychology first. Principle 2: If the completion of this task allows a batch of tasks to take a selection of phase, then its priority is higher than others.
Whether you are or your leaders, you are eager to hear successful messages. Give priority to a task If you can change a batch of tasks to "OK", this will be able to encounter. For software projects, morale is undoubtedly a necessary condition for many things. Principle 3: If this task is capable of completing, it will be done directly or indirectly affecting the tasks of other people in the team, then this task is high.
The success of the software project must be the success of the entire team. The priority is done, allowing the entire team to work in parallel, thereby achieving better progress. Principle 4: If your boss cares more about your task, then this task has a high priority.
Help the project success also helps you succeed. And helping yourself succeed, your confidence will inevitably help the success of the project. 1.5. The expectation of each task is expected and the inverse task at the same time, or later, this task is expected to be given. For project members, although starting, it is very difficult to complete the task's completion time, but we see from practice, as long as each member of the team insists on doing this, it has formed habits, then the entire project The task seems to be much better than this. The biggest feature of software development is very dependent on the work status of members and the communication and coordination between members. The habit of maintaining expectations is conducive to making the entire project's workload and working schedule to maintain transparency throughout the team, which is to fully mobilize the enthusiasm of everyone to ensure the key to the entire team. Who is expected to give the task?
I have always believed that the most understanding of the task is the designer and developer who knows the experience, then the expectations of the task have also been given by themselves. I firmly believe that in the team, integrity is as important as it is, even though "boldly believe in your subordinates", let them decide to complete their own tasks. After the decision, you can track it according to the time of his plan. In fact, you have no reason to believe that your subordinates will deliberately delay the completion time of the task. Because smart subsidiaries often want to be more than your expectation to complete the task, take your appreciation. Only fool will deliberately do your task to complete time does not meet logic delays. Let project members give their own task expectations, reflecting the full trust of leaders. This trust is actually an invisible pressure. "The leaders make me the time I expected to finish the task. If I didn't finish it, how to explain it?". Daily Review
Through the task expectation, the manager and the subordinates have reached a certain time contract. As a subordinate, the only idea is to complete your expected task on time or in advance. For managers, it is necessary to pay attention to this contract, need to actively, on time, and meticulously to the completion of the Review task. Agile Project Management Since the granularity of the task is subdivided into the day, then the task of the expected completed task is required every day. The advantage of Review is the error of the project progress can be controlled with the sky, while allowing the entire team to know the good communication status of each other. Is it necessary to do REVIEW when needed? My suggestion is that it is best to determine a fixed time to review the project status. At a fixed time, it is very important to form a good time concept of the entire team. When is REVIEWREVIEW starting? There are also learning this. One of my colleagues YEW has suggested for half an hour after work every morning, and gives the following reasons: 1. Project members are not late 2. Let the project members enter the tight working state of the beginning of the day 3. emphasize each Personal tasks, helping project members clearly work targets on the day 4. Reserved for project members as a Buffer that completed tasks on time.
A very effective REVIEW system is a daily morning. At the daily morning meeting, the members of the project can report their own project progress. The problems encountered in the work requires coordination, and the project manager can check the progress, lay the new work task and convey the above new instructions. And dynamics. As a team, each member has an uniform understanding of the project, especially if risk is extremely necessary. Morning Club skill
I don't think there is a suspect that the benefits will be brought to the morning, but there will be many people suspect whether it is too wasteful to do it. Here, it involves a skill of one morning meeting. First of all, what do we need to recognize the goal of the morning meeting? The morning goal should be to understand the status of yesterday and layout today. Remember "Yesterday" and "Today" two time range. Since we arrange morning meetings every day, its purpose is to reach today's things today, don't drag the task to tomorrow. At the daily morning meeting, I heard a member talking about not yesterday and today's things, I immediately let them host, "Please don't want it!" The morning time should be as short as possible, so its " "It is greater than" loss ". How to control the time of the morning meeting? Here are several inspirational opinions to share with you: 1. Let everyone establish a time concept, the morning will not be late, the speech is not dragging, concise. 2. Allows everyone to take consistent methods on progress reports, such as reporting forms, strips, etc. 3. Install the routine of the morning, and limit the scope of discussion. 4. It is strictly forbidden to discuss specific technical issues and management problems. To do organizers, learn to control the time of the morning meeting to make project members more responsible for the most prone to experience in the morning, the project member mission is not completed, and strive to find various excuses for themselves. "My task is basically completed, but there is still a problem that I have not solved"; "I can do it, but it happens to be not there, there is no assistance, I have not solved it"; "There are a lot of things yesterday, I haven't completed this task. ". Various excuses are different. More terrible is that project members sometimes lie military conditions, there is no task that has not been completed, lies to report itself or contain confidential not to give you a clear state. How to solve this problem? I think this is a problem that is posing every project manager. There is also a little experience in sharing with you. 1. The task of the agreement is only "completed" and "not completed". Even if you have completed "99%" on your task, it belongs to the "unfinished" state. 2. If the task is not completed, give a reasonable explanation. Please don't tell me a lot of all kinds of original committees, your explanation is very simple. Just hook in the following classification: [] Objective reasons [] Personal reasons [] physical reasons [] technical reasons [] Subject reason, only non-active reasons are acceptable. Treated these "delay events" as a work assessment for individuals 3. The completion of each task is marked "OK" on the list, telling you members, you don't want to see a task from "OK" back to " Not OK. If the task latency is inevitable, the project manager must help members understand the impact on the team. While the project member forms a certain psychological pressure, it can pointed out that the improper handling method is, inspired whether he can do better, thus Help item members will gradually move.
