【起点精选】3个工作技巧让你在产品岗游刃有余
曾经一度错误认为，产品经理的日常就是连环撕：撕运营，撕完运营撕设计；撕设计，撕完设计撕开发，好像产品经理为了捍卫产品思路一直在做抗争，永远都是对方傻，对方没明白，对方无理，对方太闲。
这一年半的产品工作，教会我学会理解不同角色的焦虑和怒点：顶着kpi压力但不知道实际开发进度的运营喵，费神费脑把功能赶出来却被告知需求又改了的程序猿，有交互和视觉追求和坚持的设计狮，还有八九份合同还没看的法务兔……
很多沟通上的易燃易爆点，产品汪其实是可以把控的。产品经理的职责就是清晰表达需求，高效推进项目。让各个岗位角色都顺畅沟通舒畅干活，最终达成目标。
对于0-2岁的初阶产品经理，如果能做到以下三大工作技巧，会成长得很快：
一、PRD
网上有很多需求文档模板，产品经理入门最快的手段就是从前辈实操过的PRD中学习表达需求。同时，为了加快输出需求文档效率，我常常会更新我的需求文档模板，拿来就用。
小结一下就是：创建你自己的需求文档模板，尽量让下次的需求少一点会被diss的漏洞，更有条理更清晰明了。这里提供我目前的模板，仅供参考：
1. 文档基础
（1）文档性质
因为文档输出的时效性要求非常高，不能仅为了文档的门面就耗费太多时间，所以PRD的格式不限，可以是doc、xls、rp等，只要能“清晰表达需求”即可。一个需求内容，我可能会根据实际情况用多格式文档互为补充。
其实这里用了“组件”的思维，完整的需求表达由很多个模块组成，每次有更新，就更新该模块即可，对接人按需使用。
（2）文档命名
《【文档性质】需求名称（备注） 文档版本号_需求人名字_更新日期》，当需求本身和文档分别有版本号，两个版本号又比较重要时，我会把文档版本号放在最后。文档版本号不是特别重要时可不写。
（3）修订记录
这是非常容易忽略的细节位，很多人没养成好的工作习惯，工作就会很混乱，效率很低。每一次修订需求材料，就应该及时做相关标注。更新的频率不定，只要需求有少许变动或者补充，我都会做一次文档更新，作为留底。
（4）页眉页脚
当文档某一页被打印或截图出来，你是否能快速知道这是哪一份文档的第几页内容？
2. 文档结构：
（1）需求概述
产品经理可能要对接多方需求，如果对方只是“一句话需求”的时候，就可以让需求提出方先按以下格式梳理需求，然后你再输出后续的方案。
这些内容都是重要铺垫，需求文档就是要让每一个参与项目的人都能了解需求的全貌——需求是什么以及它的目的和价值是什么，避免让参与人员仅仅成为需求的执行者，你需要让划桨的每个人知道这条船究竟要驶向何方。
名词解释
需求背景（包括需求来源、需求目的、需求价值）
产品概述（包括产品简介、基本原则、基本思路）
竞品分析
投放渠道
性能要求（包括网络连接、手机操作系统、消息推送系统、后台数据库、服务器操作系统、系统吞吐量等要求）
资源引入（包括资源提供方以及具体介绍）
（2）业务流
原型只是需求内容的一部分，不要让自己掉入原型无法自拔，要关注需求的全貌。
需求清单（项目较小时，我会在文档内简单罗列；项目较大时，我会专门用一个表格文件来梳理。）
需求详述（包括通用、细分的详细说明，原型图可在此处辅助理解需求。注意兼顾常规流程和异常流程，尽量让设计、开发和测试没法找茬~）
流程图（当一个需求看似很简单，一句话就表述完成时，那建议你先去画画流程图，忽略的方面自然就会显露出来。）
设计需求（包括风格取向、色系取向、形象标识、其他设计要点等，让设计发挥之前，你需要先考虑你想要的是什么，避免来回改动。）
（3）后台支撑系统
需求写到这里，可能你也累了，但要坚持下去。
数据统计需求（具体内容我通常会放到数据模板的xls里，数据模板包括数据字段名称、定义、报表接收名单、修订记录等。）
配套的配置系统（视各平台业务而定）
（4）安全基础
原型只是需求内容的一部分，不要让自己掉入原型无法自拔，要关注需求的全貌。
压力测试要求（视需求的影响范围，参与压力测试，保证整体链路的内部系统达到压力测试要求。）
压力测试流程（因为是我比较陌生的领域，所以做好相关备注，每次按流程来做。）
历史压测结果参考
（5）资金流
我通常会把信息流放到业务流一并梳理，资金流涉及实际的金钱流向会专门拎出来。
对账范围
对账单
对账数据规范
查错处理
（6）技术对接
技术细节注意点会标注在这个板块。开发中出现新的问题以及对应的解决方案也可以写在这里。
（7）运营规则
产品成型后，要制定运营策略。
法务规则（合法是基础。平台协议、产品纪律等有时会是产品盲区，特意留了这个板块提醒自己要全面思考需求。）
产品运营规划
运营工具
客服文档（提供给客服人员阅读的产品介绍文档。）
（8）附录
记录需求材料中涉及到的文档名称。
以上是需求文档内基本的要素，使用时因根据需求本身按需使用，确实不涉及的领域可以不填。
二、需求池管理
近一年我的工作范围较广，属于多领域尝试，所以需求来源非常广泛，但并不影响我成为部门内高产出的代表。这非常依靠沟通、协调和需求管理能力。
我曾经是石墨的忠实粉丝，在管理UI设计和前端团队的需求时，就开始有意识培养团队共同完成排期管理表，到现在他们也一直在沿用。
后来腾讯文档出现之后，屈服于企鹅家的社交关系网，我就转用它来与对接方进行需求池的整理（虽然线上编辑功能还不是太完善，但满足基本的编辑需要）。别看它是个简单的表格，细节上的用处非常多：
每周发出此表的更新版，让需求提出人、需求对接人（产品经理）、需求执行人（设计、开发等人员）可以自行查阅相关需求在整体中的进度、优先级等。
我在表格后面设了一列自用的“上线月份”，每次填月度考核时，就导出表格然后筛选考核月份完成的需求，就不怕自己记性不好会漏掉成果。
“需求提出时间”就能知道项目拖延程度了，如果是个人原因，就要注意做好需求优先级的考量和需求清理工作。要记得，做到清晰表达需求也是为了高效推进项目。执行力是产品经理的必备技能。项目推不动，就是你的不作为。
三、不断学习
虽然产品经理不用手把手敲每一行代码，但需要补充程序思维。程序猿在面对一个问题，除了已有的经验，可能更多地是依靠搜索解决问题。
一句“Hello world”开启的是全球知识资源的互通，只要不故步自封，多主动去挖掘有效资源，网上有那么多免费或者付费的知识内容（需自己筛选有价值的），个人增值的途径还是有很多的。平时多逛逛技术的社区，培养对程序猿的崇拜感（哈哈哈哈哈哈）以及共同语言，对技术的敬畏可以让你变得谦逊而不是趾高气扬。
而培养自己的产品感，就要多体验多思考：抖音与赌博之间的相似点是什么，上传在抖音和微博的视频各有哪些编辑区别点，为什么在支付宝付款码页要露出一个不可点击跳转的会员等级信息，为了用户留存小程序们都做了哪些心机动作，还有好多类似于牛奶经济学一样的产品学问。
《人人都是产品经理2.0》中提到产品、开发、运营三者的关系：想清楚、做出来、推出去，在产品设计之初，就应该远虑，产品诞生不是最终一环，被市场认可需要很多的运营手段。所以产品经理也需要学习社会新出的运营花样，再结合到产品设计中。
我是以产品为核心，运营、开发为新触角作为自己的发展方向，虽然离“全栈产品经理”还有很长一段路要走，但这个时代，属于年轻人的机会太多太多了，加油~
写在最后：需求从提需求到上线究竟经历了什么：https://weibo.com/tv/v/GcHote2L4?fid=1034:d9cc17f3761874df3990a40806548d3e
本文由 @婉盈不是这个莹 原创发布于人人都是产品经理。未经许可，禁止转载
题图来自 Pexels ，基于 CC0 协议
