可恶的流程
创业初期的很长一段时间里（10人以内），我们没有任何工作流程，我们所有焦点都集中在如何迅速把体验好的产品做出来，那时大家效率很高，每周一个版本的迭代速度也让大家工作得很嗨，周五都像“打仗”一样，紧张而又快乐地打着包，发着版，然后满怀期待的等待周末效应的到来(聚会玩周末数据是平时的1.5-2倍)。
现在，聚会玩发展到20+人，我这边更多地承担起项目管理的工作，不自觉地慢慢积累了一些成文的工作流程和规范。产品策划、美术设计、程序开发、测试，每个部门的工作分配是非常清晰的，但随之而来的是各部门内的规范和部门间的流程。
为什么公司发展大了都需要流程？
- 流程让分工和权责更明确
- 流程让跨部门工作有据可依
- 部门内流程起规范作用，让工作有条不紊
什么样的团队才不需要流程？
- 只有小而精的团队（<10人）。团队小，分工非常明确，没有太多的跨部门协作，没有太多的工作上下游关系。团队精，意味着每个个体能力都很高，不管是专业技术能力还是团队合作、自我管理、情商等。唯有这样的团队，不需要流程。团队大了以后，可以考虑按项目或需求来拆分达到上述小而精的团队需求。
举个🌰
运营有个需求，要对一张图做一个很小的改动，运营妹子直接去找到了负责UI的美术同学，美术同学一听这个需求，觉得几分钟就可以搞定，于是欣然接受了此任务。这时，这个行为被旁边的设计主管拒绝了：要求运营妹子去内部工作流系统里面提交任务单给UI同学。
从两个角度分析上述问题：
- 运营妹子和UI同学角度。一个很小的问题，10分钟就可以搞定，为什么需要那么多流程？增加无用的工作量，蛋疼！
- 设计主管角度。UI同学真实没经验，这种任务怎么能随便接呢？私下接了，不仅影响手里的工作，而且公司这么大，运营找你提个小需求，程序找你提个小需求，策划找你提个小需求，老板再让你做个图标，都堆在一起你怎么做？怎么去安排优先级？且不说你会不会忘记后面提的需求，后期根本没版本追溯每一个需求和问题？而且现在公司还小，你们都不养成这种好习惯，公司大了，大家都习惯没秩序以后，改都改不掉了！
站在公司层面，你肯定知道我偏向于哪种角度来思考了。这也让我明白了为什么大公司不得不有那些让人可恶的流程。
再举个🌰
版本内测，开发通过手动的方式打包，通过QQ把包传给了运营同学，第一次发现传错了，又重新通过QQ传了一个正确地包，运营拿到包以后开始上传，内测开始。两天以后，测试发现，运营上传了那个错误的包……
上述过程很简单，但是每一步都反映出问题：
- 开发通过手动方式打包
- 开发通过QQ将包传给运营
- 传了两次，还有一个错误的包混在里面
- 上线后测试没有及时接入测试线上版本
这也是真实事故，后面我们规范上述流程如下：
- 开发通过脚本打包，打包后的文件放在指定的内部贡献盘；
- 开发打包完后，将工作流任务指向运营，运营受到工作流任务后开始去指定位置拿包上传；
- 运营上线结束以后，将工作流任务指向测试，测试第一时间对线上版本进行测试；
通过上述简单的三步流程，很好的避免了上述问题。