原文
沒有人想延遲交付時間、超出預算。沒有一個開發人員會在早上醒來的時候想"我今天要做搞一些垃圾代碼。我如何才能增加、耗費雇主更多的錢？"。盡管如此，還是有許多的軟件項目進行的不是很好。總是有來自各方面的壓力，讓我們不得不更快的編寫代碼。因此，如果我們在一家軟件公司，應該怎么作呢？怎樣才能在保證代碼質量的前提下做的更快？
盡管有超過50年的歷史，無數的方法論、建議、書籍，IT項目還是會面臨失敗。
—Susan Moore
商業、生意是解決客戶的痛點的
要開始一個成功的生意，首先要找到客戶的痛點。然后提供方法解決客戶的痛點，以此來換取金錢。例如，人們發現學編程很難。那么寫書或者開班來教編程就是一個市場。有些人不喜歡他們自己的外觀。那么健身、美容、化妝品就是一個市場。商業的價值就在于解決客戶的通點。因此，如果客戶相信我們能解決他們的痛點，那么他們就很樂意付錢給我們。
在軟件行業，軟件就是我們提供的可解決客戶痛點的產品。軟件行業的關鍵在于軟件開發。
當然不是說軟件開發是軟件行業唯一的有價值的活動。例如，如果沒人知道我們產品的存在，我們的軟件產品就變得一文不值。因此銷售和市場活動是必不可少的。我們應該確定我們的產品真正的解決了客戶的痛點，否則我們就是在浪費我們的時間。因此市場調查很關鍵。市場、銷售、市場調查、用戶體驗這些都非常重要。這些活動的目標的偶是：了解人群。這些活動只是計劃和承諾了客戶價值。軟件開發活動在能將這些計劃很承諾轉為一個產品。
如果能理解“產品”、“設計”、“開發”都是同一個事情的不同視角，那么就能做的更好。
— Greg Veen
減少對業務影響的時間
“了解客戶”是一個持續發生的活動。隨之，我們會越來越了解我們要解決什么問題。我開始設計一個更好的解決方案。因此我們也需要修改我們的軟件產品。為了做到這些，我們需要一個敏捷的開發團隊，能快速交付價值、響應變化。這是軟件開發時間的核心目標。
因此，有一個敏捷的開發團隊很重要。但是，如何才能有一個敏捷開發團隊呢？你是否：
- 付給開發很高的工資？
- 給開發人員買速度快的，昂貴的電腦？
- 只要他們想，讓他們去參加任何開發、技術會議？
如果你想保持一個開發敏捷的開發團隊，你應該好好想想上面的每一條。更快的電腦、好的技術會議會提高開發者的生產力。這項投資是值得的。但這些是關于如何維持、留住好的開發。那么如何建立一個敏捷團隊呢。
So if the answer is not giving developers whatever they want, what do we do then? 很簡單，去問開發。在正確的時間用正確的方法問他們。The thing to understand about developers is that they tend to be natural problem solvers. 好的開發者喜歡他們的工作。因為他們喜歡整天去解決復雜的問題，并且以此來獲取回報。好的開發沉迷于接受復雜的挑戰，找到優美的解決方案。但是，很多組織使得開發者去聚焦于錯誤的問題。
聚焦于錯誤的問題
為何會發生這種事情？這是因為我們將開發和客戶隔離開來了。隨著項目越來越大，我們引入了項目管理者，和業務分析師。引入這些人，基于一個很好的理由，開發者沒法完成所有的事情。軟件項目非常復雜。編碼已經很復雜了，但是更復雜的在于決定開發什么，計劃開發的階段，開發計劃，與客戶建立聯系。開發者對于編碼已經夠頭痛的了，因此我們需要額外的人來幫助他們。
但是，當這些人成為了開發和外部聯系的接口的時候，會發生什么呢？項目管理者和業務分析和外部的利益相關者進行溝通。項目管理者專注于項目的交付，項目管理者像管理層進行匯報。那么管理者關心什么呢？
- 還要花多少錢？
- 還要花多長時間？
- 為什么要花這么多錢？
- 為什么項目會延遲？
- 為什么還沒完成？
- 項目延遲一天要花多少錢？
這也是可以理解的，項目管理者變得越來越聚焦于預測。他們計劃、估算。他們想知道發生了什么，什么時候發生的。預測和衡量讓他們在向管理層報告的時候看上去是勝任工作的。因此項目管理者想開發者要預計花費的時間，報告和deadline。因此，開發者也開始聚焦在deadline、報告和估計上了。開發者聚焦于此以使項目管理者開心。
問題是估計和預測是一個不可能解決的問題。每當開發者開始一個新的任務時，他們要面對是一個令人難受的現實。這些任務可能隱藏了了一個巨大的復雜性。我們希望任務是簡單的，但通常不是這樣。
Hofstadter定律: 要花的時間總是比你預想的要長，即使你考慮到了Hofstadter定律。
—Douglas Hofstadter
有這么一個場景：一個項目管理者問一個缺乏經驗的開發要一個估計的時間。缺乏經驗的開發給了一個他覺得合理的預估時間。項目管理者轉身就把這個預估做成了一個deadline和計劃。一個好的項目管理者為了安全起見甚至會在開發給的預估時間上在加那么一點。 不可避免的事情發生了 - 項目要延期了。因此開發者開始工作更長的時間。但是更長的工作時間意味著開發者會越來越疲勞。他們開始犯更多的錯誤。這還不夠，即使這樣項目還是延遲了。項目管理者要求知道是什么耗費了這么多少時間。因此飽受折磨的開發開始偷工減料了。這樣下去，項目于不僅延期了，而且滿是bug。
這樣會帶來負價值。也許這個延期的，滿是bug的產品還是能解決客戶的一些痛點。但是bug帶來了新的痛點，而且需要時間去修復bug。客戶不再有信心我們有能力幫助他。他們不愿再付錢給我們。每個人都失敗了。
有經驗的開發者不去預估要花多長時間。想象下，項目管理者問一個有經驗的開發要預估時間。開發會給出一個聽起來長的荒唐的時間。但長的還不至于公司馬上取消這個項目。項目管理者下一步就是跑過來商量了“這個預估超出了我們希望的時間。有沒有可能我們可以縮短一些？”開發問“你們想縮短多長時間？”項目管理者給出了一個數字。開發摸摸下巴說：“時間很緊啊，我們看看能做些什么。我們應該減少一些需求，只做一些基礎的功能。” 這時項目管理者會評估減少多少需求，并且能看起來還是勝任的。但是，即使在這種情況下霍夫施塔特定律還是會發生。
預估是軟件開發中不可避免的一個問題。不幸的是，人們以為開發一個新軟件和建一棟房子，修一輛車是一樣的，是可以給出一個準確的預估時間的。
—Steve Smith
我們偷工減料，提供低質量的代碼，為了在deadline之前完成工作。我們假設我們之后會回頭來修復這些問題。但是“之后”從來不會到來。我們已經落后于下一個階段，因為我們必須回頭去修改bug。我們寫的是一些脆弱的，硬編碼的代碼，這些不適合于快速修改。一旦陷入這種循環，開發者聚焦的不再是解決客戶的痛點。你們聚焦在了下面這些事：
- 怎樣盡可能快的"完成"這個功能？
- 怎樣才能盡可能的不去觸碰這些低質量的代碼？因為一旦碰了，可能會出現更多問題。
- How can I eke out one tiny piece of code that I’m proud of amongst this giant steamy pile of technical debt?
- 如果像人們證明我的決定是有道理的，他們不知道我做了什么，也不知道這個有多復雜？
- 當客戶開始抱怨我沒有時間去修復的bug的時候，我怎么去責怪別人？
- 如何在簡歷下寫下一些流行詞，以此去到一個不混亂的公司工作？
沒有開發想延遲交付，和寫滿是bug的軟件。但是我們對開發施加壓力，要一個更短的預估時間。開發通常都會服從，因為他想取悅別人。很快開發就會陷入困境，因為他們的預估是錯誤的。因此他們的在交付的壓力下，開始工作更長時間，偷工減料。他們妥協于代碼質量，因為每個人都在問“開發完了嗎？” 沒人是開心的，軟件還是會延遲并且充滿bug。
我認識的開發會盡力做的最好。但是他們還是會陷入困境。他們太想"快"了。因此，他們現在聚焦在了錯誤的事情上。他們聚焦于生存。 當你快餓死的時候，你很難聚焦于為退休存點錢。當你在一個延遲的項目中一周工作7天的時候，你很難去規劃如何做的更聰明。因此首先要認識到想要更快是要投入的。需要財務、時間和情感上面的投入。
打破循環
早前，我建議向開發者請教如何減少交付時間。但是，當開發者在 ‘catch up’模式時，我們不可能從他們那得到好的回復。當我們進入到這種環境，然后說"我們怎樣才能更快？"，可能會得到下面兩種回復：
- 用火燒了它。“我們需要離開兩年，從頭重寫所有的東西。”當開發被技術債務淹沒的時候會發生這種情況。也許有點道理，但是我們沒有預算去這么做。市場也不會等著我們重建。
- 憤怒。 “我們已經夠快了。我不信你通過半個小時的頭腦風暴就能解決這個復雜的問題！” 當開發被強迫產生低質量的代碼時會發生這種情況。當客戶抱怨bug的時候，他們認為他們受到了譴責。他們有理由憤怒。這種心態下的開發者不會幫助我們，除非我們能認真傾聽他們。他們需要知道我們了解他們的擔憂。我們也需要展示，我們對待變化是認真的。
上面兩種開發所關心的都是對的，但是他們是向內聚焦。我們想創建一種環境以此來減少交付時間。如果開發者是這種心態，那么對減少交付時間沒有任何幫助。Step zero is to show that we’re serious about changing things. That will usually involve finding some way to reduce pressure. Even if it’s only temporary.
But even then, unless something changes, developers will still be inward-focussed. They will have plenty of ideas on how to improve what they’re doing. Some of them might be great ideas. But there’s a lot of risk. We need the developers to focus on minimising lead time to business impact. We need to get their focus off dealing with internal pressures. We need to expose them to customer pain.
向開發者暴露出客戶的痛點
So, how then do you expose developers to customer pain? Plenty of other people have written at length on this, so I will only skim the surface. Here are three ideas in order of least-effective to most-effective:
Get developers to use the product they’re making as part of their day-to-day work. In the industry, this is known as drinking your own champagne or eating your own dog food. The advantage of doing this is that it turns developers into users of the product. So any glaring bugs or issues will now cause pain for the developers too. The problem with this approach is that developers aren’t typical users (most of the time). The way developers use software is often different from most customers. So, while this may help developers fix major bugs, it may not provide great insight into typical use cases. Also, this is not always practical. For example, imagine we’re producing a SaaS product for dental hygienists. It may be difficult to for developers to integrate thisinto their daily workflow.
Get developers to do rotations on support teams. A better approach is to encourage developers to take part in some kind of support roster for the product. (They may need quite strong encouragement.) This way developers get to experience customer pain first-hand. So, as they answer phone calls and email (or tweets, or whatever) customers tell them about problems. If developers do this long enough then they will also start to observe patterns of common issues. They’ll see things that come up over and over again. Not having to hear that same complaint again makes a good motivator to fix usability issues. Unfortunately, people rarely contact support to tell you what’s working well. So the feedback is somewhat biased.
Get developers to sit with and watch people using the software on a regular basis. This is the most inconvenient option as it requires the most organisation. But it is also likely to bring the best results. With this approach, developers get to see how real people use the software in real life to do real stuff. They get to see the good, the bad, and the ugly.
Doing these kinds of things with consistency is hard work. It takes effort and organisation. And most developers will have a natural disinclination for it. I feel awkward writing this because I don’t do this as often as I ought. But I believe it’s worth the effort.
Exposing developers to customer pain is an exercise of deliberate effort to overcome cognitive bias. Which is a long way of saying “it’s a way to learn some humility.” We developers are prone to think we’re clever. And many developers are clever. But we don’t know everything. Maybe I’ve finally figured out how monadic bind operations relate to functional composition. That’s great, but it doesn’t mean I know a thing about what our customers are facing as they use our software every day. Exposing myself to customer pain reminds me of how little I really know.
以我的經驗，越是隔離開發人員，最后的產品越是糟糕。許多團隊有一層商業分析，他們認為他們的工作就是將開發和用戶隔離開了，這種做法非常糟糕。開發者不知道客戶是誰，是非常糟糕的。
—Jeff Atwood
