###### tags: `讀書會筆記`
# 人月神話：Chapter 1-8
## 第一章：焦油坑
此圖中用四個象限來表示不同層次的軟體，圖中的「x N」，表示花費成本為 N 倍。

簡單說明一下四個象限的意義：

* 工具軟體 / 程式
缺乏可擴充性，沒有明確的介面，程式碼呈現高耦合度。
* 軟體系統
由組件組成。具有高可擴充性，有明確介面以便擴充組件。
* 軟體產品
具有說明文件，與未來版本具有相容性。
* 軟體系統產品
軟體系統 x 軟體產品。

### 寫程式的樂趣與苦難
寫程式很有趣，他滿足了潛藏於內心創造事務的渴望，並且激發了我們每個人原本就擁有的快樂感受。

但今天，若要求開發者按造既定的格式開發並結構化的區分工作項目是否會扼殺工程師的創意及想像，另外，是否繁瑣事項的要求，反倒附帶了枯燥、沈悶、耗時的開發日常。

### 我在宏碁的日子...
在這裡，我想提的是~~宏碁研發~~與**玉山智金**的差異。

在宏碁的時期，我們團隊自詡為新創團隊，希望替公司找出本業以外的利基點並創造價值，最後Spin-off出宏碁。團隊從deep learining開始研究，並專注在人臉，最終收斂應用在智慧零售的領域。不是因為先前團隊在人臉模型的成效上做的多好、多精准所以才有後來產品化的過程。而是，我先前的老闆叫做Gene。Gene很早就告訴我們，我們必須要搶這股AI浪頭，先搶落地，再回頭根據落地的狀況去調整無論是模型還是系統的架構。

因此，我們在開發模式走的是類似於SCRUM的開發模式，我們每週都會有一些功能項目必須要完成，但最終的結果都是希望能夠直接做成Prototype，在兩週一次的Sprint Review中要讓團隊成員看到實際的“類產品樣貌”。而這個Prototype，除了讓團隊成員可以更快速的按造實際場景進行客製化的開發外，更重要的是讓客戶可以直接感受AI在影像辨識上場景的應用，讓客戶深入其境並予以想像空間。

然而，我們確實透過成功執行了不少次成功的PoC，開始接到政府或企業的案子，突如其來的，我們變成要從一隻相機的場景變成一個場域可能有同時50支相機要進行即時進行辨識...

這是我第一次感受到要從工具軟體/程式到軟體系統產品的陣痛期，也開始覺得會感覺到寫程式不是那麼有趣的事情。

## 第二章：人月神話
### 人月迷思
只有當工作可被切分(partition)，而且投入工作的人**彼此不用溝通**(commmunocation)，人力和工時的互換才算完成。

作者認為用人月估時程並不可靠: 需要10人做1年的專案，不見得能用120人在1個月內做完。討論這部份時，作者說出了本書的經典句子:
> 生小孩就是需要九個月，你叫多少個媽一起生都一樣。

套用 multi-threading 加速程式的觀點容易理解，關鍵在於資料 (工作) 相依性。**只有在工作能完全切分互不影響的情況下，才能藉由加一倍的人手而縮短一半的時間**。

*一但有了相依性，更多人員反而增加溝通成本。*
### 時程估計
作者對時程的經驗法則:
* 1/3 規劃。
* 1/6 寫程式。
* 1/4 組件測試和早期系統測試。
* 1/4 系統測試，完成所有組件。

寫程式只占 **1/6** 時間，軟體專案不順的主因是缺乏良好的時程規劃。事前排定測試時間可以提高品質，避免進度落後時，無法把測試列入考量。

### 議題討論
除了業管直接給定上線時程？PM們有沒有什麼什麼估計開發人月的方式？

## 第三章：外科手術團隊
### 運作方式
作者提倡「**外科手術團隊**」。以一人為主，其他人輔助處理一個小專案。公司再切成多個團隊處理各個專案。這個作法可因少數人的決策兼顧概念整體性，且減少溝通而提升全員生產力。

團隊之間是樹狀結構是不可免的結果，這樣才能有明確的更高決策單位。但溝通仍是網狀的，因此需要特別組織補足樹狀結構溝通不足的問題。

