為什么大部分軟件工程師脾氣都很暴躁

前不久，Jenna Bilotta［譯注1］寫了篇很棒的文章叫做《設(shè)計(jì)師和工程師怎樣才能默契地工作》［譯注2］。在文章中她說到了設(shè)計(jì)師和工程師更加富有成效地工作的方法。面對相同的和設(shè)計(jì)師一起工作的挑戰(zhàn)（及當(dāng)我作為UI角色和工程師一起工作的挑戰(zhàn)），我贊賞她建議的那些實(shí)際方法。尊重其他角色起到的作用以及明白他們工作時(shí)的想法總是有好處的。

其中有一個她對工程師的建議是不要過快地說“不”。這困擾了我很久，并一直在我腦海中揮之不去。我的第一反應(yīng)是：“但你們不明白為什么我們會說‘不’！”，隨后產(chǎn)生了成千上萬的自我防衛(wèi)想法。當(dāng)然她是對的，我們的確非?？斓卣f“不”，不僅僅是對設(shè)計(jì)，對所有的一切都會這么說。這使我開始思考軟件工程師的心理以及是什么導(dǎo)致我們變成現(xiàn)在這樣的。

譯注1：Jenna Bilotta，Google產(chǎn)品體驗(yàn)設(shè)計(jì)師和自由顧問。設(shè)計(jì)過YouTube和Google Reader等產(chǎn)品。

譯注2：本文相當(dāng)精彩，推薦給所有的設(shè)計(jì)師和工程師們。

我們的名聲

坦白講，軟件工程師一般都因傲慢自大、難以相處以及喜怒無常而著稱。我們也因在辯論賣弄學(xué)問的細(xì)節(jié)時(shí)說“不”而出名，并且認(rèn)為自己知道怎樣把每個人的工作做得更好?？傊@種名聲是應(yīng)得的。這正是我們天天在做的：一邊寫代碼，一邊上Twitter和Hacker News。

（邊注：有些人會說這對所有的工程師來說是不正確的，你說對了。對于在工程師中的一小部人來說，上面的某個或者所有的觀點(diǎn)對于他們來說都是不正確的。在滾動到底部留言告訴我這篇文章讓你有多無語時(shí)，請繼續(xù)讀下去。）

名聲不是隨便就能獲得的，名聲是靠經(jīng)驗(yàn)掙得的。名聲這東西困擾我的是，就我自身認(rèn)識的一些工程師來說，一般他們都是喜歡娛樂的、和藹可親的（如果不是固執(zhí)己見的話）且令人愉快的群體。他們是你在工作之余想一起出去玩的及在周末想追隨的人。那么為什么在工作面前，另外一個不同的性格就會出現(xiàn)了呢？

創(chuàng)造者，不是建造者

我有一個推理。這個推理是軟件工程師把自己和與之一起工作的人看成是非常不同的群體。

我在軟件行業(yè)的大公司和小公司工作了十多年后得出了這個結(jié)論。公司（產(chǎn)品經(jīng)理、設(shè)計(jì)師及其他管理者）往往把軟件工程師當(dāng)作建造者。產(chǎn)品經(jīng)理的工作是夢想建造什么，設(shè)計(jì)師的工作是怎樣在審美上取悅別人，工程師的工作是建造他們想出來的東西?；旧希こ處煴豢醋鳛樵撔袠I(yè)的“臨時(shí)工”［譯注3］。

譯注3：英文原文是”short-order cooks”

我的第一個經(jīng)理告誡過我一些事情。在我的第一家公司快要倒閉的時(shí)候，他和我就我的職業(yè)生涯進(jìn)行了一場很坦白的探討。雖然我們有時(shí)相處得不好，但他給了我這個非常好的建議（大概的意思）：

“Nicholas，你比你的代碼有價(jià)值。不管你下份職業(yè)是什么，務(wù)必不要當(dāng)“臨時(shí)工”。不要接受那種會明確告訴你要建造什么和怎么建造的工作。你應(yīng)該在那種對產(chǎn)品有深刻理解并且也有能力來建造的地方工作?！?/p>

他是完全正確的。有很多的公司都想要“臨時(shí)工”，他們想要實(shí)現(xiàn)者和建造者按特定的節(jié)奏并要保持一條直線前進(jìn)。實(shí)際上，我會說幾乎所有的公司都想這樣，不管是大公司還是小公司。我無法告訴你有多少家創(chuàng)業(yè)公司聯(lián)系我，給我股權(quán)，作為交換的條件是幫創(chuàng)始人建造他們的愿景。這隱含的意思是：我們已經(jīng)想清楚了所有的東西，只需要某個人來建造它。

這里正是問題的癥結(jié)所在：軟件工程師不是建造者。軟件工程師是創(chuàng)造者。建造是你從宜家買了一件家具帶回家，說明書就擺在那兒，如果你按部就班地照著做，就能得到你想要的滑稽小桌子。創(chuàng)造是不同的過程，它在沒有指導(dǎo)和說明書的情況下會產(chǎn)生一些東西來。這就像是在一塊空白的畫布上繪一副杰作。軟件工程師不編碼是因?yàn)樗麄兿雱e人來告訴他要做什么，他們開始編碼了是因?yàn)樗麄儼l(fā)現(xiàn)了能夠創(chuàng)建一些有用的東西。每個軟件工程師都是因?yàn)樵缦茸隽艘粋€有用的小程序而愛上編碼，從此便迷上了。

