敏捷实践中的利益相关者管理

利益相关者理论诞生于1984年。在认识到不仅投资者可能影响到成功的同时,此理论主张持续沟通更广泛的受众 – 即企业的利益相关者。自那以后,该理论在各行业广为接受,这其中也包括了IT项目的实践者们。它有助于加强客户关系,维持健康的项目环境,以培养更为满意的交付产物。

为了进一步说明,我们将以其在一个专业服务自动化(PSA)项目中的应用举例。该目标组织是一家提供定制化的技术解决方案的全球机构。它拥有超过三千名技术顾问,工作于数百个客户项目;很多项目是分散式团队,其成员可能分布在多个不同的时区。是时的战略是以保持业务可持续发展为目标实现财务的自动化。但问题同时被揭示 – 如何于如此复杂的用户群体中开展企业变革?本文希望就此问题进行解答。

利益相关者在哪?

首先,我们需要知道应该包括哪些人。尽管网络上陈数了很多方法,我们采用了全新的方式,即是将利益相关者理论与敏捷实践相结合,揭示出项目的利害关系人。敏捷方法中的用户头像能够帮助识别潜在的用户以及他们如何与系统进行交互;进而将类似交互或行为的用户进行分组。

系统用户和他们身边的人可以很容易地干预到项目进程。通过绘制业务价值链和沿着它与用户的每次交互的背后关联的人员。遵循这个流程,我们能够同时识别我们的用户Personae与项目利益相关者。

pasted image 0

他们相同吗?

答案可能不是一个简单’不’,但他们为什么又是如何不同于彼此呢?非常流行的利益相关者矩阵建议从兴趣(Interest)和影响(Influence)两方面进行分析。在敏捷项目中,我们可以进一步分析更细致的因素。在我们的示例中,我们认为当用户更频繁地与我们的系统进行交互,以及当他们愈加依赖系统才能完成自己的任务时,他们会表现出对项目成果更强的兴趣。另一方面,每个用户组的人数,和他们与其他各种用户的沟通数量,可以帮助理解影响的层面。然后,将我们在PSA项目中识别出的利益相关者进一步归结如下:

pastedImage_10

有了这样的认识,我们就可以将辨识出的利益相关绘制入矩阵:

pasted image 0 (1)

依优先排序沟通

就像我们在迭代计划时对故事卡进行优先排序一样,为了更好地利用有限的时间和资源,利益相关者相关的活动也要排优先级。幸运的是,在提供以上全面附图的同时,利益相关者矩阵也对沟通方式也提供了指导。

核心成员 Key Player

同时具备高兴趣和高影响力的利益相关者往往与系统的目标用户有所重叠。他们常需要及时和详细的信息共享,因为有很高的几率,他们的兴趣直接来自系统的使用情况。在PSA项目中,各大区的财务和CP团队是这个小组的主要成员。系统提供自动化开票功能于他们的工作内容有很大益助。他们不仅关心系统在出票当日是否可用,而且包括用户路径是否简单易用。

为了确保核心成员对项目的支持和联盟,与他们保持强有力的工作关系甚至邀请他们参与到大多数的开发流程中来显得尤为重要。财务和CP用户被邀请与开发团队紧密合作,参与最初的产品设计,并对新功能于上线部署前提供反馈,以提高产品性能对用户的契合。

随时沟通 Keep Infomred

项目的指导委员会(Steering Committee)的成员 – 如金融赞助商和运营领袖 – 通常归于这一部分。他们可能对项目的日常表现出较低的兴趣,但常具备更改基础假设和用户路径的强大影响力,进而使项目目标转变。

这些利益相关者往往倾向于接收汇总信息,并可以包括了客观和主观观点的讨论。在我们每两周一次的指导会议中,常对里程碑事件的进展和宏观发展方向进行讨论;最终用户的整体体验,也几乎每次都会被谈及。运营领袖往往能对产品地图和区域性功能的优先级平衡提出深入的指导意见。

值得注意的是,此类成员通常比较忙,所以关键是要建立共同的期望并尽力减少惊奇(surprise)。与他们安排会议,提前预约很重要;或者,我们可以申请他们建立代表小组,以提升沟通效率。建议约定定期的代表会议,同时提前对指导内容和升级讨论的级别达成共识。

保持满意 Keep Satisfied

