银行移动产品从团队敏捷走向产品敏捷

中国银行业的数字化转型刚刚拉开帷幕,移动产品成为了中国银行业的新战场。为在新战场占有一席之地,各家银行开始纷纷尝试自己移动产品的敏捷转型,更有甚者开始重新组建IT团队,用敏捷的方式重做原有的手机银行产品。

但这些转型往往在6-12个月后显示出明显的疲态。基本的实践都已经导入了,团队似乎已经“敏捷”了,但产品的响应速度并没有变快多少(想法的提出到上线的时长),产品的线上月活也没有显著的提升。那么敏捷转型到此就结束了吗,敏捷转型的下一步我们又该做什么?这篇文章作者将以多个实际案例出发,为大家揭晓银行业的移动产品如何从团队敏捷走向真正的产品敏捷。

团队敏捷是必要的,它是产品敏捷的必经之路

银行移动产品的敏捷转型很难一蹴而就,团队已经适应了“慢节奏”,习惯了阶段式的开发方式,敏捷的导入,无疑是一场变革。大规模的灌入标准化实践,最后的结果只会是“有形无实”,就像办公室中贴满五颜六色便签纸的白板,最后都沦为装饰品(数周也不更新)。

团队敏捷作为敏捷转型的第一步,以了解团队、分析痛点为前提,定制化的导入实践,让团队从传统向敏捷的开始转变。转型团队敏捷聚焦IT研发团队内部,包含产品、研发、测试人员,目标是:

  • 打造出一支敏捷迭代运作的IT研发团队
  • 建立团队级的敏捷流程及工程方法
  • 以及初步形成内部改进的种子力量

以50人的手机银行团队为例(4个全功能团队),团队敏捷从开始转型到稳定运作会持续4-8个月的时间。具体的转型过程就不在这里多做论述了。如果您的团队已经满足了以上的3个目标,那么恭喜您,您的团队已经迈出了敏捷转型的第一步。

产品敏捷的目标

“创业像开车,而不是发射火箭” ——埃里克 莱斯(精益创业的作者)

做产品也是一样。环境变化太快,产品很难像发射火箭一样,经过长时间缜密准备再发射验证。产品要像开车一样,有一个前进的方向,之后在行驶过程中根据外界的变化快速做出调整并验证,产品敏捷的目标也将聚焦于此。

  1. 帮助产品构建像“开车”一样,可以根据外界变化做出快速响应的能力;
  2. 在产品演进的过程中,帮助产品选择相对正确的“行驶”方向,帮助产品实现“弯道超车”。

很显然,团队敏捷,主要聚焦于研发团队内部的改进,对以上两点的影响并不大,更像是敏捷的萌芽和生长阶段。产品敏捷是以上述两点为目标,端到端(想法的产生到功能的上线)的分析及改进整个产品的实施过程,像是敏捷的开花结果。

走向产品敏捷的三个关键点

一、构建产品快速响应的能力

产品TTM(Time To Market)的长短体现了产品的响应能力的高低。以TTM的持续缩短为目标,是整体转型的关注点从“资源效率”到“流动效率”的改变,分析“流动单元”在产品端到端的实施过程中的流动情况,找到瓶颈点并加以改进,来持续提升“流动效率”,是转型的关键,主要分为3个步骤:

  1. 分析并定义产品端到端的实施过程;
  2. TTM的相关数据采集;
  3. 基于VSM的持续改进。

步骤1:分析并定义产品端到端的实施过程

团队敏捷中我们聚焦IT研发团队内部的迭代运作,在产品敏捷,我们需要以版本为维度,以需求为“流动单元”去梳理并定义端到端的研发过程,关键点是将产品版本与研发迭代融合

如下图,以某金融产品按月发版,研发双周迭代为例。需求分为Epic,Story两个层级,Epic为解决一个用户问题,Story为实现Epic的功能拆分。在版本迭代,我们关注的是Epic的流动(一个版本会包含多个Epic),从想法的提出,到最终的上线。在团队迭代来研发产品,我们关注于Story的流动,从Sprint Backlog的确认,到功能的持续交付(SIT环境)。端到端的实施过程覆盖了所有活动、产出件及流程流转,每一项都有自己独特的意义,每个产品的运作方式都有可能不同,重点是加强各个角色间的协作,使得团队适应该种运作方式,可以稳定的运作。

(某金融产品 产品端到端实施过程)

步骤2:TTM相关数据的采集

数据采集的前提实施过程梳理清晰且团队稳定运作。根据实施过程,我们可以清晰的得出Epic和Story的两条价值流,如下图。TTM是每个Epic从概念到上线的平均时间(如果Epic都是运营类的小需求,建议做合并成一个Epic)。当然Story的大小我们是可控的,Story的产生到集成测试完成的时间我们也要关注。

(某金融产品 Epic、Story的价值流)

数据不是通过WorkShop的问问答答就能得出的,需要借助电子工具的辅助,做准确的分析。首先作者对于电子工具的态度是:工具是辅助运作,而不能影响运作,不能出现由于电子工具的限制而改变运作结构。电子工具的目的是便于过程管理及可视化。

作者推荐的工具是Jira,Jira的优势在于可以通过配置实现高度的定制化,以及开放API数据接口(商用版)。作者建议抛开Jira中大部分的预定义好的模板及元素,根据现有的运作方式,做深度的定制(例如Story元素的重新定制)。从Jira中“问题属性”、“字段”、“界面”、“工作流”、“权限”等的自定义,到Jira Agile中的“看板”,“阶段”,“移动规则”等自定义。由于是相对于底层的定制,所以配置起来比较复杂,这里要保持开放的心态。

