Skip to main content

一名ThoughtWorks咨询师的心路历程

还记得2015年初我在红螺寺许下的新年愿望:事业顺利、家庭和睦。验收标准分别是:

  • 事业顺利:我能够加入ThoughtWorks
  • 家庭和睦:“造人”计划顺利进行

如今,我已加入ThoughtWorks一年半,宝贝女儿澄澄已经七个月大。

PS:笔者每年都会去红螺寺还愿、许愿。

缘起

在加入ThoughtWorks前,笔者在互联网企业里做内部教练,同部门的同事们中有几位是ex-ThoughtWorker,他们和周围的同事实在太不一样,他们太优秀、太任性、太奇葩…跟他们的合作颠覆了我对于软件开发的认知以及整体的思维习惯。

被颠覆的我之后也加入了ThoughtWorks,加入了咨询团队。还记得刚进公司时,每当我碰到一个HR,都会得到善意的提醒,“这里的人都是奇葩,你要做好准备”,当时我心想,“老子都已经跟奇葩们一起工作3年了,还有什么可准备的,老子也是奇葩…”。

后来我被事实打脸,事实告诉我,由于企业文化和团队环境的不同,我遇见的ex-ThoughtWorker们还是压抑住了自己的天性,而在ThoughtWorks的文化下、在咨询团队中,你会获得最大程度的自由。同时由于你做的是咨询工作,在多重压力下,你的能力会得到极速的提升。这种成长和文化是我之前从未见到过的,我希望可以用我的文章带领读者们走进神秘的ThoughtWorks咨询团队。

PS:这里不得不提一下,2012年ThoughtWorks被评为全球面试最难的IT公司,第二名是Google。(此为科技博客Business Insider撰稿人Julie Bort依据美国雇主评价网站Glassdoor.com提供的数据所评)。

咨询?

ThoughtWorks是一家服务型的IT公司,交付和咨询是中国区的两项核心业务,分别用一句话介绍两个业务:交付的核心是帮助客户解决问题,而咨询的核心是为客户赋能。

由于工作性质的不同,咨询多以单兵作战或pair为主,交付则以团队协作为主,在ThoughtWorks中国区的近1000人中,咨询团队不到100人,其余的多数是交付团队的同事。

在咨询团队中,分管理、技术两类咨询师。管理咨询以企业战略层面的投资组合管理\创新管理、产品及组织层面的结构治理\需求管理\设计思维、以及团队层面的运作管理框架为主。

技术咨询则以技术架构治理、DevOps、“黑科技”的研究以及技术实践为主。当然这两者并非完全独立,管理和技术实际上会有很多交叉,同时ThoughtWorks也不会约束你的工作范围,笔者是管理咨询师,最近在带领客户做CI Dashboard(当然过程中受到了很多技术教练的帮助)。

入门

初入咨询团队时,新咨询师会有一段适应时期,这期间会有一位老员工来充当你的buddy,buddy的目标是协助你顺利度过6个月的试用期,他主要的职责是帮你融入团队及提高自身专业技能。

之后你可以在内网上阅读并学习相关资料,可以去国内交付项目了解最佳敏捷实践的运作方式,也可以通过shadow老咨询师去了解ThoughtWorks咨询的套路。这个时间大概是3个月左右。ThoughtWorks十分鼓励员工持续学习,甚至可以在工作时间去学习(看书、看视频等),这在我之前的公司是很难看见的。

所以刚加入咨询团队的新咨询师在这3个月左右的时间里需要抓紧时间去学习,去融入团队。

出师

通过3个月左右的持续学习,作为咨询师的你已经可以选择合适的机会出师了。ThoughtWorks咨询的rate很高,客户请你来一定是解决复杂问题的,在他们眼里你是一个上通天文下晓地理的专家,而且客户一般在同一领域只会请一个人(单兵作战)。

所以在去之前,你需要做好充分的思想准备,对于复杂问题的解决,不是固定套路就能搞定的,需要不断的根据客户期望以及现状,调整你的计划甚至目标。在整个敏捷转型的过程中你一定会遇到很多问题,这些问题多数是需要咨询师独立去解决,但ThoughtWorks是你坚实的后盾,要充分的利用公司内网、咨询群、buddy,快速学习及成长,带领客户一起攻克难题。

