To B产品交付的那些是非，有坑慎入！

To B产品交付的时候，需要注意些什么？坑那么多，能够很好的回避吗？

在上一篇《第一次做的to B产品去部署，我竟然有点想哭》中，我回顾了自从进入这家公司开始，对所负责的这个产品从0到1再到交付的种种过往，本以为可作为我对此的一个交代，可天真如我才猛然发现，这不过是新一轮甩锅的开始。

为了确保部署后的验证完成，在技术人员出发后的第三天，我便带领测试一同赶往客户现场与他们汇合，希望可以做个完整的收尾。习惯了做C端的产品小伙伴，一定没有感受过在客户现场的待遇和境地，说实话我也是第二次，所以还差不多能接受。

结束当天我们完成了所有问题的测试修复以及验证，在和项目经理沟通确认后，将之前准备好的交付文档，以及本次验证问题及修复结果汇总合并，发给了公司内部的上级领导层以及本地项目经理，并和他确认了第二天我们小组可以启程回京。

看似一切顺利的背后，其实暗藏各种隐患，这其中的是是非非，更与何人说。

信息不一致

正常来讲，产品研发、项目经理、客户方这三者间的信息应该是一致和对等的，客户提出的需求，传达给项目经理，由项目经理同步给产品研发，如此一致的节奏和验收会相对顺畅一些。

可实际情况往往并非如此，有时候项目经理传递给产品研发的需求也许并没有和客户确认，而客户自身的需求也没有比较直接的传递。这就导致产品研发时而摸石头过河，时而在项目经理安排下前进，而等客户真正意义上去看的时候，会发现超出他们之前的设想或者是其他一些项目经理未同步的情况。

对于传统行业的客户而言，这其中还会有一些人事方面的纷争，可能有的人深有体会，在这里就不多说了。总之，信息不一致以及信息不对称，是诱发冲突的根源，也是随时可作为甲方客户爸爸找茬的一根导火索。

交付未明确

不管是内部研发，还是外部交付，一个相对清晰明了的list是必不可少的。在我做项目管理的时候，习惯用project plan出所有的排期列表，哪怕中间有变动，有优先级调整，整体情况也可以一目了然。

在本次交付中，作为产品研发的我们自始至终也未明确得到一个跟客户确认一致的交付物list，这个list并不会因为产品新颖而受到影响，而应该是沟通在前。因为我们涵盖的模块也是从总干上拆出来一个分支，从而加上客户自身需要的部分组成的交付物。

这个不明确和我上文所说的信息不一致有一定关系，由于项目经理在客户现场，而我们小组的产品研发在公司，所以项目经理就是连接并传递我们和客户之间信息的纽带。

有时候项目经理传达给我们的任务，并非是客户知晓的，而客户一心想要的，已经由于接了项目经理安排的新任务而被我们推后了优先级。由此导致规定日期去部署的时候，我们所交付的没有涵盖所有客户的需求，公说公有理婆说婆有理， 我们的目的不是争执不下，而是该看清问题的本质 。

客户多责怪

客户责怪这一点，我在上文中也点到过，也许这真的有些工作之外的隐晦关系，而非人为所能控制的，但减少此事件发生的概率不应该寄希望于遇到一个明理的甲方爸爸，而是尽自身努力做到最好，最好让对方挑不出毛病。

如果把该做的都做到了，还会有不满，那也只能接受，因为无法做到百分百让所有人满意，努力到无能为力，无愧于心，无愧于己。而如何做到极致，首先应该尽量把上述两点做到规范，减少冲突发生的概率。

在这个过程中我渐渐发现，我们的项目经理在客户现场，并没有一个十分明确的对接指令，有时候甲方大领导过来说要怎样怎样，而甲方下面的对接人在与项目经理沟通时又会想出另一种方式，项目经理以此方式传达给我们，最后会让甲方大领导看了依旧不满意，这里面各方责任其实都有。

比如项目经理在执行某一事件时，可以将现有方案以及为什么如此（和甲方下面对接的人沟通，对方表明这样）通过邮件方式统一发出来，抄送给大领导，这样让大家有留存，不然到最后领导不满意的时候，万一甲方下面的人改口一变，那么锅就全都甩到了我们这一边。

其实通过这些事可以看到很多问题，也许有些问题并非我们一己之力可以解决，但至少应该积极探索并努力过，如此才算做到极致。

牵头人缺失

站在一个更高的层面看此问题，其实管理层和牵头人的缺失也是出现问题的一个原因。不论是我们产品研发，还是身在客户现场的项目经理，从高层来看还是偏执行多一些。那么在我们之上的领导层是否应该出一个人来对接和协调此事，尤其是在客户现场的项目经理自身还要参与到研发的具体事务中，那么管理这一层多少会有些无暇顾及。

在创业公司，创始人的精力是非常有限的，他可能只会顾及到一两个重点客户和项目身上，这时候就需要建立起完备健全的管理体系，不然就会导致管理缺失，底下混乱。

结语

最近也看了一些B端方面的内容，做B端，标准化和定制化的抉择是所有B端公司绕不过去的一个问题。作为针对头部B端客户的公司来说，定制化和项目化可能是当前维持生计的一个必然选择，毕竟先活下去才最重要。那么如果想覆盖头部公司之外的中小客户，标准化走量的这种必不可少。

关于B端公司选择何种走向，这其实已经不是产品层面能解决的问题，事关公司决策和发展战略，更多是创始人和领导层的决策和方向。一个公司能够生存的方式有很多种，衡量它的价值可能不能只看一时，而是看能走多久，走得如何。

就像前两天看文章说腾讯当时出来的一个团队创业，钱花光之后靠做外包来维持，可后来通过与一个大V合作，目前已成为小有名气的一家公司，客户数量非常可观，逐渐越来越好。

也许今天这个公司经历的一些事，在今后的某个时刻来看，已经微乎其微，和每个客户之间的那些纷扰，都可以当作前进路上的警示，指引着我们做得更好，走的更远。不论怎样，衷心祝福它的未来之路宽且长。

一起加油，共勉！

#专栏作家

慕斯姑娘，微信号：musiguniang，公众号：产品那些年，人人都是产品经理专栏作家。关注金融科技和大数据领域，擅长产品规划和落地。

本文原创发布于人人都是产品经理，未经许可，禁止转载

题图来自 Unsplash，基于 CC0 协议

作者暂无likerid, 赞赏暂由本网站代持，当作者有likerid后会全部转账给作者（我们会尽力而为）。


Support author:
Author's Filecoin address:
Or you can use Likecoin to support author: