开发团队面临的三大安全挑战

应用安全不能只依靠防火墙,必须要在应用开发阶段采取适当的安全控制措施,使得应用在发布上线前就具备较好的安全性,避免人为失误造成安全隐患。

不少企业早就意识到了这一点,然而理想和现实之间还隔着几十个安全漏洞,尤其是那些采用敏捷或者精益开发模式的团队,在具体的实践过程中,几乎无可避免的会遭遇到下面几个挑战。

挑战1:一次性的安全检查无法匹配持续性的交付

为确保团队开发出来的应用具有足够的安全性,最常见的选择是对其进行全方位的安全渗透测试。无论这样的测试是由企业自己的安全团队执行,还是购买外部第三方服务,最终都会得到一份详细的安全报告,团队接下来需要做的就是基于这份报告所揭露的漏洞,对应用进行相应的调整,直到安全漏洞被修复为止。

持续交付是敏捷、精益开发团队的核心能力之一,这意味着团队可以做到每周甚至任意时刻发布产品,持续性的从真实环境中获取市场反馈,然后基于这些反馈对产品进行调整。一个可以参考的案例是,早在2014年的时候,亚马逊平均每秒有一次以上的产品部署,每天如此。

与此同时,安全渗透测试却没有这么高的“交付”速度。由于渗透测试的特殊性,虽然有大量的自动化漏洞扫描工具可以使用,但是一次全面、高质量的渗透测试依然需要人工参与,几天甚至一两周之后才能得到测试报告是普遍现象。

那么问题来了,一方面开发团队持续性的每周都有新功能上线和旧功能调整,另一方面渗透测试却没办法在这么短的时间里完成,它只能是阶段性、或者定期性的进行,例如每个季度测试一次。

这种情况下,开发团队该何去何从?如果要安全,那么就得等着做渗透测试,而且一旦发现安全漏洞还要花额外的时间去修复,产品发布必定会延期。如果要效率,那么就只能冒着风险发布,因为谁也不知道当前应用有没有安全漏洞,万一被黑客发现并且加以利用,后果不堪设想。

问题的关键在于,开发团队是在持续的发布应用到生产环境,然而渗透测试却是个相当耗时的一次性活动,它没办法跟上这么快的交付速度。

挑战2:缺乏自动化、自助化的支持,安全实践落地难

开发团队其实明白安全对于应用而言至关重要,也知道在开发过程中就应当通过运用各种安全最佳实践来主动消除安全问题,把安全风险降至最低。不过现状却是,不少安全实践要么无法落地实施,要么有流于形式的倾向。

一个真实的案例

一个开发团队在做完业务需求梳理后,立即进入了开发阶段。安全团队虽然在项目启动时提出过安全要求,例如要求团队采用威胁建模活动,识别出应用面临的安全威胁,并制定应对措施。然而由于该项目交付压力大,时间紧任务重,再加上团队成员对于威胁建模并不熟悉,最后这个活动被一拖再拖,直到应用开发完毕进行上线前的审批时,才发现没有做威胁建模,而此刻为了能让应用按时上线,只好回过头来临时补一份威胁建模的文档,仅用于应付安全部门的要求。这种情况下,安全威胁根本得不到全面的分析和应对,风险由此而生。

在项目前期的设计阶段是进行威胁识别的最佳时刻,开发团队只要在这时做一次威胁建模,就能识别出潜在的安全风险,并且在接下来的开发过程中采取适当的措施加以应对。但是开发团队却仿佛是懒癌晚期患者,硬是拖到上线前才把威胁建模补上,而此时它早已失去意义。

为何开发团队一边认同安全的重要性,一边却又对安全实践如此怠慢呢?本质原因在于,某些安全实践需要大量人工参与,或者对人员安全技能有很高的要求,与此同时又缺乏自动化、自助化的支持,因此在开发团队看来,这些实践的采纳成本太高,在面临交付压力的情况下选择性的忽略,或者认认真真的走个形式,就成了再正常不过的结果。

挑战3:高耸的部门墙让开发和安全团队难以进行高效的协作

随着敏捷、精益开发模式的普及,再加上DevOps转型的助推,不少企业已经开始组建全功能开发团队,团队中各个角色有着共同的目标,相互协作以更高的效率交付应用。但是安全团队却依然隶属于一墙之隔的安全部门。

别小看了这堵墙,说它是万恶之源有点太夸张,但它的存在确确实实阻碍了企业实现其业务价值最大化。墙的这边,开发团队竭尽所能的以最快的速度完成应用开发,以求尽快上线获取反馈;墙的另一边,安全团队只关心应用是否安全,至于是否急着上线,那不是他们关心的问题。但是他们都忽略了一个事实,那就是企业的成功需要两者共同高效的协作。

小结

敏捷、精益团队一方面要保持快速的交付速度,一方面还要提高应用的安全质量,看上去这是鱼和熊掌不可兼得的事情,然而事实上我们依然有办法解决这些挑战。

