[add] add 慎防一人團隊.md

common/慎防一人團隊.md

@@ -0,0 +1,53 @@
+# 慎防一人團隊
+
+若說到「及早並頻繁地驗證」的重要性，有個常見的情境常常會讓我們發生很多與這個概念背道而馳的狀況，那就是「一人團隊」。一個代表性的矽谷故事中，一個工程師，他獨立設計並開發了一個很有野心的系統。期待早點運作他的專案，所以請了團隊夥伴為他龐大的 code，做 code review。之後才發現他的 code 有著設計上的重大缺陷(major design flaw)，並被告知他必須用完全不同的方式來重新建立這個系統。
+
+有個夏天，當我還在 Google 實習的時候，我幫 Orkut 開發了搜尋的功能。（Orkut是一個 Google 早期社群網站）。我努力的開發這個專案，為了搜尋結果，調整著 indexing，ranking，以及過濾著使用者資料。我很理智地與同事們檢查我最初的設計，但隨著我每天累加的工作量，加上對 code review 沒有太多的經驗，我自以為我並不需要拿出我真正的 code 來 code revie。到了我實習階段的最後一個禮拜，我將我這個夏天所做的專案，送幾千行的 code review。Google是依照 code 有改變的行數來區分 code commit。在我 mentor 的信箱裡面電子郵件表示著「Edmond寄了極大的 code review 給你」。("Edmond sent you a ginormous code review")
+
+吃完中餐，我與其他實習生，很隨性地聊到我的”程式炸彈“（code bomb)。我對於我這個夏天所完成的專案感到沾沾自喜，但他們聽完，全部嚇死了。
+
+「你說什麼？！如果你的mentor找到明顯的設計錯誤怎麼辦？你的mentor有足夠的時間做全部的review嘛？而在他找到的前提下，你又有足夠的時間能解掉所有的issue嘛？如果他不決定讓你check in你極大的code commit？」
+
+我整顆心有如沉入大海。難道我整個夏天都將浪費掉了嗎？我花了我最後一個禮拜在 Google 擔心這件事會如何發展。
+
+所幸，我的 mentor 樂於助人，且在我實習階段結束後，願意處理需要面對的 issue。我得以 commit 我的 code，且這項功能在我離開後幾個月內正式運作。但有很多部分都需要找機會處理，且我的整個專案恐因此終止。回頭來看這件事，很明顯的，如果我頻繁地 commit 我一小段一小段的 code，我的成果不會被單獨孤立這麼久，且我可以去除大部分的風險。而我的 mentor 會有更多時間 review 我的 code，以至於我有更多有價值的回饋來改進我的 code。最後，我很幸運能在我職涯早期，因為獨立專案學到了這門課，而只付出少少的代價。
+
+有很多情形下你必須一個人獨自進行一個專案。有時候這是為了能夠避免不必要的溝通成本，專案負責人或 Tech head 會安排一些專案僅由單人負責進行開發。另外有些時候，團隊會內部分成好幾個一人團隊，來單獨處理小的 task，來讓整體協作更容易。部分組織會主張他們的升遷過程，需要工程師證明他們能獨當一個專案。這樣能激勵工程師對於升遷做最大的努力。有些工程師就是喜歡能自己獨立作業。
+
+一人團隊開發專案，本質上是沒有問題，但仍然有些額外的風險容易降低專案的成功。首先也是最重要的，開發過程中很難獲得回饋(feedback)，而你需要回饋來驗證你的開發是可運行的。除非幫你做 code review 的工程師，跟你在同個團隊，且與你開發同個專案，否則你很難從 code reivew 中取得好的回饋。如果你對於 `取得回饋`(feedback loop)這件事不以為意，你有可能會較晚拿到回饋直到你以為你的 code 很完美。 而如果你到了專案尾端，都尚未發現你開發方向是錯的，就容易前功盡棄。
+
+一人團隊開發專案還有其他風險。當你獨立作業的時候，開發上的低潮較易使人感到喪志(demoralizing)。你必須面對下述狀況：困在你無法逃脫的沙坑，磨掉單調的工作，以及許多能藐視你理解能力的bug，如果有人能陪你分擔這些痛苦，能量比較不會這麼快耗盡，也比較能承受。只要一件事情卡住，便能停止專案進度，延後專案期限。我曾經經歷過，也看過別的工程師經歷過。只要一人團隊裡，還能額外配一個成員，縱使有人進度卡住了，整個團隊依然能維持著動力繼續前進。
+
+同樣的，當你獨立作業的時候，開發上的高潮較不易使人感到有動力。與團隊夥伴一起慶祝達到開發上的成就，是鼓動團隊士氣最好的方法(boost morale)。如果你是一人作業，當你終於解開了令人沮喪的 bug，誰能跟你擊掌？此外，當你知道，你的團隊夥伴是需要依靠你的時候，是會增加你的責任感(sense of accountability)。希望幫助夥伴達成目標的渴望，是可以讓每一個成員沉浸在開發的動力上(dips in motivation)。
+
+即使你仍然是一人團隊在作業，也不用絕望。上述的風險是可以被克服的。Steve Woziniak 最初在他家（之後到 Steve Jobs 的車庫）開發了 Apple I 與 Apple II 電腦，軟體與硬體皆自己獨立開發。當他的作品，自己興趣使然的玩具，從 Homebrew Computer Club 到創造了個人電腦革命，你怎麼看這件事情？一個關鍵的原因：Wozniak 有 Jobs 能給他平衡點(counterbalance)與回饋來驗證他的想法。縱使 Woziniak 內向，且表面上只做自己的東西，但他並沒有閉門造車，而是被 Jobs 的遠見與野心所鞭策了。最後，他們兩位新創了Apple公司。
+
+有如 Woziniak，我們可以建構出必要的回饋管道(necessary feedback channel)，來增加專案的成功率。以下是其策略：
+
+* 對於回饋保持開放與接受的心態
+如果你對於你工作內容保持防禦心態，你便很難將回饋聽進去，之後人們就很難有意願再幫忙。取而代之，要保持樂觀的心態去學習。不要將回饋與批評視為個人攻擊，而是視為改進自我的機會。
+
+* 及早且頻繁地 commit code
+更動量大的 code 是很難 review 的，需要花很多時間才能獲得回饋，如果結果是你開發根本偏了方向，浪費時間，浪費精力。專注在迭代進度，並利用迭代式 commit 來徵求回饋。不要成為發出極大 code review 的人。
+
+* 從透徹批評中要求 code review
+給不同的工程師做嚴格地 code review，是有很大的差異。如果你急著將 code 送出去，你也許會想將 code 交給會粗略 review 的工程師看過且批准。但如果你想優化 code 的品質，或者你想確保你的 code 可運作，你應該找能在 code review 中給予你深思熟慮批評的工程師。開發早期從團隊夥伴中獲得嚴厲的回饋，總比後期從用戶得到回饋得知某某功能無法使用來的好。
+
+* 從團隊夥伴身上獲得此想法的回饋
+獲得回饋，最直接的途徑是：直接要求它。如果你能佔用對方幾分鐘的時間，在白板上討論你的想法，那就直接詢問正躺在飲水機旁的沙發上的團隊夥伴。研究指出：對其他人解釋一個想法，是自我學習最好的方法之一。此外，你的解釋也許會揭露你理解上的漏洞。大部分的人都想要幫忙，且對於能用片刻時間去接觸一個不同且有趣的問題感到感激。也就是說，如果你想要保持你的回饋管道未來仍暢通的話，要對你夥伴的時間感到尊敬。事前討論的準備要做足。確保你可以清楚描述：你嘗試解決的問題，以及你已經嘗試了哪些方法。討論過後，作為回饋，你也可以在需要的時候為它們的想法給出意見。
+
+* 先設計新系統的 interface 或 API
+先設計好 interface，相關的 code 完成時就會看起來和 prototyping 的時候一模一樣。新建一個使用交互的具體模樣，會使不好的假設，或者遺漏的需求給浮出來，長期來看會節省你的時間。
+
+* 先發送你的設計文件，再投入你的精力去寫 code
+這或許看起來是增加額外的開銷，但這是投資10％的努力，去驗證另外90％你計劃要做的工作的範例。文件不需要特別正式，它可以是一個提到很細節的 email，但它必須夠全面地使你的讀者理解你將做的事情，以助於能夠問出清晰的問題。
+
+* 如果可以的話，把正在進行的專案架構描述出來，讓你的夥伴們在這個專案試圖解決的問題上擁有共同的思考脈絡。
+與其與你的夥伴，在不同的專案各自開發，不如考慮一起做同一個專案，之後再一起解決另外一個專案。又或者，考慮與你的夥伴，在同一個時間，分別開發情境相似的功能。這麼做可以建立團隊間相通的思考脈絡，減少討論與 code review 上的摩擦。團隊依序共同開發專案，而不是彼此獨立作業，如此更能增加學習優勢如：每個專案可以更快完成，這樣在指定的時程上，你才能在專案上發掘更多的可能。
+
+* 先對有爭議的功能征詢同意，以防投入過多時間
+這意味著在討論的過程，可以嘗試採用該想法，並開發出 prototype 來說服相關的人員。有時候，工程師對這種推銷與營銷形式，誤解為辦公室政治而反對，但從有利觀點來看，這是一個公平且合乎邏輯的決定。假如從一討論得到回饋只需要幾個小時，但從實作上得到卻需要幾個禮拜，那前者這種較短的路徑，以至於更早獲得回饋的方式就極度有價值。做某個領域的功能開發卻得不到該領域前輩的認同，代表你選擇的實作方式是錯的。然而，即使你認為你錯了，這對話至少會把其他人在意，並且你應該要注意的問題給標示出來。(假設你決定要處理的話)
+
+
+上述策略的目的在於克服：當你獨自開發時，收集回饋中會有的困境。而這能幫助你更早並頻繁地驗證你的想法。 `當你處在一人團隊，且xxx的話，這些策略顯得特別重要。（They're particularly important if you're working on a one-person project, where the default behavior, unless you're proactive, is to work in isolation.）` 但其中有些策略，套用在你跟你夥伴的團隊也會同樣有效。Brian Fitzpatrick 與 Ben Collins-Sussman，兩位工作於 Chicago 辦公室的 Google 工程師，在他們寫 Team Geek 這本書時他們很準確地描述了這樣的心態：「軟體開發是一場團隊合作的運動」。即使你比較喜歡獨立工作，當你將你的工作視為團隊工作且建構出回饋管道的話，你也會比較有效率。
+