A 12-point prompt indicating the actual schedule in a software development project)

From rational edge: software development teams rely on rigorous schedules. However, in addition to using basic scheduling tools, how can a Project Manager balance conflicting requirements or have enough time to cope with unexpected threats to the best plan? This articleArticleIt provides some complex schedule techniques to differentiate priorities, clarify value objectives, and compare the relative values of different activities.

S do you have the ability to lead a software development project or adjust the time of your child's soccer and dance classes? A schedule is a useful tool for reasonably arranging a series of events. Many timelines include a start time and an end time, the time required by the task, and the dependency between the task and the task. However, no matter how well you arrange a series of things, unexpected events will always appear, occupying your time and failing to finish the project before the deadline. People you didn't expect will participate in your plan, have an impact, control things and usually make things complex. Our schedule began to be fragmented when we had no way to deal with unexpected things and relationships.

It is very difficult to develop a timetable. It is a combination of art and science. In this article, I will discuss how to make actual schedules to cover all the types of events mentioned above-planned, possible, and unimaginable. There are many tips that can help you maintain your wit. These skills are not found in your notes, lists, important events, and memos. My twelve tips differentiate priorities, clarify value objectives, and compare the relative values of different activities. They combine the traditional list with the improved relationship to get the expected results.

12 tips for the actual schedule

It is common to hear some team complaints that we don't have enough time. We often feel exhausted and helpless about an imminent schedule. When we compete with time or schedule, we always struggle hard, but the possibility of failure is very high. When we stop competing with time and start working based on our schedule and capabilities, we increase the possibility of success.

For example, a timetable may not represent itself: it only indicates how many tasks are completed in a limited time. It is wise to decide what to put into the schedule and how to work in these scopes under our control.

The following skills will help you reconstruct your control capabilities. They illustrate how to differentiate priorities and how to clarify facts by comparing the relative values of each event.

1. Don't shirk responsibility with me busy.

2. Create a detailed task list.

3. determine the key paths and bottlenecks as soon as possible.

4. Do what is valuable to the customer.

5. Execute the solutions supported by the customer.

6. Know how to make decisions efficiently and quickly

7. Strictly enforce reasonable forcible means.

8. perform efficient conference management.

9. Accept revolutionary good suggestions.

10. reduce inventory as long as possible.

11. Do not create chaos.

12. Be alert to the atmosphere of installation.

Note: I think some of my tips contain information that I call as an additional tip. This information includes some related skills you will use when making your own judgments. Depending on an organizational structure, you may not appreciate some suggestions.

Tips #1 don't shirk responsibility with me busy

Do you find that the busier you are, the more likely you are to have all kinds of interference and requirements? Many of us have spent a lot of time in one job after another, instead of making things happen. However, if we only want to do this without disturbing ourselves, we will lose patience and even teammates.

I call this a busy conflict because what you want to do is the opposite.

In fact, the more busy we are, the more patience we need, because all things require more time. 2. The more things that need to be done, the more important these things are for people. The heavier the burden, the more we need to work with others and with the team.

Remember that your teammates do not need to know your current task list; they only focus on what they need to do. If you are willing to spend time explaining your work and deadline to them in detail, they will have a framework of understanding about your situation. If you can allocate time on the schedule and tell them when you can properly meet their requirements, you will see that they are all very reasonable, and your time will work well with their time. All of these require patience and mutual understanding.

We often assume that a new request is urgent, important, and urgent. But this is not always the case. Discuss with them about your current situation and their special requirements. You will have a general idea of how to differentiate priorities. Another benefit of talking to your teammates about various tasks and timelines is that they may have done something similar, which can help you save time. You may find some surprising cooperation, collaboration, and network work opportunities.

It is helpful to evaluate events from different perspectives. Busy is not a synonym for chaos. It doesn't mean giving up everything, although some people think that as fast as possible means as fast as possible. Busy only means actively or fully engaged in work, and usually means as fast as possible. With patience and communication, it is possible to control and construct a tight and orderly schedule.

The more parallel work is required on the schedule, the longer the time from order to delivery and the longer the delay. The more work you perform, the more unexpected events you should realize for each job. Unexpected things are part of life, whether in the office or in the office, in an efficient and practical schedule, they are expected to occur and their impact on the order of completion of the desired job. Without a perfectly established security system, an unexpected (or additional work) will have a domino effect. Without a well-planned buffer, we will waste our time on one job after another, but will not do anything. If you strategically arrange some buffer time on your schedule, you are more likely to handle unexpected events so that they do not affect your entire schedule. Now you can confidently say that you can meet unexpected requirements in the next space that can be used.

Sprint and Buffer

A better way to ensure that you have a convenient pause in dealing with unexpected emergencies is to combine short sprints and buffering times.