开发团队可以通过自动化,显著降低安全实践的实施难度和成本,把一次性的安全检查转变为持续性的安全质量反馈。对于安全团队,也应当向着开发团队迈进一步,打通开发和安全部门之间的隔离,以更加紧密和高效协作的方式,共同确保应用具备更高的安全质量。


更多精彩洞见,请关注微信公众号:思特沃克

Share

也谈“精益”

精益对大家来说都不陌生了,无论是最开始提取的丰田制造原型,还是后面延伸出来的物流供应链管理,再到近两年颇为流行的精益创业(Lean Startup),都在不停刷新着“精益”这个概念。最近也不乏把精益当成“热词”来包装的各种理论,以至于很多客户建议我另外给“精益企业”取个名字。我一般都会礼貌回答说:看看精益房子(见下图)吧,我们并没有发明什么新东西。

(图片来源于Six Lean Sigma – Learn | Teach | Impact )

当然,精益房子所表达的架构其实还蛮复杂的,也不是一两篇文章可以论证的,日本和美国管理学界也没有达成完全的一致。很多人的疑惑是咱们好歹是21世纪的新兴产业,肯定跟上个世纪的汽车制造业有不同吧?还用精益思想合适吗?这里我来谈谈自己的理解,抛砖引玉。

精益思想为什么适合于咱们这个行业,在我看来有以下两点:

  1. 追求快速价值交付的小批量生产模式
  2. 追求极致卓越的匠艺文化

追求快速价值交付的小批量生产模式

“这个谁都知道”、“这不等于白说吗”、“这个太虚,来点干货吧” …

这些都是每次抛出这句时会收到的反馈。然后我反问,“能给我讲一下你最近交付的一个功能挣了多少钱吗?”一般这个时候对方会回避我真诚的目光,嘴巴上说着“我们的系统很复杂,一个功能太小了…”。那么我们再来看看各个岗位的绩效考核吧?开发了多少条需求和测试出了多少bug,横比环比增长了多少都是报告中的常客。这里的“价值”被定义为了每个角色、每个人的阶段输出,类似富士康流水线上生产一个iPhone零部件的工人,至于最后是iPhone 6还是7于这个工人其实并没有太大关系,反正这批订单200万台,本周得搞定,做的越多个人收入自然会更多。

上面的例子告诉我们,并不是所有的生产模式都是追求“小批量”的,富士康在生产模式上是成功的,甚至是行业标杆。而丰田制造当年形成精益的生产模式,其核心是追求对市场变化的响应力,即用户一旦变了口味想开SUV,我的轿车生产团队及流水线能够很快调整开始生产SUV,并且我能够通过这种能力快速验证SUV的市场是不是真的。在这样的生产模式下,较之每个员工的资源利用率及输出,我们更关心的是“需求”是否能够在团队快速流动产出最后的产品,应运而生的是对生产批次小规模化及人员跨职能的要求。持续交付(Continuous Delivery)显然是咱们这个行业对这小批量生产模式的总结。

当然不用论证的是科技行业的市场是持续变化的,具有不确定性,所以逻辑上这种生产方式应该是必须的,即使是所谓的后台核心系统,其需求也不得不跟着所谓的前台用户需求变。很多人会说这个很自然啊,咱们拆了User Story做迭代不都是这样吗?那么有多少次大家会说“这几个User Story关联很紧,客户都要,我一起开发(测试)了,效率高一些”、“上线走流程麻烦死了,咱们还是一个月上线一次吧”、“所有都是Must Have,砍不下去了,PM上去磕客户了” …

当然我们不否认有的时候这些意见表达的可能是正确的选择,但显然,坚守这样的生产方式就需要在这些时刻去思考是否大家真的都运用了精益思想来指导自己日常的生产工作。

这个时候可能会有大牛又跳出来拍一砖:”看吧,还是管理的人不懂精益!”

那么技术人员真的理解了“小批量”的含义吗?在你的内心深处有理解包括TDD这样的基础技术实践是在践行精益“小批量”的价值观吗?用测试来描述一个业务小场景,然后加以实现,这种小步前进的方式正是个人对精益思想的日常修炼!每个“小批次”业务场景实现后,都要严格重构,追求代码的极致简洁,这又是我们接下来谈的对”匠艺“的卓越追求。那么环顾四方、环顾行业,有多少工程师能够坚持TDD呢?当开发进度紧张成为压力的时候,有多少人是选择第一个放弃TDD,将“小批量”原则第一个放到裤兜里的呢?!

追求极致卓越的生产匠艺

回到富士康流水线上,一个杀马特造型的青年在熟练地完成着iPhone屏幕的组装,他下意识地拿着工具钳咯噔一下,熟练地把一个屏幕扣入了iPhone的背壳,时间不到10秒钟,然后他开始重复循环。他的眼神好像有点游离,嘴角不时露出微笑,脑子里在回忆着昨晚和兄弟们撸串时的高谈阔论。他到岗1个月,第一天就学会了这道工艺,除了有一次把屏幕扣反了,这一个月还没出过啥问题。最近谈恋爱花钱不少,他每天都工作10个小时,虽然辛苦但想到和女友的甜蜜时光还是觉得值。

