别怪技术同学不给力，首先你要搞清楚这几点（节奏盒子研讨会模组）

身为产品经理的同学要明白一个道理：有的时候真的不是技术的同学不给力，而是我们自身没有做好这几点。

转眼又进入了新的一年，经过2018年年终的述职总结，很多小伙伴期望在新的一年里有所改变。

期望团队更加的和产品同心，以更加高效的速度将产品进行推进和落地，比如在原有的合作方式上叠加了各种流程、管理软件，甚至是自掏腰包请团队成员喝个奶茶贿赂贿赂……

(请喝个奶茶，贿赂贿赂……)

然而这一切能解决根本性的问题么？其实作为产品经理我们擅长的就是分析用户的需求，但是我可曾分析过团队其它小伙伴的需求么？知道他们想要什么吗？

我们曾经把技术小伙伴的各种配合当做理所当然，一切都是应该的……
我们很多时候在道德的高点上认为大家都是平等，只是分工不同而已，我们负责产品设计，它们负责实现，就如同你们负责挣钱，我负责美一样的……
我们很多时候是将产品原型设计出来，直接告诉它们怎么怎么做，然后坐在自己的位置上等着收获……
我们很多时候以为以目标为导向最终我们和团队会走到一起去……

最终我们认为的认为的最终并没有成为现实！

其实原因并不是大家不努力，每天晚上熬灯夜战往往也是技术小伙伴。

我曾经近距离的观察过很多团队的做事方式，也看多很多产品经理的工作方法，抗拒技术同学参与产品方案的讨论的都是自己的心理在作祟，在没有实际操作之前就已经给技术的同学打上了各种标签。原因无外乎于以下几点：

一、技术同学不懂业务

关于这点其实是一个悖论“有关技术是否应该了解业务逻辑”虽然早已有了结果，然后实际操作并没有这样。我们暂时先不讨论技术同学是否应该了解业务逻辑，先从现实中的小的案例来说明：

1. 因为不懂业务，技术实现的时候很多小的细节处理的很业余，然后会被产品给教育；

2. 因为不懂业务，所以对于产品所说的产品中涉及的业务逻辑一头雾水，不知所云，产品要死的心都有；

3. 因为不懂业务，技术在实现的时候需要产品做相对详细的注释说明，且在技术方案设计的时候高度参照产品说明文档，需求发生变更，技术同学整个的要死要活的……让产品目瞪口呆。

在日常工作中涉及到技术同学不了解业务逻辑的案例还有很多，可能有些产品同学会说，业务逻辑的科普和我有什么关系呢？

然而实际过程中，很多的业务逻辑是经过产品经理设计出来，现实中有逻辑对照的相对来说较少，也就是在整个的产品开发团队中，产品经理是最了解业务逻辑的，那么产品经理就应该肩负起这个责任。

在这里再强调下：

产品和技术组成团队就是通过业务逻辑的实现来达成产品的目的。

产品并不仅仅是产品经理的，也是技术以及团队其它小伙伴的。这里面有一个价值的认知，我觉得产品经理越早意识到越好：团队小伙伴工作的价值是指交付给用户的价值，而不是自己工作内容的价值！

在此我们可以看到其实大家的目的和价值衡量是一样的(关于这点我在后文详说)，但是在达成这个目标的过程中存在分工的不同，但是大家都是围绕这个业务逻辑来工作的。因此让整个团队都了解咱们的业务逻辑，对于效率的提升和业务的实现是有极大的好处。

业务逻辑的科普并不是靠一次两次的全范围的业务讲解就是可以的，业务逻辑其实是一个相对复杂的事情，囊括了业务流程、行业基本认知、异常等各种情况。

此外随着产品的设计，业务逻辑在某种程度上也在变化。基于以上两点我们知道希望通过一次两次的大范围的讲解就可以解决这个问题是不太现实的。

因此日常关于产品方案的讨论和评审的时候带这技术的小伙伴一起参与，是很有必要的，能够想小伙伴传输业务逻辑，同时对于小伙伴不了解的点进行个性化的讲解，最终的效果应该是很理想。

并不是技术同学不懂业务，而是你根本没有给予人家了解业务的机会；并不是技术同学不需要了解业务，而是你对于技术工作的价值认知是错误的。

二、效率低

认为技术同学参与产品方案的设计会导致效率的降低是产品经理拒绝技术同学参与产品方案设计的一个主要原因，我在很多场合都听到诸于此类抱怨。

关于效率我们需要从多个方面来看待：

1. 让产品方案定性的时间变的更长。这在某种程度上是事实，但是从长期来看它又并非如此。一些工作策略的带入和长期参与的坚持，最终这种对于决策时间的影响应该是越来越小。

产品方案的设计是我们产品经理的主要工作，在某种程度上团队内的任何成员也是替换不了的，因此在关于产品方案的讨论之前我们应该都做过了相对完成的梳理和一定的设计，在讨论之前将这部分内容同步给团队技术同学，使得大家能够提前去研究，最终在产品方案设计的讨论会上，无非就是优化、补充、选择么？并不是任何一场产品方案讨论会都是漫无目的，嘈杂的长达几个小时的会议，早期做好相应的准备难道不是我们的工作内容么？

2. 随着这种讨论会的增加，大家之间的磨合越来越好，也越来越高效，对于流程和方式也越来越适应，最终整体上也在提升会议的效率。

