如果你有不會(huì)寫代碼卻要管理程序員的領(lǐng)導(dǎo)或上級，那本文就是要給他們掃盲軟件開發(fā)的基本常識(shí)。比如：為何軟件開發(fā)工期難以估計(jì)、為何開發(fā)速度那么慢、為何程序員要“浪費(fèi)”時(shí)間寫測試以及做代碼審查（Code Review）？

更快，更好，更便宜——軟件開發(fā)的藝術(shù)

沒人想交付延遲的、超過預(yù)算的軟件，我從沒見過一個(gè)軟件開發(fā)者會(huì)大早上起床后心里想著“我就想把工作干得很差勁，我怎能讓老板花更多錢呢？”但是，有太多的軟件項(xiàng)目進(jìn)行得都并不順利。而且對于每一個(gè)新項(xiàng)目來說，似乎在加快軟件開發(fā)速度方面的壓力變得越來越大。所以，如果我們正在從事軟件開發(fā)的工作，那么我們應(yīng)該怎么做呢？我們應(yīng)該如何在不降低軟件質(zhì)量的前提下加快開發(fā)速度呢？

雖然歷經(jīng) 50 多年的歷史，已推出無數(shù)方法、建議和書籍，但是 IT 項(xiàng)目仍總是經(jīng)歷失敗。——Susan Moore [1]

現(xiàn)在，我不是以某種專家的身份在這兒寫東西。我從沒運(yùn)營過自己的軟件公司，也沒傳播從豐富的學(xué)術(shù)研究或?qū)φ諏?shí)驗(yàn)中提煉而出的理念，我寫這篇文章是為了組織我自己的想法，因?yàn)槲蚁胍O(shè)法了解我所看到的周遭所發(fā)生的一切。

為了正確地看待此事，我們首先需要搞清楚為什么要開發(fā)軟件？所有軟件生產(chǎn)的意義是什么？我們?yōu)槭裁醋铋_始要做的就是開發(fā)軟件？咱們暫且把開源當(dāng)做房間里的大象擱置一邊，先來探討一下商業(yè)軟件。咱們先從生意說起。

生意就是指減少客戶的痛苦

按照我的理解，為了達(dá)成一筆成功的交易，我們首先應(yīng)該找到使人們痛苦的東西（找痛點(diǎn)），可能是一種隱喻形式的或字面形式的痛苦（但通常是隱喻形式的），然后我們以錢作為交換，為他們提供減少痛苦的方法。例如，人們發(fā)現(xiàn)編程很難（很痛苦），所以開辟了編程書和編程課的市場；有些人不喜歡他們自己的外表，所以帶動(dòng)了健身、化妝品、美容等等整套完善產(chǎn)業(yè)的發(fā)展。生意從某種程度上給客戶傳達(dá)的觀念是它們可以減少客戶的痛苦（或?qū)ν纯嗟母兄?，而且如果人們相信我們可以減少他們的痛苦，那么他們就會(huì)很樂于給我們付錢。

在軟件產(chǎn)品業(yè)務(wù)中，軟件就是我們用來減少客戶痛苦的東西。對于這種類型的業(yè)務(wù)，軟件開發(fā)就是提供價(jià)值的關(guān)鍵環(huán)節(jié)?？蛻糍I（或訂購）一件產(chǎn)品，那么軟件開發(fā)這一環(huán)節(jié)負(fù)責(zé)把它開發(fā)出來。當(dāng)然，這只適用于產(chǎn)品業(yè)務(wù)。如果我們把咨詢服務(wù)或IT作為一種支撐功能進(jìn)行售賣，那么情況就會(huì)有所不同。可是但凡主要核心業(yè)務(wù)是軟件產(chǎn)品的，那么完成該業(yè)務(wù)的手段就是軟件開發(fā)。

這不是說軟件開發(fā)就是增加價(jià)值的唯一方式。例如，要是沒人知道我們的產(chǎn)品存在，那么還不如說它真的不存在呢，所以產(chǎn)品的營銷和推廣活動(dòng)也是至關(guān)重要的。我們也需要確保我們的產(chǎn)品實(shí)實(shí)在在解決了客戶的真正痛點(diǎn)，否則，我們就是在浪費(fèi)時(shí)間，所以市場調(diào)查（無論是正式的還是自組織的）同樣是非常重要的。產(chǎn)品中的摩擦是我們解決客戶問題時(shí)的攔路虎，我們也需要用戶體驗(yàn)（UX）和圖形設(shè)計(jì)活動(dòng)來減少摩擦，所有的這些活動(dòng)（營銷、銷售、市場調(diào)研、UX、設(shè)計(jì)）都很重要，而且如果你略微瞄一下，它們看上去都挺相似。它們就好比同一個(gè)核心活動(dòng)的不同方面，這個(gè)核心活動(dòng)就是理解他人。但是歸根結(jié)底，所有的這些活動(dòng)只為客戶價(jià)值提供計(jì)劃和承諾，而將所有的計(jì)劃和承諾轉(zhuǎn)化為實(shí)際的產(chǎn)品的則為軟件開發(fā)。[2]

