技術(shù)圈能夠從業(yè) 50 年的開發(fā)者顯得彌足珍貴，本文作者 Karl Wiegers 就是這樣一位有著豐厚經(jīng)驗(yàn)的軟件行業(yè)從業(yè)者，在過去 50 年里，他積累了 63 條啟示，并將其梳理分享出來，希望對(duì)你有所啟發(fā)。

作者 | Karl Wiegers，譯者 | 香檳超新星

責(zé)編 | 唐小引

頭圖 | CSDN 下載自東方 IC

出品 | CSDN（ID：CSDNnews）

以下為譯文：

1970 年，我在大學(xué)里上了第一堂編程課（當(dāng)然了，學(xué)的是 FORTRAN）。在過去的半個(gè)世紀(jì)中，我的很多時(shí)間都花在了軟件工作中：需求、設(shè)計(jì)、用戶體驗(yàn)、編程、測(cè)試、項(xiàng)目管理、寫文檔，領(lǐng)導(dǎo)過程改進(jìn)，撰寫 7 本書和許多篇文章，咨詢，培訓(xùn)。

當(dāng)然，在此過程中也完成了一些支線任務(wù)，比如讀了有機(jī)化學(xué)的 PhD（我的論文有三分之一都是計(jì)算機(jī)代碼），做了幾年的研究員。但基本上來說，我是個(gè)軟件行業(yè)的人。

在如此漫長(zhǎng)的這段時(shí)間里，我積累了許多關(guān)于軟件行業(yè)的見解。在本文里，我將跟大家分享 63 個(gè)啟示，也許你也會(huì)像我一樣覺得它們很有用。

關(guān)于需求

1. 如果你沒有搞明白需求，那么項(xiàng)目的其他部分你做得再好也沒用，最終都會(huì)失敗的。

2. 午餐后你在辦公桌上發(fā)現(xiàn)的便簽紙，保存下來的語音郵件和電子郵件，以及記得似是而非的走廊上的隨意對(duì)話，所有這些都不能算得上是需求。這只是一堆信息而已。

3. 對(duì)于所有項(xiàng)目利益相關(guān)者來說，利益的交集在流程需求（Requirements Process）中發(fā)生得最多。

4. 如果缺少了高質(zhì)量的需求，利益相關(guān)者們可能會(huì)對(duì)最后交付的內(nèi)容感到倍感意外。在軟件中，意外幾乎總是壞消息的代名詞。

5. 在探索需求時(shí)，請(qǐng)不要只考慮當(dāng)前的用戶。你曾經(jīng)的客戶仍然是你的客戶。

6. 人們不應(yīng)該只是去“收集”需求。需求獲取是個(gè)探索，協(xié)作，發(fā)現(xiàn)和發(fā)明的過程，而不僅僅是簡(jiǎn)單的收集。一個(gè)商業(yè)分析師不僅僅要干抄寫員的活。

7. 需求獲取的目的是讓客戶的聲音——即 VOC，voice of the customer——盡可能地貼近開發(fā)人員的耳朵——即 EOD，ear of the developer。商業(yè)分析師有助于縮小其中的溝通差距。

8. 對(duì)于需求獲取，人們通常寄希望于兩種方法：“心靈感應(yīng)”和“千里眼”。但這兩樣都沒用。

9. 不管我們的文化怎樣宣稱，但客戶其實(shí)并不總是正確的。但是客戶總是有他自己的意見的，而你必須理解以及尊重這個(gè)意見。

10. 需求開發(fā)需要迭代。你不能指望在第一次討論中就 get 到所有的需求；要知道你可能永遠(yuǎn)也無法完全 get 到。有效的需求開發(fā)涉及對(duì)細(xì)節(jié)和清晰度的逐步改進(jìn)。

11. 不要害怕對(duì)需求進(jìn)行記錄。與獲取知識(shí)的成本相比，記錄知識(shí)的成本很低。

12. 如果要求中未描述某些功能或特性，則沒人期望在產(chǎn)品中看到它。

13. 需求開發(fā)的可交付成果不僅僅是一組書面需求，而是一種共識(shí)和一致的預(yù)期。

