2016 Project Reflection

Graduation so far, large and small projects have experienced more than 10, there are many successes of joy, there are many lessons of failure. In the recent time, carefully aftertaste, the end of 2016, a little feeling.

Count, 7 years of project experience, from the very beginning to write in C language compiler, to the nearest. NET's organization edition. One of the most successful of all is the udn of health care and the TTS of the training platform, and the most unsuccessful lessons are the institutional version. The Health Care Project group was the first formal large-scale project that I followed Zhong Li, the first full-time contact with formal software process management. Thousands of people around the world at the same time for a project service , which is the process of control I have so far affected me the deepest. Cross-regional, cross-platform, cross-language culture, cross-technical category, cross-work cooperation, collaborative development. Finally completed the Microsoft into the Chinese market, the first medical products, including the director, so far the profit is shallow. Unfortunately, thanks to Microsoft's strategic realignment, health care was abolished worldwide. This project is also dullard.

TTS is the first project in which I host a constituent block independently, and most of the experience of hosting the project in the future is mostly sourced from this. Although only a less than 20 people to develop small teams, but also involved in all aspects of software development, fortunately there are strict head, Mengo support, the first project, bumps have also been successful, our project team developed the first medical training platform in China, so far, the national dozens of medical colleges and large hospitals of the training system all year round operation, Every year tens of thousands of students use, Changsha, Hunan, when I left the weir is business negotiations, I do not know the final result, if used, but also I made a contribution to the hometown. This should be my most proud, but also the most tired of a software process, all night, all over the country "outing", was pointed to the nose scold this has become a normal, but also this process, let me really understand how to control the project in the global, will be a few years of learning to verify and correction, can say, after the completion of this project I really have the power of a software manager. After the intelligent City monitoring system, SBS, TCM syndrome and so on the project is logical, but is to increase experience only. Of course, there are also abortion projects, but the management of the project resulted in a few failures.

However, this year, in 2016, I met the biggest failure in software career-the institutional version of the project. For this project, give me only a lesson, the blood of the lesson! Delay, quality is not standard, software members heart scattered, management is missing, eventually completely out of control, almost project abortion. The lesson of this project, I need to remember, for the future only.

One, simple rough project start-up

So far, I can not recall the start of this project, no need to verify, no analysis, I now can not find a piece of the project I started the drawing, is to do a preliminary function to understand, and then, said the good point is not hesitate, said the bad listen to the point is "unthinking" open the small broken boat sailing to the unknown sea. I have the deepest impact is 4.30, all for this date service. Then a high-risk plan, such as a tightrope-walking process, was created. Thanks to the company's kindness, not the specific responsibility of the person responsible, but I should have an inescapable "history" responsibility, as a project host, not timely according to professional knowledge to organize decision-making mistakes, but blindly open the project, which is the biggest failure as a project host.

Based on this, we have the following reflections

1, the company's top manager or management should develop a correct and manageable stage target, rather than specifying a time. Specific dates, the specific plan should be determined by the professional team of their own, the top managers or management according to this decision to decide whether to implement the plan. This should not be a nonsense, it should be to start a software process of the first layer of constraints, through this layer of constraints, the company all the relevant team of the idea of unity, the goal of unity. If at first the relevant teams were unable to articulate what the goal of a project would be, it was estimated that 50% of the probability of the project had failed.

2, the specific estimate team (here refers to all the relevant teams involved in this project), should be estimated including cost, development cycle, can invest resources, can withstand the adjustment, core value, core users, promotion degree and so on details, has been provided to the top management or the administration team effective information to make decisions. At the same time, the team should be expected to ensure that the scientific and reasonable estimates, which requires the upper level to give specific team analysis time and the correct information, should not say this: This is the transition version, give me a little time, I want this product XX on-line. These will have a substantial impact on the specific team assessment, and require the specific assessment department to have the strength and correct attitude to assess.

3, do not rush to hands, even take a few days out, clear the context, unity. The specific person responsible for each project execution should have time to think about how far away from the target, what deviation, and what the risks are at the moment in the process.

Second, over-weak project management and too strong administrative intervention

For a project team, the control is the core, the product team is the supreme god. But in the institutional version of the process, this rule is completely broken, as the project leader, LAX control, the time is basically used for the maintenance of old products, code development and administration, really devote to this project management of the project less energy and less. There are even periods of time in an unmanned state of control. Too many people have the right to make decisions about the product. for a project process, product personnel should have absolute decision-making power over the product. If a project top manager or management is passed, then the product personnel on the project by absolute right , the optimal decision-making power of the product is only the product personnel in the decision. Of course, this is an ideal process, and I have only experienced it in health care. To say the words, in the industry think: the most should not talk about the product has the most say the boss. The boss is generally in the buckle details and comparative competition, however, if this is not considered, then do what product Manager, go home to grow sweet potatoes! Of course, absolute rights must have an absolute responsibility for the project, that is, the product manager should be responsible for the whole process of the project, including profit and loss.

Third, the members of the project to survive