當(dāng)你接受了其實(shí)“產(chǎn)品”、“設(shè)計(jì)”和“工程”僅僅是同一件事的不同方面這種觀點(diǎn)時(shí)，事情便都會(huì)進(jìn)展得更好?！狦reg Veen

將開發(fā)時(shí)間對業(yè)務(wù)的影響最小化

如果我們能夠很好地做到“理解他人”，那么軟件開發(fā)這項(xiàng)活動(dòng)就能穩(wěn)步推進(jìn)。在軟件開發(fā)過程中，我們會(huì)更加了解那些我們致力于解決的問題，所以我們可以開始設(shè)計(jì)更優(yōu)的解決方案，因而我們創(chuàng)造的軟件產(chǎn)品也需要有所改進(jìn)。為了實(shí)現(xiàn)此目標(biāo)，我們需要一支敏銳的開發(fā)團(tuán)隊(duì)、一支可以快速傳播價(jià)值并且迅速應(yīng)對變化的團(tuán)隊(duì)，這是軟件開發(fā)實(shí)踐中的核心目標(biāo)。正如 Dan North 指出：

“軟件開發(fā)的目標(biāo)是持續(xù)盡力降低軟件開發(fā)時(shí)間對于業(yè)務(wù)的影響?！薄狣an North[4]

所以，擁有一支敏銳的開發(fā)團(tuán)隊(duì)至關(guān)重要。但是如何能夠擁有一支敏銳的開發(fā)團(tuán)隊(duì)呢？你會(huì)：

將開發(fā)者像王一樣供奉？

給他們買超快的、昂貴的計(jì)算機(jī)？

把他們送到任意他們想要參加的瘋狂科技研討會(huì)？

我們有很充分的理由做任何這種事：如果你想要維系你那支敏銳的開發(fā)團(tuán)隊(duì)，那么就要對團(tuán)隊(duì)中的每個(gè)人都認(rèn)真上心。運(yùn)行快的計(jì)算機(jī)和優(yōu)良的科技研討會(huì)使開發(fā)者表現(xiàn)得更好，這種對開發(fā)者的投資總有一天會(huì)得到回報(bào)。但是這種投資對留住優(yōu)秀的開發(fā)者更有用，而我們想要組建的是一支敏銳的開發(fā)團(tuán)隊(duì)。

所以如果不給開發(fā)者提供他們所想要的，那么我們該做什么呢？簡單的答案是，去問開發(fā)者。但是，請?jiān)诤线m的時(shí)間，用合適的方式問他們。我們需要理解的一點(diǎn)是，開發(fā)者往往是天生的問題解決者。優(yōu)秀的開發(fā)者熱愛他們的工作，熱愛的原因是他們整天能解決有趣的、復(fù)雜的難題，并且能夠因此而掙錢。優(yōu)秀的開發(fā)者陶醉于迎接復(fù)雜的挑戰(zhàn)并且找到簡約漂亮的解決方法。所以他們應(yīng)該能想出精彩的點(diǎn)子以變得更加敏銳。但是許多組織鼓勵(lì)開發(fā)者專注于錯(cuò)誤的問題，這種鼓勵(lì)可能既不是深思熟慮的也不是有意而為之，但是卻時(shí)常發(fā)生。

專注于錯(cuò)誤的問題

這是怎么發(fā)生的？我們怎么可能甚至不知道自己在做錯(cuò)事，以至于最后讓開發(fā)者專注于錯(cuò)誤的問題呢？因?yàn)槲覀儗㈤_發(fā)者從消費(fèi)者身邊拉開。一個(gè)項(xiàng)目一有任何合理的規(guī)模，我們就會(huì)找來項(xiàng)目經(jīng)理和業(yè)務(wù)分析師。[5] 我們拉來這些人是出于一個(gè)非常好的理由——開發(fā)者無法完成所有的事。軟件項(xiàng)目是復(fù)雜的，代碼已經(jīng)夠復(fù)雜了，但是另外更重要的是，還有各種工作諸如決定構(gòu)建的內(nèi)容、規(guī)劃開發(fā)的階段、制定推廣部署的計(jì)劃、聯(lián)絡(luò)客戶……不一而足。代碼已經(jīng)夠讓開發(fā)者操心了，所以我們需要這些額外人員來幫忙。

但是，這樣做使得這些額外人員成為了開發(fā)者面向世界的接口。與外部持股者進(jìn)行協(xié)調(diào)溝通的是項(xiàng)目經(jīng)理和業(yè)務(wù)分析師，尤其是項(xiàng)目經(jīng)理非常在意項(xiàng)目的交付。項(xiàng)目經(jīng)理向管理部門匯報(bào)情況，管理部門關(guān)心的是：

項(xiàng)目需要耗費(fèi)多少資金？

項(xiàng)目需要進(jìn)行多長時(shí)間？

為什么項(xiàng)目需花費(fèi)這么多資金？

為什么項(xiàng)目拖延到這么晚？

為什么項(xiàng)目還沒有完成？

