1、维护一份竞品跟踪文档

竞品分析是一个长期、繁重、琐碎的工作，而不是在刚接触产品时，写一份文档就丢在一边。医微达觉得维持一份长期的竞品分析文档，保持对竞品的关注，不仅可以从中分析竞品的策略。在医微达看来，竞品跟踪主要从以下三个方面来看：交互变化、功能迭代、战略变化。

2、维护一份产品全局文档

之一：医微达发现很多伙伴刚接手做的产品时，踩了很多坑，当然现在也还在持续踩。当时几乎没有文档，而仅存的文档不仅数量稀少，而且过时（跟实际情况有较大的出入）。当时想要知道一个功能的实现逻辑，只能靠自己手工测试，或者让程序员去查看代码，效率十分低下。

之二：除了被别人挖的坑埋了之外，医微达发现很多伙伴也做过自己挖坑埋自己这样的蠢事···在做版本迭代的需求的时候，自己是非常清楚上下文和用户场景，以及在细节处的实现逻辑（要知道在实现过程中，总是会临时做出一些不在文档范围内的小调整），由于调整比较小，所以也没有体现在文档中。于是出现了在几个月后，想不起来当时的实现逻辑的情况···

鉴于以上的惨痛经历，医微达建议伙伴们开始维护一份产品的全局说明文档。在这个文档中说明版本的大致迭代情况、各个模块的现状和调整。

在实际情况中，医微达更希望伙伴的产品全局文档不用写的特别长，妄想把所有文档都集中到一个文档中，只在这个文档中说明『变化』和相关文件的地址。

另外，在云笔记中保存文档也是一个不错的主意，这非常利于及时修改和查看。但是切记要备份。

3、横向记录版本：版本的需求文档

请注意自己的需求文档的阅读体验。

好好写需求文档。

好好写需求文档。

好好写需求文档。

重要的事情要说三遍。如果你觉得这个不够重要，医微达建议你去翻一下产品的历史产品需求文档再来说话···

结构不清晰的产品需求文档，不仅会虐死你的继任产品经理，还有可能虐死自己。请在写文档的时候，务必注意格式，注意错别字，注意结构。确保文档语句通顺，且能够完美的表达你的想法。

4、纵向记录版本

从时间轴上，记录每个版本的基本信息和概况与上下文

之前已经说了，对竞品的迭代要保持关注。但同时也要对自己的产品的迭代进行记录。这个记录包括了每次版本迭代的内容和相关信息，以便于以后查询。

5、需求池

维护需求池，而非收集所有需求。

在平常工作里，你一定都会收到来自很多同事或用户的改进建议，千万不要弃置一旁，也不要立马将需求加入需求池。多和提需求的同学沟通一下，了解一下需求的上下文、场景等，从多个维度对产品进行评估，如果需求足够重要就将它加入需求池。

注意要用多个维度对需求进行衡量，建立上下游都认可的衡量体系。譬如隶属的功能模块（不同模块有不同的重要性和优先级）、紧急性（影响程度）、重要性（覆盖面）等等。

6、记录需求的场景与上下文

这个本来是要归到『好好写需求文档』那里，但我觉得很重要就另外抽出来了。

医微达知道需求文档是给技术部的程序员看的，而大多数情况下他们并不 care 你需求的上下文、场景和合理性，但是，不管他们是不是 care，你都要记录下需求对应的场景，好记性不如烂笔头，千万不要过度信任自己的记忆力。

7、良好的文件管理习惯

所有的文件，一定要好好管理，分文件夹摆放，定期备份，及时清理。

不经历一次找不到重要文件的事情，你就不知道好的文件管理习惯有多重要。

8、指导全局的文案风格文档

一个产品的文案会出现在产品的各个角落，一个统一一致的口吻，有助于塑造一个优质的品牌形象。而前后不一致、不礼貌、不细心、冷冰冰的文案风格，将会极大的影响用户体验。

而最简单的是，将文案风格用文档的方式确定下来。哪怕团队只有你一个人在负责产品，也一定要写下来。写下来，那就是准则。被遵守的机会也更大一些。医微达希望各个伙伴们能少走一些弯路，少进一些深坑，伙伴们可以关注医微达的公众号e-weida讨论交流。