在軟件的三個統(tǒng)治角色中（即產(chǎn)品經(jīng)理、設(shè)計(jì)師及軟件工程師），只有工程師是被期待不用創(chuàng)造的，只管生產(chǎn)。軟件工程師不是傻瓜，他們看到發(fā)生了什么，會開始“創(chuàng)造”不滿（沒有雙關(guān)語義）。工程師想成為創(chuàng)造過程的一部分，但被拒之門外。因此最終有了典型的軟件工程師的性格叫做暴躁。

等等，出了什么問題？

產(chǎn)品經(jīng)理是很有趣的人。他們的想法和了解市場的能力令人欽佩。他們也有一種傾向，認(rèn)為他們的想法是完整的，其實(shí)，那漏洞大得火車都能通過了。我是友好地說的，我有幾個要好的朋友是產(chǎn)品經(jīng)理，大家都知道我曾經(jīng)當(dāng)著你的面說過這種話。這絕對不是對產(chǎn)品經(jīng)理的批評，這是他們的本性使然。他們的工作是一種創(chuàng)造性的，呈現(xiàn)的想法是不完整的。這是使軟件工程師脾氣變得暴躁的一部分原因。

工程師和產(chǎn)品經(jīng)理都趨向于認(rèn)為，產(chǎn)品規(guī)范或需求就相當(dāng)于宜家的家具使用說明書，這是不對的。在現(xiàn)實(shí)中，這些文檔很少包含足夠的信息來建造實(shí)際的東西。他們通常只是工程的起點(diǎn)，這給工程師提出了一個獨(dú)特的問題。

要理解這個問題，考慮造房子的工作。有人已經(jīng)決定希望在某塊土地上造一所房子。房子有二層和一個車庫。甚至還有一張餐巾紙，上面畫著房子的正面草圖。那人帶給你這個信息和餐巾紙，說“這足以讓你開始造了吧，對不對？”那你是否能夠開始造呢？

從邏輯上講，這時(shí)你還不能開始造房子。你不知道房子的建筑面積。你沒有房子的平面圖。你不知道城市對新房屋的要求規(guī)范。從字面上看是沒有足夠的甚至可以開始挖土的信息。此時(shí)，你會告訴你的客戶，他們是瘋狂的，必須要弄清楚自己想要什么?，F(xiàn)在假設(shè)你不能這樣做，因?yàn)槟橙艘呀?jīng)設(shè)定了Deadline，于是你負(fù)責(zé)召開會議。

“嗯，”你的客戶告訴你，“為什么你不先開始造呢，當(dāng)我想到細(xì)節(jié)部分時(shí)我會告訴你的。這樣一來，我們沒有浪費(fèi)任何時(shí)間?！?/p>

你知道，沒有足夠的信息能讓你開始造，并且現(xiàn)在進(jìn)一步質(zhì)疑客戶也不會得到任何別的信息。然而，你要趕Deadline，坐在那里等更多的信息你是受不了的。你會做什么？你開始假設(shè)了。

俗話說得好，“當(dāng)你假設(shè)時(shí)，就把你和我都當(dāng)成驢了”，大概再如此正確不過了。假設(shè)是危險(xiǎn)的，而且往往是錯誤的。然而，如果沒有做一些假設(shè)，項(xiàng)目就無法向前推進(jìn)。這就是你所做的。你假設(shè)你已經(jīng)知道的信息是對的：房子有兩層樓和一個車庫。車庫，它應(yīng)該是附著式的或分離式的？它應(yīng)該是多大？好吧，簡單起見，它和房子是分開的，并只能停一輛車。這意味著你可以先開始造車庫，作為一個房子旁邊的獨(dú)立建筑物，當(dāng)有關(guān)于房子的更多細(xì)節(jié)時(shí)，你可以繼續(xù)建造一旁的車庫而不受影響。

車庫造了一周后，你的客戶想到了更多的細(xì)節(jié)。事實(shí)上，房子有三層和八間浴室（唷，真幸運(yùn)，還沒有開始造房子）。沒有車庫的進(jìn)一步信息，但房子要被漆成藍(lán)色。然后，你從邏輯上假設(shè)，車庫也應(yīng)該被漆成藍(lán)色，所以未來的一段時(shí)間你都花在這上面了。

幾天后，車庫差不多造好了。你對建造的質(zhì)量相當(dāng)滿意，因?yàn)橹挥羞@么少的信息你就造出來了。你現(xiàn)在開始準(zhǔn)備造房子了，就在這時(shí)，你的客戶回來告訴你更多的細(xì)節(jié)。車庫實(shí)際上需要能停下兩輛汽車并且不是分離式的。你感到很沮喪，因?yàn)槟阍炝艘患脰|西，現(xiàn)在需要用推土機(jī)推平掉，為“真實(shí)”的東西讓道。更糟糕的是，你現(xiàn)在只有更少的時(shí)間來完成整個工種了，這只能增加暴躁的級別。

