Work comments: Task Allocation and Management

As mentioned above, when I started to bring a group and received a task, I estimated how much time I would spend, and how many people in the group would be me, estimated time = the total time I need "the number of people in the group (so stupid, don't you need time to explain the task to the team members? Are all my team members better than me? At most I have finished the rest, and I am in a little trouble.) As a result, the actual time is much longer, in addition, some people in the group had nothing to do, while others were so busy that they were easy to combat the enthusiasm of the team members, resulting in dissatisfaction between the members.
With the accumulation of experience, to assign tasks appropriately, first of all, you must have a certain understanding of your team members. It is best to be energetic, secondly, we need to grasp the task (this depends on the needs analysis and system design skills). Here is my experience. I classify my team members (ABC Classification for short ), indicators mainly include technical capabilities, speed of work, and business understanding.
I mainly look at the first two indicators, because I have already familiarized myself with the business during requirement analysis, and I will tryProgramFrom the perspective of the members, describe the business logic with them. The following is my experience in discussing the business with the team members:
1. Be clear about some concepts and terms of business, especially those similar to program terms.
2. Let's talk about the process and draw as many pictures as possible. It's easy to understand the flowchart and clarify the ins and outs.
3. Tell me more about the reasons for doing this (thinking). In turn, you can verify that you really understand the business.
4. The questions raised by the team members should be clearly answered (business Verification and design can withstand the test of others)
Team member classification (out of 10 points for each item ),

Capability level	Technical capability	Speed
A +	Very good (8-9)	Slow (5)
A	Good (7)	Fast (6)
B	Generally (6)	Fast (6)
C	Generally (6)	Generally (6)

Work tasks, mainly divided from two indicators (technical, business), workload,

Task Type	Technical difficulty	Workload
x	large	small
Y	large	large
Z	small	large
Z-	small	small

Assign a task, and move the Task Type check mark to the member of the corresponding capability level (priority is given to the red capability level, descending to the right ):

Task Type	Capability level
x	A + A
Y	A A +
Z	B , A +
Z-	CB, A, A +

The principle for assigning tasks is:Better technology, more mental work, and more physical work after technology.
Not only must the requirements be analyzed in place, but also the tasks be analyzed in place.Many Y and Z tasks can be converted into X and Z-by analysis. The advantage of doing more mental activity, less physical activity, and less development time.

 

Conversion 1 example: a majority of the information systems are: business data input + Data Processing + process control. You can abstract process control into a workflow control component, which can be done by one person in the group, others can directly call the API according to the instructions.
Example 2: Some data tables correspond to the business logic corresponding to the operation is only add, delete, modify (small difficulty, large amount), we can make it into an automatically generated template, directly generate corresponding pages and operationsCode. (Codesmith is a good automatic generation tool, and there are many good templates on the Internet, which are very useful and recommended !)
During normal development, after a task is completed, I will go back and look at my code. I often come up with another method, which is time-saving and labor-saving, then I regretted Why I didn't use this method?
The requirement is not well done. Early coding is a negative task. The Task Design allocation is not well done, and early coding is a lot of work!

Determine the time of the member task
Let everyone estimate the time of each task separately, and PM should also estimate the time of the task. When the gap is not big, the team members shall prevail. When the gap is big, the discussion will decide! (The time should be based on the team members as much as possible, reflecting trust. Then, if the PM is hard to press the time, the team members will surely feel emotional and not conducive to their work, then, the relationship between them is not conducive to subsequent work)

 

 

In actual operations, I will carefully estimate the time for key tasks (such as basic modules that need to be called in many places) and compare them with the team members; for some less important tasks, I just feel the time, as long as it is not much different from the team members (the time of the team members = the time I feel * 2), the team members shall prevail. I personally think that we should assign permissions to our team members in all aspects. If we do our best, PM will be very tired. For something that is not very important, let others do it with confidence! I feel that programmers are still quite real. The team members generally estimate less time than me, and there is almost no time = I feel * 2.

Clear responsibilities
Write the tasks that each person has to do in each period of time as a document. This document should be written by the executor of the task, he seems to understand (he also thought he understood it at the time), but only in the middle of the process, he found that he was not knowledgeable, Mo lingyu, at this time, the estimated time is naturally unreliable, and the progress of the entire project is naturally slower than planned. After reading the document, PM can understand the team members' knowledge about the task and find out the problem. The following are some details that I think should be clearly stated in the task documentation:

(1) What is the function implemented by this task?
(2) When will it be completed?
(3) What quality should we achieve? (In order to prevent speed-only, regardless of quality, part of the test standard can be considered as the quality requirements to be met. For example, one type of error cannot exist. <some functions in the design are not implemented>, two types of errors <severe errors make the process unable to continue>)
(4) how to handle latency? (When latency occurs during development, it cannot be solved again. My practice: the task executor estimates the remaining time required, and agrees directly as long as the delay is reasonable)
(5) When will the task be terminated? (My practice: if the task fails to be completed after one delay, the task will be terminated, changed to another person or solution)

