本文写给被裹挟在敏捷中的小伙伴。
本文框架如下,内容有点多啰嗦,伙伴们也可以先挑有兴趣的看。
1. 先扯点文史哲
2. 敏捷实践的四个范畴
3. 组织的敏捷转型
3.1传统组织架构面临着巨大的挑战
3.2组织的敏捷转型动机
3.3你实践的是组织的敏捷吗
4. 适合敏捷的项目任务
4.1项目的四种生命周期
4.2没有最好只有最合适
4.3中国互联网行业的特点:应用驱动型创新
4.4C端的情况:携程的优秀实践
4.5B端的情况
以下是正文。
1. 先扯点文史哲
一本红楼梦,因读者的眼光不同会有各种解读。“经学家看见《易》,道学家看见淫,才子看见缠绵,革命家看见排满,流言家看见宫闱秘事”,这是鲁迅先生的感叹。莎士比亚也有句名言,“一千个读者一千个读者,就有一千个哈姆雷特”。上升到哲学高度,《老子》开篇的“道可道非常道”更是微言大义。
针对同一事物,除了不同理解以外,还会有不同动机。一个有趣的例子在《厚黑学》里,厚黑教主指出“召陵之役,不责楚国僭称王号,只责他包茅不贡”。有兴趣的同学可以去百度这段历史。
由于有不同环境、不同角度、不同思考维度、不同参照系等一切主客观不可控因素,针对同一事物总会有不同的认知,这也造就了我们这样一个充满无数矛盾共同体的有趣世界。
“敏捷”(Agile)也是这样。“敏捷”在IT及互联网领域被作为一种“济世良方”而被寄予厚望。基于各种动机,众多企业在开展敏捷实践,懵懵懂懂的IT小伙伴被裹挟在其中,被动参与到各种敏捷实践中,随波逐流,晕头转向。
典型案例:
为了提高研发效率,IT部门领导要求推进敏捷。然后无论大家是否能够理解敏捷原则和实践意图,也没有定量数据证明效果的情况下,经过几次Scrum培训,Scrum就被仓促上阵,各种角色设定起来,计划会、站会、回顾会开起来,大家都忙得不可开交。过个一年半载再看,敏捷实践仍然停留在召开Scrum会议的阶段,不但拿不出提高效率的证明,反而往往产生大面积的质疑和牢骚。
这是一个典型的失败案例,当问题得不到解决的时候,所有的实践必然会变成对上的应付,最终走向不了了之,这种肤浅的实践注定不会起到实质性作用,对企业和个人是一种双输。你的企业是这样吗?
2. 敏捷实践的四个范畴
DP哥是一家互联网平台企业的PMO负责人,操盘了整体的敏捷实践,在实践过程中历经了太多的纠结,面对过各种小伙伴的各种问题,进行过无数次的复盘、反思。DP哥不喜欢吐槽,但希望和大家分享思路,因此尝试从动机的角度去分析敏捷实践,希望能帮助小伙伴们厘清问题思路,摆正自己在敏捷实践中的位置,也希望能使小伙伴们感知到“敏捷对自己的好”,提高对敏捷实践的信心。
从开展敏捷实践的动机方面进行分析,DP哥认知简述如下:
1)基于动机角度,敏捷包含四个范畴:
组织的敏捷转型
适合敏捷的项目任务
个人及小团队的敏捷化
规模化研发与DevOps
2)四个范畴分别代表了:组织的动机,项目任务的动机,个人与团队成长的动机,协同与效率的动机。
3)这四个范畴尽管有共同的敏捷内涵“以人为中心、价值驱动、鼓励合作、拥抱变化”,但对于IT小伙伴来讲,却是基本没关联的独立话题。
4)在讨论敏捷的时候,首先确认话题的范围属于哪个范畴,避免双方不在一个频道上。
本文中,DP哥分别阐述下前两个范畴。
3. 组织的敏捷转型
目前能够看到一些现象:最热衷于投入重金“从上至下”推动敏捷转型的,往往是一些大型成熟企业、跨国集团、大型银行等,反而不是互联网企业,分析其动机,是因为他们在这个VUCA时代遇到了需要用敏捷来应对的局面。
3.1 传统组织架构面临着巨大的挑战
传统组织架构来源于“泰勒”的“科学管理”理论,其基本出发点是,为支撑起大规模的工业时代,需要一部分高能力的人去预测出生产方式,并且规划、拼接、协调庞杂的生产流程,另一部分人只要执行就好。其成功点是将“管理”制度化作为纪律,管理者负责思考、规划,工人们负责执行。处于决策顶端的人负责战略决策,每个层级的管理者会检视目标并进行拆解,从而规划出好的执行方法;处于底层的人物,则应当根据指示行动。这个理论的基础在于事物的可规划和可预测性,并且将规划和执行互相分析,它改变了世界,仍然是当今管理理念的基石。
当企业发展到一定规模,不可避免会出现所谓大企业病,包括深井式的组织架构、孤岛式的信息系统、导致隔阂的部门墙、只知发号施令的领导作风,职能的臃肿,决策效率的低下,官僚主义盛行,创新能力衰弱,所有的问题都被甩锅给流程和最高领导,如果说在工业时代的极少数对极少数模式,大企业病通常并不会导致致命,但现在已经不一样了。在这个VUCA时代,情况已经变得更复杂,市场从极少数对极少数模式,演变成了多对多模式,行业的转折点可能不经意就会来临,如不能成功进行战略转型,会被最终干掉,诺基亚殷鉴在前。
而决策者经常恐惧的发现,企业发现自己陷入一种无法掌控的生态系统和价值网络中,几乎无法预测或规划自己的命运,针对价值判断的难度,已经超过了决策者的理解范围。
3.2 组织的敏捷转型动机
而在探索这些问题的解决方案时,任正非说“让听到炮火的人呼叫炮火”;阿米巴模式提倡“全员参与经营”;丰田重视长期理念并建立学习型组织;德鲁克明确指出,管理者应该激发和释放人本身固有的善意潜能,来创造价值,工业时代的“胡萝卜加大棒”方式对与知识工作者已经完全不起作用。
究其根因,是因为决策者们不约而同的认识到,自己做出的决策,不见得比一线团队更好。最靠谱的方法,应该是让掌握最多信息的一线团队去自己试试,如果这个一线团队比较强,成功的可能性会更高一点。
为了建立这种机制,企业需要调整组织架构,打破层级架构,建立网状组织,确保底层和前线的声音能被上层听到,又要打造能力超群和韧性十足的基层团队,并且实现互信和目标共享,即建立敏捷型组织。
为了建立敏捷型组织,领导最应该做的是要为团队赋能,在快速响应市场变化的过程中,组织领导需要“双眼紧盯、双手放开”,赋予一线团队更好的“试错”和成长机会,赋予一线团队更多的安全感和自主性。在未来,“英雄式领袖”会越来越少,领导者应该是敏捷型组织环境、组织文化、组织氛围的建立和维系者。这需要领导者改变自己的思维,不要再试图以“突出的能力,强大的意志”“英雄式”的牢牢控制一切,而是要带领企业走向敏捷转型。
3.3 你实践的是组织的敏捷吗
敏捷转型是艰巨的侵入式变革运动,需要使组织的流程、制度、文化发生本质的改变,方式方法也会伴随着战略方向的调整而不断调整,在组织敏捷转型所遇到的障碍中,排在前三位的是“改变组织文化的能力,人们对组织变革的抵制,组织现有的瀑布式流程”。
那么,小伙伴们,你所在的组织在进行敏捷转型吗?你在参与实践吗?高层领导在改变吗?你的部门主管在改变吗?项目运作流程在改变吗?如果大大小小的主管不理解敏捷,不拥抱变革,不改变管理模式,而只是在下属团队中开展敏捷实践活动,那么敏捷实践一定会遇到阻碍。如果敏捷实践只在研发内部开展,产品管理团队仍然以瀑布的方式提供产品需求,他们也往往成为敏捷实践的拖累者。
如果连你的主管和重要干系人也认为敏捷转型与他们无关时,你还能标榜自己的团队在进行敏捷实践吗?
如果你只是实践了Scrum方法,或者实践了极限编程和持续集成,你仍然是在用正确的思路在提高自身和团队的技术水平,你默默的继续做就是了,但不要标榜自己在进行敏捷实践或转型。关于这个话题,在第四个范畴中会详细解释。
推荐一本畅销书,建议IT小伙伴浏览下。
《赋能》(Team of Teams)这本书精妙而又全面的阐述了相关观点,这本书的副标题就是“打造应对不确定性的敏捷团队”。
4. 适合敏捷的项目任务
项目有多种形式,也有多种实施方式。需要根据项目的实际情况,选择合适的项目推进方法,而方法并没有对错之分。
4.1 项目的四种生命周期
根据PMI的官方资料,根据项目的特征,项目可以分为四种生命周期。
预测型生命周期:项目在开始时就确定项目范围及所需的时间、成本,以顺序的方式执行。项目应该具备如下特点:项目的可交付成果描述清晰,团队有较为丰富的类似项目经验。项目从高确定性的明确的需求,稳定的团队和低风险中获益,但不会在项目结束前交付商业价值。项目管理的目标是减少变更和管理成本。
当遇到变更或需求分歧,使得技术解决方案变得不再简单明确时,预测型项目就会产生意向不到的成本。瀑布模型是预测型生命周期的典型代表。
迭代型生命周期:通过不断的验证来改进产品或成果。针对同一需求,团队可能会连续的收集各种见解和不断返工。在复杂度高、受不同观点支配和变更频繁时,迭代生命周期会有优势,但它是为学习而优化,而不是为了交付速度,相比预测型可能需要更长时间和成本。
增量型生命周期:客户可能无法等待全部事情都完成,而是愿意接受解决方案的一部分。为为了加快交付速度,这种少量成果的频繁交付成为增量型生命周期。
敏捷型生命周期:团队预料到需求会发生变更,希望尽早交付来获得反馈和商业价值。
4.2 没有好与坏只有是否合适
没有哪个生命周期能够完美地适合所有项目。每个项目都需要根据其特征,找到最佳方式,并实现最佳平衡。这种方式可能是混合的,比如项目的一部分采用预测型,一部分采用敏捷型,或者前期整体评估采用预测型,过程中采用短迭代的增量交付以及站会回顾会等。又或者以一种为主,另一种为辅。选择了某种生命周期,也并不意味着就要僵化地执行下去,需要根据项目的综合情况来判断分析。项目管理的目标是在给定的当前环境下,尽可能以最好的方式创造商业价值,采用哪种方法并不重要,重要的是“我们怎么做才能成功”。
小伙伴们,你们在做的研发项目,适合哪种情况呢?
敏捷研发取得成功的,多是面向人的业务系统,或者toC的互联网产品。 用户故事(User Story)里面的第一项内容就是“作为...角色的用户,她/他想要....,因此才能....”. 这种需求收集是以用户为中心的。因此,但凡遇到重交互的系统,敏捷方法都可以很好的工作。
反之如果是中后台系统,或者数据采集和分析系统,大量的工作都是经过抽象的业务模型和数据计算逻辑,这种STORY的需求分析的方式就不容易适用了。再加上中后台的产品技术团队往往并不接触业务前线,也很难判断业务价值,采取以瀑布为主的方式反而更加合适。
对于纯技术性质的探索和尝试通常的做法是采取小范围尝试,切入少量流量或系统进行快速验证和收集反馈,然后不断迭代重构以及扩大范围,这是典型的“经验型过程控制”(Empirical Process Control)—一种根据实际项目中的现实观测而做出决策的流程,这是是符合人的自然认知规律的。无论你是否“敏捷”,你都会这么做。只是在当前,大家也把这个列入“敏捷”范畴。
4.3 中国互联网行业的特点:应用驱动型创新
中国的互联网行业发展迅速,每一个风口都会出现一哄而上,迅速形成激烈的竞争局面。而成功存活下来的互联网企业无一不是能够很快的响应市场变化,打造出优秀产品,快速形成价值,总结成一句话那就是“快速响应用户的需求变化”。无论他们是否标榜敏捷,其过程都是符合敏捷定义的。那么中国互联网是怎样一个情况呢?
在发达国家,互联网带来的进步是渐进的,在原先良好的基础上逐步升级产业。而中国在进入互联网时代时,由于部分行业市场成熟度较低,许多市场需求无法被满足,从而留下大量空白。而互联网提供了解决方案,解决了原有产业痛点,得到了跳跃成长的机会,在某些领域甚至成为主导市场的力量。
加上中国拥有多层次的经济和社会结构,导致需求的高度多元化,因此在中国也就出现了数量众多的独特创新,并展现出令全世界吃惊的创新精神和能力。这也导致中国互联网企业更偏向商业模式、应用、内容层面的应用驱动型创新。
这一创新偏重,一方面导致了中国互联网行业的竞争门槛相对较低,能够快速吸引了众多的新企业加入竞争,容易形成对风口和热点的集聚追逐,导致竞争更激烈。这就要求企业要更善于挖掘多变的市场需求、更追求创新频率和短期见效,因此节奏变化更迅速,市场波动性更大。回顾近年来中国互联网行业的几大风口,无一不呈现出资本迅速汇集、竞争迅速白热化、高峰期企业数量多、企业存活率低的现象。相对应地,在中国互联网行业也更加容易“一夜成名”。
在这种情况下,互联网的IT项目就面临了两方面的压力。一方面,希望快速交付并满足业务使用,以最快速度吸引眼球抢占市场,一方面求能够随时应对变化,甚至要不断试错,要求以尽量小的成本验证各种可能性。同时,多变的节奏打破了原来的协作方式,针对新衍生出来的工作任务,在旧有组织结构的语境中经常会出现模糊空间,很难快速理清这些任务究竟应该谁来做。
在这种背景下,涌现出了大量适合敏捷生命周期的项目,如果这些企业能从流程、制度、绩效等方面提供“敏捷”支持,确保敏捷交付与商业实践的良好协作,那么必然会给企业带来相应的商业价值。
写到这里突然想到了传统美食金拱门的例子。你可能没有想到,麦当劳也会有优秀的敏捷实践案例。DP哥曾经在一些敏捷交流的场合与麦当劳的伙伴有过深入沟通,后来在网上找到了一篇《麦当劳中国化》的文章,文中提到,麦当劳曾经拿出选土豆的追求完美精神,用五年时间打造出一款没有BUG的APP,面向全世界推出后但没有被市场所接受。文中如是说,“最早上线的麦当劳的APP评分并不高。之前的版本是在麦当劳全球的框架里面开发的,用户体验也来自于全球统一的标准流程。”麦当劳中国数字业务副总裁冯莲说,‘这个经历还是蛮痛的,如果说一个产品不采用更敏捷的方式去做,当最终生成、推出市场的时候就已经过时了’”。而在中国,在2017年,麦当劳用了40天的时间就勇敢的上线了小程序,成为首批实现小程序应用的企业,而小BUG和不完善也没有影响用户对小程序的使用热情。有兴趣的伙伴们可以自己去找找这篇文章。
4.4 C端的情况:携程的优秀实践
携程面对的是C端客户,我们看看他们是怎么面对适合敏捷的项目任务的。
典型案例:
业务场景:让旅客退房后无需将行李寄存酒店然后再折返去取,或者到达后不用专门去酒店放行李。从而节约半天至一天的游玩时间,节省折返酒店的费用。当时市面上还没有类似线上业务,也不知道市场有多大。
(行李寄送在美国、日本、新加坡是一种线下标准服务,一般由快递公司经营。DP哥当年在日本东京生活过,回国的时候,由于行李太多银子太少,选择了从大阪坐船回国,近百公斤的几大箱行李由“宅急便”上门揽收,直接邮寄到了轮船的托运安检口,而在美国听说有航空公司上门办理登机托运的。在中国,相关业务并没有得到大规模的发展。)
创意来源:来自携程内部创新工场的讨论。但由于成本、安全、时效的考量,大家并不看好。调研阶段:虽然不被大家看好,但一名产品经理并不死心,着手收集资料,联系当时了提供线下行李寄送的6家公司,调研成本、安全、时效等解决方案,终于得到领导的尝试许可。
最初阶段:该产品经理在携程APP的一个角落里发布了一张图片和预定电话,并亲自充当客服,24小时接听客户咨询和下单需求,在一段时间之后,得出结论,这个业务是有需求的,然后开始立项(携程的OK制),目标是日均100件行李。截至此时,经手的人仍只有这名产品经理1人。
立项上线:立项后开始设计原型和交互,加入进来2名团队成员,1名后端研发,1名前端研发。二周后上线,时间是2016年11月1日。
项目成长:立项后加入两名商拓的伙伴,开始拓展线下供应商以及酒店合作,在不断改进的同时,业务覆盖范围从8个境内城市,2个境外城市,到后面20个境内城市,10个境外城市。通过不断的发展,团队越来越大,范围越来越广,截至2017年2月,仅仅三个月,就达成了第一个小目标,日均100件。于是设定了第二个小目标:10倍增长……
这是DP哥用自己手机在携程APP截的几幅图(2019年4月7日)。
一个符合敏捷生命周期的项目,被完美地用敏捷的方式实现了。
这是个典型的ToC端的案例,如果说这个创意是一粒种子,在携程的土壤中,长成了大树。我们可以看到,在项目推进的每一步,组织都提供了合理的支持。小伙伴们,你所在的企业会有类似的项目吗?如果有,那么恭喜你,你们的项目任务天生适合敏捷。你要做的,就是把这些创新想法,努力的去落地实施。
携程是经过了敏捷转型的,他们这么描述自己,“过程就是一部真实的血泪史,团队经过了漫长的5年时间,终于修成正果,完成了一个小目标,那就是研发团队的敏捷方法覆盖率达到80%”。同时他们实现了“让团队以最短路径完成业务目标”。
他们在创新管理、业务驱动、保持高效、激活创业激情、培养创业型人才、塑造文化上下工夫,他们的实践包括:创新的组织结构(OK制)、高效的运营管理(OKR)、创业型激励机制(投名状)、人才培养管理(黄埔训练营)、文化塑造与改造(管理层理念革新)。
推荐一本书,《大产品,小团队:携程敏捷技术与管理转型实战》,这本书只讲实战不谈理论,可以看看他们是怎样利用敏捷的生命周期去做项目,并在竞争愈演愈烈的市场中立于不败之地的,“OK制”等名词的解释,可以在书中找到答案。
B端的情况
ToB端的情况会复杂,研发者天然不是用户,用户往往不是买家,因此更需要分析市场趋势,作长远的规划,你需要全面地考虑各个方面的因素,比如竞争对手的情况,行业规范监管条例,客户的内心诉求,你要形成长期的产品愿景,长期的战略规划图,这个长期往往是1年半到2年。落实在平台系统的建设上,可以以三个月为周期建立开发路线图,并分解成项目组合、项目集,并衍生出大大小小的项目,这个过程通常由PMO团队协助完成。
非常重要的一点是,无论对内对外,都要坚定的传递这样的信息:一切都是按照战略规划图在有条不紊的进行!
对于这些衍生出的项目中,根据各自特征安排合理的生命周期就好了,瀑布也好、敏捷也好、亦或是混合的,综合考虑确定性、效率、资源、交付周期、反馈等情况,寻找最佳实践和最佳平衡。