如果這個比喻對你來說近乎瘋狂，你可能永遠(yuǎn)沒做過作為一個軟件工程師的工作。這是我們現(xiàn)實(shí)生活的每一天都會發(fā)生的。我們試圖通過我們的創(chuàng)造力來推進(jìn)項(xiàng)目，最終發(fā)現(xiàn)事實(shí)上我們不能讀懂任何人的想法，因此錯誤地猜測真正要建造的東西。然而，如果我們不做假設(shè)，就會坐在那里無所事事，因?yàn)闆]有人喜歡瀑布流方式的軟件開發(fā)過程。

除了軟件行業(yè)，幾乎所有其他行業(yè)建造東西，預(yù)期的所有需求和細(xì)節(jié)在建造開始前都已商定并最終確定。在軟件行業(yè)，“沒有足夠的時(shí)間”提前收集所有的需求。從第一天開始“快速推進(jìn)的重要性”就已深深地釘在了我們的心中。所以工程師學(xué)著去填充產(chǎn)品經(jīng)理留下的空白，僅僅是為了保持項(xiàng)目能夠向前推進(jìn)。當(dāng)然，產(chǎn)品經(jīng)理也因經(jīng)常改變主意而著稱，這意味著工程師的假設(shè)在項(xiàng)目推進(jìn)過程的中途往往會失效。

那么，軟件工程師們常常會很快失去工作的熱情并頻繁跳槽，這還用懷疑嗎？

第一優(yōu)先級

上下文切換［譯注5］是任何創(chuàng)造者的敵人。一旦你沉湎于創(chuàng)造模式（有人稱之為“流”）里，把注意力轉(zhuǎn)移到別的東西上面就會使你焦慮不安，當(dāng)前的過程也被完全中斷。編碼是一個創(chuàng)造性的過程。它同時(shí)是邏輯性的和創(chuàng)造性的。我們不僅僅是在編碼，我們是在精心地設(shè)計(jì)代碼。

譯注4：英文原文是”context switching”

在管理工程師時(shí)間的人當(dāng)中，好像認(rèn)為工程師很容易從一個任務(wù)轉(zhuǎn)移到下一個任務(wù)。就像有些人告訴我的，工作畢竟就是工作。你就直接指揮他去需要去的地方，就像指揮發(fā)射大炮一樣。當(dāng)然這根本就是不對的。如果你在一個任務(wù)上花費(fèi)了大量的時(shí)間，然后被要求放下它去做其他的任務(wù)，你就不能很容易地再回到首次的任務(wù)，并從離開時(shí)丟下的地方重新拾起來。在你再回過頭時(shí)要確保明白所有的狀況，這有一個重新適應(yīng)的過程，這是上下文切換的代價(jià)。即使新的任務(wù)只需要幾分鐘即可完成，這足以把“流”中斷，從而使工程師生產(chǎn)力低效。

這是讓工程師脾氣變得暴躁的最主要的原因之一：不斷改變?nèi)蝿?wù)的優(yōu)先級。如果第一天某個任務(wù)的優(yōu)先級最高，第二天別的任務(wù)優(yōu)先級最高，這意味著必然會發(fā)生上下文切換。富有創(chuàng)造性類型的工作是不想被打斷的，這是為什么工程師們能高興地持續(xù)編碼，直到早上凌晨才結(jié)束工作。把“流”中斷，會使我們的生產(chǎn)力低下。

真正的優(yōu)先級不會是臨時(shí)性的，它們是不變的。在我們上面的人頻繁改變他們的想法，這會非常令軟件工程師們沮喪。我們時(shí)刻準(zhǔn)備著投入到戰(zhàn)斗中去，只需給一個行軍的方向。但如果第一天你告訴我們是在造一所房子，第二天告訴我們是在造一輛汽車，你應(yīng)該預(yù)料到你的士兵會和你的意見不合。

工程師的不足

軟件工程師每天都被推入困境，但我們不是受害者，即使我們這些人會很夸張地傾向于表現(xiàn)為受害者。實(shí)際上我們脾氣暴躁的一部分原因來自于自身，由于某種原因深深扎根在大多數(shù)軟件工程師的心中。我們有一個很悲劇的不足之處，這個不足是我們高估了自己的知識和能力。

這個不足會以多種方式表現(xiàn)出來。最常發(fā)生的是時(shí)間估計(jì)。幾乎每一位我知道的工程師，會習(xí)慣性地低估完成一項(xiàng)或一系列任務(wù)需要花費(fèi)的時(shí)間。只有最出色的人能給出精準(zhǔn)的時(shí)間，并和實(shí)際情況相符，而其余的人有時(shí)會漏掉兩個或多個因素的一個。問題是軟件工程師作為創(chuàng)造者，無法預(yù)見他們會遇到的問題。