This is rarely seen in general company task documentation, but I think it is necessary. Its benefits are as follows: A prevents infinite latency (bottomless pit ), sometimes someone is not competent for this task (misassignment of tasks). When the time is reached, the task cannot be completed, the task cannot be completed, and the task can be delayed. If it is repeated, You do not agree that it is a bit unfriendly and you do not give face to face, if you agree, you cannot accept the time. With this description, it will be terminated in this case. If there is a document to prove it, act on the basis of = not to the person, then it is a relief to both parties.
B plays a supervisory role, because it will be stopped if it cannot be completed after the delay occurs. After the delay occurs, the team members will mention 12 points, because it is no longer possible.

This part is divided into three parts, one for the superior, one for the PM, and one for the executor of the task. If you have a project management system, you can directly enter it. In this case, it is recommended to generate a document for the superior, because the superior generally does not enter the Project Management System; then, it is easy to pay attention to the special documents.

Trust, but check

When a task lasts for more than six days, it should be refined to 3-6 days. (In the task, make it clear what results should be produced at this time point, how to check), mainly for the following considerations:
A's individual team members have almost the ability to manage themselves. When the task time is relatively long, it is easy to see the previous loose and then tight. At this time, the task is refined to a inspection, which can avoid this situation.
B's check time is exactly one week. At this point, the Group will hold a regular meeting. At the meeting, each member of the group will speak in sequence. The content is what I plan for this week, if the actual progress is better than the plan, let's talk about where you are doing well and let everyone learn. If the actual progress is worse than the plan, let's talk about where your problem is; finally, I made a concluding speech. This regular meeting may seem simple, but it actually plays a very important role. Imagine that you cannot complete the tasks you planned. In the face of so many people, let's say that the reason is that you are doing things slowly; or you can't finish the task every week. If you don't have a thick face, you will feel self-blame, embarrassed, or even blushing! This is an invisible kind of supervision and restraint. This team member will definitely fight for the task next week (once again, not for the second time, people are quite normal, this is much better than asking him to do it quickly or blame and criticize him)
C. This is like running a marathon. Because of the long distance, people may not be able to see the target for a long period of time. But after you artificially divide it into several targets (checkpoints, the goal is clearly visible and easy to reach, so people are motivated and cannot feel tired.

Each check should complete the corresponding record to form a document (updated to the system) and send it to the superior within a certain period of time as the report content, so that the superior can know what the group is doing and how it works.

The task documents are scheduled, the check records are compared with the actual ones, and the actual performance is compared with the plan..It is better than the plan, that is, it is better. Otherwise, it is worse, better, and worse. You can also find the corresponding basis (time, quality) in the document ). In addition, this avoids adding features in the middle and cannot be clearly stated in terms of latency (for documents, the newly added features, as a new task, naturally require time, the latency may be the same for the customer, but it is different for your superiors. At least he will not think that the Group does not work hard, and lazy will cause the delay ).

Remember that there is a project, because the customer added the function at the end of the project, so the time was extended, some problems have occurred when sales and marketing personnel demonstrated the system to the customer (Sales and Marketing personnel are puzzled by the system and are not skilled in operating the system, of course, there are also reasons for the lack of human nature of the system ), at the coordination meeting, the sales staff pushed their responsibilities to the development team, and they had to discuss the case. They even talked about other issues. They said that the development team was not busy enough and delayed for a long time. At that time, the superior said that they also felt the same way (in the Post-analysis, it was estimated that when the superior came to check, the team members completed the task of the time, a little relaxed, reading books and reporting ), in the past, I complained: "You don't want to see how many features are added in the middle? ", "The group has been working for several days," and other people will definitely not pay for it. In the end, it will become a quarrel! At this time, I took out the task and record-checking documents, and pointed out which functions are added and which are originally designed functions (These documents all have records), one-to-one ratio, what is the percentage of added functions, and what time period is added (mainly in the later stages, it is too late to work). This is why the delay is caused? The comparison between the schedule and the schedule during the inspection by the team members (the schedule is relatively good, and the actual schedule is basically the same). Is it because I intentionally delayed the schedule or did not neglect the schedule, there is also a lack of hard work for development, and the problem can be explained in the documentation. After the lecture, I handed the document to the sales and marketing personnel. Then they were dumpfounded, which is better than words! Afterwards, he apologized to me, saying that he had a straight temper and said that he had spoken.

Other related experiences:

1. PM should not allocate too many tasks to itself. The task type is X and Z-is better, because PM needs to spend more time than team management. Because development is based on technology, PM should be able to serve the hearts of the people. The key is that the technology should be better. Therefore, we recommend that you select the X-type task, so there will be no time for the management team because of the heavy workload.
2. Demand Analysis-estimation of time-assignment of tasks is not a straight-down operation. In demand analysis, you can find out some technical difficulties unrelated to the business, at this time, you can schedule team members to tackle the problem. Assign tasks, and each member calculates their own time, which can be used as a reference for estimating the time.
3,Do not treat overtime as normal working hoursBecause development often suffers from latencies, overtime is generally considered as a suitable time for filling in the gaps, and I find that overtime is less efficient, generally, two or three hours in the evening is not as good as one hour of normal working time (good team members are absent-minded, but you can understand that they have worked hard for a day and work overtime at night ), if you work overtime on Saturday or Sunday, it is easy to make the entire group tired next week and affect normal work efficiency. (Do you feel the same with what I have observed ?); However, I found that my superiors liked to hook up group overtime with hard work. I felt very hard when I saw the group working overtime (in fact, there were very few jobs, and I counted the number of completed tasks ), in this case, you can do it as a superior.