BT

如何利用碎片时间提升技术认知与能力? 点击获取答案

用数字沟通——来自敏捷精灵的忠告

| 作者 Barbara Chauvin 关注 0 他的粉丝 , Linda Rising 关注 2 他的粉丝 ,译者 郑柯 关注 3 他的粉丝 发布于 2008年8月13日. 估计阅读时间: 17 分钟 | GMTC大前端的下一站,PWA、Web框架、Node等最新最热的大前端话题邀你一起共同探讨。

因为不知道要如何还击,我们技术人员屈从于市场人员和管理者们——这些代表业务的人;这已经是老生常谈了。结果,业务人员眼里的开发人员充满了消极和抵制的情绪,而开发人员则给商务人员贴上了无能甚至是撒谎的标签。这是一场正在进行的“我们和他们”的战争。 Linda Rising认为,问题的产生是因为一个基本的误解:业务人员更多是通过数字来做出与人和团队相关的决定,但开发人员主要将数字用于计算。

是不是就没有和解的可能了?Linda的答案是“当然可以!”——只需要一点指导,开发人员就能够掌握足够的业务语言,让他们跨越沟通的鸿沟。正如“敏捷精灵”在这个故事中指出的,关键技巧是使用数字语言,用之表述与计算无关的问题和事件,以辅助决策。


他们一进入Rick的视野,他就想赶紧跑开,到桌子下或其它地方藏起来,但是已经晚了。他的Team Lead——Jim和市场部的Sam已经进到了他的小隔间里面,站到了Rick面前。

“你好,Rick!”Sam跟他打招呼“只有找你帮忙了!我们的新客户对Framits很感兴趣。但问题是,他只需要Whatsis模块,并且希望赶在我们现在的客户之前拿到这个模块。如果我们能在这个月底前交给他,他愿意支付一笔额外的费用。我知道这对你来说有压力,但你总是能够搞定这种棘手的事情。还能说什么呢?你能帮我们搞定这个吧?这对公司来说很重要,我们第三季的销售情况不是太好。”

Rick很艰难地动了动身体,就像一只被困在陷阱里的老鼠。他甚至不能看对方的眼睛,而Jim对此也无能为力。Rick知道Jim也是被迫的。这种强人所难的事情以前也不是没有发生过。Rick本来以为,一旦团队采用“敏捷”开发,事情会有所好转。但事与愿违,商务人员依然按老方法行事。他只能回答“我不敢保证能在最后期限之前完工。我是说这个月底。那个模块牵涉很多工作,目前还无法预计什么地方会出问题。我想…”

“当然,Rick,当然”,Sam说“你们开发人员总是这样,什么时候你们才会说‘没问题’?听着,如果你愿意周末加班,应该是有奖金的。”

“这不是钱的问题,Sam,”Rick争辩道,“我只是不确定要多久才能完成,但是…”

“但是什么,Rick?”Sam打断了他,“把数据拿出来再跟我谈!我可没有时间听你说这些‘但是’,我要尽快告诉客户没有问题。”Sam转身走开了。

Jim在一旁看着Rick,一脸无助:“抱歉,Rick。我在‘敏捷’上还是个新手,不知道该对这帮市场人员说什么。你知道这是怎么回事。客户,总是谈客户。不过,这难道不是敏捷思想的一部分吗?客户很重要,对吧?”

Rick点头:“恐怕是的。”

“一会儿再跟你谈,”Jim心不在焉地挥了挥手离开了。

Rick坐下来,两手抱着头。他希望公司能够盈利。他希望大家对他的印象是一个“有团队精神的人”,随时准备尽自己的工作职责。刚才发生的一切让他感到沮丧。他刚刚说的是实话,确实现在还不太了解那个模块。有一大堆没人接手的故事卡片。突然有什么声音,这让他吃了一惊。这声音又响起来了。他一抬头,看见一个东西。事实上,他也不知道自己看到的是什么,就像一个幽灵,它还在咯咯的笑!


“谁,你到底是谁?”Rick小声说。