上面对等的场景是一个蓬头的程序员,对象(OO)也搞了5年了,这次遇上了函数(FP)项目,于是“WTF”成了口头禅,有时候在pair时忍不住说了还得道歉。最近code review出来问题很多,功能是没问题了,但老是想着修改变量值。每天盯着屏幕的眼睛有几根血丝,脑子里不时闪过无数马匹从Monad身上压过去,都上项目一个月了,最近几个User Story还是被QA揪出不少问题。虽然“心”苦,这段时间还是觉得很充实的,回家地铁成了最好的思考地儿,有时候突然开悟,回家兴奋着也想来个session,当然结果一般都是家人2次元的眼神。每每这个时候都希望第二天快点开始,能够去把代码重构了,实践一把自己在地铁上的灵感。

上面的两个场景很普通,在这两个行业里可能比比皆是。经常我们会开玩笑说一个卖体力,一个卖脑力。但其实本质的不同是生产者采用的生产方式的不同:在流水线上的杀马特少年需要的是严格遵循制造工艺的每一道工序,通过不停的重复形成机体的记忆;而程序员需要的是认清自己认知的局限性,通过不停的学习形成更好的解决方案。好的流水线生产者能够通过认真练习、快速形成机体的记忆,使自己产出的效率和成功率都能够达到一个高水平。好的程序员能够通过刻意练习形成大脑的思维体系,从而能够持续提升自己面临新问题时的响应力。由于丰田当时的“特殊”市场环境,迫使其表面看是一个偏重于前者的流水线,但实际却走出了一条持续学习和提高的文化之路,收获了对市场需求变化的高响应力。

所以有人会说:“对嘛!管理层都想着用熟练工,所以没法有精益的文化了!”

咱们还是小处着手,刚才谈了TDD,现在谈谈pair。曾经作为一名PM,我也为两个人结对指着代码论道半天非常恼火,虽然内心万马奔腾,但对“匠艺”的认可还是阻止了我去拆散这对pair,毕竟我清楚两人确实是在讨论重构而非其它琐事。当然事实证明这对pair现在都是业界有名的敏捷和架构专家了,好歹也算是对我当年苦难的回报。

再次环顾四方、环顾行业,有多少工程师能够坚持pair,甚至code review?有多少人希望能够在功能已经实现的代码之上持续追求卓越,而不是想着我自己干实现快一点好交差。至少这么多年的咨询生涯所见者有限,令人惭愧的是code review成了咨询需要去说服团队的日常工作之一。如果都没有分享和交流,甚至是争论,又哪里来的真正意义上对极致卓越的追求呢?

小结

上面两点可能只是整个精益思想落地层面的两个具体方面,但就我个人的体会而言,要做到已经非常困难了!即使在ThoughtWorks这样对敏捷高度认可和实践的团队里,要坚持做也可谓是一件艰苦卓绝的事情。什么事情喊口号容易,持之以恒的一万小时是每个希望成为精益践行者必须经历的磨练。“着眼长远”这一精益的另一基本原则送给还在坚持的同学们。


更多精彩洞见,请关注微信公众号:思特沃克

Share

精益产品需求的要义

1. 需求的新定义
2. 需求的多重挑战
3. 这么多挑战,有解吗?
4. 精益产品需求是什么
5. 写在最后

1. 需求的新定义

我们这里说的“需求“,是沿循计算机技术诞生以来的“软件需求”,所以可以稍稍先回溯一下历史。下图是Michael Porter的“IT变革的三次变革”[^1]。作者的本意在于看待技术在时代变迁中扮演的角色和地位,我们这里则去看看IT需求的变化特点。

1-three-waves

图1 Michael Porter IT发展的三个阶段

  • 信息技术时代:IT主要是用于实现业务、流程自动化,期望利用技术来提高“效率”,相对而言,因为工业时代的业务流程相对固化、计算机技术资源能力的相对稀少,商业市场对软件的需求变化并没有那么大;
  • Internet时代:互联网变成新的营销渠道,市场对技术的期望不单是自动化固有流程,而是延展业务,所以外部需求的不确定性、变化越来越多;同时也因为技术渗透更广,软件服务的竞争程度也更加激烈;
  • 数字时代:技术渗透到生活方方面面,引领着消费、生活、商业生态的革新,市场变化日新月异,高度竞争,企业都在追求创新,市场对企业的期望是“高响应力“,甚至是引领力。需求变得更加易变、不确定。

我想大家都深切感受到了这个突出的变化,那就是:普遍来讲,市场需求不确定性越来越高,竞争越来越激烈

与此同时,如果对比软件开发方法的发展,好像也对应有三个时代:

