3个工作技巧让你在产品岗游刃有余

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