Consider the following example: As shown in the upper part of 1, we have task a and Task B. It takes eight days to complete each of them, they took up a total of 16 days on our schedule. We started to work, but at the end of the third day we suddenly had an emergency. So in the next day, we spent all our time dealing with emergencies and liquidation, and then we started to deal with task. It takes some extra time to recall the stage at which the task is to be processed. It takes some extra time to start the job of task a again, therefore, we must re-estimate the total time required for this task. After re-estimation, we believe that it takes longer than seven days to complete the task because the task process is interrupted. Two days later, we had another emergency, and the same situation was repeated. Finally, we spent more than 12 days to complete the real task a (2 days for task a + 1 day for the emergency that interrupts the original work a + 2 days for the task a + 1 day re-evaluate and complete the task in B + 6 days for emergencies that interrupt the original work) this is shown in the lower half of the positive 1.

We not only delayed the delivery of tasks to those who needed them for four days, but also delayed those who waited for the tasks and tasks.

Figure 1: Emergency sample A includes the eighth day of evaluation task. Two days after task a was processed, an emergency occurred. After the emergency is handled, we will re-evaluate and expect that it will take seven days to complete task a (to continue the interrupted work ). After another emergency is handled, we will re-evaluate it and it will take six days to complete task.

2. A better way to deal with such a problem is to divide task a and Task B into smaller, independent activities, or sprint. We arranged some buffer time between each sprint. The overall schedule of task a is now increased from the original eight days to the eleven days. Let's take a look at what will happen in the same example.

Figure 2: combining sprint and buffer in our schedule, we can see the application sprint strategy (A1 A2 A3 A4) the real schedule meets both the Emergency and original schedule requirements. The original task a method took a longer time, but did not reach the expected goal.

We start with task A1. No emergency occurred two days later. We started task A2 without hesitation. At the end of the first day of Task 2 (the third day of the entire process), an emergency occurred, but for a good reason, tomorrow's end will be a good pause for the task to end, and the emergency handling will be arranged at that time. 3. When we finish A2, we start to take time to handle emergencies. Once again, we did not automatically stop what we were doing and shift our focus at this time. This example continues in this way until another emergency occurs at the beginning of task A3.

Although the original schedule based on the sprint-buffering method takes longer than the original task schedule, our predictions are more realistic and the results are more realistic. People who rely on the entire task (A1 A2 A3 A4) completed the task on time, sometimes even ahead of schedule, and part B does not need to compress the time.

If a request appears, and it is more urgent and important than the ongoing work (for example, the requester cannot wait until the next available period of time on your schedule ), you should go to the manager and make sure that everyone is aware of the priority, impact, and results of the incident after the schedule changes. People usually understand and accept this scheme, because it is based on the priority order that affects the entire work, it also compares the relative value and mutual dependency of each job. By discussing and comparing priorities with your managers, you will have a clearer understanding of each activity on the project schedule.

Time Limit

Another possible event that makes schedules messy is compliment. Since you know your expertise in a certain field, you are the target of others' help in another similar but not identical field. It is not very difficult to say to a companion or another manager, especially when they make a request with such a statement, it will only take you five minutes. A small voice in our mind said: Well, you only need to spend five minutes for your friends and other managers. But five minutes are usually half a day, and your manager is still waiting for your daily progress report, which should have been completed last night.

A good trick is to set a time limit for these extra requirements. 4. Schedule a convenient five-minute meeting with your friends, during the meeting, he or she will do his or her best to explain the situation. Estimate how long the job will take you with the obtained information. Check your calendar or schedule to see if you have the appropriate time and explain it. I can spend XXX time on it at AM on xxx day. If we haven't found or solved the problem by that time, we will need to reevaluate the energy, priority, and ask the manager. After the appropriate time limit is reached, stop 5 and re-evaluate. The time limit is not confusing and the answer is a good method.

With all the strategies mentioned above, you are still a team member. This does not make your other tasks impossible. However, these policies depend on a detailed list of tasks, including what you are doing, when and for who and why (priority ).

Additional tips
 
Many books on time management recommend that you just say "no. But sometimes, when something meets your priorities and values, it is smarter to use the correct method. Of course, it depends on yourself.
 

Tip #2: Create a detailed task list

Again, if there is no detailed task list containing the deadline, the previous prompt will not work. If you don't know yourself, you won't be able to explain everything you need to do to your partners effectively and reliably. A detailed task list can also help you focus on the importance of each activity.

Effective Time managers actually have a list (on their whiteboards or bulletin boards ). When someone comes with a new task, they have a visible template that knows where to start their negotiations.

