你被潜规则了吗追溯软件项目失败的根源

　　长年混迹在软件场的老鸟们，哪个没品尝过失败的痛苦，当我们的日日夜夜的加班及辛苦的劳动换来的只是失败的结果时，不知道你有何感想。每当我完成一个项目时，都有着虚脱的放松感。虚脱是累的，放松是一种解脱，不论项目成败，心里的感觉就是个终于解脱了。
　　在软件行业这些年里，生活就如同上了发条，不允许有一丝的松懈，就是希望自己负责的项目能够成功，得到公司和客户的认可。但现实呢？相信所有人都一样，都会遇到这样或那样的问题，理想很丰满、现实很骨感。
　　老吴今天要说的是软件项目失败的根源到底在哪？
　　幸福都是一样的，但不幸却各有各的不幸。
　　当我们接一个项目，在初期需求调研时，感觉客户确实要的不多，功能也不太复杂。但随着项目的深入，你会发现客户的需求会不段的蹦出来，而且客户谈的需求也很合理，应该有，不加上功能确实不完整。但是，一切已经远超你最初的控制了。当初只是10万的一个网站，后来变成你根本控制不住成本，变成了赔本连吆喝都没赚到，客户还不满意。说你：太垃圾了，这么简单的产品都做不出来。你，苦啊
　　案例分析：
　　前两年我受公司委托，以产品经理身份参与了某房产信息平台的建设，从项目谈判、需求调研、设计、开发、上线，整个过程都全程参与。在谈这个平台规划时，感觉确实是一个有前景的房地产信息平台：平台目标是为了能够打通买方、卖方、经纪人、中介公司、建委等多方的信息瓶颈，让信息通过平台变得透明，让交易变得公平而公正，买方能够通过平台直接联系卖方，实现自行交易，如果能够真正实现自行交易，将会打破整个房产市场结构。
　　如在网络上实现交易，买、卖双方因为信息不对称而存在不信任问题。如何解决呢？买方，通过向平台提供个人相关资料信息，平台利用买方提供的资料信息进行购房资格和身份的核验，保证买方为有资格的有效购房人；卖方，平台与北京建委实现合作，提供卖方的房产信息真实性校验，保证卖方人与房源的真实性。解决了这两个瓶颈，就有了自行成交的前提。
　　当时与对方沟通过多次，客户对我方公司资格和能力也比较认可，就要求报价和签约，当时通过初步的沟通对需求有一个大致的了解，当然细节都还要不断的沟通、确认，我们也出过几版效果图，在双方会上多次沟通过。但商务合作已经到了报价阶段，不会等大家需求全谈明白了再进行，然后重点就转向谈商务，多少钱、多长时间、多少人力？估算吧，整理列出大模块，自行成交、经纪成交、用户管理、建委等外部接口、权限管理、交易管理、平台后台管理、网站前端。各模块列出大致功能及报价。下一步再经过几轮的砍价，达到意向，签约。
　　当项目正式启动后，再与客户谈需求时发现有着一种莫名的无力感，虽然大方向大家都是认可的，但客户方每个领导的想法及实现细节都不太相同，对这款产品将来的意识形态描述有区别。有的领导提出要有大宗资产，房产交易过程中提供的服务是不太挣钱的，从挣钱效益看大宗资产的交易才应该是平台的核心。
　　有的领导提出房产数据才是重点，在房产平台刚上线时，买、卖双方、房产都是空白的，没有房产资源如何做交易并带动平台良性发展。有的领导提出，真实性交易是核心，如果想打造良性的发展平台并被大众所认可，真实房源、真实交易是重点，保证真实性就要与建委等政府平台对接，打通平台与建委之间的信息鸿沟，以保证房源真实性及购房人购房资格，才能取信与民，平台才能真正的占领市场并打破当前的经纪人垄断行情。还有领导提出，与经纪公司合作，利用经纪公司的经纪人资源，让平台的用户交易可落地，有了经纪人也能盘活平台，以引入更多房源。还有领导说，现在PC版的网站平台已经落后了，我们也要做手机端，需要手机端与网站端相结合，打造移动互联平台
　　大家看到了吧，情况很复杂，问题很严重。老吴来给大家梳理下有可能导致项目失败的几个致命伤。
　　问题一：需求不明确
　　客户方各执一词，思想不统一。在思想不统一前提下，我们做什么都会是错误的，做多错多。你说我们应该跟谁谈？如这个问题不解决最后死的就是你。有的产品负责人为了让客户满意，尽量去满足客户要求，完成客户需求。导致的结果就是，开发人员累得要死，项目需求控制不住，需求间矛盾冲突，各执一词。而且成本上升导致公司赔钱，公司领导不满意。你就变成了人民公敌，项目结束后你也该走人了。
　　问题二：需求蔓延
　　大家说的都有道理，但有的需求与我们最开始谈的已经不太一致了，最开始谈的合同内容里并没有大宗资产交易，也没有手机端功能。哪怎么办？相信你们都遇到过吧，感觉是个坑啊。
　　问题三：没有指定接口人
　　谁都跟我们提需求，而客户内部都没有达到思想统一，我们到底应该听谁的？让我们无从下手啊。你得指定一名对接人才行啊，从他哪出来的我们才能认为是真正的需求，不要谁都跟我说需求，谁都说需求，就是没有需求，最后的结果是客户方没有代码，出问题时谁都可以不负责，哪时你可惨了，连个替你说话的人你都找不到。
　　问题四：用户期望不实际
　　在要房源没房源、要用户没用户、要数据没数据的前期过程中，就把平台想的过分完美化，想通过一个平台的建立就实现鹰击长空的目标还是有点要求过高。互联网市场一直强调的是小步快跑、快速迭代。这种互联网房产交易的平台，还需要O2O的线上与线下结合，用线下业务的开展来推动线上业务，用线上业务再来推动线下业务的开展。刚开始起步时，一穷二白，资源还都没有，一下子做个大而全的产品，合适吗？想通过一款软件就一统江湖，可能吗？
　　好接着往下讲这个故事。
　　为了解决以上问题，我也是很头痛，即要让客户满意，又想得到公司支持。但老好人在复杂的项目环境下是没法生存了。大家好才是真的好是错的。首先，先得跟自己公司领导沟通好，让公司领导知道目前的项目情况，争取得到领导的支持和帮助。其次，要与客户针对项目情况达成一致意见，我们得有一个指定的需求对接人，避免需求入口过多问题。要让需求回归理性，不能让需求偏差太大吧，拿合同来约束需求。让对方思想不要太过信马由缰，通过沟通来解决需求蔓延的问题，让思想回归理性。同时也要让用户知道，太发散的需求，最后会导致需求无法控制，无法落地，无法执行的尴尬，项目的失败是双方的，要让对方知道，我们是一根绳上的，一条船上的，我们是真心的与客户沟通，认真的帮助他分析，不要出现对立、不要出现你们我们这种界限，真诚的付出会得到对方的尊重。
　　之前老吴写过一篇文章如何控制需求蔓延，有兴趣的朋友可以看下。
　　故事继续下去，经过努力，双方达成共识，客户方有一位负责人专门负责此平台的建设，我们只需要针对这一位领导就可以了。另外，经过公司领导的帮助，把需求拉回了合理的范围。看似简单的问题，实际是需要多方努力的，一方面客户态度非常积极，而且对方负责人是一个比较勇于担当的人，针对此项目专门成立了一个业务组。另一方面公司与自己的团队也都愿意付出，领导也多次出面与我一同承担责任，共同与客户探讨、沟通。经过了一翻努力，看似开始走向正轨了。
　　接下来，当去除了项目杂音后，当大方向确定后，就开始一起讨论需求细节了。细节如何确定呢？对方公司不是一个软件公司，是一个业务型公司，对房产业务非常精通，但对软件要如何做，不清楚；做成什么样，不清楚。在需求细节不明确的时候，我们团队打算先出原型，用原型来获取对方需求，接下来就是一起坐来来讨论需求，讨论原型的阶段。经过一翻努力，原型最后确定下来了，需求也就确定下来了。开工吧，因前期讨论需求所花的时间比较多，项目工期开始变得紧张了，只好从外面再请一支外包团队进来，开始封闭开发。
　　因时间紧，我们采用两手准备原因，一方面开发人员开始搭建环境、了解业务、进行设计。另一支UI队伍开始出效果图，出完效果图再与客户沟通。确定了展示效果并对数据库设计、功能设计完成后，团队开工建设，之后就是从早起一直干到晚上11点的循环日子。因当时是年末，临近春节时，团队全员蒙头垢面的走出宾馆后，当看到第一缕阳光后，心情是苦乐掺半，技术人员、设计人员全部回家过年了。我与外包公司的项目经理一同回到客户公司，进行汇报演示，演示结果还算可以，但客户也提出了许多意见。当时提的意见还是有些空泛，因为提出的多数意见都是方向性问题，实际这时候再提方向性问题确实有些不合适了，生米都快煮成熟饭了。
　　问题五：需求细节没想透彻
　　因当时要求上线时间比较紧，中国项目都是短、平、快的要求，不允许给你大量的时间去整理、分析需求。团队为了赶工期，许多细节地方还是没有想的太通透，尤其是后台的管理部分，与客户沟通的主要是在沟通业务前台部分，买方、卖方、经纪人之间的交易，如何实现房源的验证部分，在后台上许多设计不合理。
　　问题六：多团队作战，思想难统一
　　客户方、我方、外包公司，三方联合作业，每一方都需要沟通好，每方都有自己的想法及打算。这回出问题的是外包公司，我方要求对方至少出10名开发人员，刚进来的人都是我面试的，后来项目紧，又进来的人我也没再把关，直接让对方的外包公司带队的项目经理把关了。在封闭期间，因有的功能实现太慢，我就找到负责这块的技术人员看着他如何实现的，才发现，这哥们是个菜鸟，还是大菜鸟。这就是问题了，外包团队为了节省成本、凑够人数找了些成本低的人滥竽充数，打着自己的小算盘。当时找了对方项目经理说明情况要求换人，但因为是年底了，他们也以很难找到水平好的人进来为由，就托了下来。再说后台，我与客户一直在讨论前台功能，后台功能有所疏忽，我就让外包公司项目经理带人负责设计、开发，当我忙完其它工作后，想要看下设计的后台效果时，却以正在开发，快出来了，迟迟没有给我看效果。原因就是他们想尽快做完，怕我看后再提出其它要求，先把生米下锅了，最后看你拿我怎么办？因为利益不同，导致各方思想不统一，给项目也带来了诸多麻烦。
　　问题七：项目时间紧，经费少
　　以前，我做过对日外包项目，那里也经常加班，但日方给的需求、设计的时间都是比较充足的，他们对需求、设计看的非常重，可能也是因为客户方在日本的原因吧，不在现场，需求不好把控，就尽量把文档整理的特别细致。设计能达到什么程度呢？你看到详细设计文档都可以直接编码，都不用你细想了，基本上就是伪代码程度。中国软件行业的特点就是快，客户多半是对软件开发过程不了解，认为可以一个月就出一个产品。谈合作时基本上就是谈完需求后，再谈的就是两件事，多少钱、多长时间。钱报高了不行，有比你出的更低的，一些小公司不计成本的接项目，恶性竞争严重；时间报长了不行，客户们要不不做，要做就得马上出来，给的时间就几个月，你要说半年、一年的，你都不好意思说，非挨嘴巴不可，这就是中国软件的现状。
　　案例继续，年后，带着团队回来，与客户沟通，新问题出现了，我们做的房产刚上线时不能没房源数据吧，得找资源啊。于是，项目暂停下，先与外包公司协商，技术人员先回，当项目再启动时，人员再过来。因为客户没有太懂IT的技术人员。我呢职责就变成，给客户做技术支持，我们一起去找房产数据公司谈合作。还有，房子的价格与地理位置关系比较大，为了更直观的展示地理位置信息，我们得有地图啊，于是，我开始帮助客户协调地图公司。另外，房子要想网上销售，得尽可能的让买方多了解房子内部信息吧，于是，又协调三方公司是否可以引进360度房子内部的全景展示。
　　这段时间做的事情基本上是，协调资源、评估可行性、出各种报告及文档。经过集体的力量，项目又向良性发展了，房源数据和地图信息都搞定了。有人要说了，地图还用搞定啊，百度地图都是免费的。我们的房产平台是要引进政策资源的，有相应国企背景的，最好还是与同样是政府背景的平台合作比较好。这就如同要跟政府采购一批办公软件，能采购OFFICE吗？不能吧，得用金山办公软件吧，当然买回来用不用是另外的事情。
　　资源协调完了，房源数据有了，地图数据有了。360室内展示因采集工作复杂，工作量大，没有做。人拉回来继续做吧，新的问题来了。一个问题是，年后，有两个骨干外包人员离职了，还有的外包人员被他们派到其它项目了，调不回来了。另一个问题是，我们的项目已经根据之前讨论的需求做了设计、开发，程序都是根据自己设计的数据库开发的，新买的房源数据的数据库与我们的数据库结构完全不同，结构不同，我们如何解决房源数据对接问题？而且，对方数据库数据表就有300多张，对方只提供数据和每个表的字段说明，表关系完全没有，买回来的只是一堆数据。这就相当于，中国改革开放初期，从国外买回一批高端车床，本想大干一场，却发现，我们没人懂啊，说明书全是英文的，没人详细讲解，原来我们买回的只是一个美丽的花瓶。但我们的客户并没有认识到问题的严重性，他们以为有了房源数据就可以了，还想着将来做房产的数据分析呢，做个大数据啥的，没有表结构、表关系，能分析啥啊，看都看不懂，300多张表，怎么分析，一地散落的珠子，没有线头啊。
　　其实，在谈数据公司时我已经出过报告，并解释过，但确实没有其它家再能提供这么全面的房源数据了，别无选择。另一个是，客户与数据提供商相互间还是有着一定的信任关系，本身愿意一起合作的。做为开发公司有什么办法呢，我们也只是建议，不能因为困难不做吧，还得继续。想办法吧，原则是我们的表结构不能动，要动以前开发的程序都白做了。另外，我们要把所有的房源数据导到我们表里，得研究提供商的与房源有关的表结构。还有个问题是，数据公司在合同规定时间内会把新采集的房源数据继续生成给我们，新生成的数据我们也得转过来啊。想办法吧，具体办法就不细说了，此处省略一万字
　　问题八：先干了再说，没有全局考虑
　　客户把一个项目包出去后，他们不太管你是怎么做的，我只要结果。希望你赶紧做出来东西，让我看到，至于今后可能出现的问题，出现了再说，反正我不太懂，出问题了你得给我解决。就像这个案例中，第三方房源数据公司的出现，打破了现有的平衡，为项目带来了大量的额外工作量。有的时候，我们很被动，你不能说让客户都万事具备了，你再来谈合作吧，因为哪样的话，项目就不会再是你的了。你不能说，你别接其它房源三方数据了，你让人用我们的系统录数据吧。怎么可能，近10年的房源数据，数据量得有上千万条。干吧，说多了都是泪。
　　问题九：人员变动
　　人做为项目资源，有着他的流动性，年后人员的离职，及原人员被分配到其它项目组，给项目带来了额外的不确定性。外包公司考虑的是人员的成本，他不会因为你项目原因，把人给你留着，一有机会马上就会把人分配出去，到时候抓狂的只有你。只能再花高价钱找人补充进来吧。
　　问题十：项目经理的控制力问题
　　当多位骨干人员离开后，项目开始变得难以控制了，之前虽然有大量文档和原型，但在紧张的开发周期内，是没有太多时间让人细细理解，细细分析。有问题的话直接问，有的人离开了，只能看代码，为了推动项目开展，团队成员只能硬往前推动。代码开始不好管理，虽然之前做了各种版本管理，随着系统的变大，人员的变化，让文档、代码、数据的管理也变得复杂。
　　写的比较多了，故事就不再往下讲了，后面还发生过其它问题，就不细说了。对于导致项目进行中的各种困难还有好多，严重的还有可能导致项目失败。只是在这个项目中没有出现，我继续整理下，在其它项目中经常遇到的一些常见问题。
　　问题十一：需求变更频繁
　　在很多项目中，客户经常修改需求，经常遇到的情况是，你接触的客户代表并不是拍板人，当你们一起讨论、开发的功能出来后，领导一看，不对啊，得改，然后就是你的几个没日没夜的加班。这还是好的，有的功能全做完后，客户提出来，方向错了，然后呢？然后你疯了
　　问题十二：沟通不顺畅
　　有时候，当你们与客户沟通后，整理需求、出设计，想要再与客户沟通以确定是否正确时，客户出差了，那怎么办，等吧，两个星期后回来了，再沟通，再确定。修改完不一致内容后，再找客户，他说，你等等吧，告诉你：最近有领导检查，没时间弄这事，然后再等吧
　　我想追逐到末路与你白头到入土
　　不到地老天荒不认输
　　等半夏叶落地
　　花开花落人离兮
　　我知道在你心里没痕迹
　　当我初次遇见你的时候天空下着雨
　　而你高傲脸庞映入眼里侵入我的心
　　人群中萧瑟的身影总是那么的清晰
　　我的眼睛不离不弃跟紧你的背影
　　再也找不到退路
　　问题十三：信息传递过程失真
　　记得有个真人秀节目，一个中国人说一个中国的成语，一个外国人听后再告诉给另一个中国人，然后再告诉给另一个外国人，经过6个人后，你已经不知道第一个人说的是什么了。
　　经过这些流程后，你猜最后理解的人与客户最初说的还是一回事吗？
　　实际沟通存在两个维度的问题，一个维度是客户层现，另一个维度是公司内部层面。客户也是有不同部门、不同领导的，每个人想要的、想做的都是一样的吗？信息传递给你，你接收的、你理解的就是真正的需求吗？然后这个不一定正确的需求就一道道的传递下去，到了最后会变成什么样呢。
　　问题十三：需求被放大或缩小
　　需求是一个很难被正确衡量的东西，于是我们就开始写文档、做原型，试图把它立体化，丰满起来的需求，就更加真实而直观了。但许多产品经理或需求人员经常爱炫一些小技巧，加些特效或功能，让它更能耍酷。这还是好的，有的你根本就没弄懂需求，以为的并不是真正你以为的，需求就这样被你放大了或缩小了，在没有被很好的确认后，就产生了一连串错误。最后的结果是什么呢？你，被一群程序猿、设计师们围殴。120吗？快，这里有一个伤者，需要急救。什么，怎么搞的被人打的，太惨了，快来吧！！！
　　问题十四：利益纷争
　　我们经常看共军与国军战斗的场面，共军团队攻打国军，国军将领在炮轰纷飞的战场摇着话机喊：我顶不住了，快给我增员啊。什么，你也没人，你们有命令，不许离开阵地一步？他妈的，都这时候了，你还不增员，这是要老子死啊？然后，电话被炮火炸断了，只留下一个人在阵地上骂娘。在客户方也好、在自己公司也好，当公司规模到一定程序，都要出现派系之争和利益之争，互相争抢资源，宁肯自己人剩下，也不愿意帮助其它团队。最后不幸的是，你躺枪了哥，醒醒，快跟领导要点资源啊，再没人支持我们就要废了。你也不看看，谁还能帮咱？我们被潜规则了！！！
　　人在世上漂，哪有不挨刀。项目是复杂的，悲欢离合，喜忧掺半，以上的问题你遇到过吗？遇到几个？你要没遇到过，说明你还是新手，我们这些老鸟们已经练成金刚不坏之身了。兵来将挡，你总能够通过自己的智慧化解这一个个难题，任何问题也都有解决方案，以后老吴慢慢给你道来，如何在产品和项目的烈火中永生
　　对了，你问我，最后房产的平台怎么样了，上线了，还不错，现在运行也挺好的，经过努力困难也被一一化解，最后成功上线。兄弟们的付出没有白费，每个人都是从一个个项目中慢慢成长起来的，全都是一帆风顺，怎么会拨云见彩虹。