14. 對(duì)于需求開發(fā)而言，比較實(shí)際的目標(biāo)不是創(chuàng)建出的需求有多完美，而是創(chuàng)建出的需求足以使團(tuán)隊(duì)以可接受的風(fēng)險(xiǎn)水平進(jìn)行建設(shè)。這種風(fēng)險(xiǎn)就在于，由于被忽視的，不必要，不完整，模棱兩可或溝通不暢的情況下產(chǎn)出的需求，而不得不進(jìn)行過多的計(jì)劃外返工的情況。

15. 我們有時(shí)在表達(dá)需求時(shí)會(huì)比較隨意，因?yàn)槲覀儠?huì)假設(shè)讀者有一個(gè)跟我們自己類似的“理性過濾器”，但是對(duì)于一段相同的陳述，人們經(jīng)常會(huì)以不同的方式解讀。這種模糊性會(huì)導(dǎo)致期望不匹配以及交付時(shí)的意外。

16. 把需求工作室和審核小組保持在一個(gè)較小的規(guī)模。一大群人連是否要離開一個(gè)起火了的房間的無法做到意見相同，更不用說在某項(xiàng)需求應(yīng)該如何措辭上達(dá)成一致了。

17. 當(dāng)有人提出新需求時(shí)，第一個(gè)要問的問題是：“這在我們的討論范圍之內(nèi)嗎？”如果是的，那就必須解決。如果不是，那就不解決，或者至少不是現(xiàn)在解決。但是，如果答案是“不是，但我們應(yīng)該關(guān)注這個(gè)問題”，那么你必須調(diào)整范圍來適應(yīng)它。這對(duì)成本，進(jìn)度，資源，參與度，優(yōu)先級(jí)和效益折中都有影響。

18. 如果你沒有一個(gè)記錄在案且已達(dá)成共識(shí)的項(xiàng)目范圍，怎么能知道自己是否正在經(jīng)歷范圍蔓延？

19. 在決定要在一個(gè)產(chǎn)品或迭代中包含哪些功能時(shí)，請(qǐng)避免“分貝優(yōu)先級(jí)”的做法（俗稱按鬧分配）。聲音最大的那些客戶所要求的功能從業(yè)務(wù)角度來說并不一定是最重要的。

20. 項(xiàng)目的利益相關(guān)者們必須能夠理解，對(duì)可能的需求進(jìn)行討論與承諾將其包含在產(chǎn)品中之間是有區(qū)別的。

21. 有兩個(gè)術(shù)語，你聽到時(shí)一定要提高警惕：“假定需求”和“隱含需求”。要力爭(zhēng)明確地交流需求的預(yù)期。

關(guān)于項(xiàng)目管理

22. “項(xiàng)目管理”指的不是一項(xiàng)具體活動(dòng)。項(xiàng)目管理是人員管理，需求管理，風(fēng)險(xiǎn)管理，機(jī)會(huì)管理，預(yù)期管理，承諾管理，變更管理，資源管理，以及供應(yīng)商管理的混合物。

23. 為什么有些公司永遠(yuǎn)沒有時(shí)間來好好地做出軟件，而后續(xù)卻總能擠出時(shí)間，金錢和人力來彌補(bǔ)？這是一個(gè)謎。

24. 每個(gè)人都愿意認(rèn)為自己的團(tuán)隊(duì)擁有頂尖人才，但事實(shí)是在所有軟件開發(fā)人員中有半數(shù)的能力都低于平均水平。那么這些人都在哪工作呢？

25. 不要輕易地評(píng)估任何人。如果別人請(qǐng)你評(píng)估，最合適的回復(fù)是：“讓我先考慮一下，回頭再與您聯(lián)系吧?！?/p>

26. 無論別人施加給你多大壓力，都不要給出自己無法兌現(xiàn)的承諾。

27. 如果你手上有很有說服力的數(shù)據(jù)，而對(duì)方幾乎沒有任何數(shù)據(jù)的話，你在談判中就會(huì)占據(jù)優(yōu)勢(shì)地位。

28. 除非你把評(píng)估記錄下來并將其與實(shí)際發(fā)生的情況進(jìn)行比較，否則你將永遠(yuǎn)是在猜測(cè)，而不是在評(píng)估。

29. 不能因?yàn)橛X得對(duì)方喜歡聽好話，就影響到你對(duì)某人的評(píng)估。

關(guān)于質(zhì)量與過程改進(jìn)