A detailed task list is equally important to recognize how much effort a job can put. When your manager asks you how long it takes to complete the task, make sure that you understand what the completion he or she defines means. If your manager thinks that completion means the following situations, what will you do? Feature design, review the design with all participants of the project, and compare the designCodeStandard and System Enterprise Standard Check codes. Before submitting codes, use the encoding overview and status analysis tools to collect and report the main features of Code states, unit tests, embed and automate these unit tests in an automatically Established Authentication Test, and complete the function authentication test to ensure a pass rate of more than 95%. Okay, but if you think that completion simply means encoding components and submitting, the problem arises. It is also very likely that such conceptual differences will not be discovered long after.

Use a detailed task list template to estimate how much effort you have made. The list template should include every major 6 activities that need to be completed in this entire project. Some action projects may not be needed. It depends on our specific goals, but at least you have considered each of them (relative to a forgotten task that has not been assigned any time ). When we don't take the time to write down tasks, but simply review them in our minds, instead of taking the time to write down all the work steps, our expected returns will be relatively small and inaccurate. My organization found that after doubling the expected results by carrying out purely mental predictions, we still need to add 30% more time to complete these tasks. In other words, even if we double our mental expectation at will, we still underestimate the actual time as we used. However, when we write down all the steps prompted in the template, we increase our estimation accuracy. We are not so surprised when we encounter a hidden or unknown task; in addition, we have evidentiary documents in all areas that require unanticipated time.

When you may fail to complete the task before the deadline, the detailed task list helps you and your manager efficiently review the project. That is to say, if there is a risk, we still have many options including solutions to the problem: 1) change the schedule, 2) intelligently add some resources, 3) reduce quality, 4) reduce the scope (remove some of the tasks we are about to do from the task list ). If you do not have a detailed list of what you plan to do, it is very difficult to Intelligently reduce some activities to complete tasks by the deadline. Intelligently reduce tasks. What I want to say is that the tasks that are reduced do not affect the coding quality or their independence throughout the project process.

Explicit activities also enable you to know whether you can complete tasks on time. For example, consider the very vague timetable shown in figure 3.

Figure 3: Timetable

In the schedule, the exact estimated time for completing Component Task 1 is ten days. When we started working, the developer said on the ninth day that he wanted us to submit the code. The team thinks that we are executing according to the original plan.

Figure 4: Timetable

In the schedule, we can see that only five days are actually used for coding. The remaining time is allocated for inspection, testing, and error fixing. Therefore, when the developer says that the code writing will end immediately on the ninth day, we have four days to check the schedule. Although these tasks are not clearly visible on the schedule, those activities that are not specifically marked on the schedule still need to be completed to meet our repeated test criteria.

Therefore, agreeing to complete the task ahead of schedule means to facilitate communication and make us better understand our status.

Tip #3 determine the critical path and bottleneck as soon as possible

Risk management has been widely publicized in important project management tools. However, we didn't actually spend time modeling or researching our workflows to define risks, key paths, or bottlenecks as early as possible. Just like defining how much effort we should make, we often rely on a fast and temporary approach, depending on our review of past experiences. Unlike all other tasks and workflows in the project, risk management is rarely considered. If we cannot fully understand all tasks and time consumption, we cannot recognize the vast majority of risks. If you do not realize the risks, you cannot overcome them.

A very effective and convenient way to quickly and clearly define risks is to outline the progressive workflow in a visual flowchart in the project. Workflow methods can be used to analyze everything: workflow analysis is effective in terms of component independence, progress step independence, and even resource conflicts. Consider the chart in figure 5, which outlines different components in development. A specific color indicates the different human resources required to complete the activity. The estimated duration is in.

Figure 5: Progress workflow: The workflow is drawn by the graphic method, so that we can clearly see that step 3 and the resource "orange" are bottlenecks.

The chart shows some important meanings of the proposed resource allocation. Note that if resources are not taken into account, the time needed to pass through the Key Path is nine days (the maximum time required for steps arranged in various order ). However, because we use the same resources for steps 2a, 2b, and 3, we need to add two additional days. Why? Because even if these steps do not depend on any other step, they are still subject to resource restrictions. We need more than 11 days now.

Continue our analysis. If there are several input lines for a step or resource, you clearly define the bottleneck mentioned in an architecture or structure. In this simple example, multiple small projects depend on Step 3. Therefore, we not only have a bottleneck on resources, but also a bottleneck on the project structure. No other steps can be performed unless steps 2a, 2b, 2c, and 2D are all completed at the specified time. If the resources in step 3 consume too much during step 2B, the entire process cannot continue. There are no other steps to start. This places an orange resource on the Key Path. If we are waiting until the team starts writing code, we are actually in a bottleneck, and we can't do anything about it, because the "orange" resource has been generated. If someone is the only person who knows how to write code in Step 2a and step 2B, because he is the only person with the encoding, he may have added some additional assumptions in all three steps. It makes the independence of each other complex, but makes the task faster (again, because it is the only owner of the encoding ). He makes the relationship complex, and we cannot effectively help him by adding resources.