我的天哪，這個(gè)項(xiàng)目拖到這么晚每天需要燒我們多少錢？

于是我們可以理解為什么之后項(xiàng)目經(jīng)理開始變得專注于預(yù)測項(xiàng)目了。他們想要計(jì)劃、結(jié)構(gòu)、評估，他們想要知道什么時(shí)候在發(fā)生什么事。當(dāng)他們向管理部門匯報(bào)的時(shí)候，所做的預(yù)測和估量會(huì)讓他們顯得更稱職，所以他們才會(huì)向開發(fā)者探討預(yù)估、報(bào)告和截止日期。所以之后，開發(fā)者開始專注于預(yù)估、報(bào)告和截止日期，他們將精力集中在這些預(yù)估和預(yù)測性上來讓取悅項(xiàng)目經(jīng)理。

但是這樣做有一點(diǎn)不如人意的是，預(yù)估和預(yù)測性都是不可能解決的問題。每次一個(gè)開發(fā)者開始著手一個(gè)新任務(wù)時(shí)，他們就面臨一個(gè)不安的事實(shí)：任何一個(gè)給定的任務(wù)背后都可能有一個(gè)潛在復(fù)雜性的大坑，也可能沒有。我們都希望任務(wù)是簡單的，但是它有可能并不簡單，你永遠(yuǎn)都不會(huì)知道。這時(shí)霍夫史達(dá)特定律就起作用了：

霍夫史達(dá)特定律：事情總是要比你預(yù)期的花費(fèi)更長的時(shí)間，甚至當(dāng)你把本定律考慮在內(nèi)時(shí)也一樣。——Douglas Hofstadter[6]

考慮這種情況：

一個(gè)項(xiàng)目經(jīng)理向一個(gè)沒經(jīng)驗(yàn)的開發(fā)者問項(xiàng)目的估算，這個(gè)沒經(jīng)驗(yàn)的開發(fā)者告訴了一個(gè)他們認(rèn)為合理的估算，然后項(xiàng)目經(jīng)理回去根據(jù)估算情況得出截止日期和相應(yīng)的計(jì)劃。優(yōu)秀的項(xiàng)目經(jīng)理為穩(wěn)妥起見，甚而會(huì)在此基礎(chǔ)上加上一點(diǎn)“富余”。但是之后不可避免的事情發(fā)生了——項(xiàng)目落后了。所以開發(fā)人員開始為趕在截止日期到來之前完成任務(wù)，開始加班加點(diǎn)地工作。但是長時(shí)間的工作使得開發(fā)人員疲憊不堪，他們便開始犯更多的錯(cuò)誤。而且不僅如此，項(xiàng)目仍然在落后。項(xiàng)目經(jīng)理需要知道到底是什么耗費(fèi)了這么長時(shí)間，所以苦惱的開發(fā)者圖省事，開始投機(jī)取巧偷工減料，這一過程中，程序漏洞源源不斷地出現(xiàn)，所以此時(shí)產(chǎn)品不僅延遲了，而且漏洞頻出。

這種情況傳達(dá)了一種消極的客戶價(jià)值。當(dāng)然這種延遲的、漏洞頻出的產(chǎn)品可能仍然能夠解決某種程度的客戶痛苦，但是這些漏洞帶來了新的痛苦，這又需要耗費(fèi)時(shí)間來進(jìn)行修復(fù)，這樣客戶就會(huì)對我們可以幫助他們的能力喪失信心，這使得他們更不想為我們付錢，到頭來無人從中獲益。

經(jīng)驗(yàn)豐富的開發(fā)者知道這種估算是不公平的，所以他們盡其所能不蹚這灘渾水。

想象一下，

一個(gè)項(xiàng)目經(jīng)理來找有經(jīng)驗(yàn)的開發(fā)人員問預(yù)算，開發(fā)人員便會(huì)回復(fù)他一個(gè)大到離譜的數(shù)據(jù)，但同時(shí)又小到使這個(gè)項(xiàng)目還不能立馬被取消。接下來，項(xiàng)目經(jīng)理（銷售人員）回頭開始質(zhì)疑這個(gè)荒謬的數(shù)據(jù)：“那個(gè)預(yù)算看上去比我們希望的多一點(diǎn)，我們有沒有可能縮減一下，讓預(yù)算少點(diǎn)？”這時(shí)，有經(jīng)驗(yàn)的開發(fā)者便會(huì)問：“我們著手需要的預(yù)算是多少？”銷售人員回復(fù)他一個(gè)數(shù)，然后有經(jīng)驗(yàn)的開發(fā)者揉揉她的下巴說：“預(yù)算有點(diǎn)緊，但是我們會(huì)盡量做。這樣的話我們難以滿足所有要求，只能提供最基本的性能?！比缓笏龝?huì)在自己看上去不會(huì)不稱職的前提下，預(yù)估他們可以承諾交付的是多么有限，并且這是她可以承諾的所有。這樣的話，如果她最后交付的比自己先前承諾的更多，那么每個(gè)人都很開心。但是甚至在這個(gè)情況下，霍夫史達(dá)特定律還是會(huì)出現(xiàn)，過不了多久，我們就會(huì)像從前一樣，在趕最后期限、交付低質(zhì)量代碼的泥潭中苦苦掙扎。