30. 關(guān)于軟件質(zhì)量：你可以現(xiàn)在就付錢給我，也可以以后再付給我，但是要付得更多。

31. 力求完美；追求卓越。

32. 永遠(yuǎn)都別被老板或客戶說服去做壞事。

33. 質(zhì)量應(yīng)該是你的重中之重。高質(zhì)量的自然結(jié)果就是長(zhǎng)足的生產(chǎn)力，因?yàn)檫@樣團(tuán)隊(duì)就不需要浪費(fèi)太多時(shí)間進(jìn)行返工了。

34. 力求能讓一位同輩，而不是客戶來發(fā)現(xiàn)缺陷。同輩技術(shù)評(píng)審是一種行之有效的技術(shù)，可以提高質(zhì)量和生產(chǎn)力。

35. 如果和你打交道的人不講理，那任何軟件工程方面的技術(shù)都沒用。

36. 當(dāng)人們被要求改變自己的工作方式時(shí)，他們的本能反應(yīng)是問“這對(duì)我有什么好處？”但其實(shí)這個(gè)問法是不對(duì)的。正確的問法應(yīng)該是“這對(duì)我們團(tuán)隊(duì)有什么好處？”

37. 軟件開發(fā)人員永遠(yuǎn)都在尋找出色的工具，但請(qǐng)記住，小傻瓜有了工具以后也只會(huì)變成大傻瓜。

38. 當(dāng)人們不了解當(dāng)前工作方式所導(dǎo)致的痛點(diǎn)在哪里時(shí)，進(jìn)行流程更改是很難的。就像如果人們不知道自己家里有老鼠，就很難把更好的捕鼠器賣給他們。

39. 問：更換燈泡需要多少名軟件過程負(fù)責(zé)人？答：只需要一個(gè)，但前提是燈泡必須愿意被更換。

40. 在朝著新的工作方式發(fā)展的過程中，不要低估改變組織文化的必要性和困難程度。實(shí)行一套新流程比灌輸一種新文化更快。你需要在這兩方面都做到成功。

41. 不管是否是出于好意，改進(jìn)計(jì)劃如果不能轉(zhuǎn)化為行動(dòng)那都無濟(jì)于事。

42. 在許多情況下，常識(shí)，良好的判斷力，以及經(jīng)驗(yàn)應(yīng)當(dāng)比正式程序更重要。但是，有時(shí)候這個(gè)程序的存在是有充分理由的。在決定繞過它之前需要先調(diào)查一下。

43. 在領(lǐng)導(dǎo)組織采用新的工作方式時(shí)，請(qǐng)不斷輕柔地施以壓力。

44. 能促使人們改變工作方式的最好動(dòng)力是痛苦。不是人為的，外部施加的痛苦，而是當(dāng)前工作方式帶給團(tuán)隊(duì)的非常真實(shí)的痛苦。選擇那些可以最終減輕痛苦的改善活動(dòng)吧。

45. 除非你花時(shí)間進(jìn)行回顧，學(xué)習(xí)經(jīng)驗(yàn)教訓(xùn)并不斷改進(jìn)團(tuán)隊(duì)的流程，否則沒有理由來預(yù)期下一個(gè)項(xiàng)目能比上一個(gè)項(xiàng)目做得更好。

46. 你不能一下更改所有內(nèi)容。找出那些能夠帶來最大收益的流程變更，并在下個(gè)周一開始實(shí)施。我沒有開玩笑：就是下周一！

47. 對(duì)文檔模板中采用“縮小以適應(yīng)”的理念。先從一個(gè)豐富的模板開始，用來提醒你多考慮有哪些信息可以包含進(jìn)去，然后再根據(jù)每個(gè)項(xiàng)目的規(guī)模，性質(zhì)和需求來進(jìn)行重塑。

48. 有許多團(tuán)隊(duì)都被要求做到事半功倍。不過，通常情況下，他們并沒有能讓自己事半功倍的方法。如果沒有相應(yīng)的培訓(xùn)和過程改進(jìn)來提高效率和效果，就不要期望更高的生產(chǎn)力會(huì)神話般地自己顯現(xiàn)。

49. 適用于四個(gè)在同一辦公室里工作的人的非正式流程是無法擴(kuò)展到在不同大陸工作的多個(gè)開發(fā)團(tuán)隊(duì)上面的。