“嘘,别人会以为你在自言自语的。”幽灵笑了起来。“我是来帮你的。你似乎没有搞清楚事情的状况!”

“你是什么意思,来帮什么忙?”Rick注视着它。“你是谁?在我的隔间里做什么?”

“别紧张,Rick。”幽灵突然严肃起来,“你遇到了一个大问题,许多开发人员跟你有同样的困扰。我决定来帮你一把。如果你的问题解决了,那么你或许可以用这种方式帮助别人。我没有时间挨个辅导你们,即使我很敏捷!”幽灵再次咯咯笑起来。

看到Rick一脸迷惑的样子,幽灵点点头:“先自我介绍一下,我是敏捷精灵。任何形式的敏捷都以我为核心,我才不管你们是用XP还是Scrum,还是像Gary McGraw说的‘屠杀山羊’,真喜欢‘屠杀山羊’这个说法——这是个笑话,听懂了吗?”精灵重复了一次,但是Rick只是摇摇头。

精灵清了清嗓子继续说下去:“我发现一直都是这样。开发者向市场人员和管理者——代表业务的人——屈服。业务人员眼里的开发人员充满了消极和抵制的情绪,而开发人员则给业务人员贴上了无能和撒谎的标签。这是一场正在进行的战争。‘我们和他们’之间毫无和解的可能。”

“是的,”Rick赞同道,“你说得对。这些人很愚蠢。他们满口都是日期和数字,这些数字在他们眼里都一样,没有任何意义。但如果我们这些开发人员提供了数据,我们是很认真的。那些数字也一定是有意义的。这一点跟业务人员完全不同。”!

“这就是问题所在。”精灵说,“你说的正中要害。开发者和业务人员对数字的理解完全不一样。”

“等等!”Rick提高了嗓门,他赶紧跳起来看了看走廊:很安全,没有人注意到他的反常,即使听到了也会以为他又在自言自语。“数字就是数字,”Rick摇晃着拳头说,“同一个数字,比如‘2’,在不同人眼里含义难道会不一样么?真是荒唐,数字就是数字…”

“等等,”精灵打断了他,“让我给你举个例子。从咱们都知道的语言出发,我使用了一个单词,而且我想你应该知道我在说什么,接下来我们就可以开始对话了,对么?”

“没错!”Rick回答“就是这样!单词同数字一样有确定的意义。不然的话,就会以为我们说的跟想的一样——实际上却有所不同。”

“但是,你肯定曾遇到说过的话被对方误解的情况吧?你也会遇到过与别人用同一个词,但是表达的意思却不一样的情况吧?”

“嗯,你说的没错。”Rick承认,“这种事情时常发生。我说的话有一半都被误解了,特别是关于最后期限的那些。”

“想一下你刚才说过的话,Rick,”精灵蹲下来,用很认真的表情说:“你说2就是2,没啥好说的。对吗?”

“当然是!”Rick叫道,又赶紧用手捂住嘴。“当然是的!”他低声说道。

“但是,”精灵继续说道,“数字是‘生造出来的’,这没错吧?你能到真实世界中找出一个‘2’的实体来么?”

“这个,当然,”Rick表示赞同,“这是由数学家创造出来的系统,但这并不意味着对2会有不同的解释。”

“但如果发生了类似于我们之前提到过的、关于‘词汇’的误解呢?如果对数字真的有不同的理解呢?你不是说过,业务人员在数字上都是满口“谎言”?”

“他们从来如此!”

“难道不是因为对数字的理解不同吗?”

“不可能!”

“别激动,”精灵提醒他,“让我们想想市场人员、业务人员或者管理者承担的角色。在实际工作中,他们要面对许多形形色色的“精确”。有时候,“精确”是一个范围,比如说时间或者成本。只要数字在这个范围之内,他们就会非常开心,而并不会在意“真正”的数字是多少。这个范围有时候很大,有时候很小——完全取决于风险和要做的事情,这些都会根据环境发生变化。当然,有些时候这个数字可能非常精确,如果是时间的话,可能要求不晚于某个特定日期。比如说,他们可能有一个与某个产品交付密切相关的预算计划,或者在向客户交付新产品后,他们可能希望销售额能够增长某个百分比。在预估销售增长带来的收入时,要考虑预算和因雇佣人手或添加设备而需要增加的计划开支。如果不这么做,在准备支持销售的提升时,可能就已经导致高昂的开支增加了。”