預(yù)算是軟件開發(fā)過程中一項(xiàng)必不可少卻令人生厭的東西。不幸的是，人們往往以為編軟件就像建房子或修車一樣，承包商或參與的機(jī)修工在客戶審批工作前，應(yīng)該能很好地對要完成的工作提供一個(gè)可靠的預(yù)算。[……]然而對于定制軟件，很多系統(tǒng)都是從零開始搭建，而且通常組裝、最終運(yùn)行、應(yīng)實(shí)現(xiàn)的功能、完成的時(shí)間等等都在隨時(shí)發(fā)生變動(dòng)，因此在工作之初，你要選的方法和最終達(dá)成的效果都是不確定的，所以很難知道到底什么時(shí)候可以完成。——Steve Smith[7]

我這兒的觀點(diǎn)不是說要抱怨軟件預(yù)算，大家都知道它雖然令人生厭但又十分必要，就怪這種軟件預(yù)算會(huì)陷入一種惡性循環(huán)。為了趕截止日期，我們投機(jī)取巧偷工減料，交付低劣的代碼，還一直互相保證我們過后終將回頭將代碼進(jìn)行完善，但是“過后”再也不回來。如果我們回頭修復(fù)那些漏洞的話，我們就已經(jīng)在下一個(gè)階段中又落后了。所以我們構(gòu)建的一切都建立在脆弱的、雜亂一氣的代碼上，這些代碼難以應(yīng)對快速的變化。而且一旦困在這個(gè)循環(huán)中，那么開發(fā)者的注意力將難以繼續(xù)集中在解決客能戶痛苦上，相反，他們將會(huì)專注于諸如以下的問題上：

有什么可能的方式能使我們最快地將任務(wù)標(biāo)為“已做”并且讓項(xiàng)目經(jīng)理不要再煩我？

我怎樣才能盡可能少接觸脆弱的代碼呢？因?yàn)檫@些代碼我接觸得越多，它們崩潰的可能性越大。

我怎樣才能在這筆巨大而過火的技術(shù)債務(wù)中，竭力維持讓我引以為豪的那一小塊代碼呢？

我怎樣才能向那些不知道我在干什么，或者不知道問題的復(fù)雜性的人們證明我的決定是對的呢？

當(dāng)客戶開始抱怨那些我沒有時(shí)間修復(fù)的軟件漏洞時(shí)，我怎樣才能將責(zé)任推到其他人身上呢？

我怎樣才能在我的簡歷中加入一些流行語，幫我另找一份不這樣混亂不堪的工作？

我沒見過有開發(fā)者想要交付一份延遲的、滿是漏洞的軟件，但是我們因?yàn)橄胍麄兯俣确趴欤越o開發(fā)者不斷施壓。他們?yōu)榱巳偽覀円泊饝?yīng)照辦，但是由于預(yù)估往往是錯(cuò)誤的，所以導(dǎo)致他們深陷泥潭，在重壓之下交付軟件。他們?yōu)榱巳偽覀儯影嗉狱c(diǎn)工作，但又在軟件開發(fā)中偷工減料。因?yàn)榇蠹乙恢痹诖邌査麄儭巴瓿闪藛?？”使得他們在軟件質(zhì)量上做出妥協(xié)。最終沒有人開心，軟件仍然拖延，仍然滿是漏洞。

所以我知道的大多數(shù)開發(fā)者都在工作中盡其所能，但卻深陷困境。他們?yōu)榱粟s進(jìn)度忙得焦頭爛額，甚至連怎么變得“更快”都顧不上想。因此他們把精力集中在了錯(cuò)誤的問題上，他們重點(diǎn)關(guān)注的是如何讓自己活下來。好比當(dāng)你餓得快要死了的時(shí)候，你很難再去關(guān)注為退休攢錢的事兒了。也好比當(dāng)你因?yàn)橐粋€(gè)延遲的項(xiàng)目一周連續(xù)工作七天后，你很難再去計(jì)劃怎樣才能做得更巧。所以第一步應(yīng)該承認(rèn)，想要項(xiàng)目做得更快就需要投資，而且如果事情進(jìn)展不順，那么也同時(shí)需要時(shí)間/財(cái)政投資和情感投資兩項(xiàng)。

打破這種惡性循環(huán)

之前，我建議去問問開發(fā)者怎樣才能減少軟件開發(fā)時(shí)間對業(yè)務(wù)的影響，但是當(dāng)開發(fā)者處于“趕進(jìn)度”模式時(shí)，我們不可能得到從他們那兒得到很好的回復(fù)。當(dāng)我們進(jìn)入這種環(huán)境問道：“我們怎樣才能開發(fā)得更快？”可能會(huì)得到兩種回復(fù)中的一種：

1. 用火燒了它。