2-Software+3+Waves图2 软件开发方法的沿革和需求定义的演绎

  • 软件工程时代:对应于上图的“信息技术时代”。市场需求聚焦在现有业务流程的自动化,大工业时代固化下的业务流程并不会天天变,所以对需求的定义是“软件功能的规范说明”。工作方式是瀑布式的:先花大量的时间模型化业务流程,制作出详细的“需求规格说明”,然后才进行开发实现。
  • 敏捷转型时代:对应于上图的“互联网时代”。随着互联网的出现,信息技术不再是自动化固有流程,而开始延展业务,如进行网上展示、销售和营销。这时,发现需求的不确定性变大了,用传统的“瀑布”方法不能适应外部市场的需求变化,软件项目失败率非常高,于是开始寻找更轻量的、迭代试错、小步前进的轻量级敏捷方法,来提升软件团队的响应力。这时,对需求的定义也演绎为“代表着业务价值的一个单元”。但是,这种变化始于IT也仅限于IT,敏捷方法簇[^2]里需求相关的实践和方法大多是面向技术团队的,如小步发布(Small Release),产品负责人(Product Owner)要和技术团队在一起,来制定团队的迭代计划、排优先级、澄清需求问题等等。虽然开始关注业务价值,但却仍主要度量IT团队的效率和产能。
  • 精益企业时代:对应于上图的“数字经济时代”。面对高度不确定、激烈竞争的市场,发现需求和定义需求的过程,变成一个不断试错、然后逼近“正确结果”的过程,这已慢慢成为大家的共识;同时,面对市场的高响应力、引领力的要求,对需求的验证环路必然要穿越IT、销售、运营、市场等所有职能部门,才能形成端到端的闭环,持续创造市场价值,即“整个组织的更广阔精益变革”[^3]。

因此上,在当前高度不确定性的市场环境下,有必要重新定义下“需求是”:

需求“建立在商业、技术和人之间的一组动态的、待验证的假设”;挖掘和定义需求的过程,是一个不断验证假设、在试错中学习、逐步逼近直至找到与市场的“契合点”的过程。

2. 需求问题的多重挑战

下面是我们在提供咨询时收集到的一些常见的需求问题。看起来是不是很眼熟?

3-Common-Requirements-Problems

图3 组织中常见的需求问题

如果仔细去分析这些问题,本质上会归结为下面的挑战:

4-multiple+challenges

图4 需求的多重挑战

挑战之一: 需求产生时的“不确定性”。产品需求的本质都变成了“有价值的假说”,而不是传统意义上是确定的、一开始就能准确定义出来的。“市场用户需要一匹更快、永不疲倦的马”,是一个“有价值的假说”;“用户需要汽车”则是不断转向、学习的结果。人们善于解决确定性的问题,在面对不确定性的时候,往往束手无策。产品创新连接商业、技术和人,但方向有那么多,该从哪个点开始?如何在首次提出产品想法时,就能(比竞争对手)找出“更靠谱的假设”?这是前所有未有的挑战。

挑战之二: 需求经过层层分解可能完全失去原有意图。即使在最开始,我们独具慧眼,已经识别出更接近“正确结果”的假设,但在落地实现时,因为组织分工、政治、计划等约束,不可避免地会被拆解成零部件,然后再一一实现,组装完了再去验证。在这个过程中,拆解、组装之后的结果很可能让原始的意图面目全非。

挑战之三: 需求实现所必须的社会化协作导致的需求失真、或被“污染”。需求的交付是一个社会化协作的过程,所有参与其中的人背景、知识、能力、出发点、利益不同,在理解、表达、传递、接收、消化、再传播需求时,都会“解释过滤“一遍,这样的协作过程的产物极有可能让需求意图失真、或被“污染”成另外的样子。

挑战之四:需求的时效性。在验证假设的过程中,外部市场时刻发生着变化。可能就要上线验证了,市场上突然来了一个其他的产品横空出世,消费者行为因此而改变,“原有的可选项不再是可选项”。

3. 这么多挑战,有解吗

如果我们认识到,需求只是一组假设,那么我们就会:

  • 转变思维——我们的所有工作过程,不再是一个对确定问题求解的线性过程,而是一个构建(Build)- 度量(Measure)- 学习(Learn)的螺旋前进过程,我们会认为“不确定”是常态,积极主动地调整计划以适应变化;
  • 步子迈得更小一点——每次定的“需求目标和范围”会更小一点,这样尽可能让错误的弯路更短一些,验证的成本也更低一些;
  • 尽量缩减验证、反馈周期——因为这样试错成本更低,所以我们就要拼命靠近客户和用户,与他们对话,花精力研究他们、了解他们;
  • 迫切想知道验证结果——所以在在产生需求想法时,就确定好度量指标和验证方法;
  • 为了一开始找到更接近的假设,我们需要对用户、领域问题、行业生态有更为深刻的洞察;

