直觉告诉我，一定是某个RD又被PM逼疯了。不能接受的话，可以询问一下主要的工程量在哪儿，PM是否可以做些什么，好加快进度？技术难点是否需要和组内leader一起讨论一下，必要的时候PM可以再进一步精简方案等。究其原因，主要是两方面：客观原因和主观原因。如果说研发同学最恨的是什么，那“不确定性”一定能够名列前茅。经常听到工程评审时候，PM以这些词汇开头“我觉得”、“我认为”、“我想”、“我猜”……
职场没有彼岸，只有在路上，且行且珍惜~
还是在几年前，一个普通的工作日，我正准备完成滴答清单上今天最后一个任务-清理邮箱。此时一封“情感丰富”的邮件映入眼帘，“U CAN U UP, NO CAN NO B B”。
直觉告诉我，一定是某个RD又被PM逼疯了。
想想也挺有意思的，这几年的工作中，不断重复上映着类似的一幕。
下面我们就看看这五个小技巧, 有那些亲还没有“掌握”？
第一招：高山流水
“这个实现起来，应该很容易吧！”，一个怀疑的小眼神，像激光一样在RD身上扫来扫去。
这句话的潜台词是：你最好给我的工期短一些，否则就是你能力不行！
这句话不是不能说，是要分谁说。
如果是该RD的leader，研发总监之类的说，有资格。为啥？因为他了解开发原理、理解开发过程和熟悉工程代码现状。
如果是你说，就不行。为啥？你不懂开发啊~
越俎代庖不但不会拿到好的结果，还会暴露你的情商。有的人会说了，我也是为了给对方点压力，尽快上线给公司创造价值啊。
这个出发点是没有错的，有问题的是方式方法。
例如：先不着急下结论，听听对方给的排期自己是否能接受？不能接受的话，可以询问一下主要的工程量在哪儿，PM是否可以做些什么，好加快进度？技术难点是否需要和组内leader一起讨论一下，必要的时候PM可以再进一步精简方案等。
第二招：绵里藏针
“那个，实在不好意思啊，这儿在改一下哈~”，娇滴滴的一个小女生面红耳赤的望着RD（有的时候确实是半蹲着，好吧其实是跪着~）、
频繁的改需求，你的形象值出现了赤字。
究其原因，主要是两方面：客观原因和主观原因。
前者，典型案例如下：
- 老板临时要求 ：提前做好预期管理，充分沟通，一般是可以避免的。但如果真遇到了老板不方便说（eg.资金压力），或者还处于试用期的你，就先强调执行力吧（在做了充分沟通的情况下）。
- 业务变更了需求（部分修改）：重点在于引导业务同学关注目标，只要是当前方案能解决业务痛点，达成业务目标，产品应坚持不调整或下个版本调整。
- 业务反水（全盘否定）：利用业务评审会、会议纪要和测试验收充分做好风控流程。
- 技术瓶颈：很多技术难点是在开发过程中暴露出来的，这种情况下的修改产研双方都能理解，重点是最大程度的复用方案，将工程资源浪费降到最低。
后者，主要是方案设计能力出了问题，出门左拐看《写给RD的一份情书-PRD》.
没有人敢承诺开发过程中方案一定不会发生改变，但是发生频率还是可以控制的，以上概括起来就三点：
- 尊重过程
- 关注目标
- 严谨负责
第三招：八步赶蝉
“兄弟，啥进度了？”
经常看到小白产品，不是钉钉催，就是跑到工位问，要不就用老板压。
说真的，没必要。
你可能会说了，站着说话不腰疼，不催领导找我要进度，我怎么说。
不是不让你催，而是不建议你“愣头青”式的催，可以试试“灰度催工法”。
具体如下：
- 针对信用值高且技术能力的强的大牛，你根本就不用催，这些人把职业形象看的比什么都重，你的催促除了给对方带来反感，伤害彼此的合作信任关系以外，不会有任何效果。
- 针对信用值高但技术能弱的研发，其实也不用催，为了他的信用值，他自己就会想办法保证进度，你根本不用操心。
以上两种都比较省心，最怕的是信用值低的研发（无论其研发能力如何），需要费些心思。
例如：
- 可以询问PRD是否有不清楚的地方，自己可以在单独给详细讲一下，捎带在确认一下进度；
- 工程开始时候，可以参与工程早会关注进度，哪怕是催图这种事也要积极参与，营造一种重视感；
- 公开场合赞扬改研发，并“无意间”提到排期，以便引起对方的重视；
- 通过roadmap,倒逼时间，提醒QA同学，利用团队的压力避免其失信；
- 和其领导强调该工程的意义，并确认时间。
项目管理用情商，关注进度重技巧。
第四招 ：雾里看花
“这个PRD里竟然出现了【可能】！！！”RD抓住了自己本已稀疏不多的头发说道。
如果说研发同学最恨的是什么，那“不确定性”一定能够名列前茅。因为，在研发的世界里，开发的过程就是将PRD里的内容翻译成高级语言，再由计算机讲高级语言翻译成机器语言执行的过程。
研发最愿意花时间的地方是“研究如何用高性价比的方式实现需求”而不是“理解这是个什么玩儿意儿？”
想象一下，一名出色的翻译官面前站着一个“外国人”和一个“外星人”的画面，你就应该能理解我在说什么了。
你的“不确定性”，是在扼杀RD的青春（如果他们还有的话~）。
第五招：鹞子翻身
“这TM弱智也能看出来设计不合理”，胖胖的RD开始嘟哝着。
经常听到工程评审时候，PM以这些词汇开头“我觉得”、“我认为”、“我想”、“我猜”……
腾讯UDC提出来的一个概念，有源设计，即坚持每个方案决策都有依据支撑。
深以为然。只有坚持有源设计，这种科学的决策方式，PM个人才能在工程团队中建立起来专业的形象，成为大家嘴里的“靠谱人士”。
经过多年的被喷经验，我总结了如下几个打死都能说得过去的决策依据，仅供参考：
- 数据 ：用数据说话，这个一般不会有人质疑，除非你的数据本身经不起挑战。
- 调研：只要样本量和质控制好了，可信度是很高的（京东的物流就是这么决策的，见《创京东》）。
- 竞品：只要是选择的是一直表现不错的竞品，用好MVP,被挑战的可能性不大。
- 标品：一句话，这是用户的系统习惯，你不应该也没必要去改变。
- 专家：代表着未来，老板支持就干呗。
- 老板：还用问？
有源设计，不要意淫。
最后，老生常谈一下。职场没有彼岸，只有在路上，且行且珍惜~
本文由 @吴天 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自Unsplash，基于CC0协议
,
