写点什么

别再衡量完成时间了

  • 2016-10-12
  • 本文字数:3606 字

    阅读完需:约 12 分钟

关键点

  • 及时性不总是那么重要
  • 完成时间经常被用作成功的替代指标
  • 如果你专注于时间,你会忽视结果
  • 当人们不知道什么真正重要的时候,只好去衡量时间
  • 满意度是主观的

最近,我在亚马逊网站下的订单遇上了点麻烦。我发电子邮件给卖方,告诉他们我预定的是两样货品,他们只发了其中一样给我。对我来说,这不算什么大事,我认为他们最后会解决这件事情。

我得到了标准的自动响应,他们会很快就帮助我解决我的问题。

一小时后,我收到一封电子邮件,向我致以极大的歉意,因为没能在第一时间回复我。这个有些过于客套了,因为对于我遇上的问题,一个小时的等待处理的时间并不算太长。我想,即使他们在几个星期内解决我的问题,我仍然会很高兴。

我敢肯定有人会连一个小时都等不了,但这个人不是我。我和很多人一样,对于两个星期的处理时间不会有什么意见。

所以,我没有回复邮件就去忙别的了。又过了大概一个小时,我收到他们的另一封邮件。这一次,他又为漏寄货品向我道歉。但是,这封邮件提了一个奇怪的要求,而这个要求,我完全没有想到。

他们要求我拍几张相片,包括我收到的物品、包装盒和装箱单。

可我只是买了 5 美元的商品而已!

他们希望我花些时间来分别拍摄三张照片,附在寄给他们电子邮件里给他们发去,以便他们能进一步了解我的情况。可这个时候,我已经扔掉了包装盒,当然也不想把它从垃圾桶里再掏出来。

我大吃一惊。为什么他们会要求我这样做?照片能帮他们做什么?有助于确定我是否在说谎吗?

对我来说,这只是一个简单的信任问题。他们那边有他们需要的所有信息,可以查验我的订单并核实它。亦或是,他们判断我是不是在骗他们?

我接着问为什么他们需要这些照片。我直接了当地问他们,是不是认为我在撒谎。我告诉他们,照相和填写他们的表单都是在浪费我时间。我宁可去亚马逊网站在另一家卖家那里重新下单,这不过是个 5 美元的交易。

我们来回了几封电子邮件。他们坚持说他们需要这些照片但却拒绝解释为什么。他们连续发送相同的要求,一次又一次,就像一个机器人在另一边一样。他们甚至从来没有理会过我的问题“为什么?”

最终,他们在没有为我做任何事情的情况下关闭了我的交易。所有这些事情都发生在我提出抱怨的几个小时内。

整个过程中,他们一直在不断地发送电子邮件通知我,他们会迅速地联系我。也就是说,我不需要等待很长时间。

在我看来,他们更关心的是他们能多迅速地解决我的问题。所谓解决,我的意思是指他们可以多迅速地关闭我的投诉。

想要的只是权宜之计吗?

常识似乎表明人们想要迅速的反应。在某些情况下,人们确实关心时效性。

但也有很多情况下,人们不关心完成时间。不管对完成时间的预期是什么,人们真正想要的是合理地解决问题。

人们需要关心自己的人。

从一般意义上说,人们很容易掉进误区,相信解决问题的速度很重要。但事实上并非如此,并且也远不如你想象得那么重要。

有多少次你被要求要紧急改写一个你负责的软件?多少次你迅速更新却发现你的工作成果被忽视掉,压根没用上?

你最后一次开发的如果不能按时完成就会整个做废的项目,是什么时候了?

有多少次你牺牲了其它的东西而只是为了应急?

完成 == 结果?

不幸的是,完成时间是一件很容易衡量的事情。结果却不是这样。在许多环境中,衡量完成时间是很诱人的,可以使用它作为衡量结果的替代品。可结果却往往是无法衡量的。

完成时间成为成功的替代指标。

看来,我所工作的公司衡量完成时间。非常有可能,他们用对待许多客户完全相同的方式来对待我。应急但不关心结果。我相信他们已经有了足够的完成时间。

