1.1. 司空见惯的一幕   
          
　　12月2日，又是一个平常的星期一，陈云飞踩着公司上班的点准时地坐在了自己的办公室，随手翻看着上周刚拿到的天翔TNX20产品定型验收报告。陈云飞不由得长舒一口气，“项目终于结束了”，但思绪却不由自主地回想起这9个月来的一幕幕。天翔TNX20是给通达电子公司完全重新开发的一款MP3机。原计划在国庆前就定型量产，但直到上周才完成，在原计划6个月的基础上足足推迟了3个月。期间，项目计划调整了三次，每次客户都抱怨连天，老板的脸色难看之极，项目组成员也抱怨一天到晚加班，自己也倍感身心疲惫，心力交瘁。作为项目经理，这几年来负责过公司很多重大项目的开发，按时完成的项目几乎没有。虽然老板也颇有微词，但始终没有指责过自己。一方面因为自己跟随老板多年，成绩颇多；另一方面，更重要的是，很多项目的延期责任不在自己。比如这次的TNX20项目，通达电子要求的功能太多，后来还是他们主动将一些次要功能去掉呢；因为工作强度太大，连续加班近3个月，项目组成员为此情绪很盛，和上面关系挺僵的，最后还是自己找老板深谈了一次，老板才答应让大家休息了两天……      
             
　　正想着，办公室门开了，老板王宇进来，一叠资料‘啪’的放在桌上，老板说：“老陈啊，这是上周刚签的单，你先看看，大概需要多长时间？”
                    
　　陈云飞拿起来飞快地浏览了一下，这是一款老产品的改进，增加了较多功能，客户——飞凌公司——要求3个月出样机，5个月定型，“王总，这么多要求时间可能不够啊。”
　　“不行。”王宇认真地说，“我原以为你会说3到4个月就搞完呢。合同已经签了，你必须在5个月内搞定它。飞凌要赶在五一节前上市，错过了五一，我们也不用做了。”   

               
　　陈云飞心里暗想，看来又是一个Mission  Impossible，但嘴上还是忍不住说，“这不可能啊，王总。现在承诺下来，到时实在要推迟了，客户那里也不好交待啊。”  
          
　　王宇迟疑了一下，语气松懈了一点，“老陈，不行啊，这个项目不能推迟啊，你先好好看看，要什么资源随时来找我，我一定全力会支持。”         

　　老板说完，迈着步走了，陈云飞却陷入了沉思，又是一个Deadline。该怎么办呢？ 
                     
　　上面一幕，对于很多老板和项目经理来说都司空见惯，都面临类似的问题：产品开发项目的Deadline已经确定的情况下，采取怎样的手段有助于保证项目目标达成呢？ 
                   
　　除面临这样的问题外，企业通常还面临哪些问题呢？ 
                    
　　大家常说：“客户需求又改变了”，“项目中唯一不变的就是变”，“客户总是很强势，他们提出的要求，我们没办法拒绝”。变是客观规律，项目组无法拒绝改变。那么，当这种变化发生时，项目组成员应该考虑哪些因素并据此制定应对措施？ 
                
　　公司内部已经有一套产品开发流程，但是不同的项目都走这个流程，非常繁琐，于是大家都不按照这个流程执行。这该怎么办？ 
               
　　…… 
               
　　公司管理层和项目经理无时无刻不面临着在项目中取舍的问题：又想做功能齐全、性能优异的产品，可又面临有限的时间、有限的资源、有限的成本。在这些方面应该如何权衡呢？为了解决上面这些问题，我们先来看看项目管理面临哪些方面的平衡。 
                        
