BT

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

文章:学习用数字沟通

| 作者 Barbara Chauvin 关注 0 他的粉丝 , Linda Rising 关注 3 他的粉丝 ,译者 郑柯 关注 3 他的粉丝 发布于 2008年8月13日. 估计阅读时间: 1 分钟 | CNUTCon 了解国内外一线大厂50+智能运维最新实践案例。

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

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

详细内容请看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