Summary of gains and losses of a podcast Project

I saw an article about project management that feels good.ArticleI would like to share with you the hope to help and inspire you as you enter the project management level, so as to promote your progress.
---- Springfield

Introduction:
 
If the title is changed to "managed summary", I can talk about it for the last half day, but if it is a management project, I really have limited goods, this is because the highest position I have ever done is just a "Shift Leader.

However, this podcast project was indeed faulty in terms of management, and it was so serious that the project was nearly out of control, and the final quality of the delivered work was indeed shameful. How to avoid the following programmers from getting tired, but the efficiency is very low; The above is a constant reminder, the product is a bug after a bug, there is no way to deliver; the project manager is tired, but the project is still out of control? After the end of a nearly out-of-control project, isn't these problems worth a good summary and reflection? Although I have limited capabilities in project management, I still hope to make the next project try to avoid and improve the problem. I am very happy, because I am still on the road of "good study, every day ......

I recently read the project management book "quick software development". I wanted to summarize the project by following the chapter and following the articles, but I found that what is the use of such dead books? Is the project problem that you actually feel like that? Will anyone read such articles? Can the listing of such entries reveal inspiration to others and yourself? Therefore, I finally gave up that idea and used this kind of vocabulary as a "layman", but it was written in a way that I learned from my own experiences.

Is time enough?

Maybe I have been working on an outsourcing project in Japan for a long time, so I was surprised when I heard that this podcast project needs to come out from nothing within a month, because such "man-month" resources may be equivalent to 1/5 or even less of my previous "man-month" Resources in Japanese companies. Maybe you will say that we don't need so many documents, so strict procedures. Therefore, if we remove the "Demand Analysis" time, we will remove the "Outline Design" Time and the "Detailed Design" time, and we do not needProgramWe have a dedicated test team. So since we have removed so many steps, it is okay to shorten the time To 1/5. But do you know? Project management is not a simple addition and subtraction operation as "3-1" and "-1. What you get when you use 3-1 is not 2, but 1, or even less. Too redundant things can indeed be reduced, but a lot of things, when you initially think it can be reduced by time, you will spend 2-10 times more resources in the future to make up for it. This is not worth the candle, for example, "Demand Analysis ". I am sorry to see that there is no "image migration diagram" in this project ". As a result, page jumps are messy and even appear. Although some pages are made, there is no portal.

According to a senior colleague in the team, the previous project manager never considered that the time was too short. The time set above was never refuted. In the above example, one month is complete, and one week is complete. "Can that be done ?", I asked. "Of course it cannot be done. work overtime! Jijia! As a result, overtime cannot be completed, so I told my superiors that the programmer is inefficient. ." As a result, the entire team was lost. Under such circumstances, Zhao took over the mess, so after listening to the story, I sweated at him.

Reference Solution

Time Estimation is a powerful tool. The estimated time difference may be significant at the initial stage of the project, but the estimation made after each milestone stage will be more accurate. Until the project is completed, the time estimation will be accurate. This gives us the inspiration --

1: In the early stage of the project, do not limit the time limit to death, but should be within the same scope. "Sorry, I cannot answer your exact completion date before making a full assessment and analysis, but it may take one to three months for the project to be preliminarily estimated. The most likely time to complete is 2 months ". This is a good answer. It is likely that your "3 months" ceiling will be intimidated, but when your project is actually completed in 2 months, in the end, your evaluation will be better. Let me tell you a little story: I used to like candy when I was a child. I like the hard candy of 10 yuan for a nearby store. I buy one dollar each time. Every time I went to buy a house, if she was the boss, she always liked it. She grabbed a small one and put it in my hand (about five), and then added it to 10 one by one. In the words of the boss, he prefers to put the hacker in my hand (about 15) and then take it one by one until there are 10 in my hand. I don't know why. I really like my boss, but hate my boss.