　　1.2. 平衡的要素
　　1.2.1.  项目干系人要求与期望的平衡 
根据美国项目管理协会PMI的定义：项目管理就是把知识、技能、工具和技术应用到项目活动中去，以满足或超过项目干系人的要求和期望。项目干系人，俗称项目利益相关人，系指能够影响项目执行好坏或者被项目的执行好坏所影响的人。因此，客户、产品与服务的最终用户、公司管理高层、部门经理、项目经理、项目团队成员，甚至相关人员的家庭成员等等都是项目干系人。面对如此众多的项目干系人，项目经理作为项目的第一责任人，应该识别出对项目具有重大影响的项目干系人，并了解他们关于该项目的期望以便在不同期望之间进行平衡。 
              

          
　　正如上面三角形所示，项目经理位于其中，正所谓“左右做人难”。让我们来看看每个项目干系人对于项目的期望如何。 
             
　　通常，客户或者产品的最终使用者，其终极希望是项目能够为他们带来物美价廉的产品，意即性价比最高的产品，而非单一的功能最强或者价格最便宜。                  
　　而管理高层作为该项目的投资方，当然希望最高的利润或者利润率，而非成本最低。 
                  
　　项目成员这个纬度，应首先分析一下有哪些参与者。技术开发人员毫无疑问是其中一员。站在产品能够最终交付给客户的角度来看，采购人员在其中，因为他们可能需要开发新的物料与模具，需要开发新的供应商甚至新的供应链体系；市场/业务人员在其中，因为他们需要为新的产品开发市场推广策略、新的销售渠道；生产人员也不可或缺（单纯的软件企业不涉及该领域），因为他们需要为新产品开发新的工艺和工装、最终要把产品加工装配出来；客服人员也不能置身事外，一旦产品卖给了客户，他们就必然需要售后跟进；其他人员如财务、质量保证人员也有其责任，如核算研发成本与收益，进行质量保证与监控的工作。看来要开发一款能在市场取得成功的产品，离不开这些人员的参与。因此，需要将他们集合在一起，构建协同的项目团队，他们则是项目成员。 
           
　　现在，暂且将这些项目成员最原始的期望——获得满意的新酬——放在一旁，我们来看看，他们对于特定项目还有何期望？ 
                     
　　技术开发人员作为项目组最核心的参与者，他们最希望从完成项目的过程中掌握新的技术，因此他们通常愿意尝试新的解决方案，应用新的开发工具，选择新的芯片。这种心理可以从技术人员都不喜欢从事技术维护工作可见一斑。毫无疑问，由于选择了新的实现手段，技术开发人员的期望和客户与管理高层的期望在某种程度上必然存在冲突。笔者的一个客户，某项目里面，一名开发人员在开发过程中擅自应用了从网络上下载的未经证实可靠的开发工具，导致产品在发布后客户使用时才发现问题，导致大批客户退货。 
                       
　　采购人员作为联结供应商与项目团队的接口，他们最大的期望是什么呢？笔者接触过很多的研发性企业，采购人员普遍反映：技术人员在开始新产品时，很少考虑对零部件的重用与共享，对于新的零器件的选择随意，既不从优选器件列表里面选择，也对优选供应商列表视而不见。一旦对此发生争执，技术人员往往用客户来压人“不用这种器件就无法满足客户的要求”。所以我们经常会见到公司螺钉型号有200多种，线材型号多大500种，供应商数目也是级数增长。还有的企业，早期开发过程中，采购人员几乎被蒙在鼓里，要用到的器件居然由技术人员自己到电子市场去“淘”。直到即将小批量试产时，采购才参与进来，要么发现这个器件的采购周期很长，要么发现这个器件可能供应商相当难确定。这种现象并不鲜见，看来采购人员很关心新产品开发中的可采购性问题。 
                        
　　与之类似，生产人员可不希望接受外观漂亮但很难加工装配的产品。即便能够加工组装，但生产效率会降低。不过销售人员却希望外观更漂亮更富吸引力，希望产品能够尽量吸引客户眼球以降低推销难度。品质保证人员希望开发团队成员最好按照公司的产品开发流程工作，而开发人员却会说流程会降低效率。 
                        