“我們需要出走兩年，然后重頭再來?！边@種情況通常在開發(fā)者已經(jīng)被技術(shù)債務(wù)徹底壓垮時(shí)發(fā)生。技術(shù)債務(wù)太繁重了，所以他們感覺唯一的出路就是宣告破產(chǎn)。他們這樣做可能也有一定的道理，但與此同時(shí)，我們可能并沒有相應(yīng)的預(yù)算作為支撐，而且當(dāng)我們過后重建的時(shí)候市場必然不會(huì)一成不變。

2. 憤慨。

“我們已經(jīng)開發(fā)地更快了，我不敢相信你竟然覺得你只用半個(gè)小時(shí)的頭腦風(fēng)暴就能修復(fù)這個(gè)復(fù)雜的問題！你怎么敢？！”這種情況通常在開發(fā)者覺得自己被迫發(fā)行低質(zhì)量代碼時(shí)發(fā)生。他們感覺當(dāng)客戶抱怨漏洞時(shí)，自己受到了客戶的譴責(zé)。而且他們的憤慨很可能是有一定理由的。開發(fā)者懷著這種心態(tài)是不會(huì)幫我們的，除非我們可以向他們表達(dá)我們聽到了他們的心聲。他們需要知道我們理解他們的顧慮，我們同樣也需要表明我們正在嚴(yán)肅地考慮做一些改變。

在以上兩種情況中，開發(fā)者的顧慮是正當(dāng)?shù)?，但他們只關(guān)注了自己。我們希望創(chuàng)造一種每個(gè)人都為將軟件開發(fā)時(shí)間對業(yè)務(wù)的影響降到最低而努力的環(huán)境。如果開發(fā)者不能擺脫這種心態(tài)的話將難以達(dá)成以上愿景。一切策略開始的前提是，向他們表明我們正在嚴(yán)肅地考慮做一些改變，這通常包括尋找減壓的方式，即使那只是暫時(shí)的。

但是即使這樣，開發(fā)者仍然只會(huì)關(guān)注自己，除非再做一些改變。他們關(guān)于如何提升自己的工作成效會(huì)有大量的主意，其中一些想法可能很不錯(cuò)，但是有風(fēng)險(xiǎn)。我們需要讓開發(fā)者轉(zhuǎn)移對自身壓力的關(guān)注，而將注意力集中在將軟件開發(fā)時(shí)間對業(yè)務(wù)的影響降到最低上。我們需要讓他們直面客戶痛苦。

使開發(fā)者直面客戶痛苦

我們接下來該如何使開發(fā)者直面客戶痛苦呢？不計(jì)其數(shù)的人已經(jīng)對此寫過詳盡的文章，所以這里我只是輕描淡寫一下。這兒按照從最低效到最高效的順序有三條觀點(diǎn)：

1.讓開發(fā)者將使用自己制造的產(chǎn)品作為他們?nèi)粘９ぷ鞯囊徊糠帧?/p>

這在業(yè)界被稱為喝自己的香檳，或吃自己的狗糧。這樣做的好處是使開發(fā)者變成了產(chǎn)品的用戶，所以任何明顯的錯(cuò)誤或問題也會(huì)令開發(fā)者自己感到煩惱。這種方法存在一個(gè)問題，那就是開發(fā)者并不是典型的用戶（大多數(shù)時(shí)候）。開發(fā)者使用軟件的方式通常有別于大多數(shù)的客戶，所以盡管這樣可以幫開發(fā)者修復(fù)主要的漏洞，但是可能無法為典型的使用案例提供很好的見解，而且這也并非一直具有實(shí)踐性。比如說，假想我們正在為牙科保健員生產(chǎn)一個(gè)SaaS產(chǎn)品，這時(shí)開發(fā)者可能很難將這SaaS產(chǎn)品融入他們的工作流。

2. 讓開發(fā)者在支持團(tuán)隊(duì)中輪班工作。

一個(gè)更佳的方式是鼓勵(lì)開發(fā)者參與到一些產(chǎn)品的支持團(tuán)隊(duì)中去。（他們可能需要極強(qiáng)的鼓勵(lì)。）這張方式可以讓開發(fā)者親自體驗(yàn)客戶痛苦。所以，他們接電話或收郵件（或推特，或其他種種）時(shí)，客戶告訴他們問題所在。開發(fā)者做這件事長達(dá)一定時(shí)間后，他們也將會(huì)開始發(fā)現(xiàn)常見問題的規(guī)律，他們會(huì)注意到一次次涌現(xiàn)的問題。無需重復(fù)聽那些相同的牢騷會(huì)成為修復(fù)軟件可用性問題的一大動(dòng)力。不幸的是，人們幾乎不會(huì)聯(lián)系支持部門告訴他們產(chǎn)品運(yùn)行得多么棒，所以得到的反饋是有點(diǎn)偏見的。

3. 定期讓開發(fā)者坐在用戶身邊，看他們是如何使用軟件的。

