周末重新撸了一遍《启示录》，工作中的实践，让自己对书中提到的很多场景有了更切身的体会，这篇文章既算是读书笔记，也是对自己工作的阶段性小结。
▸‣ 产品经理的职责
产品经理的本质工作到底是什么？
虽然这个岗位看起来似乎是「零门槛」，但对于这个问题的答案，每位产品经理都会随着经验的不断积累而不断刷新自己的认知。
产品经理的主要职责分为两部分：
1.评估产品机会
2.定义要开发的产品
产品经理需要在最短的时间内把握复杂的市场/用户需求，评估出正确、有价值、可行、符合公司发展要求的产品机会。
接下来产品经理需要：
1.制定产品战略
2.构思产品生命周期
3.设计产品形态
4.竞品调研
如果说以上是产品初期的一些准备工作的话，那么接下来就需要产品经理开始详细定义要开发的产品。
产品的定义包括以下几个方面：
1.产品特征
2.产品功能
3.产品的用户体验
4.产品的发布标准
随着进程的推进，团队的其他角色开始在不同阶段介入与产品经理一起完成产品实现方案的具体设计，并基于既定协作流程完成评审、开发、测试等不同阶段的工作，直至产品上线，并跟踪上线后的产品效果及反馈。在此期间，产品经理需要保证整个团队的信息对称，并对最终的产品负责。
很多产品经理在起步阶段的工作大部分都是写文档以及画一些原型图，需求一般都是上级或者老板直接分配，这个阶段因为对于产品的认知很浅，制定产品战略这样看起来很"玄"的工作其实也很难做到，此时不妨静下心来做好这些基础的执行工作，除此之外，让自己持续保持学习和思考的状态，根据产品经理的职责标准来要求自己，当有一天你发现自己有能力思考并完成职责中的大部分工作时，你已经从初级进阶了。
▸‣ 产品原则
在公司，每周产品内部会有一次例会，每一位产品经理会向大家介绍自己接下来准备完成或者已经在设计中的产品或功能。一方面便于内部的信息同步，另一方面也可以听取其他人的建议和想法。
会议形式本身没有任何问题，但时间久了之后自己发现，会议的效率和效果有时却无法达到预期，这是因为需求的重要性和必要性经常无法确定，大家各抒己见，导致讨论没有结果，同时因为很多开发资源共享，经常是谁先进行需求评审谁先获得资源，这就导致有时一些紧急的需求因为开发资源不足只能延后排期上线。
产品原则是对团队信仰和价值观的总结，用来指导产品团队作出正确的决策和取舍。
如果团队内部有清晰的产品原则，那么在每次的例会上，就可以快速的定义产品功能的优先级和必要性，彼此达成共识，快速做出产品决策。
制定产品原则意味着从重要性、原则性、战略性、战术性等几个方面来进行产品决策，它是整条产品线的战略指南，一套价值判断的框架，帮助公司作出正确的决策。不过要注意不要把产品原则和设计原则混为一谈，用户的操作路径和交互形式等并不是产品原则。
▸‣ 产品文档
除了一些职能划分清晰的大型互联网公司以外，相信很多产品经理都是边写需求边画原型边做交互，先不要抱怨这些是否都是属于你的工作，因为产品经理掌握任何一项技能似乎都是理所应当的事情。
Marty Cagan在书中给出了理想的产品说明文档的几个要素：
1.完整地描述用户体验：包括需求、交互设计和视觉设计准确地描述软件的行为
2.直观的把产品信息和行为告诉所有人，因为产品文档的受众广泛，开发、测试、市场、销售等都需要了解
3.可以修改，开发或者设计中经常会碰到意象不到的细节或者逻辑问题，产品文档需要随时修订
4.产品文档会出现很多衍生物：需求列表、线框图、实体模型等，需要选择一个主体来代表你的产品
上述的几个要素中其实也包含了其他团队角色需要完成的文档，比如交互设计稿、视觉设计稿等等。作为产品经理，我们经常会问产品文档如何写才最好，模板可以给我们提供参考，但一定要适合自己的团队并保证每个人可以快速理解并提出问题。毕竟，你写的不是日记，只要自己看得懂就行。
▸‣ 又要重写代码？
最后谈一个跟管理有关的问题，也是自己这段时间感受比较深的一个现象。
因为之前的开发节奏紧张，连续很长一段时间为产品增加了几个大且逻辑复杂的功能，因为没有太多时间对代码结构进行很好的设计，导致后续的一些产品功能出现了维护困难，且问题频发的状况。自然而然的，我们将问题归咎于开发团队的技术能力问题，而这类问题的本质其实是产品管理失误。开发团队一直处于满负荷的工作状态，不停的在开发新功能，无法保证代码的质量和架构的稳定性。最后技术团队开始对代码进行重写。
Marty Cagan举了eBay的例子，与开发团队合作在产品管理上要为其预留20%的自主时间，这个技术能力称为余量（headroom），由开发人员自由支配，可以重写代码、完善架构、提高系统性能等等。
『 产品经理是个看似简单却又最难琢磨的岗位，需要时刻对产品保持关注、思考和反省，而这个最耗费时间和作内容，却往往被我们所忽视 』
公众号传送门：大喵的设计瓦罐