如下图,根据运作方式,在关键节点引入Jira做管理,并且根据运作方式,确定Jira的使用规则。

(某金融产品 配合运作方式的Jira使用)

在上线了2-3个版本后,我们就可以尝试做数据的采集及分析,Jira提供了方便的API接口供我们提取数据,要注意数据清洗及公式的配置,最后得出每个版本的TTM时长。

步骤3:基于VSM的持续改进

我们使用的实践是精益中的VSM(Value Stream Mapping)价值流图,来做持续的改进。通过Jira中的数据,建立Epic和Story的价值流图。以Story为例,如下图,数字为Story在该阶段的平均停留时长(天),按照迭代做分组。分析数据找到可能的问题点,很明显前4个迭代“待联调”和“测试中”的用时很长,之后去做该阶段的原因分析并尝试改进,再分析新的数据(第5个迭代的数据提升),以做到团队的持续改进。

当然了这里面的问题点是多样的,组织、需求、管理、技术等因素都可能成为问题的原因,这里的重点是找到核心问题,拿着数据证明去尝试解决,最终也可通过VSM也来体现我们的转型成果,这也是真实的量化的数据。

(某金融产品 前5个迭代,Story的VSM)

电子Dashboard。持续的Excel取数很难做到实时。尝试做电子Dashboard,做到价值流实时可视化,便于信息的透明化及持续改进,为提高产品的响应力打下坚实的基础,详见下图。

(某金融产品 价值流Dashboard)

到此阶段,您的团队已经有一套端到端的稳定运作方式及电子管理平台,可视化的VSM来体现问题点及成果展示。剩下的就是大胆去做瓶颈的原因分析及改进,来持续的提升产品的响应能力。

二、帮助产品实现“弯道超车”

金融科技企业对中国银行业的冲击是巨大的。多家传统银行直面差距,定义自己的移动产品策略是“追赶”,产品经理的惯性思维,“XXX有这项功能,做了这项优化,我们的产品要把它加上”。当然了如果落后,追赶固然没错,但在追赶的过程中我们也要制定赶超的策略。

金融需求无处不在,衣食住行娱每个细分场景都有金融需求出现,对于传统银行,信誉,数据、网点、存量用户等都是自有的优势。那么结合用户的需求与自身的优势实现金融产品创新,才是“弯道超车”的关键

利用设计思维的方法来获取、定义及实现用户的需求。扭转业务、产品、研发等角色的本位思维,从提出需求走向了解用户痛点,从实现需求走向为用户创造价值。

(设计思维的双钻模型)

建立产品内部的创新机制,抛开传统银行自身的限制,鼓励全员创新。如下图,从一个创新想法,到MVP的制作验证,最快只需要3周的时间。立项通过的想法进行2-3个月的孵化验证,最终有望形成新的商业产品。过程中给予创新者创新教练、团队资源的专项支持,内部创新的同时也在培养团队产品思维,提升团队的产品能力。

(某银行的内部的创新机制)

三、培养内部教练队伍

这个是敏捷转型的基础,需要进行管理、技术、产品、创新等内部教练的梯队建设。组织中缺少的是经验积累及专有人才,而不是流程规范。之后作者会以专文来讲述企业内部教练的体系建设。

总结

在移动金融产品的新战场上,银行的移动产品需要从“发芽生长”的团队敏捷,走向“开花结果”的产品敏捷。

三个关键点助力产品迈向产品敏捷:

  1. 通过产品开发过程端到端的梳理与定义,电子工具的引入,基于VSM的持续改进,来持续缩短产品的TTM,构建产品快速响应的能力;
  2. 使用设计思维打造产品,并建立产品内部的创新机制,来实现金融创新,帮助产品实现“弯道超车”;
  3. 建立企业内部的教练体系,注重人才培养及积累经验,来推动敏捷的发展,促使产品持续进步。

最后,希望中国银行企业把如今市场中的不确定性,看做是产品的新机遇。对于这种新机遇的驾驭的能力,将成为产品优胜劣汰的关键。


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

Share

服务蓝图再思考

服务蓝图(Service Blueprint)是服务设计中重要的实践之一,本文将回到这一实践的本源,重新思考其核心逻辑在新的消费环境中是否需要演进。

溯源

服务蓝图(Service Blueprint)这一名词可追溯1984年1月哈佛商业评论中G. Lynn Shostack的文章《Designing Services That Deliver》,此文首次将对服务的设计分为以下几个过程:

  1. 定义流程
  2. 区分出服务失败点
  3. 引入时间效能
  4. 分析盈利模型

(一个擦鞋店的服务设计)

此外,Shostack还建议了执行这个蓝图的几个要点,其中包括:

  1. 客户可见和不可见的部分,用可视线(Line of Visibility)进行分隔;
  2. 强调统一制式的物品(Tangible Evidence)对服务承诺的正向影响,例如航空公司整齐划一的制服、物品或用具;
  3. 强调人对于整个服务体验的影响。

由于欧美国家时薪制度的标准化,标准服务流程中的时间估算,可以计算出一项服务的成本和盈利模型,因此服务蓝图有着强烈的标准化、工业化、系统化、商业化和控制化的基本属性。

Shostack在本章的最后也指出,服务蓝图的作用可归纳为:帮助服务提供商节省服务时间、提高服务效率、以及高视角完成对服务流程的管理。不得不忽略的是这一理论的出现,正处于美国进入服务业时代的1980年代中期,企业迫切需要一种对服务进行有效规划和管理的手段。