這種方法是最不方便的，因?yàn)樗枰疃嗟慕M織進(jìn)行協(xié)調(diào)，但這也可能收獲最好的結(jié)果。利用這種方法，開發(fā)者可以得知正常人是如何在現(xiàn)實(shí)生活中使用軟件去做實(shí)在的事的。他們能看得到好的、壞的和丑的。

長期持續(xù)這樣做是一件辛苦的事，需要耗費(fèi)精力，需要進(jìn)行組織,而且大多數(shù)開發(fā)者會(huì)對此有一種本能的抵觸。我寫這個(gè)感覺有點(diǎn)笨拙，因?yàn)殡m然我理應(yīng)做這件事，但我并沒有經(jīng)常這樣做，但我相信值得付出努力做這件事。

使開發(fā)者直面客戶痛苦是一種用悉心努力克服認(rèn)知偏見的訓(xùn)練過程。這是一條“讓人學(xué)會(huì)謙卑”的漫漫長途。我們開發(fā)者往往認(rèn)為我們要更聰明，而且許多開發(fā)者還要更加聰明，但是我們并不是無所不知。也許我終于搞清楚了一元綁定運(yùn)算和操作組合的關(guān)系，這很好，但是這并不意味著我知道了我們客戶每天使用我們的軟件時(shí)會(huì)遇到什么。使開發(fā)者直面客戶痛苦提醒我們自己我們所真正了解的東西是多么有限。

在我的經(jīng)歷中，開發(fā)者越孤立于周遭，生產(chǎn)的最終產(chǎn)品越差。大多數(shù)團(tuán)隊(duì)層次中，有一層為業(yè)務(wù)分析師，他們認(rèn)為讓開發(fā)者免于接觸用戶是他們的工作，反之亦然，其實(shí)這樣做是沒有用的。若創(chuàng)造了一個(gè)開發(fā)者對于用戶一無所知的環(huán)境，那么這種狀況是非常危險(xiǎn)的?！狫eff Atwood [9]

現(xiàn)在，所有這種面向客戶的溫情舉措非常模糊，都存在一個(gè)明顯的問題。簡單來說，這并沒有讓開發(fā)者的開發(fā)速度更快。事實(shí)上，這奪走了本應(yīng)該用來編程的時(shí)間，所以可以認(rèn)為這反倒使得開發(fā)速度變得更慢。所以我為什么認(rèn)為以上說法對呢？簡單來說就是如果你工作奮進(jìn)的方向是錯(cuò)誤的，那么開發(fā)速度的提升沒有絲毫意義。使開發(fā)者直面客戶痛苦重要的是方向而非速度。

咨詢開發(fā)者

我們想要可持續(xù)性地將軟件開發(fā)時(shí)間對業(yè)務(wù)的影響降到最低，我的假設(shè)是如果你為開發(fā)者指引了正確的方向，那么你可以在此基礎(chǔ)上咨詢他們接下來該如何做的意見。如果我們讓他們落實(shí)他們的意見，那么我們便應(yīng)該能看到結(jié)果。

理想地來說，這是一個(gè)持續(xù)推進(jìn)的過程。我們問開發(fā)者他們是否有任何能夠加快軟件開發(fā)速度的方法，然后我們對提供的方法進(jìn)行試驗(yàn)，幾周之后再回來，打聽進(jìn)展?fàn)顩r，繼而再去問開發(fā)者加速的方法。就這樣一直問他們，直到你每次你連問都不用問就可以直接進(jìn)入他們的工作區(qū)域。他們于是開始這樣說：“我們所做的路由引擎的重構(gòu)真的成果不錯(cuò)。但是我覺得如果我們把那種邏輯的一部分移出來，放入微服務(wù)層，那么我們就可以更快地進(jìn)行縫補(bǔ)和撕毀?！蹦憧赡懿⒉恢滥且馕吨裁?，但是如果我們看到漏洞減少、客戶更加滿意，那么大家就都成為了贏家。

具體到你自己的團(tuán)隊(duì)，用什么樣的方式詢問他們?nèi)Q于你自己。有些人喜歡頭腦風(fēng)暴研討會(huì)，另一些人更傾向于調(diào)研或一對一專訪。每種方法都有其不同的優(yōu)缺點(diǎn)，但是無論你選擇哪種方法，請確保弄清了限制。如果你僅有一筆很小的預(yù)算，要明說。如果沒有靈活延長任何截止期限的余度，請告訴開發(fā)者。假設(shè)你擁有聰明的、能干的開發(fā)者，他們能夠把以上這些都考慮在內(nèi)。而且如果他們沒搞明白，甚至在你多次解釋說明后仍不明白，那么你也從中學(xué)到了點(diǎn)東西……

