《把握好软件项目的管理原则》由会员分享，可在线阅读，更多相关《把握好软件项目的管理原则（4页珍藏版）》请在金锄头文库上搜索。
1、把握好软件项目的管理原则软件开发的残酷的现实告诉我们：没有规则的软件开发过程带来的只可能是无法预料的 结果。我们中的大多数项目管理人员在其个人简历中纷纷写到：拥有多年的丰富的项目 管理经验，但在实际开发中，丰富的管理经验变成了软件开发人员可怕的梦魇。一次 次的失败、一次次的返工，她所谓的项目管理经验只不过是再一次的游戏于无间（十八 层地狱）O 一次，在与不少项目管理者的交流中，大家纷纷提到的软件变更带来的可怕影 响。但是正如完整的法律体制不能制止犯罪，但没存完整的法律体制犯罪会更加犯獗- 样，频繁的软件变更固然可怕，但是没有一个完整的项tl管理对应机制，我们无法相像项 日最终会是一个什么样子。
2、此外还有一次，笔者在求职时，招聘公司的技术主管（40-50 岁左右），向我吹嘘公司按CMM4的过程规则来进行软件的开发和管理。殊不知，我一问 下面开发人员，她们在经历无数的加班后正在给已经完成的软件项目添加软件概要设计 书，这让我大吃一惊如此这样形式主义的公司，不呆也罢。记得一个格言曾经说过人类最愚蠢的行为在于忘记常识气另外一句较为相仿的格言则 是不知道历史的人必然会重蹈覆。作为项目管理来说亦为同样的道理。很可惜，我们中 的大多数管理者口 口声声软件工程，工作时用程序代替用户需求，极具政客的嘴脸。 其结果必然如目前媒体程序员生存状况所言，以开发人员在时间的牺牲为代价来换取项 目的结束，这是再为
3、普遍不过的现象，在此不再妾加评论。如何改善我们的软件开发管理，一条便捷之道便是尊重常识，尊重历史经验教训气在 软件项目管理中，有许多的原则和经验可以供我们借鉴。一、计划原则没有计划，你无从知道什么时候控制和变更。制定一个详尽的计划，以详细到开发人员 可以理解的程度为宜。计划能够告诉你什么时候应该做什么。没有计划，你无从知道自己 需要做什么。不少项目经理告诉组员需要做什么东西后扬长而去，丝毫没有一个相关任务 （活动）之间的说明。由于没有计划或是计划太粗糙、不切实际，很多项目1/3甚至1/2 的时间花在返工上面。因为计划中遗漏了某一项关键任务，项日就有可能宣告失败。试想 下，制定一个周密合理的计划
4、需要耗费这么多的时间吗？需要付出项目失败的代价吗？ 还有很多项1=1管理人员常常错误认为变化比计划快，但实际的情况是，由于没有计划， 你无法预测和估量变化给你的项廿所带来影响，你所面临的将会是比面条还难以理清?混 沌状态。此外，对于开发人员来说，目标导|nj （Objective Oriented）是充分调动其 工作积极性的最佳方法，每一个任务阶段的成果能够将员工的工作效率维持在一个较高的 水平。因为近期目标总是比远期日标来说更容易看到和达到。为此，制定一个计划吧，让 它符合目标导向（通过各个具体任务计划促使项kl总计划的达成）。二、Brooks 原则向一个已经滞后的项目添加人员，可能会使项k
5、l更加滞后。因为作为新加入的员工来 说，相关培训、环境熟悉和人员之间的沟通通路的增加，迫使项U的工作效率急剧下跌。 工作效率下降需要加班来进行弥补，但加班造成的疲劳会再次使工作效率降低。同时工作 成本却不断的向上攀升。不过就目前来说，项甘管理人员丝毫不会理会这一点，人多力 量大也许更能引人入胜。不少项管理人员抱怨到时间的急迫性，须知很多项目内时间的急迫性来自于项U管理人员不假思索和不基于常理的邀功表现，没有充分考虑的开发人 员能力的多样性所致。为此，正规的企业不得不耗费大量的加班费用于加班人员的津贴，同时亦要承担 违反劳动法的潜在法律危险。现在一种力不得已的做法是，假设项目开发人员之间的 任务
6、的关联性不是太大的情况下，采取两班倒或是三班倒的方法来保证时间的延续性和相 关开发人员的工作高效性。三、验收标准原则我们在进行某项任务，往往会为以何种结果为宜而感到困惑。不求质量的开发人员往往 凭据经验草草了事，追求完美的开发人员则在该项任务上耗费太多的精力，但此番耗费未 必针对该项任务，因而常常吃力不讨好。这是由于没有验收标准而导致的情景。因为没有 验收标准，你无法知道你要进行的任务需要一-个什么样的结果，需要达到什么样的质量标 准。在很多情况下，你的活动会与期望结果背道而驰，而此时的你还在沉醉于自己的辛勤 耕耘之中。作为项U经理来说，只有制定好每个任务的验收标准，才能够严格把好每一个 质量
7、关、同时了解项日的进度情况。四、默认无效原则你的项目成员理解和赞成项目的范围、目标和你所制定的项目策略吗？不少项目管理人 员认为沉默意味着同意气实际上我们或多或少都会陷入这样的一个思维误区。试想一 下，你作为职员或项甘开发人员时的沉默完全代表你赞成你的领导的意见吗？不见得，这 就是答案。这-点在项目沟通中极为重要，项日管理者切不可为沉默认为是同意，沉默在 很大的程度上说明项日开发人员还尚未弄清楚项目的范围、任务和目标。为此项目管理者 还需要同开发人员进行充分沟通，了解开发人员的想法。在对项目没有一个共同的一致的 理解的前提下，一个团队是不可能成功的。五、80-20原则80-20原则在软件开发和
8、项U管理方面有许多实例气其一便是我们在20%的项U要求 上耗费了 80%的时间。仔细分析一下，这些项目要求分为必须的非必须的，因此我们建议 是压缩非必须的部分或是暂时将其放在一边不必太重视。软件项目开发事实告诉我们，开 发人员在非必须的项目要求上耗费了太多的精力，用户的需求变更的大部分出现在最好 有这一部分，实际上用户并不看重这些需求（即使去除这些需求），而我们所做的，往 往是舍本求末。80-20原则的另外一个实例是我们项目中的20%的人员担当了 80%的项目任务（这样讲 在实际实施中-点都不过分）。考虑到开发人员能力的多样性，聪明的项目管理人员决不 会采取任务均分的愚蠢做法，因为就系统论的观
9、点来看，互补结构比对等结构要更稳定一 些。此外作为项目管理人员来说，了解属下员工的能力特点，将其放在合适的位置上，会 更有利于项目的顺利进行。很多管理人员常常抱怨属下能力问题，究其实质，往往是这些 项日管理人员未能发现开发人员潜能所在之处。她们看待问题往往以经验这样的思维定 势来做决定。导致的结果如系统论所言：由于抱怨的作用和反作用循环，结果是大家都 不欢而散。六、帕金森原则帕金森原则原是用于反映政府部门机构臃肿，效率低下的代名词。不过它在软件开发中 一样适用。没有时限限制的话，工作可能无限延期。在软件开发中，如果没有严格的时间 限制，开发人员往往比较懈怠。这是人的天性所决定的。千力不要指望奇
10、迹的发生一一 所有员工的思想觉悟异常崇高。作为项目管理者而言，此时应充分考虑到员工的工作效 率和项目变更带来的负面影响，制定合理的项U工期并鼓动开发人员尽快完成。七、时间分配原则在项日计划编制过程中，我们常常将资源可用率（人、设备）等设置为100%,殊不知 你曾想过，由于开发人员需要休息、吃饭、开会等，根本不可能把所有的时间放在项目开 发工作上，而且这还不考虑到开发人员的工作效率是否保持在一恒定水平上。所谓一天8 小时工时制实际上是徒右虚名。由于项bl管理人员的无知，不少开发人员被迫拼命加 班。结果依旧出现Brooks原则所出现问题。在实际开发中，开发员工的时间利用率能够 达到80%就巳经时很
11、不错的了，我个人比较倾向于60%左右（黄金分割点）。一个常用 的经验是如果项日人员不懂技术的话，项目时间可能是原计划（该计划没有考虑到资源可 用率）的4/3 5/3。如果项日人员不憧技术、管理人员不憧管理的话，这个数字可能是2 倍到3倍。现实就是这么严酷。这很大范围内归功于项目管理人员。是的，我们的确没 有必要责备开发人员，因为我们对资源可用率的判断完全违反常识。八、变化原则也许有人问过你，在项目管理中唯一不变的东西是什么？我可以告诉你，项目中唯一不 变的就是变化。在项目中不考虑可能发生的变化是不可思议的。不过在面对项目可能发 生变化而带来的项目风险时，我们的项目管理人员往往会怀有逃避的态度。
12、经济学里大名 鼎鼎的风险规避原则便是项1=1管理人员心理的有效描述。作为项目管理人员来说，应该及 早预测可能出现的风险，做好风险储备。虽然风险储备不能解决所仃的问题，但预防胜于 治疗。可惜的是我们绝大多数人没有这方面的意识，否则医院的生意未必如此红火，项 日开发之途未必如此坎坷。九、作业标准原则一个团队要完成项日的开发需要再一定的章法。很可惜，在国内目前仍然以作坊式为 主，高举我们符合国际CMM X规范（ISO某某规范）的环境下，未必有多少项目团队注 意到这一点。我们曾经惊叹印度的高中生都能编程序，而国内却非木科、硕士不收眼帘。 究其原因，在于没有开发章法或是章法粗糙，犹如牛皮圣旨一般。一个好
13、的代码模板和代 码规范能够解决大多数人编写程序随心所欲的问题，很可惜，没有多少项目管理人员有此 意识，也没有多少人愿意去做这项基础任务。业务软件开发需要高超的开发技巧吗？不需 要，那是故弄玄虚的开发人员的伎俩。软件开发的美在于其简洁性和规范性，不在于奇技 淫巧。因为缺乏作业标准，我们付出的代价是客户的抱怨和无休止的返工。此外，对于那 些以形式主意蒙人的项目团队来说，如果你实质如同你曰头所说那样，也许你就不会是今 天的这副狼狈相。十、复用和组织变革原则一解决项H问题的未来之路如何解决H益突出的项日工期、成木、质量等问题，这是大多数项甘管理者最为关心的 问题。从实践来看加强复用的力度，建立项1=1
14、复用体系和实施组织变革是效果较好的途径 之一。复用能够提高项1=1的生产率，降低项1=1风险。通过复用，项bl管理者能够快速的进 入项目问题定义之中，减少项目开发人员的工作量，从而尽可能的解决项目在时间、资源 方-面的过载问题。另外一条途径是实施项日团队的组织变革（Moc）,精简项目管理机 构、重新定义工作职责，制定柔性的项1工作流程，改善项日开发人员的沟通状况，提高 项目人员的开发效率，努力营造一个良好的项目开发环境。这样才能从根本上解决项日开 发的种种棘手问题。结论作为-个项目管理者来说，了解和运用上述原则是不够的，若要深入的掌握项目管理知 识和技巧，还必须深入学习项目管理（建议参看PMIPMBOK）、管理心理学、质量管理 学、组织变革、系统论等方面的知识，并在工作中不断的总结和实践。唯有如此，我们的 项目管理人员看自己个人简历时方不会觉得脸红，才能在公司中树立自己的管理权威性， 同样也才会有一 个良好的职业经理生涯的开端。