延续

服务蓝图偏流程和系统效率的特点延续到近几年服务设计的兴起。在服务设计中,服务蓝图被认为是客户体验地图(Customer Journey Map)的延伸,在传统客户体验地图的基础上添加了客户触点、跨部门的前中台服务人员行为、后台系统流程支持等元素。

(图片来自:http://suo.im/22QugV)

许多元素,例如中后台的交互、可视线、物理实物、服务时间等都被保留,其本质并没有脱离G. Lynn Shostack最初的概念——系统、任务、流程、和效率依然是服务蓝图的主题词。

全新上下文

如果我们回到Shostack所处的时代,服务有如下特点:

  1. 客户有固定的场所与服务商进行互动,如银行、酒店或是机舱;
  2. 为了追求效率和成本考虑,相同事务的客户有着统一的服务流程,而随着时间的推移,服务本身是趋向于统一化、稳定化的和简化的;
  3. 时间即服务成本、客户也期待更快速的服务,因此用更短时间完成服务,是客户和服务商的共同诉求。

当我们走完21世纪的第一个十五年,服务对于我们而言,有着惊人的变化:

  1. 客户不在固定场地与服务商互动,同一场地可能跟多个服务商互动;
  2. 客户追求多元化、定制化、个性化的服务流程,服务需要不断创新,而不是趋于稳定和一成不变;
  3. 客户体验开始替代完成任务,短时间完成服务不再成为唯一诉求,反而成为服务商的机会。

策略的变化

在传统上下文中,服务提升的策略有以下几种:

  1. 标准化流程,包括流水线化以降低服务人员培训成本、独立或外包某一核心模块、细化的指标进行精细管理;
  2. 管理关键事件,对客户等待、抱怨、投诉等典型事件进行集中处理;
  3. 减少和简化触点,并缩短触点交互的时间,即减少关键事件和非标准化流程出现的几率;
  4. 提高客户参与度,增加客户主动参与服务的比重,以降低服务人员的成本,例如便利的自助服务;
  5. 对客户进行分组,用几个分割的、相对简单的子系统代替一个相对复杂的统一系统,例如银行的对公和对私业务;
  6. 将复杂过程集中处理,减少客户在一个流程中走动的时间,例如多个窗口的转移;
  7. 增加信息透明和流动减少服务的失败和返工。

在新的上下文中,这些策略可能发生变化、或者被赋予了新的意义。

  1. 服务人员被赋予了更多决策权,以在标准化流程的同时针对客户的个性化需要提供服务;
  2. 移动社交网络赋予客户更大的能力,对于客户投诉需要全新的管理策略;
  3. 增加触点或增加触点交互的丰富度,以提高触点体验的沉浸度,而非一味减少或简化;
  4. 提高客户参与度的目的不再是降低服务成本,而是满足客户的特殊体验需要;
  5. 尽可能提供一站式的服务体验,而不是分割客户;
  6. 降低客户对复杂过程的感知,尽可能取消窗口,而不是缩小窗口间的距离;
  7. 由于单个客户获取信息能力的大幅提高,增加信息透明和流动成为服务商不得不做的事情。

服务蓝图实践

一项设计实践是否需要演进,取决于:1)其所在上下文是否发生变化;2)其是否鼓励新的设计策略。从这个角度来看,服务蓝图实践传统逻辑所在上下文发生巨大变化、其所鼓励的设计策略(简化、稳定化、标准化、专业化等)也发生巨大变化,我们应该重新审视服务蓝图实践本身是否符合现代服务体验设计的需要。

在我们的实践中,该实践的真正意义有两点:

  1. 用一种概括性的手段,梳理服务体验的诸多要素,初步建立上下文,寻找到设计的突破口,即建立问题或机会假设(Hypothesis),基于此进入深入的设计研究;
  2. 通过系统化的分析,寻找内部系统的边界、集成、和信息流动,帮助我们建立服务背后信息系统的初步上下文。

注意,此二点都不是完整的设计实践,而是建立上下文(Context Building)的实践,从这个意义上来说,服务蓝图,已经不是一张蓝图,帮助我们在长时间内固化服务方式和流程,而只是理解上下文、寻找设计突破口的工具。

服务蓝图在新的上下文中,即不是规划工具、更不是设计工具、而只是帮助设计师建立上下文的沟通工具。

写在最后

我们今天所知的任何一项设计实践,都并非新鲜之物,它们都有其最初的上下文、目的和基本逻辑——当上下文和目的在新环境下发生变化,其基本逻辑也必然需要发生转变。

服务从标准化工业流程朝着个性化发展、客户议价能力有着巨大提升、服务地点和品牌边界日趋模糊和灵活,这些上下文使得一个固化的蓝图(Blueprint)失去曾经的意义,那么服务蓝图作为设计实践的一种,我们对它的认识也需要更新——它只是帮助设计师建立上下文的沟通工具,即无法设计服务、也难以指导规划。


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

Share

浅谈软件项目规模估计——估什么?

预测是一件非常困难的事情,尤其是预测未来。—— 尼尔斯.玻尔

玻尔

定制化软件开发是一件复杂的事情,尤其是目前我们主要提供的端到端软件交付,它极大拓宽了软件开发的生命周期,更加着眼于业务价值,但这也增加了整个设计、分析、交付过程中的复杂度。软件交付已不仅仅是传统意义上的技术交付,更包括了体验设计、业务分析、测试、管理、运维、运营支持、以及流程管理的内容。