2: every time a milestone is reached, the time estimation should be carried out again to provide a more accurate time range. At the same time, it is easy to summarize why the previous phase took so much time.

What is it like?

The most basic basis for time estimation is demand analysis. What is it like? In what environments? What functions do I need? How many pages are there? How do I jump between pages? Where does the page come in and where can I go out ?...... How many projects are started after these needs are fully understood? Or more -- "It's almost like that." "first, some functions can be added later." "The Planning Department said, can you add this function now? "...... I will not talk much about the dangers of starting construction if the demand is unclear, but I still want to list the data-"The prototype problem that can be solved by one resource unit in the initial stage, 2-10 resource units will be required to solve the problem in the future ".

If the time is really tight (after all, for software or websites, especially commercial software or commercial websites, release time and market preemption are the first ), I think that something like detailed design can be simplified, but requirement analysis and image migration still require strict requirements. In fact, many people are idle in the early stage of the project. Some things can be done by idle people first. Then, let's discuss and make a conclusion. This not only completes these crucial tasks, but also provides great benefits for the team to warm up and stay dynamic. There will be no "idle when idle, busy when busy" phenomenon.
Note that all these things require documentation, rather than verbal decisions.

Bad apple

As I mentioned above, the team was dispersed by the previous project manager and the entire project was messy. Therefore, this team has no group culture at all. Even a "bad apple" with "pay-as-you-go ". However, if it's just "getting a pay-as-you-go", it seems that the harm is not very great. If such "worse Apple" appears, the whole project will be at risk --

For your ownCodeIt is extremely irresponsible. There are too many junk code, and you never test your own code. The highest principle is program running.
You can use the simplest method to complete functions without considering the code running efficiency.
A bug is always in conflict with each other, shirking responsibility, and even refusing to fix it.
Independent from superiors.
It is tempting to destroy the team culture as much as possible.
Refuse to cooperate with superiors or even quarrel with superiors.
More actions endangering project development ......

In fact, many people are not very happy to do bad apple, maybe because the previous project manager was too chilling, maybe the previous project manager dispersed the entire team, maybe there is a problem with the project system, maybe ......, There are too many possibilities, but the fact is that our team has really experienced bad apple.

Maybe the fastest and most effective solution for bad apple is-Open it! But is that really the best way? Have you ever wondered what kind of soil breeds these "bad apples "? I found two bad problems in our company --

1: There is no clear reward system. Just like eating "big pot meals" during the Cultural Revolution, it is a good job. Every month is a great salary. If everyone really thinks so, inertia will come out.

2: There are only unreasonable punitive measures. Although the technical center has not yet taken such measures, I heard that the edited article will be charged if there is a mistake. What I am most opposed to is the "Money deduction. Because it is particularly easy to arouse the "resistance" of employees ". You may say that if you are late for work and do not deduct money, what should you do if you are late? In fact, the deduction is relative to the reward. Part of the money that should have been given (of course the following employees do not know ). After that, the full amount will be sent. If there is any violation, the portion will be removed and the remaining portion will be sent. Just like the so-called "full attendance rewards" of many enterprises. There is nothing profound, and there is no psychological strategy.

Therefore, although "open" is the most effective and fast method, it is useless if the soil of many bad apples cannot be improved, bad apple will come out one by one. Establishing a good team culture and a reasonable company system, a positive team is the most fundamental solution.

Tracking and feedback

In the early stage of the project, the project was still under control, but these items were not well executed and implemented in the later stage. What impressed me a lot is bug tracking. In the later stage, some bugs were not clearly matched, or even were not corrected. If the bug correction task is assigned, the following errors are not corrected. If the bug correction task is corrected, the correction is incorrect. In addition, the following people do not test the corrected bug or even run it. When such a phenomenon occurs, programmers are tired in the later stage, and the inertia is relatively large, but more is caused by the absence of effective tracking and feedback mechanisms.

Reference solution --