務(wù)必在探討限制時(shí)小心謹(jǐn)慎。如果你告訴開發(fā)者沒有預(yù)算、截止期限是定死的、沒有一丁點(diǎn)回旋的余地……那么他們無疑將回復(fù)你他們無力幫助，這種情況下你應(yīng)該格外小心。高質(zhì)量軟件若想要提高生產(chǎn)速度，就需要花費(fèi)金錢。開發(fā)者需要知道我們愿意為他們和他們的工具投資。如果沒有預(yù)算、沒有延長截止期限的余地、沒有情況好轉(zhuǎn)的跡象……那么聰明的開發(fā)者就會(huì)去考察其他方面，這種做法讓我喝彩。這是一種沒有勝方的局面，這種局面會(huì)吸引情感投資。向開發(fā)者展示我們在乎、并且愿意向他們和他們的未來投資,向他們解釋我們目前正處于資源嚴(yán)重受限的困境，這樣他們便可能會(huì)愿意想一些創(chuàng)造性的解決方案幫我們掙脫當(dāng)前困境。

假設(shè)

我在這兒要做一個(gè)較大的假設(shè)，我假設(shè)當(dāng)你向你的開發(fā)者解釋限制時(shí)，他們都很聰明，完全能夠理解。最大最顯而易見的限制就是我們并沒有無窮無盡的金錢去揮霍。開發(fā)軟件很費(fèi)錢，遠(yuǎn)比大多數(shù)人預(yù)期的或意識(shí)到的要多得多。好的軟件開發(fā)者得花不少錢去請。我在這兒的假設(shè)是有至少有一個(gè)或兩個(gè)聰明的開發(fā)者可以能夠理解以上情況。

可悲的是一些開發(fā)者就是不理解，那么你該怎么做呢？答案并不簡單，但是我推測開發(fā)者不理解的原因是他們從來都沒有機(jī)會(huì)以更大的眼光去看待問題。他們只被要求做去做不現(xiàn)實(shí)的預(yù)算和加快開發(fā)速度，并沒有從客戶或那些付他們薪水的人的角度去考慮問題。唯一使他們開始理解的方式就是有人展示給他們看。

我要做的另一個(gè)大假設(shè)當(dāng)我們把開發(fā)者帶到委托人員面前時(shí)，我們相信他們不會(huì)讓公司難堪。當(dāng)然了，也有很多次我和委托人開會(huì)時(shí)，開發(fā)者說了蠢話或宣泄不滿的情況，畢竟并不是每個(gè)人都做好了站在幻燈片前展示推銷游說本領(lǐng)的準(zhǔn)備。但是如果我們相信一個(gè)開發(fā)者能夠僅禮貌地握握手打招呼，那么他們當(dāng)然至少也能做到坐在一角，靜靜地看人們使用軟件？[10]也許他們需要有人首先能帶帶他們。但是如果從來沒被給過機(jī)會(huì)，一個(gè)人還能以什么方式去學(xué)做一個(gè)組織優(yōu)秀的大使呢？

但是我離題了，咱們回到提升軟件開發(fā)速度上。

安全帶和引擎升級

咱么假設(shè)你的團(tuán)隊(duì)里全是聰明的開發(fā)者。當(dāng)你讓他們出主意時(shí)，他們可能首先想出許多聽上去是反直覺的東西，比如像：

測試驅(qū)動(dòng)開發(fā)（TDD）

持續(xù)集成

結(jié)對編程或mob編程

代碼審查

所有的這些技術(shù)都會(huì)降低開發(fā)速度……TDD很像是完成同樣的結(jié)果卻用了兩倍的代碼量，而結(jié)對編程就像利用了兩個(gè)高產(chǎn)的開發(fā)者卻將結(jié)果削減了一半。我能理解一些質(zhì)疑，但這不只是時(shí)髦的流行語（大多數(shù)的這些技術(shù)已應(yīng)用了幾十年之久），它們自然有存在的充分理由。

讓我試著用類比解釋一下：當(dāng)你開車時(shí)，你要系安全帶。近些天我們希望車能自帶安全氣囊和防撞緩沖區(qū)，但是當(dāng)你想開得真的很快時(shí)，你要戴賽車安全帶、頭盔和防火服，我們還會(huì)將翻滾護(hù)架、氣流偏導(dǎo)器和粘型輪胎加到車上。這個(gè)類比不完美，但是希望你能明白我想表達(dá)什么。首先，一些諸如TDD和代碼檢查的方式會(huì)使你開發(fā)速度變慢，他們會(huì)變得笨拙，不易習(xí)慣。但正是這些保障團(tuán)隊(duì)更加安全地加速進(jìn)展。

我們非常確信當(dāng)維護(hù)費(fèi)用——許多時(shí)間和金錢考慮在內(nèi)時(shí)，TDD節(jié)省了時(shí)間和金錢?！狤ric Elliott[11]

像TDD和持續(xù)集成這樣的技術(shù)是關(guān)于提升軟件質(zhì)量的，這意味著生產(chǎn)中會(huì)產(chǎn)生更少的漏洞。在漏洞流出前將其捕獲意味著會(huì)減少重做的次數(shù)、減少尷尬、更愉悅客戶。問題通常會(huì)被更快（耗資更少）得被修復(fù)。隨著時(shí)間流逝，不耗費(fèi)在修復(fù)漏洞上的時(shí)間增加。另外，這些技術(shù)支撐下寫出的代碼往往更為靈活，更易改變或再用。這意味著我們可以花費(fèi)更少的時(shí)間去對抗脆弱的代碼庫，能花費(fèi)更多的時(shí)間去添加新的特征或修改功能。最終結(jié)果是軟件更好，開發(fā)速度更快。