基于笔者几年浅薄的软件交付经验,尝试总结在初期进行规模估计的时候,应该考虑的范围会有哪些。

体验设计

在笔者看来,在互联网产品的影响下,目前客户对体验设计的要求已经到了“奢侈”的程度,经常对仅有几十个、甚至几个用户的系统提出很多关于体验式上的较高要求。但人毕竟是视觉动物,好的展示效果、使用体验往往是产品的加分项,能带来比较大的口碑收益。同时,这也是最容易跟客户(尤其是业务客户)产生交流和互动的地方,有利于跟客户的深入沟通,特别是这些终端用户还经常是项目重要的 Stakeholder。

在端到端交付中,设计人员会参与项目的整个交付过程,从最开始的 Discovery 一直到产品的上线,从与客户沟通设计需求,到方案设计、方案确认,再到开发过程中与开发人员、业务人员协同方案落地,从源头到落地保证方案的准确性。

功能性需求

在敏捷软件开发中,系统的业务功能会从终端用户的业务价值交付出发,被拆解为一个个用户故事,形如:

故事卡模板

全部的业务功能会形成一个用户故事列表,来从更细的粒度上描绘业务全景。 这部分是项目规模估计中最重要的一部分。所以业务分析和拆分的整个过程要非常非常非常的仔细,因为初期的这个故事列表很可能会成为对客户的一个承诺,未来如果发现不在故事列表中,但也必须要做的重要支撑功能时,就需要增加跟客户协商谈判的成本,或者默默的认了。

在拆分完成进行复检时,敏捷团队(而不仅仅是BA),可以问自己下面这几个问题:

  • 客户所处的行业是什么?本行业有没有固定的业务领域模型?客户想做的是哪个模型的扩展?
  • 有没有类似的竞品可以参考?
  • 有没有考虑系统交互的全部的用户角色?
  • 有没有系统自动推进、不需要用户交互的任务?
  • 有没有考虑全部的业务场景?正常的场景和异常的场景?
  • 每个场景的每一步是如何对接的?具体的详情是什么?是否可以进行进一步拆分?
  • 每个环节使用的用户数量是多少,会有性能要求么(精确到每个指标)?
  • 系统边界是什么?待开发系统和待集成系统各自完成的业务功能是什么?
  • 是全新的系统,还是需要与旧有系统做数据迁移,逐步替代?是否有逐步替代的计划和方案?

拆分方法可以参考《庖丁解牛:产品需求分析》,在这里就不展开了。

非功能需求

除了功能需求外,非功能需求更要引起重视,这往往是项目容易忽略、掉到坑里的地方。

考虑到我们开发的往往是 Web 或者 Mobile的产品,最基本的,要考虑:

  • 浏览器的兼容性问题:兼容哪些浏览器,兼容版本。
  • 移动端的兼容性问题:兼容哪些手机设备,操作系统,版本号。

除此之外还包括:性能,可维护性,可测试性,可用性,可移植性,可扩展性等,项目太多就不展开了,这里单说下性能。

性能是个比较容易量化的需求,比如同时并发访问的人数、页面读取时间等。对于一些用户量较大、高并发的场景,可能需要做多级的性能调优:从应用代码级别、到数据库级别,再到部署架构级别,甚至CDN缓存级别,都可能成为需要考虑的部分。这部分根据项目的情况不同,差异会很大。有的项目可能并不需要投入太多精力在这上面,只需要对其中明显的性能问题进行一些修复,但有的项目可能整个项目都在满足性能上的要求,所以不可不察。

技术架构

有些项目,客户会比较看重我们对产品架构的设计能力。这个时候,技术架构不仅仅需要简单满足短期项目的诉求,还需要有更长远的规划。在这种情况下,前期 Inception 的时间不能支撑整个项目技术架构的设计和搭建,可能是需要更长时间的设计和演进,这部分可以作为独立的工作来进行估计。部署架构亦然。

开发部署环境

同时,为了能够支撑持续集成/持续交付,整个交付过程往往需要一系列的开发、测试、上线的环境,包括但不限于:CI环境、开发环境、QA环境、SIT环境、UAT环境、Pre-Prod和Prod环境。如果这些没有预先准备好的话,这些环境的准备工作也会花不少时间,尤其是当同时涉及客户内网和外网的情况下,甚至会成为项目的严重风险。

与三方的集成

集成往往不是个小问题。目前的软件项目,往往都是基于现有的系统进行开发,所以集成的工作必不可少。如何进行契约的制定、数据的迁移、其它供应商三方系统开发工作的推进、接口的集成联调等,往往都是项目全周期的工作重点。一定从项目第一天开始就要思考持续集成、持续交付,万不可把这部分工作留到最后处理,血泪经验之谈。

测试

敏捷项目中的测试,跟传统的先开发、再测试的这种方式极为不同的一点是:没有固定的 Tester,而是全员来保证软件的质量。测试包括的范畴也比较广,目前项目中的标配包括了:

  • 自动化测试:单元测试/集成测试/功能测试
  • 迭代内探索性测试
  • 业务回归测试
  • 性能测试
  • 安全测试
  • 代码质量测试

这些测试根据项目规模、复杂度的不同,规模估计上会有较大差距。就比如安全测试,有的系统是面对企业内部用户使用的,仅部署在内网,这样仅实现内部权限控制即可,一般不会有安全问题,安全测试的粒度也可以适当放粗;但有的系统要部署在互联网上,供终端用户使用,此时安全测试不仅仅要考虑应用层面的权限隔离,还要考虑网络层面的防火墙、防攻击策略等。这部分可以由专业的安全专家提供建议方案,看如何合理的将测试任务放到总的规模估计中,并与客户提早达成一致。