The graphic method provides a workflow to make the problem clear and visible, and provides us with a way to avoid the problem even before the project starts. Consider the improvements shown in figure 6.

Figure 6: workflow: Once you use a chart to show your initial process, you have done your best to correct risks and bottlenecks near independent components and resources.

Once you use charts to express your initial process, you have done your best to correct risks and bottlenecks near independent components and resources. In this example, although I divide my tasks into many small steps, my Key Path is only seven days (shorter than I originally expected ). I still can feel that the "orange" resource-Step 3-is a potential bottleneck, so I arranged two days of buffering before the potential bottleneck. This allows subsequent steps (Steps 2, 2, 2, and 2) to accumulate in a mild stop mode. Stable time is a good way to merge intermediate links, fix errors, and review quality. 7. Although I have reduced the risk of bottle diameter and provided some additional time on key paths, I did not add time throughout the project plan.

I also know that the technical level of resources is not 100% that can be exchanged. But the fact is that if we do not analyze such workflows, we don't know where we can't reallocate, subscribe, or change the structure to make better use of our resources and technology. In this example, the "orange" resource in the workflow needs to be used in step 3, only because part of step 3 requires a high level of Multiline design. After we spend some time stripping that part from the rest of the step, we can find that many other resources can complete the rest of step 3. If we define in another way that nobody can replace the crucial "orange" resource, we can place the "orange" resource elsewhere in design and construction, so that others can get the code specification that has been designed and simply program these original templates.

Another advantage of this project management technique is that it avoids excessive concentration of resources (or resource shortage) when individuals are solely responsible for their own projects ). We allow a Key Path to add additional time for caching, but not for a task. Other tasks in non-critical paths have an internal buffer time.

If you haven't shown an alternative workflow at the beginning of your work, you may be in trouble easily. When you are in the middle of the projectProgramMost of these options are no longer needed. The key to this tip is to give an illustration or build your workflow as soon as possible to provide you with a variety of options and options.

Additional tips
 
Do not use your favorite calendar tools (such as Microsoft Project, modeling tool, or Gantt charts) to draw the original workflow. These tools will virtually bring you into the same mode. Use instant stickers? Paster and a large whiteboard, which makes it easier to discuss the teams and groups involved in the project, and facilitates re-modeling. The eyes of multiple people can see what one person's eyes cannot see. This also helps you establish interactive interpersonal relationships and team responsibility at the same time.

Only when your team is happy with the optimization of decision making can you use your favorite schedule or modeling tool to create paths for periodic and repetitive checks and updates.
 

Tips #4 do valuable things for customers

A large study by James qiongsen from the standiz Team (2002) noted that 45% of features embedded into various application devices have never been used (see figure 7 ). It seems ridiculous to spend time on things that nobody uses, so where are all these features?

Figure 7: Use of embedded features: standiz team from 2002 meeting (2002)

The feature list comes from many places. Some documents from business analysis that can be viewed to ensure that the company is still competitive. This seems reasonable and important. We need to be competitive and distinctive. However, the way we achieve this may not produce value to our customers. For example, consider that all customer report analysis and even your own analysis are based on comparison from technical resources. Generally, these charts list more than 100 features and compare each other using specific tools of different schemes, each feature has a score in the column corresponding to its solution. It seems that the solution with the most scores is the best one.

What we don't know is that 100 of the 64% features are rarely or never used. However, in order to make our brand more competitive than other brands, we will merge the 64 features we don't need into our solutions, this allows us to mark scores for those columns (making our products more complex and harder to use ).

Dependent on customer feedback

It should be acknowledged that it may be impossible for many project managers to exclude 64% of the features listed by a customer at the beginning of the project. However, we can specify a customer who repeatedly checks the availability of these features (requirements, prototypes, samples) throughout the product development cycle ). By doing so, your final product will have more features that will actually be used. You can also know what features you need to spend time developing. Even if your product has 100 features, through continuous communication and cooperation with your customers, you will know which 36 features should be concentrated, which 64 features should have a lower priority. Therefore, even if you may not be able to influence business organizations to list the Feature lists required by customers, at least you know what will make your customers most satisfied after the project ends.

This feature review that includes customer value is also the removal of Customer Value features (more often, this is called a careful study to ensure that it is consistent with the schedule ). In many cases, features (such as ease of use or user files) that are most valued by customers are given a lower priority. Applicability (which helps customers determine what is wrong and what should be done and the useful features that can be done immediately) and troubleshooting database classification are usually not taken seriously. These are not necessary for the pure technologies we are keen on, but they are valued by our customers. By recognizing that some of the features that we think are less valuable may be the features that our customers are highly evaluating, we can discuss these aspects with our customers to improve overall satisfaction.

