“从来没有意外计算机上调试周期短。”——史蒂芬•列维
调试代码或硬件很少被视为迷人的工作的一部分。作为工程师,我们喜欢的东西——设计。任何调试活动是一种默认,我们的设计不是完美的;我们没有得到正确的第一次。
但调试,调试心态,是有价值的职业技能,不仅在工程。相反,良好的调试技能可能是管理中最重要的。(你应该选择走这条路。)
成功的调试需要对细节的关注和把握大局。是一回事在代码中发现缺少分号拍拍自己的背,捕获错误。这是另一件完全凭直觉,畸形的TCP / IP数据包导致系统崩溃一次17天。这两个技能在一起让你成为一个好的调试器,和一个好的候选人桃花心木行。
大公司必然是分解到部门,部门或组。工程,市场营销,财务,销售,等等。这就是我们做的。我们区分的目的。
“当我们创建组织,我们做给人们关注,”马克说Okerstrom,旅游网站Expedia的首席执行官。“我们基本上给他们近视的许可证。我们说:这是你的问题。定义你的使命,创造你的策略,并让自己的资源来解决这个问题。和神权忽略所有其他的东西不一致。”
我们画的界限在我们工作组很重要,因为它们定义我们所做的和我们不做什么。他们是禁止入内的标志在我们的专业领域。组织图表确定预算和人力,和责任,我们和那些我们没有。他们方便我们说,“不是我的工作。”
Okerstrom知道一个大机构和调试的问题。在他的书中上游作者丹·希斯谈到Expedia的客服噩梦。现场处理数以百万计的在线交易,但高达58%的客户跟踪他们的订单电话。字段调用的海量,Expedia维护客服呼叫中心的全球网络。自然,公司希望减少呼叫中心的成本,同时让顾客满意。他们想尽一切办法想让电话短和提高生产力。
这是完全错误的解决方案。
大多数顾客想要的只是一份他们的行程。这很奇怪,因为Expedia已经发邮件复制到每一个客户。客户已经有他们的行程。为什么很多人——每年2000万的客户——花时间打电话,要求他们应该已经收到了吗?
降低呼叫中心成本为零没有固定的问题。事实上,没有什么客户服务部门可以做来阻止洪水显然毫无意义的调用,因为它不是在其职责范围内来修复它。这真的不是他们的问题。没有人,部门内可见性,或责任,甚至任何动力工程师的一种方式。的确,正如希斯指出的那样,Expedia客户服务部门使问题变得更糟,因为他们鼓励这么做。
在任何组织中,就会做什么。一群想要的也许不是另一组想要什么,所以我们推卸责任,使事情变得更糟。近视的一个公司的问题是没有不同于一个狭窄的调试。如果你看只有几行代码,或者一个页面示意图,你可能会错过失败的根源。如果你唯一的目标是证明这个错误不是在你设计的一部分,它必须是别人的错,你不会在调试。或者在你的职业生涯。
Expedia工作摆脱混乱的问题,忽略自己的组织边界和向后看,找到问题的根源,在类似5个为什么技术。为什么会有这么多他们数以百万计的客户请求信息已经收到了吗?,许多自动生成的确认邮件是降落在收件人的垃圾邮件文件夹,所以Expedia改他们避免垃圾邮件过滤器。另一方面,客户是稍事休息自己的电子邮件地址,所以消息反弹(或者去别人)。或电子邮件刚收到错误的和客户打电话来请求第二个副本。
这些都是简单的修复。减少拼写错误,Expedia现在让你输入你的电子邮件地址(如大多数网站)的两倍。这个看似微不足道的变化是很难的,因为这些工作在Expedia的销售部门说,他们会失去客户。两次输入你的电子邮件是一个讨厌的东西,和一个小但很大一部分客户会放弃。太糟糕了,首席执行官说。有点痛,疼痛的前端会节省很多下游。在编码方面,范围检查您输入可以节省很多问题和冗余检查。
Expedia还添加了一个自助选择在其网站上,所以客户可以请求一份他们的行程。每年砍掉了几百万更多无意义的电话。从2012年的58%的电话率现在下降到15%。
“当你花年应对问题,有时会忽略一个事实:你可以预防,”希斯说。
这一切看起来很有点事后诸葛亮,但这就是重点。你几乎总是承认一个错误的来源后你已经找到了。选择了不匹配的括号和松散的电线很容易。真正的技能是识别可能的更大的系统性问题,严格地说,在你所在的地区之外的责任。
在医学术语,我们可能比较预防与治疗。经理谈论主动而不是被动的。希斯称之为上游和下游的思考。我认为这只是好调试。