如果我们认识到,需求层层分解会导致需求变形,那么我们就会:

  • 需求目标定小一点,尽量避免不必要的分解;
  • 简化组织结构,层级少一点,减少层层分解;
  • 建立跨职能部门,减少分解;

如果我们认识到,需求的社会化协作(沟通、传递、协调)会导致需求变形,那么我们就会:

  • 统一需求接口,减少沟通节点;
  • 按照产品职责来设置团队,让市场、技术和消费者直接沟通,减少中间环节;
  • 建立跨职能团队,避免部门政治给需求带来的污染;
  • 采用更直接、更简洁、更高效的方式去沟通,减少信息失真;

如果我们认识到,需求是具有时效性的,那么我们就会:

  • 需求目标定得尽可能小,因为目标越大、验证学习周期就会越长,失效的可能性更大;
  • 时刻关注市场变化,随时做好调整转向准备

所以,需求挑战的应对,不单单是IT团队负责需求的个人和团队的事,更是思维和文化、组织结构、管理流程、领域洞见、沟通和协作能力等各个维度在各个层面的事。

4. 精益产品需求是什么

当前,在诸多开始尝试或已经实施敏捷转型的企业里,应用最普遍的还是团队级的“敏捷开发方法“,有关需求的方法和实践,如果浓缩下来,大概像这张图:

5-agile-analysis

图5 当前常用的“敏捷需求分析“

回头检视,我们会发现通过图上这些方法、实践和工具,主要是改善了IT交付团队内部的“需求沟通和传递”,通过“小步发布“少量地改善了“时效性”的问题,而针对其他问题似乎没怎么改变。因此,也出现了类似这样的疑问:“实施敏捷需求分析的效果,也就是团队内合作和沟通更流畅了,对业务也没什么影响啊?”

如果想要全面应对这些需求挑战,则需要应用“精益企业”[^4]的指导方法——把敏捷、精益的理念思维应用在与需求有关的组织结构、管理流程、领域洞见、沟通和协作能力等各个维度、各个层面。

另外,“传统上,大多数企业秉承以范围、成本和进度为中心进行交付管理,这使得所有人都迷失了,似乎项目交付就是目的,而忽视了投资本身的初衷所要达到的用户和业务目标,更谈不上持续创新。现代科技企业所面对的竞争环境越加激烈,用户和市场的变化迅速,要能够快速适应变化,真正创造用户喜爱的,有竞争力的产品,并持续创新,需要告别以往多年“以项目为中心”的管理,建立一种以产品为中心的软件交付模式”[^5]。要根据面向业务的能力来建立产品团队,在看待需求时从产品的全生命周期——产品的机会发现、定义、启动上线、成长、成熟以及演化去看待和管理需求。

如果尝试给“精益产品需求”下个定义,就是以“精益企业”为指导,以产品为中心,把敏捷、精益的理念应用在产品全生命周期相关的组织结构、管理流程、需求沟通和协作中的方法和实践

结合第2部分的常见需求挑战,无非就是在组织层面应用精益的思想和原则:

需求挑战 精益产品需求的应对策略 方法和实践举例
市场是不确定和高度竞争的 通过设计思维去寻找有价值的需求假设;无论是在探索期和拓展期,构建(Build)-度量(Measure)-学习(Learn)的螺旋前进流程;建立产品团队,每个产品都直接与自己的客户/用户打交道;对业务领域、市场、用户需要洞察 设计思维MVP假设驱动开发验证板(Validation Board)可选性原则精益画布产品团队单一关键指标在线受控实验可视化运营,持续的领域研究和洞见,用户研究用户测试
需求层层分解会导致需求变形 去中心化组织架构、服务治理和数据存储;以业务为边界建立产品化团队;度量响应力而非效率 MVP微服务设计领域驱动设计产品团队跨职能团队
需求的社会化协作(沟通、传递、协调)会导致需求变形 协作需求分析;可视化需求;原型设计;轻量级文档;建立团队契约规则 故事墙看板墙用户故事敏捷快速启动协作式需求工作坊概念草图低保真原型行为驱动开发(BDD)实例化需求价值点分析优先级契约团队协作契约
需求的时效性 小步前进,精益创业实战流程,假设驱动开发, MVP假设驱动开发精益画布单一关键指标纵向切分在线受控实验可视化运营

精益产品需求的目标:

  • 通过在组织、团队、个人层面的精益需求发现、管理、沟通和协作实践,来提升组织的响应力和创新力。

“精益产品需求”的原则:

  • 对业务领域、市场、用户需要有洞见,来主动驱动业务变化,而不是仅仅理解跟随业务变化;
  • 真正以客户/用户为中心,像客户/用户一样思考,由客户/用户价值来驱动决策,而不是利用组织政治来决策;
  • 共同一致的需求愿景和目标,高度透明、可视化、协同地、高质量地需求沟通,而不是不写文档、频繁但低效地沟通
  • 去中心化的产品体系架构和产品团队,负责产品的整个生命周期,而不是项目团队,只注重交付的速率不注重交付的价值;
  • 业务成效来度量和验证价值,形成价值闭环,而不是单单衡量IT团队的交付效率和产能;
  • 产品的需求,少就是多(Less is More), 做减法