盡管許多工程師會抱怨產(chǎn)品經(jīng)理改變他們的想法，但幾乎沒有人會對他們的時(shí)間估計(jì)負(fù)責(zé)。沒有時(shí)間申請召開會議再過一遍需求并做出更改。Bugs？我們的代碼是完美的，從來沒有bug，所以我們并不需要擔(dān)心（終究QA還是會測出一些莫名其妙遺漏掉的問題，對吧？）。我們依賴的一些人會退出？沒關(guān)系，其他人會來補(bǔ)足這個空缺的。

所有這些原因加起來很快就會趕不上Deadline，但是在事情沒有及時(shí)完成的理由當(dāng)中，沒有一個比這更加危險(xiǎn)：沒把學(xué)習(xí)的時(shí)間算進(jìn)去。這又直接回到了我們的不足了。我們認(rèn)為已經(jīng)知道如何完成所分配的任務(wù)，但這經(jīng)常是我們之前從來沒有做過的。時(shí)間估計(jì)反映了一個完美的知識狀態(tài)：你有宜家手冊幫你開路。現(xiàn)實(shí)情況是，許多任務(wù)都要求我們做以前沒做過的事情。

在大學(xué)學(xué)習(xí)計(jì)算機(jī)科學(xué)的工程師，在課堂上教會的對軟件安全的感覺是錯誤的。他們出校門后認(rèn)為明白軟件及軟件開發(fā)過程，其實(shí)什么都不知道。我在第一份工作的時(shí)候絕對是傲慢的大學(xué)畢業(yè)生，告訴大家他們這樣做是錯的。我在多年以后才能弄清楚其實(shí)我什么都不知道。

計(jì)算機(jī)科學(xué)課程不是為你工作時(shí)準(zhǔn)備的。他們教會你的是主題范圍廣泛的理論知識，以便你在工作中遇到他們時(shí)不會傻了眼。你學(xué)習(xí)變量、函數(shù)和對象，因?yàn)槟銓⒁恢睍龅竭@些東西。你學(xué)習(xí)數(shù)據(jù)庫和查詢，然而你學(xué)習(xí)的正規(guī)形式在實(shí)際工作中是沒有用的。你在排序算法和數(shù)據(jù)結(jié)構(gòu)上花費(fèi)了大量時(shí)間，所有這些在你工作編碼時(shí)都是不用考慮的?？傊?，計(jì)算機(jī)科學(xué)課程是在評論問題的解決方案，你在工作編碼時(shí)決不需要靠自己來解決。如今如果我需要對什么東西進(jìn)行排序，只需調(diào)用sort（）方法即可。如果我需要一個隊(duì)列或鏈表，只要使用所用語言本身的實(shí)現(xiàn)即可。這些都是已經(jīng)解決好的問題。

因此，剛走出大學(xué)校門的我們認(rèn)為知道如何做一切東西時(shí)，其實(shí)知道的都是已經(jīng)被解決的問題。事實(shí)情況是我們只知道已被解決問題中的很少一部分。然而，我們做出像知道一切一樣，自認(rèn)為有完整的知識，給出的估計(jì)時(shí)間很短因?yàn)椴挥每紤]學(xué)習(xí)的時(shí)間。

我們脆弱的自尊心也是問題的一方面。我們害怕如果估計(jì)的時(shí)間“太長”，人們就會小看我們。他們說“優(yōu)秀的工程師”應(yīng)該能夠快速地工作，我們默許了。我一直很驚訝，當(dāng)項(xiàng)目有了初步的估計(jì)時(shí)間后，一個非工程師人員來說這太長了。首先，正如我已經(jīng)提到的，由于我們的不足，實(shí)際上很可能時(shí)間還是太少了。其次，一個非工程師人員怎么知道需要花多少時(shí)間來建造呢？這引申出了另外一個問題。

我曾經(jīng)寫過代碼

沒有比“我曾經(jīng)寫過代碼”這樣的話更能讓軟件工程師惱火了。無論這是來自一個產(chǎn)品經(jīng)理、設(shè)計(jì)師或高層管理人員，除了合理的質(zhì)疑為什么工程師是不對的外，說出這種話來的人只會遭人鄙視。如果我問LeBron·James［譯注6］，他為一場比賽需要準(zhǔn)備多少時(shí)間，如果我不同意他的理由是因?yàn)槲以诟咧袝r(shí)打過籃球，我相信他會被逗樂的。軟件工程師也都是一樣的

譯注5：即勒布朗·詹姆斯，NBA著名球星，人稱小皇帝

下面是一些常見的謬論，是非工程師人員在我面前說的：

我不明白這為什么會是這樣一個大問題。不就是幾行代碼嗎？（從技術(shù)上來說，一切都是幾行代碼，這種話不會使問題變得容易或簡單。）

{請對號入座}說，這個可以在一兩天內(nèi)完成。（這是因?yàn)閧請對號入座}已經(jīng)擁有完整的解決方案的知識。我沒有，我需要先學(xué)習(xí)。）

我們能做些什么能使這個建造得更快些？你需要更多的工程師嗎？（在一個問題上投入更多的工程師，往往會使情況變得更糟?？焖俳ㄔ鞏|西的唯一方法是建造一個小點(diǎn)的東西。）

