中准网
产品经理的八个良好工作习惯
  或许好的产品经理不只是这八个良好的工作习惯,但,你做到了么?本文是关于作者的产品笔记,值得一读。
  1. 维护一份竞品跟踪文档
  竞品分析是一个长期、繁重、琐碎的工作,而不是在刚接触产品时,写一份文档就丢在一边。维持一份长期的竞品分析文档,保持对竞品的关注,不仅可以从中分析竞品的策略。竞品跟踪主要从以下三个方面来看:交互变化、功能迭代、战略变化。
  2. 维护一份产品全局文档
  年初我刚接手现在在做的产品时,踩了很多坑,当然现在也还在持续踩。当时几乎没有文档,而仅存的文档不仅数量稀少,而且过时(跟实际情况有较大的出入)。当时想要知道一个功能的实现逻辑,只能靠自己手工测试,或者让程序员去查看代码,效率十分低下。
  除了被别人挖的坑埋了之外,我也做过自己挖坑埋自己这样的蠢事···在做版本迭代的需求的时候,自己是非常清楚上下文和用户场景,以及在细节处的实现逻辑(要知道在实现过程中,总是会临时做出一些不在文档范围内的小调整),由于调整比较小,所以也没有体现在文档中。于是出现了在几个月后,想不起来当时的实现逻辑的情况···
  鉴于以上的惨痛经历,我开始维护一份产品的全局说明文档。在这个文档中说明版本的大致迭代情况、各个模块的现状和调整。
  在实际情况中,我建议你的产品全局文档不用写的特别长,妄想把所有文档都集中到一个文档中,我建议你只在这个文档中说明『变化』和相关文件的地址。
  另外,在云笔记中保存文档也是一个不错的主意,这非常利于及时修改和查看。但是切记要备份。
  3. 横向记录版本:版本的需求文档
  请注意自己的需求文档的阅读体验。
  好好写需求文档。
  好好写需求文档。
  好好写需求文档。
  重要的事情要说三遍。如果你觉得这个不够重要,请你去翻一下产品的历史产品需求文档再来说话···
  结构不清晰的产品需求文档,不仅会虐死你的继任产品经理,还有可能虐死自己。请在写文档的时候,务必注意格式,注意错别字,注意结构。确保文档语句通顺,且能够完美的表达你的想法。
  4. 纵向记录版本
  从时间轴上,记录每个版本的基本信息和概况与上下文
  之前已经说了,对竞品的迭代要保持关注。但同时也要对自己的产品的迭代进行记录。这个记录包括了每次版本迭代的内容和相关信息,以便于以后查询。
  5. 需求池
  维护需求池,而非收集所有需求。
  在平常工作里,你一定都会收到来自很多同事或用户的改进建议,千万不要弃置一旁,也不要立马将需求加入需求池。多和提需求的同学沟通一下,了解一下需求的上下文、场景等,从多个维度对产品进行评估,如果需求足够重要就将它加入需求池。
  注意要用多个维度对需求进行衡量,建立上下游都认可的衡量体系。譬如隶属的功能模块(不同模块有不同的重要性和优先级)、紧急性(影响程度)、重要性(覆盖面)等等。
  6. 记录需求的场景与上下文
  这个本来是要归到『好好写需求文档』那里,但我觉得很重要就另外抽出来了。
  我知道需求文档是给技术部的程序员看的,而大多数情况下他们并不 care 你需求的上下文、场景和合理性,但是,不管他们是不是 care,你都要记录下需求对应的场景,好记性不如烂笔头,千万不要过度信任自己的记忆力。
  7. 良好的文件管理习惯
  所有的文件,一定要好好管理,分文件夹摆放,定期备份,及时清理。
  不经历一次找不到重要文件的事情,你就不知道好的文件管理习惯有多重要。
  8. 指导全局的文案风格文档
  一个产品的文案会出现在产品的各个角落,一个统一一致的口吻,有助于塑造一个优质的品牌形象。而前后不一致、不礼貌、不细心、冷冰冰的文案风格,将会极大的影响用户体验。
  而最简单的解决方案是,将文案风格用文档的方式确定下来。哪怕团队只有你一个人在负责产品,也一定要写下来。写下来,那就是准则。被遵守的机会也更大一些。
另一篇 下载 复制 搜一下
建站大全赚钱大全