文档规范和流程规范

Posted 2022-06-29 bit_kaki

为了把产品做好，在项目管理时候我们需要一些手段。

比较常见的就是通过文档和流程来作为项目管理的手段，

也就是通过一些文档和流程来规范项目整个周期。

 

文档规范

---

在项目管理时候我们避免不了写大量的文档，

常见的比如需求要求说明书、系统设计方案、详细设计方案、项目WBS表、周报日报等。

按常理说文档应该是一个手段，辅助我们做好项目的管理。

但实际情况中有时候大量的文档却成了一种负担，甚至很多文档是临近验收才开始补上。

这就有点本末倒置了，文档应该是手段，而不是目的。

 

所以我们应该根据自己实际情况作出一套符合自己的、真正可用的文档规范。

下面这个规范是《人人都是产品经理》作者苏杰总结的一套文档模板。

 

这套规范基本能覆盖产品经理日常绝大多数的工作，他这套规范主要是针对to C产品，

对于一些其他行业的to B产品，也会稍有变动。

比如我所在的能源行业，一般不需要BRD，

但是会有很多和政策相关的文档，比如N年计划规划、JMRH计划、国家战略需求计划等。

根据自己所在行业及产品类型，做出一个类似的规范，这点非常有必要。

 

文档模板的本质作用主要有三点：

让经常看同类文档的人提高效率：当开发工程师看惯一种UC文档以后，如果换成一种哪怕更好的写法，他们也会很不适应；

让写文档的新人可以尽快上手：新人可以根据模板，快死写出和团队里“老人”差距不大的文档。

让写作者不会漏考虑某些内容：比如PRD文档的整体说明部分，有7项内容，如果每次都从零开始写，难免漏掉一两项。

 

文档版本管理：

我们所作的各类文档都不会是一气呵成的，往往会随着需求变动、任务更改、版本迭代等不断进行更新。

为了更好地维护这些文档，我们往往需要进行文档版本的管理，尤其是在多人维护同一份文档的时候，

良好的文档版本管理可以更好地进行协同办公，保证所有参与者阅读和讨论的是同一份同一版本的文档。

文档版本管理核心涉及到的有版本管理工具以及版本号。

文档版本工具我使用最多的是SVN，自己觉得还是挺不错，尤其是对于权限管理上要求比较高。

版本号上各人就见仁见智了，我比较常用的是对内使用小版本号+姓名缩写+日期的方式，对外使用大版本号方式。

 

流程规范

---

长视者把目的当手段，短视者把手段当目的。

文档只是手段，流程也是手段，这些手段都是为了把项目做好，把产品做好；

当然把项目和产品做好也是手段，是为了达到公司的商业目标；

达到公司的商业目标也是手段，是为了完成公司的使命、实现公司的愿景；

。。。。。。

 

流程也不是一开始就有的，流程都是需求驱动，然后根据项目不断完善的。

设计流程的目标，在于保证“无论谁来做这个产品的设计，都能达到80分”。

也就是一个团队在做项目时候，将做项目的经验转化为显性知识表达出来，

而对于经常做的事情，就可以用流程这种形式进行固化、传承，

使得后人做这些事情时候能有所参考，不会太无助，

同时也保证即使人走了，事也还能做，减少特定的人的影响。

 

常见的流程有：

产品会有：觉得“做不做，做多少”，决定整个产品的方向；

需求评审：包括产品需求文档、用例、demo的评审；

设计评审：在开发较弱、新人多、业务不熟时候必须要进行设计评审；

测试评审：和设计评审类似，属于纯技术的精神；

功能评审：主要采取线下的方式进行，需要项目干系人都参与；

评审会议本身并不产生价值，所以应该尽量简化，但重要的评审一定不能省。