在这个过程,思路一定要清晰,首先我们做的是咨询,做的是赋能,不是用自己的专业技能去为客户做事,而是用自己的专业技能辅导客户自己做事,否则你的影响面以及精力都会受到很大的限制。

其次,一定要充分的自信,公司内网中有无数的案例和资料,咨询群中有一百多名咨询师为你答疑,还有一个与你亲密无间的buddy,没有什么问题是解决不了的。记得当初我上第一个项目,前两周每天晚上都会给buddy去电话,请他为我“指刀”,buddy从未感到厌烦。

出师项目我定位的目标是“生存”,能“生存”的前提是让客户满意。当然了,客户投诉的情况也不少,每个客户的习惯不同,咨询团队对待投诉的态度更多的是反思、总结、提升,ThoughtWorks没有KPI,不会因为你的投诉多了,工资就没了,公司更看重的是你的成长以及客户的满意。

沉淀

在ThoughtWorks咨询团队,每名咨询师的风格/套路都不同,“拍砖型”、“儒雅型”、“教授型”等等风格都可以在这里找到。我们需要去总结并定位出自己的套路及特点(擅长的领域)。还记得我刚进咨询团队时,Team leader给我的第一封邮件是一份书单,外加希望我之后能总结出自己的套路及特点。

套路不是做一两个项目就能有的,也不是可以从别的咨询师那里直接“抄”来的,而是在你做了大量项目,收集了大量老咨询师的经验及反馈后,从中总结提炼出来的最适合自己的套路。而特点取决于你的兴趣与经验,找到自己感兴趣的领域深入下去,形成自己的知识体系。

这个过程我认为有三点最重要:不断总结、刻意练习、主动学习。

不断总结

套路源于总结,在不断总结的过程中清晰自己习惯的套路。在咨询过程中给客户的方案和汇报是少不了的,虽然说很多资料可以通用,但在还没形成自己完整的套路时,我一直坚持原创。这些内容从哪来?从每个活动的总结甚至每天的总结中去汇总,这种频繁的总结对我们的知识积累以及对提升客户体验都是有很大好处的。当然,你也可以先让客户总结,再自己总结。这里手段会有很多,关键点在于是否去做。

刻意练习

刚做咨询时,我们并不是“八面玲珑”,都是有明显的技能短板,例如沟通\演讲能力、危机处理能力、某些敏捷专业能力等等,这些短板如果我们知晓,我们会在客户现场刻意避免,但如果我们不知晓,让客户发现,会直接影响到客户的信任以及咨询的效果。发现短板的方式一般是自己总结以及向周围的同事要feedback,重点是提升自己的短板,方式就是刻意练习,持续集成中有一句话让我印象深刻,“如果做一件事让你觉得痛苦,那么就要更频繁的去做这件事”。

刻意练习就是这样,你需要频繁的去练习你的短板技能,当然这个练习多数是在你非客户现场的时候,你需要抓住时机甚至创造时机去不断练习。但不得不说这一点很难,人的天性并不是这样的:P

主动学习

在咨询团队中有很多的内部活动,大家平常在不同项目中,难以相见,就会抽出晚上或周末的时间进行内部碰撞,例如读书会、实践集、以及各项专题的研讨等等,这些都是完全开放的,自由报名,都是很好的学习平台,相信只有高手过招才会擦出别样的火花,而在这些活动中,我们是真的在“过招”(拍砖),所以大家都在飞速成长,这种活动并不是所有公司都有的,而这个机会,你一定要把握住。

简单总结下,这个阶段我认为的目标是总结并定位自己的套路及特点(当然它不是一成不变的,是个持续改进的过程)。

当你有了自己的套路及特点后,你需要励志做出自己的“金牌案例”,以提升影响力及帮助新人。下面说一下咨询团队的特点及挑战。

团队的特点

自由

咨询团队中的大师(吴雪峰)曾说过“牛人是不需要管理的”,我十分认同这句话。在咨询团队中你所受到的约束很小,这里没有强制的职责划分,以你的兴趣导向为主。没有强制的命令安排,会尊重的你的建议。没有KPI的约束,大胆去做你认为正确的事情,等等。

互相伤害&互相关爱