Ask your team

If you do not have a customer sponsor, when you re-evaluate a scheme (whether adding or removing features) as required ), let your team clearly know the answer and carefully consider the following questions:

Does this feature really help customers?
Do you realize value-added energy?
What is our goal?
Is this goal realistic?
How do you perform the test?
If you have a valid answer and quantify the above questions, you can accurately present the energy we need, the practical time frame, and the value to the customer.

Be aware of other causes that lead to a long feature list

Another common cause of software feature expansion is our common system requirements and security features. Many of our company systems require a very general template that contains a large number of application scenarios and products. For example, some network and security system considerations do not exist in an isolated, isolated, and single-user model, nor do they exist for users. However, in order to sell it together with other products of the company, this special application needs to be done according to specific company regulations (especially when it is ready to be pushed to the international market ). 9

Another common contributor is the concept of "We, development team. We love our work. We love simple and technical advanced tricks. Sometimes we design something just because it has a lot of fun. Or we can pick a feature and design it perfectly so that it contains everything we (but not our customers) might think. This is interesting, and we have not actually occupied the project's schedule process because of these creative additional work.

Tip #5. Execute the solutions supported by the customer

Another way to add customer value to your feature list is to make every solution supported by the customer. Compared with the customer review method recommended in Tip #4, this is a more formal approach for customer participation.

In the past, our product manager collected various requirements from various channels, then they will sort these requirements by priority based on whether they are competitive, how much effort they need, and the product R & D cycle. Now, the product manager needs to select a customer spokesman who plays a core team's Role in the work we are trying to accomplish and use it to make these requirements more widely used. The customer spokesperson needs to participate in the requirement collection activities and review and design a specific solution. They must carry out repeated evaluations on the delivery of each solution. Their test results and use procedures indicate that their goal is to become our No. 1 mandatory test solution. The obstacles and defects they encounter have become our highest priority. Their final comments will become part of our decision to do/not do this.

With the customer support solution, we have a team goal that everyone can understand (for the customer, this goal is successful ). Priorities and priorities also follow. Finally, we are not looking for success, but creating success.

Tip #6 know how to make decisions efficiently and quickly

One of the most difficult aspects of creating a realistic calendar is making decisions.

Generally, one reason for delay is that you are afraid of making wrong decisions. The irony is that if you choose not to make a decision, it will delay the operation time, which will not help you make the right decision. Even wrong decisions allow you to quickly get into a workable solution, because you can immediately handle the results of a decision you have made. The sooner you make a decision, the sooner you start to move forward and take action in both positive and negative aspects.

I did not suggest making decisions without consequence or rashly. I recommend that you act in reversible directions as soon as possible, and postpone actions in irreversible and High-Risk Directions. If the negative consequences of wrong choices are small, you should make the best decisions and take further actions based on what you know. In the technological environment that we have repeatedly and continuously changed, we cannot 100% know whether our decisions are correct, because they will play a role in the future. So don't worry about it as long as you make a decision. Once a decision is made, do not discuss it again. Execute, learn from any subsequent errors, and continue.

For some things that you cannot decide now, define specific action items that can make up for the conflict between where you are and where you need them, which can help you make decisions. Make sure that each of your actions has a clear customer and deadline (see note #7: strictly enforce reasonable force measures ). In my product team, we often attend meetings and use every means to discuss a problem. After much debate, we disband (usually because we need to attend another meeting on another project ). Therefore, we not only delay making decisions, but also fail to bring anything in a series of things closer to our goal. 10

Note:
 
This is not a real problem if no one assumes responsibility or obligation for the deadline of a project that has a crucial impact. Remove it from the schedule and clearly understand that without that decision, it will not happen at any time, and your project will not change.
 

Tips #7 strictly enforce reasonable forcible means

As you can see in previous prompts, I have mentioned clearly defined action projects, tasks, owners, and deadlines. This is essentially the true meaning of reasonable forcible means. To ensure success, you not only need a successful plan, but also a clear list of tasks with time constraints. The list should be clear to the owner and predict the results.

You also need to define success criteria for various actions or projects. Stephen Cavi described this as the beginning of the task, and you already know what the results will be. To make an activity successful, we need to understand what the definition of success is. 11

An early example is used to explain whether a successful completion means that a) the developer submits the program code to the superior, or B) your colleague re-checked and agreed with the design and re-checked the Code to ensure that more than one developer understands the mechanism. This part of the design has a 100% pass rate, I passed the unit test of 100%, and there is no major error in this part of encoding?

