如何拯救让我最痛的一个B端项目？

　　文章通过总结的五个点阐述如何拯救一个B端项目，来致敬长胖20斤的自己。
　　回忆这么多年的IT生涯，能让我想起的有三个最痛苦的时刻：
　　第一次是刚入IT坑，我还是一个传说中的程序猿，我负责的系统是个生产系统，一天24小时都在用，经常到了晚上现场打电话过来，系统不能用了，我就马上爬起来抓bug，改完bug，还要小心翼翼的把我们负责配置管理的小妹妹吵起来给我上线。那时候很痛苦，晚上总睡不好，可刚入IT行，总觉得这些苦都值得，吃了苦才能快速的成长，所以那个时候的苦叫做成长的苦。
　　第二次是从需求转售前后，负责的的第一个售前项目，那个时候思维总是转不过弯，做需求讲究细致的需求分析，要能落地，做售前更注重总结包装，要能写出高大上的方案，是否能真的落地却并没有那么高的要求，能把标拿到才是硬道理，那个时候的苦叫做转行的阵痛。
　　还有一次就是最近这几年做了一个错综复杂的项目，这个项目我是产品负责人，现场有个项目经理，我几乎用尽全力才把这个项目交付，现在每次遇到难做的项目，想想这个项目也就没那么痛苦了，所以我把这个项目痛苦指数定为五星，这种苦就是传说中的痛中之痛。
　　如何拯救这最痛的项目，我总结为以下几点：
　　一、方案能力拯救失望的用户
　　刚接手这个项目实际上是一个半截子项目，前任项目和产品负责人没有得到用户认可，我是临危受命，所以刚来的时候一脸懵逼，还没来得及搞清楚情况，就没销售忽悠出差，第一次见用户发现被销售挖了个大坑。
　　在我来之前项目已经做了三分之一，剩下的项目需求，以销售为首的本地团队，为了把项目盘子做大，忽悠了一个很大的范围，本想着引导用户分期实施，没想到用户根本不和你谈分期，就是要本期全部做完，反正都是你们自己挖的坑。
　　没想到刚来就入坑了，而且坑里还有水，水里还有钉，销售笑笑，坑边还有肉呢，先把坑填了吧。
　　面对这种一开始就被挖大坑的情况，我刚开始的思路是缩小边界，并且用最简单的方案去满足用户的要求，按照这个思路写了一版方案给用户汇报，结果大败而归，还是小看了用户，还没等我把方案讲完，用户就说，你这不对啊，原来你们的规划可不是这么说的，说完自己拿出我们原来规划的方案讲起来。本以为是我引导用户，最后变成了用户给我讲方案，你说痛苦不痛苦。
　　这次沟通之后用户放了狠话，如果下次汇报方案还是这种水平，就不用给我汇报了，这次沟通用户讲了非常多的诉求，幸亏我当时留了一手做了个录音，回来反复研究录音，最终总结出三点核心需求。围绕这三个点总结出项目目标，又写了一版方案，这次总算能和用户平起平坐了，用户愿意和你平等交流了，而且提了很多中肯的意见。
　　后来终于迎来了转机，用户需要给公司总裁汇报这个系统的建设方案，趁着这个机会，我几乎用尽毕生所学，周末在宾馆里闭关两天，写出可一版方案。
　　这次方案不只是逻辑架构严谨，而且PPT也的做的美美的，更重要的是借着这个机会把我们想做的功能放大，写得足够详细，足够亮，不想做的部分淡化或者完全抛弃，并给出了合力的理由，这个方案看起来仍然非常的高大上，丝毫没有感觉少了很多需求。
　　经过这次成功的方案汇报，用户彻底改变了对我本人，甚至是我们团队的看法，专门指定我需要讨论方案可以随时来找他。
　　从被用户牵着鼻子走，到和用户平起平坐，再到引领用户，靠的就是提出专业解决方案的能力，这方案的载体就是传说中的PPT，也就是这三个PPT，让我们的项目初步从失望中拯救出来。
　　二、全新的产品摸着石头过河
　　从来没做过类似的产品，所以做这个项目基本就是摸着石头过河，对业务的学习、理解的过程是痛并快乐着，开始痛苦，突然开窍找到用户痛点的那一刻感觉很快乐。
　　没有对业务的学习和理解，也就没办法写出那些让用户满意的解决方案，这里和大家分享一下我的业务学习过程。
　　先是和用户沟通，通过和用户沟通能大概了解用户关心的业务范围，哪些问题是他们比较关心的，这样对要学习的业务有个大概的框架。
　　然后是看收集类的各种管理办法，实施细则、方案PPT，通过看看这些资料去捕捉用户关心的问题，丰富对业务的理解，这个时候大概能看到一些问题的解决方案，并且提出一些业务理解的假设。
　　最后是看相关系统，通过看相关的业务的数据印证自己的假设，这个时候如果能会一些SQL语句，可以直接查询后台数据库的数据，来验证自己的假设，对业务的理解就能更快。
　　这三步下来基本上能达到对目标业务的理解，如果这个时候可以找个小伙伴一起探讨业务，论证假设就好了，互相讨论，对业务的理解能更加深刻。
　　业务学习能力，对一个B端的产品经理而言非常重要，这是做出好的产品，在项目中征服用户的必备能力。
　　很多C端产品经理转行做B端很不适应，就是因为疏于对业务的理解，觉得把C端那套方法论拿过来就能用，事实上真的不灵。
　　B端产品经理最核心能力就是通过自己对业务的深刻理解，提出优秀的解决方案，这个方案并非完全是IT层面的方案，而是兼具管理和IT，所以好的B端产品经理是行业专家和IT专家的混合体。
　　三、敬业的态度决定一切
　　这是我出差最长的一个项目，有半年左右的时间，因为经常要汇报，经常是周五刚到机场，然后接到客户电话，下周一又返回去，就这样马不停蹄的从家、机场再到客户现场。
　　那年我的年终总结是这么写的，事实证明，工作和生活是不能平衡的，所以有时间陪伴家人一定要高质量的陪伴。
　　用户也知道我的情况，有时候硬把我从北京叫回去，也会感觉不好意思，通过这种奔波，用户对我比较信赖，也比较欣赏我敬业的态度，知道我和他们是一条船上的人，真的希望把这个项目做好。
　　“态度决定一切”，这句话前中国男足教练米卢经常说，用到这个项目上也十分合适，通过自己的敬业态度，让用户感知到，项目也变得顺畅多了。
　　四、内部斗争，自信争取投资
　　这个项目有个小插曲，最开始的时候，因为项目比较大，由两个产品线共同承接了这个项目，另外一个产品线承接的部分，做出来的系统用户不满意，基本上要翻盘重做，他们不愿意做，后来本地销售让我们接，我说接可以，另外一个产品线必须退出，并且把合同额一分不少的给我们。
　　另外一个产品线的老大觉得自己投入了人力干了大半年，虽然系统无法验收，还是希望能分一杯羹，结果互不相让，只能找总裁仲裁了。
　　到了总裁那里，我们把诉求和未来对这个系统建设的方案讲得清清楚楚，对方只想要钱，讲不出方案的价值，结果一百多多万的利空指标，总裁拍给了我们。
　　这算是一个小小的胜利，虽然是对内的，因为是各部门独立结算，到了年底算业绩的时候，这些钱还是能有些作用。
　　还是回归到用户价值，你只要能把方案的价值讲清楚，能为用户创造价值，可以保证后续和用户的继续良性合作，作为高层领导依然会放心的把这件事交给你去做。
　　五、有张有驰，控制好项目的节奏
　　方案赢得了认可，系统也都顺利上线，也逐步开始推广使用，可项目却迟迟无法验收，原因并不是系统不满足他们的需求，而是用户明年没有投资了，如果给我们验收了，后面还要好多推广运维的工作，怕我们直接撤了，不验收硬拖着，作为产品线也没法一直坚持持续投入。
　　最后我们选择的策略是放缓项目节奏，不再主动的推进项目，让用户着急找我们，经过几次试探，用户发现很多工作推进起来非常困难，也大概明白了我们的意思，大家友好协商，遗留了少许问题，最终还是把项目验收了。
　　这个事情也让我们明白一个道理，项目的节奏把控很重要，当发生一些突发事情的时候，停下来，放缓节奏可能会迎来转机，一张一弛，文武之道就是这个道理。
　　最后向因为这个项目变胖的同事们致敬，他们很多都是现场的开发人员，也是从北京出差到现场，经常加班写代码、找bug、上线，吃饭没规律，一下子都胖了好多，感谢小W、小Z，还有一位女同胞小L，感谢你们，当然也包括我自己。
　　因为这个项目胖了20斤，这大概是让我最痛的一件事吧。