表现出高度兴趣,却有较低影响力的成员,很可能是项目某项功能的受益者。此类型中个人的“声音”可能较弱,难以影响产品设计或优先级。因此要保护他们的利益可能需要一些有着重性的措施。

在我们的案例中,庞大的顾问角色群体属于这一部分。它由3000多名分布在全球6大洲的30多个城市的员工构成。他们各人的角色,资历,文化背景,以及当地商业惯例,都促使他们对系统的功能要求产生成百上千的分支。为了听到需求背后的故事,我们邀请志愿者加入到用户咨询委员会,并精心选拔了可以充分体现上述不同条件的代表团。我们共享虚拟板来收集意见,并在每月开线上会议进一步讨论。这个实践有效地改善了采集和交换广大用户意见,也有助于让用户代表们自由商议功能开发的优先顺序。

该用户咨询委员会也会受邀测试产品原型并提出早期的反馈,他们的建议也经常会被采用到之后的正式版本中。并且,当我们最终推行版本上线时,这些“超级用户”大多为产品在各自办公室推行给予了培训和宣传方面的大力支持。

观察 Monitor

低兴趣和较小影响力的人们常在项目沟通中给予较低优先级。在我们的例子里,这里可能包含了相关职能者,如人力资源和销售用户。他们没有与目标系统的直接交互,而是把关键数据通过系统集成的方式间接影响到我们的系统中的数据完整性。就此,我们也通过被集成系统的维护团队进行间接接触。这样在资源共享的同时也可以将风险降到最小化。

变化的因素

敏捷宣言主张通过及时重新定义产品路线图的方式响应变化。这些个重新定义的过程也常常会导致利益相关者的兴趣和影响力水平的转变,所以我们的沟通策略也应该进行相应的调整。

pasted image 0 (2)

在我们的PSA产品推出几个月后,CP角色对发票的制作产生障碍,进而从该用户组中被剥离出来。由于他们新的用户旅程并不要求他们登录到系统,而可以只通过检查电子邮件数据完成,他们对项目的兴趣也开始大幅下降。作为回应,我们也开始减少与他们的沟通频率。这个调整随后被证明更加有利于设计师和分析师,使他们在之后的工作中可以专注于唯一的核心用户群,大幅提高了改进此用户旅程的效率,由此避免了运营中的实质性业务损失。

结语

为确保敏捷开发项目的顺利进行,利益相关者管理至关重要。他们可以通过用户画像被轻松辨识出来,并不需要额外的努力。通过分析他们的兴趣和影响力,我们可以在不同层次,以他们容易接受的方式进行引导 – 有些需要沟通目标而另一些需要我们帮助解决更细致的问题。正如在敏捷项目中我们经常需要修正的产品地图一样,利益相关者策略也需要考虑到环境变化因素,这样才能持续巩固他们对项目的赞助与合作关系。

Share

孙子兵法的智慧——拯救死亡行军

entersunzi

我们看了太多失败的和即将失败的项目,在软件领域更是如此。每天早上醒来在朋友圈里看到半夜更新的,不是身在国外的朋友,就是在办公室为了项目上线而加班的朋友。

Edward Yourdon为那种项目约束与目标之间相差一倍以上的软件项目专门写了一本书,叫《死亡行军(Death march)》。

我曾经亲眼见证过几个“死亡行军”项目的立项过程。

其中一个项目,那时候我才工作不久,一个项目从无到有,“大领导”希望在21天之后上线,这个日期包含了周六和周日。但是按我们的预估——当然我们也不会盲目乐观到每天只工作8小时,这个项目按现有资源起码需要3个月到4个月。在产品立项过程中,“大领导”坚决不肯让步,时间、范围均压得死死的。就这样,我们在会议室里博弈了整整两天,最后的结果是我忧心忡忡地走出会议室,问我身边的同事:你觉得咱们能办到吗?同事的表情我至今印象深刻,那是一种释然和轻松——他笑着说:怎么可能嘛。

最后的结果,项目延期了半年。


如何能够让自己的项目稳定运行并得到期望的结果呢,避免死亡行军,打一场胜仗呢?

几千年前的孙子兵法已经给我们提供了思路:

故知胜有五:知可以战与不可以战者胜,识众寡之用者胜,上下同欲者胜,以虞待不虞者胜,将能而君不御者胜。