“嗯,”Rick将头歪向一边,“我可以认为他们在‘使用数字’,但这并不意味着我喜欢这样。”

“还有一些你可能没有考虑到的因素,”精灵继续说,“商务人员用数字辅助做决定,他们并不是一定要用数字进行计算。你们团队里那个不喜欢采用敏捷的家伙——Fred,你知道他吧?”

“哇!你连这个都知道?你在这里晃悠了多久了?”

“我有时候会很让人吃惊呢。”精灵笑起来,“总之,之前你到Team lead——Jim那里去,告诉他如果Fred在,那么敏捷试验就无法进行。Jim让你接受事实,给Fred找一些事情做,你感到很不高兴。但是你期望什么呢?Jim并不能因为有人抱怨就将员工开除或者是调走。Fred是一个干活的好手,他是Whatsis方面的专家,并在多个项目实施过程中用到了 Whatsis。即使他不赞成敏捷,你可能也需要他的帮助,特别是对付这些新客户。好,让我们回到数字上来。

“有趣之处在于管理者喜欢与数字打交道,所以如果你跟Jim谈这个问题的时候,用数字而不是带有个人情感的方式来表达,他对问题影响的理解会更加清晰和简单。这样你会更有希望获得别人的反应和行动——除非是连傻瓜都能做决定的事情。一个导师告诉我,很容易做的决定不算是决定!管理者要根据成本和收益来考虑问题。选择‘是’和选择‘否’,会带来什么样的影响。成本和收益可以用模糊或者明确的方式来表示。他们喜欢明确的方式,因为它往往基于数字,而不是个人的情感。数字是无可争辩的。如果别人对你提出质疑,通过数字,你可以很容易地获得证明和支持。同时,在进行短期和长期的公司战略规划时,数字也会有帮助。数字的增减可以表示某件事的程度。模糊的方式不好处理,难以判断,更难着手。出错的几率增大,而且个人也很容易做出不同的诠释与质疑。如果需要的话,人们会采取模糊的方式。但是管理者更喜欢具体的方式,如果这些数字足以帮他们做出决定的话。

“我给你一些建议,Rick。把模糊的原因变得更明确。你之前告诉Jim的方式就很模糊 ——只谈到一个团队成员的态度和行为,而且非常个人化——都是关于某个人的,这容易导致误解。可以用下面这些明确的数字进行解释:公司成本、返工、完成任务所需的额外时间、在会议上浪费的时间、公司需要承担的真实成本,这样阐述问题老板就可以理解了。下次,给Jim一些具体的内容,一些他能够向老板汇报的信息,他们做出的决定会让你更开心。”

“你的意思是编造一些数字吗”

“我是说没有人能够预知未来,但是如果你能用数字来进行沟通,那么人们就会理解你所说的深层含义了。”

“我光靠说还不行?”

“是这样的。光靠个人的意见,没有数据支持,是无法做出业务决定的。Jim可能同意你的观点,但是在没有数据支持的情况下,他无法作出正确决定或者向老板汇报情况。”

“下面我要说的很重要。”精灵说,“这也是我来这里的真正原因。开发人员主要把数字用在计算上,这就是你所谓‘2就是2’的逻辑。当然这是数字的正当用法,但不是唯一的用法。商务人员用数字来辅助决策。实际上,他们需要依据数字来进行决策。商务人员和工程师不同,他们有另外一套解决问题的方式,而且决不会借鉴你的方式。解决这个困境唯一的方案,就是让你这样的工程师学会用业务人员的语言来交流。如果能够做到这点,你不仅不会失去信任,还会得到业务人员的支持,因为你帮助他们理解了你的立场。另外的好处在于:单纯从个人的角度出发,你需要让你的观点被更好地理解。先进行估算再学习如何改进,是敏捷世界的要点之一。如果你不把数字摆出来,在估算的时候不利用数字,你就无法改进这些估算。你不知道需要花多长时间能解决问题,也无法在同业务人员沟通的问题上取得进步。尝试采用敏捷方法,尝试有效利用数字,不仅仅用它来进行计算而且是作为一种语言,这将能提高你的工程能力。这听起来像不像一个多赢的主意呢?”