Whether the success criterion works depends on whether everyone agrees that the criterion is successful.

Additional tips
 
In each meeting you attended, use a reasonable forcible means. Don't just use it to remind your team to use reasonable coercive means, and make them realize when to use them. Repetition is the key to making the use of reasonable coercive means a habit.
 

Tip #8. perform efficient meeting management

As described in Tip #1, the more busy we are, the more we need to communicate and work in the team. This often leads to more meetings. Since we spend most of our communication time in meetings, meetings should be more purposeful and meaningful. I have talked enough about this in efficient conference management, so I don't want to talk about it any more. We all understand that it is best:

1. There is a goal and success criterion for this meeting.

2. There is a schedule on the schedule.

3. strictly abide by your time and basic meeting rules.

4. Do not stop the meeting before you confirm that you have followed your guidelines on the success of the project, owner, and deadline (Review Tips #7 ).

We all know the attributes of a successful meeting, but for most of us, ensuring that the meeting we attended has these attributes remains our goal.

Additional tips:
 
If you think you have just been freed from an inefficient meeting, this is your fault. Whether you are promoting the meeting or participating in the meeting, this is not important. You should assume ultimate responsibility for the way you spend time. If you do not know the purpose, agenda, or reasonable mandatory success criteria of a meeting, then the meeting will become the last meeting you attended without such important answers.
 

Tip #9: accept revolutionary suggestions

We have all heard of this sigh: our schedule is too tight. The fact is that the schedule is not too tight, but how we can adjust ourselves to adapt to it. 12 As I mentioned earlier, we cannot be 100% sure whether a decision is correct because it will only have an impact in the future. After accepting the fact that time changes our environment and sometimes changes our purpose, we also need to accept revolutionary good suggestions. That is to say, a very conservative attitude should be made at the initial stage of the project. Only a very small number of (3-5) features are accepted, and the remaining features are given a certain room for improvement. After the project is implemented, as we get to know more deeply, we will re-adjust our expectations and schedules accordingly. This allows us to shift our focus from the pressing schedule of complaints to a realistic but more challenging list of optimal features.

Revolutionary good suggestions do not need to be delayed on the schedule. In fact, we have made a series of decisions and made constant review and minor adjustments throughout the project.

I do not agree with too many preventive actions. However, you should set a reasonable and stable easing time in the key paths and bottlenecks of each project (see Tips #3: define the key paths and bottlenecks as soon as possible ), and a more confident percentage (for example, we have already been 70% sure ......) As part of your timeline estimation and review of the guidelines.

Usually in the development phase, we feel pressure to sign a schedule and take responsibility early. 13 as far as you know, the timetable may be perfect, so you cannot deny it. The problem is that you don't know what to do. Adding a more confident percentage policy to your consideration allows you to readily agree and give an example of your considerations for your field.

For example, when the next-generation version 1 product starts development, you may only have 40% confidence in your original schedule and estimated level. This means that you only have 40% confidence in your estimation, and you may only have 60% confidence at most. Discuss with your teammates about your level of confidence, including what you don't know-for example, activities, owners and deadlines-on your timetable estimation.

Additional tips:
 
Do not give confidence percentage when there is no action plan that can make up for the conflict between where you are and where you need it.
 

Tip #10: reduce inventory as long as possible

Retail stores, such as clothing malls, grocery stores, and five-gold stores, can understand the costs of maintaining a large inventory. Their goal is to place only enough goods on the shelf for circulation. Large Inventory means uncertain expenses, because skirts may be outdated, food may expire, and machines may not be sold, but you will not be able to get out of it because you are stuck with all these things.

There are similar concepts in the software industry, unless our inventory has many defects, the features of a whole list have not been developed yet, and a series of decisions have not yet been made. The waiting periods of these projects are also costly because technologies and customers are constantly changing. The following methods can be used to reduce the wait time:

Distribute periodic and frequent stable time to fix and reduce product defects.
Develop plans and timelines so that current standards for each of your stable times can be communicated to a specific customer (to some extent, like Alpha, beta, customer travel, internship programs, etc. ).
Make a timetable and make a decision as soon as possible. For example, you can sort out and execute your final deployment based on the current rules frequently used during each stable time, and concentrate your decisions instead of waiting until the final release of your software application.
Modify your design documents and test plans during work. Instead of making changes, the backlog will change until you have time to update your design, which will lead to confusion and time delay. Remember that these documents need to be handed over to other relevant parties, rather than you. If they need these documents, they will evaluate them. So you can't do anything until you have time to do these things. If these files are outdated, your readers may make inaccurate decisions. Continuously update and re-check required documents on an orderly basis. Make your routine document check a decision-making schedule shown in Figure 4 necessary for timing.
Additional tips:
 
If no one is responsible for maintaining the accuracy of the design document and constantly re-checking it, do not write it down at the beginning. If it has been written down, but no one claims to be responsible for it, delete it.
 

Another way to reduce inventory is to include unimportant items in your email, your calendar, machine maintenance, and the list of things you are going to do to you and your customers. delete things that have no value.

Stephen Cavi is the author of seven habits of high-performance people. He divided four common activities into four types: Important and Urgent (quadrant I), important but not urgent (Quadrant II), urgent but not important (quadrant III ), it is neither urgent nor important (quadrant IV ). The danger of always working in seemingly urgent quadrants (I and III) is that you didn't spend your time on non-urgent matters, and those things may help you get rid of some urgent tasks later. Projects in Quadrant II are important but not urgent. Therefore, we often postpone, extend, or delay these projects, but they may help us get rid of urgent matters.

Figure 8: cavo's emergency transaction quadrant figure 8

When you begin to sort out and reduce inventory, the only way to assign the project time to Quadrant II is not to do things in quadrant III and IV. But before we start to do something in quadrant III and IV, we need to know them first. Let's consider some of the audiovisual characteristics of seemingly urgent things that often make software development organizations difficult.

Defect Control

I suggest you do not show your mercy when eliminating the backlog of defects and constantly expanding features. Check your defect list continuously. If defects or constantly expanding requests are not expected in the next two release products developed by your production line, ignore them. This is because our industry and technology are constantly changing. If these problems have already occurred in the next two release products developed by your production line, many other things will come one after another:

1. New technologies and methods have been introduced to solve the original problems.

2. The current customer either finds a work zone or turns to a completely different product.

3. If you fail to solve the problem in the next two release products, it is no longer important to solve the problem.

Additional tips:
 
If your technical support staff or product manager does not agree to repair or ignore a special defect, you can challenge them in this way: put urgent and important things on the plate that must be repaired for the product. The product R & D will be postponed unless the repair is completed.
 

Machine maintenance and security activities

Many companies have various fire drill-based trainings on Machine security and maintenance issues. If a fire drill has been planned, it should be kept confidential to some extent for participants and those who need to do the work. Generally, this is the dilemma of "dropping everything. And because these projects that require significant effort are not obviously closely related to any other project, program, or product, we usually do not schedule and provide resources for these projects. Everyone recognizes that security is a problem that needs to be taken seriously. A virus can stop production, which is costly for everyone. Therefore, I do not suggest skipping any of these important steps; I just think that they should be more effective during good R & D. Try the following suggestions:

1. Automatic Process update

2. familiarize everyone with the timetable in advance (see Tips #1)

3. repair the machine and discard the useless ones. If no one is willing to take care of the machine's repair, discard the machine.

4. Find sister teams in your company that are doing similar things and share machines and interact with them to use resources.

Don't waste your time on making unnecessary decisions.

About 80% of your decisions are unreasonable. Many of them should be decided by others. Many of them are irrelevant in the long term. Before taking the time to make a decision, make sure that this decision is important enough. If not, ignore it or let others make the decision. In some cases, you can ask yourself: Should I be the one who makes the decision on behalf of the entire team?

For example, if the team spent an hour discussing how to handle a temporary Installer (but the program we want will be delivered next week), this team is wasting time. This decision is of no importance. You should let a developer decide how to fix it temporarily and make sure that he does not spend too much time making decisions. It is sometimes appropriate not to make a decision, especially when this decision is not helpful for solving the problem. If a decision is unimportant to anyone (for example, no one is willing to sign and take responsibility for it without deadline or action), there is no need to consider it at all. Here is a simple example: if no one feels hungry, it is totally irrelevant to what to eat for lunch. Simply not talking about lunch, there is no need to make a decision.

Other credit points: reconsider your automatic email list

The automatic email list can be very helpful or an obstacle for your personal time. If you are listening to daily routine reports about structures or detailed designs, but you don't care about them yourself, it will take you time to filter and review these projects. Get rid of these lists, place notifications online or in the central area (so you can review them whenever you need them), or put them in a separate folder and clear them from your inbox. So remove an email that has been in your inbox but has not been read for more than a week.

Tips #11: do not create confusion

A busy second-line manager I know emailed many teams at a.m. and announced that a team meeting would be held at a.m. Since he has done the same thing many times in the past, I think it is time to talk to him about the messages he sent and his expectations.

I pointed out that not many people actually arrive at the office before am. Therefore, it is unlikely that they will see this emergency email notification before AM. Because they have no time to prepare for the meeting, they cannot provide him with any valuable comments or feedback he is looking. The second-line manager replied: But my schedule was so messy that it was the first time I had notified the Meeting. I will be very busy for the next few days, so is the only time on my calendar that I have no time to do this.

His goal is to let everyone be notified and sincerely hope to hear suggestions from others, but he does not realize that even if people receive this letter, it does not mean anything. The team and front-line managers have worked overtime to complete the pressing schedule. They are trying to construct, filter, and control their own work schedules. They are trying to finish their work on time in a scheduled meeting. They are notified at a.m. that there will be a meeting at a.m., which will lead to an emergency and important error. They did not receive the agenda, so the team assumed they could not bring anything, and rescheduled their work schedules to meet the requirements for this notification meeting. This requires an unscheduled series of task conversions. Since there is no meeting details or agenda, they will question how important their attendance is to the meeting, if they do not have time to prepare for the meeting, they will also question how important their opinions are. At the same time, they want to know whether there is an unwritten expectation. Everyone must work till a.m. or arrive at the office before a.m.. Only in this way can they receive these Urgent notifications. Unplanned meeting notifications have resulted in unconscious changes in the atmosphere and morale.

This is not the information that the second-line manager wants to transmit. After rethinking the true purpose of the meeting, the second-line manager can define an agenda and members who need to attend the meeting to reduce the list of attendees. Once the goal and agenda are outlined, he realizes that it is not necessarily his demonstration; therefore, this special meeting does not depend on his pressing calendar now. Others can host the meeting at a more appropriate time. Once the goals, agenda, and new attendee lists are released, the team will be able to determine the priority and importance of this special meeting based on what they are currently responsible.

There will always be a lot of urgent and important things happening, making our schedules messy in a short time. Even so, do not bring chaos into your schedule or your team to make the situation more complex.

Tip #12: Be alert to the culture of the costumes

Another form of Chaos breaks out when the rhetoric becomes standard, rather than chaos. Companies often predict that additional time and rhetoric will lead to product R & D failures. It is very common that this will not make things better. Putting your product out of the box is the worst project management. If you first set up a realistic timetable, you do not need to pretend. Failure to correctly define tasks and latencies is also a poor project management. Allocating a single resource to projects in parallel is not suitable for buffering and execution, which is also a poor project management. The Capability Maturity Model simply calls this status level 1.

In addition to routine needs, unexpected tasks attached to product development or customer satisfaction are put away. Some examples are white papers on successful product deployment, tips, and tips for customers. They have been demonstrated in some meetings.

Summary

Although this is not a list of all the ways to improve the timetable, I can confidently say that they provide good suggestions for companies that are growing and whose workload is slowly increasing. I am very happy to hear your suggestions on any small tip, especially when any of them helps you and your team.

Note

1. Since we can neither create nor destroy time, it is meaningless to fight against it.

2. You can easily lose everything you have. So we don't need to be idle. We are more inclined to find ways to create great value with a few things. Therefore, we need to create a method that can be transferred and supported to change our busy life.

3. Although an emergency may not start after the task is completed (it may take 8 days at first), it may take one day, this allows you to continue the sprint of Task 2.

4. For additional requests, I mean those requests that are not listed in your detailed task list today. An extra request is something your manager or test lead has not asked you to do. Even if these additional tasks are not explicitly proposed, they can also weaken the independence of teams and organizational functions. The key lies in the need for an efficient network and a harmonious environment. We all know that it is not very difficult.

5. It is important to re-evaluate at the work breakpoint and make the work continue. We usually only think about it for 30 minutes, and then start to work, but we didn't really stop after the time limit. The concept of execution stop is the key to this technique.

6. It is very difficult to decide what is the main activity. We don't want to be overwhelmed by trivial matters; but to some extent, we should be good at dividing time and resources into small pieces.

7. Strategically inserting some stable time on the schedule helps reduce errors, document reviews, and clean up the entire project (see Tips #10: if possible, reduce inventory)

8. What are your requirements for standiz team papers? Standish Group International, inc., 2003, Standish Group (based on 2002 chaos Report ).

9. One of the key reasons that system requirements usually cause a pause in the schedule is that they are not integrated into the entire project and have not been computed at the beginning of the project schedule. When we describe in detail and integrate our project processes, we only focus on customer characteristics, but do not care about all the tasks that need to be supported (see Tips #2: create a detailed task list)

10 to find more tips to make quick decisions, see: http://www.liraz.com/tdecision.htm

11 seven habits of Stephen cavy's high-performance people Simon and Schuster, New York: 1989

12 For example, if we try to put 10 lbs in a bag that can only hold 5 lbs, is that the bag's fault?

13 many high-level project managers like to walk in the room and verbally delegate the early schedule framework. He serves to delegate oral matters to individual project participants and maintain a certain degree of responsibility for his work. Even if his purpose is good, time may not be appropriate. We may not know or understand whether the project is consistent with our schedule at this time point.