你能做到的最糟糕的事情是告訴他們你曾經(jīng)寫過代碼。請注意，這實(shí)際上和一個專業(yè)的軟件工程師是非常不同的。工程師轉(zhuǎn)行做產(chǎn)品經(jīng)理，在一段有限的時(shí)間內(nèi)還是有些可信的（通常約為5年，大于這個時(shí)間則一切都已經(jīng)完全改變了）。但是，那些從來沒有專業(yè)地開發(fā)過軟件的人，最好還是偷偷地保持編碼的愛好吧，而不是在企業(yè)里面使用它來為你爭論一切。

（說句公道話，對于設(shè)計(jì)師們也是有這個問題的。每個人都是業(yè)余的視覺設(shè)計(jì)愛好者，因?yàn)槲覀兌枷矚g漂亮的東西，但并不是每個人都有資格來設(shè)計(jì)東西的。）

更多的廚師

軟件工程師也經(jīng)常面臨廚房里有太多的廚師的問題。因?yàn)槲覀兊凸懒送瓿扇蝿?wù)需要花費(fèi)多長時(shí)間，大多數(shù)軟件都會延遲交付。這對大公司和小公司、你知道的和喜歡的產(chǎn)品都是適用的，他們都屬于這一類。延遲交付會讓管理者不高興，他們通常覺得問題是工程師太少了。他們說將會雇用更多的工程師，這會使一切變得更加美好。

在某些情況下，再多增加幾個工程師是有效果的。但在大多數(shù)情況下，增加更多的工程師，只會使問題變得更糟。讓富有創(chuàng)造力的人互相協(xié)調(diào)配合已經(jīng)夠難的了，你再添加更多的人進(jìn)來只會變得更加困難。一般地，工程師是不允許有空閑時(shí)間的。如果管理者注意到有工程師閑著，就常常會為他們制造一些工作來。

這樣的事情在幾年前以一種幾乎是滑稽可笑的方式發(fā)生在我身上。我們一個小團(tuán)隊(duì)在設(shè)計(jì)新的雅虎首頁，從頭開始重做。其實(shí)，我們之中的少數(shù)人能把注意力集中在構(gòu)建頁面依賴的底層構(gòu)架上，就是一個很理想的情況了。我們把所有的都設(shè)計(jì)完了，正準(zhǔn)備開始做原型，突然給了我們8位工程師。我們的開拔令嗎？這些工程師需要立馬開始為新首頁編碼。難題相當(dāng)多，因?yàn)榧軜?gòu)根本不存在。但工程師不能閑著，他們被分配到項(xiàng)目中總需要開始做一些事情。這是一個典型的雞和蛋的問題。

在理想的世界里，我們至少先建成一個原型，然后再接受別的工程師來幫忙建造。然而在這種情況下，我們被困住了。最后我使用了從別的項(xiàng)目拿過來的已有架構(gòu)，創(chuàng)建一個很弱的模型，使它看起來好像實(shí)際的架構(gòu)存在一樣。工程師們能夠停止他們手中的工作，同時(shí)我們能夠建造實(shí)際的架構(gòu)。這是對恐怖問題的恐怖解決方案，這最終會刺痛我們，因?yàn)楣こ處熥罱K會碰到目前并不存在的新架構(gòu)功能的條條框框。最后在某個時(shí)候，我不得不告訴我的經(jīng)理，如果不給我們時(shí)間建造實(shí)際的架構(gòu)，空中樓閣是會倒塌的。

一個項(xiàng)目有太多的工程師，是一個嚴(yán)重的問題。添加更多的工程師就是在假定有并行任務(wù)需要完成，但在現(xiàn)實(shí)中，任何一個項(xiàng)目的并行任務(wù)數(shù)量是很小且有限的。當(dāng)有更多的工程師可以使用時(shí)，很多工程時(shí)間就會從開發(fā)轉(zhuǎn)向規(guī)劃、同步和協(xié)調(diào)?；氐轿覄偛诺谋扔?，在第一層樓建成前你是無法建造第二層樓的。實(shí)際上許多軟件項(xiàng)目的任務(wù)是連續(xù)的，因此增加更多的工程師并不會加快速度?；蛳裎乙郧暗囊粋€同事經(jīng)常說的，不管你給我多少個女人，要生小孩仍然需要九個月的時(shí)間。

真正暴躁

所以，沒有足夠的信息、不斷變化的需求、沒有足夠的知識來完成這項(xiàng)工作及另外人們不斷猜疑我們，導(dǎo)致我們每天都在吃力地工作。作為創(chuàng)意人，我們?nèi)萑塘怂羞@一切，因?yàn)槲覀冎烙幸惶烊藗儠梦覀兊淖髌?。這是最主要的真正驅(qū)動軟件工程師的動力：甚至我們不認(rèn)識的人都會受到我們作品的影響。無論你是在做一個每天有百萬級訪問人數(shù)的網(wǎng)站，抑或是為餐館做一個銷售點(diǎn)系統(tǒng)，影響人們生活的知識是強(qiáng)大的驅(qū)動力。