加緊反饋環(huán)

這樣的要點(diǎn)是減少從寫代碼到交付客戶所經(jīng)歷的時(shí)間。這樣的話，開發(fā)者可以觀測到新的代碼是如何減少客戶痛苦的。掌握了客戶反饋，那么他們可以進(jìn)一步提升代碼等等，這樣我們就創(chuàng)造了一個(gè)良性循環(huán)。

我們的轉(zhuǎn)變就是從真實(shí)用戶那兒獲得反饋的時(shí)間大大減少。——Phil Wills[12]

如果你在過去幾年一直在追隨IT發(fā)展趨勢，那么對良性循環(huán)一定很熟悉。良性循環(huán)聽上去很像持續(xù)交付，但是這種流行語并不是重點(diǎn)。持續(xù)交付只是一套實(shí)踐的標(biāo)簽而已。而且，這些實(shí)踐能夠提供緊湊的反饋環(huán)，反饋環(huán)能夠使得我們在提升速度的同時(shí)減少風(fēng)險(xiǎn)。

這樣做有一個(gè)很好的理由。我們所建立軟件的環(huán)境不僅麻煩而且復(fù)雜，一個(gè)麻煩的系統(tǒng)有許多部分，實(shí)則讓一個(gè)專家都要好好理解這么多的部分是如何結(jié)合在一起的。但是一個(gè)復(fù)雜的系統(tǒng)不僅僅有許多部分，而且所有的部分都彼此連接，相互作用。所以，當(dāng)你改變了一小部分后，那么整個(gè)系統(tǒng)可能都會(huì)因而發(fā)生變化。一個(gè)經(jīng)典的案例就是眼鏡蛇效應(yīng)：

英國政府對德里的有毒眼鏡蛇數(shù)量非常擔(dān)憂，因此每捕殺一條眼鏡蛇，政府就會(huì)發(fā)放一筆賞金。起初這是一個(gè)非常成功的策略，因?yàn)楹芏嗳藶榱速p金開始大量捕殺眼鏡蛇。然而最終，激進(jìn)大膽的人為了收益反而開始專門飼養(yǎng)眼鏡蛇。當(dāng)政府意識(shí)到這種情況后，這一獎(jiǎng)勵(lì)計(jì)劃便被取消了，眼鏡蛇再無價(jià)值，于是導(dǎo)致飼養(yǎng)眼鏡蛇的人只好將其放生，所以野生眼鏡蛇的數(shù)量進(jìn)一步增多。[13]

在復(fù)雜的系統(tǒng)中，很難預(yù)測一次給定改變所可能產(chǎn)生的影響，這是因?yàn)樽鰞纱蜗嗤母淖兛赡墚a(chǎn)生截然不同的結(jié)果，第一次改變能引起一定的系統(tǒng)反應(yīng)，在下一次中會(huì)完全不同。這樣會(huì)導(dǎo)致非本意的結(jié)果，使計(jì)劃和預(yù)估出現(xiàn)問題。

理解復(fù)雜性的方式是，在空間中的動(dòng)作會(huì)導(dǎo)致空間發(fā)生變化，而且原因和結(jié)果只有在回顧時(shí)才能被理解?！狶iz Keogh[14]

那么我們在一個(gè)復(fù)雜的環(huán)境中如何設(shè)法去完成每件事？專家建議“探索、感知并且回應(yīng)。”換句話說，創(chuàng)造緊湊的反饋環(huán)去評估哪些事能成或不能成。然后我們盡快重復(fù)此動(dòng)作，保持小變化、短周期。因此，與失敗關(guān)聯(lián)的風(fēng)險(xiǎn)也控制到很小，恢復(fù)的成本也更低。我們要做很多小實(shí)驗(yàn)，保留工作正常的，恢復(fù)工作失敗的。

在一個(gè)復(fù)雜的環(huán)境中，你探索、感知并且回應(yīng)，你做一些可能失敗的小風(fēng)險(xiǎn)的事，這會(huì)幫助你對你所應(yīng)對的環(huán)境有所了解，這是高反饋、風(fēng)險(xiǎn)和創(chuàng)新的沃土?！狶iz Keogh[15]

結(jié)論

我們不能僅靠“最佳實(shí)踐”建立一支高水平開發(fā)團(tuán)隊(duì)。不幸的是，軟件開發(fā)中幾乎沒有捷徑，但是當(dāng)我們能夠謙卑地承認(rèn)我們并非無所不知時(shí)，總能利用一些方式能干得很好。

讓開發(fā)者直面客戶痛苦縮小了反饋環(huán)，這使得我們確信如果我們加快開發(fā)速度，那么我們一定在正確的方向上加快速度。一旦達(dá)成了這一點(diǎn)，我們便能夠以一種適應(yīng)給定情況的方式進(jìn)行持續(xù)的改進(jìn)了。