互相伤害:咨询团队的咨询师在客户现场常常大杀四方,在团队内部也免不了带着这种杀气,这让团队内部的很多活动都“刀光剑影”,就像前文中所提到的,高手过招才会出现别样的火花,团队中很多创新的点子或创意都是在这样的环境下产生的。

互相关爱:咨询团队又是一支极度团结的团队,我们都是一群怀揣相同梦想的“奇葩”,当某一个咨询师遇到困难(各个方面),在咨询群中、电话中、邮件中都可以寻求到别的咨询师的帮助,而大家都毫无保留。

面临的挑战

学习能力

在客户,团队的多重压力下,你需要具备快速的学习能力,你会快速成长。在客户现场你需要短时间内了解客户业务和背景,永远走在客户的前面。在团队中,大家都在跑步前行,就算摔倒了你也要快速的爬起来,用更快的速度赶上队伍,因为你是ThoughtWorks咨询团队中的一员。

纪律性及健康

在咨询团队中,你会有50%以上的时间在出差。你每天会承受很大的工作压力,如果没有良好的纪律性以及生活规律,你的健康将受到威胁。还记得当初出差到深圳,南北的气候差异让我很不适应,家人给我的评价是,“你一放假回家就在养病,养好了出差,回来又一身病…”之后我每天坚持跑步并保证睡眠,情况才有了好转。所以纪律性的好坏会直接影响你的健康以及你的职业生涯。

总结

最后用团队中部分咨询师的语录作为总结:

道长(伍斌):“高手如林,左右逢缘。”

姚安峰:“进入ThoughtWorks咨询团队是一次幸运的选择,和一群充满理想、激情和务实精神的人同路,思想火花和异见碰撞让人快速成长,1年所学胜过过往6年职场。这里也是极具挑战的地方,全球软件领域最顶尖的人才,最前沿的理念,国内最规模化的客户,以及一年近百次启航。”

宇宙青(刘玉青):“自从加入ThoughtWorks咨询这只‘奇葩’团队,便开始了指数级的野蛮生长。在这里人人怀揣梦想,每天都在身体力行,用心改变世界!”

袁大师(袁英杰):“在ThoughtWorks做咨询师最大的优势就是你可以不断面对新的问题、新的客户、新的产品、新的文化、新的人。这会迫使你不断思考,时刻保持状态。你的经验,视野,能力也随之不断变得广阔。”

Share

业务分析实践:10个常见问题

在敏捷社区里, 下面这10个关于业务分析的问题会经常被人问及。我也一直在思考这些问题,结合过去8年来的敏捷项目上的经验,试着做个简单的解答,希望能给大家以启发。

1.进入到迭代的用户故事,到底拆到多大尺寸为好?

我会尽可能让拆分出来的卡,3天左右能够开发完成(无论是否结对)。比这个尺寸大的卡,因为请假、周末等中断会导致更多的背景重建时间,而且会让开发易产生“疲劳感”;比这个尺寸小的卡,卡片管理的边际成本会比较高。

2.在迭代计划时,是否重新评估并调整用户故事的点数?

我会尽一切可能不去讨论、调整卡的点数,而且会尽可能防止团队这样做。经验告诉我,这完全在浪费时间。当项目进入交付阶段后,只要业务需求范围没有变化,就不应该出现点数变动。

3.临时拆分出的技术任务卡和迭代中发现的缺陷卡,要不要给点数?

不给。同上,只要业务需求范围没有变化,就不应该出现点数变动。

4.不同的卡中,验收标准可以有重复吗?比如我们有按关键字、名称、地址来搜索客户的功能,搜索结果的页面都要分页。现在我们每个卡中都有分页相关的验收标准。

不要有重复。我们知道测试用例讲究“相互独立,完全穷尽”,这同样适用于需求。所有卡片上的验收标准,组合起来应该不多不少刚好等于整个项目的需求范围。好比图A。当有不同卡片的验收标准重复,不完全独立,就像是图B,导致额外的重复成本;当所有卡上的验收标准组合起来,不能覆盖到整个项目的需求范围,就是有需求遗漏,好比图C。

 

图C

 

对于这个问题中的例子,我的做法是把搜索结果的分页显示拆分成一个独立的卡,然后在每一个搜索卡中,加一个标注说,搜索结果需要分页,并关联到这个分页卡。