6-value-circle

图6 精益产品需求的价值闭环

“精益产品需求”方法:

  • 产品化方法,区分探索期和拓展期的工作方法
探索期 拓展期
基于可选性原则,快速对大量的“方案”(需求假设)逐一验证,期望其中大部分会是不匹配的,而少量的能真正解决问题;以科学方式进行一系列快速、低成本的实验,所有活动以验证假设和消除不确定性为目的,来找到产品市场匹配点; 以价值为核心要素并得到普遍共识的经济模型来进行优先级决策;将需求拆分为小粒度并限制在制品数量,以最快的流速持续为用户和客户创造价值,并收集反馈;将新的特性视为有待验证的假说,基于实际的用户和业务成效而非产出量来衡量取得的进展,并驱动产品的演进方向,甚至调整愿景;将质量内建到交付的每个环节,以高度的自动化和可视化来提高交付效率和降低风险,同时兼顾吞吐量与稳定性
  • 不同产品生命周期的关键方法:

7-lean-product-methods

图7 产品的生命周期及关键方法

“精益产品需求”实践和工具:

8-lean-requirements

图8 精益产品需求的实践和工具举例

我们在跟一家国外大型金融企业合作的过程中,他们实施了“以客户为中心”的组织架构重组,他们已实施敏捷转型5年,想借用此次架构重组来做到“精益产品化治理”,并解决“业务需求响应力慢”的问题。 他们面临的具体挑战是:

  • 经过了几十年的运营,IT系统非常复杂,仅客户平台这块新老系统超过200个,相互紧耦合。
  • 以项目团队进行工作,项目之间相互依赖,经常出现因为等待依赖而浪费大量的时间;
  • 项目启动基本上是瀑布方式,概念阶段和启动阶段长达数月;
  • 开发和运维分开,负责维护的团队觉得不被重视,长期士气低落;

他们的改进路线和应用实践如下:

9-improvement-plan

图9 XX金融企业的需求改进路线

应用实践

  • “以面向业务的能力来构建产品团队”,每个产品团队自己规划自己的项目,以持续交付、持续验证的方式来演进自己的“能力”(如发展新产品,退役旧产品);
  • 每个产品团队设立Product Owner和Product Architect,按照“业务能力职责”,共同规划自己产品体系的发展蓝图及运维支持;
  • 持续的产品需求技能提升训练和实践社区;
  • 产品团队建立后,运维放到产品团队做了之后,发现总体人员规模可以减少1/5 – 目前这1/5的人用来识别创新机会,在团队内开展创新项目。

5. 写在最后

很多企业当面临图4中列出的需求问题时,第一时间想到的就是组织需求分析人员的技能培训,给他们制定一个工作流程,发给他们一个有着“先进实践”的Handbook,然后就期望这些需求问题都能迎刃而解。但这样过了一年,发现好像没什么变化,那些存在的问题还依然存在。希望通过本文,大家能认识到:在新的数字经济时代下,需求不确定性更强,挑战来自于市场外部、组织内部的结构和管理、能力等多个方面。在实施转型或改进时,企业能以一个更系统的视角来看待,真正实现“精益的产品化治理”。

另一方面,从个人和团队来说,图5所展示的“敏捷需求分析”方法和实践依然适用,但应该有两个关键的转变:

  • 一是“产品思维”,“人人都是产品经理”,认识负责产品的生命期,根据不同的生命期取舍不同的需求实践,全面掌握不同生命期的实践方法;
  • 二是“精益思维”,以业务成效来度量,对需求要有效做减法。

参考资料:
[^1]:Michael Porter, http://www.faz-forum.com/scp/150121_SCP_Porter_Harvard_Heppelmann_PTC.pdf.
[^2]:“敏捷方法簇”,指代Scrum、XP等为代表的轻量迭代开发方法。 [^3]:肖然,”从敏捷转型到精益企业”, http://insights.thoughtworkers.org/from-agile-transformation-to-lean-enterprise
[^4]:《精益企业》. [^5]:姚安峰,“精益企业原则之:以产品为中心,而非交付项目”,http://www.infoq.com/cn/articles/the-principles-of-lean-enterprise-product-centric.

Share

精益的新产品启动与技术创业(下)

用真正对用户有价值的技术和产品去创业

接上篇,这篇咱们继续讨论精益创业的实战技法。

设计思维和精益画布是精益创业的有效技法,可以清晰方便的来帮助自己归纳分析已有的信息和资源。

设计思维

6

上图是使用设计思维来启动一个产品的过程,需要经过的过程:愿景(起点)->探索(发散)->定义(收敛)->创想(发散)->原型(收敛)->计划(落地)

