创业初期的很长一段时间里(10人以内),我们没有任何工作流程,我们所有焦点都集中在如何迅速把体验好的产品做出来,那时大家效率很高,每周一个版本的迭代速度也让大家工作得很嗨,周五都像“打仗”一样,紧张而又快乐地打着包,发着版,然后满怀期待的等待周末效应的到来(聚会玩周末数据是平时的1.5-2倍)。

现在,聚会玩发展到20+人,我这边更多地承担起项目管理的工作,不自觉地慢慢积累了一些成文的工作流程和规范。产品策划、美术设计、程序开发、测试,每个部门的工作分配是非常清晰的,但随之而来的是各部门内的规范和部门间的流程。

为什么公司发展大了都需要流程?

  • 流程让分工和权责更明确
  • 流程让跨部门工作有据可依
  • 部门内流程起规范作用,让工作有条不紊

什么样的团队才不需要流程?

  • 只有小而精的团队(<10人)。团队小,分工非常明确,没有太多的跨部门协作,没有太多的工作上下游关系。团队精,意味着每个个体能力都很高,不管是专业技术能力还是团队合作、自我管理、情商等。唯有这样的团队,不需要流程。团队大了以后,可以考虑按项目或需求来拆分达到上述小而精的团队需求。

举个🌰

运营有个需求,要对一张图做一个很小的改动,运营妹子直接去找到了负责UI的美术同学,美术同学一听这个需求,觉得几分钟就可以搞定,于是欣然接受了此任务。这时,这个行为被旁边的设计主管拒绝了:要求运营妹子去内部工作流系统里面提交任务单给UI同学。

从两个角度分析上述问题:

  • 运营妹子和UI同学角度。一个很小的问题,10分钟就可以搞定,为什么需要那么多流程?增加无用的工作量,蛋疼!
  • 设计主管角度。UI同学真实没经验,这种任务怎么能随便接呢?私下接了,不仅影响手里的工作,而且公司这么大,运营找你提个小需求,程序找你提个小需求,策划找你提个小需求,老板再让你做个图标,都堆在一起你怎么做?怎么去安排优先级?且不说你会不会忘记后面提的需求,后期根本没版本追溯每一个需求和问题?而且现在公司还小,你们都不养成这种好习惯,公司大了,大家都习惯没秩序以后,改都改不掉了!

站在公司层面,你肯定知道我偏向于哪种角度来思考了。这也让我明白了为什么大公司不得不有那些让人可恶的流程。

再举个🌰

版本内测,开发通过手动的方式打包,通过QQ把包传给了运营同学,第一次发现传错了,又重新通过QQ传了一个正确地包,运营拿到包以后开始上传,内测开始。两天以后,测试发现,运营上传了那个错误的包……

上述过程很简单,但是每一步都反映出问题:

  • 开发通过手动方式打包
  • 开发通过QQ将包传给运营
  • 传了两次,还有一个错误的包混在里面
  • 上线后测试没有及时接入测试线上版本

这也是真实事故,后面我们规范上述流程如下:

  1. 开发通过脚本打包,打包后的文件放在指定的内部贡献盘;
  2. 开发打包完后,将工作流任务指向运营,运营受到工作流任务后开始去指定位置拿包上传;
  3. 运营上线结束以后,将工作流任务指向测试,测试第一时间对线上版本进行测试;

通过上述简单的三步流程,很好的避免了上述问题。