公车版本：一种高效的研发项目管理方法

freedom1

学会了需求管理，紧接着就是要把需求合理、有节奏的进行落地。怎么做呢？平时听说过最多的研发生产方式可能有：瀑布流、Scrum敏捷开发等等。
) u1 i- J# B4 @; J, M* V
: Y; N) V2 e. M) n7 h7 t9 E结合实际生产中的客观因素，我用过最有效的版本管理方法叫做[公车版本计划]，何为？
( w' M6 L! t0 O7 J9 Z5 P" [
1. 公车版本是什么
+ d0 z* x8 {1 g: S& }; t& A1 g
& d+ ^9 S. X' i! o2 a2 [# y/ d第一次接触到【公车版本】这个概念是在阿里巴巴，当时看到有点懵，不是很理解这个庞大的组织是如何用这种方式指导研发生产的。
& c/ `3 ?! p& j3 z- K6 Z
: s1 P+ R+ l. `7 x9 Y  b/ ~趁这个机会用一张生活中都碰得到的场景做个引入：
8 a# L4 _4 {* Z. c
     
& ?8 c7 G2 S9 l$ y/ p公车版本就好比日常生活里的公交站台以及站台上的一个个乘客。咱们做一个类比：运营部、销售渠道、市场部门、产品部门提过来的需求，就好比站台上一个个乘客。而研发中心的每个版本，就是搭载这些乘客前往终点的一班班公车。
- g2 \( `0 K' _( R& }+ R! M$ e
试想一下：如果城市的公交车不按照规则随便乱发，乘客也不遵守规则随便插队，那整个交通会混乱成什么样子？

为了充分利用研发资源，保证输出效率，我们就需要做科学的项目管理和实施。有序的处理需求，才能保证整体的效率最大化。
$ d* G+ S" Q" R" R% @4 X- L
所以公车需要按照既定的规则发车：
乘客会按照比如：军人优先、老人优先、妇女儿童优先的规则上车，这就像咱们需求的优先级设定；
但是每班车的载客量是有限的，载客量就等同于我们每个版本所拥有的研发资源，一旦严重超载就会造成很大的风险，比如项目延期、项目质量下降等；
所以：如果一班车已载满需求发出，那么只能等下一班车，所以我们才会有需求优先级的PK，我们必须要保证高优先级的需求先上车，先上线；

/ ~; c. ?7 j# ^7 o5 u但是整体还是上面提到的那个原则：每班车的载客量是有限的，所以在一个版本中我们肯定要有取舍。

7 \' [& m4 M) L6 W
3 g! u* F  |  r1 @2. 公车的发车节奏

' z7 a4 S4 y: f- e/ H7 p8 N5 X这时候可能需求方会问：那你们产研能保证快节奏的发车吗？
答案：会。

! Y* a1 g9 [/ r. X$ ]- Z- c下面我就给大家用图示意的方式给大家讲解研发中心的发车节奏是什么样的。
2 G1 X! t- E: _: S$ z, Z
4 h1 Z' o5 H+ w3 R+ {
, |4 P5 u5 t+ R1 s
V是Version(版本)的意思，每个版本由三种不同颜色的阶段组成：
绿色的代表产品和设计小伙伴画原型图，出设计稿；
蓝色的代表开发小伙伴去实现，也就是写代码；
5 v  d- W0 a0 V+ L黄色的代表测试小伙伴去对代码质量进行测试，保证上线后不会出问题；

0 F2 P2 N+ @" B& h& t; I从上面这个图中，我们可以直观的看出来：V3.4版本刚刚开发完（蓝色部分），研发小伙伴已经投入到下一个版本V3.5版本的开发当中，只预留了1周时间修复上一个版本的Bug，其他都是一边开发V3.5的新功能，一边修V3.4的Bug。

为了保证能够最快速的响应市场，为一线提供充足的弹药，通过这样的版本迭代，研发中心版本与版本之间可以做到无缝衔接。
" \4 T; r6 G# W  ~

! F! M9 J6 z! _  p3. 公车的效果

* t' l( w4 @$ U& Z5 Q4 r$ a; D可能会有少数小伙伴问：那公车版本效果好吗？
答案：好。

混乱的生产一定不如有序、快节奏的生产来的有效。几年前曾经历过某家公司在长达半年的时间，业务几近于0产出。后来深入做过复盘，究其原因，就是因为版本的节奏混乱，缺乏科学的管理。总结下大概都有哪些问题：
1 y# [, g1 V, a5 D排期也都排，但缺乏客观的评估依据，拍脑门居多；
+ H5 n: J# X  i) Q" K' W优先级不明确，开发的时候这个也变得更高优、那个看起来也更高优；
一个大项目看似也拆多个子项，实际基本是物理切割，子项目之间无关联承接；
) z; v" z$ j; `$ |, a研发生产过程中，各种需求插入、需求难度预期过低导致工作量不可控、延期；
- ~$ L& ]# {. A3 @7 R0 _, D
" Z; ]0 p3 L+ P# M+ ?8 t
年终总结复盘时的数据显示，启用公车版本管理项目后，线上问题的处理数量从先前的80个/半年，提升到310个/半年，在产品功能上更是实现快速推进，弥补了前面1-2年落下的大坑。

通过公车版本的推进和团队的磨合，我们每个版本可以搭载的需求量都在提升。



9 e  m* q7 M1 ]4 L4 h1 s  t  _4. 每班公车的发车时间
, t- Q5 {0 k3 ?! g( w/ r
& e( ?! w" t. q# S7 \. R3 S4 F每个版本的发车时间相对都是固定的，通常会在confluence或者其他一些共享空间进行维护，和兄弟部门同步，当时我们基本保持1个月1班车的发车节奏。
) e1 E* U: r1 S6 Q8 @5 s+ a后续每个版本做哪些需求／功能／问题处理，也都会提前邮件同步給兄弟部门，以便实时了解研发生产当前的状态和节奏。
1 }. Y2 Y) o$ p9 R  a9 O
0 n* c# \( f2 a( v  I              
这时可能有小伙伴会问：那我有紧急需求处理怎么办？
答：迫切解决问题的情绪可以理解。但是为了保障主线版本有序的推推进，也请大家都遵守交通规则。除非阻塞性问题或者大面积影响的问题，我们会安排研发小哥哥立即处理。其他常规优化需求，都会按照上述规则放到各个班车中去实现。
. u# ]' Z- b2 W! Z
, A9 u  s$ z6 i/ d  O8 h
2 D. p8 W5 s. j) y$ U4 r" k5 ]      
可能每个需求方站在各自的立场，都会觉得自己提的需求更重要。但是大家必须要明白：每班车的载客量是有限的，我们必须站在业务整体的层面，优先去落地一些普适性、对于公司整体市场打法有明显收益的点。
# ?! N0 q; }6 `0 A8 d. n/ a

! k  ~. e3 _: e( Q' d  u每个业务都需要建立起一个有序、健康的发展节奏，
同样的，研发生产也需要。
* j# j$ q/ _0 G* M  ?8 m

grand

公车版本就好比日常生活里的公交站台以及站台上的一个个乘客。咱们做一个类比：运营部、销售渠道、市场部门、产品部门提过来的需求，就好比站台上一个个乘客。而研发中心的每个版本，就是搭载这些乘客前往终点的一班班公车。