由于人們改變他們的想法導(dǎo)致有延誤時(shí)，我們會變得非常暴躁。發(fā)神經(jīng)似地暴躁。我們在人們面前的工作目標(biāo)已被推遲，這是令人泄氣的。令人驚訝的是，軟件工程師通常不是完美主義者。我們通常對有些東西好了就行，而不是要非常好。我們喜歡先快速地發(fā)布一些小東西，然后晚些時(shí)再把它們組合成一個大東西。為什么？因?yàn)檫@就是我們?nèi)绾伟旬a(chǎn)品給人們的。

現(xiàn)在，我們都知道延誤和其他東西一樣都是軟件的一部分。估計(jì)的時(shí)間不夠時(shí)，工程師們會拼命工作并完成目標(biāo)。工程師不討厭努力工作或長時(shí)間工作，我們討厭沒有取得成功。

得到了什么可以表示感謝的東西？

作為一個軟件工程師，我們的工作時(shí)間線和其他人是非常不同的。通常不會是設(shè)計(jì)師或產(chǎn)品經(jīng)理在半夜醒來，是因?yàn)楫a(chǎn)品中的一些東西出問題了（雖然，我也知道在發(fā)生這樣的事情時(shí)產(chǎn)品經(jīng)理也是希望能被通知到的）。有一次我即將下班去約會，突然被叫到辦公室里，因?yàn)橛袀€產(chǎn)品問題。她坐在那兒，而我在狂暴地試著解決這個問題，她最后離開前耐心地等了一個小時(shí)（我不能責(zé)怪她），留下我一人在那兒工作，我只能在即時(shí)聊天工具上和我的同事分享我的痛苦。

然而，你很少發(fā)現(xiàn)軟件工程師會抱怨長時(shí)間的工作或者由于產(chǎn)品問題被叫醒。軟件是我們的孩子，我們喜歡這樣來關(guān)心她。這意味著，如果需要在半夜起來喂她，我們就會做。如果需要在周末額外的照顧，我們也會做，我們會面帶微笑，因?yàn)槲覀兊膭?chuàng)造力在增長。

工程師在可以提交任務(wù)最后的代碼時(shí)會特別高興。當(dāng)他們發(fā)送一封電子郵件說任務(wù)完成了準(zhǔn)備接受評論時(shí)，我從來沒有見過他們?nèi)绱丝旎钸^。然而，在接下來的十分鐘，這種情緒很快破滅了，人們開始對他們新創(chuàng)造的寶貝提交bug了。

如果你肯再想象一下，你在一個東西上工作了一天或一個星期或幾個星期，然后提交了。你感到很自豪，因?yàn)槟阃瓿闪巳蝿?wù)，很可能學(xué)做了一些之前不知道的東西。你真正想要的是花點(diǎn)時(shí)間坐下來，欣賞你的作品一會兒。也許有人說，“干得好。”我們得到什么反饋？Bugs。有些東西無法工作，另外有些錯位了等等。我們的好心情被破壞了，我們倉促地進(jìn)入了修復(fù)模式。

為什么我們說“不”

鑒于我已經(jīng)提到的一切，下面是工程師說為什么說“不”（或是脾氣暴躁）的常見原因：

需求在開發(fā)過程中姍姍來遲，在Deadline前沒有足夠的時(shí)間來適應(yīng)。

需求導(dǎo)致早期過程中為了推進(jìn)項(xiàng)目而做的一個或多個設(shè)想變得無效。

需求和先前的要求相反。

需求在其他方面增加了工作量，而且在Deadline之前必須要完成。

我們是如此的精疲力竭，任何需求看起來都像是大量的工作，我們就是不想做這個。

請記住，除了最后一項(xiàng)，所有這些工程師要做的都要趕上Deadline，以便完成項(xiàng)目。只有在我們工作的時(shí)候任務(wù)不發(fā)生改變，我們才會想把它做完。當(dāng)他們發(fā)生改變且我們真的很暴躁的時(shí)候，“不”字就會在你說完話前脫口而出。

關(guān)愛

那么，你的企業(yè)是如何處理這些必然會出現(xiàn)的暴躁呢？先回顧一下驅(qū)動工程師的東西：

有創(chuàng)意的

能解決問題的

人們使用我們的作品

請注意名單中缺少什么。錢。向工程師砸錢很難滿足他們。這聽起來是陳詞濫調(diào)，但對工程師來真的不是錢的問題。錢讓他們有樂趣，但我們真正感興趣的是編碼和創(chuàng)造。當(dāng)我們能在一個健康的環(huán)境工作時(shí)，我們能在很長的一段時(shí)間內(nèi)保持快樂。

那么，你如何為工程師創(chuàng)造一個健康的環(huán)境？

交叉工作職責(zé)

軟件工程師就像產(chǎn)品經(jīng)理和設(shè)計(jì)師一樣富有創(chuàng)造力，所以你在創(chuàng)造工作過程中要算上他們。工程師在頭腦風(fēng)暴會議和初始設(shè)計(jì)評審時(shí)是巨大的資產(chǎn)。給每一位工程師和創(chuàng)作團(tuán)隊(duì)見面的機(jī)會，讓工程師直接和他們一起工作（不需要一直在一起）。總之，盡早讓工程師加入到創(chuàng)造過程中去。沒有工程師會喜歡他們不理解的從墻外扔過來的規(guī)格說明和設(shè)計(jì)稿件。

