最近在做網路讀書會的問卷調查, 裡面也請網友給我們建議想看哪一本書? 人月神話這本軟體工程領域的經典之作也列在其中, 這本書讓我想起在前公司當軟體專案經理的往事, 當時高層主管是美國人, 他推薦我看這本書, 並跟我說雖然這本書有點歷史, 但是無論哪時候看, 裡面講的現象依然適用, 所以過了多年後更有網友直接點名希望我們辦這本書的讀書會, 可見這本書在軟體界的重要地位.
這本書為何成為經典之作 ? 我想應該是很多軟體開發的一些重要觀念與忠告都是Frederick P. Brooks 先提出的, 這本書提出一些經典話語, 您大概也常會聽到, 例如軟體開發沒有銀色子彈 等等觀念, 到了2016年 您在想一下目前的軟體開發真的有銀色子彈嗎? 當年在帶團隊的時候, 因為開發效率一直落後, 我開始評估是不是使用的開發工具出了問題? 是不是使用的程式設計語言對團隊而言門檻太高? 當時的主管即告誡我軟體開發沒有銀色子彈 🙂 這個觀念.

那麼軟體開發團隊為何有人月神話提的種種現象?

這邊我分享一下在另外一本書 “最後期限” 作者是Tom DeMarco 提出的一個軟體開發團隊的一個模型

看了這張圖後您應該會更了解為何軟體開發團隊 1+1 不會等於2 🙂 而且當軟體專案延遲的時候加人力以為會解決問題, 根據Brooks法則，增加人員到一個已經延誤的專案裡， 等於是火上加油 , 所以要如何解決人月神話的問題? 這張圖應該會給你一些想法.

對於人月神話的讀書會有興趣嗎? 歡迎來參加讀書會, 一起來互相激盪與交流

讀書會報名網址 http://www.accupass.com/go/mythical

One More Thing

無論您是軟體專案經理或是軟體工程師對於工作效率不彰的問題該怎麼辦? 每天要如何運用時間將力氣花在槓桿值最高的工作上? 在工作上要如何學習讓自己的職涯成長不斷地攀升, 推薦另一本書 The Effective Engineer的讀書會.

報名網址是 http://www.accupass.com/go/effective

為何這本書我會跟人月神話放在一起推薦? 不要忘記軟體開發的產出最重要的角色之一-軟體工程師, 從以上Tom DeMarco 提出的軟體開發團隊模型可得知如何讓一群軟體工程師融入團隊得到最高的凝聚效應? The Effective Engineer這本書從工程師個人成長角度出發, 也對提升您的軟體開發團隊整體效率非常有幫助.
作者Edmond 在知名矽谷新創公司Quora曾經擔任新手工程師的職前訓練工作, 除此之外, 這本書裡面講的觀念與方法也是他訪談許多矽谷知名公司的資深工程師加上他閱讀多本書綜合出來的成果, 如果您目前也是在創業或是在新創公司上班, 這本書會是您必讀的經典也是灣區日報推薦給開發者看的好書之一

喜歡我們的分享嗎? 記得使用以下社群分享按鈕分享給您的社群朋友吧!

之前因為銷售協同作業的軟體曾拜訪過不少開發團隊, 無法如期出貨一直是常見的問題.  追根究底, 其實很多延遲不是大家不努力做, 而是每個人都擔當許多產品的開發責任.  有的甚至技術越厲害的拖得越嚴重, 為什麼呢?  所有的產品開發都要等他完成他那個部分, 最厲害的工程師反而變成瓶頸.  這種問題不管MS Project規劃得再好, 工作拆得多精準, 每項工作追蹤得多徹底, 都沒辦法改善這狀況.

最近團購剛拿到Creating Great Teams-How Self-Selection Lets People Excel這本書, 翻開來看了兩個章節. 邊看邊點頭, 覺得這裡面講的現象不就是很多客戶說過的問題嗎?  本書作者輔導紐西蘭最大的電商公司Trade Me, 他們在快速成長中遇到了“人月神話”的現象, 加人也不會讓事情更快完成, 團隊人數成長反而減緩出貨速度.   每個人沒有固定的團隊, 有哪些專案需要他, 他就要加入, 每個人的時間是零碎的, 要同時完成不同專案的指定工作.  整個工作場域充滿了要交接或被拖延的鳥事.  專案經常要暫停,因為有時大家都在忙別的事, 沒有人有時間做這專案.  沒有人了解人力資源和專案的現狀, 也沒人可全盤說出現在整個公司到底發生什麼事.  每個人的工作進度被其他人錯綜複雜的影響.