验收交接流程

这部分是比较容易忽略的,主要包括了软件的整个验收流程、代码交接、文档撰写工作,根据情况不同,可能会使项目延长1周~4周不等的时间,在项目之初也要考虑到。

总结

在初期进行规模估计绝不是一件容易的事情,需要跟客户的深度沟通,敏锐的洞察力,多角色的思考,以及快速的判断,否则后面。。。

Share

庖丁解牛:产品需求分析

在庄子的《南华经》中有一则寓言。说是有位叫丁的厨师,替梁惠王杀牛,其技法之娴熟,有行云流水一般的顺畅感。惠王就问他为什么有如此高超的技术。他回答说:“臣所喜好的是『道』,早就超越所谓的技术了。最初臣杀牛的时候,眼里看到的都是『完整的牛』;三年之后眼中就再看不到『完整的牛』。到了现在,臣以精神接触,而不用眼睛看牛,视觉感官停止了而精神在活动。按天然的道理,击入牛筋骨的缝隙,顺着筋骨的空洞进刀,依照它本来的构造,牛的筋骨接合的地方,臣都未以刀刃碰到过,而何况是大骨头呢!”

同样的道理。当我们在面对一头牛--复杂的业务需求时,如果不得其构造,不明其法,是不能够很好的拆解的。只有对需求深入了解,按照其本来的构造,在筋骨的缝隙处下刀,才能拆出不错的用户故事。今天在这里,就给大家介绍一些解牛之法。非『道』,唯术尔。

工作流系统

我们平时经常会接触到工作流类的系统。所谓工作流,就是我在完成一件工作的过程中,需要经过多个步骤,可能还会有多个不同的角色参与。对于这种系统,我们一般有两种方式 —— 横切和纵切。

1、横切

所谓横切,就是先切分出工作流中核心且轻薄的一层,然后再去实现各个步骤中的细节部分。这对于那些核心业务逻辑比较简单、但每个步骤的附属功能多且复杂的工作流系统来说比较适用。

(横切示例)

举个例子:

假如现在我们需要做一个商旅订票系统,其简化的订票流程如下图所示:

(携程商旅的工作流案例)

在这个流程中,每个步骤都包含了很多个功能。比如“会员查找需要预定的航班”这一步,会员的需求可能会包含:

  • 根据起始城市搜索航班
  • 根据选择的城市,找出最近的机场所在城市
  • 使用GPS定位所在城市
  • 翻转起止城市
  • 根据航班号选择航班

如果采用横切的话,我们仅会选取让本流程可以工作的最小故事集,如

  • 根据起始城市搜索航班

甚至,在本故事中,我们可以设置会员仅能通过精确输入起落地城市名称的方式,来进行航班搜索,在不影响本步骤走通的情况下,来最小化这个步骤的工作量。其它的流程也使用同样的策略,来加速打通整个业务流程。

横切的优势在于可以快速实现核心逻辑,并快速上线,验证假设并收集反馈,可以根据反馈的结果来决定每个步骤中的功能应该如何设计、优先级是什么,来避免一些可能出现的浪费。缺点在于整个工作流设计会采用短平快的原则,用户体验较差。

2、纵切

另一种方式是纵切。纵切就是按照工作流中的每一个步骤进行切分,这样可以使每一个步骤都具有相对完善的功能,这在某些需要关注终端用户交互体验的产品中应用较多。注意,这里有个技巧:如果在整个工作流中,需要跟终端用户进行交互的功能仅出现在某几步中,如第一步和最后一步,而中间的N-2步都是后台流程,在开发中,我们可以先实现第一步和最后一步的功能,而中间的流程处理环节,仍然采用逐步线上化的方式,这样可以使整个工作流系统最快的上线,同时能平衡用户的交互体验。

(纵切)

比如上面携程商旅订票系统的例子,我们可以把涉及终端用户操作的步骤:

  • 会员查找航班
  • 会员发起订票申请
  • 公司审批人审批订票申请
  • 会员收到订票成功通知

把这几个步骤拆出来优先实现,及早上线;而中间的跟票务相关的步骤,仍然采用线下的形式。比如工作人员在携程商旅后台,把订单导出到excel表中,人肉打电话给票代,再把票代确定的订票信息填入系统,然后手动通知会员。这种方式对于一些流程复杂但用户量较小的初创公司比较适用,可以在保证用户体验的情况下,大大提升产品上线速度,并降低试错成本。

在这里要注意的是,不管是横切还是纵切,工作流中的每一个步骤都会遵循80/20法则,也就是20%的功能决定了这个步骤的核心价值,而80%的功能仅仅是锦上添花的,所以我们需要更深刻地研究客户的真正需求是什么,提炼出这20%的业务价值到底在哪里,从而进行更加合理的拆分。

功能模块拆分

对于已经拆出的功能模块,仍然可以根据一些方法进行进一步的拆分,这里介绍三个方法。

1、按业务规则拆分

同样的流程和操作,由于输入的数据业务规则不同,因此进行数据处理时采用的方式也不同。对于这样的情况,我们可以把功能按照业务规则来进行拆分。

典型的例子是搜索引擎,比如Google。在Google中,输入框只有一个,但Google会根据你所输入的数据规则的不同,来进行不同的处理操作。看下面几种情况:

  • 在Google搜索框中输入一个关键字,得到这个关键字相关的搜索结果
  • 在Google搜索框中输入一个算式,如“ 1+1=”,得到算式的结果
  • 在Google搜索矿中输入“ThoughtWorks site:www.example.com”,得到在www.example.com这个站点中出现ThoughtWorks的页面