50. 如果軟件行業(yè)有什么東西是可復(fù)現(xiàn)的，那就是在一個(gè)又一個(gè)的項(xiàng)目上重復(fù)地做同樣的蠢事。你需要通過回顧來學(xué)習(xí)，理解，以及不斷改進(jìn)。

51. 當(dāng)人們不遵循既定流程時(shí)，你面前只有三種選擇：（1）讓人們開始遵循流程；（2）調(diào)整流程使其更加有效和實(shí)用，然后讓人們遵循它；（3）放棄這個(gè)流程并不再假裝你遵循這個(gè)過程。

其他見解

52. 人工智能不能替代真實(shí)的事物。

53. 在技術(shù)界，如果你領(lǐng)先其他人一個(gè)星期，那么你就是大佬了。

54. 今天的“必須馬上搞定它”的那種開發(fā)項(xiàng)目會(huì)成為明天的遺留系統(tǒng)維護(hù)噩夢(mèng)。

55. 軟件系統(tǒng)的許多問題都發(fā)生在接口上：軟件和軟件，軟件和硬件，軟件和人，人和人。這些接口需要好好研究。

56. 人們總是過多地談?wù)撟约旱摹皺?quán)利”。而每項(xiàng)權(quán)利的另一面都是責(zé)任。要以協(xié)作的心態(tài)去思考以及行動(dòng)。

57. 一盎司的設(shè)計(jì)相當(dāng)于一磅的重構(gòu)。

58. 要當(dāng)心“商業(yè)周刊式的管理方式”——僅僅因?yàn)橛腥俗x到了它所承諾的極好結(jié)果，就匆忙地在軟件開發(fā)中采用最熱門的新事物。

59. 在拇指和食指之間保持一英寸的距離。在大多數(shù)情況下，這就是質(zhì)量和垃圾之間的唯一區(qū)別。只在于多聆聽一點(diǎn)，檢查一下你的工作，再次運(yùn)行測(cè)試，參考清單，閱讀說明，再多問一個(gè)問題。通常，這是改善垃圾的唯一方法。

60. 你沒有時(shí)間去重新犯一遍那些軟件從業(yè)者之前犯過的錯(cuò)誤。閱讀并尊重文獻(xiàn)。向你的同事學(xué)習(xí)?？犊嘏c他人分享你的知識(shí)。

61. 軟件開發(fā)中計(jì)算技術(shù)可能占 50％，剩下 50％在于交流溝通。但商業(yè)分析是完全在于交流溝通的。我們?cè)谟?jì)算方面要占得更多。

62. 如果你想自立門戶做個(gè)獨(dú)立顧問或承包商，則你需要向全世界宣告自己有空。如果沒有人了解你，那不管你業(yè)務(wù)能力有多好都沒用。

63. 在軟件行業(yè)中，我們經(jīng)常會(huì)假裝。我們假裝已經(jīng)找到了合適的利益相關(guān)者，他們了解自己的業(yè)務(wù)目標(biāo)，并且清楚自己的需求。我們假裝合適的人向我們傳達(dá)了正確的需求，且我們理解并準(zhǔn)確地做了記錄。我們假裝我們的評(píng)估是準(zhǔn)確的，且我們已經(jīng)考慮到了所有必要的任務(wù)。我們假裝所有可能會(huì)損害到我們項(xiàng)目的風(fēng)險(xiǎn)都不會(huì)真的出現(xiàn)。我不愛假裝。有時(shí)候，我也不是那么喜歡現(xiàn)實(shí)，但我除了現(xiàn)實(shí)以外一無所有，所以我必須面對(duì)它。讓我們停止假裝吧。

英文：63 Lessons from 50 Years of Software Experience

原文：https://medium.com/swlh/62-lessons-from-50-years-of-software-experience-2db0f400f706

作者簡(jiǎn)介：Karl Wiegers，作家，寫作內(nèi)容涵蓋軟件開發(fā)和管理、咨詢、自我提升、化學(xué)、軍事歷史等領(lǐng)域，目前還在寫一本懸疑小說。

譯者：香檳超新星

本文為 CSDN 翻譯，轉(zhuǎn)載請(qǐng)注明來源出處。