我们只做高价值的事情

价值驱动作为敏捷开发的两根支柱之一,为软件开发提供了一种全新的思路。在上世纪八十年代之前,软件开发的时候还有这样的等式:功能=价值。
所以奇怪的一幕出现了:软件开发这个行业一边承受着巨大的进度压力,一边在生产着没有人用的功能。

微软曾经发起office 2003用户调查,希望调查用户希望 Office 2007实现哪些新特性,结果收获了让人吃惊的消息。产品总经理 Takeshi Numoto 如是说:“超过90%的特性请求早已存在于 Office 中可供使用”。

更何况对于所有的软件开发组织来讲,资源不足都是常态,识别出来哪些可以不做,我们才知道应该去做什么。

知可以战与不可以战者胜。

通过限制在制品的方式来缩短前置时间

对于缩短产品交付周期,一向是很多客户都会提到的问题,特别是电信级的产品,动辄一年的交付周期。当前市场环境已经变得越来越快,根据波士顿咨询公司的调查,最近的20年已经成为变化最剧烈的20年。

22484-8eb1d728c83ca707

《经典战略工具过时了?BCG矩阵新解》

在这样的市场环境下,“响应速度”就被提到越来越高的位置上,而衡量响应速度最直接的指标就是“前置时间”(lead time)。一个需求从产生到变为现实,究竟可以有多短?

利特尔法则是一个神奇的公式,它简单到甚至可以被10岁的孩子所理解:平均吞吐率=在制品数量/平均前置时间。对于一般的组织来讲,平均吞吐率约等于团队的产能,把它视作常量的话,我们想得到更短的平均前置时间,就需要控制在制品数量,小批量地快速流动。

要么不做,要么快完。

识众寡之用者胜。

团队所有人目标一致

“我们所处的项目,目标是什么?”有没有保证项目有着一个清晰而具体的目标?有没有保证所有成员都能够理解并执行?

在客户现场的时候,我经常听到的问题是:“作为一个管理者,我如何能够准确看到员工的人员利用率?你有没有办法让团队里所有的人都忙起来?”每听到一次这个问题,我在心里就会默念:“你可以让闲着的人都出去跑圈啊,这样大家都忙起来了。”

软件开发的项目,绝大多数(保守了,其实可以说“所有”)的目标都不是“所有人都忙起来”,而是“快速交付价值”。也就是说我们做任何的努力,都是为了能够让需求尽快上线。

而敏捷开发中的各种可视化手段,包括故事墙、故事地图,都起到了这样的作用——目标可视化。特别是树立在团队中间的物理看板,我们真正的目标都清晰地挂在上面,所有人的工作和努力,都是在推动着一张张卡片从板子的左边挪向右边,如果你做的事情对于推动卡片没有起到直接或者间接的作用,那就要好好思考一下了:我们的目标究竟是什么?

至于说人员利用率——谁知道一个正在端着咖啡面对窗外发呆的知识工作者(译作Thought Worker)是不是在为接下来消灭更多卡片而在布局呢?

上下同欲者胜。

做好风险管理

在客户现场待了一年,看的项目虽然不多,但也发现了一些共通的问题,其中最大的一个就是风险管理。

有不少项目在前期根本就没有做风险识别,或者识别的风险缺乏跟踪,到项目执行中仍然会像放炮仗一样一个接一个的爆炸。其实风险管理作为PMBOK九大知识领域之一,管理和应对手段都很成熟了。

应对的思路就有“转移、接受、缓解、消除”四种,而我看到的情况通常都以“接受”为应对手段,赌这个风险不会发生,或者等一个Risk变成了Issue再去想应对方案。

风险识别不论是在需求优先级排序还是在架构设计上都是非常重要的一环,我们之所以把高价值、高风险的需求视作第一优先级,是因为我们希望尽早识别风险,尽早释放风险。我们提的“简单设计”简单到什么程度,也是由是否能够涵盖最大的风险作为边界的。

以虞待不虞者胜。

团队应当自组织,领导者应当负起管理者的责任

客户现场另外经常被提及的问题就是:“如何打造自组织团队?”“团队自组织了,我们经理怎么办?”

我的答案通常是:团队自组织应当是一个逐步打造的过程,而领导者更应该负起管理者的责任。《管理3.0》中提到,授权有七个级别:从不信任到信任,或者说团队成熟度从低到高分别是:告知→贩卖→咨询→商定→建议→征询→委托。