对于这样的情况,我们可以把每一个业务规则都单独拆分成一个用户故事。当然,虽然这些用户故事看起来很相似,但是大部分情况下,这些规则的优先级是截然不同的。总会有一簇最高优先级的用户故事以及围绕在外围的用户故事。比如在这个例子中,对于Google来说,支持关键字搜索一定是最高优先级的,需要在产品设计的一开始就要实现,而能够计算算式的,可能很多年之后,才开始考虑加这样一个功能。

2、1+N模式

第二种情况,是对同样一个流程,在终端接不同的网关或渠道。最典型的例子是在线支付。比如,我在京东上买了一盒磁力橡皮泥,提交订单进入支付流程,在支付页面可以选择微信支付、京东支付、银行卡支付等等。

第一次实现支付的功能,可能会比较复杂,但后面如果从一种扩充到多种支付方式,就相对比较简单。而且最先需要支持什么样的支付方式,你可能在一开始也拿不定主意。这个时候,我们不妨将支付功能拆成2张卡,形如

  • 会员可以使用微信支付/京东支付/网银支付中的一种进行支付
  • 会员可以使用微信支付/京东支付/网银支付三种渠道进行支付

使用这种拆分方法,可以延迟决策-我们需要最先支持哪种支付方式,同时合理的评估项目的工作量。

3、复杂的业务模型拆分

对于有的系统,业务模型可能会非常复杂,比如一个房产交易平台中的房产信息,可能包含户型信息、中介信息、地理位置信息、价格及购买相关的税率信息、展示图、效果动画等等,当我们需要在系统中引入这样一个业务模型时,如果一上来就要考虑清楚这个业务模型的方方面面,是个性价比很低的事情——做了很多功课,但没有给客户带来真正的业务价值。

这个时候,我们需要将业务模型,按照我们实际需要提供的功能进行拆分。比如,我们要做一个中介搜索系统,可以仅取出模型中的中介信息,而不需要处理其它部分。即使我们需要整个业务模型去做一些事情,也可以把其拆成一个个子模型,根据子模型的业务价值及优先级去设计相应的功能。

比如在这个例子中,我们需要对房产的信息做展示

  • 对于户型信息,需要有户型图,户型相关的文案展示
  • 对于中介信息,可以看到中介人的头像、联系方式,可以使用多种方式在线联系中介代理
  • 对于地理信息,我可以在Google Map上查看其地理位置,并能够从我的位置导航过去
  • 对于展示的图片和动画,我需要像幻灯片一样,可以在页面上播放
  • ……

那么,如果我们一开始就着手于解析这个房产业务模型,那可能浪费了很多时间,而没有交付对用户有价值的业务功能。这个时候,我们需要区分哪些信息是核心信息,是对用户来说最有价值的,把这些信息从业务模型中提取出来,而后设计相应的更小的业务功能,切忌一蹴而就。

需求拆分是否有一套完美的方法?

需求拆分是没有银弹的,要根据具体的场景、限制来选择合适的拆分方法。在遇到使用某个拆分方法,不能满足当前业务需求时,看看是不是可以换个思路,换个方法。

当然,在选择拆分方法时,也有一些技巧,如

  • 基于80/20法则,选择那些可以拆出低优先级卡片(或者可以被扔掉的卡片)的拆卡法。
  • 选择可以把卡片拆的大小差不多的方法,未来在发布计划中更容易做需求置换
  • 选择开发团队更容易理解和实现的方式

当然,这一定不全面,每个人在不同的场景、限制条件下,都会有不同的技巧。相信你自己的拆分方法,多与团队成员沟通才是不变的法门。

以终为始-故事验收方法

Bill Wake提出了一个好用户故事的验收标准——INVEST模型,它由六个单词的首字母组成,分别是

  • Independent:每个用户故事应该是独立的,不会和其他用户故事产生耦合
  • Negotiable:并不会非常明确的阐述功能,细节应带到开发阶段跟程序员、客户来共同商议
  • Valuable:每一个用户故事的交付都要能够给用户带来用户价值
  • Estimable:不需要能够准确的估计,但需要能辅助客户排定优先级
  • Small:要小一点,但不是越小越好,要大小合适,可以更容易的圈定故事范围
  • Testable:需要能够进行验收测试,最好能把Test Case提前加进去

这不仅仅是故事的验收原则,更是在进行需求拆分的时候所需要考虑的拆分原则。当然,凡事有例外。在需求拆分中,有时会拆出一些实在不能满足INVEST原则的故事卡片,也不要太纠结,我们追求完美,但也总要接受现实的不完美。这个时候,跟开发团队多交流,开拓思路,协调一个比较好的拆分方式,比自己一个人憋大招要好的多。

最后

再介绍几个反模式。

  • 按照技术架构分层进行拆分,常见的会按照持久层、应用层、展示层进行拆分。这种拆分方式拆出来的用户故事,会明显破坏INVEST中的Valuable的原则,而且各个故事卡由于各方面的原因,如开发进度不统一,无法灵活的集成上线。
  • 拆分时,把复杂的UI交互算在故事卡片中。大部分情况下,比较fancy的UI交互都不是核心的业务功能,这部分功能可以作为用户体验优化的卡片,独立拆出来。
  • 拆分时,过早考虑性能问题。在性能基本达标、不出现大问题的情况下,提升性能很多情况下也属于用户体验的一部分,可以单独拆出来,左右优化卡片。
  • 拆出一些管理类的卡片。比如管理产品,实际上可能包含很多产品相关的操作,如导入、编辑、同步信息、改变状态、上架、下架等,所以应该根据具体的功能,拆分成更为准确和大小合适的故事卡片。