还有例子的“跨功能性需求”(Cross Functional Requirements)。比如做UI的卡,都需要遵循统一的VI标准,比如用什么样的按钮、什么样的字体、颜色风格等,我一般会创建一个共享页面,来描述这个所有UI卡都要遵循的UI标准,然后在每个UI卡,标注说UI细节请参照共享页上的UI标准。

另外一个典型例子是做API项目。不同的API接口也都需要共同遵循一个技术标准,这个也不用在每个卡上重复去写,也是建一个共享页面来描述这个标准,其他卡来引用这个页面。

5.迭代计划或迭代汇报时,大家总是对着“点数”斤斤计较,客户希望加几个点,团队希望少做几个点,于是讨论焦点就变成和客户争执某个卡到底应该是2个点还是5个点,怎么办?

首先深表同情 – 但这是一开始犯下的错,估计纠正起来需要花不少精力。我的做法是,从迭代0开始,就引导客户“轻视”点数。做法是:

  • 做计划的时候,要对照着故事墙(或“业务全景图”),来列出迭代要完成的功能目标,强调为什么要完成这些目标,否则对整个交付计划的影响,在最后的10%的垃圾时间,顺带提下计划的点数是多少,想争论点数,啊没时间了!所以shut up。
  • 做汇报的时候,同样,强调完成了什么样的功能目标,有没有里程碑完成,利用故事墙(“业务全景图”)展示整体进度;当前核心的Blocker和Issue是什么,有什么行动来解决,然后再顺带提下原计划多少点数,完成了多少点数。如下图:

X review
总之,引导客户和整个团队,去看到整体需求完成情况,点数信息做参考,而不是围着点数转。

6.在项目快速启动(Inception)时,得到的“RAIDs” (分别代表Risk, Assumptions, Issues, Dependencies),在交付期间到底还有没有用?

大有用处。如目前的项目,我70%的精力其实都是在花在“RAIDs”上。其实在交付过程中,分析常规性需求是相对简单的;给交付带来困难和挑战的往往是这些RAIDs。分析、理解、跟踪、提前采取措施消除其影响,就会有效避免需求蔓延、提前化解“大老虎”危险需求、及时调整好客户期望,避免大的矛盾发生。每一个项目,我会去建立一个共享页面,列出所有的假设、风险、问题和依赖;提前1-2个迭代去分析这个列表:

  • 假设:有哪些假设现在就能确认是对的?有哪些假设是错的?错的假设意味着演变成了一个问题,需要移到问题列表上;迟迟无法验证的假设,请从假设列表移到风险列表。
  • 风险:如果发生了,会影响需求范围吗?有哪些备选方案?需要提前做什么准备?如果已发生,需要转移到问题列表。
  • 问题:所有的问题在创建之前,其实应该已经跟客户沟通过,不应该有意外;跟踪更多是报告状态,追着相关的人完成。
  • 依赖:跟外部接口人做好沟通了吗?最好/最差情况什么时候能解除依赖?

这些都是与需求紧密相关的,不能甩手扔给PM。在每一个迭代汇报或演示时,除了汇报进度,更要汇报RAIDs的最新状态;需要领导注意的高亮出来,经验证明这种场合消除问题会很有效。

7.BA(Business Analyst,也即业务分析师,是敏捷团队中的必要角色,下同)经常需要跟踪依赖和一些待处理的问题,这些需不需要可视化在故事墙/看板上?

要。这些可能会成为阻碍(blocker),我一定都会让它们可视化在墙上,这样客户、团队中的每个人每天可以看到。一块干净的玻璃,如果上面有一块明显的污垢,人天性里都回有擦除它的欲望。放在墙上,是同样道理。只不过这类卡片不应该有点数,或者点数为0。

8.在项目快速启动(Inception)时,我们已经找出了MVP,并确定为第一次发布的需求范围,且交付时间很紧张只有3个月。在交付过程中,有一个客户提出方向可能不对,建议重新发散想法确定需求,要不要这样做?

