职场|B端产品职场：拒做背锅侠，轻松赢得认可( 二 ) 业务|产品|需求|

毕竟我们做产品是跟人打交道，投诉还是表扬也都来自于日常的业务对接人。所以要学会帮助业务对接人获得更大成功，他自然会认可你。
给几个具体可执行的方法：

帮助他完善业务需求里有问题的地方；
提供其他竞对的业务策略和方案；
述职时提供需要的产品数据和方案；
在项目庆功会上多替他邀功。

3. 提前考虑风险，同时降低预期产品执行过程中经常会有各种风险，处理不好就容易引发投诉。一般产品风险就2点，一是资源问题导致的延期风险，二是历史包袱和项目时间有限等导致的产品上线效果达不到预期。
具体可执行的建议：

项目排期时给出buffer：举例，一个需求正常是开发加测试一共需要8天，那给业务侧承诺时建议是11天。
及时暴露风险，与相关方达成共识：举例，项目资源有限，临时有高优需求插队时，需要第一时间找到业务方说明情况，同时拉上插队的业务方和你的业务方一起沟通就资源问题达成共识。
项目前期，明确项目目标及预期：举例，关于客户数据重构的需求，短期内无法实现业务终极目标。这时需要在前期跟业务侧就项目的推进节奏和各个阶段的目标及预期达成共识。例如一期先保证业务侧有数据可看；二期考虑做数据可视化的图表，让业务侧更直观高效的通过数据发现问题；三期考虑做数据分析及诊断建议；四期做销售拜访策略及话术推荐等等。

4. 信守承诺这个是基本要求，不多说。例如承诺了上线时间，就一定要按时交付上线。
5. 做好各类沟通信息的留档，避免恶意甩锅
有备无患，针对项目过程中的重要决议和信息一定要注意留档，主要是邮件确认。这样即使被恶意甩锅，也有证据翻盘。
6. 建立私交
人毕竟是感情动物，私交好自然会更加宽容。所以平时有机会可以跟业务对接人一起吃吃工作餐，微信聊聊兴趣爱好。
说了这么多，听着电话那头的小A喝了口水。继续说道：“其实这几点也同样适用于跟老板、开发等等，总之做产品，天天与人打交道，套路挺多的。 ”
小C：“哈哈，与人斗其乐无穷，我这道行确实还是太浅了。哥儿，你接着跟我说说怎么搞定开发呗。 ”
三、开发投诉产品的常见原因
小A：“开发投诉产品无外乎就是这6点：

不懂技术，经常搞些稀奇古怪的方案。就像之前平安产品要求APP随手机壳颜色变色被开发暴打；
产品方案变更频繁，尤其是开发过程中变更；
产品方案写的太烂，产品逻辑混乱，信息缺失严重；
讲完需求就当甩手掌柜，只知道追进度，不负责沟通协调；
无底线压缩开发工期；
产品上线效果不好，影响开发绩效。

小C：“哈哈，我有个同学是做开发的，上次他跟我吐槽的就是这几点，简直一模一样。不过这样说来，我确实也存在上面的这些问题。 ”
四、如何赢得开发的认可
小A：“其实开发比业务运营更好搞定，毕竟大部分程序员都心思单纯，真诚呆萌。只要做到下面几点，轻轻松松赢得开发认可。 ”
1. 以开发视角来写产品方案
编写产品方案属于产品基本功，关于产品文档要逻辑严谨信息完善等这里不展开说。
关键是要学会换位思考，站在开发视角写方案。
举个例子：
同样2个产品，一个是每次把产品变更点直接写在文档正文里。另一个是将变更点写在文档正文里用红色字体重点标识；同时在文档最上面有个变更记录登记，写明了具体变更时间、变更内容、变更原因等等。
如果你是开发，会更喜欢哪个产品？
2. 勇于承担，让开发专心写代码
开发大多不善于沟通协调，只想专心敲代码，所以作为产品要承担相关的沟通协调工作。例如需要上游提供数据接口这些问题，产品应该主动联系上游拿到接口及接口方案。
3. 小心处理需求变更
作为产品在前期调研和方案输出时，要尽量一步到位。但需求变更是难免的，所以一旦出现变更时：
1）首先，态度要诚恳，即使是业务引发的变更，也需要跟开发说明致歉。
2）尽量弥补需求变更为开发带来的影响。例如变更后，可以适当将排期延迟。前脚说完需求变更，后脚就催着要按期交付，这样的做法开发不吐槽才怪。
4. 合理安排工期
开发也讨厌996 ，所以不要动不动就压缩工期。
1）基于需求的紧急程度合理安排工期，普通需求就正常排期。同时明确表达出这一点，让开发知道你是个关心他们身体健康的产品；
2）紧急需求，拉开发老板一起沟通，由开发老板来决定是否加班；
3）面对不靠谱的开发，恶意拉长工期的情况，那就直接拉着开发老板一起沟通。
总之，产品虽然是无组织的领导者，但是涉及到加班等问题时还是要把权利交给真正的组织管理者。
5. 帮助开发成功
现在开发的晋升述职对项目产出、业务理解、方案呈现都有要求，但大部分开发不善言辞，不善写作，不了解业务。而作为产品正好能给予这方面的帮助，给几个具体可执行的方法：