欧阳修在《卖油翁》中,提到一个老翁,在倒油时能通过铜钱中心的方孔,却不洒一滴油,大家都很惊叹,他只说了一句话——“无他,但手熟尔”。需求拆分也一样,并没有什么高深的学问,拆的次数多了,也便有了那份手熟。


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

Share

PM是大傻叉吗?

一些背景故事

坊间流传着很多关于PM(Project Manager,项目经理)的笑话,在这些不无刻薄的笑话中,PM往往被描述成一个盲目应承客户,不了解实际情况而又喜欢指手画脚、专门坑开发的家伙。毋庸置疑,这些笑话当然出自那些“聪明的”开发(不过你得承认,这些笑话并非空穴来风)。

在智力工作中,对于开发的实际进度、开发速率等问题,具体着手做的人永远比在背后指手画脚的人更有发言权。软件开发正是一项智力活动,优秀的软件无法通过人力的堆积而产生。一个关于PM的经典的讽刺是:PM就是那些指望着9个女人在1个月内生出1个小孩的二货。乍看上去,这个笑话还真是一针见血。

pm-and-dev

我记得在刚加入ThoughtWorks的时候,私底下经常听到这种论调:PM基本就是项目上被人鄙视的角色,基本上负责团队建设去哪儿这种杂事儿就行了,团队的其他人员可以高度自治,并不需要被管理,项目就会如预期般按时交付。

这些论调在某些情况下可能是对的。但是如果放在国内项目的这个上下文里,倘若没有一个专业的PM来协助项目、控制需求、划定项目范围、与客户谈判等等,没有任何一个项目是可以真正成功交付的,指望高度自治的开发们来完成项目?咱们还是现实一些吧。

一个悲剧的事实是,开发人员往往都恃才傲物,有时还会带着一幅要拯救世界的心态做项目,这事实上和客户以及PM的期望是有很大出入的。在项目启动之初,PM会面临重重困难:首先,团队里的每个人都不好管,而且每个人都认为自己不需要被管理(当然这种想法在大多都是错误的);其次,PM需要和客户快速建立信任,并推动项目进入正轨;最后,他们也需要了解大量与项目相关的上下文(业务上下文,人员关系,资源协调等),最后留给自己的时间也非常有限。

除了催进度,PM平时还干点啥?

本质上来说,PM其实就是一个轮询器:识别所有的项目风险,然后不断跟进。项目风险可能是技术风险,比如某个技术上压根搞不定的问题。也可能资源风险,比如人手不够,或者开发者很多,但是没有足够的设计师协助,这些风险都会导致项目无法按时交付。一个客观事实是,所有项目都会变化,从售前到需求分析结束,项目的需求都在持续变化,如果不对报价做相应的调整,极有可能会亏本。

2-demand

PM的一个重要职责就是在项目之初将项目范围定下来,这个范围的划分非常依赖经验:划得少了团队得天天加班,累得跟狗一样才能保证交付(据我的经验,虽然项目一般不会天天加班,但是总会有一些攻关、打补丁的事儿,最后还是会累成狗),划得多了客户不买单,意思是就这个小功能你要做两个月,绝对不行。PM需要协调这些不一致,还需要和销售、客户等方面不断谈判、写方案、排计划,简而言之,也是累的跟狗一样。在此过程中,还可能被那些天真幼稚的开发坑 — 开发经常会高估自己的开发速度,反正我还没遇到过低估的,你见过吗?

我们每天看到的PM干的最多的事情就是:元芳,那个接口怎么样了?什么时候能做完,有什么blocker?李柯,昨天说的代理的事情怎么样了?小波,高保真什么时候出?何方,我们周三下午要showcase,麻烦你订一下会议室吧……

3-pm-resized

除了写代码,Dev平时还干点啥?

如果脱离PM的角度,做为一个孤傲的开发,时常会觉得“PM为什么老是问我进度?是不是怀疑我的能力?为什么监视我的工作?”相信我,其实他才不想监视你。但是你设想一下:如果你不参与代码编写,每天只是看旁边的哥们写,你如何知道他实际的进度呢?而且众所周知,开发很难准确更新自己的工作进度,而且遇到问题也很少积极主动的报告,通常都会自己埋头尝试解决。那么,轮询显然是一种成本最低,反馈最快的方法。

不主动更新进度是一个大问题,这个得单独说。关于更新进度,典型的场景是:早上站会的时候,开发目光呆滞的盯着某个卡片,努力回忆其中的验收条件以及自己当前的进度,如果恰好脑海中的技术细节和卡片描述在某个点上匹配了,他会迅速的告诉你,目前进展良好,今天上午应该就可以做完。开发在更新进度时,要么盲目乐观,要么就跳进太细节的地方进行讨论,最后的结果就是:跟没更新一样,白白浪费了10分钟。但是别忘了,PM会在15分钟之后再来轮询一次。

PM每周都需要汇总很多数字,比如本迭代完成的点数、剩余的点数、总体进度如何、有没有人准备请假、遇到什么blocker、每个blocker的具体原因、每个风险点的最终日期是何时等等等等。他肯定不能记住这些数字,所以可能一天之内向你询问数次。