“这么多,我还真得好好想想。”Rick若有所思,“不过你所说的我明白几分。或许我应该开始试着给Sam 一些有关Whatsis的数据,或许我应该让Fred来帮忙?天哪,我在说些什么啊?现在你该让我跟Fred交谈我的想法了!”Rick站起来,看看四周,发现隔间内还是自己独自一人。他摇了摇头,然后又点了点头,微笑着向Fred的隔间走去。

查看英文原文:Using Numbers to Communicate - in the Spirit of Agile

关于作者

Linda Rising在亚利桑那州立大学获得了基于对象设计方法领域的博士学位,她的背景还包括:在大学中授课,在电信、航空电子和战略武器系统等行业的工作经验。在模式、回顾活动、敏捷开发方法和流程变更等方面,是国际闻名的演讲者。Linda是《Fearless Change: Patterns for Introducing New Ideas》一书的作者,与Mary Lynn Manns共同编写,而且是《Design Patterns in Communications Software》、《 The Pattern Almanac 2000》和《The Patterns Handbook》等书的编辑。

InfoQ的读者都很喜欢Linda关于“Bonobos”的采访,其中谈论了有关大脑的科学,还有她的文章《Questioning the Retrospective Prime Directive》。


Barbara Chauvin具备业务系统设计、项目和项目组合管理方面的背景和相关经验,并曾在IBM、3M、DMR Group和LinkAge工作。目前是Sentry Insurance的Nonstandard Auto Insurance的业务支持总监。


InfoQ的读者Jason Little曾经遇到类似的情况:

我曾多次遇到类似情况,让我很不开心。其中一个极端的情况导致整个部门离开了公司。“我们vs他们”这样的说法非常准确,但是以我的经验来看,这是由于缺乏领导力的问题。我曾经试过的一种方式,是把开发速度、得到的业务价值与收入这三个数字放在一起。数字当然会不同,但是它们之间的关系才是关键。管理层和项目干系人可以将业务价值与功能(故事)做比对,同时跟踪收入作为项目和功能进展的结果,团队仍然照常估算故事。一段时间之后,就可以观察到团队交付的功能能够收到的业务价值,管理层也会把这些对应到收入上。就像Scrum团队能够从估算和承诺中学习如何提高一样,管理层也可以学习到如何更好地估算业务价值。

志愿参与InfoQ中文站内容建设,请邮件至editors@cn.infoq.com。也欢迎大家到InfoQ中文站用户讨论组参与我们的线上讨论。

评价本文

专业度
风格

您好,朋友!

您需要 注册一个InfoQ账号 或者 才能进行评论。在您完成注册后还需要进行一些设置。

获得来自InfoQ的更多体验。

告诉我们您的想法

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

开发人员掌握足够的业务语言 by 徐 绪雄

在软件开发过程中,开发人员往往只关注与开发相关的技术内容的学习,而忽略指导开发进行的实际业务知识。从而出现因与实际业务不符的重复性还工。对于参于其中的各方都是一个很大的打击。开发人员掌握足够的业务语言是高效完成开发任务有力保障。

橙汁测试 by haixiang xu

橙汁测试

即使有了具体数据的支撑,在实际的工作中仍然存在开发与市场之间的诸多博弈。 by woo terry

实际上,现在开发给出中的各种数据非常的丰富,但要说明市场或研发领导仍然是一件几乎不可能的事情。因为众多研发领导的考核指标也是以市场成功为导向的。

研发和市场之间的信任关系非常关键,双方的统一目标如何能够达成一致又是这一点的前提。感觉还是很难,不知哪位是否有一些成功操作的case,期待中。。。。。

