content
1. How deep is the pit?
2. Who is making the pit?
3. How to avoid pits?
"No one can change the status quo. Only when countless programmers shed blood on the earth can the project be rebuilt." This is not an exaggeration. A software project is a hole when it is rotten, and the participants are just filling the hole. It's like meeting the national team in the World of Warcraft battlefield, you can't win, you can't get out.
1. How deep is the pit?
When we enter a project, we can find out whether our project is a pit or not through continuous observation. Projects that build pits often have certain "smells". The following are some of my understandings. These "smells" are obvious signs of poor project health:
-
Coding specifications are a waste of paper, and the quality of the code is low. Every project has coding conventions, but really strict enforcement is another matter. Too many projects use coding conventions as a formality, and no one cares about letting developers write "programs that people can understand", and comments and naming have become developers' discretion. There are always only development tasks on the project, and there is almost no time for unit testing and code review. Projects under high-pressure schedules appear to be so imitations. When we are still complaining about our low wages, let's see if our program can still be called OOP.
-
Lack of documentation or low quality documentation. Preliminary documents are very important, whether it is the framework's API manual, requirements or design documents, as well as the specifications of various established processes, different types of templates and checklists, etc. These documents are very important resources for the project. . In some projects, such documents are written by people who are not in the software industry, or do not plan to waste time on documents in the early stage. This leads to the lack of relevant documentation or the low quality of documentation. During the software construction process, developers and teams have to struggle with the product of this "surface engineering". It will even go back to prep work to complete the required documentation. Some documents can be supplemented in the later stage, but some must be prepared in the early stage to keep the team from reducing risks, reducing the chance of attracting defects and improving the coding quality. If such documents are not done well in the early stage, it will be like not reviewing before the exam , self-eating.
-
Endless demand changes, never catch up with the progress. This is the most common and scariest because we can't get it done no matter what. Clients may think that changing a program is as easy as changing Excel, and will even use all the rights and resources at their disposal to implement the change. Well, I admit that I have come across a lot of clients like this. After I explained the cost of the change to the customer and provided alternatives, I had to wait for the customer's choice.
-
Just relying on overtime to cope with the backwardness. It's not scary to be behind, what's scary is to work overtime to catch up. This is the crux of the problem. The long-term rush work still fails to catch up with the schedule, which only means that the project has some kind of deeper problem, which cannot be solved by rushing the work alone. Pay attention to projects that work overtime for a long time, they often have big problems in management, find these problems, and don't make similar mistakes when you become a PM.
-
There is no way to communicate. If you are in a project that "calls every day should not be, and is called earth is not working", then you better worry about it. Communication is very important in a project, but there are always some projects where the leader is too busy, people just can’t find it, no one responds to the emails sent, and if you encounter a problem, you have to take care of it yourself. There are also some benefits in such a project, such as exercising your self-learning ability, and honing your will and root. But these are all my self-deprecations. Ineffective communication leads to unnecessary rework, which is what I hate. One of my most annoying experiences was that Party A wanted to make changes, and no one notified me during a one-week meeting. During the week, my team completed several requirements originally planned and entered the testing phase, but these requirements were all rejected. chop off. Originally, only Party A informed that it was possible to adjust the progress to develop other modules, but it eventually turned into a waste of resources. You can see how important communication is.
-
没人关心质量。因为软件构建属于专业领域，客户并不具备相应领域的知识，由于这种信息不对称，助长了软件的质量低下。我们开发的软件可以是“低等级高质量”的，但不能够是“高等级低质量”的。但是，太多的项目不在注重编码质量，这与软件构建的复杂度有关，也与整个行业的风气有关。但不管何种原因，提高代码质量仍然应该作为团队的努力方向。团队应该奖励那些，编写高质量代码的程序员。如果你的团队奖励的是那些，“BUG杀手”（每天修改上百个BUG），而冷落那些缺陷检出数量很低的程序员，那么，你的PM是个不懂技术的，至少我本人认为，任何有技术背景的PM都应该奖励那些正在保持职业操守，认真对待需求，保证代码质量的程序员。他们为项目付出了更多，更多的异常处理， 更多的测试调试，更多的检查，更多的重构，虽然他们的进度并不快，但他们引人的缺陷数量很少。每个做过开发的人都会在质量和进度上做出取舍，而我敬佩那些选择质量程序员，因为他们才是真正拿开发当事业的人。在此，向所有努力提高代码质量的程序员致敬！
-
没人为缺陷买单。没人为自己的成果负责。需求产出了低质量的文档，设计没有进行充分的迭代，开发可以怎么简单怎么写，测试可以随意测测，没人为自己的成果中的缺陷买单，除了项目经理，他为项目承担唯一责任。当项目组所有人员都在混时，就是在给自己挖坑。这种缺陷的堆积，会像放射性元素在食物链中的堆积一样，早晚项目会因此而崩溃。
-
过高的离职率。这个是最明显的“臭味”，这说明我们的同行已经在这里无法忍受了。它所带来的恶略影响不光体现在可用资源的减少，还体现在对成员士气的极大影响。如果不及时改善，这将是一个非常恶性的循环，当往一个进度落后的项目中添加资源只会使进度进一步落后，而非正离职导致必须补充新的资源，资源从入职到培训都会对对团队产生震荡，并降低现行团队的生产力。一个频繁处于形成阶段的团队，很难要求其有什么凝聚力，团队问题将会凸显，尤其是在沟通上，在项目忙的时候很少能照顾到新人。花费在对新人进行培训，和与其沟通上的时间，很可能得不偿失。
-
团队中的不良情绪。不同团队开始扎堆并相互敌视，例如开发组认为设计组是一帮搞业务的白痴，根本不懂编程；测试组认为开发组的人就是垃圾，BUG提交了多少便还是无法关闭；PM开始抱怨，自己的成员不配合；成员开始抱怨，PM是个纯管理没资格指挥内行做事。等等，诸如此类的怨念会在团队中积累，并以某个导火索为契机爆发。面对现实吧，至少，我远没有自己想象的那样高尚。我承认我曾经会和别的程序员说：“你看XX他们写的代码...什么呀...”，这样的话。在过去我也吐槽过别人代码，这种做法是错误的，我为此表示歉意。现在，如果有必要，我会说代码有缺陷，但绝不会说他的代码不好。我希望，我们能彼此尊重。对于技术人来说，不尊重他的成果就是不尊重他的人，所以我还是建议PM在管理工作中，多用“缺陷”，少用“不行”、“不对”。但是，项目中也总是有些人，靠鄙视别人的成果来彰显自己的实力。这些人，有，但很少。至少我遇到的很少，遇到过几个，让他们的话语成为你学习的动力吧。我曾经被人讽刺UI做的太丑，之后我学会了SL和FLEX；被人鄙视基础太差，之后开始阅读《CLR Via C#》；我朋友被人嘲笑过数据库设计，现在人家也开始买书深造。团队中就是这样，我们无法管住别人的嘴，但我们可以管住自己的。少说多听，一鸣惊人，乃上上之策。不要受情绪的影响，保持一个平静的心。
-
没有项目或阶段的后评价。不对项目的阶段进行后评价，也意味着没人在乎你到底干了些什么，所有人都只是进度是否完成，而没有对完成的好坏进行评价。这也意味了，仅靠做好你的工作，你是无法得到领导的重视的。最终只有那些加班时间最长的程序员被领导认可。而能力强，口碑好的成员也只能在团队和客户中间留下传说。
二、谁在造坑？
软件项目涉众众多，造坑的多为项目实施团队内部，而究其原因也是多方面的，但是始终离不了项目的四个维度——时间、范围、成本、质量。很多时候客户并不具备软件项目的实施经验，而实施团队为了迎合客户意愿，也会多多少少的在这四了维度上做文章。资源、时间不足，轻质量重功能，往往成为造坑的契机。所以，不用怀疑，造坑的往往是我们自己。很难理解，真正挖出大坑的人，最后也是填坑的人。一个人很容易被外部事务所左右，就如“同假的多了，真的到成假的了一样”，多数人不愿意在一个新环境中表现得特立独行。但也有老的程序员对我说过：“当别人做错了，你就不要跟着去做！”所以，我认为工作就是工作，不需要我们在其中融合多少兴趣，也不要求我们有过多的付出，但对于工作的成果则要求我们认真的对待。俗话说：“拿多少钱，办多少事！”如果多少有些团队意识，能够对自己的工作负责，那至少在意识上，我们能给自己少造些坑。
三、如何免坑？
（一） 清除盲区
以下观点，仅是我对软件项目中一些错误认识的归纳：
-
写出能用的程序就行啦！我们应该首先清楚我们做的是什么，一个成熟的团队产出的可交付成果应该包括软件编程产品，相关文档，项目实施过程中的经验教训已经其它一些非形式的成果（培训）。这里，我们必须清楚的认识到，我们所开发是是编程产品，而不是我们个人的技术实践或大学的毕设。对于编程产品，我们必须认识到，其是产品级别的，必须保证质量，必须提高用户体验，必须考虑系统的诸多特性或维度。这一过程远比我们自己写个程序要复杂的多。设计需要不断地进行迭代；开发人员需要遵守严苛的规范，编写大量的注释和大量的异常处理；测试人员需要不断地进行各种重复测试，但是正是这种全局的规范，全体团队的不懈努力，才保证了我们的编程产物可以称之为产品。所以，一定要明确，我们要完成的是一个产品，而不是一个毕业设计，它不是一个人的技术实践，而是整个团队倾注精力去完成的最佳成果。我们可以轻松的实现客户的某些需求，但需求背后的某些东西，需要我们认真对待，比如安全性和性能等。实现功能的程序谁都会写，而写出高质量的程序的才是真正的艺术。
-
尽快开始编码吧！软件构件是一个精心设计的过程，其前期准备十分重要。在后期修复缺陷的成本要远远高于前期。因此，在项目执行前，前期的规化十分必要。在前期每发现一个缺陷，都会为后期节省大量的成本。
-
需求怎么变了！没有不变的需求。
-
进度落后了就招人呗！这是种典型的错误认识，《人月神话》中已经说明的很清楚了——往一个进度落后的项目中注入资源，只会使进度进一步落后。虽然，这本著作成为PM必读之作，其思想也被业界所广泛认可，但是，还是会有很多管理者单纯的认为，通过注入资源能解决问题。对于这些人，只能让实践来检验真理了。
-
软件质量保证是测试的工作！这是一种逃避责任的说辞。如果把代码质量比喻为减肥，那么测试无疑是一个磅秤，减肥工作还是要有开发人员来完成。所以，不要将代码质量都寄希望于测试工作上。即使是大规模的用户测试，其错误检出率也不足五成。而真正挑起代码质量重担的是代码审查。
-
程序员你8小时就写了这么点代码？让开发人员将全部时间都花在编码上是不可能的。开发人员需要时间预读文档，需要与相关干系人进行沟通，需要花时间来搜索资源。此外，可能还需要编写文档，参加会议，培训以及处理个人事务等等。这些时间都会无情的夺走编码的时间。程序员大约有近似20%的时间甚至更多会用在与编码无关的事情上（不算上班或聊QQ），所以不要错误的以为每个程序员每天能写8小时的程序。
-
你今天写了这么多行代码真有效率！编码不是在扫地，比谁扫的面积大。不能单纯用行数来评价开发人员的工作量。评判的标准应该结合模块的复杂度，编码的缺陷检出量以及最终交付时可用代码的比例（实践表明，我们报废了大量的无用代码）。
-
他今天把自己100多个BUG都改了，我们得在组里表扬下他！在我看来这样的领导不跟也罢，这就是让人相当无语的行为。好的开发者在提交测试前，觉得会对自己的代码进行走查和调试，甚至使用单元测试工具，因此其代码的缺陷检出量很小。这样的程序员，才值得被表扬。而那个一天改了自己100多个BUG的人，作为管理者应该想想，流程哪里错了，需要进行改进。
-
设计我来定，开发你闭嘴！这样的例子也不少，这种做法有一种听起来非常合理的理由——保证项目架构的概念完整性。其解释为，如果将设计人员从开发人员剥离，那么就可以将架构的概念完整性统一，因为设计人员的数量比开发人员是数量要少的多，更容易统一认识。而这样做的项目组，也默认地认为设计组的技术实力要明显高于开发组。他们往往从开发组中选择优秀的设计人员到设计组，但也会有走眼的时候。其一，硬手没有被提拔。这时候多半是硬手对设计不满，并对团队管理层产生质疑，并想法设法进行沟通。如果处理的好，可能硬手会被重视，如果沟通无门，那之后，可能会充斥着抱怨和不满，以及人际关系的恶化。有些强硬些的可能会选择拒绝不合理的设计或更为极端的是离职。走眼的另一种情况是，挑的人干不了设计。这样往往就是让他锻炼，而不是撤换（彼得原理——每个人都会被晋升到他不适合的岗位）。这就郁闷到极点了，设计者将会与相应的数名开发人员进行一场旷日持久的暗战。其中，已经不只是个人的抱怨，甚至会演变成成员集体的士气低落，并最终促成小组的重组。我认为，有必要将开发人员纳入设计活动。应该参考开发人员的意见，其原因有三：其一，开发人员对实现相当熟悉，往往发现设计中的不足；其二，通过授权开发者参与设计，能让其感受到认同感，提升其参与项目的欲望，和责任心；其三，让开发参与设计，可以对设计人员进行储备，在需要时作为备选资源使用。
-
客户（领导）说必须完成，我也没办法！这就是“领导一句话，劳动人民跑断腿！”这是非常典型的加班借口。软件构建过程如同耕种，你每次只处理它的一小部分，一点一点的加到整个系统，使系统一点一点的“生长”。这也暗示了，工作应该按部就班，正如春种秋收一样，各个环节有强硬的逻辑存在。所以，我们必须学会对不合理的要求说“不”。这里并不是说要拒绝客户的需求，而是指应该向客户说明情况并提出相应的备选方案以供参考。例如通过通过削减范围来达到按时完工的目的。PM需要向客户说明情况，并向其提供几套可行的解决方案，以促成项目向良性发展。
-
我是领导我来排进度！工作进度的安排不能是领导的单方决策，而应该参考做了解这项工作的人的意见。
-
系统上线了，项目就算结束了！只有当可交付成果成功移交，项目进行的相应的收尾工作，项目的经验教训文档被总结和归纳，一个项目才算真正意义上的完成。
（二） 参考建议
-
做好前期准备。前期准备很重要，如果在开始构建之前认真的地进行适当的准备活动，那么项目会运作的良好。充足的准备防止我们制造一个错误的产品。前期工作的好坏，多少会为这个项目的成功和失败打下基础。即使进入构建阶段，如果我们发现前期工作做的不好，也完全有理由退回去。前期准备工作和核心目标就是降低风险——一个好的项目规划者能够尽可能早地将主要的风险清除掉，以使项目的大部分工作能够尽可平稳地进行。目前，对后期影响最严重的风险是糟糕的需求分析和项目规划，因此准备工作就倾向于集中改进需求分析和项目规划。
-
预先行其事，必先利其器。用软件武装团队提高生产效率，例如：版本控制，错误跟踪，信息发布，自动发布，CASE工具，调试工具，测试工具，文档管理，代码生成工具等等。
-
分析项目类型，在管理和构建之间找寻平衡。商业系统、使命攸关的系统、性命攸关的系统在整个项目阶段具备不同的控制粒度。需要根据项目的具体类型来确定管理的严谨程度，避免“过度控制”或“控制不足”。
-
需求必须被冻结。需求必须被冻结，如果需求不能冻结，那么谁来了都没有用。再强的团队也无法完成一个无尽的任务。
-
变更必须走流程。正确应对变更，变更并不可怕，可怕的是失控的变更。以下建议希望对读者有所帮助：
在构建期间处理需求变更
核对需求，评估质量：如果需求不够好，停下来，把它做好再开始。
确保每一个人都知道需求变更的代价：让客户知道需求办更并不像在Excel上进行几个修改那样容易，“进度”和“成本”是你最有力的武器。
建立一套变更控制程序：固定的变更控制程序让你知道在什么时候处理变更，让客户知道你会处理他们的提议。
使用能适应变更的开发方法：迭代与增量。
放弃这个项目：如果以上提议没有一条奏效，需求变更极其频繁，那么，评估你的项目，考虑放弃它吧，继续下去你只会越陷越深。
注意项目的商业案例：性价比，没必要满足超出项目成本的需求。
-
关于加班。做IT的加班是很正常的，但加班要加的有意义，而且不应该长期加班。必须针对关键路径上的工作进行赶工，而不是做些无法加快整体进度的工作。而且，应当安排调休，而不是支付加班费。其主要原因也是我不赞成加班的原因——疲劳更容易引人缺陷。加班无疑会使人疲劳，每个人都想尽快结束手上的工作后回家休息。在长期疲惫的情况下，人员的工作效率会下降，士气会低落，非正常离职率增加，最重要的是疲惫的团队很难保证软件的质量，缺陷在不知不觉中引人，在后期无疑会为此付出代价。项目的总成本和周期，都会随着引人缺陷的数量的增加而倍增，而且发现的越晚越严重。
-
做好版本控制和配置管理。版本控制和配置管理是必须有的，即便是再小的项目也不能忽视，必须加以重视，一旦版本混乱，多多少少会对构活动造成影响。所以，平时不要偷懒，管理好每个基线。
-
授权的好处。授权好处多多，包括：一，减少管理者工作量；二，对人员有意识地进行锻炼，培养储备人才；三，提高人员对项目的参与度，从而提高士气。
-
乐观管理与悲观管理。乐观与悲观完全取决于人的性格，一般来讲多数倾向于乐观，应该清楚这两种性格在项目中的优势与劣势。我本人倾向于悲观，可能是性格使然，但悲观的管理至少不会误事。乐观管理的优势在于，很容易营造气氛，擅长给客户或领导描绘一个美好的未来。这种作风，前期很舒服，但后期可能要吃苦了。乐观管理容易出现的问题是对风险的预计不足，不能预留充足的缓冲时间，没有准备足够的预防措施。其表现就是，在进行进度计划时，总是认为今天的问题今天可以解决，已经修复的BUG将不会再次出现，用户需求是最后一次变更，等等诸如此类的乐观想法会使管理者蒙蔽双眼，而没有做足风险应对，其结果就是不管怎么加班就是赶不上进度，因为进度计划被设计为最顺利的情形，而不是现实场景。悲观管理的好处是，为潜在风险做足了准备。但悲观管理有一个非常大的缺陷，就是“过度控制”，可以比喻为“疑心病”（小心的都有些病态了）。其表现是为：按照之前的措施，发现遗漏了一个问题，那么悲观管理者会在之前措施基础上增加新的保障措施，然后又发现遗漏了一个问题，之后会继续追加保障措施。乍看之下没啥问题，因为是在不断地进行过程改进，但问题出在保障措施的增长速度过于惊人，称其为“疑心病”一点也不为过，悲观管理者容易在很小的地方施加过多的控制，造成人日的浪费，而忽略掉本应该关注的更为重要的问题。不管那种性格的管理，清楚自己的弱点总是好的。
-
有效的沟通，不要踢皮球。软件项目因为其本身的复杂度和涉众众多，所以更加需要沟通。沟通问题是所有大型项目都共用的问题，在大多数团队中往往也不认为沟通是个问题。但我还是想请读者认真对待沟通，比如邮件。邮件可以回复的慢，但请回复邮件。当我在一个连发出的邮件都没人回复的团队中工作时，除了无法解决问题，让我感受到的只有无奈以及冷漠。
-
客户是我们的朋友。把你的客户当成朋友，客户是我们做重要的资源之一。在每个客户背后往往隐藏着更多潜在的客户。我们必须清楚，客户作为非专业人士，其可能并不理解我们的工作，在项目执行阶段产生摩擦是难免的。但是，这些都不能成为我们迁怒客户或故意在工作中放水的借口。即便是为了项目能成功收尾，我们也必须维护好与客户的关系。
-
不要超前设计，不要项目镀金。超前设计和项目镀金都是不可取的，因为他是在浪费资源。满足需求以外的东西，不会对你的项目有任何好处，但是却可能引人缺陷。
-
总结经验教训。必须对阶段进行经验教训总结，没有什么比这些收获更有价值。这样文档就是组织的资产，是以后类似项目的参考和依据，并在持续优化方面发挥更为重要的作用。
-
不要让会议和文档拖了团队的后腿。“当船快要沉的时候，我们需要的是一个发号施令的领袖，而不是开会。”软件项目的核心问题是降低复杂度，越是复杂的项目就越需要沟通，但别让开会拖了我们的后腿。没有必要的会尽量少开或不开，要常开会，开小会，每次会议就几个相关干系人碰头沟通下就可以了，没有必要扩大为全员参与。冗长的讨论应该适时的终止，毕竟会议室上只能做出决策，而解决问题还得在会下。所以我认为应该精简那些冗长的会议，别然开会成为我们的工作。此外，要时刻谨记客户最终需要的是可以良好运行的软件产品而不是华丽的文档。所以，文档要恰到好处，写的再漂亮的文档没有完备的系统也不过是废纸一堆，别丢了西瓜捡芝麻，可以正常工作的软件才是我们的工作重心。
-
核对表的你的好助手。就像飞机工程师在检查飞机时使用核对表一样，软件项目也可以大量使用核对表。核对表可以帮助检验文档的质量，降低缺陷数量，以及改进项目管理。好的核对表，是你工作中的好助手。
-
小范围的受控好过大范围的失控。要注意控制的粒度，事无巨细。根据项目规模，人员构成，要采用不同的控制粒度。评估可控范围，并不是控制越广越好，控制不了就是失控。 对无暇顾及的地方授权别人管理是个可行的做法。 即便是小范围是受控，也好过大范围的失控。一个失控的项目，谁也不知道其会走向何方。