愿景:理解客户的项目愿景,收集已有的关于目标用户的需求和痛点。

探索:走出办公室,倾听真实用户的声音,挖掘未知的用户需求。

定义:梳理全部已掌握的信息,定义出明确的目标用户和待解决问题。

创想:针对目标问题进行自由的发散思考,寻找任何有可能的解决方案,寻找创新的机会。

原型:将优秀的创意细化成原型,通过原型测试进一步收集用户反馈。

计划:根据产品原型拆分出产品功能清单,整个团队一起确定交付上线计划。

下面是一个实际的足球比赛产品落地计划:

7

精益画布

8

除了上面这些精益创业的办法,还需要进行一下竞争对手分析和详细的资金使用计划,来减少创业失败的情况。

分析竞争对手从而规避风险

知彼知己,百战不殆。分析竞争对手,从而规避不必要的风险。在进行竞争对手分析时,需要对那些现在或将来对自己产品可能产生重大影响的主要竞争对手进行认真分析。根据创业产品的独特卖点,分析竞争对手,下面是一个足球比赛产品的竞争对手分析:

9

制定资金使用计划

兵马未动粮草先行,初步规划好开发计划和资金使用计划,创业初期,设计良好的资金使用计划从而保证最终产品的交付。下图是一个产品6个月的常规资金使用计划:

10

在创业的路上有了这些策略和计划,会大大减少失败的情况。讨论了精益创业的技法,咱们看看一个实际落地的案例吧。

订餐应用的MVP落地实践

故事的开始: 美好一天从健康的早餐开始,可是每天买早餐都要排长队,这该怎么办?

用户:白领上班族

需求:买早餐不排队

方案:未知

11

根据调研,V0.1版只需要三个步骤:订餐, 选择取餐点,付款,(实体取餐柜入住写字楼)完成定早餐的需求,从而试图解决买早餐排队的问题。

12

(用户提前一天晚上订餐)

13

(选择取餐点)

最后结账付款。

15

(入住写字楼的取餐柜)

用户反馈数据收集:发布调查问卷,实地采访用户感受,假设新功能,验证新功能。

用户调研问题:

  1. 太晚取早餐,早餐冷掉了,这该怎么办?
  2. 我想预定面条,或者饺子,时间稍微长了,虽然是热的,但是粘在一起了?(早餐真的有人想订饺子和面条哦~)

V0.2版本改进:

  1. 带自动加热或者保温的小柜子(需要硬件支持);
  2. 细化取餐时间,更合理的配送时间。

14

原型设计时最后取餐时间可以到中午12点,但是根据实际调研情况,上线后调整到10点,每隔30分钟配送。(一般10点后就没人取早餐了。)

再次用户调研,用户需要定下午茶功能,等等其它新功能,满足不排队的需求。

16

最终通过,精益创业,MVP的方式,打磨抛光出用户由衷喜欢的精致产品!

Share

精益的新产品启动与技术创业(上)

用真正对用户有价值的技术和产品去创业

企业平均寿命从1920年的65年降到了2015年的15年,社会与科技飞速发展,大企业的既有竞争优势迅速弱化,甚至被颠覆。大企业对市场趋势和用户喜好的变化不敏感,错失机会,巨额投资产生不了预期收益。在这种大背景下,给技术创业和创新性的产品带来了更多机会。

借古比今,站在巨人的肩膀上好办事。近代历史上有那些成功的精益创业案例供我们参考呢?看看二战后的美国福特和日本丰田:

1

二战结束时,福特已经掌握了成熟的T型车生产线。但是在战后物资耗尽的日本,丰田必须白手起家,重新开始摸索。福特和丰田都是要制造一部车。

福特:稳定、大批量、执行计划:

2

丰田:灵活、单件流、需求拉动:

3

丰田这样做最终创业成功了吗?1993年,丰田汽车公司以 295 亿日元的纳税款额,荣登日本纳税榜首。”有路就有丰田车”也成为丰田车知名的广告语。

丰田的成功其实就是一次精益创业,技术创业的经典案例。丰田打破了原始的汽车制造方式,采用:灵活、单件流、需求拉动。精益的控制和度量生产汽车的每一个过程,先做出最小可用产品(MVP),尽早投入市场,收集市场反馈,然后根据反馈不断的迭代改进。

同样的,我们不想采用福特的方式制造产品,不想等产品全部做好了才投入市场,不想投入技术和时间做出来的新产品上线后无人使用。我们需要产品准确命中目标用户的真实需求,从而降低创业风险。

我们希望最终得到的不是一堆不知道未来会有多少人使用的代码,而是一件抛光已久、用户由衷喜欢的精致产品。所以需要先做出最小可用产品(MVP),尽早投入市场,收集市场反馈,然后根据反馈不断的迭代改进,不断抛光打磨产品,制造出用户由衷喜欢的精致产品,从而取得创业的成功,甚至像丰田一样伟大。