工程師們的邏輯性很強(qiáng)，所以參加這些早期的會議，明白需求是從哪來的，對完全地避免問題是有很大的幫助的。當(dāng)工程師感覺像建造者，他們會有疑問，然后進(jìn)度就慢下來了。當(dāng)工程師是共同的創(chuàng)造者時(shí)，問題很少，因此之后的過程中延誤就更少。

更重要的是，工程師們在什么是可能做到的知識方面遠(yuǎn)遠(yuǎn)領(lǐng)先于別人。如果考慮前端工程師，我們知道什么瀏覽器能夠?qū)崿F(xiàn)，遠(yuǎn)遠(yuǎn)早于產(chǎn)品經(jīng)理和設(shè)計(jì)師知道的時(shí)候。當(dāng)我們分享這個知識點(diǎn)時(shí)，我們實(shí)際上給了大家如何做產(chǎn)品的新思路，因?yàn)橹懒耸裁词强赡茏龅降?。試想一下，如果你想?chuàng)建一個照片共享網(wǎng)站，不知道現(xiàn)在可以把文件從桌面拖放到瀏覽器上傳？［2］這對產(chǎn)品設(shè)計(jì)會有怎樣的影響？

因此，請?jiān)谠缙谘埞こ處熂尤氲絼?chuàng)作過程。讓他們給你反饋，并提供什么是可以做到的信息。我們被呼來喚去的感覺越少，我們就越有可能傾聽并愉快地著手工作。只要我們感覺對創(chuàng)造這東西有貢獻(xiàn)時(shí)，我們就會這么做。

留出創(chuàng)意空間

跟著“軟件工程師是創(chuàng)作者”這個主旋律，試著為我們提供充足的機(jī)會勇于創(chuàng)新。Hack日和Hack周如此受歡迎的原因：因?yàn)檫@是創(chuàng)意的發(fā)泄方式，工程師需要加油，需要重新發(fā)現(xiàn)自己喜愛的代碼。Hack活動是工程師們可以盡情創(chuàng)作的時(shí)候，是擺脫了正常工作的限制的時(shí)候。

每季度的Hack日足以讓人興奮。想讓人更加興奮？給Hack日一個主題。給最具創(chuàng)意、最有可能推出產(chǎn)品的人獎勵等等?？偟脕碚f就是激勵軟件工程師的創(chuàng)造力，當(dāng)他們回到正式工作時(shí)，會感到神清氣爽，準(zhǔn)備再次貢獻(xiàn)自己的創(chuàng)造力。

請記住在這方面工程師不是特別的。每個人創(chuàng)作時(shí)都需要時(shí)間。然而，據(jù)我的經(jīng)驗(yàn)，產(chǎn)品經(jīng)理和設(shè)計(jì)師往往更加能夠體會到這一點(diǎn)。管理者有拓展的地方，設(shè)計(jì)師有設(shè)計(jì)峰會，但工程師往往會被遺棄。

隨便說下，Hack活動不是做到這一點(diǎn)的唯一方式，但他們是最好的開始方式。你也可以派工程師參加會議，使他們能夠保持更新技能，點(diǎn)燃他們的創(chuàng)意之火?；ㄙM(fèi)公司的一丁點(diǎn)兒錢讓工程師去買書，有助于完善他們的知識儲備。讓工程師表達(dá)自己對正在做的項(xiàng)目的想法。眾所周知，Google給工程師20％的時(shí)間去從事編外項(xiàng)目。所有這一切對于和你的工程師建立極好的關(guān)系是非常有幫助的。

鼓勵休假

我們經(jīng)常進(jìn)行數(shù)個小時(shí)的腦力勞動，我們需要休息。不幸的是，安排時(shí)間并不是我們很在行的。我們沉湎在工作的過程中，忘記了休假。我覺得在我職業(yè)生涯中的第一個五年里，我總共休了7天的假期。我不知道為什么，但我們對給自己騰出時(shí)間來緩解壓力這種事情不大在行。這是一個問題。

工程師倦怠是很特別的問題，因?yàn)槲覀兞?xí)慣于在項(xiàng)目表現(xiàn)為精力充沛。當(dāng)倦怠變得糟糕透了，我們會離開去尋找安慰。此外，工程師將可能永遠(yuǎn)不會告訴你他們正在接近這個點(diǎn)，我們太自負(fù)了。在我上一個團(tuán)隊(duì)，我告訴工程師，請?jiān)谒麄兊谝淮胃械骄趩蕰r(shí)來和我說說話。我不想讓他們等到直到它變得這么大，以至于他們逃脫的唯一辦法是離開。我不想讓他們離開，我想讓他們快樂，只有我知道他們開始不高興了我才能幫助他們。

鼓勵工程師休假。你的公司提供了一些數(shù)量的假期，所以一定要確保在一個整年中鼓勵工程師們休掉這些假期。每4-5個月至少休一次。管理者是幫助完成這事的好角色，因?yàn)樗麄冎理?xiàng)目的進(jìn)度。