不要。对于绝大多数组织来说,尤其大型组织,所谓创新难有一个主要因素是“执行乏力”。从产品概念产生到第一个雏形上市,这是一个“快速试错”的过程;越试得快,离“正确”的目标就越近;即使第一次方向针对选错了,完整地收尾才能真正学习到“错误”在哪里。反复犹疑,只能让“不确定”越来越多,越不知道该怎么做。我自己的经验,一旦进入交付,尤其是短期极速交付,就是要尽一切努力帮助客户收敛,收敛,收敛。所以当我们去跟客户沟通需求时,不是真正地让他来告诉我们做什么,怎么做;而是“诱导”他同意按照我们想好的“性价比”最高的方式做。

9.客户提出了一些新需求,我做了足够扎实的分析,排了个优先级,想让客户放弃一些低优先级的需求,可无论我怎么说,客户都说这个优先级都是一样的,必须得做?

先暂时放下这个“事”,下点功夫在“人的需求”上面,挖掘下想客户最真实的个人诉求是什么?《商战往事》有段话我印象非常深刻“项目需求在内外部运作中、竞争中会源源不断地给个人需求提供机会,而个人需求在这个基础上,还包括内外部环境变革中源源不断地给项目需求制造动机,一个问题,一个概念,一个挫折,一种情绪,都会改变需求…”, 所以要追根溯源,才有可能解开谜结。

10.我好像绝大多数时间都在写卡,都没时间去想产品和业务,更别说去写总结和分享了。作为BA,该怎么分配自己的时间和精力?

刚才说的,项目中的时间,60%用于跟踪和管理RAIDs;15-20%时间来分析卡的细节并写出来;15-20%的时间做需求确认(做预验收和给客户演示)。这样自己与客户间的对话尽可能保持在骨干需求级别; 而不仅仅是需求的细节,这样才能把控需求大局。如果需求分析透了,写卡这件事其实比较简单,我会让我们团队的Dev/QA自己去写,我来审核。另外我一定会给自己找出额外的时间,用于学习了解相关产品行业、总结等。“磨刀不误砍柴工”,有时新的解决业务问题的思路、新的工具会让你“事半功倍”。

“敏捷无定式”, 这些答案仅是个人项目中的经验,可能不适用于所有的企业、项目和团队,有启发、能带来思考就好。

Share

敏捷咨询日记——能力建设

enable-team

丰田精益生产信奉的两大支柱是"以人为本"和"持续改进"而从字面来看第一个是所有的基石。印象深刻的是当我第一谈起这一点时候,我隐约感受到这个强大执行力组织中的管理者心中的迟疑。不止一次地被问道在一个庞大的,人员结构参差不齐的组织中如何实践对参与者要求极高的敏捷实践:“若非丰田那种百年拥有有强大技工文化背景的企业不能真正实现精益生产。

这便是我们绝大部分客户对于敏捷实践最为疑虑之处:

弱化流程的敏捷方法如何在平庸素质团队执行?

疑虑的产生合乎情理:敏捷崇尚的自管理团队对人的优秀程度要求极高,自管理的团队可望而不可及。当我承认如此现状时,解决方法无外乎两个:其一提高人员优秀程度;其次则降低敏捷实践的要求。

抛开降低敏捷实践的标准不谈,因为咨询师调整标准的权宜之计只可能有策略地采用,当提升团队某方面的能力到达极致仍不可达到。

于是策略在于如何全尽所能提升团队内部执行敏捷的能力,视为敏捷咨询首要目标。

接下来的问题是,团队需要什么样的能力?让我们回到敏捷理论本身,即对价值近乎偏执的验证。然其背后的驱使永远是杜绝浪费-即停止做和不要做被认为使偏离价值驱使的事。那么我们需要提升的能力究其根本便是如何发现错误的事和如何做正确的事。

简而言之,我们的存在就是告诉敏捷实践团队什么是错误的事,怎么做正确的事。

广泛存在的问题在于,如何做正确的事情可以通过知识传递例如指导手册的方式教授,这也是我们一直以来做的事情例如持续集成如何搭建,测试驱动如何执行,但是往往被忽视的是,团队成员分析错误事情的能力。然而,每个成员如何分辨什么是错误的事情再用正确的方法去做正确的事情,往往被忽视。忽略的原因也很好理解:无法评审,无标准可依。

丰田精益生产线上每个人拥有的那条可以随时停止生产线的拉线背后,体现的是对员工辩识错误能力的信任。员工拉线的驱使只有两个:我知道这是错和我知道怎么改或谁能改。而第一个永远是前提。