作为管理者,打造自组织团队的过程也是逐步团队赋能的过程,团队成熟度不高而采取放任的做法,对于自组织的打造百害而无一利,反之亦然。所以作为管理者,最重要的责任就是在对团队赋能,当上面的四条团队都掌握了玩法,管理者就可以采取更高层次的授权了。

而所谓自由,就是团队的事务管理者不要管,团队外的事务管理者尽量多去做。区分管理者水平高低的点就在于如何判断一件事属于团队“内”还是“外”。

将能而君不御者胜。

我们总结一下

故知胜有五:知可以战与不可以战者胜,识众寡之用者胜,上下同欲者胜,以虞待不虞者胜,将能而君不御者胜。

 

Share

我怎么看敏捷

去年11月份的时候,我进到了ThoughWorks实习,开始了我的TW生涯,从现在除去今年年初由于毕业论文断断续续的10天左右的请假,我已经到ThoughtWorks1年了,现在我想来我聊聊我眼中的敏捷和我对敏捷的看法。它是比较主观的看法。
首先,我必须得说敏捷并不是完美无缺的,当然也不是所有行业,所有软件项目都适合使用敏捷来开发和管理的。很明显的一个例子就是,你不能用敏捷来开发NASA的航天飞机的软件系统。从敏捷的理念我们会说,我们让开发航天飞机的起飞系统,然后交付给NASA使用,之后再继续交付降落等其他系统,显示这是行不通的,航天飞机不能在仅仅拥有起飞功能的时候就上天啊。敏捷里强调快速交付,快速响应,及时修复bug,因此我们会允许软件存在潜在少量bug的时候让其上线,使用。这在航天飞行系统里面也是行不通的,因为涉及到人的生命,航天飞行系统应该是不允许任何bug的。

但我依然会说,敏捷是一种很好的理念和实践,适合大部分IT企业使用,特别是互联网企业和运行互联网产品的企业使用。

