服务蓝图再思考

服务蓝图(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

开发人员的客户思维

都说产品与开发之间的矛盾由来已久。在很多互联网企业,都发生过类似这样的一幕:

工程师日以继夜,终于在约定的时间里交付产品——虽然这在产品经理看来可能还只能算个高保真的原型。产品经理体验了这个原型之后,发现一些与期待不符的地方,提出了改进意见。工程师带着泛起充满自信的笑容,再次进入了封闭的开发阶段。

programmers-and-users

类似这样的过程持续往复下去,开发工程师和产品经理对对方的耐心都会受到挑战:

产品:新的方案也就是改了一种排列方式,数据都是一样的,再花点时间不就能搞定了么?

开发:你知道上次那个推荐算法,我花了多久才做出来的么?你说改就改?

产品:可我已经跟老板回复了,说咱们三天就能搞定!

开发:……

在互联网企业里,开发人员作为产品的直接生产者,地位受到优待;工程师作为“创客”所具有的自豪感及自信心也理所应当。直到随着项目的持续,业务越来越复杂,工程师终于不能在期待的时间里顺利交付功能,即使加班加点已在不知不觉中成为习惯。

开发人员与客户思维

在大量的团队里,大家表面看似春意盎然、合作愉快,实际却危机四伏。问题的原因可能很复杂,而从开发人员的角度来说,一个很重要的因素在于开发人员普遍缺乏客户思维。

2-mind

这样的开发人员也能交付能够工作的产品,但从产品设计人员的角度来说,要么他们交付的产品在细节上与需求有较大出入(或多或少,或错),要么就是花费了大量时间,却没人知道他们在做什么,也无法估计一项需求到底需要多久才能开发完成。

开发人员大多有相似的特性,他们擅长解决问题,却不擅长与人沟通。甚至一些人还有“技术至上”的自负心理,认为测试人员和业务分析师等其他角色可有可无。这或许与他们理工科的成长背景有一定的关系。“因为、所以、得证” 这是数学里常见的论证步骤,理工科的同学们擅长运用已有命题推理出一个个新的命题,这一特点在软件开发人员这里有着很好的体现。那些曾在算法练习中用过的代码片断就像一段段积木,当产品设计人员提出一个想法,开发人员就心生一计:这事儿没问题!似乎,接下来就缺时间了。

3-need-more-time

事实却不会那么简单。一个需求的提出,必然有其商业上的考量,其所在的业务场景、适用的范围和限制,以及要实现的可度量目标。在实现过程中,还需要考虑不同的解决方案,各个方案中可能存在的风险,以及需要投入的成本。在团队中,只有所有人都对业务有一致的理解,所有的努力都朝着一致的方向,才有可能获得成功。

有客户思维的开发人员,能够把工作当作为客户提供服务:自己是服务提供方,而同事、老板就是客户。他们积极地从客户角度思考需求的真正来源,在开发过程中与客户保持沟通,适时给出合理的建议。最终在更高效完成工作的同时,建立更顺畅的协作机制,培养出更健康友好的团队关系。客户思维也能够培养开发人员转变视角的习惯和能力,令其习惯于分析价值并作出决策,既而为职业和事业的发展带来更多可能。

思考并沟通

当接到一个新的需求,无论是初次提及,还是后续反馈,首先要思考的是为什么会有这个需求产生,它解决了什么问题、提供了什么价值。虽然开发人员很聪明,却很容易忽略这样一个其实很简单的部分。大部分开发人员的思维方式真的就如同数学证明那样,习惯于接受指令并醉心于实现一些看起来很酷的功能。

4-cool

然而,如果一开始不弄清楚需求的前因后果,就会出现在做了一半、甚至完成了之后,才发现最终得到了一个与设计人员的期待并不符合的产品。其他情况,由于开发团队内部理解不一致导致接口不兼容、由于前期没有沟通清楚而导致返工浪费等情况更是数不胜数。

举一个实际发生过的例子。

作为一个基于浏览器来管理的电商网站运营方,产品经理希望管理员能够在浏览器中即时收到网站用户下的新订单,而不再需要隔一段时间去刷新浏览器,以便做好发货准备。

在拿到这样的需求之后,工程师很兴奋。他开始着手研究服务器推送的各种技术,并深陷其中不可自拔,学习了长轮循、WebSocket等技术。三天过去了,他终于成功地完成了相关开发工作,急切地找产品经理要演示其进展。可没想到,产品经理却并不买账,没等工程师演示,就黑着脸向他回复,“这三天里,我两次向你询问进展,你都说‘快了’。可我一直没见什么动静。后来,我已经请旁边的阿哲搞定了,他只花了一小时!”

5-what

工程师转向阿哲,却发现阿哲用了一个每隔5秒向服务器再取一次数据的“笨方法”。工程师感到委屈不已,向产品经理解释自己的方案比阿哲的方案更有效率,也更先进……

在这个例子里,工程师自认为的高效和先进似乎并不是产品经理所关心的。产品经理作为功能设计者,自然更关心其功能价值,而不是技术方法是否先进。另外,对需求里的“即时收到新订单消息”里“即时”的理解,工程师一开始就将自己的臆测加了进去。

不妨考虑一下,需求的价值是使管理员更早知道新订单到来,但这个“即时性”要求有多高呢?显然没有达到秒级,大概,分钟级也是能接受的——毕竟之前管理员是手动刷新浏览器去完成这个需求的,这说明新订单并没有频繁到需要秒级通知。因此,不管是工程师提前想到了这个结论,还是与产品经理及时沟通了自己的技术方案计划,都可以提早防止浪费。

6-work-place

在工作中,如果只将产品经理视为规则制定者,将领导视为发号施令的老板,我们便会失去思考的机会。逐渐地,思考的能力也将失去。但如果将他们视为客户,那么就更容易理解客户与我们之间可能存在的误解,毕竟大家术业有专攻。这时,不少人便会考虑客户可能的隐藏的想法,耐心地沟通核对,态度也端正友好。

灵活地给出建议

对于一家IT公司来说,开发人员是当之无愧的宝贝,各企业为了招来优秀的工程师,都不惜重金。他们是那么的天才,似乎什么问题到了他们那儿都有解决方案。是的,其实一个用技术能够解决的问题,往往都有很多种解决方案,有些方案甚至不涉及技术。在拥有天才一面的同时,开发人员也相当的耿直,有时候甚至过于耿直,过早地将精力集中到技术方案上,而这时的方案往往还只是开发人员一厢情愿的期盼,不一定是客观上合适的方案。令人不安的是,与这些技术人员合作的业务分析人员和管理人员却没有办法预测或是验证其中的风险。

7-work

在手机支付的概念在技术圈风声水起时,有人正对“刷手机乘公交”的想法感到兴奋,在一边走一边与朋友分享的时候,正好有公交车到站。只见朋友伸出手机在刷卡机边轻轻一滑,“嘀”的一声,刷卡成功!他好奇地问朋友,你是怎么做到的?朋友淡定地翻开手机盖,从中缓缓抽出一张公交卡。

虽然这只是一个笑话,但现实中类似的情形却在真实的发生着,就像上一节中提到的例子一样。 如果开发人员拥有客户思维,就应该在真正行动之前,考虑多个可能的方案、权衡其中的优劣,及时向客户阐明这些方案的利弊;根据对需求的理解,以及客户提供的更多信息,给出具有可操作性的建议。对于一些经验丰富的开发人员来说,给出有价值的建议早就成为了他们的工作习惯,这也正是能体现他们更具专业性的行为之一。

不过,对于老油条们来说,也需要警惕:请注意保持对客户的尊重。作为客户,他们有时候显得不太专业,甚至不太友好。但开发人员,请一定尊重自己的客户。客户的最终目的是解决问题,而解决方案不一定要花哨炫酷,或是技术先进——开发人员应该在合适的时机,让客户知道他们可以做出选择,而不是由开发人员自行决定。即使开发人员自己有什么偏好,也不应该直接或间接地强加于客户,那样只会画蛇添足、招致反感。

《软技能》一书中指出了一个事实,虽然听起来有点残酷:当我们为了谋生而一头扎进代码的世界里时,其实与小时候老家镇上铁匠铺里的铁匠并没有什么区别。那样的我们,不用考虑顾客为何需要打造一件那么奇形怪状的铁器;在顾客一而再地提出挑剔意见时,我们一开始争辩,后来丧气,最后麻木了。那样的我们,数十年如一日,作为铁匠的技艺愈加纯熟。直到有一天,一种叫做“铸造机床”的远在天边的东西,夺去了我们的饭碗。

8-mechanic

如果养成了思考的习惯,拥有为客户提供专业服务的能力,随时都能换个地方另起炉灶。实际上,企业的价值正是体现在它为客户解决的问题上。习惯将工作视作服务客户,把自己当作一个企业去思考,也就具有更独立的人格,为今后真正做出良好的商业决策积累经验、奠定基础。 一旦拥有了这样的心态,开发人员也就不会只关注完成手头的工作,还知道要计划接下来的职业发展,关注自己和同事的成长;也不会因为觉得作为开发人员去帮老板实现梦想没有意义而烦燥不安。很快,开发人员这种聪明的人种就会成为有思路、有规划的进步青年。

 

更多精彩洞见,请关注微信公众号:ThoughtWorks

Share