软件项目开发中的二八现象
在软件项目管理中，经常遇到这样的情况：进度到百分之九十后开始停滞，要花很长很长时间很大很大代价（甚至超过前百分之九十所花费的工时、工期）才能完成最后的百分之十。我把这种情况叫作：软件项目的百分之九十效应。
西汉·刘向《战国策·秦策五》：“诗云：‘行百里者半九十。’此言末路之难也。”
通俗地讲，做事情越接近成功越难，越要认真对待。很多人、团队做事情，开始的时候总是雄心壮志、信心十足，认为一切尽在掌握，可是随着时间的推进，各种问题出现，慢慢的就没有了动力，毅力也消磨殆尽，决心不经意间一去不回，到最后只盼早点结束，要么放弃要么草草收尾要么延期再延期。
在软件项目开发中，这种案例比比皆是。我自己也曾经遇到几次。
我总是在想，为什么会这样？为什么这最后一公里路程如此遥远以致难以逾越？
先来听听相关人员的抱怨：
有的人说，真不明白系统框架为什么设计成这样……
有的人说，压根儿就不该选择自己实现 http 协议，根本就是重新造轮子……
有的人说，给我的任务太多了，比任何其他人都多……
有的人说，搞不懂 UI 为什么这么丑陋，交互也糟透了，一点都不符合习惯……
有的人说，我卡在那个问题那里，动不了了……
测试人员说，为什么到快发布了才让我们测，根本不给我们测试预留时间……
还有测试人员说，开发太不象话了，自己根本不测……
项目经理咬牙切齿，你们这帮人，为什么不早说……
领导说，这么点儿小事儿都那啥啥，执行力忒成问题，效率极端低下……
客户在摇头……
其实如果能带着现在的问题、经验回到起点来看，我们会发现很多可以规避掉的弯路、陷阱、沼泽。
回过头来再看所谓的百分之九十效应。我这里有一个问题给大家：项目进度真的到了百分之九十（90%）吗？
其实我们可以换个问题，为什么越临近交付期问题越多？再换个说法，项目为什么老是延期？
让我们来看看软件项目进度延期的关键因素。
- 项目进度计划本身不合理
软件项目延期时，项目经理应当首先自问，项目计划安排是否合理？而项目进度计划安排是否合理，需要从以下几个方面来分析。
- 估算是否准确
估算是否准确是对项目进度计划安排影响最大的一个因素。
估算不准确的原因有很多，缺少经验丰富的估算专家和可参考的历史数据是最重要的两个方面，而这只能通过多个项目的积累或者某个项目的多个版本的积累才能得到改善，没有终南捷径。除此之外，还要考虑一些特殊因素，比如项目组有新成员得预留上手时间，又比如项目涉及到新技术需要预留学习时间……
- 关键资源和关键路径的安排是否合理
在项目进度计划安排上，我们首先要识别关键路径，对关键路径上的资源进行合理安排并进行保护（尽量减少关键资源上非关键任务的安排）。
另外我们在进度计划安排上应该适当安排 10% - 15% 的余量，这样在项目遇到突发事件，或项目风险转变为实际问题时候才能够有人员和时间进行处理。
- 项目中的资源是否充分利用
在一个项目开发过程中，有的人一直忙碌不停，哼着小曲“时间都去哪儿啦”；有的人是脉冲性的，一阵子忙一阵子闲；有的人则在唱“我的心在等待，永远在等待”。这说明项目中的人力资源往往不能充分利用起来，这样还会带来项目团队成员之间的不平衡从而进一步影响生产率。
对一个软件项目而言，需要保证项目成员的整体利用程度在 70% 以上，否则就应该考虑采用新的开发模式和生命周期模型。为了充分利用相关资源，项目应该尽可能地采用敏捷模型或迭代模型，规避对瀑布模型的使用。另外如有可能，还应当持续集成，让测试人员尽早开始工作以便尽早暴露问题。
- 团队的问题
我始终认为，找到合适的团队成员，是一个项目成功的关键。看过电影《十一罗汉》、《十二罗汉》吧，每个人都有他的价值，个人价值的最大化加上协同效应才能成事儿。人和团队的因素是对项目影响最大的因素，一切问题说到底都是人的问题。
软件项目中的程序猿从事的是创造性的工作或者通过螺旋重复进而产生创造性的工作，而非简单重复的劳动。我们必须承认项目中每个成员的价值，充分的尊重每个成员，让他发挥出自己的价值。惟其如此，才能保证项目的生产率。
那么在一个项目团队中，可能有哪些人员相关的因素会影响团队的生产率呢？
- 项目经理
兵熊熊一个，将熊熊一窝，好的项目经理可能占到项目成功的一半因素或者更多。好的项目经理应该具备哪些的条件呢？
-
- 勇于担当，有很强的责任心
- 领导能力
- 识人善断
- 技术上一专多能，有技术上的号召力和说服力
- 项目经验丰富，最好是直接的项目经验，最好有成功的经验也有失败的经验
- 有较强的沟通、组织技巧
其实优秀的项目经历还有很多很多特质，每个人都能说出一箩筐，这里不再赘述。
- 人员技能
干什么样的事儿需要什么样的人，很朴素的道理。
可是我们在开始一个项目的时候，往往并非如此。通常我们没有机会选择项目成员（除非为新项目组建新团队），而是在已有成员基础上接受新项目。那么这个时候就存在项目组成员技术能力与待开发项目所需技能不匹配的问题。但我们通常会假设项目组成员的技能都能达到要求，并在此前提下进行工作量估算，所以呢，失之毫厘谬以千里。
在开始一个新项目之前，应当对团队成员的技术能力进行一次评估，项目经理必须做到谁能干什么事儿能干到什么程度心中有数，要以此为基础来调配资源，张三什么时候干这件事，李四什么时候干那件事，赵六、王五，怎么衔接，都必须有谱才行。
如果项目经理认识到团队人员技能不足，那就要妥善安排。对于大家都欠缺的技能，统一培训并跟踪效果；对于个别技能不足的人员，应当给他预留自我学习时间或者安排师傅帮带，使其技能尽快达标；而对于新员工和他的人物，应该加强评审和检验，以免输出质量太差导致后期代价昂贵的返工。
- 责任心
假如我们以最大的恶意来揣测，很多时候做项目，多数项目成员是抱着完成任务的心态来工作的，责任心不强、敷衍了事。这样就会导致产出质量低下，带来大量返工，或者单独模块能 Run ，继承后给协作模块带来莫名问题引发大量扯皮及工作量浪费。
在这种情况下，公司或项目经理应当加强项目规范建设，加强项目的团队建设和集体荣誉感，让项目成员感觉到做的系统是他们自己的产品，而不是公司的项目，项目经理的项目，让项目成员有主人翁意识，采取各种措施，让项目成员对成就感有一定渴望。
- 沟通
好吧，我得说，有人的地方就有江湖。江湖得有江湖的规矩，项目组必须建立起有效的沟通渠道，使项目组成员能够快捷顺畅地进行沟通。如果项目组成员一周的时间有大半耗费在不必要的人际消耗上（张三和李四有抵触，王五和赵六互相较劲找茬，钱二麻子谁都不吝……，想想吧），项目经历必须及时分析和总结原因，必要时还要约谈相关成员以艺术的方式和稀泥。总而言之，一定要在最短的时间内，使用各种工具、手段（无所不用其极）地使交流双方或多方达成一致。
- 项目开发模式
前面说项目进度计划是否合理时，已经提到了项目开发模式和生命周期模型。好的模式可以提高项目组成员的利用率，提高团队生产率，为项目计划顺利实施奠定基础。软件开发行业这么多年出现了很多开发模式，各个都有其优点，要结合项目组的特点，妥善选择，行差踏错可就追悔莫及了。
- 技术路线选择
技术路线选择错了，南辕北辙，跑得越快离题越远。
前面我们提到项目经理在技术上要一专多能，知识面要足够宽，原因就在这里，项目经理要对技术路线有评估能力，要负责任。当然也不能搞独裁，应当团结所有成员尤其技术骨干共同选择，要尊重每个成员，大家都参与了才会有认同感，尽量不要给成员“上面强制推行”这种错觉（哪怕是强制推行也要做到不着痕迹）。
- 系统架构
定了技术路线，还要定系统架构。架构设计非常之重要，不仅仅要根据业务的功能性需求进行子系统、接口、组件等的设计和划分；同时架构设计还需要考虑系统的健壮性、可扩展性、性能、安全性、可维护性等非功能性需求。架构人员应该通过架构设计屏蔽整个系统的复杂性，向模块设计和开发人员提供一套简单、高效的开发规程和模式，这样才能够真正提高后续设计开发的效率和质量。
要设计一个成熟的架构，架构人员不仅仅要是技术方面的专家，也需要充分理解业务需求，这样才能够做出好的架构来。一定要给项目的总体设计和架构设计留足时间，架构不稳定就很难承重很难抗震，很快就会积重难返被迫重构或推倒重来。
- 风险管理
项目经理一定要有风险管理意识，对项目行进过程中可能出现的风险有清醒的认识，要提前采取应急措施。举个例子，如果前期没有分析出来某个核心成员会离职，那当项目进行到一半时该成员要走，项目组中既没有合适的替代成员又不能在短期内招募到合适的新成员，这样对项目的打击将会是致命的。
项目组最好形成一套应急预案来应对突发事件，使得意外的发生在情理之外预料之中，能够使用已经积累的各种策略、方法、工具和预备的资源余量进行跟踪处理。
- 需求变更
太阳底下没有新鲜事儿。对客户或需求人员来讲，变是唯一不变的真理。可是对于项目团队，频繁的、大范围的需求变更简直就是噩梦，新增功能不但会线性增加工作量而且往往会破坏已有架构最终导致项目不可避免的拥抱延期。如果到了项目后期，就更是噩梦中的噩梦了，有些开发人员砍人的心都会有。因此在项目管理中，一定要形成一套可行的需求管理机制（比如采取敏捷开发模型，一个冲刺之内不允许变更）来对需求变更进行有效的控制。
- 质量因素
乍看之下，时间和质量是项目中的两个互相矛盾的因素。我们经常为了赶进度而牺牲质量，或者为了保证质量而延期（当然有时以质量之名延期却没有保证质量）。
多数公司都有一套质量规范，交付出去的产品都要经过测试环节的验证以便尽可能少的发布有严重质量缺陷的产品。可是，可是，现实中经常出现项目后期测试问题太多，BUG 修改和回归测试等花费了大量的时间而导致项目的延迟，有时甚至不是一点点而是几倍于估算工期的延迟。
那么，怎样在时间和质量之间取得平衡呢？有几点可以参考：
- 采取合适的开发模型，比如敏捷和快速迭代，每个固定周期（2周或3周）交付可测试版本，测试人员及早介入
- 加强各阶段产出物的评审和 Review ，比如需求、UI 设计、架构设计、总体设计、接口设计、模块设计
- 开发人员引入单元测试，如果认为单元测试粒度过细或要求过高，可以变通，撰写针对输入输出、内在逻辑、接口使用的测试程序，测过才可以集成
- 持续集成，每周要进行 2 次或者更多次，开发人员要不断交付可用 BUILD ，相互之间交叉测试
- 先对外后对内，接口先行，将子系统之间、模块之间的依赖降低，避免开发人员之间的相互等待造成的空耗
简而言之一句话：尽可能的在项目早期发现问题。只要能达到这个目的，什么措施都行。