我所看到的忽视在于我们强调做正确的事情的能力多于识别错误的事的能力。而我要做的事情就是贴补这一部分短板,即教团队如何发现错误的事情(现在无价值的事)并有勇气拉停整条流水线。

这个目标可以分成两个部分:一为如何通过分析区分正确和错误的事,二为如何阻止错误的事发生。前者关注于团队内部对于统一价值观的一致意见;后者关注于内部敢于质疑的鼓励机制。

统一价值观在于建立一条所有人都认同的质量标准线,这不单单所指代码质量,亦在于对团队所有内部事务的统一评判。帮助团队成员即时发现错误的事,同时降低对同件事情不同观点所产生的争论成本。

鼓励机制在于通过项目管理激励降低因为组织位置差异或身份差异造成的羞涩和不情愿,随时发现和停止造成浪费的错误的事。

必然,关乎敏捷实践中的技术改进必不可少,但是用价值评判和审视作为指导项目内实践活动的准则也是敏捷咨询中至关重要的一步。简言之,我的目标是让团队所有人眼中揉不了沙子并大胆表达偏执。

Share

敏捷咨询日记——匠人精神

“敏捷,是一种匠人阶层的唤醒”

我曾经拜访过印度某个Freemason(共济会)分所,这个世界上最大地下组织来源于传说中制造巴比伦神殿的三个石匠。教谕认为石匠是人类中掌握自然奥秘的一群人,常人只是“神有缺陷的复制品”,而只有靠匠工的不懈努力才能修补人类缺陷使其更接近于神。这也是为什么共济会的标志便是圆规和方矩,方圆规矩的隐喻在六芒星下变得直白。

也许西欧文明开化来自于匠工阶层精英化,不论是对技能技巧的极致追求,或是家族荣耀的逐代传承,这样的阶层似乎在可以营造一种近乎偏执的质量文化。之后,匠人阶层的经验和行规在大生产时代演变成各种制造业雏形,最终演化成一种现代的规模化的制造业体系。从匠人阶级到现代制造业体系,必然是某种技能精益,经验积累,和规则验证极致后模式化规模化的演变。而究其根本,其核心充满着精益中两大核心:“以人为本”-社区荣誉(community honor)和家族传承;“持续改进”-技能演进,经验积累。

相对于西欧文明,我一直苦恼于为何从未断代的华夏文明始终未曾在历史的任何时刻诞生一个类似的匠人阶层。匠人这个在欧洲曾经被认为是改造自然改造人类的职业,在中国被关闭在始皇帝的骊陵中殉葬。不止一次在伦敦的大英博物馆感叹同时期中国的器物精细之程度远胜于欧洲其他文明,但惋惜的是,繁荣延续的匠人阶层未曾出现,更未曾产生过一个趋于成熟的制造业体系。

值得一提的是,欧洲文明善于制作工具,华夏文明善于制作器物本身。工具的目的是为了传承技术,传承技术的目的是为了改进技术,而若只关注于极致精细器物本身,只能理解为中国曾经出现的伟大匠人更关注于“孤品”,或者是更关注于权威绑架。

从精益中衍生的质量文化实际上是对匠人阶层的一种传承,近乎偏执的关注质量,并使用专属的工具和执行相关的流程保证质量,这必是对16世纪共济会繁荣时代(也是工业时代开始的萌芽期)致敬。

很多次,我被告知“以人为本”不可能实现,我忍不发,因我明白匠人们自古以来只是领导者手中更高级的工具,只需做,不必问。而我真正希望做的,是在某种程度上唤醒我们缺失了千年的匠人荣耀,让他们清晰地听见,如果人类走向完美的历程为敏捷项目,他们便是骄傲的交付者。

本文转自:http://i25zt5.lawrence-gd.diancloud.cn/agile-craftman/

Share

敏捷咨询日记——消除浪费

waste

当我们追根溯源敏捷最先被发明的初期,可以发现,敏捷所消除的便是因为频繁业务需求改变带来的潜在浪费,而一切关于杜绝浪费话题到最后,都变成为对价值的纯粹追求。任何商业模式都基于创造新用户和挽留老用户,最终也被细化为为新用户提供不可替代的新价值和为老用户提供持续改进的旧价值(当然同样可为新价值)那么两件事情被认为是杜绝浪费最重要的两个方面:

  • 只给客户想要的;
  • 让客户简单地用到他们想要的;

