【ArchSummit架构师峰会】探讨数据与人工智能相互驱动的关系>>> 了解详情
写点什么

别再衡量完成时间了

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

    阅读完需:约 12 分钟

关键点

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

想要的只是权宜之计吗?

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

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

人们需要关心自己的人。

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

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

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

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

完成 == 结果?

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

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

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

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

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

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

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

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

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

弥补不足

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

追求什么便得到什么

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

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

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

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

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

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

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

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

关于作者

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

阅读英文原文 Stop Measuring Turn Around Time

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

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

关注

评论

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

技术干货 | Native 页面下如何实现导航栏的定制化开发?

蚂蚁集团移动开发平台 mPaaS

大前端 H5 移动开发 mPaaS

大数据presto作业

Clarke

深入浅出Redis宝典,阿里架构师10年经验汇总,PDF免费分享

Java redis 架构

DCEP:真正的“无现金新时代”!现已完成技术对接!

CECBC

列举出常见的Java面试题100+,我靠这个在十月拿到了阿里的offer

Java 程序员 编程语言

第6章-《Linux一学就会》- Centos8 用户管理

学神来啦

Linux 运维 linux学习 linux云计算

AI技术在漫画阅读体验上的应用

快看工程技术中心

深度学习 AI 漫画

小程序下一破局点?钉钉小程序卡片,应用与平台的深度集成

阿里巴巴终端技术

小程序 ios android App 移动开发

大模型时代的AI之变与开发之根

脑极体

开发上云,化繁为简 | CIF 论坛精彩看点

CODING DevOps

腾讯云 DevOps 云原生 云开发 CIF

后端选择 java, 还是 python?

cdhqyj

夸克APP端智能:文档关键点检测实践与应用

阿里巴巴终端技术

算法 移动开发 客户端 端智能

云拨测助力节卡机器人 全面优化海外网站性能

阿里巴巴云原生

阿里云 云原生 拨测 成功案例

2022前端react高频面试题

buchila11

React

太有用,Alibaba架构师十年心血熬成的435网络协议文档

程序员 编程语言 网络协议 TCP/IP

财经大课:从效率公平看“共同富裕”

石云升

学习笔记 9月日更 共同富裕

十大算法

wudaxue

如何处理各种「陨石开发」的紧急要求?

LigaAI

敏捷开发

这份阿里P8手写的JDK发展史源码剖析手册,竟获GitHub热门榜第一

Java 架构 面试 程序人生 编程语言

当支付宝 App 遇见 AndroidX......

阿里巴巴终端技术

android App 移动端 AndroidX

常用的 分布式事务 都有哪些?我该用哪个?

Java 程序员 面试 后端 计算机

P8整理的OpenStack构架,希望能帮助到你

hanaper

不愧是阿里高工出产的《Java面试手册》,实战命中率竟高达“80%”

Java 架构 面试 后端

内含(基础+进阶+高级+调优)的神仙级的阿里巴巴“MySQL”教程限时开源!

Java 架构 面试 程序人生 编程语言

网站攻击到提权的全部过程

网络安全学海

黑客 网络安全 信息安全 WEB安全 漏洞分析

想要入职阿里P8?至少是要啃完这本500页Java并发多线程源码笔记!

Java 架构 面试 程序人生 编程语言

GraphQL 快速入门【4】GraphQL 组件

码语者

Rest graphql

顺丰对供应链+区块链应用的思考与规划

CECBC

企业如何通过图数据库及知识图谱形成业务壁垒

星环科技

低代码的自动化工作流靠谱吗?对企业有何帮助?

优秀

自动化 低代码

百度智能云全面升级金融AI中台解决方案, 打造软硬一体AI开发全栈能力

百度大脑

人工智能 金融

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