为什么就算大家很努力，项目还是失败了？

年前我曾经参与的一个数据采集与监控项目，正当大伙废寝忘食、没日没夜地加班改程序的时候，从现场传过来一个悲伤的消息：客户决定终止项目，并另选其他厂商来实施。

项目组连续数月的奋斗，就此宣告彻底的失败，用户最终放弃了给我们救赎的机会。

当时实施的情况大概是这样的。一开始项目执行顺利，系统也顺利部署到用户现场。随后坏消息接踵而至：先是用户发现功能和实际需求出入太大，要求重新开发，几天后随后系统崩溃，不仅自己崩溃了，还把好好的IT系统拖垮了。随后便陷入了一个循环：我们虽然很努力不停地修改，而客户始终不满意，就这样持续了大约一个月，便出现了开篇的画面。

造成这样的局面，难道是团队技术和能力的缺陷？

当时我们的团队大约有10人左右，无论从技术、管理角度来看都是一个不会太差的团队：6个985背景，3个研究生，虽然部分人刚毕业不到1年，但也有两位工作超过20年的技术大牛。

而团队中的核心人物，我们项目组老板是一位集科研、售前咨询身份的大佬，他在政府口径的项目申报，方案策划方面有极强的背景，每年可以拿到数千万的项目。

除了技术之外，还有更重要的原因。

1.急于求成，需求未作详细分解

项目组开发的小伙伴至始至终都在这样的状态下工作：我要开发的这套系统功能、流程、交互、UI究竟是什么？

当时，项目组对系统做了一个概要设计，粗略地表达的系统的面貌。按正常流程，在大家认同了概要设计后，就需要进入详细设计环节。一切看起来都很正常。

但是老板为了“又快又好”地交付系统，做出了一个决定：概要设计完就可以开发了，不清楚的地方开发人员自己看着办就好，“我相信你们”。

于是，大家就进入了这样一种状态：开发人员不知道具体分析方法是什么，在数据库实现分析还是在后台实现分析，不知道功能组件如何布局，操作流程如何。

无奈只有按照自己的想法解决自己负责的模块。而之前做整体设计和规划的人被抽调到其他项目中了，也无权对项目进行把控。

然后场面就失控了：不同的人做的界面风格不一，后台也不一致，有的在数据库做分析，有的在后台做分析，东拼西凑出来的系统简直惨不忍睹。

随后开发人员自发推举一位“德高望重”的同事统一了一下界面风格，虽然功能依然极不稳定，但至少看起来像那么回事了。

团队忽视了设计和规划环节的重要性，急于求成，冒进地略过详细设计环节，弱化了项目管理职能，使开发人员失去了统一的、系统的、有价值的开发需求，是导致项目失败的重要原因。

2.流程混乱，责任不清晰

前面提到冒进地略过详细设计阶段，只是开发流程混乱的一个方面。整个项目的执行和和管理始终都处于一种失控的状态。

需求环节，老板是带着先入为主的想法入场的，在还没和客户沟通时，就在路上给我说了系统的规划和功能，“他们想做的一定是这个。”

测试环节，开发人员自己开发自己测，没有测试大纲，发现一个问题解决一个问题。同时老板也催得紧，十来个人花了一周时间搞了个“劳动竞赛”，凑活凑活也就交付了。

管理方面，没有指定项目经理，调研、实施、售后每次去的都是不同的面孔，每次去都把需求重新问一遍，每个人都试图按照自己的想法对项目施加影响。

缺乏合理的流程导致了项目团队之间无法充分配合，将大量的时间和精力浪费在毫无意义的功能迭代上，并且也没有达到预期的效果，而缺乏明确的分工和责任更进一步加重了这个现象，最终项目的成本、周期、质量三个核心指标均得到出灾难般的结果。

3.模糊的职责和权限，人员的能力没有得到最大程度发挥

你们是否发现一个问题：项目组不是有两位工作超过20年的技术大牛吗？有他们镇场子为什么还会出现如此灾难般的结果？

答案是：老板没有赋予他们明确的权限和职责，例如架构师什么的，只是要求他们尽量参与，尽量帮助年轻人。

没有明确的权限和职责，他们便不会主动对项目负责。在技术选型时，通常是开发人员带着问题请教老师傅，老师傅给建议。这样的结果就是老师傅就算技术再牛，也无法做出全局最优的决策。

对于开发人员，有的人擅长JAVA，有的擅长数据库，但他们也无奈被迫从事了自己不擅长的工作，还要负责自己模块的设计和技术选型。

然后我们就看到系统崩溃了，而且把其他系统也带垮了。

虽然老板给了每个人分配了明确的任务，但没有划定他们的职责和权限，一部分人的边界被他人侵蚀，部分人的责任范围被迫超出能力范围，团队的优势资源被内耗，大家都从事着相对陌生的工作，自然无法保障交付的质量。

整个项目的失败不完全是技术原因导致的，深层次的原因是团队在项目管理方面知识和经验的缺乏。如果在进行市场尝试前，老板能够稍微在管理方面花点心思，做到需求有依据，设计足够详尽，对系统的质量足够负责，和团队成员交流足够充分，都可以一定程度避免这些问题的出现。