但很明显完成时间并不能展现出问题的全貌。根据他们的问题跟踪系统,他们有足够的完成时间解决我的问题。

你如何判断你的软件开发项目是否成功?你衡量什么?你会把哪些东西挂上展板?你为哪些事情而表扬自己?

很可能,你衡量完成时间。我们知道这一项在许多“现代”的开发实践中都被称颂。举几个例子:进度跟踪、燃尽图、需求项、计划扑克牌、迭代计划、时间盒以及任何与“持续”相关的东西,这都是关于时间,而且经常是为了尽可能地减少时间。

敏捷宣言甚至提出:“经常交付可工作的软件”和“可工作的软件是对进度的重要衡量”,这两个想法结合起来就很容易造成疏忽。

我们可以快速开发软件并且我们可以很快地把它作为可工作的软件发布。但是,该软件有什么影响呢?我们是不是仅仅简单地很快地提交了可工作的软件,但事实上这并没有太大的价值?

我们的客户是不是都在疑惑,为什么我们不相信他们,为他们寄出 5 美元的替代品呢?

弥补不足

现在你可能会认为,完成时间仍然是重要的。就事论事的衡量每一件事所用的时间,然后汇总数据和使用情况,把这作为一个指标奖励自己。只要你能找到其他指标来为完成时间做补充,你就不会做错。

不幸的是,没有太多的衡量标准可以告诉你你需要知道些什么。其实你需要知道的是人们是否满意。有效地衡量人们的感受并不容易。

你可以直接问客户他们的感觉。我见过有的公司自动发送电子邮件问我是否愿意参与一项调查。就是简单地点击几个“是”或“否”的链接就好,这种调查很容易做。

但是当你汇总收集到的答案时就出现了一个问题。你如何处理“是”或“否”的答案?你如何汇总大家的感觉是怎样的,并且把它还原为有意义的事情?

是非问题往往缺乏问题的背景。通常,客户都是非理性的。客户不开心不一定是因为你做错了什么。所以你必须弄清楚该如何将这些考虑融入到你的调查中。

从另一个角度考虑,一些客户不管他们是高兴还是不高兴他们都不会告诉你。他们可能根本不回应你的问题。也许他们是因为任何理由而有顾虑,也可能不想让别人不安,所以他们不会诚实地作答。

我记得去年打电话给电话公司投诉我的账单问题。过后,我接到一个调查。我不高兴,所以,我给了低分。

几分钟后,一个主管给我打来电话,问我这件事的详细情况。这不一定是一件坏事。但是,有问题的是,主管告诉我,客服代表哭了。

我感觉很糟糕。其实接我电话的客服代表并不能解决我的问题。我的打分和客服代表的表现无关。分数只是表明我对我的账单处理情况非常不满意。并且我也很不满意我不得不多次打电话来解决这个问题。

我老老实实地回答,却事与愿违。

有人告诉你你把某个人弄哭了——如果你认为这样的事情不会影响大多数客户如何回应调查,那你可能需要再重新考虑一下。这种类型的反馈确实会影响人们在未来的打分情况。

这让我很生气,一家公司竟然无法分辨让我不高兴的是这个处理结果而不是那个试图帮助我的人。

所以,另一个问题是你如何对待你收到的反馈。

只要是衡量和汇总关于表现的统计,就肯定会存在这样的问题。它经常脱离现实,以至于它压根是没有用的,而且最好不要导致不良后果。

衡量完成时间容易导致上文中提到的批评客服代表的情况,应该是去帮助客户,而不是使客户满意。

你还考察了哪些东西作为软件开发进度的指标?它们是否足以消除衡量时间所固有的问题,以减小衡量时间和判断结果之间的差距?

你曾经历过的最大的项目是什么?软件对用户的价值是什么?对业务呢?对你呢?你知道吗?你怎么知道的?衡量交货速度对这些有影响吗?

追求什么便得到什么

无论你在什么行业,无论你在做什么类型的工作,你都不应该衡量完成时间。不要把它贴在墙上,不管这件事有多诱人。