在现在互联网时代,天下武功唯快不破。采用敏捷的实践,初期开发MVP(Minimal Valuable Product)产品,快速上线,根据用户的反馈不断更新、改进自己的产品,开发新的功能,这样周而复始,产品把用户最喜欢,优先级最高的功能永远都放在第一时间开发、上线。根据用户的反馈、统计数据的结果不断调整产品的策略,这样才能立于当今互联网。在我们身边也许Github、 Flickr等都是很好的成功例子。
下面是我对于一些是非的意见:

  • 结对编程能够明显提升代码的质量,让团队成员对代码的熟悉度大幅提升,但是我不赞成至始至终都是结对编程,应该留时间进行单独编程,这样虽然代码质量也许会有一些下降,但是如果伴以TDD对进行辅佐,是不会下降太多,单独编程有助于让dev独立思考,发挥创造力,很多时候会达到意想不到的结果。另外一点结果编程通常达不到两个dev独立编写代码的效率,就像在《人月神话》中讲到的那样,1一个人如果需要开发一个软件需要100填,那么10个程序员10天肯定不能完成任务的,因为期间还需要算上沟通的成本。
  • 关于TDD,确有遇到过几次绞尽脑汁也没想明白怎么测试的case。但是我们如果使用 隔离依赖(即mock依赖,stub行为,如使用mockito中的:given().willReturn();或者when().thenReturn()等)的原则来编写测试,绝大多数情况都会变得豁然开朗,就Java而言,遇到静态方法,我们可以通过间接的调用去测试,对于无返回值的方法(void)我们可以采用验证行为的方法去测试(如使用mockito中的verify()函数)。使用TDD的好处是不言而喻的,用测试代码描述你的需求,表达你想要的结果,既保证了质量也不用担心会做出多余的功能。不过在开发自己的小点子、小创意时,我通常选择Rails和Node.js进行开发因此TDD做得并不好,通产只是选择性的对重要的部分进行测试保证。
  • 沟通胜于一切,跟项目中所有的人频繁沟通,在实际项目中有一次是这样的,对于story中一个对于生效时间信息的描述有些模糊,我没有多想久自己认为肯定的全局的生效时间,但是不曾想到,当多个子产品出现时,就不能依赖全局生效时间,因为全局生效时间是其中最大第一个,而不一定是当前所需准确的生效时间,因此这个sotry在最后给BA 检查的时候才发现这个bug,试想最初如果我没有随便假设,而是马上给BA发邮件沟通,问清楚生效时间,也不会出现返工的情况。我个人认为良好、高效的沟通甚至比写好代码优先级更高。
  • 站会(stand up)既是一种对团队成员工作的可视化,了解彼此的进度等情况,也是锻炼表达能力、增强自信心的好机会。为何这样讲,因为在站会上每个人需要用几句话来概括自己前一天所做的一切,当你讲到你前一天做的一些进步时,团队为你真心叫好,难道不会让你你增强自信心吗?对于站会进行的方式,有团队会选择每个人依次讲解前一天的工作内容;也有人会选择采用按照故事墙的方式来进行,依次对每个列(analysis, ready for dev, in development, test, sign off等)进行浏览等,当讲到自己的那个story时,每个人需要更新自己前一天在这个story上的工作,这样的好处是可以对每个story的情况进行可视化。但是我个人更喜欢前者,这样更加自由,但是目前在工作中基本尝试的都是后者。
  • 另外一点是尽早集成,这点感触很深,大三的时候在一家公司实习,当时做一个原型系统,两三个人做一个模块,到最后快要演示的时候,才把几个模块尝试连到一起做集成测试。结果就是,所有人坐在一起进行的进行各种接口的连接、调用,bug修补。一旦连接成功就兴奋到难以言表,仿佛很长一段时间的工作都没有这一下来得兴奋。系统可以集成后,一直都提心吊胆,担心其中某个东西会不会莫名挂掉,因为集成测试都是使用人肉测试的啊。在展示的时候,各种紧张,安排专人时时刻刻注意到服务器。在敏捷中,我们要求及早进行系统集成和和创建部署环境的脚本,每次CI的运行都是一次集成测试,都是一次服务器的部署。因此不用担心在realse的时候不能部署的情况。不过有一件事情是需要注意的,那就是数据库的迁移,在开发机器,测试服务器你还能每次部署的时候都干掉之前的数据库,重新创建,但是在部署到产品服务器的时候就需要小心了,在Java中我们可以用Flyway 达到类似Rails中的 rake db migrate的效果。

另外,我认为 switch pair(变还你结对同事)、 code review(团队成员坐到一起对团队前一天提交的代码进行浏览、解读),这些都可以让整个团队共享更多的上下文,还可以检查出不到的代码,学习好的代码。
也许明年这个时候我对敏捷的看法又有不少新的见解,到时候再来分享。

Share

我和敏捷团队的五个约定

我——作为一名测试人员——有一个与众不同的习惯:每当要加入一个新项目的时候,我总会找到项目中的同伴,真诚而亲切地说:“为了更好地合作,我有5个约定,希望大家能尽量遵守”。

约定1. 业务分析师们,我们其实是同一个角色的两种面孔,请叫上我们参加客户需求会议

我们的团队需要让客户频繁的得到可用的软件,客户的不断反馈会给软件的未来做出最正确的方向指引。

如果我们交付的软件有很多质量的问题,存在大量的缺陷,客户会被这些缺陷的奇怪行为干扰,没有办法把注意力放在软件本身的价值是否符合他们的真正需求上, 不能给出最有价值的反馈。所以,我们只有频繁的做测试,在每次交付之前都把质量问题找出来告诉我们的团队,问题才能及时的得到改正。

而我坚信“prevention is better than cure”(预防胜于治疗),我会要把工作的重点放在预防缺陷上,这样可以节省Dev们很多修复缺陷的时间与精力。

为了达到这个目的,我需要跟你一起参加客户需求会议,尽早的了解客户需求与使用软件的惯常行为。那么在你完成需求的验收条件的定义的时候,我也基本完成了测试用例的准备。

我们可以赶在开发人员们写代码之前就告诉他们我要测什么,让他们减少因为过于乐观而漏掉的一些重要的有破坏性的情况,减少缺陷的发生。这是我测试的一项重要任务。

如果你们在大部分需求都整理好了再交给我们,我会浪费掉等待的时间。更重要的是,开发好的软件里面已经有很多本来可以不存在的缺陷在里面了,开发人员们可能需要加班加点来保证在项目最终交付时间之前把它们改好。这样很容易产生新的缺陷的。