作者針對這問題解決方法是:  減少等交接的問題與交接相關的默認知識損失, 把這些人從這複雜的矩陣中脫困, 確定一個人只參加一個團隊, 一個團隊在任何時間內都只做一個專案.

有兩份資料顯示: 穩定的團隊的生產力相對高出不穩定的團隊很多

• Rally Software研究說軟體開發團隊95%+專注與50%-專注的生產力是2:1
• 2014年一篇”The Impact of Agile Quantified”白皮書的資料, 從將近10000個團隊研究顯示, 穩定的敏捷開發團隊相較其他, 生產力多出60%

所以與其讓一個人一直處在變動的團隊環境下工作, 不如讓一個人能有穩定的共事團隊.

在這樣有實際數據證明的“一個人, 一個團隊, 一個專案, 高生產力” 的架構下, 作者繼續將解決方案帶到如何組團隊.  以一般的方式, 多是由經理人挑選團隊成員.  作者認為, 如果小於10人, 經理人有能力識人帶人的話, 應該沒問題, 可是當團隊變大, 由上面挑人就出問題了.

作者分享了Spotify的組織型態, 也由Spotify的組織延展Self-Selection的方法. 很值得大家參考.

Spotify的組織分部落(Tribe), 部落裡有跨功能的小隊(Squad), 小隊裡有各種專長的人, 同專長的人還可組成協會(Chapter), 分享經驗, 另外跨小隊跨專長還能組成互助會(Guild).  部落像是小隊的創業中心, 小隊由開發需要的各種專長人員組成, 如UX設計師、前端開發設計師、後端開發設計師、測試工程師等, 協會像是知識經驗交流中心, 而互助會則幫助整體的開發環境更自動化如測試自動化、版本發佈自動化, 或文化流程的改善如Kanban, 敏捷教練等都以互助會的方式來進行, 我看起互助會很類似DevOps的作用.

這裡面很重要的是, 這些組織都是自治組成的, 尤其是跨功能的小隊, 採用的是Self-Selection方式.

根據J.Richard Hackman的研究, 一個團隊績效多好, 60%取決於這個團隊的設計, 30%取決於這團隊開始的方法, 10%才是後續的領導和培訓.  好的團隊設計並非一定要一群明星工程師, 而是在技術、喜好、人格特質上能互相支持的組合.   由此看來一開始要如何組團隊就已經決定團隊績效會在哪個範圍了.

要一下子改變整個公司文化似乎不是那麼簡單.  如何讓公司嘗試這種Self-Selection方式的好處呢?

澳洲一家很有名的軟體公司Atlanssian(他們的Jira相信很多人聽過)發明了一天體驗自主工作的活動ShipIt Day, 這是類似黑客松的活動, 讓員工那天自己選擇一起合作的團隊成員, 一起發想主題, 在當天完成對公司有益的專案.   Spotify、任天堂和許多科技公司都相繼在公司內舉辦這樣的活動, 來激發內部的創意, 讓大家感受自治的好處, 以及快速出貨的重要性.  作者在她輔導的公司Trade Me也舉辦多次ShipIt Day的活動. 她觀察到:

• 大多數人很自然的組成3~6人跨功能的團隊. 善於協同作業的T型人才特別受歡迎.
• 沒有人選擇加入一個以上的團隊或專案.  一般公司多以如何善用每個資源做為成功的衡量要點, 一人多工變得很平常. 可是在實際運作時, 以早點出貨為前提下, 沒有人認為一次做多件事會比較有產出, 也沒有人認為自己參與多個團隊會讓自己更有價值.
• 組團隊時寧可找可以面對面溝通的, 即使有一位超優秀的同事遠在他方, 他們還是比較喜歡找可以看得到可就近溝通的人一起工作
• 當團隊的每個成員都很清楚團隊的目標, 將很容易形成共識, 不管做決策、解決問題都會容易很多
• 每個團隊成員都高度地被激勵, 他們很享受這樣的經驗, 且完成許多事.