如果你愿意,在一个个案例的基础上你可以计算它,也许可以用它来找到被忽略的东西。但是当你和人类打交道时,你需要知道什么对个体人类最重要。

完成时间往往不是那么重要。如果你优先考虑它,它将成为你关注的重点。你最终会认为你做得很好,但有可能你并不是。

当你把它挂在每个人面前的墙壁上时,你就给大家一种暗示速度是非常重要的。你可能会发现自己保持了快速的完成时间,却付出了不顾结果代价。

了解对某个人来说什么是重要的,这是一项更值得挖掘的能力。要发展与单个客户的私人关系。如果你专注于这一点,你更可能让你的客户快乐和满意,业务也会更成功。

在这个过程中你会发现要做到这一点,需要你下放责任和权威,了解客户价值。

墙上的数字不会比心态更重要,数字是主观的。在商业中,你创造的价值让客户有多满意,你就能猜到你会有多成功,不信你可以试着算算。

说回软件,你真的在乎开发它需要多长时间?你推出功能有多快?或你只是想知道人们对软件满意吗?要为组织提供巨大价值的软件。重视你所意识到的东西,专注于它们,并努力最大化它们的价值。

关于作者

作为一名顾问,韦斯用技术帮助人们消除情感盲点,并产生快速的结果。他的职业生涯非常丰富多彩。他开始时是一个软件开发人员。在与客户密切的合作中,他意识到有许多需求超出了软件本身,却没有得到人们的重视。无论这些需求是否涉及技术,这些都是他今天解决对象。在职业生涯中,韦斯一直非常有分享知识的热情。通过 15 门课程,他帮助成千上万的人得到了提高。他也与 Pluralsight O’Reilly 一起合作。他是一个演讲者,参与无数的地方聚会、社区组织研讨会和会议。他的专业演讲有助于各个公司改进。

阅读英文原文 Stop Measuring Turn Around Time

2016-10-12 18:201817
用户头像

发布了 152 篇内容, 共 70.8 次阅读, 收获喜欢 64 次。

关注

评论

发布
暂无评论
发现更多内容

毕业设计:设计电商秒杀系统

开拓纪

架构训练营 毕业设计

【LeetCode】第 N 个泰波那契数Java题解

Albert

算法 LeetCode 8月日更

快递员应不应该送货到家?

石云升

用户体验 体验设计 8月日更

模块四

Winston

架构实战营 - 模块四

Testcase

架构实战营

商城异地多活架构

arctec

千万级学生管理系统的考试试卷存储方案-模块四

hello

架构训练营

高亮架构训练营毕业设计-设计电商秒杀系统

高亮

架构训练营

模块四作业

Tina

学生管理系统的考试试卷存储方案

技术是伙伴

架构实战营

毕业总结

yu

架构实战营

架构实战营 毕业总结

CR

【架构设计模块四】:设计千万级学生管理系统的考试试卷存储方案

Ryoma

业务定制型异地多活架构业务设计

arctec

值值得收藏,揭秘 MySQL 多版本并发控制实现原理

架构精进之路

MySQL MVCC 8月日更

架构训练营模块四作业

老实人Honey

架构训练营

毕业设计

yu

架构实战营

千万级学生管理系统的考试试卷存储方案

gawaine

架构实战营

04 设计模式之生成器模式

陈皮的JavaLib

Java 面试 设计模式 8月日更 生成器模式

架构训练营——毕业总结

开拓纪

架构训练营 毕业总结

架构实战营 毕业设计

小遵

架构实战营 毕业设计

夏日

架构实战营

模块4 千万级学生管理系统的考试试卷存储方案

SAKIN

初识宽度优先搜索

泽睿

架构实战营-毕业设计项目

༺NPE༻

架构实战营 毕业总结

小遵

Apache Flink的体系架构(三)

Databri_AI

flink 时间戳

架构师学习心得

ifc177

模块四作业

seawolflin

《项目管理三步法》教你搞定孩子 作业拖延症

Ian哥

三个问题,颠覆你的三观

非著名程序员

个人成长 认知提升 个人提升 8月日更

别再衡量完成时间了_技术管理_Wes Higbee_InfoQ精选文章