　　可见，矛盾在这些项目干系人之间始终存在。项目经理作为项目的责任人，则承担了识别和管理他们期望的重任。 
                
　　1.2.2. 时间、成本、质量、范围之间的平衡 
                        
　　识别出项目干系人后，项目经理（甚至项目团队）应了解项目干系人在范围（Scope）、时间（Time）、成本（Cost）、质量（Quality）等方面的期望。这就是通常所说的项目约束三角形（如右图）。这四个方面代表着项目管理的核心内容。 
     

                   
　　项目管理是目标管理方法。一般，项目目标是通过明确项目的起止时间、项目成本和要达到的质量要求来界定。因此，QCT构成了项目的约束边界，S则构成了项目需要满足的功能要求，也就是产品与服务的需求。如果产品实现的功能点越多（三角形面积越大），所耗费的时间则越长，投入成本也越高。而质量会如何变化呢？俗话说“做得越多错的越多”。一般而言，质量会随着产品功能的增强而下降。 
假设客户的功能性需求S保持一定，QCT会如何变化呢？如下图所示，为了达到较高质量目标，势必进行更多的测试与评审等质量控制活动，耗费更长的时间和更多的开发成本（投入市场后的维护支持成本会降低，客户总体拥有成本TCO——Total Cost of Ownership会降低）；反之亦然。


 
          

              
　　因此，QCTS在成为项目经理开展工作的约束的同时，也成为其在面对问题时，需要考虑的四个方面，甚至成为与相关干系人谈判并取得平衡的手段。 
                       
　　笔者曾亲身参与过这样一个项目：某移动运营商为了在5月17日国际电信日推出一种移动增值服务，向A、B两家公司发出招标邀请。招标邀请发出时已经是3月中旬左右。这对于AB公司来说，几乎又是一个Mission Impossible。AB两家公司毫无例外都想到了增加人手和加班加点的方式来确保按时完成。但人手问题对于哪一家研发企业来说不是捉襟见肘，即便即可启动招聘工作，也“远水不解近渴”。看来依靠人海战术缩短开发时间行不通；加班加点也同样，试问有几个研发企业的技术人员不经常加班的？ 
                  
　　经过三天招投标双方的沟通，运营商选择了A公司。且来看看A公司给出的方案： 
                        
　　A公司首先分析运营商在该项目上最关注什么？时间，毫无疑问是时间。运营商无论如何无法承受在5月17日推不出新服务的结果，因此才会用时间来“压”投标方。既然如此，A公司认为在QCS三个方面应该有谈判的余地。 
                        
　　于是，A公司向运营商提出了两个要求： 
                       
　　首先，减少产品的需求。通过对产品进行分析，发现该产品的最终使用者包括两部分人员：运营商内部人员——内部用户、运营商的客户——终端用户。因此A公司提出在5月17日前确保终端用户的使用功能完全实现，内部用户的需求按照卡诺模型1进行优先级排序，在5月17日前实现基本功能。 
                        
　　其次，考虑到时间紧迫，要求降低验收标准。在验收测试时，软件缺陷密度由千分之二降低为千分之五；产品上线一次成功率100%降低为90%。A公司给出的方案是：减少部分单元/单板的测试工作，但同时提出，在保持产品级技术评审的基础之上，增加部分关键模块的专项评审，并邀请客户参加。
                       
　　以上两点足以保证A公司在5.17完成运营商的要求。这似乎就OK了？ 
                       
　　A公司可不这样认为，还提出了补充方案：在5.17正式投入运营之后，一个月内，将为运营商实现前期未完成的功能，并且提高产品质量到最初的要求（千分之二，100%）。 
                        
　　面对如此全面的方案，该运营商无法拒绝，欣然与A公司签订了合同。顺便提一句，运营商还为之后一个月的工作买单了。多好的方案！ 
                     
