再问他们要多久呢？脑回路再一转，掐指一算——3天吧。最后，开发gg没有食言，还果真用3天就把功能做完了，由于当时也没有测试，于是开发gg自己测一下没啥问题，当天下午就直接就发布上线了……

　　这样的形式由于中间环节少，看起来似乎工作效率、沟通效率都挺高。但时间一长，团队规模一大，负面影响也就逐渐显现出来了，这些负面影响集中表现在：

　　低价值需求——需求没有经过有效地筛选过滤，开发的产品没有缺乏有效的价值，一些低价值的需求被投入巨大的精力去实现；

　　低优先级需求——需求的优先级缺乏有效的评估，做了很多紧急但不重要的项目，对产品的提升并无太大的意义；

　　信息不畅——由于大多单点沟通，所以业务部门并不知道技术部门在整体都在做些什么项目，开发每天都很忙，但似乎没有人知道他们在忙什么；

　　节奏混乱——开发做完一个项目没问题就发了，有时候一周法两次，有时候一周发三次，也有时候遇到大的项目，可能两周也不发一次，工作缺乏节奏感。

　　产品质量差——由于产品缺乏需求设计，又缺乏有效测试，产品上线之后又暴露出一堆的bug，根本用不起来。

　　于是，为了解决这些问题，最为一名新官，在我担任产品经理之后，除了完成自己最基本的产品设计的工作之外，在产品管理的流程上，我也烧了三把火：

　　第一把火：需求归口

　　所有人提出的需求，必须且只能提到我这里做统一的需求归口，由我进行统一的需求筛选及优先级管理。

　　业务方不能越过产品经理直接向开发提需求，开发人员也有权拒绝产品经理之外的人员提的所有需求。就这样，公司千丝万缕的需求变得逐渐清晰，开发和业务部门都可以更加清楚地找到准确的对接人。

　　而且，由于产品经理可以将业务部门的业务需求转化为开发更容易理解的开发需求，也可以把所有开发正在开发的项目以清单的形式传递给业务部门，因此，这一把火，也让整个公司跨部门之间的沟通变得更加通畅。

　　第二把火：产品测试

　　向公司提出直接了直接的测试人员招聘需求，为团队补充测试人员的角色。测试人员到位之后，在项目没有经过测试之前，开发不得直接把项目发布上线。这一把火，让我们的线上的产品质量得到了很大的提升。

　　第三把火：产品发布

　　跟开发、业务部门一起，商定了每周四晚上23:00之后作为常规的发布时间，除紧急修复类的项目之外，常规情况下，一周一个发布周期，产品和项目的开发都按照这个节奏进行推动。这一把火，让整个研发部门的计划性得到了很大的提升。

　　这就是上任伊始我为公司制定的极简版产品管理流程，尽管比较简单，但的确解决了当时的很多实际的问题，以至于我们CTO在月度全员例会上，对我上任一个月的表现进行了点名表扬。

　　但随着公司的发展和团队的扩张，这个最简版的产品管理流程逐渐不能适应实际的工作需要，于是，我又根据实际的情况对流程进行了版本迭代和升级，比如：

　　由于没有明确的PRD文档，而沟通又存在信息的损耗和失真，开发最后实际做出来的功能跟产品经理的原始需求差别太大，进而导致跟开发扯皮的情况越来越多，于是，我增加了PRD文档的流程——产品经理提交开发之前必须要形成明确的PRD文档的流程。

　　业务部门的业务量陡增，对技术部门抱怨连天，总觉得很多很重要也很紧急的项目提给技术部门最后都没做，于是，我增加了优先级例会的流程——产品与业务每周一的需求优先级排序的例会，一起商定接下来要做的项目优先级。

　　由于需求变更经常导致开发、产品和测试之间的沟通问题，比如产品跟开发商定了需求变更的内容，却没有及时告知测试，导致经常测试按照旧版的PRD跟开发提bug在所难免，不仅产生工作量的浪费，甚至有时还造成一些不必要的矛盾。于是，我又增加了需求变更的流程——任何的需求变更，均需要同时跟开发和测试确认过后才可以进行需求变更，同时，变更的内容必须及时记录进入PRD文档。

　　就这样摸着石头过河，一步一步地对产品管理的流程规范进行升级，最终，在我离开公司之前，就在当时那样一个有着七八十人技术团队的创业公司当中，形成了这样一套产品管理的流程规范：