简而言之,做了没用的和没用已经做了的是最普遍的两种浪费。二者间的关系是:做了没用的往往的结果是未使用,但未使用往往不止是因为没有用(也许你不够好)。

一个简单的对话可能会揭示这个道理。gigix在贴卡片的时候使用了没有ThoughtWorks logo那一面,我问:用反面的价值是什么?gigix说:我顺手写在了反面。我说:那你就把 logo marketing的价值浪费了。gigix便马上在正面重写。可以看出,在卡片的正面印上公司标志是一件具有市场推广和提高品牌认知价值的事情,我们也同意这种价值是实际需要,但是有50%的情况我们可能会忽略这个价值,于是,这个价值便被浪费了。

据说这个卡片的成本是两毛钱,而印刷logo的成本可能是1毛钱(印logo的唯一价值就是展示出来,于是不展示出来的浪费就是100%),每年全球范围内整个公司的卡片消耗量估计有51万张(一个人一年大概消耗300张,一年就是300X1700=510000张)于是理论上每年因为没有展示公司logo造成的浪费就是25500元。

解决这个办法有两个,长期的,如果每个TWer都有一种价值驱动的自然反应,把浪费扩展到日常生活中去,这个价值被浪费的几率可能减少;短期的,两面都印logo的成本理论上比一面印一面不印还要低,而当两面都有的时候,这种浪费便不可能发生,甚至成本更低。

这就是为什么用户体验被拔高到一个很高的地步,良好的用户体验可以更容易地把有用的价值传递到用户使用过程中,而很可能,往往被忽视,这是一个投入低于可能产生的价值浪费的过程。

敏捷当中关于杜绝浪费的阐述,绝对不应该只是个适用于软件开发(或精益制造)的概念,它应该贯彻到所有日常管理开发的过程中。有时候,我会刨根问底地询问某个内部管理表格上某行小字表述的意思,或者某个状态图中某个多余标签颜色的目的,甚至关于饮水机摆放位置的斟酌。

当各种询问进行之后,你会惊奇地发现,这样的价值最后一定被认为阻塞在一个更高级阶层人物的脑中,而所有人要做的只是忍受一次便接受这种浪费。而这样的现象成为一种奇特的人类自适应习性,特别是在一个具有组织结构的环境里,人们不加思索地游走忍受各种浪费,或者说有意识的拿出可能百分之一的生命作为浪费,而不去质问这个所谓深藏在高阶人士脑中的某个模式。而更神奇的是,这样的组织结构似乎就是为了种容忍浪费的习性提供养料,他们用权威语言(community language)描述这种可能产生浪费的活动,用意识形态的方式提高质问的门槛,他们用一种容忍浪费的高明手段来杜绝“浪费”,这种“浪费”被理解为更多的投入,或者改变,或者干脆就是自己权重更大的时间。

更深层次讨论这个问题这样的浪费被打造成一种十分有效的管理手段,因为我们的文化里,当你不懂我的时候,浅意识里我高过你,当你懂我的时候,你可能高过我,换言之,阻塞价值传递带来的心理慰籍多于价值广达于人。于是,如同状元可当驸马入赘皇族给天下清苦寒士打一针鸡血一样,这种“你不必懂,你只需做”的潜台词,成为底层工作者努力上进的“状元奖品”。同时,不可避免的是,各种浪费在这庞大的机器里不停被产生,讽刺地是,某种意义来说这样的浪费便成了机器运转的润滑剂,我们的发展不也是基于更庞大的物质浪费吗?

或许,我说到了最苦恼的地方,我努力尝试把敏捷方法跳出制造业(基于流程的软件业也是一种制造)而更多地作为一种现代企业管理方法论引入企业日常管理当中去,而似乎,敏捷原则的桎梏在于对人的依赖,以及是不是还有权威与非权威的概念,回到刚才的例子,如何保证所有质问的价值都是低于浪费本身的-万一大部分人的质问都是无理取闹?权威“不必问,只需做”的方式是不是本身也是一种杜绝浪费?

就此来看,敏捷方法还有很多值得思考的东西,但杜绝浪费初衷本身是值得肯定的。

本文转载自:

Share