200604240825565.html

软件工程的红包书

<P>　　正视这四个要素之间的平衡关系是软件用户、开发商、代理商成熟理智的表现，否则系统的成功就失去了一块最坚实的理念基础。 </P>
<P>　　企业实施IT系统的首要目标是要成功，而不是失败，企业可以容忍小的成功，但不一定容忍小的失败，所以需要真正理解上述四个要素的平衡关系，确保项目的成功。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 2高效原则 </P>
<P>　　在需求、资源、工期、质量四个要素中，很多的项目决策者是将进度放在首位的，现在市场的竞争越来越激烈，"产品早上市一天，就早挣一天钱，挣的就比花的多，所以一定要多挣"，基于这样一个理念，软件开发越来越追求开发效率，大家从技术、工具、管理上寻求更多更好的解决之道。 </P>
<P>　　基于高效的原则，对项目的管理需要从几个方面来考虑： <BR>　　要选择精英成员 <BR>　　目标要明确，范围要清楚 <BR>　　沟通要及时、充分 <BR>　　要在激励成员上下工夫 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 3分解原则 </P>
<P>　　"化繁为简，各个击破"是自古以来解决复杂问题的不二法门，对于软件项目来讲，可以将将大的项目划分成几个小项目来做，将周期长的项目化分成几个明确的阶段。 </P>
<P>　　项目越大对项目组的管理人员、开发人员的要求越高，参与的人员越多，需要协调沟通的渠道越多，周期越长，开发人员也容易疲劳，将大项目拆分成几个小项目，可以降低对项目管理人员的要求，减少项目的管理风险，而且能够充分地将项目管理的权力下放，充分调动人员的积极性，目标会比较具体明确，易于取得阶段性的成果，使开发人员有成就感。 </P>
<P>　　作者主管过的一个产品开发项目代号为SB，该项目前期投入了5人做需求，时间达3个多月，进入开发阶段后，投入了15人，时间达10个月之久，陆续进行了3次封闭开发，在此过程中经历了需求的裁剪、开发人员的变更、技术路线的调整，项目组成员的压力极大，大家疲惫不堪，产品上市时间拖期达4个月。项目完工后总结下来的很致命的一个教训就是应该将该项目拆成3个小的项目来做，进行阶段性版本化发布，以缓解市场上的压力，减少项目组成员的挫折感，提高大家的士气。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 4实时控制原则 </P>
<P>　　在一家大型的软件公司中，有一位很有个性的项目经理，该项目经理很少谈起什么管理理论，也未见其有什么明显的管理措施，但是他连续做成多个规模很大的软件项目，而且应用效果很好。作者一直很奇怪他为什么能做的如此成功，经过仔细观察，终于发现他的管理可以用"紧盯"2字来概括，即每天他都要仔细检查项目组每个成员的工作，从软件演示到内部的处理逻辑、数据结构等，一丝不苟，如果有问题，改不完是不能去休息的。正是在他这种简单的措施下，支撑他完成了很多大的项目，当然他也是相当的辛苦，通常都是在凌晨才去休息。我们并非要推崇这种做法，这种措施也有他的问题，但是，这种实践却说明了一个很朴实的道理：如果你没有更好的办法，就要辛苦一点，实时控制项目的进展，要将项目的进展情况完全的实时的置于你的控制之下。 </P>
<P>　　上述的方法中对项目经理的个人能力、牺牲精神要求是很高，我们需要有一种进行实时控制项目进度的机制，依靠一套规范的过程来保证实时监控项目的进度。如在微软的管理策略中强?quot;每日构建"，这确实是是一种不错的方法，即每天要进行一次系统的编译链接，通过编译链接来检查进度、检查接口、发现进展中的问题、大家互相鼓励互相监督。 </P>
<P>　　实时控制确保项目经理能够及时发现问题、解决问题，保证项目具有很高的可见度，保证项目的正常进展。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 5分类管理原则 </P>
<P>　　对于不同的软件项目其项目目标差别很大，项目规模也是不同的，应用领域是不同的，采用的技术路线差别也很大，因而，针对每个项目的不同特点，其管理的方法、管理的侧重点应该是不同的。就像古人讲的，"因材施教"，"对症下药"。对于小项目你肯定不能象管理大项目那样去做，对于产品开发类的项目，你也不可能象管理系统集成类的项目那样去做，项目经理需要根据项目的特点，制订不同的项目管理的方针政策。如，下表是作者为一家应用软件公司制订的项目管理的方针： </P>
<P>　　在该案例中，将项目分成了订单类项目与非订单类项目，非订单类项目是指由公司根据市场的需求开发一个标准产品的项目，而订单类是指针对某个具体的客户定制软件的项目，订单类的项目根据需要协调的资源的范围有划分成了公司级、部门级、个人级三类，非订单类根据估算的工作量的大小也分成了A、B、C三类，估算的工作量超过720人天的为A类，超过360人天的为B类，360人天以下的为C类。不同类的项目管理的侧重点是不同的，从立项手续的完备性、计划的严格层度、周报的完备层度、规范的严格层度、跟踪的实时性、是否进行阶段总结、是否核算项目成本、是否严格进行阶段评审等多个方面来考虑，以确保管理的可行性。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 6简单有效原则 </P>
<P>　　项目经理在进行项目管理的过程中，往往会得到开发人员这样的抱怨"太麻烦了，浪费时间，没有用处"，这是很普遍的一种现象。当然这样的抱怨要从2个方面来分析，一方面从开发人员本身可能存在不理解，或者逆反心理的情况，另一方面，项目经理也要反思：我所采取的管理措施是否简单有效？搞管理不是搞学术研究，没有完美的管理，只有有效的管理，而项目经理往往试图堵住所有的漏洞，解决所有的问题，恰恰是这种理想，会使项目的管理陷入一个误区，作茧自缚，最后无法实施有效的管理，导致项目的失败。 </P>
<P>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp; 7规模控制原则 </P>
<P>　　该原则是和上面提到的其他原则相配合使用的，即要控制项目组的规模，不要人数太多，人数多了，进行沟通的渠道就多了，管理的复杂度就高了，对项目经理的要求也就高了。在微软的<a href="javascript:if(confirm('http://www.itisedu.com/phrase/200604231607095.html  \n\nThis file was not retrieved by Teleport Pro, because it was unavailable, or its retrieval was aborted, or the project was stopped too soon.  \n\nDo you want to open it from the server?'))window.location='http://www.itisedu.com/phrase/200604231607095.html'" tppabs="http://www.itisedu.com/phrase/200604231607095.html" target="_new">MSF</a>中，有一个很明确的原则就是要控制项目组的人数不要超过10人，当然这不是绝对的，也和项目经理的水平有很大关系。但是人员"贵精而不贵多"，这是一个基本的原则，这和我们上面提到的高效原则、分解原则是相辅相成的。 <BR>&nbsp;<BR><STRONG>十四. 软件项目管理在管理思维中的空白</STRONG></P>
<P>　　空白1：为效益而实施项目管理<BR>　　<BR>　　为什么我们要实施项目管理，是为了提高项目的效益。这里所指的项目的效益是一个综合性的指标，包括低风险、高产出等。为此我们不难得出我们在实施项目管理应该掌握的度。即：引入项目管理后所产生的效益减去项目管理的成本后必须大于未引入项目管理时的效益。由于引入项目管理后所产生的效益与项目管理的复杂度（项目管理的成本）并非线性相关的，因此项目管理的复杂度必然存在一个最优值，这就是我们应该把握的度。也许上面的说法比较抽象。一个实际行之可效的判断项目管理的度规则就是：大家认可并且能够准确地理解和实施。拿美国项目管理专家James P Lewis的话说就是KISS原则（Keep it simple and stupid），拿物理学家爱因斯坦的话说就是：Keep it simple but not too simple.</P>
<P>　　空白2：考虑所处环境<BR>　　<BR>　　任何系统都是建立在一个具体的系统环境中的，一般情况下受上一级系统影响最为显著，这是系统论的观点。项目管理是企业管理的下属层次，因此在很大程度上项目管理的成功与否常常受企业管理的制度制约（比如说设备采购的批复等待会延误工期），这就是为什么常常会出现计划不如变化来的快的原因。因为我们在制定计划时根本就没有考虑自身和客户双方的企业管理的环境，所以我们的计划在实施过程中会受到企业管理环境因素的影响。我敢跟你打赌：在没有人事激励机制常常拖欠或故意克扣员工工资但获得CMM5认证的公司开发效率不会比一个没有实施项目管理的开发团队的效率高多少。因为恶劣的公司人事制度扼杀了开发人员的天才和积极性。因此，作为一个项目管理者，审视自身的项目所处的企业环境并做出准确的判断是非常有必要的。缺少良好的项目环境，项目管理者的心血常常白费。这往往是我们中的一些项目经理在不同的公司里项目管理表现大相径庭的原因。<BR>　　<BR>　　此外，正是基于企业环境这样一个观点，目前美国PMI，日本ENAA等提出了项目管理成熟度模型（OPM3和P2M），改变了传统PMBOK的缺陷（忽略外部因素和自身的灵活性）。有兴趣的项目管理者可以参看有关项目管理成熟度和企业管理方面（建议参看职业经理人方面）的资料。</P>
<P>　　空白3：合理评判软件项目管理<BR>　　<BR>　　我们总是把过多的项目失败归罪到项目经理的名头上。他们的角色常常是替罪羊而不是领导者，他们拥有的更多的是责任而绝非职权。实际上项目失败并非完全决定于项目管理，比如说<a href="javascript:if(confirm('http://www.itisedu.com/phrase/200603011147495.html  \n\nThis file was not retrieved by Teleport Pro, because it was unavailable, or its retrieval was aborted, or the project was stopped too soon.  \n\nDo you want to open it from the server?'))window.location='http://www.itisedu.com/phrase/200603011147495.html'" tppabs="http://www.itisedu.com/phrase/200603011147495.html" target="_new">信息系统</a>过低的报价。一个项目按时在预算范围内完成了而另外一个则没有按时完成，这不意味着第一个项目管理得比较好。因为前者可能是项目时间和成本宽松的项目而后者根本就是不可能完成的项目。前者项目管理的意义在于获得较高的项目效益而后者的意义在于避免更大的项目损失。很可惜，充满了浮躁的软件企业没有诸如此类的意识，一些项目在未开始前注定就是失败的，项目经理们一上手便被扣以一责任人的镣铐。因此，项目管理有无具体效果，需要合理地进行评判，单纯以出效益为上的观点未必有失偏颇。</P>
<P>　　空白4：心理学的必要性<BR>　　<BR>　　没有一个领域像软件项目管理中人的因素更为重要，在软件领域没有实现自动化之前，一切试图取代人的主要作用的机制都是收效甚微的。人的行为是心智活动的表现。开发人员的心理活动决定了其在开发的表现。合适的压力能够勾起开发人员的成功欲望但是过大的压力却直接影响着项目参与者的身心健康。特别是后者一直以来都未能引起软件开发界的重视。很多人曾经有过不明不白的辞职经历，在没有学习《管理心理学》之前，笔者对这些人的"过激"行为有时想想都觉得奇怪。作为一个软件项目管理者，不了解和掌握管理心理学，很难针对复杂多变的人的因素采取合理的应对措施，同时自身的心理健康也未必能够得到保证。为此笔者建议有条件的软件企业，可以通过聘用心理顾问来处理员工的心理问题，以此缓和由于工作压力而导致的员工之间矛盾冲突和项目坍塌。</P>
<P>　　空白5：尊重常识，系统性考虑问题<BR>　　<BR>　　这个观点笔者在《软件项目管理原则谈》已经重申过。就像不要指望人一秒钟跑二十米一样指望项目中有过多的奇迹出现。可惜我们中的大多项目管理者在进行项目管理时依然实施"大跃进"。我们的管理者都知道自然规律不可违抗性，但是却很少有人意识到一些社会规律的不可违抗性。他们总以为唯物的主观能动性能够替代实际，产生奇迹。加班被认为是解决资源匮乏的唯一途径，通过开发人员"无上"的生产力来达成项目的成功。很少有人会意识到加班造成的疲劳会再次使工作效率降低这一事实。这是一种缺乏常识和系统性思考问题的表现。诸如此类的表现还有"唯工具论"和"唯方法论"。<BR>　　<BR>　　实际上，项目管理涉及各个方方面面，一味提高某一方面作用而忽略该方面对其它方面的影响，并不能提高项目管理的层次和最终产出，这是制止我们的项目管理者走偏激（极端）立场的一剂良药，希望项目管理者们能有所意识。</P>
<P>　　空白6：学会思考<BR>　　<BR>　　项目管理不是拿来主义，需要项目管理者进行认真的思考。这就是为什么我们项目管理者中不乏PMP和IPMP但是项目却未能如愿以偿的原因。理论和实践的差距极大地挫伤项目管理者的积极性。"证书无用论"所持的观点其依据也在于此。理论是一种完美的抽象，而现实是各种条件的集合。我们的项目管理者在实践上往往生搬硬套而忽略其依存条件，这就是招聘项目经理"唯经验论"的来源。一位项目管理者跟我交流的时候提到无法使用挣值（Earned Value）的概念，原因是公司人事部和财务部不愿意出示员工的收入清单。我建议他将挣值换为挣时（Earned Time），以时间替代成本。从项目进度的意义上来看这两者其实是一致的，问题马上得到了解决。可惜的是我们的项目管理者往往未学会思考具体概念的真正含义之前并匆匆上驴，提着长枪去和风车做斗争去了（注：唐吉诃德）。</P>
<P>　　空白7：学会计划<BR>　　<BR>　　现实中我们往往用补救措施代替计划，其效果便如<a href="javascript:if(confirm('http://www.itisedu.com/phrase/200603111651085.html  \n\nThis file was not retrieved by Teleport Pro, because it was unavailable, or its retrieval was aborted, or the project was stopped too soon.  \n\nDo you want to open it from the server?'))window.location='http://www.itisedu.com/phrase/200603111651085.html'" tppabs="http://www.itisedu.com/phrase/200603111651085.html" target="_new">软件缺陷</a>的放大效应。在项目经理的招聘中，你听到的只是几个项目管理白痴问你项目出了什么问题应该怎样解决的提问，这些项目管理白痴在不断地做各种问题假设，而你必须根据假设采取各种符合这些项目管理白痴口味的回答。但是，作为项目管理的来说，项目管理的真正意义在于事先预防各种偏离项目目标的问题出现而不是在于解决问题。古话说得好"磨刀不误砍柴工"。你不能期望癌症有100％的治愈率，但是你可以通过合理的生活习惯和锻炼来防止癌症的出现。我们在进行项目管理时，首先应该考虑如何防止问题的出现，虽然它不能保证所有的问题（风险）都可以避免，但是通过计划，你将拥有更多问题（风险）应对储备，能够在问题出现时有备无患。一个只会在问题出现时考虑应对措施的项目经理只是一个失败的项目经理。其项目结果无异是把健康交给医生而不是自己。作为项目管理的定位来说，项目管理应该是"管理会计"的角色而不是"成本会计"的角色。<BR>　　<BR>　　最后，以某电影的台词来结束本文;人为什么犯病？简单的东西想复杂了，复杂的东西想简单了，人就会犯病"。拿这句台词来形容我们目前的项目管理状况一点也不为过。软件项目管理是一个从"自发"走向"自觉"的过程，也是一个从经验主义走向理性主义的过程。软件项目管理是一个主动的管理，而这一切，需要广大项目管理者的项目管理思维和积极实践。</FONT></P></div>
</body>
</html>