接下來, 要怎樣在公司內大規模的實行Self-Selection呢?  我還沒看到那裡, 也不能把這本書全說了. 就等您來看這本Creating Great Teams-How Self-Selection Lets People Excel 囉.

不過我跳到後面去看實行Self-Selection的方法所產生的長尾效應:

• 求職的人指名要到這家公司, 就是為了在這裡工作有選擇的自由
• 公司的擴張變得很有效率, 因為Self-Selection變成公司開新團隊的標準方法
• 員工幸福指數增加, 工作壓力降低, 生產力上升
• 經理人不用花太多時間處理人和人之間的問題, 有比較多的時間去計畫、決策、支援並幫助員工成長.
• 公司擁有高度激勵人心的自治文化, 如此也有好的決策品質, 和成長的動能.

看起來Self-Selection的方法很不錯吧.

回到現實看看我們現在每天的工作方式, 有什麼是我們有能力去改變的呢?

延伸閱讀

• Facebook如何一面成長一面維持它的工程師文化

Soft & Share在Facebook有經營兩個粉絲團, 歡迎來加入

• 研發團隊協同作業解決方案
• 軟體開發團隊工具心得分享

喜歡我們的分享嗎? 記得使用以下社群分享按鈕分享給您的社群朋友吧!

曾有位朋友跟我說他們公司有太多緊急事件要處理，而且每個人同時做很多專案， 排程幾乎只是參考用， 大家也不可能有空來寫 issue， 做追蹤， 所以任何專案管理， 協同作業工具都很難派上用場。 我很納悶這樣的問題要如何解決….

最近剛好看到這本書 Project Portfolio Management-Increase Your Capacity and Finish More Projects， 書中特別指出， 如果沒有做 Project Portfolio Management， 將會不斷有 Emergency出現， 這樣會降低整個 portfolio 的管理容易度， 造成不斷搶人的狀況， 將團隊成員完成專案的效率降低， 也降低完成專案的數量。 這跟朋友說的狀況很類似。

這幾天剛把這本書看完，覺得這本書寫得太好了，以下簡要整理， 希望對在類似工作環境的人有所幫助。

實行小建議

• 專案要排序，且要決定哪些專案要 commit， kill, transform， 或暫存待執行。
• 如無法準確預估專案獲利與風險，以 Scrum 分段 deliver 部分user stories(requirements)的方式來試 run， 預估velocity，幫助forecast， 同時觀察可行性。
• 越高風險但卻是高獲利的案子越需要小規模試run。
• 專案資訊越透明完整，越好做 PPM。
• 至少一季做一次 Project Portfolio Review。
• 以公司整體利益為指導原則做 PPM 決策。
• 需檢查公司的 bonus 或薪資政策是否配合，如果專案經理的 performance 是比賽同時間內完成的專案數量， 那…..

• Project Portfolio Review 目的: 決定專案先後順序，妥善安排資源， 全力完成對公司最有利的專案。
• Review 參與者: 高層、 專案經理、 部門經理。
• Review 時間: 最好不要超過 3 個月， 當 release 時間需要修改時，當重要客戶需要新功能或產品時， 當知道競爭對手將有新產品上市時，當技術更新時， 當產品可以部分完成時， 當資訊足夠到計畫下一版時， 當有錢有人來做新專案時。
• Review 需要的資料: 每個專案的內容， 相關客戶， brundown chart/velocity chart，階段可demo 產品或 version 完成工作單， 風險與障礙， 人力分配。

Review應問的問題:

• 排序的準則？ （要配合公司目標， 策略， 願景， 獲利)
• 對於每個專案在每次 review 的時候都要問是否仍與整體策略相符， 值得繼續做下去？
• 從上次 review 到這次 review 之間, 到底完成了哪些？ 進度如何？ 完成速度怎樣？
• 專案進行是否有遇到什麼困難？

專案排序的方法

計分: 可考慮的項目如

Qualitative: Alternative 有替代方案？ Effect完成後的影響？ Success Picture 專案成功的樣子?

Quantitative: 獲利？ 市場拓展？ 既有客戶再消費？ 降低成本？ 增加公司競爭力？

比較法: Single-Elimination Tournament單淘汰制， Double-Elimination Tournament雙敗淘汰制。

p.s. 作者建議不要用ROI來排序， 因為 ROI 通常試算不準的。