产品经理如何避免被程序员打？

一、沟通能力
任何一个新增需求都不会简单到优化需求那般，单方面和前端或后台或大数据进行沟通就万事大吉了。一般而言，新增的需求都不可避免地会同时触碰到几个开发小组的边界，这就要求产品经理，或分别和不同小组组长进行沟通，或同时拉上几个小组一起进行group discussion。
讨论的话题自然是由产品经理发起，在探讨过程中要求把控好节奏，内容点要足够犀利和一针见血，对于话题跑偏的情况能够及时回正，对于没耐心把解决方案确定的要积极督促。
在和程序猿们打交道的过程中，要对他们辛苦加班码代码所付出的努力表示认同，因为他们觉得自己才是辛苦搬砖的“可怜人”，而你靠着三寸不烂之舌处理处理需求，就可以拿着和他们同等甚至更高的薪水，实在是可耻可恨。当然PM也到处喊冤，羡慕开发可以专注工作，而他们却在头痛地处理不同角色扔过来的各种雷……
因此，嘴巴甜的产品经理更容易获得程序猿们的好感，他们在你去请教技术问题或者沟通需求的时候也更乐意配合。没办法，谁叫你那么招人喜欢呢？
二、PRD撰写能力
产品需求文档是产品项目由概念化阶段进入到图纸化阶段的转折点，其质量的好坏直接影响到研发部门能否明确产品的功能和性能，能否研发出符合预期的产品。如果说沟通帮你和研发部门打开了一扇窗，那么需求文档的专业程度直接决定了你能否打开一扇门。
需求文档的撰写讲究规范性，最好每次都用同一种格式，力求产品的每次迭代的书面标准化。以下是我工作几年的prd写作技巧的分享：
1.逻辑定要清晰
PRD是对产品需求如何进行功能性开发的文字描述。这个产品既可能是一个简单的社交性质的APP，也可能是一个架构复杂的大型web系统。无论哪种类型，都要求产品经理逻辑要足够清晰，将抽象思维进行具象化表达。对于if和if—else的情况要多维度考虑，一些显而易见的逻辑漏洞要尽量避免。在需求评审的时候要批判地听取开发人员的意见，孰是孰非，做出判断后都可以借助软件工具去实现，比如Axure画原型，Visio描述流程图，Excel制作甘特图。
2.表达适当通俗
PRD是面向开发人员的，其专业化程度之高也是毋庸置疑的。有的产品经理为了凸显自己的专业性，喜欢在文档中堆砌大量的专业词汇，致使开发人员在阅读文档时颇为痛苦。这就考验产品经理translate的能力，即一些专业性表达尽量用通俗的语言代替。要记住PRD最重要的使命是便于理解和操作，要让阅读文档的人迅速get到功能点才是一篇及格的文档。如果你在写完文档后不确定是否通俗易懂，在不涉及透露公司机密的前提下，可以发给自己的一些好朋友审阅，让他们多提意见，你也可以借机对文档进行修正。
3.切记突出重点突出重点是将核心功能进行说明，辅助说明尽量简化，有主有次，深入浅出去表达。PRD的内容描述跟我们写的文章差不多，标题进行内容概述，内容进行功能性描述，分析有理有据，总结一针见血。对于重点突出的部分，不仅需要花费更多的笔墨，也要注意和辅助部分的文字说明比例。一些产品经理往往力求完美，拼尽所有脑细胞顾及到每一个细节，但其实这是完全没有必要的，PRD只要把事情讲得明白通透就足够了，无需反复论证。
三、决策能力
产品经理的日常就是不断做决策的过程。在日常工作中产品经理经常会听到这样的话：“这个功能到底怎么做，听产品的。”，“我认为这个界面跳转有问题，但最终的决定权还在产品。”在有利的交谈氛围中，产品经理或许可以听到来自架构小组或者开发人员的一些建设性意见。但事实上，更多的情况是需要产品经理来一锤定音。因为产品经理就是需求的亲生父母。
那么如何正确做好决策呢？
1.积累经验：通过长年对用户、市场、竞品、业务的深耕学习，不断总结来自本行业的实践经验，并结合自己理解提炼出一套系统的方法论。
2.数据分析：依靠市场调研、竞品分析、运营数据、用户调研等，从数据维度上支持自己的决策；
3.团队合作：通过和业务、研发、运营等同事交流，从他人的视角完善自己的决策，进而得出更全面的得出结论。最后，即使你收集了很多信息，可能有的信息还是相悖的，但是最后决策必须是你自己决定，因为你才是最具发言权的产品经理。

产品经理如何避免被程序员打？

猜你喜欢