此文章为转载

产品经理是否该确认开发人员提供的工作量？又该如何去评估呢？

众所周知，完美的团队构成里有产品经理，也有项目经理，产品经理和项目经理可以各司其职，开发Leader具备很强的产品意识，整个团队很凝聚。但现实往往是，产品经理需要兼做项目经理的工作，开发Leader也只关注开发团队的工作内容和产品质量。

那么问题来了：

产品经理应不应该确认开发人员提供的工作量？又应该如何评估？

以下将针对这两个问题展开笔者的看法。

为什么要确认工作量

笔者认为，在每次迭代的需求评审完成后，产品经理是一定要确认开发人员提供的工作量的，原因很简单：产品经理和开发人员思考问题的出发点是不一样的。比如：

每个产品都有战略目标、里程碑、运营压力、KPI指标等开发和测试人员可能并不太关心，而产品经理非常关心的东西；
对开发团队来说，用足够的时间保证当次迭代的质量是最重要的。
那么，从开发的角度看，完全有理由评估出让产品经理大跌眼镜的工作量，这个时候，很多产品经理会出现这两种做法：

一是对内发火、对外抱怨
二是根据开发人员提供的工作量排期，其实两种做法都不可取。
首先开发并没有错，对内发火对外抱怨的做法只会导致团队合作出现更多问题，而不闻不问更可怕，很容易出现需求无法上线、交付延迟、产品目标无法达成的情况，这样是无法让一个产品良性发展的。

如何做

面对产品经理和开发人员的思考鸿沟，可以引用《高效能人士的七个习惯》里的习惯四五六来解决这个问题，即：Think Win/Win、Seek first to understand, then to be understood、Synergize。

可以简单理解为：

一定要有双赢的思维，寻求双方都满意的解决方案。
当双方发生意见分歧的时候，首先分析双方的分歧点，然后先去真心理解对方，再尝试被对方理解。
在上述两点的基础上，寻求新的解决方案。
那么，针对本文讨论的这个实际问题，如下是笔者的个人看法。

价值沟通

无论是在产品启动，还是需求评审的时候，产品经理一定要和团队所有成员描述产品的战略目标、运营目标以及每个需求的价值和意义，而不是一味的只描述需求的实现和功能逻辑。

当然，会有产品经理提出疑问：我这样做了，但是开发人员并不关心，所以是在浪费时间，还影响心情。

在笔者看来，这样做是利大于弊的。

首先，只有和团队讲了目标，团队在评估工作量的时候才有可能去考虑这个目标，否则连这种关联思考的可能性都不会有；
其次，这样长期的坚持比较容易培养团队的主人翁精神，在这种情况下，开发人员在评估工作量的时候，会更容易去考虑产品目标；
最后，作为一个团队，产品经理是有责任让所有人清楚产品的状态和目标的，腹黑的讲，在产品出现比较大的问题，领导问责的时候，开发人员惯用的“并不清楚这个需求的重要性和优先级”之类的理由将无法再站住脚。
换位思考

产品经理首先要坚定的认为：开发人员评估出的比较夸张的工作量并不是一件错误的事情（需要排除掉外包人员恶意夸大工作量的情况），因为他们的出发点是用充足的时间来保证产品的质量。只有在这个基础上，我们才能发自内心，友好和平的和开发人员进行下一步的沟通。

友好沟通

在理解了开发人员的基础上，产品经理可以开始尝试让开发人员理解自己，最简单的就是用KPI和业务压力来和对方沟通，引导双方往互相理解的方向走，当然还有一个办法，就是拿领导当挡箭牌。

这里有一个沟通的技巧，就是沟通开始，先向开发人员表示我们完全理解他们给的这些工作量，让他们觉得我们并没有站在他们的对立面。

任务分解

在以上的基础上，针对实际的工作量，产品经理可以要求开发人员将需求进行任务细分，评估出每一条任务的工作量，并且每一条任务尽量不要超过一天，然后针对每一条任务进行工作量的沟通。

根据经验，这是一个很有效的方式：

首先，对于比较简单的需求，当开发人员去做分解的时候，一方面是分解不出多少任务，另一面是针对任务这个级别，工作量是否夸大就比容易看出来。
其次，如果对某个需求或任务的工作量有疑惑，一定要让开发人员描述为什么需要这么多工作量，如果开发人员能够说的很清楚，那基本可以认为确实需要这些工作量，但有很多情况下，开发工程师是无法自圆其说的，这个时候很大程度上说明工作量被夸大了，这个时候，开发人员一般都会自降工作量。
在工作量沟通方面，产品经理如果有技术背景当然占有很大的优势，对于没有技术背景的产品经理，笔者建议最好稍微了解一些基本的技术，网上有很多面向产品经理的技术科普。当然，对一条需求到底需要多少工作量，即使没有技术背景的产品经理，随着经验的积累，也会有大概自己的判断。

另外，开发人员在日常工作的时候，很容易被很多其他事情打断，这也是开发人员经常抱怨的事情，因此在工作量评估的时候，我们需要考虑到这点，根据笔者的经验，以一天8小时的工作为例子，每天5、6小时可以做全职开发来评估工作量会比较符合实际情况。

外包情况

如果开发团队是外包，这会是一个比较特殊的情况，首先，产品经理很难让外包人员去认同产品价值，另外，很多外包人员存在同时为多家公司服务，但是甲方并不清楚的情况。而且，根据经验，外包人员提供的工作量一定是非常夸大的，根据笔者以往的经验，二倍甚至三倍都是有可能的。因此针对外包情况，笔者的建议如下：

有条件的话，最好由甲方开发人员来评估工作量，或者甲方提供一个技术支持来评估外包开发人员提供的工作量；
没有条件的话，就是用上面讲的任务分解去和外包开发人员沟通，因为是乙方的性质，所以在沟通上，甲方产品经理可以稍微强势一点；
无论和乙方如何沟通，一定要抓住问题的根本，不要被忽悠。外包公司一般都加班很晚（笔者曾经遇到一个外包团队，连续一个月加班都凌晨），然后和甲方沟通的时候，会让甲方觉得是因为甲方的过重工作导致他们加班很晚，这个时候产品经理很容易被忽悠，所以一定要注意，还是根据分解后的任务来沟通，让乙方开发人员来描述为什么需要这样的工作量，或者工作量花费到了哪里，大部分情况下，最后沟通的结果都是乙方自己砍掉一半的工作量，或者说不清楚工作量花费到哪里去了。
最后很重要的一点，笔者目前所在公司和外包团队签合同的时候，并不会让产品经理参与，另外，产品经理也不会负责外包团队的考核，那么，也即是说，产品经理针对外包没有任何管理实权，这和与自己公司的开发人员合作的方式不同，如果是外包团队，那么合作方式就是合同，就是甲乙方，所以针对这种情况，建议产品经理向公司要求实权。
总结

以上只是笔者根据经验，对产品经理如何面对开发工作量的一点浅谈，欢迎大家一起思考沟通。