Undoubtedly, the project process, the project members are the main body, the project members of the work enthusiasm, work attitude will directly affect the quality and process of the project. Then the daily management of project members is extended. I admit that I am deeply influenced by the way of working in European and American enterprises and mature team, I only pay attention to the quality of the project, and other aspects, even if you are a murderer I do not care. But I ignored the differences between European and American cultures, our culture, mature teams and immature small teams, which also led to a complete failure of member management. In the second half of this year I have been thinking that I am not suitable for Chinese-style enterprise project management, the concept of incompatibility will only make the project suffer losses. I hope that this company can be a great leap forward to complete the transformation of software process management, but I also ignore the company members have the basic qualities, I saw the company "capitalism" sprout, but soon back to the workshop of Chinese-style enterprise management mode. I am not sure how to choose the future project management path. The company may also see this situation, the adjustment to me, the new technology manager to take control of all, take back my management positions, at present I as an ordinary developer, accept the administrative management of the project members, is to set the box for the project members, to join the restrictions, indeed achieved some results, but at the same time, The observation of these months has also caused a drop in responsibility, a big problem of throwing a pot at each other and unwilling to take responsibility. I really do not have a good plan at the moment ~ ~

IV, missing quality control and defect controls

For example, the agency version has a bug in the main process, on-line, after the customer feedback, said unable to use. This should be regarded as a serious quality accident. Why there is such a problem, the day I looked for testers, testers told me, said the bug has been detected, the development also submitted a repair version, and also passed the acceptance, but do not know why on-line after the emergence of. Then I asked the specific developer of the bug, and he showed me the specific description and resolution of the Bug on Zen Road. Obviously, the bug has actually been fixed and the tester has been shut down. So, what's the problem? Where's the root? Later, chat with the test manager, he complained to me, they are always in the project to transfer the test, often a project in one of the submitted version came, but suddenly transferred to another project, the original problem was put down, after a few days or a two weeks, forget. Then I asked him about the bug, and he told me that the members who had executed this version of the test were suddenly taken away, and the problem was common practice. Then ~~~~~ out of this problem, the first idea is that the tester is not responsible for the quality of the developer is low, indeed, the specific executive members have an inescapable responsibility, but the company has been digging up its deep-seated reasons: the phased target is missing, the project interspersed with confusion.

Five, "meeting" culture

This company is I have seen the most able to meet the company, often a meeting is a few hours, the final basic inconclusive, a simple technical application problem, do not know what the horizon to go, at the same time, the company is also popular "small meeting", is responsible for meeting, this is scientific, the person in charge should meet and discuss regularly. Then its problem is that some of the conclusions of the "small meeting" are not communicated, and even sometimes the project manager is not sure what the "small meeting" has changed. Then, at the time of completion, the members of the "small meeting" will say: "This I was not with whom who changed a piece?" Why is it still like this? Then everyone's face is crazy! Of course, I can't make any judgments about this culture at the moment, but I think that the meeting, as appropriate, say meaningful words, the rest, say go off.

VI, can not effectively manage user needs

A very simple example, the teaching of the requirements of the question bank, we at the beginning of the project there are many optimistic estimates, seemingly reached a consistent demand. Then on this optimistic basis, the user's demand expands, the expectations emerge from the product boundaries, users don't know what to expect or they can't see the actual progress of the project, and then they are disappointed with the project and our relationship is completely broken.

Workaround:

Managing expectations to a reasonable level is the responsibility of the project manager.

One approach is to break the project down into individual task blocks or project stages with frequent milestones. You can give your customers a recurring deliverable by posting them, so they see what they are going to get. In this way, customers can see what you are doing in the early stages so customers can ensure that project deliverables meet customer expectations.

Seven, no emphasis on risk control

In the life cycle of a project, there are many occasions when risks and anomalies can lead to problems and even failures. Feel that in this project, we have at least made the following points:

1 There is no clear definition of requirements, the result is unable to meet customer expectations;

2 Too simple technology design so that the future of the method is not changed and the possibility of scaling;

3 Invalid change control causes the project to offset the original target;

4 Inadequate testing results in errors and defects left on the product;

5 lack of support from key figures at critical times.

Workaround:

Review the list of risks and issues at the beginning of the project. One good way is to use brainstorming to list possible risks and problems, including project members, other project managers who have been involved in similar projects. Continually review risks and issues throughout the project. The workarounds in the above example include:

1. Draw out the needs of the customer and use clear and clear documentation to record the employment;

2 ask whether it is necessary to use cutting-edge technology, which has more ways to provide the same functionality;

3 Technical design by your team. This gives you a great opportunity to get a reliable and flexible design, and your team has a basic design that can be used to inherit;

4 to achieve a change control process with the customer before the project starts, and strictly according to the process execution;

5 put the test plan together with the test scenarios developed according to customer requirements. Ensure that you have sufficient resources and ensure that the customer undertakes to test;

6 develop a contingency plan for the risk of losing key people.

2016 Project Reflection