“ 团队和个人需要很快和持续有打胜仗的感觉。”





1 团队需要激情



从去年开始，我们公司设立了“天使基金”。个人和团队可以自由发挥，提交点子申请“天使基金”资助，点子经评选后并可搭建团队把它做成产品。这也是公司激发大家创新的机制之一。



突如其来的疫情，让“天使基金”孵化的产品及时立功。



春节后，由于各种不确定性，公司需要及时把各种最新的安排通知到每一个员工，也需要掌握员工的健康情况。由于数据安全的原因，我们还没有使用企业微信或钉钉。



一个团队用10天的时间做了一个微信小程序，完全满足了当时的需要，而且界面做得很用心，用户体验非常好。期间不断迭代，为复工提供了很好的信息保障。产品得到其他分公司认可，迅速推广到国内其他分公司使用，在集团内成就了一个很好的“中国故事”。



另一个团队开发的产品可以自动监测复工后回办公室上班的员工（目前我们大部分同事还在在家办公）的具体座位，帮助公司有效地掌握了有多少同事回办公室上班满足报备需要，总数是否有超过政府规定的上限，以及同事是否按要求保持座位距离。这也是一个概念验证只用了几天，从0到1只经历了三个月的过程。



作为一家全球金融企业，我们绝大多数项目的交付周期都是数以年计。一个软件系统，抛开开发时间，光是生产服务器走上线审批的流程都要起码6个月时间。



在这么长的周期里面，你是很难获得激情的。游戏之所以使人兴奋，就是因为玩家能频繁得到反馈和回报，哪怕每次分量不大。年终奖给人的兴奋有限，就是因为周期太长。



同理，10天、三个月上线一个产品，并且随后可以频繁迭代，就能很快并持续给人“打胜仗”的感觉，这种赢的感觉对于激发和维持团队和个人的激情非常重要。这也是一种重要的激励。



而且，快速交付意味着很快得到反馈，正面的反馈使人兴奋，负面的反馈能帮助我们及时调整或放弃。数以年计的项目大概率都是一个挖坑的过程，因为缺乏及时、有效的反馈，摸黑前行。



02 怎样才能快



那么怎样才能快起来呢？有人说敏捷开发就是牺牲质量的快速开发。其实非也。敏捷与DevOps的快，是通过定义最小可用产品（MVP），快速交付MVP，获取用户对MVP的反馈，及时调整产品，并通过持续交付迭代的过程。先完成，再完美。是一个螺旋式的产品演进过程。





大而全的需求往往是万恶之本，也是项目交付周期长的根本原因。定义MVP，就是要拆解需求和项目目标成各个阶段性目标，并约定能满足阶段性目标的最小需求。当然，MVP虽不完美，但必须是完整的、端到端的、可上线的。



如果是迭代开发，每个迭代都必须要有具体、明确的阶段性业务目标，而且有预期的产出。







如果是一个原计划数以年计的项目，就要思考半年内能交付什么，甚至一个月内能交付什么。有些时候，客户、用户不接受MVP的想法，我们可以通过把资源、时间作为限定条件做这种极限思考。



我相信疫情一定让所有公司、团队都做出过平时没有尝试过的改变和妥协，这就是极端条件对思想、能动性的激发。



03 一个实例



两年前，我负责公司一个新业务的系统建设，一个从0到1的过程。由于该业务是一个成熟业务，有现成的供应商系统，业务部门决定采购该系统。我们主要负责系统采购、架构设计、搭建服务器、部署、测试和上线。



由于业务部门想在国内开放该业务的时候能先拔头筹，他们希望能在半年内上线该系统。而按照我们的经验，要完成前面提到的这些过程，起码需要9个月到一年的时间。



而且，该供应商系统满足国内的业务需求和监管要求都没有问题，但是也要满足我们集团作为全球金融机构的各种全球要求，包括业务方面的合规要求和IT方面的架构设计、灾备处理、系统安全等要求，衍生出大量整改需求，交付时间肯定会被拉长。



由于该业务比较成熟，市场上肯定会出现同质化竞争，如果我们仅提供核心服务，肯定没有什么竞争力。所以，业务部门还要想方设法为客户提供更多的增值服务。最终，我们除了采购了2个核心系统外，还采购了3个增值系统。这也大大增加了项目、业务流程、系统和架构的复杂性。



简单来说，要在半年内完成系统上线，是Mission Impossible。



通过和业务部门协商，发现要开展该业务，需要申请牌照。业务部门着急的，是想尽快提交牌照申请的材料，这样牌照申请和系统实施可以同步进行，一旦牌照下来了，我们便可以招揽客户和开张。



而其中一个申请材料是我们要和监管机构进行联测，并由监管机构出具联测报告。通过进一步了解，该联测并不要求在生产环境上进行，而且只涉及到核心系统。



因此，要满足牌照申请的要求，我们只需要把核心系统部署到测试服务器就可以了，这样不受系统上线流程的限制，可以快速实现。我们也以此设定了首个阶段性目标。并在三个月内达成了目标。



基于这样的思路，我们把整个项目拆解成了若干个阶段性目标，并通过持续交付，避免了项目陷入数以年计“憋大招”的状态。





04 总结



曾经在Facebook担任过产品经理的马丁内斯在他的书《混乱的猴子》里提到，所有的创新，都会变成平庸。因为一旦一个创新的产品成功了，就会多人使用，一旦多人使用，产品的稳定性就显得更重要，产品的更新和维护就会变成平庸的开发和运维工作。在Facebook也不例外。



所以，即使进入阿里、腾讯这样的以创新标签的公司，大几率都是从事很平庸的工作。也就是说靠创新来维持团队和个人的激情，是不现实的。



快速交付产品，除了让公司和团队抢占先机外，也能让团队和个人更快地获得赢的感觉，激发和维持激情，也能更快地获得产品反馈。



而快速交付，就是要通过MVP+持续交付，实现产品螺旋式演进过程。避免通过憋大招的方式反而给客户、用户和自己挖了个深坑。



分割线 卡通



关于作者

刘华（Kenneth）



• 敏捷、精益、DevOps专家

• 公众号“敏于思 捷于行”博主

• 精通极限编程、Scrum、看板方法、测试驱动开发、持续集成、行为驱动开发、DevOps工具栈

• 曾在GDevOps、DevOpsDays Meetup、中国软件技术大会、ArchSummit等论坛发表主题演讲

• 著有《猎豹行动：硝烟中的敏捷转型之旅》一书