本人是一名程序员，工作中经常与PM打交道。PM与程序员的关系真的是相爱相杀。
如果没有PM，程序员就是空有一身编程的本领，但是不知道该干啥；如果没有程序员，PM也只能空有一肚子想法，无法落地。说白了，谁也离不开谁。
可是呢，日常工作中却又总会相互嫌弃。PM会质疑程序员工时以及排期的合理性，程序员则会抱怨PM需求不合理。
我也会经常和一群技术兄弟们吐槽某个PM提的需求太离谱，有时甚至一边干着活，一边嘴里面骂骂咧咧，恨不得当初直接拒了这个需求。事实上，技术侧确实有权力去质疑需求，也可以将需求打回，我们的需求预沟通以及需求评审环节就提供了这样的机会。
然而，大部分的需求评审会最后都以评审通过结束，为啥呢，程序员提不出有价值的质疑意见。好在，我在一本书里面看到了有人教程序员怎么在需求沟通的时候质疑PM，下面就是样例：
1. 每次对方讲完PPT
为什么要做这件事，不做会有什么影响？
2. 看到对方从总体KPI分解出的目标
这是用户的目标还是我们的目标，是不是老板的目标，老板换了怎么办？
3. 看到对方从用户需求出发，引用了一个观点
这个用户有普遍性吗，能代表多少人，这类用户对我们的优先级是什么?
4. 看到对方引用一条数据来证明自己的观点
数据来源是什么，什么时候获取的，是如何采样的?
5. 看到对方规划写得太实在，都是项目方案
为什么没看到这个产品线的大图，5年后这个产品是什么样子，你实现整个图景的路径是什么
6. 看到对方写得太虚，都是画大饼
未来的确很美好，但怎么实现？现在如果只做一件事，最重要的是什么，你打算怎么做?
7. 看到一个运营方案需要资金预算
你能给出量化指标吗，ROI是多少，这笔钱真的能用在最看重的用户身上吗?
8. 看到要做的事情太多
这么多事情，你打算组建多少人的团队，他们都需要什么能力，怎么分工？如果只给你两个人，怎么办？
9. 看到要做的东西真的很吸引人
实现路上会碰到的最大问题是什么，你打算怎么解决？需要大家怎么配合你?
10. 看到具体项目
你这些项目需要占用的开发资源有多少，如何给技术同学带来成长和成就感？
当然，程序员提出质疑的出发点应该是让需求更加合理，而不是刻意刁难PM同学。毕竟，真得惹恼了PM同学，不给你提需求了，你也慌。