　　笔者现正从事咨询行业，也接触了很多为电信运营商提供产品与服务的企业。每每谈起双方的合作，这些企业都满肚子怨气“他们（指电信运营商）太强势了。我们为了生存被迫接受一些不合理的要求”。是这样吗？ 
1.2.3. 人、过程、技术与工具之间的平衡 
                   
　　企业任一方面的管理能力都依赖于三种要素的有效组合：人（People）、过程（Process）、技术与工具（Technology and Tools）。一个企业或者一个项目团队的项目管理能力也不例外。 
   

 　　人、过程、技术与工具三个方面相互制约。这点很容易从企业发展过程得到印证。当一家新公司成立时，人员较少，公司的初创人员几乎都是各方面的专家，分别具备市场、技术、管理等方面的知识和技能，并承担各自领域内的责任，因此即便没有统一规范的过程，也不妨碍公司的发展壮大。但是随着企业规模的增长、业务形态的日渐复杂、人员数量的快速增加、人员的积极性主动性相较成立之初却下降很快3、技能水平也参差不齐，如果缺乏规范的过程，仅依靠不断地犯错误去获取经验并成长，企业运营成本实在太高。因此，企业一般会在这个阶段构建自己的业务流程，通过提升组织成长速度来支撑快速提高的业务成长速度。 
                   
　　项目运作与之类似。
                        

　　当项目组成员有丰富的经验时，产品开发的流程可以相对较粗，一般可在节点处进行控制，里程碑的设置也可适当减少；反之，当项目成员缺乏相应的经验时，项目经理无疑应考虑增加更多的控制手段（如子评审），以避免成员在错误的路线上溜得太远。当面对不同个性、不同技能、不同专业的项目成员和其他项目干系人时，项目经理采用的管理和沟通手段也截然不同。比如：要说服老员工和新员工加班，项目经理付出的努力也不同，加班的效果也会不同。 
                       
　　当选择恰当的工具作为管理手段时，项目经理对人和过程的关注程度也可随之减少。例如，项目组采用配置管理工具作为开发文档的版本和基线管理工具时，项目经理对于流程中要求的文档的管理就可以交由该系统完成；又比如，如果采用IT化的评审流程，当每次进行评审时，项目经理仅需重点关注评审的对象，而可以将评审过程的监控交由系统，或者授权项目助理完成。可见工具的运用，对于项目经理的管理有很大的促进作用。 

　　1.3. 平衡要素在实际中的应用 
                     

　　从上面可以看出，良好的项目管理就是在项目干系人要求与期望之间平衡；在时间、成本、质量、范围之间平衡；在人、过程、技术与工具之间平衡。依赖于这些平衡的要素，当面对项目中出现的问题时，项目经理就如同掌握了项目管理的“点金棒”，拥有了提出有效解决方案的利器。 

                        
　　下面我们就以开篇所展示的场景为例，来看看如何应用项目管理平衡之道来解决项目中的常见问题之一：在项目时间目标已经确定的情况下如何采取行动来帮助时间目标达成？   
                                                  
　　1、项目成员加班赶工                         
　　毫无疑问，这是企业和项目经理采用的最普遍的方法。这也几乎成为他们的唯一方法。殊不知，加班赶工能够争取时间，但同样危害多多，特别是长期超负荷加班。据统计，研发人员长期加班超过两周以上，研发士气低落，研发效率将下降40-50%。因此有不少高效企业，面临必须加班的时刻，也不允许长期加班，因为得不偿失。甚至有企业专门拨款作为项目运作费，要求项目经理在加班过程中，带领项目成员出去Happy，正所谓有张有弛。长期加班将给项目质量带来重大影响。毫无疑问，长期加班传递着一种信号：时间第一。而质量如何得到保证呢？原来是依靠后期的测试、修改、再测试、再修改来保证。正所谓：没时间一次把事情做正确，却有时间不断的返工。 
                        
　　因此对于加班的应用，应考虑“度”。 
                     
　　2、增加项目成员 
                     
