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

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

責編 | 唐小引

頭圖 | CSDN 下載自東方 IC

出品 | CSDN（ID：CSDNnews）

以下為譯文：

1970 年，我在大學里上了第一堂編程課（當然了，學的是 FORTRAN）。在過去的半個世紀中，我的很多時間都花在了軟件工作中：需求、設計、用戶體驗、編程、測試、項目管理、寫文檔，領導過程改進，撰寫 7 本書和許多篇文章，咨詢，培訓。

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

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

關于需求

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

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

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

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

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

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

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

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

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

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

11. 不要害怕對需求進行記錄。與獲取知識的成本相比，記錄知識的成本很低。

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

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

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

15. 我們有時在表達需求時會比較隨意，因為我們會假設讀者有一個跟我們自己類似的“理性過濾器”，但是對于一段相同的陳述，人們經(jīng)常會以不同的方式解讀。這種模糊性會導致期望不匹配以及交付時的意外。

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

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

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

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

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

21. 有兩個術語，你聽到時一定要提高警惕：“假定需求”和“隱含需求”。要力爭明確地交流需求的預期。

關于項目管理

22. “項目管理”指的不是一項具體活動。項目管理是人員管理，需求管理，風險管理，機會管理，預期管理，承諾管理，變更管理，資源管理，以及供應商管理的混合物。

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

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

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

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

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

28. 除非你把評估記錄下來并將其與實際發(fā)生的情況進行比較，否則你將永遠是在猜測，而不是在評估。

29. 不能因為覺得對方喜歡聽好話，就影響到你對某人的評估。

關于質量與過程改進

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

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

32. 永遠都別被老板或客戶說服去做壞事。

33. 質量應該是你的重中之重。高質量的自然結果就是長足的生產(chǎn)力，因為這樣團隊就不需要浪費太多時間進行返工了。

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

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

36. 當人們被要求改變自己的工作方式時，他們的本能反應是問“這對我有什么好處？”但其實這個問法是不對的。正確的問法應該是“這對我們團隊有什么好處？”

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

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

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

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

41. 不管是否是出于好意，改進計劃如果不能轉化為行動那都無濟于事。

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

43. 在領導組織采用新的工作方式時，請不斷輕柔地施以壓力。

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

45. 除非你花時間進行回顧，學習經(jīng)驗教訓并不斷改進團隊的流程，否則沒有理由來預期下一個項目能比上一個項目做得更好。

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

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

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

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

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

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

其他見解

52. 人工智能不能替代真實的事物。

53. 在技術界，如果你領先其他人一個星期，那么你就是大佬了。

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

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

56. 人們總是過多地談論自己的“權利”。而每項權利的另一面都是責任。要以協(xié)作的心態(tài)去思考以及行動。

57. 一盎司的設計相當于一磅的重構。

58. 要當心“商業(yè)周刊式的管理方式”——僅僅因為有人讀到了它所承諾的極好結果，就匆忙地在軟件開發(fā)中采用最熱門的新事物。

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

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

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

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

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

英文：63 Lessons from 50 Years of Software Experience

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

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

譯者：香檳超新星

本文為 CSDN 翻譯，轉載請注明來源出處。