开发人员,特别是开发的领导者,应该学会工程估算 by Lv Jili

这篇文章道出了很多公司的实情。
软件开发过程充满了未知和曲折,本质上工程量就难以估算,开发人员很容易满足于“今天我已经很努力了”这样的说法。但销售、管理人员要的是时间、成本以及质量。要解决沟通问题,还是要各打五十大板。
开发人员,要尽量对工程量进行估算,因为这对于完成商业价值是非常重要的。即使不准确也不要紧,关键是要做,并不断的重新评估。再就是不要频繁换技术,新技术会带来很大的未知数。或者专门找人研究新技术。
业务人员,对于开发人员要足够信任。允许开发人员估算有出入,并留有余地。切忌说什么,“当初不是说好了的,怎么还没做好完成”。当计划订出来后,没有人不期望按计划完成。这种话说多了,开发人员就会给估算留有大量水份,为的是不时之需。
当然,估算的伸缩能力还是都要考虑的。

“我们”和“她们” by 徐 绪雄

软件开发是项复杂的事情,如何从需求、技术、人三方面获得可靠的平衡,在大多数企业内部认识上都没有达成共识。“我们”和“她们”将需求的提出者和实施者无形中进行了隔离,如 terry woo 所说,工作中出现了开发与市场之间的诸多博弈; 那么这种情况是不可避免的吗?显然不是,很不幸,任何单方面的行动,到目前为止都是失败的,因为在整个个过程中,大家依然在说“我们”、“她们”。

Re: 即使有了具体数据的支撑,在实际的工作中仍然存在开发与市场之间的诸多博弈。 by Li Jacky

是的,你说的很多,开发与市场的博弈经常存在。

我可以分享一下我关于开发与市场博弈的例子,以下是一个在市场部主持召开的进度会议上的对话:

我代表开发部主管,m代表市场部主管,开会的时间是5月份初

m:现在开发的进度怎么样了?

我:318个功能点,目前已完成71个功能点

m:那能在8月1号前完成吗?

我:我可以估算一下,我们到目前为止进行了3个sprint开发,共完成71个功能点,也就是在目前9个人的开发团队上,每个sprint是能完成大约23个功能点,那剩余的247个功能点,大概需要10个sprint,每个sprint是3个礼拜,也就需要30周后才能完成。所以从这个估算来说,8月1号前完成,几乎不可能。

m:这个时间准吗?

我:因为功能点有很多不同的特性和复杂度,我不能保证这个时间是准的,但可以给你们个参考。

m:那怎么样才能保证8月1号前完成呢?

我:投入更多的人和时间是最有效的办法

m:那需要投入多少人呢?

我:目前我们统计出来平均每人上班时间是10.1小时,也就是基本上每天加班工作了。也就只能增加人了,按照上面的估算,如果要将周期缩短到12周,才能保证8月1日完成,那就至少要多投入一倍多的人。

m:这个成本那会很高诶

我:按照目前的估算,这是没办法的事情

m:那我们市场部再考虑看看吧。如果是这样,那也不一定非要在08月1日前完成。

我:我们也会继续努力(他们对deadline松口了,我也就达到目的了)

Re: 即使有了具体数据的支撑,在实际的工作中仍然存在开发与市场之间的诸多博弈。 by 徐 绪雄

总的说来你的整个沟通过程是失败的,很显然m只知道项目在8.1之前完不成,那对于这以经完成的71功能点的价值一无所知,并未形成对m有利的态势,我想过不了多久m又要来找你了,下次也许是问“能在9.1号前完成吗?”

应该先弄清楚“完成”的真实含义 by Zhang Charlie


2008年8月19日 下午11时32分 发表人 jiang li



市场部主管(m):那怎么样才能保证8月1号前完成呢?



开发部主管(我):投入更多的人和时间是最有效的办法



...




m:这个成本那会很高诶



我:按照目前的估算,这是没办法的事情



m:那我们市场部再考虑看看吧。如果是这样,那也不一定非要在08月1日前完成。


