前言
前几天有一个产品经理在微信上向我吐槽，说明明在原型上有相应的说明，评审会也说过，但是最后还是会问他很多产品的问题，搞得他有点无语。我相信这种情况是普遍现象，大部分人遇到问题第一时间想到的是最快解决问题的办法。对于产品需求不清楚地方，技术开发同学最快的解决方式就是找产品经理去问。其实不仅仅是技术开发同学，在上下游配合中，当我们遇到上游有不明白的地方的时候，往往也会优先直接去直接问上游的人。
作为技术开发的上游，他们问的问题多了，经常打断我们的工作，难免会让我们觉得烦。然而，如果我们换一种思考方式，可能就不一样了。下面是我当时给他的回复，当我们“把下一个环节当作客户”的时候，心态就会转变很多。
把下一个环节当作客户
我们产品经理有时候也会参与到售后服务中，去解答客户的问题（个人推荐产品经理要抽出时间去做售后客服，直接面对客户获取一手信息）。我自己曾经加入到我们多个客户售后服务微信群，然后遇到了各种各样的问题。有些问题非常简单，比如刚接触系统不久，找不到某个功能了；比如去哪里看xx数据等等。这些问题其实看起来非常初级，但是我们却会耐心地解答，哪怕是觉得很繁琐也不会向他们表露出我们的情绪。然而，到了和我们合作紧密的技术开发同学了，为什么反而会有情绪了呢？
说实话，一开始我这边同样会有情绪，觉得原型明明标注说明了，为什么不看？文档里写了，怎么不认真看文档？但是，后面我改变了这些想法。印象中是看了《华为人才管理之道》这本书，里面有讲到了华为团队协作的要求，每个人、每个团队需要把下一个环节当作客户去服务。从我们团队协作上来说，技术开发是产品设计的下一个环节，如果下一个环节工作做不好，实际上会影响到我们产品设计的工作价值。只有下一个环节的工作顺畅了，产生价值了才能体现你的价值，这其实和我们的产品与客户的关系是相同的。客户如果用不好我们的产品，我们产品的价值就体现不出来，结果就是被客户弃用，造成客户流失。与客户不同的是，客户弃用产品后和我们可能不会再有交集，而我们和技术开发同学的工作配合是长时间持续的。这就意味着，如果配合不好，我们的产品研发质量根本难以保证。
另外换个角度来说，开发同学愿意在开发前和我们确认问题，至少有两个好处，一个是说明他们比较认真负责，另一个是不会等到开发上线后才暴露我们的产品设计问题。我也有遇到一种开发，全程不问任何问题，闷头开发，然后等到发版复核前才发现很多业务理解都是他自己想的，根本不符合产品需求，结果不得不返工修改，推迟上线。所以，相比吭哧吭哧闷声开发的同学，我更愿意和提出问题的技术开发合作，大家在讨论的过程中能够提前查漏补缺，可以有效降低延期风险和减少上线后的bug数量。
对于产品设计来说，我们要把看原型、看文档的人当作我们的客户（或者用户），秉着他们能够轻松看懂的原则去画原型、写文档、做标注。这样，他们能够抓住关键信息，快速理解业务，反过来其实也能减少问题的数量。
如何做好下游
我们是技术开发同学的上游，也会是其他同事或者外部需求方的下游。换位思考一下，当我们有问题需要咨询上游的时候，以下两点可以帮我们做好我们“下游”的角色：
有问题要提出来：这一点经常在和领导开会的时候出现，领导布置任务后，会问“有没有问题”。不少人为了不给领导“添麻烦”，往往会说没问题。然而，可能到了要交付的时候却暴露出大堆问题，反而“添了大麻烦”。我的习惯是，有问题我会提出来，哪怕是解决不了，至少让领导知道潜在的风险。如果是必须要解决的问题，那么更是要坚持让领导解决，而不是藏着捂着，最后等着问题爆发。
不要零碎地提问题：国内企业内部沟通大多数都是通过IM软件进行的，好处是随时随地可以给同事发消息，坏处是随时随地可以“打扰”同事。实际上，每个人每天专注工作的时间非常有限，如果经常被零零碎碎的临时事件打断，那么工作效率会非常低。我自己曾经有一段时间不得不下班后工作，就是琐碎的事情太多，只有下班后有清闲的时间去专注工作。因此，我们有问题的时候，除非是那种需要马上确认的问题，否则建议是先列出问题清单，然后和“上游”同事约个时间一起讨论。这样双方的专注时间都会增加，效率自然能够提升。比如，国外的邮件沟通其实就非常好，通常他们会把沟通的内容用清单列好，然后通过邮件和对方约时间。这种相比IM的方式，虽然时效性不强，但是其实效率会更高。
总结
在产研团队，个人认为团队氛围很重要，往往因为少数人情绪控制不好，结果影响整个团队的氛围。久而久之，整个团队互相看不顺眼，沟通不畅，配合效率大打折扣。如果我们能够像对待客户一样对待下一个环节，以“用户思维”站在对方的角度换位思考，那么很多负面情绪都可以消退，甚至转变为推动认真负责的工作力量，让团队每个人的产出质量更高。当每个人、每个团队需要把下一个环节当作客户去服务的时候，我们的产品研发、交付质量都会得到大幅提升。