　　加班不是唯一手段，那我们增加人手。这又成了企业想要的灵丹妙药。能行吗？

首先，在研发型企业里，人手始终紧张。一个企业人力资源经理和研发部经理对话为我们提供了佐证： 
                      
　　HR经理来到研发经理办公室：“王经理，年底了，明年你这边工作规划怎样？需要增加多少人，我们好开始招聘了？” 
                        
　　研发经理说“明年的研发任务很重，有好几款新产品要开发，至少需要增加十个人。” 
                     
　　HR经理，“好，我们会马上启动招聘工作。”转身离开了。 http://bbs.mypm.net
                    
　　三个月后，两人的一场新的对话。 
                       
　　HR经理心情畅快的再次来到研发经理的办公室：“老王，怎么样，现在人数够了吧？” 
                      
　　哪知，研发经理一脸郁闷，“哪够啊，现在新项目都上来了，还要有人做售后支持，昨天又派两个去杭州了。看能不能再帮我们招十个人来。” 
                        
　　HR经理沉思了一下，“行，那我们再去招。” 

　　这样的场景，每季度或者半年都回重演一次。 
                 
　　真的是缺乏人员吗？还是研发效率有待提高？ 
                       
　　无论如何，这至少说明了一种常态：在研发型企业里，人员“短缺”是正常，人员充裕才是“不正常”。 
                        
　　因此，一旦项目时间压力凸显，项目经理就想通过增加人手的方法来解决时间问题，但这只是美好的愿望，而非可以常用的方法。 
                 
　　况且《人月神话》4告诉我们，1人100个月完成的项目，不是100个人1个月就可以完成。况且研发工作有其内在规律，比如需求完成才可以开始设计与开发。因此一味增加人员于事无补。 
                     
　　3、需求平衡 
                    
　　当我们在人手和加班两方面进退两难的时候，还有其他可以采取的方法来帮助我们达成项目时间目标吗？ 
前文提到的A公司为我们树立了很好的榜样，通过需求优先级排序，先完成高优先级需求来确保时间目标达成。只不过，当真要如A公司一样删减需求时，几乎所有的项目经理都会像霜打过的茄子，斩钉截铁地说“客户是不会同意的！”。 
                        
　　为什么我们要画地为牢呢？ 
                      
　　当时间目标成为项目最重要约束的时候，通过平衡需求可以助一臂之力。只不过，客户决不会简单地同意删减需求。这时可采用卡诺模型来帮助我们说服我们“顽固的”客户。 
                       
　　卡诺模型是一种需求优先级分析方法。它将客户需求分为三类：基本型需求、期望型需求、兴奋性需求。                          
  

                      
　　基本型需求代表着产品的必备功能，是不言而明的功能。比如手机必须能够打电话，汽车必须能开动，电视机必须能够播放电视信号等等。试想，有谁去买手机时会问售货员“能打电话吗？能发短信吗？”。但是，如果售货员告诉你这种手机不能发短消息，你听了肯定想“这手机也太落伍了吧？”如果他/她再告诉你还不能打电话，你一定扭头就走了。可见当产品具备了这些不言而明的功能，客户并不会因此而满意；相反，一旦产品不具备这些功能，客户则肯定不满意。 
                       
　　兴奋性需求则完全相反。如果产品满足了这类型需求，客户的满意程度会因此提高；如果产品不满足这些需求，客户也会觉得很正常，不会因此而不满意。

                        
　　我曾给比亚迪进行过多次产品开发管理或项目管理的培训。有一次，他们派车来接我，我一坐上车就发现车内后视镜的左上角有一个小物体。仔细一看，原来是一个指北针，当时我这个消费者就感觉有些“激动”。司机告诉我，方便现在的自驾游一族啊！看来提高客户的满意度，也可以从小处做眼。 
                      
　　曾几何时，洗衣机也逐渐步入农民朋友的生活中。在西南地区出产红薯，农民朋友的洗衣机不仅要洗衣服，还用来洗红薯等农作物，但由于“洗衣机不是为洗红薯而发明的”，因此洗衣机排水管被藤蔓泥巴阻塞就成了常事。据说国内某知名家电厂商为此专门开发了针对农村市场的可以洗红薯土豆的洗衣机。这难道不是让农民朋友兴奋的功能吗？ 
                     
　　期望型需求则成了产品开发商的竞争要地。这是区分产品优秀与否的重要部分。产品满足期望型需要越多，客户的满意度越高；满足得越少，客户的满意度越低。几乎成线性相关。比如到电器商城买手机，销售人员对你说“这款手机可以听MP3、MP4、可以上网收发邮件、可以炒股、照相等等”，你的感觉如何？一定是觉得功能强大；反之，如果告诉你这也不能那也不行，你一定会觉得不太满意。 
                        
　　而且，这三种需求还可以转化。随着时代进步，以前的兴奋型会转化为期望型，甚至成为必需满足的要求。因此，在分析客户需求的优先级时，因考虑时间要素。 
                      
　　可见，当项目面临时间压力时，需求排序可以成为缩短时间进度的重要手段。也只有进行有效的需求排序，客户也才可能赞同删除部分低优先级需求来确保时间目标达成。 
                      
　　4、质量平衡 
                    
　　正如前面的需求平衡一样，质量平衡也可成为项目经理在时间压力下的手段之一。不过，追求产品的高质量是任何企业的根本责任，希望这不会成为项目组开发低质量产品的借口。 
                       
　　5、外包 
外包正成为时下研发领域时髦的字眼。外包对于缩短开发周期效果显著，因为外包是专业分工的结果。不过外包也有缺点，企业在选择将部分工作外包给外部供应商时应注意。 
                       
　　首先，外包一定会发生利润转移，因为外包服务提供商本身也需要赚钱。 
                    
　　其次，外包管理是一个难题。如果管理不好，可能带来更大的时间延迟。因为沟通成本增加，缺乏过程中监控，特别是外包供应商提供的组件/部件如何与自己的产品有效快速衔接。这些都导致外包结果难于预料、风险增加。 
                     
　　另外，有些企业是因为自己在某领域内缺乏能力和人才，所以才选择外包。这也必然导致在公司内部无法形成自主开发能力。 
                      
　　所以，企业在选择外包来缩短开发周期时应慎重。 
                        
　　6、流程裁剪 
                 
　　企业普遍号称自己公司内部有流程，特别是大多数通过ISO9000认证的企业。只不过，有多少企业会严格按照该流程来执行呢？笔者在对企业进行调研时发现，这些公司的流程基本就是“摆设”。为何会这样呢？除了因为公司没有严格要求、有要求但没有QA5、员工未接受过流程培训、流程本身不合理之外，员工反映较多的是：“这个流程太麻烦，我们的产品/项目开发周期大部分都很短。按照那个流程，我们肯定没办法完成，……。” 
                       
　　员工们说得对，现在的业务模式、产品开发类型多种多样，怎么可能会有一个“包打天下”的流程呢？现在很多企业的业务模式既有OBM（自主品牌制造商）、又有ODM（原始设计制造商）、OEM（原始设备制造商）业务；产品开发类型既有全新产品开发、衍生/改进产品、Costdown产品、特定规格改变类型等等；还有多种多样的产品线。一个流程当然不能适应各种不同情况。因此，为了适应不同的开发型态，有些企业又走上了另一个极端，那就是针对不同的开发型态建立不同的流程。殊不知，这样做建立、维护、优化这些流程的成本有多高？更为重要的是，公司员工可能会面临今天执行这个流程明天执行那个流程的窘境，开发效率必然下降。 
                        
　　面对多样的开发型态，最好的办法就是在公司层面建立标准的产品开发流程和针对不同开发型态建立基于标准流程的流程裁剪规范。这样的话，开发项目组选择流程就有了统一的原则与标准，可以做到在“规范与效率”、“质量与风险”之间的有效平衡。 
                      
　　特别是当项目Deadline成为一个强约束时，流程裁剪是一个非常好的有助于时间目标达成的途径。流程裁剪规范为项目组提供了裁剪的原则和标准，避免了随意的删减。比如，某一特定项目为了赶进度，决定降低测试覆盖度以节约时间。但是减少测试工作将导致产品质量无法得到保证，因此项目组应该增加更多的子评审活动以便发现更多的潜在问题，避免因为减少了测试而带来产品质量的下降。 
                     
　　这才是裁剪，而非裁减！ 
                  
　　7、流程的异步并行 
                    
　　当遇到项目时间压力很大时，可以将以前串行的活动改为异步并行，将有效缩短产品/项目的开发周期。 
  

                 
　　很多情况下，研发团队内部会有明确的分工，有人负责硬件，有人负责软件、有人负责采购、有人负责市场。这些不同专业领域内的人并行工作，将大大缩短产品交付/上市的周期。 

那么在技术领域内来看，该如何异步并行呢？这首先要求项目团队能够将产品/项目进行恰当的分解。如上图所示，如果能够将产品分解为三个部分组件A、组件B、组件C，那么就可以首先完成组件A的需求分析，然后同时开始组件B的需求分析和组件A的设计工作，依次类推。 
                     
　　在应用这种方法进行异步并行时，应注意以下几点： 
                    
　　首先，产品应能够分解为更小的组件/子系统，并且这些组件/子系统必须相对独立，相互之间的影响较小。如果相互关系紧密，可能出现严重的返工事件。比如在对组件C进行需求分析的时候，才发现组件A的需求由于C的影响需要更改，这势必导致组件A的设计和实现工作重新来过。因此为了避免这种“欲速则不达”的情况出现，首先需要考虑的就是组件之间是否相互影响。如果相互影响则需要首先界定它们是如何相互影响的，然后明确之间的接口关系，然后再实施异步并行。 
                     
　　另外，异步并行需要投入更多的人力资源，以便同时开展工作。 
                   
　　8、先分析再设计后实现的开发方式——终极手段 
                        
　　产品开发是具有本质规律的，这些规律不应该被打破。无数的经验教训和数据告诉我们，产品开发在总体上应该遵循“先分析、再设计、后开发”的过程。这是一种“谋定而后动”的开发模式，笔者称之为产品开发中这“纸上谈兵”。 
                  

    
　　上图说明这一点。H公司4年来产品开发周期显著下降。为什么会又这样的效果呢？从图上可以看出，最大的差别就在于概念阶段与计划阶段所占整个开发周期的比例显著增加。在99年，H公司的产品开发项目普遍很快就进入开发阶段6，这样做大家都能够很快看到了成型的产品，似乎就可以早一点“开庆功宴”。但是可以预料的是后期阶段问题百出，只能依赖于不断地返工来查缺补漏，时间当然也被一点一点地耗尽。正所谓“没有时间一次把事情做正确，却有时间不断的返工啊！”。 
                       

　　显然，I公司采取了与H公司99年完全不同的策略，它的概念阶段——明确产品包需求——和计划阶段——明确产品的总体设计方案和产品设计规格——几乎占了整个开发周期的40-60%，这反而是一种“磨刀不误砍柴功”的做法。

　　上面这八个手段只是基于项目管理的三个平衡三角形所演化出来的应对Deadline的部分方法。但是从这些方法可以看出，当项目面临时间压力时，可以采取的措施是多种多样的，而不仅仅是我们凭直觉采用的加人和加班的方法那么简单。 
                
　　三个平衡三角形不仅点明了项目管理的精髓，也同时为我们提供了很好的解决问题的思考出发点，帮助我们在面对项目困境时能够全面地思考和权衡，以找到最好的问题解决之道。