所以,请让我尽早了解需求,请不要让我到项目后期才能开始测试。

约定2. 开发人员们,虽然你们是编写自动化测试的专家,但请听听我们意见

我知道,对于你们,自动化测试不过是利用junit, rspec, selenium,watir,uiautomation等等写出的“另一段程序”而已。而对于80%的QA来说,编写自动化测试并不是一件简单的事情。

不过我仍然相信,有测试人员介入的自动化测试更有价值。

你们用单元测试,集成测试来保证代码的质量。然而你们的这些日常测试离代码更近,离最终用户还点远。很多测试都不是在测软件功能。

你们可以把功能测试写的又快又多,而我们可以指出什么功能测试最有必要加到自动化测试中。

你们平时大部分精力都在编码上,没有太多时间去查都有什么缺陷。而我们可以指出什么地方缺陷可能会出现的比较频繁,建议在这些脆弱的地方加自动化测试。

所以请听听我们的意见,我们可以给你们提供这些信息。

约定3. 项目经理们,请不要要求我们测试软件的所有路径

软件测试是一个永无止尽的任务。基本上没有什么软件简单到我们能够尝试完它的每一个可能的路径的。就连一个看似简单的微软计算器都有无穷尽的路径,无止尽的输入,更何况比这个更复杂的商用软件。

如果你们担心没有尝试过全部的路径不可靠,疑惑我们怎么敢说这个软件质量是好的还是坏,都有什么风险。请你们先注意,我们是跟业务分析师一样,都了解软件的价值的。价值可以帮我们做出判断,什么时候可以停止测试并对客户说我们的软件已经满足您的要求了,请放心使用。

因为我们了解价值,我们可以肯定的说哪些软件的使用方式是至关重要的,哪些是不太可能出现的。我们会在全面测试了软件以后,把主要精力放在价值高的功能点上。合理的利用项目有限的时间。

因为我们了解价值,我们可以正确的把发现的问题分类。我们可以帮助dev们把精力放在重要的缺陷上,避免把时间放在对于客户微不足道却不得不花费大量精力才能修正的问题上。

所以,请不要要求我们无止尽的测试一个软件。我们了解价值,请相信我们的判断。

约定4. 迭代经理们,如果对于交付风险有任何疑问,请来询问我

BA和Dev们都是关注一个软件在什么情况是可以良好的工作。而我们除了验证这些情况以外,大量的时候都用在寻找什么样的情况软件不能正常的运行。所以除 了针对定义好的软件行为进行测试,我们还会做很多探索性测试。我们通常可以通过这样的测试发现一些没有定义的、不曾预期的行为。这些行为往往将会构成软件 交付的风险。

我们会告诉你们现在都发生了什么问题,分别分布在哪里。

我们会告诉你们,在什么情况下软件可能会有异常行为,是不是会牵连到其他的部分,是否可以绕过去。

我们会告诉你们,哪些部分功能比较不稳定,需要更多的留意。

约定5. 测试人员们,那些敏捷实践对于我们也是有用的。

结对不是dev们的专利。我不希望总见到你们独自坐在自己的位置上冥思苦想。走出去,跟其他队友多多交流!

多跟测试队友交流,pair看看设计的测试用例是不是够全面,独自一个人想到的未必足够好。他们会给你诚恳的意见的。对他们,也请一样认真对待。

如果你发现开发人员们做出的架构决定使测试工作变得更困难。那么请大声地告诉他们,design for testability(提高你们设计的可测性)。

如果你发现业务分析师写的需求无法验证,定义的客户行为不够具体,一个用户故事中包含太多了功能点,等等,那么也请大声地告诉他,INVEST(独立,可协商,价值,可估算,短小,可测)。

也请你们多跟开发人员结对写自动化测试,既可以帮助你们学习怎样更好的编写自动化测试,也能帮助开发人员们结对更多的了解用户行为。

这就是我的五个约定,它们是我在团队中顺利展开工作的基础。


作者:覃其慧,ThoughtWorks敏捷咨询师。她参与了大量的敏捷软件开发的实践和敏捷咨询。目前主要关注以价值为驱动的敏捷测试。


本文原文发表于InfoQ:http://www.infoq.com/cn/articles/thoughtworks-practice-parti

Share