你是否遇到交接资料为零，接手的工作未画流程图，进入业务之后，发现流程等各种产品文档缺失严重，版本更新内容未记录，中间断层难以上手？如果你有遇到这些问题，那建议看看这一系列文章。
我从事互联网行业以来，前后待了几家公司，有大型公司和小型公司，BAT级别公司未待过。从这几家公司的经历来看，产品的管理流程都存在一定的问题。小型公司不用说，流程较为混乱，在之上第一段落中遇到的问题都存在。在大型些，人数在几百人的公司，则遇到公司的流程各分支业务线所执行的流程也不一样，也就是一个公司内，可能都存在多种管理流程，版本更新等未详细记录，或者转手过多，中间丢失。
产品流程，文档管理不规范，增加了额外的成本及问题。这些成本包括新人对项目的上手时间成本；因资料缺失导致的沟通成本；无文本信息，问题反复，理解不一致导致的团队信任成本；研发周期加长导致的进度问题；人员流失导致信息断层的问题。
拥有一套较为规范的产品管理流程，对文档进行规范，对于需求收集，整理，更新，产品研发均有非常大的好处。如果业务要扩张，人员团队要扩容，任务复杂度增加，则规范化将发挥巨大作用。
有些朋友可能会提出反对意见，现在互联网是讲究速度，讲究快速反应，讲究敏捷。我不反对敏捷，也不反对速度和快速反应。敏捷，也不是不做规范，敏捷的基础恰恰是规范化。规范化，不管是流程还是文档的规范化，这是形成统一认识和使用相同的语言来做沟通，也就是让大家有一个共识。在此基础上再进行更快速度的变化，快速反应，这是敏捷。
为何如此说，因为业务上的人员背景不同，经历不同，不会天然的存在一个共识，这个共识需要搭建，需要维护一个环境，一个认知，一个合力。如果未有这个认知，那讲究快速，则非常容易进入一个拉扯的境遇，最终很可能导致混乱。如果不根据具体情况来分析，不了解一个东西的适用范围及前提，随意上，则需要怀疑提出此事的人其行为背后的动机。是真的不了解，还是存有纯粹搞事，还是迎合上层，为自己的履历添彩？
总之，我认为敏捷，快速反应的前提条件就是先做规范，先如任正非先生所说，先削足适履，然后在此基础上做改变，做微创新，做优化。先人来适应一下制度，再来改制度。
基于这个认知，我先后也做过几个业务的产品负责人，逐步搭建了一套产品流程及规范文档，进行了实践，取得了一定的效果——内部认知语言统一，沟通时间更短，各方效率提高，文档可追溯查询，人员变动流失影响更小，权责清晰。
此系列文章将对此套管理流程及规范做分享，主要约定公司产品从立项到产品上线的整个过程，产品经理的做事流程，产品经理需要完成哪些事情，需要产生哪些文档以及文档的产出规范。
a，产品需求的收集；
b，产品需求管理；
c，产品规划；
d，产品原型设计；
e，产品需求的输出文档；
f，产品验收；
g，产品版本命名规则；
h，产品发版管理。
以上内容，将按照各部分的做事流程，文档规范，一般方法进行阐述，并会将相关的文档样本给出，也就是讲实操的东西，讲上手可用的东西。
此系列文章的缺点：
第一，作者本人的经历，认知有限，必然存在很多问题，流程及文档不是尽善尽美；
第二，产品工作是一个涵盖范围非常大的知识领域，此系列文章，将主要集中在流程及文档规范，做事的一些方法，对于商业分析，数据管理，大数据，AI等个产品领域的业务知识，不进行扩展；第三，此系列文档的读者对象，更针对已经进入产品岗位，具有一定的基础的从业人员，可能对部分人员不友好，也请谅解。
将要讲述的主要内容
讲述以下流程以及对应的产出标准：