此外我们要看到这种效率的提升所带来的价值，对于我们产品经理来讲是极其值得。那么技术参与产品方案的讨论会带来哪些好处呢？

1. 业务逻辑的科普：所有关于产品方案的讨论都是建立在对于业务逻辑的认知，因此关于产品方案的讨论必定在某种程度上让技术团队对于业务逻辑更为的理解，这点也对接上我们前面讲的技术团队应该了解业务逻辑。伴随着业务逻辑的熟练，在日常开发中遇到了上文所说的业务逻辑问题的时候解决的更为的自主且快速，导致后续的返工或者测试修改的机会变的更少，在一个点花费多一点时间，在后续节省大把的时间难道是不经济的？

2. 产品方案的完善：老话说的好“三个臭皮匠，顶个诸葛亮”，我们知道任何一个人的行为决策都是受自己的认知所影响的，对于我们产品经理也是一样，我们在思维上和认知上都有自我的局限，而这种多人参与，有的时候很好的弥补这个缺点，使得产品的方案更为的完整和可行，举一个常见的例子：

大多数产品经理在设计业务逻辑的时候是希望按照自己预期的结果也做，也就是按照正常的逻辑来设计产品原型，但是如果开发参与产品方案的讨论的时候，他们考虑的很多是边界值、异常处理等等情况，他们往往能够很好的发现我们这方面的业务逻辑缺失。

3. 参与感：几乎每一个产品经理对于小米赞誉有加，几乎都知道小米的七字诀，很多同学也读过黎万强的《参与感》这本书，对于小米产品设计和用户运营思路季度的赞赏，甚至在做产品运营的时候极力的邀请用户来参与产品的设计。为什么我们行为上这么做了，但是却忘记了每天在一起工作的人呢？正是技术小伙伴们参与产品方案的讨论，使得他们感觉到足够的尊重，从而对于产品的推进更加的用心，更愿意去投入。

三、人多意见杂，共识难道成

我们经常说“有人的地方就有江湖”，也有说“众口难调”。这都是客观实际，每个人的认知不一样，自然每个人对于事物的评论也是不一样。

每个人的出发点不一样，自然每个人的方案是不一样。这些都属于正常范围的事情，但是我们并不能因为可能难以达成一致，就放弃做这样的事情，此外也有老话说“事越辩越明，理越辩越清”。

关于这件事情我是这样理解的：

1. 意见管理是一项软技能。对于任何一个在职场上混的人来说，如果的管理各方的意见是一个必备的技能，我们作为产品经理不仅应该具备这项技能并且最好要胜于常人，因为产品经理经常要协调各方资源来达成产品的目的，收集各方需求最终找到普遍性需求并最终实现。因此这难道不是我们关于该技能的练兵场么？

2. 寻求相对最优解。有多种方案多方建议是正常的，我们寻求的是相对最优解决办法，而不是绝对完美的解决办法。这是一个基本的常识，我们很难做一个绝对完美的方案出来，只能从众多方案中挑选出相对最优的解决办法。这里面有一个价值观：“讨论的目的是找到最好的解决办法，而不是我的办法”。

在实际操作过程中我这里面有几个小技巧：

A：如果节奏不是很紧张，两种方案不能很快的判断优劣，是可以采用A/B Test,实际环境中跑一下，最后以实际数据来选择好了。

B：少数服从多数，少数意见保留。这种方式对于商业价值影响不是很大的产品方案问题不大，但是对于重要的节点，这种方案风险太大，群体性决策失误比比皆是。

C：对于没有太实质性的差别的方案，或者影响相对不大的方案，产品经理要学会妥协，适当的采用团队成员的方案是个明智的选择。

最后给大家包括我一个忠告：

作为产品经理的我们的有的时候要能够放的下脸面，以开放的心态，采纳最好的方案，接受别人指出的不足。一方面能够逼迫我们在业务上更加精进，一方面也有利于产品的成长。

成功的产品是我们的代言，成功的产品是我们的脸面，在此之前不要自尊心那么强。其次要学会妥协，产品的推进和落地非一日之功，需要时间的逐步的完善推进，作为产品经理的我们要着眼长远。

四、技术和产品工作的差异

作为产品经理我们每天的工作有着明确的目标，我们的目标并不是今天画了一个产品原型，明天写一个产品说明文档，这些只是我们工作的手段并不是产品层级的目标。

作为产品经理我们关注的应该是新增用户、活跃用户、注册率、转化率等数据性指标。也就是对于产品经理而言我们是以目标达成为目的。

在传统的产品开发团队中(技术不参与产品方案的讨论)技术小伙伴每天所做的工作就是功能模块的实现，在时间的纬度上不停的通过技术来实现业务逻辑，甚至很多时候还会给技术小伙伴来做工作分解，我所见过的工作分解能够细化到某一功能模块的建表，时间纬度可以细化到2个小时的单位，真是细思极恐。在这种背景下技术同学的工作是以产品功能模块的交付为目的。

在这里我们可以看到原本我们以为的大家的目标一致在实际操作过程中差之千里，既然目标都不一致，最终的效果必然是差强人意，才导致最后的“技术小伙伴不给力”。说不定在背后技术同学真在骂“产品狗太扯淡……”呢！

So，并非是技术同学不给力，而是我们打心眼里并没有将技术同学当做自己人，没有给予充分的尊重和同理心。