行业经验

        每天都有不计其数的新项目在互联网上线，每个人都想凭借自己超凡的智慧、绝妙的idea在互联网上淘一桶金。然而，每天又有不计其数的创业者败下阵来，看着一波波的后来者不断涌上来。如大浪淘沙，而每个人都想做留下来的金子。

        这其中，很多付出了超凡的努力和智慧零结而成的项目，死的都比较冤，或者未死的幸运者，伤得也很冤。如果各单位执行到位，本可以成功，或者本可以获取更多的价值。导致这种情况的原因，其实很早就出现了。总结了这么多项目，最核心的风险，都存在于团队的信息和认知的不对称上面。信息不对称可以让人谋利，这是永恒的道理。但这个是相对于团队外部的。如果团队内部的信息和认知的不对称，那这就不是一个好的团队，就很有可能把项目做死。

        项目失败，首先应该反思的是项目发起者(老板或职业经理人)。其实很多的失败，我们原本可以避免，只要我们遵循某些基本原则。而犯了某些错，可能就需要更大的成本来弥补，甚至于不能弥补，而直接消亡。

        下面，我将分析软件项目因为开发问题而致死的若干种死法，以及如何规避这些问题：

1、需求不明确

        需求不明确是软件项目中经常遇到的问题，其表现包括需求范围未界定、需求没有细化、需求表述不清晰、需求遗漏等多个方面。发起者最开始只有一个简单的idea，一个相对狭窄的需求范围。随着沟通的进行，会不断的去调整和补充这个范围。至于一些未曾考虑到的因素，往往是需要从专业的人那里获取的。即便如此，你也不可能把什么到考虑到位。你以为你已经把一切都跟团队交代清楚了，剩下的就是他们的事情了。直到项目上线的那一刻，你才发现有些部分完全偏离了最初的想法，而这时再调整可能为时已晚。

        这是比较早期的风险，却直接导致了后期的项目失败。在软件开发过程的各阶段，需求不明所造成的浪费是最大的，必须尽早解决，而且必须持续解决，不要想着万事大吉，否则就是做多错多，做到最后毫无意义。下面这些建议，也许有助于你从这个层面上降低风险：

（1）化整为零，分期迭代

        也许你想要造一艘航母，但以目前团队的实力、项目的进度，只能给你一艘小船。那么你应该从你的层面来合理规划，如何能够持续迭代，一步步交付可用产品模型，最终把航母造出来。不克制自己，不分阶段限定项目范围，单靠喊口号和人力的投入，就会有意想不到的潜在的巨大风险。按照精益生产的理念，敏捷开发的原则，化整为零，分期迭代，持续交付，这是对项目负责，也是最理性的开发方式。让需求的偏离尽早的暴露出来，尽早调整，让持续变更的需求，与项目的周期契合，不能说就成功了，但至少最大程度绕过了坑、淌过了暗流。

（2）信息同步，持续沟通

        你看到了全局，掌握了该有的信息，但是你的团队成员会像你一样吗？你应该尽早让他们获得必要的信息，持续进行沟通。认知盲区，会导致他们不能理解你的想法，最终做出来的产品偏离了初衷。经验丰富的成员，考虑更加周全，但你也不要仅仅寄希望于此，因为一块短板、一个纰漏，就可能满盘皆输。

（3）早期评审，定期回顾

        一定要参与早期的需求评审，确定项目的整体方向。不仅如此，你也需要定期的与团队一起回顾过往的需求，从整体上确认和保证逻辑的准确性。 

2、项目无法提前呈现

        即便明确了需求，项目发展到最后，依然可能出现偏离。直到上线那一天，发现用户界面丑陋不堪、功能缺失、核心需求错误，这种情况也是数不胜数的。

        一个最有效的方式，就是让项目尽早呈现。结合上文提到的持续迭代，其目标应该明确，让每一次迭代都能看到真实效果。

3、性能低下

        曾经有个朋友的项目在一波大力推广、用户数上来后，app使用卡顿，数据半天加载不出来，业务操作直接无法进行。于是不得不在客服群里各方安抚，通宵达旦的做补救工作，最终还是没有抓住那一波流量，白白损失了大量用户。更要命的是，因为并发问题，导致资金错误，原本应该有的漂亮的收益，转眼变成了尴尬的亏损。

        很多软件项目，由于先期设计不足，一段时间运作下来，性能翻车，导致不可用，直接造成损失或失败。为了避免这种风险，你需要这么做：

（1） 提前进行性能规划

        在系统设计之初，就应该做好性能规划，对可能出现性能问题的环节做到充足的估计。尤其是数据库和并发方面，虽然未必一开始就能做集群和分布式，但可以合理架构，一旦流量上来，能做到短时间内横向部署，通过增加机器或提高配置的方式，应对性能问题。

        如果软件架构设计不合理，优化就会需要大量的时间和精力，甚至伤筋动骨。在实际的生产环境中，市场怎么可能给你时间？

（2） 提前进行性能测试

        在合适的时间，提前做好性能测试，包括并发测试、压力测试等。需要一个明确的指标，什么样的架构和配置，应对什么量级的用户基数。如果不满足需要，还得有时间来进行调整。调整完再进行回归测试，避免调整引起了其他问题。

4、上线仓促

在项目实施过程中，系统切换上线环节最容易出纰漏。项目好不容易开发完成了，却在最后最后时刻功溃一匮。如果项目小，影响面窄倒不怎么重要；如果是影响面大的项目，则千万不可出现问题。在系统切换前，应充分考虑各种可能出现的问题，做好风险对策。

（1） 应急预案

面对各种不可预知的风险，要做好应急预案。正常运行的车站售票系统在春运、旅游黄金周，都会做好应急预案。新系统切换时，更应该做好应急预案。应急预案中应做好最坏的打算，售票系统不能正常工作时，准备手工票就是最坏的打算。

（2） 分步切换

为了减少风险的影响，可以做系统分步切换的方案。例如：售票系统在切换时，往往用新系统售预售票，或者是用新系统售长途车站，用旧系统暂时售短程票。待新系统运行稳定后，再全面切换到新系统。针对多个用户单位的系统切换，也可分单位进行。

（3） 交叉培训

新旧系统切换过程中，用户都存在适应过程。除了在切换前做好操作培训外，还要在新旧系统切换过程中做好交叉培训。让用户提前一些时间上班，让早班的用户在交班时培训中班的用户，中班的用户培训晚班的用户。做好交叉培训能够让系统平衡过渡。

5、缺少真实用户参与

软件的可用性包括软件的使用是不是高效、是否容易学习、是否容易记忆、是否令人愉快、是否不易出错等诸多因素。往往由于软件的可用性差，导致用户不满意，甚至被市场淘汰。在项目开发中应注意可用性问题，避免软件出现可用性方面的风险。

        总结

在信息系统集成项目中，风险是多种多样的，是无处不在的。在项目管理活动中，要积极面对风险，要培养。越早识别风险、越早管理风险，就越有可能规避风险，或者在风险发生时能够降低风险带来的影响。特别是在项目参与方多、涉及面广、影响面大、技术含量高的复杂项目，应加强风险管理。如果不主动驾驭风险，就会面临风险。