PM的其他职责/技能

上边说到的其实只是描述PM的辛苦,而最微妙,最考验PM的是其“察言观色”的技能。这绝对是一个工作经验在10年之内完全无法获得的技能(而且是在国内项目上工作10年)。比如,在showcase的时候,有个客户说,“嗯,挺好,整个流程就是这样的,后续你们的UI是不是还会美化?”如果你遇到这个情况,请问,这个客户是什么意思?

如果你能回答上这个问题(而不是提出问题),那说明你还离PM差十万八千里。成熟的PM会先判断,提出这个问题的人是什么角色,以及他在系统中的话语权如何,还有其他人就此问题的反应如何等,然后找到一个合适的答案。

4-guess

PM另一个绝技是扯皮(不是贬义),开发会花一个下午(我是说10分钟)去跟客户讨论需求的范围吗?或者会为5个人天来讨价还价吗?我想开发大概会说,“尼玛,找其他供应商吧,老子不伺候了。”

一个项目的成功,需要多方合作,这里说的合作并不局限在甲方和乙方之间,即使在乙方的团队之中,也需要很紧密的合作。比如项目经理和开发、设计师之间的合作。如果仅仅从开发的角度来看,PM有时候看起来就像和客户站在一起来整开发的一样,比如催进度,过分保守的估算人天(导致团队加班赶工)。PM需要释放团队中的负面情绪,保证团队士气,还需要做一些开发不屑于做的琐碎事情。

设身处地,替他人着想

从本质来说,每个项目都是一次生意。在去掉那些繁杂的流程和形式之后,做一个项目和你去菜市场买菜其实并无二致。根据传统,软件开发界特别喜欢找建筑行业做类比,我也找个建筑方面例子。装修房子的时候,我们会要求施工方提供图纸(水电改造,基本设计等),按期交付(确定工期),同时会界定项目范围(比如刷墙,贴地砖,吊顶,封阳台等等),会要求工人按时来上班,正常出勤,认真工作,直到项目结束。过程中我们还会讨价还价,比如捎带着把栏杆拆除,捎带着敲掉一面隔离墙等等。在过程中,我们还会敲敲地砖,检查过门石,检查吊顶,测试水电等等。作为甲方,这些活动相信没有人会觉得过分。

5-building

但是一旦我们做乙方,也就是施工方的时候,情况就全变了。比如客户要求打卡,有人会觉得不爽,客户要求代码review,有人会觉得不爽,要求代码有设计文档,有人会觉得不爽,要求设计有多个备选方案,有人会觉得不爽。大多数情况下,这都是虚无缥缈的虚荣在作祟,这种情况在所难免,不过还不致命。一旦涉及到讨价还价(不是商务上的讨价还价,而是和客户就工作量达不成一致,或者就某个技术方案达不成一致之后),开发全部歇菜,一言不合,转身就走,压根不具备讨价换件的能力,这样还怎么做生意啊?设身处地想一下,如果你是甲方,当提出了一些合理的要求(比如需要一方提供验收标准,通过验收测试等),结果施工方还一脸的“我不跟你说了,你就是以大傻B”,你能乐意吗?

如何合作?

说了这么多,这两种角色在同一个项目上要如何合作呢?我想,作为开发来说,有这样几点可能:

首先,理解PM的工作。在很多时候,开发会有莫名其妙的优越感(其实每个角色都会有,比如销售看不上技术人员,技术Lead看不上PM等等),主要原因是坐井观天,对其他角色的辛苦和工作内容不清楚,错误的认为别人的工作都很low。

之前听一个同事讲过一个小session,里面有一点我印象非常深刻:不要因为一个人不会某个技术而鄙视他。就好比你不应该因为不会弹钢琴,而被一个会弹钢琴的人鄙视一样。道理很简单,但是开发在长期的“宅”生涯或者坐井观天中,进化出了这种非理性的观点:如果一个人连vim(此处的vim可以换成任何其他技术)都不会,就压根不足以谈人生。

其次,学习如何报告进度。PM催你的根本原因是进度不明确,如果每一个潜在的风险都清楚的显示着进度,而且有明确的负责人,PM就会降低轮询的频率。这需要开发经过刻苦的练习才能达到:

  • 站会前自己花3分钟整理一下昨天做的工作
  • 根据story的验收条件(最好有和BA/QA一起的讨论需求),进行合理的任务划分(tasking技能)
  • 可以借助便签纸等工具,帮助自己明确进度(划分了5个子任务,昨天完成了3个,那么可以粗略的估计为60%)

再次,合理估算。有些时候,新人(来自于传统管理环境的新人)可能会误以为PM是一个管理的角色,或者处于某些考虑会在PM询问进度时做出一些错误的回答。比如PM在迭代启动会议上是问“这个迭代我们有没有可能做完所有计划内的任务?”作为一个负责任的开发,你需要在第一时间指出那些“非理性”的期望,以便PM进行更加准确的计划。

6-tasking-resized

  • 明确告诉PM,有哪些需求是不可能按时交付的,PM会根据实际情况来重新定计划,并和客户确认
  • 明确告诉PM一些可能的风险,团队整体对交付负责,而不是PM,或者开发

按照经验,项目从来就不会按照计划进行,在做好一个粗略的计划之后,PM的职责更多的是进行动态调整。所以团队内部至少需要保持信息的流通,虽然可能短期来看可能会影响开发速度,但是从整体上来看,可以减少很多不必要的浪费。

简而言之,要站在别人的角度考虑问题:如果换做是你,你会怎么做?

Share