每個專案都有管理者或技術總監，有三種可行的搭配方法:
* 一人兼任兩者，但很少會這樣。一來這樣的人少，二來這兩份工作都需要大量時間，即使有這樣的能力，時間也不夠用。
* 管理者為主，充份授權給技術總監發揮。
* 技術總監為主，管理者幫忙處理雜事。

*管理者最重要的工作是溝通而非做決定。*

## 第四章：專注、民主與系統設計
### 概念整體性
一個強調整體概念性的系統不但開發得更快，測試也快；而要達到這個目的，就代表設計**必須出自一個人的想法，或是極少數人的一致決定**，也就是必須要是「**專制**」的。

而在要維持概念整體性的前提下，又需要多人合作開發時，有兩個技術可以使用，一個是上一章的「外科手術團隊」，另一個則是將工作分為「架構」(architecture)和「實作」(implementation)兩個部分；其中，架構是在說明做什麼，實作則是說明如何做，而將架構設計獨立於實作之外。

### 組織文化
> 我們需要的是傳教士團隊，而不是僱傭兵團隊。

產品團隊的目標是要建立傳教士團隊，而不是傭兵團隊。雇傭兵是叫他們做什麼他們就做什麼，傳教士則是願景的信徒，致力為客戶解決問題。
產品團隊必須負責實現被賦予的明確目標，公司授權產品團隊找出實現目標的最佳方法，並為結果負責。

想要團隊有被授權的感覺、幫顧客解決問題時產生傳教士的熱情，公司就必須賦予團隊很大的自主權。顯然，這不是代表團隊可以做任何他們覺得有趣的事情，但確實可以用自己覺得最合適的方法，去解決公司指派的任務。

> 授權給工程師發揮創意及天賦

建立團隊自主性。讓團隊用最合適自己的方式，去解決公司指派的任務。
**讓整個團隊都對結果產生責任感**
1. 協作是建立在關係上
2. 創新需要專業知識
3. 整個團隊都需要了解商業目標和脈絡情境

盡量給予工程師自由，讓他們想出最好的解決方案。
每天與工程師的討論有兩點：
1. 針對產品「探索」流程中提出的物件，徵詢工程師的想法和意見
2. 討論工程師要求你針對他們正在開發以便「交付」的物件，釐清一些問題

### 議題討論
> 難道成為一個好PM，只能放棄夢想...理想與現實，不應該是二分法！

大家都曾經擔任過團隊成員或工程師的角色，請換位思考，當時的你！希望PM的樣貌以及合作方式？

而目前！擔任PM的你，有沒有符合當時的期待，或是！當時的期望的樣子其實不完全是真正PM的樣貌...

## 第五章：第二系統效應
找不到重點qq

## 第六章：意念的傳達
這章想要討論的主題在於讓參與專案的人都能夠完全無誤的瞭解專案的需求、進展，將討論的架構、規範、介面等等透過結構且文件化的方式公開透明的傳達給所有人，確保大家on the same page.

“架構設計師都必須隨時準備好提出一種實作方式供人參考，但不應該企圖硬性規定採用特定的實作方式。”

## 第七章：巴別塔為什麼失敗？
專案的溝通不良容易造成非常多的後果，例如時程落後進度、功能開發誤解、甚至是從需求就產生脫鉤。因此，無論團隊或是專案大小，**專案的管理者需要確保專案進度透明**，每個小組應該要盡可能運用各種方式來做溝通，不管是非正式的方法（電話、電子郵件），或是會議、專案工作手冊等等。

「組織」的目的，則是要透過人力配置和專業分工，來減少溝通量。傳統的樹狀結構組織主要是源自於權力的責任結構，但是以溝通結構來說，則是會是網狀的，這樣才可以避免溝通不良的問題。

### 議題討論
專案為什麼會失敗？（*請大家分享失敗專案的經驗*）
技術?
時程?
人力?

## 第八章：預估

> 寫一個獨立小程式所花的時間，不能拿來做為預估整個軟體系統產品開發時程之用
>
規劃、寫文件、測試、系統整合以及訓練的時間，都是必須加以考量的，線性外推種天真的做法是沒有意義的。

> 費力程度=(常數)*(指令數量)^1.5
>
即使只考慮個人創作，不含任何和別人溝通的代價，寫程式的費力程度仍然跟程式的大小呈現出指數倍數的關係（某些研究指出指數值是 1.5 左右）。