According to the original plan, the third chapter is to write about the common sense, because the Feiyue plan has to hand in the homework, so I changed to write some of my own experience in project management. It happened that the girl we chased together in those years was very popular. , the name of this sentence is called the project we did together in those years.
My first project was in 2005. It was a localization translation company with the top three market shares. There were only two people in the company's information department: the boss and me. We developed the company's internal collaborative office system together. The problem to be solved is simple: As the company grows rapidly, the task of assigning and tracking tasks that used to be purely paper documents and mail has increasingly overwhelmed project managers and finance, and there is an urgent need to automate these tasks. The technical architecture of the system is also very simple: jsp+javabean+mysql. There is no special development plan, the basic development process is as follows: every Monday we interview a business manager to understand his needs, develop in the middle of the week, if there is any problem in development, you can directly contact the business manager, and test on the system on Friday environment and sit down with the business manager to see if his needs are met. The system has been developed in this way, the boss's office is behind us, and the boss will use the system with us whenever he has time. There is only one detail in the entire development process that impressed me, that is, when estimating the workload of a task, no matter how much I estimate, the boss will multiply it by 3, and add a field to the business form at a time. It takes 10 minutes to add a database field, and the boss gave me half a day. The boss said that adding a field really only takes a few minutes, but it takes time to open the editor, it takes time to concentrate, and it takes time to start the system test after the change. Time, it will take time to confirm the requirements with the business manager after testing, we estimate the time to complete the whole thing and not just the time to code.
When the project was completed, it won unanimous praise from the whole company. From the company owner to the business manager, everyone was very satisfied. The only regret I felt was that as an IT staff, I never worked overtime.
In retrospect, this project was successful because the technology was simple and the system was not complicated (we didn't even need SVN, we completely relied on scripts to synchronize the code), but the most important thing was continuous delivery and continuous user feedback, the boss and business manager every time. Seeing new features go live every week has boosted their confidence, while feedback is happening almost every day, and they can quickly see if it's what they want.
The second project was in 2006, and I changed jobs this year because I thought programmers who didn't work overtime were not good programmers. The new company is in Shangdi. It is a company that makes a collaborative office business platform. It first went to the project department. At first, I was very fascinated by the concept of business platform, because when writing programs, the first thing is to use code generators instead of code. Generate code, and the generated code is ready to run! The first project is Toyota's sales management system. We innovatively used the hottest Ajax technology at the time. We completely used the enthusiasm for technology and the weekend to complete the Ajax enhancement of the original functions. This project has won a very high user rating. Evaluation, because when most web systems are still using click/refresh for interaction, we can drag and drop directly to complete the operation. If at that time, I would think that technological innovation made the project successful, but now, I will use the word progressive enhancement, that is, only after completing the core functions required by users (what is a core function, that is, the lack of this function system) can not work) before starting to gradually optimize the system user experience and performance.
The third project is in the platform department of the company, where the department manager is preparing to rewrite the original business platform. The technical framework of the original business platform is: jsp+struts+ojb+sqlserver, and the new technical framework is defined as: ajax +freemarker+webwork+spring+hibernate. This got me excited because the new technical framework was pretty much the most popular technology at the time. There are three developers in addition to the department manager (so communication has never been a problem), the boss uses the project to manage the project, each person is responsible for a module, the estimation is in units of weeks, the initial plan is to deliver in 5 months, and the function is directly a replica of the old platform The only replacement was the technical implementation, but a large number of defects were found during testing and project trial 5 months later. In the end, it took almost half a year to converge the defects, and the product release plan was postponed for half a year. Looking back on this project, the inconsistency between implementation and requirements seems to be the most important problem of project delay without detailed decomposition and review of requirements. However, a deeper consideration is whether we need to start the development of new products for technical reasons, without affecting the use of users. Is it more appropriate to incrementally enhance the original business platform under the circumstances? That is, when we start the project, we should pay more attention to user value (only users with user value will pay for the company to benefit).
The fourth project I am in charge of, this project is almost a copy of the previous project, rewriting the company's workflow products: supporting more workflow modes, easier integration of api and management interface, the only difference is that this project adopts I learned a lot of agile practices: continuous integration, unit testing, stand-up meetings, and iterations, but none of these practices will affect the final failure of the project. It is also a question of whether or not to rewrite this project. Under the circumstance that the company's capital chain is tight, time requirements are tight, and the new product has no outstanding features compared to competing products, this project has been determined to fail from the beginning. Don't rewrite the product without a particularly good reason. This is almost one of my most important principles right now, especially from the perspective of the company as a whole. The product cannot be limited to technology. Now, whenever anyone talks about rewriting the product for technical reasons only, I'm going to sweat it out. In the case of being fully responsible for the project, my other profound feeling is the importance of people. For every person in the team, as a leader, you need to know what his needs are. No one wants to be a robot. After a technical solution was simply and rudely finalized, a core technical staff was lost, which became the last straw that overwhelmed the project.
At the end of 2008, I went to a new company that adopted agile practices. The first project was very successful, almost a successful example of agile projects. Requirements analysis, iteration, continuous integration, pairing, customer showcase, continuous delivery, and the project was even completed half a month ahead of schedule. The only fly in the ointment is that in the second phase of the project, the new team caused a lot of trouble due to the lack of documentation in the first phase. The outstanding feeling is that the team members have roles and division of labor, and there are also processes. Now, when you arrive at a new department or center, the first thing is to sort out the project development process and define the roles of each person. Unclear responsibilities are the source of mutual complaints.
The second project is a consulting project, which is omitted. The third project is a distributed team. Some teams are abroad, and some teams are in China. At first, everything went well, but a month before the launch, it encountered serious performance problems and fell into chaos. Everyone did not know that we were leaving. How far is it to go online, what work still needs to be completed, what are the priorities, the project manager even loses control of the entire project, she does not know what conditions the project needs to meet, so she waits for the foreign team again and again The optimized test results, so the test results are not satisfied again and again, so the project has become the laughing stock of the entire company in the empty promises that it will be launched next Tuesday. Looking back on this project, the team gave up the plan when they encountered setbacks, the iteration was gone, the story wall was gone, everyone was waiting, and the project manager had to think of some low-priority tasks in order to prevent the developers from being taken back by the company. We were busy with the team finishing outfits. The lesson is that the plan cannot be abandoned under any circumstances, the plan is the foundation of the project. Others include that if the team can be distributed, it should not be distributed. If it must be distributed, it must be isolated from the architectural development task and minimize the interaction between the two teams (many project managers advance the project system after entering the department, in fact, it is also The same principle, when the team is big, it must be disassembled, and the product code must be modularized to minimize the interaction between teams and modules, so that they can evolve and release independently). Test in real-world environments as early as possible, the sooner the better. The sooner the test is performed, the better, and the closer the test environment is to the production environment, the better. This principle cannot be overemphasized (we only found serious performance problems in our pre-launch tests).
The third project is lucky because they have money and can wait. After waiting for more than half a year, the system is finally online. The fourth project was not so lucky. This project is a rewrite of an online saas CRM system, and it has a strong time constraint (if it can't be delivered within half a year, it will miss the window for the system's customers to make budgets every year), see, Another rewrite, and another time constraint, almost always portends its doom. On the face of it, the project collapsed in a mid-term architectural rewrite, which took too much time for the team, and again made the project worse due to an incorrect estimate of unknown domain knowledge (need to learn), and the project goal was not met. Change, to be launched in six months, but the deeper reason is that the decision was not made correctly before the project started. Is it really necessary to rewrite the product? It is true that the old product has an ugly interface and some functions are not available, but these can not be progressively enhanced, must we start over? Rewriting and using a new team, they have no experience in the business field, they are not clear about the pits encountered in the system in the past, is their plan too optimistic because they have not considered some situations? Other problems with this project include that the project plan has not changed, and the date has not changed, despite the fact that everyone thought it would not be possible to deliver before the stipulated date. Finally, I have to say that this is a technically strong team, everything is automated, and even the deployment of the product environment is completed with one click, but these are overshadowed by the failure of the project goals. The customer loan to do this project made many team members uneasy.
When I came to Tencent and soso, the most important gain was a new understanding of operation and maintenance. I used to think that devops was an automated deployment, a full-featured team. Now I find that it is related to architecture: whether a bad case of search can be quickly found The reason for the error? Did the crawl fail, was it lost during indexing, or was the relevance sorted badly? Regarding monitoring and alarming, can we quickly locate the cause from monitoring? It is related to the organizational structure, front-end development, back-end architecture, infrastructure, and operation and maintenance testing teams are all separated. How to collaborate to minimize the cost of teamwork and maximize the overall benefits?
Looking back on the past, Paul Korchakin said: How can we not waste time, only to fight for communism for life; Ke Jingteng said: Only Shen Jiayi makes me miss; and what I want to say is:
- Before doing any project, you must figure out why you want to do this project, you must figure out that the value of this project is for users and the company (especially you need to jump out of the station to see the project at a higher level), and you must think clearly about the constraints of the project (time constraints, personnel constraints), not only to think before the project starts, but to constantly review it during the process;
- Projects must be planned at all times and transparent to all stakeholders;
- The project must be continuous delivery and continuous feedback, and black boxes are not allowed;
- Testing and operation and maintenance must be involved as soon as possible;
- Focus on the interests of all from the perspective of each team member to achieve a win-win situation.