當(dāng)工程師需要定期的休息時(shí)，他們不用面對苛刻的Deadline，恢復(fù)了創(chuàng)造力。是的，我們?nèi)匀豢赡軙谛菁贂r(shí)花一些時(shí)間編碼，但這是純粹的創(chuàng)作，這和我們在工作中做的是相當(dāng)不同的。這對重新提起精神準(zhǔn)備下一場戰(zhàn)斗是很重要的。

讓他們寫代碼吧

聽起來具有諷刺意味的是，很多公司雇用軟件工程師，然后在實(shí)際工作中不讓他們編碼。替代的是他們的日子都充滿了阻礙生產(chǎn)力的無用會議。在一般情況下，軟件工程師們至少能夠編碼四個小時(shí)而不被中斷時(shí)，他們的生產(chǎn)力是最高的。

如果你在編碼的時(shí)候知道在一或兩個小時(shí)之后有會議，就很難進(jìn)入到“流”里面，因?yàn)檫@總會在你的腦海里。編碼一個小時(shí)，停止一個小時(shí)，編碼一個小時(shí)，停止一個小時(shí)等等是驚人的低產(chǎn)的。你不能進(jìn)入“流”當(dāng)中去，因?yàn)槟銊傞_始，你就必須停止。軟件工程師的大腦切換到很好的狀態(tài)去編碼是需要時(shí)間的。

確保你的工程師每一天至少有四個小時(shí)不間斷的時(shí)間用來編碼。這是更快地工作的關(guān)鍵所在。這似乎相當(dāng)合乎邏輯：如果人們一天通常工作8小時(shí)，至少有一半的時(shí)間應(yīng)該花在主要任務(wù)上。我以前覺得，我在下午1點(diǎn)和下午5點(diǎn)之間是最高產(chǎn)的。我知道如果每天都擁有這段時(shí)間，我可以很容易地完成任務(wù)。當(dāng)這段時(shí)間開始被會議中斷，我知道就不能完成更多的任務(wù)了。

此外，每周至少有一天沒有會議，包括每天的站立會議。讓工程師有一天能完全自己管理自己的時(shí)間，把所有的事情做完。一整天都沒有被中斷，完成的工作量絕對是驚人的。如果有必要，讓工程師可以在家工作，以確保他們不會被中斷。實(shí)際上在我的職業(yè)生涯期間我有過這樣的經(jīng)歷，我的經(jīng)理要求我每周至少兩天在家工作，因?yàn)槲以谵k公室里會被中斷太多次了。結(jié)果是：我的工作完成得非?？?。

表達(dá)謝意

這是可以立即做并且是完全有效果的。我前面提到的長期勞累地趕工完成任務(wù)，結(jié)果是遭受被提交bug的沮喪。我們的工程師很少有機(jī)會坐下來欣賞自己的作品，更不用說得到別人從背面拍肩膀的贊賞了。

當(dāng)一位工程師完成了任務(wù)，尤其是一個漫長的任務(wù)，快速地說聲謝謝是大有幫助的。即使它只是“嘿，謝謝把那完成了，我們先看看。”也足以增強(qiáng)面對通常會發(fā)生的bug涌現(xiàn)情況的防御能力了。被感激的感覺對工程師來說是很重要的，因?yàn)槲覀兊玫降拇蟛糠址答伿窍麡O的：以bugs的形式、產(chǎn)品問題等等。一點(diǎn)點(diǎn)積極的反饋就能使工程師容忍其余全部的東西。

每個季度給那些做了最大影響的，或者改進(jìn)最多的，或者任何其他東西的工程師加分、設(shè)立獎品。獎品甚至并不必是像iPad那樣大件的和令人滿意的東西（雖然我們會和其他的東西一起欣然接受），它可以是一個小小的記念品以及發(fā)封電子郵件給團(tuán)隊(duì)或部門，讓別人也察覺到我們的努力。

請務(wù)必確保當(dāng)你感謝在產(chǎn)品上辛勤工作的人們時(shí)不要忘記工程師。我已經(jīng)參加過無數(shù)次的會議，在上面人們公開稱贊產(chǎn)品團(tuán)隊(duì)或設(shè)計(jì)師在對項(xiàng)目的作用，從來都沒有提到工程師。正是他們的血液、汗液和眼淚才把東西變成真實(shí)的。每一個產(chǎn)品是成功還是失敗歸根于所有三組人員，沒有一組可以單獨(dú)做到這一點(diǎn)。確保公司始終把團(tuán)隊(duì)當(dāng)作一個整體，而不是一個特別的角色。

總結(jié)

我們軟件工程師是一個有趣的群體。我們有一定的個性，我們要做最出色的東西。如果停止把我們當(dāng)作“臨時(shí)工”，開始把我們看作創(chuàng)作過程的一部分，你很可能得到更多，另外項(xiàng)目也會比你想象得更快推進(jìn)。由于不理解工程師的心態(tài)和是什么在驅(qū)動他們，我工作過的團(tuán)隊(duì)都有不同程度的摩擦。我真誠地希望本文將更好地引導(dǎo)工程師及和他們一起工作的人之間的溝通。這真的沒有那么難。我們都想覺得自己是解決問題的一部分，而不是一只小工蜂。