软件项目管理原则谈

软件开发的残酷现实告诉我们，没有规则的软件开发过程只能带来不可预知的结果。我们的项目经理大多在简历中写着自己有多年丰富的项目管理经验，但在实际开发中，“丰富”的管理经验却成了软件开发人员可怕的噩梦。经过一次次的失败和返工，她所谓的项目管理经验不过是“天衣无缝”(十八层地狱)的又一场游戏。曾经，在和很多项目经理的交流中，大家都提到了软件变更的可怕影响。但是就像一个完整的法律体系不能阻止犯罪，但是没有它犯罪会更加猖獗，频繁的软件变更是很可怕的，但是没有一个完整的项目管理机制，我们无法想象项目最后会是什么样子。另外，还有一次，我在应聘的时候，招聘公司的技术总监(40-50岁左右)，向我吹嘘公司按照CMM4的流程规则开发管理软件。众所周知，当我询问下面的开发人员时，他们正在经过无数次的加班加点，在已经完成的软件项目中添加一个软件概要设计书，这让我很惊讶。这样形式主义的公司，不留下来也没关系。
我记得有一句谚语曾经说过，“人类最愚蠢的行为在于忘记常识”。另一个类似的格言是“不了解历史的人必然会重蹈覆辙”。项目管理也是如此。可惜我们的管理者大多在工作中大谈“软件工程”，“用程序代替用户的需求”，这是政客的嘴脸。其结果必然是以牺牲开发者的时间为代价的项目结束，就像现在的媒体《程序员的生存状态》所说的那样。这是普遍现象，这里就不武断评论了。
改进我们软件开发管理的一个便捷方法就是“尊重常识和历史经验教训”。在软件项目管理中，有许多原则和经验可供我们借鉴。
一、计划原则
没有计划，你无从知道何时控制和改变它。做一个详细的计划，计划要足够详细，让开发者看得懂。计划可以告诉你什么时候做什么。没有计划，你无法知道你需要做什么。许多项目经理告诉他们的团队成员他们需要做什么，然后离开，相关任务(活动)之间没有任何解释。因为没有计划或者计划过于粗糙不切实际，很多项目1/3甚至1/2的时间都花在了返工上。由于计划中遗漏了一项关键任务，该项目可能会宣告失败。试想，制定一个周密合理的计划需要这么多时间吗？是不是要付出项目失败的代价？很多项目经理往往错误地认为“变化比计划快”，但实际情况是，因为没有计划，你无法预测和衡量变化对你的项目的影响，你将面临比面条还难梳理的“混乱”状态。另外，对于开发人员来说，“目标导向”是一种充分调动其工作积极性的方法，每个任务阶段的结果都可以将员工的工作效率维持在较高的水平。因为短期目标总是比长期目标更容易看到和实现。为此，制定一个计划，使之符合目标导向(通过每个具体的任务计划来推动项目总体计划的达成)。
二、布鲁克斯原理
给已经滞后的项目增加人员可能会让项目更加滞后。因为作为新员工，相关的培训，对环境的熟悉，人与人之间沟通渠道的增加，迫使项目的工作效率急剧下降。工作效率的降低需要加班来弥补，但是加班带来的疲劳会再次降低工作效率。与此同时，工作成本不断上升。但是，目前来看，项目经理们不会关注这一点，“人多力量大”可能更有吸引力。许多项目经理抱怨时间紧迫。需要注意的是，很多项目的时间紧迫，来源于项目经理的不思考、不合理的表现，以及没有充分考虑到的开发人员能力的多样性。正因如此，正规企业不得不在加班津贴上花费大量的加班费，同时还要承担违反劳动法的潜在法律危险。现在万不得已，假设项目开发人员之间的任务相关性不是太大，采用两班倒或者三班倒，以保证时间的连续性和相关开发人员的高效率。
三。接受标准的原则
当我们从事某项任务时，我们经常会困惑于哪种结果是合适的。不求质量的开发者往往凭经验草率做事，而追求完美的开发者在这个任务上花费了太多的精力，但这个时间的支出不一定是针对这个任务的，所以往往是吃力不讨好的。这是由于缺乏验收标准造成的情况。因为没有验收标准，你无法知道你要执行的任务需要什么样的成果和质量标准。很多时候，你的活动会和预期的结果背道而驰，而你还在沉迷于自己的努力。作为项目经理，只有制定好每项任务的验收标准，才能严格控制每项质量，了解项目进度。
四。默认无效原则
您的项目成员是否理解并同意您制定的范围、目标和项目策略？很多项目经理认为“沉默意味着同意”。其实我们都或多或少会陷入这样一个误区。试想一下，你作为工作人员或者项目开发人员的沉默，完全意味着你赞同领导的意见？不一定。这就是答案。这在项目沟通中极其重要，项目经理一定不能把沉默当成同意。沉默在很大程度上表明项目开发人员还没有搞清楚项目的范围、任务和目标。为此，项目经理也需要与开发人员充分沟通，了解他们的想法。没有对项目的共同和一致的理解，一个团队不可能成功。
五、80-20原则
80-20原则在软件开发和项目管理中有很多“例子”。一个是我们花费80%的时间在20%的项目需求上。经过仔细分析，这些项目需求分为必要和非必要两类，因此我们建议将非必要部分压缩或暂时搁置，无需过多关注。软件项目开发的事实告诉我们，开发人员在非本质的项目需求上花费了过多的精力，用户需求的变更大多出现在“是”的部分。其实用户并不看重这些需求(即使去掉)，我们做的往往是求最后。
80-20原则的另一个例子是，我们项目中20%的人员承担了80%的项目任务(这在实际执行中并不算多)。考虑到开发人员能力的多样性，聪明的项目经理绝不会采取平均分担任务的愚蠢做法，因为从系统论的观点来看，互补结构比均等结构更稳定。另外，作为项目经理，了解下属员工的能力特点，并把他们放在合适的位置上会更有利于项目的顺利进行。许多经理经常抱怨他们下属的能力。本质是这些项目经理往往发现不了开发者的潜力。他们看问题，往往是以“经验”的心态做决定。结果正如系统论所说:由于“抱怨”的行动和反应循环，结果是大家都不开心。六。帕金森原理
帕金森原理原本就是政府部门臃肿低效的代名词。然而，它同样适用于软件开发。如果没有时间限制，工作可能会无限期推迟。在软件开发中，如果没有严格的时间限制，开发人员容易懈怠。这是人性决定的。不要期待奇迹发生――所有员工的思想觉悟都是极其崇高的。作为项目经理，此时要充分考虑工作人员的工作效率和项目变更的负面影响，制定合理的项目工期，鼓励开发人员尽快完成。七。时间分配原则
在项目计划的过程中，我们往往会将资源(人、设备)的可用率设定为100%。如你所知，开发人员不可能把所有的时间都花在项目开发上，因为他们需要休息、吃饭、开会等。，而且这还没有考虑到开发人员的工作效率是否保持在一个恒定的水平。所谓的8小时工作日，其实名存实亡。由于项目经理的无知，许多开发人员被迫加班。结果，布鲁克斯原理的问题仍然出现了。在实际开发中，开发人员的时间利用率能达到80%就很不错了。个人比较喜欢60%左右(黄金分割)。一个普遍的经验是，如果项目人员不懂技术，项目时间可能是原计划的4/3-5/3(这还没有考虑资源可用率)。如果项目人员不懂技术，管理人员不懂管理，这个数字可能是2到3倍。现实就是这么严酷。这在很大程度上归功于项目经理。是的，我们真的不必责怪开发者，因为我们对资源可用性的判断完全违背了常识。八。变化的原则
也许有人问你，项目管理中不变的东西是什么？我可以告诉你，项目中不变的是“变”。不考虑项目中可能发生的变化是不可思议的。然而，当面对项目可能发生的变化所带来的项目风险时，我们的项目经理往往持回避的态度。经济学中众所周知的风险规避原理是对项目经理心理的有效描述。作为项目经理，要尽早预测可能出现的风险，做好风险储备。虽然风险准备金不能解决所有问题，但“预防胜于治疗”。可惜我们大多数人都没有这种意识。不然医院的生意可能不会这么红火，项目发展的道路可能不会这么坎坷。来自考试大学
九。操作标准原则
一个团队需要一定的规则来完成项目的开发。遗憾的是，目前在中国，“作坊式”仍然占主导地位，“我们符合国际CMM X规范(ISO某某规范)”被高举。没有多少项目团队会注意到这一点。我们曾经惊叹印度的高中生都能编程，而中国的非本科和硕士项目却无人问津。原因是没有制定规则，也没有粗糙的规则，就像牛皮的圣旨一样。好的代码模板和代码规范可以解决大部分人随心所欲写程序的问题。可惜没有多少项目经理有这个意识，也没有多少人愿意做这个基础工作。商业软件开发需要高超的开发技巧吗？不，那是一个迷惑的开发者的诡计。软件开发的美妙之处在于它的简单和标准化，而不在于它的独创性。因为缺乏操作标准，我们付出的代价是客户投诉和无休止的返工。另外，对于那些用正规思路骗人的项目组，如果你真的是你说的那样，也许你今天就不会这么乱了。
十、复用和组织变革原则——未来解决项目问题的方法
如何解决日益突出的项目工期、成本、质量等问题。是大多数项目经理最关心的问题。在实践中，加强复用，建立项目复用系统，实施组织变革是较好的途径之一。重用可以提高项目生产率，降低项目风险。通过复用，项目经理可以快速进入项目问题的定义，减少项目开发人员的工作量，尽可能解决项目的时间和资源过载问题。另一种方式是实施项目团队的组织变革(Moc)，精简项目管理组织，重新定义工作职责，制定灵活的项目工作流程，改善项目开发人员的沟通状态，提高项目人员的开发效率，努力营造良好的项目开发环境。只有这样，才能从根本上解决项目开发中的各种棘手问题。
结论:作为一个项目经理，仅仅理解和运用上述原则是不够的。要想深入掌握项目管理知识和技能，还必须深入学习项目管理的知识(建议见PMI《PMBOK》)、管理心理学、质量管理、组织变革、系统论等。，并在工作中不断总结和实践。只有这样，我们的项目经理看简历才不会脸红，才能在公司树立自己的管理权威，也才能有一个职业经理人的良好职业开端。