不知道市场部主管所说的“完成”是不是指提交全部的 318 个功能。难道必须要在 8.1 之前交付所有的 318 个功能,市场部才能开展有效工作?我表示怀疑。




实际上,投入更多的人或时间,往往很难办到。针对无法实现的 deadline,time-boxing 迭代的一个标准解决方案是砍掉功能。




我觉得更好的、对你们公司整体更有利的一种做法是:1)把这 318 个功能之间的关系结构梳理一下,排出一个轻重缓急,让市场部挑选;2)弄清楚市场部设定这个 deadline 的真实原因和必要性。




有时候部分完成也是不错的选项。




敏捷 OO 教练 张恂


www.zhangxun.com

建议:给你们的市场部培训敏捷迭代开发 by Zhang Charlie

jiang li,



不错,你的博弈理由很充分。




然而,如果市场部人员尤其主管们,不理解什么是敏捷迭代开发,我想在公司组织层面,你们通过 Scrum/Sprint 获得的好处是很有限的,只能算是局部优化



作为开发部主管,让市场部主管明白什么是敏捷迭代开发,尤其 time-boxing iteration,以及你们的开发方式,我觉得是你值得考虑的下一步优先工作。



敏捷 OO 教练 张恂


www.zhangxun.com

Re: 应该先弄清楚“完成”的真实含义 by Li Jacky

恩。张教练分析的很正确。

很多时候,市场部设定的deadline可能是毫无意义或则片面的。这次的沟通就让他们知道这个deadline本身存在的问题。

现在已经是8月份了,只从那次沟通后,市场部的人就不会无理的设置deadline,而是与我们谨慎讨论具体的阶段性的目标(严格指明需要实现的功能点)。

Re: 即使有了具体数据的支撑,在实际的工作中仍然存在开发与市场之间的诸多博弈。 by Li Jacky

^_^,市场部对数字是很敏感的,他们知道9.1号也无法完成318个功能点,何必多次一问的。他们现在的做法就是与我们讨论出318个功能点中的优先级,我们按照优先级顺序,分阶段给他们实现完成。

Re: 即使有了具体数据的支撑,在实际的工作中仍然存在开发与市场之间的诸多博弈。 by 徐 绪雄

又见“她们”和“我们” :(

Re: 即使有了具体数据的支撑,在实际的工作中仍然存在开发与市场之间的诸多博弈。 by 刘 晓彬

非常精彩.
我现在就是碰到这个问题.没有用数字与老板进行交流.博弈中开发部总是处于劣势.结果成了项目问题全部都是开发部的原因.

Re: 开发人员掌握足够的业务语言 by 苏 生

我们开发的是内部应用系统,你说的情况在我们这边挺严重,出现了开发出来的功能和业务需求是脱节的显现

这个结果不错 by Zhang Charlie

very good.


2008年8月22日 上午2时1分 发表人 Jacky Li



^_^,市场部对数字是很敏感的,他们知道9.1号也无法完成318个功能点,何必多次一问的。他们现在的做法就是与我们讨论出318个功能点中的优先级,我们按照优先级顺序,分阶段给他们实现完成。

Re: 情况的确挺严重 by Zhang Charlie


2008年8月27日 下午11时31分 发表人 生 苏



我们开发的是内部应用系统,你说的情况在我们这边挺严重,出现了开发出来的功能和业务需求是脱节的显现




出现这种情况表明,需求分析能力不足,需求管理的彻底失败。



Use Case 分析是一种联系业务需求和软件功能需求很好的技术。

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

允许的HTML标签: a,b,br,blockquote,i,li,pre,u,ul,p

当有人回复此评论时请E-mail通知我

16 讨论

登陆InfoQ,与你最关心的话题互动。


找回密码....

Follow

关注你最喜爱的话题和作者

快速浏览网站内你所感兴趣话题的精选内容。

Like

内容自由定制

选择想要阅读的主题和喜爱的作者定制自己的新闻源。

Notifications

获取更新

设置通知机制以获取内容更新对您而言是否重要

BT