丰田是大企业,它做的是复杂的汽车,我们要做的是技术创业,一定需要借鉴丰田精益创业的办法吗?我们把功能都做完再上线,不用MVP,不行吗? 不着急一下子就回答这个问题,我们先分析一下技术创业要解决的问题,技术创业的风险,然后看看不用精益的方法是否可行?

技术创业一般要解决一个错综复杂的问题从而产生价值

实际的问题一般可以分为:简单问题,复杂问题,错综复杂的问题。创新型的产品,技术创业一般是解决错综复杂的问题,没有前人经验可以参考,从而产生价值取得成功。

简单问题:很容易理解,它的目标是明确的,达成的路径也是明确的,只要依照步骤来就一定能达成。(比如家里的灯泡坏了,如何修复?买一个新灯泡,卸下坏灯泡,换上新灯泡)

复杂问题:虽然有清晰的目标和路径,但是需要控制很多因素,每个因素都会影响最终的成败但可以通过大量实验来控制。(比如一个大水池,3个进水管,2个出水管,同时开,什么时候能把水池灌满?分析3个进水管的参数,2个出水管的参数,水池的容量,做实验,看放水的时候,水池是否有漏水或者别的损耗,放水时,水的自然蒸发,等等因素,列出公式,实验推算,最后得出实际正确的结果。)

错综复杂的问题:目标和路径都不明晰,需要根据不断遇到的问题去决策,没有现成的经验可以借鉴,创新是可以解决这类问题的。(比如每天早上买早餐要排队,我想每天早上不排队就能买上想吃的早餐。目标和路径都不明晰,需要根据不断遇到的问题去决策: 今天早餐摊位少了一个,买油条豆浆的休息了,导致排队时间更长了。今天周围园区里有一家企业放假了,买早餐的人少了,很快就买上早餐了,等等情况。)精益创业,最小可用产品(MVP)是解决这类问题的有效方法。

创新性产品(解决错综复杂问题)的特点

4

创新性产品,一般要解决一个错综复杂的问题,提供一种独特创新的解决方案,需要根据不断遇到的问题去决策,没有现成的经验可以借鉴,一般情况下,产品演进的道路是曲折往复的,最终要得到产品也是不明朗的,但是最终都要逐渐收敛逼近到可用的产品,产生价值从而取得成功。

在技术创业时您可能遇到下面的情况和风险

  1. 目标用户是否存在?想到了一个解决方案就直接想要做出来,顾不上做用户调研,不了解设想的目标用户是否真正存在、用户群有多大、生活的状态是怎样的。
  2. 目标用户是否有这个需求?思考从解决方案出发,想到或看到一个功能,觉得不错就想做。没有去验证目标用户是否真的有这样的需求,是否早就有了很好的产品解决了这个需求。
  3. 技术与解决方案是否有亮点?想到一个还可以的解决方案就不再继续探索了,一些创新的点子觉得它不可能就直接放弃了,没有掌握做创新的有效方法。
  4. 一开始就规划大而全的产品有用吗?想做个大平台,想要做精致的用户体验,想做精品,想到什么功能不错就想往产品上加,想要一下就做的很完美。但如果一开始方向就错了,再精致的产品,它的价值也是零。

再回到我们起初的问题:要做的是技术创业,一定需要借鉴丰田精益创业的办法吗?我们把功能都做完再上线,不用MVP,不行吗? 分析了技术创业要解决的错综复杂的问题,最终产品的不确定性,要面对的风险。由于这些因素,所以需要使用精益创业的方法来帮助解决这些问题,规避这些风险,这是实际实践过程中总结出的一套有效的应对办法,能有效的帮助技术创业取得成功。

精益创业的核心思想是:专注于学习未知,积极验证假设,尽早面向客户,持续演进。具体操作方针:

  1. 科学地做调查和实验:一开始创业者需要认识到对用户、需求、解决方案的猜想都是主观的,必须把它们视作“假设”。快速开发功能并上线给用户使用,通过数据追踪等方式进行用户研究,验证这些假设是否成立。
  2. 尽早上线并开始测试:不要等到所有功能开发完毕才上线,而是将核心功能开发完成,形成一个最小可用产品(MVP)就立刻上线,尽早开始对用户需求假设进行测试和验证。
  3. 追踪可帮助决策的指标:在决定追踪哪些指标时,不要只是追踪宏观的整体指标,如总的PV、UV,而是要找哪些能够直接验证功能价值,能够帮助我们形成判断的针对性指标。5
  4. 建立反馈环并持续测试和验证:建立“猜想->建构->验证”的反馈环,每个迭代都能持续地测试功能的价值假设是否成立。假设成立就追加投资,假设不成立就要尽快做减法,删减后续投入。借助这种方式,来推动产品的持续成长。

时常使用这4条来检查自己的创业产品,不断收敛逼近到真正可用的产品,规避风险。到这里咱们讨论了精益创业的方法,下篇咱们继续讨论实战的技法。

Share