When I first entered the company, Zhao asked me, "What kind of position is your company's pL (programmer leader? What are you doing ?". I said, "PL is actually a bridge between PM and PG ". At that time, we may not have a deep understanding of this metaphor, but now we seem to have a deeper understanding. In the later stages of this project, Zhao (PM) could hardly say that he was busy, so he had to put down problems like bug tracking and feedback. However, no matter who PM is, who is responsible. In fact, this is what PL should do. PL goes through the complete bug correction workflow and reports to PM. No bugs, no fixes, no fixes, no tests, other new problems, and feedback to the testing department. These Detailed workflows should be tracked by Pl. After PL finishes the workflow, it can report it to PM. In this way, the PM can also be tracked on the whole. In the previous project, one person was not fully utilized, and that person was -- I. I am responsible for page styles and web standards. These things are the busiest at the beginning, but I am the busiest at the end. But occasionally corrected the feedback on the page. In fact, at this time, I should assume the role of PL and take over the things (such as tracking and feedback workflows) that Zhao did in the early stage. At this time, PM focuses on more urgent and important things. As I first joined the company, I was totally a new comer in the previous project. I am trying to keep a low profile on many things. In order to avoid the impression of others being too aggressive and impetuous. So in the later stages, I was a little upset when I saw that others were very busy, but I was very relaxed. Therefore, in the next project, I will take the initiative to undertake some of the jobs that I can do. To reduce Zhao's burden to a certain extent.

 

Is code review too time-consuming?

This project is a hard nut to crack with low code quality. In the later stage, many codes may need to be re-written by Zhao. The cost of this situation is huge. The code written by some modules is completely rewritten, and the resources consumed will be wasted without a doubt. PM is writing code when the project is the most tight at the end of the project! PM has limited energy and time. If he is writing code, who is managing the project? What's more, he makes people feel that the entire project is full of loopholes, and psychologically cracking down the entire team. In the initial stage of the project, especially when the project time estimation is too short, the code review seems to be a waste of time, but "the earlier the bug is found, the earlier the correction is, the lower the price you pay, the truth is absolutely true.

Reference solution --

Improving code quality and focusing on project quality is definitely the top priority of project management. Code review is an effective way to improve code quality and project quality. Strict and unified code I feel better readability and maintainability than "scattered" and "personalized" code. In addition, I feel that the Code review has a good guiding significance for the new person's progress and coding habits. Many enterprises have a headache in training new people. In fact, the best way is to review the Code he wrote. When he has not developed a bad habit, he can give a stop and guidance.

Version Control

If version control fails, as I said in my summary on the "podcast" Project-web standard page design, the light is crazy, and the heavy part is vomiting blood. During the deployment of this project, there were some things worth pondering: During the deployment, the stored procedure executed was not the latest version. As a result, the final deployment takes a lot of time and effort for debugging and error detection. It is also because of version control problems. In the later stage of the project, there was a serious problem that the real running environment on the line was regarded as a test environment. Think about how serious it would be if the user experienced a "Yellow screen" at a few clicks in the future when the traffic volume is really high.

Reference solution --

In fact, we all have software for version control, and they are all the same. Why is version control successful, and our version control is so messy? In fact, the root cause is not the source code control software or version control software, but the workflow and work attitude. In most cases, we do not follow the strict workflow for the sake of convenience. The final workflow is also a false one. There will naturally be one or more problems. Version Control is only one of these bad work habits.

Postscript:

It suddenly feels a little messy, and it feels like problems are everywhere, and the problems mentioned above are everywhere. All the problems, big and small, have stirred up together, making me feel chaotic. In fact, if the program fails to run out of date, hundreds or even thousands of errors are actually caused by the errors of those core codes, you will find that, if you fix those segments of core code, hundreds of errors will disappear. Just like in project management, if a healthy team is established, all seemingly chaotic problems will disappear.

In the previous article, I only listed some problems. The so-called reference solution is even more powerful.