Scrum - 務實的彈性，千萬不要削足適履

夫所以養而害所養，譬猶削足而適履，殺頭而便冠 ......除小害而致大賊，欲小快而害大利

--- 淮南子說林訓


雖然說Scrum的方式與工具十分簡單，能務實並且彈性運用比照著字面嚴守方式來的重要。不過「務實彈性」和「削足適履」有時候只有一線之隔。

形式主義的削足適履

某些形式主義分子在執行Scrum上，會嚴守大部份framework的要求：每日站立會議，燃盡圖更新，user story和PM確認...等等。達成基本要素，似乎就是必要的事。

但是實際檢視其內容，偶爾會有怪異之處，而這些怪異之處，總是自然生出個理由：「因為我們team比較不一樣，所以有不同作法」。但其實以軟體開發來說，每個team統統都不一樣，而是否能有不同的做法，乃是看有沒有掌握agile的精神而定，而非把不一樣當作理由。

常見的怪異之處有：

* 每日會議除了堅持站著開之外，其他完全不堅持，會議中仍然會試著討論專案問題與技術解答。

* 在幾個sprint之後，仍然無法得知專案團隊的速度，因此仍然常有在sprint快結束時強迫加班的情況

* Scrum Master或者team leader會指定工作項目的完成時間

* 出現一些時間長達3天以上的工作項目，但卻又無法更細分階段或者細項。

* 在sprint結束的檢討會議(Retrospective Meeting)似乎都是在檢討別的單位的合作問題。


這些怪異的狀況都是削足適履的表徵。Scrum的精神在於實況並務實，因為「要Scrum」而做出怪異的行為，還不如乾脆不要使用Scrum作為開發方法論。

務實彈性的例子：以功能為sprint

sprint的基本精神在於每個sprint之後，都會產生可「交付」的結果。一般情況而言，專案的每個sprint時間長度是固定的，以符合Scrum的time-boxed精神。

但如果一個軟體產品已經是5.0版，功能趨於穩定，未來的挑戰，其實在於更快速正確的回應市場變化，則其實可以將time-boxed改為feature-boxed。

上圖取自：http://comsysto.files.wordpress.com/2010/06/scrum_cycle.png

簡單的說，每個sprint的開始，由產品擁有者(PO或PM)選定一個「最最最高優先」的user story。只能有一個，不多也不少。接下來的流程，和一般的Scrum相同，break down開發細項之後，由專案成員評估時間。

略有不同的地方在於，評估確切完成時間之後，就是這個sprint需要的時間。因此，可能是2週，也可能是4週8週。完成的定義當然是變成「可以交付的產品」。因此可能是5.0.1版。

假設sprint plan會議完成，決定是5週，之後就和一般Scrum一樣，在5週之後準時交付產品給產品擁有者。而產品擁有者應該會「立刻」將產品放到市場，看看這個「最最最高優先」項目有沒有達到預期的市場反應。下一個Sprint當然也是選擇一個「最最最高優先項目」，可能會花2週，也可能會耗時8週。

對於已經成熟軟體產品，這樣調整的最大好處是，快速取得市場反應，而非等9-12個月之後產生一個6.0的大改版。

產品擁有者(或者PM)自然會對自已的判斷有完整的責任歸屬，畢竟，如果幾個sprint都交付了產品經理認定的最最最高優先項目，而是市場反應卻不怎麼好，那麼產品擁有者當然要負起責任，花更多的精神來瞭解市場，並且將市場需求轉化為適當的user story。


每一種務實的調整，都有其優點和缺點。

「以功能為sprint」的例子中，最大的缺點在於，稍微控制不當，就會變成傳統瀑布開發模型。而時間估算稍有不當，就會容易延長專案難以收拾。因此每一次務實的彈性調整，都應該在sprint之後的檢討會議上，確實檢討改善。


參考：Scrum的缺點

軟體專案的現實：解決人的問題

無論是否採用agile的開發方式，所有軟體專案，最大問題的來源都是人。

人的問題，通常會極現實的影響專案的進行。然而，妥善運用agile的精神和Scrum的方法，有機會讓人的問題降到某個程度。

某個朋友，姑且稱為K，在專案扮演專案經理的角色，遇到以下狀況：

我最近有遇到一個問題，不知道怎麼辦，下面的人一直做不到我的要求，或者動作很慢，即便壓日期給他，他還是沒辦法達到，但實際上它任務並不多，只是開test case，我不太知道怎樣push他，我又不想來硬...他只有這個任務 平常又常常看他在上facebook, line....覺得要當一個讓人喜歡的lead真的蠻難的....


這個問題非常典型。

以敏捷開發(agile)來說，解決方式似乎也很簡單。首先專注於優先項目，接下來根據事實檢視工作，最後才考慮能力問題。

一：專注於優先項目

每個人在Sprint之中一定有正在執行的項目。確保每個人都是「專注」於目前最優先的項目是Scrum master最基本的任務。

即便不是採用Scrum也一樣。團隊成員必然在某個時間點有一個特定任務。專案經理或領導者(leader)當然必須確保，在這個時間點他只會專注在這個工作任務上。

對於剛剛成立的團隊來說，要確保團隊成員專注於目前任務上的方式很簡單：就是腳踏實地的「問」。在該成員一來辦公室的時候，就坐到他座位旁，親切的詢問他昨天早上在做哪些事情，昨天下午在做哪些，並實際上「看」到做的結果。就可以確定他是否專注，而能確定是否做到真正的效果。

整個詢問的重點都是在了解事實，而不是監督細節。因此每天頂多也只針對「需要幫忙的成員」，一起坐著看實際上的狀況。

二：工作檢視

以Scrum而言，每天的會議(無論是不是站著)就是為了統一工作情況檢視。完成就是完成，沒有完成即便是已經達到99%也一樣是沒有完成。當然，前提是在Scrum開始時有定義「什麼叫做完成」 - Definition of Done。

如果不是採用Scrum，則應該盡可能在團隊開始時，就先定義何謂「完成」。

以開test case為例，完成是指把要做的功能的test case詳述在某個測試文件管理系統上？還是只要先用excel或者wiki列出來即可？test case完成後是否要先讓團隊成員審閱，看看有沒有問題？要不要先估計每個test case執行會花的時間？test case的前置作業 - 例如建立測試資料等等，是不是也要涵蓋在其中？

當有完整的工作完成定義之後，要讓負責進行工作的人「決定時間」，而非「被決定時間」。

以軟體專案而言，任何超過2天的工作項目(task)，都應該分階段完成。畢竟，就事實而言，一個人不可能「連續工作2天」，每天一定會停住工作，下班回家。而這些階段應該要有階段產出。以test case而言，假設有10個新的user story需要建立test case，則今天完成了4個，表示還有60%尚未完成。

三：能力分配

如果團隊成員的確很專注於工作，而且也對時間/產出有正確的體認。最後的問題就是「能力問題」

團隊成員的能力組成其實非常複雜而且麻煩，牽涉範圍廣。以軟體專案而言，能力並非只是撰寫程式，測試程式，理解規格等等。能否和其他人合作，也是能力的一環。

一個規模中等的軟體開發團隊(4-7人)，如果有一個人的能力「極端」的差，確實會造成專案很大的問題。

在Scrum的情況下，這樣的問題在前兩三個Sprint應該就可以被控制。因為雖然他的產出差很多，但未來的sprint的進度，是以團隊能力來考量，因此Scrum master仍然可以有效掌握專案產出和進度。

在不是Scrum的情況下，可以先找到該成員的相對優勢。排定一些學習項目，來提昇該成員在這個專案中的相對優勢，並且在未來安排相對優勢的工作。值得一提的是，根據經濟學的「比較利益法則」，每個人一定會有所謂相對優勢：請參考這裡，和這裡。

關於軟體開發團隊的個別能力，還需要注意以下幾點：

1. 每個人都會成長，但是....

每個人都會成長學習新知識和能力。但是！在中短期專案裡，必須先考慮個別能力與優勢。

換言之，團隊領導要像下象棋一樣，找到每個人的「專長」，能妥善組合專案，就是個好的領導者。

而差強人意的領導者，則是常常試圖規避個別成員的「缺點」，這樣比較不會出大問題，但也容易產生差強人意的結果。而最糟糕的領導者，則會把人當做圍棋，看到人非黑即白，見到專案漏洞時，看到有空閒的人就直接填塞。這在某些有數百個人的硬體專案或許可行(因為數量在此可以產生品質)，但在軟體開發專案鐵定行不通。

2. 能力是綜合考量...

能力必須綜合考量「全方面」：例如是否好溝通，是否能處理複雜的設計問題，能否開放心胸的就事論事等等。不能僅僅考慮寫程式的能力。

另外，如果覺得整個開發團隊能力都很差。作為一個能自我思考的領導者，應該先思考自己是不是「問題的來源」，甚至要思考自己是不是根本不適合作為團隊領導。

3. 讓不適任的成員離開...

讓不適任的成員離開，某些時候是個可行的解決方案。特別是某些企業管理派別認為，投入時間在不適任的人身上，他有可能變得適任，也有可能不會改變，然而投入時間太多，會造成專案延誤。

以Scrum的角度來說，這個情況不太會發生，因為2-3個sprint之後團隊速度已經確立，無論適不適任，專案產出速度不太會再改變。因此剩下的問題僅在於「換個人會不會更好」。而以中短期(3-6個月)的軟體專案而言，讓破壞性的不適任者離開，當然是解決方式，但不見得要「找另一個人進來」。

---

相關文章：人才管理，心智圖，為自己工作...

Scrum (實況) - 瞭解事實才能領導專案

近年來在符合Agile精神的各種專案方法論中，Scrum應該是最簡單，也是最熱門的。

雖然簡單，但要掌握其精神，必須對抗長久的習慣，而這並不容易。

目前市面上也衍生各式各樣Scrum架構的作法和細節，從一開始的User Story到sprint最後的檢討會議(retrospective)都有琳琅滿目的作法與工具。假如只能選一個最重要的精神，則「實況：瞭解事實」是最最最根本的Scrum精神。(註1)

Scrum架構中，理解事實有很多層面。在此以「角色」「衡量效率」「固定時間」作為範例。

1. 角色

實況(Scrum)只會有三種角色

1. 產品擁有人(Product Owner)
2. 團隊領導 (Scrum Master)
3. 團隊成員 (Scrum Team)

而最根本的Scrum務實精神，在角色所扮演的任務中展露無疑。

也就是：

(A) 只有產品擁有者，才能排定產品功能的開發順序(product backlog)！

(B) 只有團隊成員，才會決定每一段時間，哪些功能會完成！

換言之，什麼事情先做後做，交由最接近市場的人 - 也就是產品擁有人 - 來決定。但是那些事情要花多少時間，是由做事情的人 - 也就是團隊成員 - 來決定！這個作法完全奠基於事實，並且適用於絕大部分的情況。

這和傳統專案有很大的不同。許多專案的時間預估，都不是做這件事情的人來預估。自然就一定不可能預估的準確。

不過，在許多「精采的成功個案」中似乎常常會有一個超強的產品經理，能主導市場，產品進度，甚至使得專案團隊有突破性的創新結果：典型的個案就是第一代iphone直接由賈伯斯(Jobs)作為產品經理帶領開發。似乎就是產品擁有者，主導進度的鐵證？

然而，事實上絕大部分的產品經理都不是賈伯斯。可是，大部分的企業，卻可以雇用到接近賈伯斯擁有的研發團隊品質！！因此，絕大部分的情況下，將產品研發功能相關執行與時間預估，交由團隊成員，才比較可能產出和市場預期的結果。除非該產品經理很確信自己跟賈伯斯差不多，並且也能提出「具體證明」。（就如同大部分的資深程式設計師，都能提出具體的證明 - 程式碼，佐證他的經歷一樣)

2. 以結果來衡量團隊效率

在實況(Scrum)中，一個項目完成的定義就是「完成」。而團隊的速度，取決於每個sprint可以完成多少項目。當然團隊一開始的完成事項的速度，大概很難和自己預估的一樣。

然而，過了兩三個Sprint之後，團隊速度應該已經「固定」，而這個完成工作的速度，就變成「事實」。

要看研發團隊速度在這時候很簡單，打開燃盡圖(burndown chart)，算一下每段時間 - 例如每週或月 - 可以完成多少單位，自此之後，要估計時間，只要能有效估計每個功能(user story)規模大概多少單位即可。

這個事實，原則上不會改變。然而，產品擁有者確有權限可以在必要的時候改變事實。他有兩種選擇：(a) 更換產品功能。(b) 改變團隊。

更換產品功能可能是縮小功能規模。例如原本app支援facebook, linkedin, google+的帳號登入，考慮市場都在台灣，因此就先做facebook登入即可。

當然產品擁有者也可以改變團隊，重新組織團隊，更換成員。但一旦改變團隊，就必須重新啟動新的sprint，而也會重新產生新的速度。

3. 以取得事實來固定會議時間

Scrum(實況)的會議，必然鎖定會議「目的」以及「時間」。在事實的基礎下，兩者有很大的關聯。

以每日會議為例-- 不管是不是站著開會，一定是一天工作的開始，最多只花15分鐘。成員輪流以1-2分鐘「說明」三件事：

(a) 從上次開會到現在完成了什麼，沒有完成就說沒有 
(b) 今天打算做什麼，而且有什麼會完成 
(c) 遇到什麼困難需要ScrumMaster協助。

這三件事情，只是說明，若有問題，也是對說明的問題，絕不應該討論。要討論是開會之後，相關人等，聚集在適當的地方，最好是某個人的電腦前面，開始幫忙解決。

通常最容易花時間就是遇到困難的時候，大家紛紛都想提議見幫忙，但這並不是「這個會議的目的」。每天5-7人聚在一起，是為了將大家對狀況的認知統一，僅此而已。因為一旦開始討論困難，很有可能變成A和B熱烈的討論起來，其他5個人在滑手機發呆。Scrum Master要根據決定好的目的和時間，具體果斷的打斷討論，讓會議前進。

或許有些人會認為，這樣會破壞創造性思考和創意思維。然而，事實上無止盡的會議才是破壞創造性思考和創意的元兇。在每日會議之後，Scrum Master可以根據遇到困難的情況，重新找適當的人，並且到適當的地點 -- 也就是電腦前面，手腦並用的解決問題，而非在會議室空談。

其他在實況(Scrum)框架中的會議，像是Sprint啟動會議，Sprint結束會議，Sprint檢討回顧會議等等也都是一樣。必然是在特定的目的，特定的時間完成。


將能專注控制的事情完成，才能把時間與思維，留給創意。

---

註1. 因此，敏捷開發中的Scrum方法，中文翻譯應該叫做「實況」，至少也比google翻譯為「爭球」來的好。

註2. Scrum的學習可以參考這裡-> 學習Scrum，或者->Scrum認證

Scrum 認證!? 不要再浪費你的錢了!

管理類型的證照無用論，早在軟體工程界提倡Agile Movement的時候就逐漸存在。

以目前看起來取得成本最高的PMP在資訊科技的評價為例：比較客氣的說法像是這篇：雇用有PMP的專案經理需要更進一步了解其能力。而比較不客氣的說法會像是幾篇：PMP毀了專案管理，或者PMP證照無用。(註1)

而這幾年Scrum的方法論，因確切執行之後確實對軟體產品開發有顯著效益。隨之就有各類型推廣，教育，甚至認證產生。

然而，花大錢考Scrum真的有意義嗎？

(1) 認證市場

技術專業認證，絕對有其必要性，例如：醫生執照，律師執照，CCNA，SCJP，TOEIC，甚至，職業大貨車駕照，乙級中廚檢定...等等。擁有此技術執照，表示你至少「會」做某些事。

然而，非技術執照，只證實「考過」某些考試，一旦考試內容和實際會到的問題有差距，該執照就沒有太大意義。只能代表你對某些考試的努力成果。專案管理，企業經營方面的執照就屬於這類。這類型執照如果成本不是太高，倒也無妨。高收費的認證？等於是浪費錢。

一旦有高收費的認證，自然就會有認證教育訓練市場。教育訓練本身是好事情，可以讓人學習成長，但是，教育訓練本身如果是應付考試，意義就降的很低。

(2) Scrum高收費認證為何沒用？

迄今，Scrum認證有很多種類，單就Scrum Master而言，網路上隨便找，都可以找到以下七種，請參見下表。

證照名稱	考取成本 (以台幣計算)	組織
Certified Scrum Master	$30,000 (含16小時訓練課程)	Scrum Alliance
Professional Scrum Master I   Professional Scrum Master II	$4,500 $7,500	Scrum.Org
Expert Scrum Master	$3,000	EuropeanScrum
Certified Scrum Master	$3,800 (不含訓練課程) $4,500 (含8小時訓練課程)	GAQM
Scrum Master Certification	$13,500	ScrumStudy
Agile Scrum Master	$5,880	EXIN
Scrum Master Accredited Certification	$900	Scrum-Institute

筆者考過並取得最貴的認證以及最便宜的認證。其價格差距很大(三萬台幣 vs 九百台幣)。單就「考試內容」而言，最便宜的考試內容甚至還稍微難一點點。而最貴的CSM (ScrumAlliance)其實也就是台灣各教育機構最努力推廣的認證。

就考取認證作為職場價值這點來說：

1. 如果是沒有任何軟體專案經驗者，透過高收費教育訓練考取最貴的收費認證，基本上，和只自學而通過最便宜的認證，在Scrum基礎知識上根本沒差別。而在Scrum實務運作上，也沒差別：都屬於完全沒經驗。

2. 如果是有數年軟體專案經驗者，「有無證照」對於專案管理來說，只是履歷表上的一撇，一旦遇到真正的艱難問題：在Scrum上採取正確作法的經驗和收獲，遠比考證照的收穫大得多。因此，昂貴證照和便宜證照也無任何差異。

3. 沒有駕照，就不能合法開車。但沒有Scrum證照，在務實的企業中，只要你有足夠實務經驗，足夠證明支持你的能力，根本沒有問題。反之，如果有Scrum證照，但無法足以匹配的經驗，能力，而再加上創意不足，那麼甚至是有害無用。

(3) 建議作法

如果有想考Scrum相關證照，有三個強烈的建議：1.「自我學習Scrum」2.「確切運用Scrum」3.「考最便宜的」

1. 自我學習Scrum：

學無止盡，無論是Scrum還是其他未來可以出現的方法論，都值得一學。但更重要的是，如何自己學習。任何教育訓練都很有用，但也不可能完全取代自我學習。

自我學習的方式可參考這裡：如何學習Scrum 。以及這裡：如何成為Scrum專家，或者：scrum的缺點，或者 ：Scrum三件必要的事。

2. 確切運用Scrum觀念與作法在軟體專案中：

任何專案管理上的知識技能，如果不能有效運用在專案管理上，當然就沒有意義。以Scrum的每日會議(無論是不是站著開會)來說，其基本觀念在於：

「限時」 - 15分鐘
「事實」 - 只描述做完的項目，和下次打算做完的項目。(註2)
「困難」 - 只說明困難，不是要在每日會議上解決困難。

也許現實會讓Scrum Master或專案經理有所調整，但如果調整的方式不能切中Scrum觀念，則取得昂貴Scrum證照也沒有任何意義。(例如每日會議花超過40分鐘，肯定不符合任何一種Agile專案方式)

3. 以實力考最便宜的證照：

不可否認，還是有不少人認為一旦履歷表上有幾個証照，似乎會多一點點面試機會。另外，也有些有專案管理經驗者，自我學習Scrum想要有個目標來證實自己。

以這樣的立場，其實考取最便宜的證照即可。而最好是在沒有任何準備的情況下，抱著隨便考的心態。如果這樣考過了，表示Scrum的基本知識已經深入腦海中，考不過其投入成本也不高。

剛出社會的新鮮人，如果覺得萬一在面試時，有人對便宜的證照有疑慮？你可以客氣的敦請他去考考看，了解一下其考試的品質。

---

註1: 我們不是反對PMP。事實上，在其他工程領域PMP有其必要性。例如：cern的LHC是一個橫跨數十個國家，涵蓋土木，電機，資訊的龐大工程，PMP條列的九大項目，五十多種可能的文件在此就有點必要性。本文反對的是，以PMP(或其他管理證照)來判斷一個專案經理有沒有能力執行資訊軟體相關專案。

註2: 何謂做完？(definition of done)也是Scrum team需要在專案開始前定義好的。

註3: coursera.org 提供各種課程修業完成認證，目前沒有ScrumMaster，但是有類似Agile Management的課程，上課是免費，不過，取得認證約為3000~5000台幣之間。

心智圖 - 進入職場第一個必備技能

在畢業之後，投入職場的那一瞬間，假如你突然失去記憶，喪失所有技術能力，你最希望先恢復什麼能力呢？

相信一定是「學習各種技能的能力」「連結不同技能的能力」「延伸整合技能的能力」這類型的選項。概念上類似神燈可以實現一個心願，稍微有智慧的人，第一個願望，一定是希望有無限多的心願。

「心智圖」mindmap是最簡單，最容易學習的能力，可以用來連結學習延伸其他的技能的基礎。它應該是踏入職場第一個必備的技能。

心智圖極端簡單（請參見心智圖wiki），不過就是把心中想的主題畫在一張紙的中間，把跟這個主題相關的重要「事情」「項目」「動作」...等等，用線連在一起，而後還可以再延伸這些「事情」「項目」「動作」到其他細節，或者其他主題。

雖然心智圖很簡單，有不少人宣稱在高中就已經會用，但實際上熟練地使用者卻很少。

下面這張圖就是在撰寫這篇blog的後所畫的第一張心智圖：

這篇文章所用的第一個心智圖

心智圖的繪製，沒有任何特殊技巧可言，它只是想法的延伸。換言之，心智圖本身無法代替思考。但他可以讓抽象思考具體化，讓你更容易有全面的視野來觀察任何主題。這和哈利波特裡面的儲思盆有異曲同工之妙。只是你不需要去念霍格華茲，也可以學會使用心智圖。

經常利用心智圖，對職涯發展有莫大助益。然而，在台灣職場上，卻並不常看到有人使用心智圖，更常遇到某些特殊事情發生之後，才想到「當時如果用心智圖做紀錄會不會好一點」的情況。

其中一個主要因素是：缺乏練習，以至於當下沒「聯想」到有此工具。


有三個工作項目，是最好練習心智圖的機會：

1.  即時會議記錄：

即便有超強的打字能力，有意義，並能快速呈現重點的會議記錄，遠比把所有人講的的話一字不漏的記下來來得重要。臨時的會議，有結論的會議更是如此。

一邊開會，一邊將主題相關的人事物，用心智圖快速連結起來，可以在開會的過程中，掌握要點，避免會議「歪掉」，減少會議常見的三大毒瘤：「會而不議，議而不決，決而不做」

會議還沒開始，先畫出主題以及會議之後的行動

做法很簡單。首先：如果你是主持會議的人，會議還沒開始前，先在白板中間畫個圓圈，中間寫會議的目的。接下來先把「Actions」先畫出來。在會議一開始，就確保會議結束前，一定會討論出作法。如果你不是會議主持人，可以畫在筆記本上，這樣確保會議結束前，萬一Actions的圖形之下，沒有任何行動，也沒有人提及要有會後行動，你也會「主動提出」。

接下來，在與會人士慢慢來到之前，先把會議的背景，要討論的事情大綱，畫在主題的周遭，並稍加分類。以簡單的圖像表示與會人士。

會議即將開始前，先將背景以及可能討問的事項在白板列出來。以簡單的圖像代表與會者的討論。

隨著會議的進行，白板會越趨複雜，當然可以簡單的照相紀錄過。

會議的目的，當然是為了「議」- 也就是為了討論。而討論最佳的方式，莫過於把彼此的思維，投射到可以視覺化的地方。心智圖是最簡單，成本最低的好方式。

2.  分析與設計：

有複雜問題的時，可用以分析。例如：專案資源不足，遇到瓶頸，解釋複雜的人際關係等等。

有需要進行的事情時，可用以分析。撰寫技術類型的文章，就很適合先使用心智圖。

以這篇文章為例，在撰寫之前先以心智圖繪製草稿大綱，然後經過一些考量修正，先修改心智圖大綱到自己滿意的程度，在開始撰寫內文。

這篇文章的最終心智圖草稿，和第一張圖有些不同

各類流程，事物的互動，也是很適合使用心智圖分析。以旅遊為例，如果你沒有精美的行程設計，使用簡單的線上心智圖工具來繪製旅遊計畫，是方便又好用的方式。

以線上工具繪製的東京旅遊計畫

3.  任何超過3分鐘的技術問題討論：

程式設計師，專業白領階級員工常常會有「技術討論」。而技術討論光用嘴巴講效果很差。一圖勝千言，簡單的流程圖，循序圖，物件圖，永遠勝過長篇大論。

UML需要比較長的學習與練習，而心智圖卻很簡單。特別是用於觀念討論，大方向的設計（註1），

app使用者登入討論大綱

以mobile APP為例，在討論技術上，也許有程式設計師，在討論之前，先花上幾天搞個極為細緻的流程圖（例如這個），但很多時候只需要只需要三分鐘，在白板畫個圖就搞定。以右圖而言，顯示這個APP在使用這登入的討論大綱。


簡單的東西，通常可以運作得更優雅良久。心智圖並非萬能，它僅只是簡單。掌握心智圖的簡潔，快速，利用它來簡化，分析，記錄事務絕對可以讓職涯事倍功半。

---

註1: 資訊科技比較完整的分析圖形工具還是以UML比較適合

解決軟體專案困境的最爛方式 - 加班

「加班」是解決軟體開發專案困難的常見方式，但也是最爛的方式。(好方法？請參考：解決專案困境的三個方式)

負責控管專案進度的主管或專案經理，如果只會用「加班」這招來解決問題，那就不適合做軟體專案經理。

長期，非自願的(註1)加班沒辦法真正解決問題的各種經驗實證，早在許多談論軟體專案的書籍中存在。例如：人月神話，Peopleware，約耳談軟體，與熊共舞等等。從來沒有看過有任何「專案管理理論或實務認為加班有用」。

最根本的原因在於：知識工作者(軟體工程師)，其產出和付出的「超額」時間根本沒有關係，也因此，加班從來都不會解決真正的問題。

既然如此，為什麼加班文化仍然存在?

常見原因有：

1.  短期效應

特定目的的短期加班：例如參加週末創業活動，或者，產品銷售大會之前的熬夜修正demo問題等等。這些特定的目的，固定時間的活動，確實會讓人拼了命「加班」完成目的。但是，短期效應絕對不能當作一般專案管理的方式，大部份的專案都不是百米賽跑！

2.  專案經理本職學能不足，利用要求加班來展示苦勞。

專案經理沒有其他辦法，只會加總人時。因此，即便人月神話從初版印刷上市(1975)到今天已經超過40年！仍然有不少軟體專案經理即便看過人月神話這本書，仍然不可自免得繼續要求加班。因為，如果有加班，即便專案失敗，以往也被認為「沒有功勞也有苦勞」。

但是，以現在環境變化迅速，一個軟體企業中，如果「一直都只有苦勞」，被淘汰的速度遠比過去還要快得多。

3.  模糊的合約。

在某些糟糕的情況下，銷售可能會簽下模糊的合約，當專案經理看到合約內容時，其解讀方式和客戶「截然不同」。在各種專案經理訓練課程，以及各類商管叢書裡，都會說「要良好溝通」，但實務上，當專案經理手上已經拿到不合理，而且驗收條件極為模糊的合約時，幾乎不可能以「溝通」來解決。如果專案經理，誤接燙手山竽，而又沒有足夠的創新能力和技術能力來解決時，通常會誤以為軟硬兼施的「加班」，或許可解決這個問題。

但是，如果這次不能非加班的方式解決，下次就不可能有更好的方式。其後就落入惡性循環。可以google一下「台灣  接案公司」看看目前的現實情況。

4. 心靈激勵。

無論是「要有創業家的精神！」，或者是「我們在做全世界最偉大的軟體」，甚至是「世界的和平，人類的未來就靠我們了」。而又有太多人誤以為，只要有正確的心靈激勵，軟體工程師就可以像電影劇情，日夜匪懈的工作，還能有創造性的思考解決問題。

5. ...很多其他的理由。

如果你是專案管理人員，之前要求成員加班的理由到底是什麼？如果你是軟體開發人員？曾經被哪些理由要求加班？ 




既然如此，到底什麼是解決軟體專案困難的好方式？
除了可以參考這裡之外，還有三個原則：

1. 永遠都有選擇 - 「Say No」也是一個選項！

認為不正確的事情就應該說「不」。在正確的時間點不說，只會拖延，就不是個好的專案領導者。


以組織層面的角度：

就專案經理本職學能而言，一旦發現自己不是個好的專案領導者，應該要對自己說不，迅速辭職，改當一個好的程式設計師，或許是對專案最好的幫助。

就專案目標而言，倘若使用這的需求不確定，就應該選擇不做，或者選擇先做mockup，讓使用者確定需求，才不會浪費時間。

資源 - 特別是人力而言 - 在企業組織中，永遠都是有限。而良好的管理是透徹於在有限的資源中做有效的分配。加班不會讓分配變得有效，只會讓無效的分配繼續無效。

以技術層面的角度：

技術永遠有選項。一個複雜的功能，可能有起碼5種不同的實作方式，到底是選擇複雜但是有趣，還是選擇簡單，但是堅固耐用？就要視情況而定。

無論什麼事情，一定有選擇，絕對不會有「我們只能加班」這個選項。

2. 專案擁有人，必須參與專案！

近年來流行的Scrum，有一個必要的要點：專案擁有者(product owner)在每一個sprint之後要檢視產出。這個要點非常的重要，遠比正確做好燃盡圖，每天站著開會來得重要100倍。

專案擁有人，需要參與專案的每一階段進展，確實了解專案的人把時間用在哪裡，並且確實了解，每一個sprint產出都是專案擁有人最想要的產出。如此才能確保「做出對的事情」。

如何讓專案擁有者參與專案，就變成專案管理者「一定要做」的事情。

會把PMP的教材背的滾瓜爛熟 -- 溝通管理計畫書是要建立蒐集擷取散布各處的資訊，以及最終處置專案資訊的流程 -- 但實際讓連每一小階段讓專案擁有者「確定產出是他要的」都無法實際做到，簡直沒有任何意義。

在每個階段發個制式的email，裡面塞了很多複雜的圖表資訊，只會讓專案管理者「誤以為」一切都很順利。把確認每階段產出是他要的這件事情越往後延，風險就越大！

3. 磨利斧頭！

技術上的學習，會讓事情事半功倍。太陽底下沒有新鮮事，你所遇到的困難，可能已經有另外17個人遇過同樣的困難，而其中也許有9個人已經解決，解決的人之中有5個把相關資訊放在網路上。只要有正確的英文閱讀和google查詢能力，並能固定的自我學習，充實自己（參考如何充實自己），通常都能以更好更快更有效率的方式，解決軟體上的問題。

但是，千萬不要把「沒有時間學習」當作理由。當你的斧頭已經鈍到無法砍樹，還試圖用鈍斧頭砍樹來表現自己的努力，這是完全沒有意義。學習的目的就是磨利自己，將知識與技能銳化，才不會以無意義的舉動，做無意義的事情，加無意義的班。

---

註1: 凡事皆有例外，遇到天災人禍等不可抗力情況而加班其實算合理，不過即便如此，也應是極短的時間。例如，颱風天放假，隔天需要額外的工作時間。自願性質也絕對不會是長期，例如自己去參加創業週末，某種程度是自己為了自己額外工作，但頂多是一個週末，也不可能連續10個週末都在進行這樣的活動。

相關文章：
-->  換工作的面試-軟體工程師如何展現價值
-->  靠感覺做專案管理 - 鐵定失敗
-->  如何提高工作效率：三個務實的快速步驟
-->  心智圖：職場的第一個技能
-->  你確定知道專案進度嗎？
-->  80/20法則之軟體專案的三個運用重點

如何學習Scrum

如何學習Scrum?

端看學習Scrum的真正目的，有三種方式可供參考：(1) 網路資源 (2) 收費課程 (3) 實際經驗

(1) 網路資源

很簡單，費用幾乎為零。

下載這兩個pdf，接下來，先不要上網查專有名詞，也暫先不要查字典，好好的先花時間看完。

* Scrum-institute 的 training pdf。
* m-plaza 的 Scrum Guide pdf。

然後，隨意上網找一些相關資料閱讀佐證即可。也可以自己做個類似這樣的簡單學習計畫。

不確定自己有沒有學會？可以考慮花29美金考一下證照看看，請參考Scrum證照這篇。

假如是剛畢業的大學碩士學生，英文閱讀沒有太大障礙的話，大概8-16小時應該可以完成。

(2) 收費課程 <- 不推薦

也很簡單，但是要花錢，大概7,000~20,000不等。

在google搜尋[scrum 認證課程]，出現起碼5個不同的教育機構，其價格從7,000到20,000台幣不等，時間通常大約是2整天左右。衡量自己的時間和財務狀況，挑選離家近的參加即可。

這類型的收費課程通常會協助考取證照。在此並不推薦這個方式考取非技術專業之證照。

(3) 實際經驗

非常難！要花的成本看起來很高，不過他通常伴隨工作經驗的成長。

(a)基本作法：

首先必須要先參與開發團隊一陣子，在此期間必須要先用方法(1) 網路資源。用以了解Scrum的基本精神。

然後，只要運氣不要太差，加上自己的努力，有朝一日會變成專案經理，或者是團隊領導者的角色。接下來，由於自己已經擔任領導者角色，就在自己領導的團隊中，以務實的方式執行Scrum。其中一定會遇到阻礙，每當你碾平一個障礙，就更多一層對務實的認識。

基本作法其實也是最佳作法，如果是一個已經有足夠技術背景的人，而有意識的朝這個方向前進，在台灣大概3-5年就可以有很好的成果。

(b) 突破性作法：

和所有專案管理技能一樣，當不能付諸現實的時候，技能的本身就沒有意義。就像籃球教練沒有籃球隊可以教，沒有籃球比賽可以參與的時候，籃球教練等於沒有付諸實踐的意義。

要有突破性作法的原因在於：

* 企業組織長久以來沒有真正agile的精神
* 在創新小公司任職，架構混亂，以完成事情為優先
* 自己並不是團隊領導，但希望能改變團隊
* 剛畢業，沒有領導管理經驗
* ...


然而，在這些外在因素不利的情況下，如何有Scrum實際經驗？（突破性方式的概念可參考這篇。）

簡要的說，自己起頭一個專案，無論是跨界虛擬專案，還是開源(open source)專案，還是到便宜的外包市場找南亞工程師加入的專案。當自己開啟專案時，自然就可以確定，如果要採行Scrum，不可能會有其他外界因素，所有成功與否的因素都在於自己。當然也是靠自己來碾平困難。

一旦個人的能力提昇，自然就越能貢獻現在的團隊，現在的組織，更容易體會團隊合作的可貴。

靠感覺做專案管理 - 鐵定失敗

真實故事：

有近70個工程師參與的軟體專案的組長會議中，除了專案經理之外，另有8個負責領導開發不同模組的組長一同與會。

例行的報告進度後，專案經理看了一下大家，帶著遲疑的臉說：「在兩三個禮拜大家的模組就都完成了，如果沒有問題的話，應該整個系統同時也都弄好了吧？」

負責UI以及整合模組的組長，看著大家漠然不語，也只能硬著頭皮的說：「現在最大的風險在於：如果所有模組都在最後實現完成，那根本不會有人知道組合起來會發生什麼事，所以我只好老實的建議，要不就額外增加整合測試的時間，要不就要減少某些模組的功能讓他可以早點進入整合」。

但其實大家心裡有數，這麼多人在短時間開發出來的系統，不可能在短期間整合完畢。

未料，專案經理似乎沒有體會事實，他說：「接下來大家就要在努力一點，就快要搞定了」。

可能是心情不好，在加上長時間加班的火氣：某組長就說：「我們到目前為止的問題是在於我們不夠努力嗎？」。

專案經理當然說：「不是，我知道大家都很努力...」話未說完，該組長就說：「既然問題不在於我們不夠努力，為什麼叫我們更努力，就可以解決問題？」。

專案經理：「...」

---

許多失敗的專案管理者，在遇到困境時，只會用幾個永遠不會有好結果的方式，來試圖解決問題。常見的方式像是：無意義的加班，默許降低品質，虛報進度，哭訴人力不足要求增加人力。在緊要關頭，這些作法都不會有好效果。只會這幾種方式的專案經理，儘快離開管理位階，才會是組織最大的貢獻。

最有天賦以及領導力的管理者，通常擁有不可言喻的直覺，並能透過直覺透徹專案。很遺憾的是絕大部分的人不會有這樣的天賦，特別是作為軟體專案經理者。很難具備以敏銳直覺，完成複雜系統開發。

然而，專案管理其實不需要天賦，所有人都可以透過自我學習，了解專案管理的精隨，透過自身的努力作個稱職的專案經理。和所有重要的事情一樣，首先是要了解事實。在略具規模的專案，應該透過事實的呈現，來了解專案目前進度，可能的風險，遭遇的困難，以及解決方式。

而且，只有盡可能了解事實，面對事實，才能引發可行的創意行動。


事實的取得有三個面相：

恰當的衡量：

恰當衡量，是判斷專案經理的好與壞的關鍵之一。恰當：簡而言之，必須是可行，正確，有效，有意義，精簡的衡量。

近年來Scrum蔚為風潮，其中一個重要因素是對於進度的恰當衡量。通常專案進行了一段時間之後，burndown chart可以清楚的顯示，現在專案的進展，和是否可能在預定期限內完成。也因為burndown chart展示的是不可否認的事實，讓Scrum的團隊在取得洽當的衡量之後，做正確的因應。

不恰當的衡量，出現在幾乎所有失敗的專案場景裡。

有些專案經理會依賴WBS的圖表，來看進度是否得當，但WBS是固定的無法調整，即便調整，也很難追溯過去調整的細節。WBS在軟體專案中，很難達到可行，正確，精簡。

有些專案經理，會依賴團隊成員報口述「完成」來斷定進度，在沒有看到「實品」（例如程式碼，每天自動編譯測試的build等等），口述完成不是「有效」衡量。

最慘的專案經理，會透過大型，繁複，耗時的會議，逐一確定已經完成的項目，花在「了解事實」上的時間，遠超過「做事情」的時間。這種本末倒置的既不可行，也不精簡。它唯一的好處只是在於讓原本不懂的人 - 也就是專案經理，花上不可置信的時間了解事情而已。一個不超過10人的團隊，要是每個禮拜耗費總時超過4小時在這類型的會議上，就表示專案經理沒有對技術有透悉能力，儘快換掉專案經理會是對團隊最有利的作法。

承認不確定性：

沒有人可以預知未來，必須承認不確定性，並且把可能的不確定性當做事實加以處理。當打算推測不可知的未來時，用過去之已知事實，並加上不確定性。

例如：未來3個月團隊的總人時？假設團隊成員共10人，每個月22個工作天。則總人時推測為220人日時，等於表示沒有推測。這220人日，根本沒有把「過去已知事實」考慮進去。比較好的推測應該是，220人日，減到(1) 過去3個月，這10人的總休假生病天數。再減掉(2)可能的季節性假日，例如颱風。再減掉(3) 組織已知的活動，例如員工旅遊，大型會議等等。當然，這些以過去的數字推測未來不一定準確。但是，以過去的事實推測未來的不確定性，總比當做沒看到的好得多。

一般專案管理中，不確定性會用風險管理來衡量並且控制。正是「真正」的風險，就是坦然面對事實。

失敗的專案經理在每週的報告中，會把「人力不足」當做風險，試圖避免未來失敗的責任歸屬 - 畢竟已經先在每週報告中說了，目前人力不足是風險，但是就是沒給足夠的人力。這其實單純是專案經理試圖逃避未來責任的作法。

人力不足壓根就不是真正的風險！如果人力不足是真的，那麼專案時程規劃不正確，對技術掌握不足，專案經理沒有創意來解決問題...這些才是真正的風險！假如真有人力不足，它必定不是突然出現的可能機率，它是「已經存在的必然」，風險必須是某種可能會出現的事件，萬一出現，會對專案造成及大的影響。例如，在建築專案中，大地震就是風險，必須要規範出現的機率，但它很有可能不會出現。

把不正確的風險當風險，以及不把真正的風險當風險，都是不願意面對事實的畏縮專案管理者會做的事情。

理解認知偏誤：

在專案管理中，人類認知偏誤(Human Bias) 不可能全部去除，但可以盡量避免。根據事實原則，專案經理應該承認：認知偏誤的存在，盡可能減少影響，但也要理解，不可能全然去除認知偏誤，畢竟人非聖賢，也非機器。自認為已經去除所有認知偏誤，等於是一種認知偏誤。

去除是不可能，理解並且降低偏誤，是取得真正事實的最重要的方向。

例如：在code view的精簡會議中，常出現偏誤在於，極為資深的員工的程式碼，通常比較不會被挑出問題。但根據研究，只要運用程式語言超過2年以上，資深與資淺員工，在程式碼撰寫品質並沒有太大的不同(參見約耳談軟體一書)。要去除這類型偏誤，最簡單的方式是透過系統送出匿名程式碼(在尚未commit之前)，要求成員利用email寫出自己的意見，而意見也可以是匿名。

高階主管為另一個例子：高層主管對團隊的了解，大部分來自第一線主管或二級主管。高級主管必須要認知，取的團隊資訊，必然經過過濾和扭曲。這幾乎是不可避免的事情，畢竟第一線主管或二級主管也是「人」。例如，如果發現有某團隊老是有問題，進度不佳，人力似乎永遠不足，高級主管如果找第一線主管了解原因，不會有第一線主管直接了當的說「是我的問題」。但是，一個團隊有問題，75%的原因是出現在領導者身上。去除認知偏誤的方式，除了越級訪談之外，高級主管不應該詢問一級主管的「看法」，而是直接詢問可以獲得的事實。例如：目前的問題，一級主管採用哪些「有價值的作法」來解決。

偶爾進行的團隊訓練活動，也可以將人類偏誤以討論的方式作為主題。讓團隊成員知道有偏誤的存在，自然就有可能減少偏誤的發生。



只要能根據「事實」，降低並去除認知偏誤，比較有機會在困難的專案狀況下，發揮團隊潛能，並且找到有創意的解決方案！畢竟，根據「事實」，一個營利組織必然希望團隊能帶給組織真正的價值，而非僅只是達成表面目的。

---

問對問題，如履平地。問錯問題，萬劫不復！

在不到十歲的年紀，有一次流感重症去看醫生。那時候還沒有健保，醫生通常還是會跟家長講一下治療方式可能的價格。當然，如果打一針可以好的比較快的話，多花個幾百塊可能也是值得的。但是！小時候的我很害怕打針。也許恐懼的神情被醫生發現了，他就好意地問『有比較大筒的針跟比較小筒的針，看你要打哪一種？』小時候的我，毫不猶豫的當然回答『小的針。』。結果，最後護士是拿出「兩隻」小的針筒，左右兩邊各打一針。

這個慘痛的經驗，後來讓我學習到，要完整考慮「問題」，至少要從三個方向思考：

1.問題可能不能代表真正的問題

無論是一般工作進行，還是特定專案，通常都有各式各樣的「問題」產生。有些可能是單純的疑問，例如「這個功能什麼時候可以完成？」。有些看起來比較複雜，例如「帳號如果被管理者停用，則正在登入使用中的session是否要立刻中斷？」

單純的問題，可能要考慮的更多。以「這個功能什麼時候可以完成？」為例。可以循用5 Whys 五個為什麼，來了解看似單純問題的真正本質，

例如：

「這功能完成的時間已經在系統有紀錄，為什麼要額外詢問？」--- 原詢問者回答：「只是想要知道有沒有意外」

「為什麼會想要知道有沒有意外？」 --- 原詢問者回答：「之前某高層詢問專案進度，我覺得這個功能因為比較複雜，不知道會不會有風險」

「為什麼高層會詢問專案進度？」 --- 原詢問者回答：「因為高層覺得專案預計完成時間太晚，想要用一些方式提早」

「為什麼會覺得預計完成時間太晚？想要哪種方式提早？」---原詢問者回答：「我也不知道，不要再問了！！」

2. 真正的問題很難找到

事實與真相就像船頭和船尾，首先會看到船頭，然後根據整個情況有多大多複雜，才會在最後看到船尾。

要找到真正的答案，必須要先找到真正的問題。

在許多軟體專案中，經常會有專案管理者以「人力不足」作為問題並試圖解決。但是，這個問題在絕大部份的軟體專案中，根本不真正的問題。

真正的問題也許是：

(a) 許多專案成員另有其他任務，導致投入專案的時間太少

(b) 專案需求不明朗，時常增刪變更，導致時間浪費

(c) 「人才」不足，而非「人力」不足，像是：
       (C-1) 專案管理者沒有看透技術關鍵的能力
       (C-2) 專案成員訓練不夠
       (C-3) ...其他...

而每一個問題， 背後又隱藏其他的問題。絕大部份的專案中，問題看似很多，但最重要的可能只有幾個。

專案經理的重要任務在於：決定真正重要的問題(忽略不重要的問題)，並且優先解決最重要的問題。

3. 真正的問題才能找到真正的答案

要找到真正的答案，必須要先找到真正的問題。

一旦找到真正的問題，等於已經產生一半的答案。不過，另一半的答案可能也不見得很簡單。

假設認為真正的問題是「專案需求不明朗，時常增刪變更」，答案的選擇可能有：

(a) 採取Scrum開發模式，確保每個Sprint的需求不會再改變，讓真正的專案擁有者能參與每階段的決定

(b) 暫停所有開發活動，在沒有完成細部設計與需求規格書之前，先不開始開發

(c) 再花時間去找到為什麼專案需求不明朗的背後原因，






最終，每一個成員，需要為自己找到最適切的真正答案。
隨波逐流，最終只能忍受左右兩邊各一針的結果。

80/20法則之軟體專案的三個運用重點

軟體專案的Scrum的一次sprint之後，照例的檢討會議(retrospective)中，張經理收集了成員的意見，經過投票整理與排序，發現"不夠專注在重點上"是成員們最希望改善的地方。於是，張經理發表他的見解：「看起來大家可能是覺得瑣碎的事情太多，沒辦法專注於工作，這次新的sprint開始，大家試著把心思專注在重要的事情上」，接下來，張經理開始順道交代其他事情：「呃，上次要給法務部門的3rd party版權清單，老馮你準備一下；明天我們要定個下午茶，小陳你有空的時候幫個忙...」。....於是乎，最希望改善的地方就從未改善過。


Pareto Principle，又稱為80/20法則，指的是80%的結果來自20%的原因。這個法則是取名字義大利的經濟學家帕雷托。他觀察到1906年義大利的80%總資產屬於20%的人口。而此一情況被學者們，在其他領域也觀察到重複類似情形，因此被簡約成此法則。

80/20法則中的數字，有時候，會和實際領域不同而有所改變。例如，絕大部份的軟體，其90%的執行期間，執行的是其中10%的程式碼(參見這裡)。


在軟體專案管理中，能掌握80/20法則，等於是掌握80%的成功。

以程式撰寫為例：最重要的10%程式碼，關係到軟體運作的90%時間，掌握最重要的10%的效率與品質，就掌握系統的本身。當然，80%的bug來自於20%的程式碼。（參考這裡）

以測試為例：1000個測試案例(test case)如果能有效掌握哪20%的測試案例可以測出80%的潛在問題(bug)，就可以有效縮小測試。

以人員管理為例：在有一定人數的情況下，30%的程式設計師完成70%的主要功能。而有追蹤問題(bug)的來源時，80%的問題來自20%的模組撰寫者。


因此，掌握並改善20%重點，是任何專案的成功關鍵因素。

不過，這件事情知易行難。以反面來看，作為專案管理人，如果整個專案過程的每天都忙得焦頭爛額，隨時都有不同的人來進行不同的會議，螢幕旁邊有數十張待辦的便利貼。這很明顯的表示你一定沒有掌握到20%的重點，而你雖然很努力的想要完成任務，但並沒有朝向正確的努力方向。更慘的是，假如你認為這種忙碌可以顯示自己在組織的價值與貢獻，這種想法做為專案的領導者只會害死大家。


每個專案都是獨一無二，因此每個專案的重點20%都有所不同。然而，掌握關鍵的「20%」倒是有三個共同切入點。

1. 目的 - 真正目的

軟體專案的真正目的各有不同：有些是新產品開發，有些是既有產品增加新功能，有些是客製化專案。大部份的情況下，其目的通常不是「技術目標」，而是「達成效果」。

例如，網路商店需要開發mobile app，其目的鐵定不是為了要有一個Android APP或是iOS APP，而可能是要讓客戶在智慧型手機上也能購物。但也有有可能目的是要讓客戶在智慧型手機上容易查詢訂單。當然也有可能兩者兼具。但無論如何，技術目標：也就是有Android/iOS APP，與達成效果通常有相關，但專案管理者必須清楚兩者的不同：

達成效果是勢在必行不可或缺，但技術目標永遠都有其他選項。

網路商店不見得需要有APP才能讓使用者在智慧型手機上購物，可以使用符合智慧型手機規格的網站(所謂的響應式設計)，讓使用者利用手機瀏覽器進行購物，也可以透過簡訊或者撥打電話的方式購物，開發APP只是其中一個選項而已。

掌握真正目標之後，列出這個目標中的所有使用情境(user story)中最重要的20~40%的功能，而軟體開發的重點就放在這20~40%重要功能。集中力量完成最重要的20%，才不會「先」耗費力氣在無謂的事情上，「最後」才做真正重要的事情。

2. 時間 - 不倒退的沈默成本

時間是不會倒退的（參考這裡）。軟體專案裡的時間成本一旦投入，都屬於不會退還的沈默成本。也因為時間無法退回，一旦投入就是投入。因此，必須要確定「先」運用時間在重要的事情上。

80/20法則的重點在於：計劃先運用「未來的時間」，在有效果的事情上以先達到80%的產出。

舉例來說，一個程式設計師，在早上抵達辦公室，打開電腦的第一件事情，應該試圖確認「今天什麼事情對我最重要」，而一個開發團隊，每天第一件事情應該是「今天團隊完成什麼事情最重要」。因此，典型的scrum都會在一早展開standup meeting(快速會議)，以15分鐘的簡單開場讓專案團隊確保先投入在最需要進行的事情。

這也是一個聽起來簡單，執行起來並不容易的概念。有很多情況，團隊成員並未「徹底」實踐快速會議時的精神。

例如：某甲陳述：今天會開始開發模組A，預計今天會完成，而這也是他今天最重要的事情。然而某甲可能無意識地忽略掉昨天他的功能B的程式碼尚未簽入版本控制系統，因此實際上會議結束，其實他花了一早上在簽入程式碼，並且執行合併/建構系統。某甲並非不應該完成昨天尚未完成的事情，而是他對於「未來即將使用的時間」沒有腳踏實地的認知。

80/20法則運用在專案的時間管理上，最重要的精神在於「腳踏實地」，並且「確實展現事實」-- 缺乏這兩者，會讓80/20法則淪為壓榨程式設計師的幫兇。

3. 激勵因素與保健因素

激勵保健理論(參考這裡)，將影響人工作時心裡的滿意度因素分為兩類：激勵因素與保健因素。簡單的說，保健因素是「沒有會死，但是有也不會很高興的因素」，激勵因素是指「沒有的話不會怎樣，但有的話會很高興」。

激勵與保健理論，乃是在軟體專案管理中，80/20法則運用的最容易忽略的一環。特別是在兩個面向上：(a)軟體團隊經營
(b) 技術決策

(a)軟體團隊經營：

保健因素(薪水，電腦設備，工作環境)：無論加碼到什麼程度，對程式設計師的績效成長極端有限，然而一旦失去基本下限 - 例如減薪，則其他的激勵方式會突然失效。軟體專案負責人，應該在一開始，就先確保：保健因素是成員可以接受的。爾後專案執行過程，不要特別關注它即可。

激勵因素(個人成長，價值觀，成就感)：激勵因素才是大部份軟體開發專案成員「願意保持工作熱誠」的真正原因。負責人或者領導者，應該將團隊經營的80%重點時間放在保持激勵因素。然而每個人的激勵因素皆有不同，因此了解團隊成員個別的「真正需求」，才是需要花時間的地方。

舉例來說，有些團隊成員可能會抱怨沒有雙螢幕，雙螢幕對於撰寫程式的確很重要，專案經理想辦法弄給他雙螢幕之後，千萬不要以為這樣就會讓他心甘情願賣命。雙螢幕只是保健因素，是必要取得，但不是重點。專案領導者在團隊經營上，應該花20%的時間快速搞定保健因素，而後，花80%的時間確保激勵因素的存在。

缺乏激勵因素的團隊成員，並不代表一定會離職，也不一定代表任務不能完成。一個能力很強的人，可能因為暫時沒有其他選項而在現在的位子上滿足最低限度貢獻。這樣成員，反而成為一個潛在的問題，他隨時有可能因為任何短暫膚淺的因素而離開，更糟的是不離開而成為團隊困擾。而這種情況並非是該團隊成員的問題，而是團隊領導者，沒有辦法找到並維持適合的激勵因素。

(b)技術決策：

既然是軟體開發專案，必然會歷經各種技術決策。80/20法則一定是技術決策的主要運用重點。

以功能而言，如果有A功能與B功能在短時間之內，只能選擇完成一個。則技術決策應該從幾個方向考量：

方向一：中大型軟體專案一定有20%的重要功能，會滿足80%的使用者需求。哪一個功能屬於這類。

方向二：如果A與B都滿足方向一，則考慮哪一個功能會直接滿足「專案目的」。

方向三：如果A與B都滿足方向一與二，則考慮兩者哪一個對於此專案是屬於保健功能(沒有會死的功能)，哪一個屬於激勵功能(有的話會很高興的功能)。並且考慮專案目的，是屬於維護且保守的專案，還是開創性的新專案。開創性的專案自然優先考慮激勵功能；而維護型或保守的專案，當然要先考慮保健功能。



80/20法則的有效運用是判斷一個優秀的專案領導人的條件。以反面例子而言：有很多15年以上專案管理經驗的所謂專案經理，他所有的經驗可能都在於無謂的忙碌與焦頭爛額中度過，這樣的15年和1年沒有什麼不同。如果你是這樣的專案經理，為了團隊好，或許應該考慮轉換適合的工作跑道。

軟體專案品質控制的三要點

老馮是軟體專案經理，在專案進行的某一天，被高層找去開會。高層：「最近雲端計算很火紅，你的專案既然是跟Cloud有關，看能不能早點完成」。老馮就問：「那可不可以auto-scaling的功能不做？」。高層：「沒有auto-scaling哪能算雲端計算平台，當然要做啦」。老馮就又不死心地說：「怎麼可能功能不減少又要早點完成？我們都已經是早9晚9在加班」而老馮心裡沒說的是，加班也絕對不是解決的方法。高層：「那就看你們的能力啦，不然我在多加3個人給你好了？」。老馮：「...」


專案管理過程中，品質是最容易忽略的項目。在狀況複雜的專案，品質常常是自動被犧牲的事情。在沒有良好控制的專案，品質是最容易被省略的事情。

品質Quality的定義其實有點複雜（參考這裡）。基本上，在軟體上，一個可接受的品質通常是指：功能如預期的正常運作，並且沒有不預期發生的壞事。

例如，一個手機購物程式，在你執行登入，往下捲動查看最近的商品目錄，點選商品，下單，這幾件事情都如預期的運作，就表示功能沒問題。從看到商品到購買，整個過程沒有讓你覺得很慢，那就算是沒有不預期發生的壞事。

又例如：當你點選商品之後，看到商品大的照片，接下來你就橫向擺放手機，照片因而旋轉之後，再轉回原來的正向，結果手機程式就當機直接跳出，這就表示功能有問題。當你點選商品到購買，整個過程讓你等得很心煩易燥，每個動作都要5秒鐘的等候，那就算是不預期發生的壞事。



軟體專業經理人，應該都知道一條鐵律：品質，範圍，成本，三者不可能兼具。

軟體專案的成本指的是：時間，人力，金錢或其他投入的資源。

軟體專案的範圍指的是：軟體的功能，規模，支援的硬體範圍等等，範圍修改自然就是功能增多或減少。


三者不可兼具，指的是要顧全某一項或者某兩項要素，就一定會犧牲另一項。例如：某APP可以支援google+ 以及facebook 帳號登入，後來因為時間(減少成本)考量，最後決定僅支援facebook登入。又例如，某APP原本可支援google+ 以及facebook帳號登入，後來又希望可以額外支援維博登入，這時候就決定花錢(增加成本)找外包廠商實作此功能。

軟體專案中，另一條鐵律是：試圖三者兼具者，會自動犧牲品質。例如：某APP可以支援google+以及facebook帳號登入，而後又想要支援維博帳號登入。專案經理想要在不增加成本，又不減少其他功能的情況下，又不增加實作時間。硬是要額外增加此功能的結果，必定是品質會自動犧牲。

不知道品質會自動犧牲的專案經理，必定不適合做軟體的專案管理者。

軟體專案品質控制有三個要點：

要點一：來源

品質的來源是整個開發過程，從一開始的計畫以及團隊組成，就已經決定了品質的一半。

一個簡單合理有效的計畫，可以控制改變，掌握進度事實。開發方法是不是採用Scrum並非最關鍵。重要的是，計劃中的開發方法是否簡單並合理的被團隊認知。

舉例來說，傳統SI常會有RFC，也就是需求變更的管理計畫。在開發過程中，如果有需求變更，基本應該是1.先填一份表格，2.在專案會議中與客戶討論，3.互相同意修改之後進行變更。換言之，有需求變更(RFC)管理的情況下，必定是前期的架構，設計細節，規格等等都先完成了，才會開始進行開發，因此，就不可能使用Scrum的開發方式。


假如團隊的組成是可以選擇的，那這件事情也是掌握品質的關鍵因素。

要點二：架構

在實作上，架構是另一個品質的主要關鍵因素。一個優良而且簡單的架構，比較有可能在多人而且複雜的開發情況下，獲取最容易達到的品質。

精煉的軟體架構設計表面上容易，實際上困難。架構的設計要素，眾所皆知：內聚力高，耦合力低，不同模組之間首重介面溝通。

然而，任何有3至5年工作經驗的程式設計師，都可以規劃出極為複雜的架構，普通並且沒有實務經驗專案經理，會容易「讚嘆」這種複雜的架構。這會在不久的未來讓品質很快降低。

實務上，只要沒特別的控制以及重構，正在運行的軟體的熵(entropy)值通常會隨著時間越來越高。同時也讓軟體品質越來越低，或要花很大的成本達到高品質。

要點三：創意

在品質控管中，創意是最被人所忽略。特別是在傳統的開發環境裡，負責品質的相關專業人員通常傾向於「找到問題」，事實上，這的確是QT或者QC的主要責任，但軟體專案中，作為QA(Quality Assurance)扮演的任務就不僅如此，而是在整個開發過程中確保品質符合規格（註一）。

而有創意的QA是第三個重要的品質來源。

普通的QA會執行QT/QC的任務，在開發過程中參與設計討論，並且撰寫測試案例(test case)。在功能完成之後，會認真執行測試案例，或者撰寫測試程式碼以便自動化測試，而在過程中找到並且記錄問題，並督促程式設計師修正錯誤。以上這些都很好，而且也沒什麼不對。

但是！當時系統複雜，時間壓力大，程式設計師能力參差不齊等等困難情況發生時，普通的QA流程並不會對「範圍」以及「成本」有所幫助，因此很容易被壓縮或者犧牲。

有創意的QA會根據專案的情況，找出最好的解決之道。而非死命地抱著舊有的測試流程，在確定有問題的情況下還不進行改善。

創意的可能行動有很多，但總之就是要有「行動」。空想的創意是沒有意義的。有創意的QA行動，可分為技術類型和非技術類型：

技術類型

例如：透過pair-programming主動參與開發；除了自動化測試之外，撰寫當介面改變時的監視程式；對於程式設計師的commit做自動化分析...這些都是透過QA的技術能力，提早發現可能的問題並提早解決。

非技術類型

例如：著重架構的精煉與簡化；改善測試流程；利用其他資源(例如業務人員)進行測試；改善code review的方式；簡化bug記錄以及追蹤方式...等等，這些都是透過ＱＡ的協調作業能力，縮短或減小品質差距。


簡而言之，絕大部份的軟體專案品質控制，其實是需要有創意的QA，才能突破既有限制，創造更多價值。而QA要有創意也並不困難，只要願意嘗試，通常都有很好的效果。


參考：沒有QA？如何確保軟體開發品質

註一：ISO對於QA的定義："part of quality management focused on providing confidence that quality requirements will be fulfilled"

你真的知道專案進度嗎？

只要是從事程設式設計相關工作的人，必然曾經參與某專案(Project)。專案的大小不一而足，有些只有幾天或幾週，有些橫跨數年。

如果有幸負責專案管理，則無論規模大小，掌握進度是除了管理利害關係人期望之外的第二重要的事情！！而實際上，要管理利害關係人期望的最好方式就是能有效掌握真實進度。

「掌握進度」之後，才能調整應變可能發生的意外，降低風險。


只要看軟體專案進度的「掌握方式」，就大致可以判斷一個專案經理的「本職學能」到什麼程度。

一個好的專案經理，可以單靠自己，就能足以掌握專案進度。

一個普通的專案經理，可以利用流程，規範，加上開發成員的協助在一個合理的時間範圍內，掌握專案進度。

一個很爛的專案經理，會利用各種會議，各種形式文件的填寫(WBS之類)，直接或者間接的資訊，花很多時間，仍然不能掌握專案真實的進度。


很遺憾的是，好的專案經理很少，好的軟體專案經理，更是極端的少。因為他同時需要具備技術能力，透悉問題的能力，以及有效的專案管理能力。

要點一：以時間為單位

非軟體專案管理上，掌握進度的單位有很多種，例如「以執行預算」或者「實獲值」來掌握進度。（請參見PMP相關網站)

以軟體專案而言，「時間」才是真正掌握進度的單位。

當詢問負責的程式設計師：「A功能進度如何？」，而他回答「只剩下UI整合，加上DB欄位定義調整，就快好了」。這樣的回答，對於掌握進度幾乎完全沒有意義。因為，該程式設計師可能在A功能花了1天，然而UI整合與DB欄位定義調整，可能還需要另外花上3天，換言之「就快好了」根本不是真的，基本上只完成了25%。但該程式設計師並不是故意要說謊，因為或許最難的就是那25%。

程式設計師若以困難度為考量，進度就像下圖，功能完成之後，就「快要好了」。

但如果以實際時間進度為考量，則如下圖，功能完成之後，只完成了25%。離「快要好了」有很大的距離。

大部份的軟體工程師，著重於困難度。這並非不正確，只是專案管理在掌握進度時，實質進度必然是以時間為考量單位。即便「這件事情很簡單」，也必須要考慮「簡單的事情還是要有人去做」。

要點二：產出的事實

直覺上，大部份的產出當然是程式碼。實務上，非程式碼的產出許多時候會超過想像中的多 -  特別對於比較沒有專案管理經驗的人而言。

基本情況

最基本情境是，根據規格要完成功能A。一開始，程式設計師寫好了程式碼，並且自己編譯(compile)並簡單測試之後，簽入(commit)到版本控制系統中，並且和其他相關程式碼合併(merge)之後，整合成新的版本，並且新的版本經過QA測試後也沒問題。這個功能A就算完成。

在這個情境中，寫程式(coding)可能佔了70%的時間，另外merge以及測試可能佔了另外30%的時間。

專案經理要掌握的「事實點」在於：整合成新版本並經過QA測試後也沒問題，至此，功能A才算完成。

進階情況

在一個稍微複雜的專案裡面，根據規格要完成的某任務，實務上可分為「功能A」與「功能B」。一開始，幾個程式設計師分頭完成自己負責的功能，並分別自己compile並簡單測試之後，功能A與功能B就commit到版本控制系統的不同版本線(code line)。此時，QA分別進行測試，沒問題之後，協調某人「分別」合併功能A與功能B到主線(main line)並且整合成新版本。在整合過程，或多或少有需要修改的程式碼，也許在合併工能A的時候沒問題，但是在合併功能B的時候有出現問題，並也修正完畢。最後新的版本經過測試也沒問題。至此該任務才算完成。

專案經理要掌握的「事實點」在於，最後新版本經過測試也沒問題。至此，某任務才算完成。

但是，這和基本情況不同的是，整個過程很長，從數天到數週都有可能。coding本身可能僅佔50%。而合併，測試，在合併，修改等等可能佔了另外50%的時間。

與前述要點一相同，專案管理者要能掌握實際上的進展，跟「未來還需要花的時間」。在複雜的情況中要掌握，除了最後的產出事實之外，中間的進度掌握，需要靠專案管理人員對專案本身實務的了解。

專案進度的掌控，大部份是由專案經理個人獨立可以完成。其中，技術上的要素就是能否「判斷產出的事實」

而以軟體專案為例，專案管理者如要能判斷產出的事實，必須要能做「自己獨立」做下列幾件簡單的事：

1. 在版本控制系統中(git, p4, cvs等)，找出過去一段時間的所有commit過的程式碼變更，誰去變更，為什麼變更。

2. 在最近的新版本測試中，看到哪些新功能確實增加

3. 自行檢查目前bug的清單，並且找出幾個關鍵的bug



假如你是專案管理人員，而你不認為上述事情是自己應該獨立進行，或者你認為上述事情會花太多時間，


請參見下節：除去迷霧。

要點三：除去迷霧

許多「非技術背景」的專案管理人員，常常用各式各樣的大大小小的會議，來獲取專案進度的掌握：每天早上例行會議，每隔兩天來執行bug review，每個禮拜來討論整合進度...開會的本身並不會「加速」專案進行，過多的會議，肯定會「拖累」專案進度。

如果你是一位主管或專案經理，而你迫使專案成員每天花超過10%的時間(也就是40分鐘左右)在正式的會議上，並且只是為了呈報「目前進度」。那麼，你實在是個很糟糕的主管，要麻，你就盡快辭職，要麻，盡快提升自己的專案管理能力，否則你的存在只是浪費大家時間。

了解目前專案的進度，等於是除去迷霧，看清事實。除去迷霧的方式，必須要是「貼近事實」與「清晰的技術檢視」。

貼近事實

事實有時候很容易了解。例如：app要可利用facebook帳號登入。此功能容易判斷有完成，或者沒完成。

但有些時候事實很複雜。例如：某程式設計師宣稱，app要可以利用facebook帳號登入，他需要花12個工作天完成。12個工作天到底是長還是短？如果覺得太長，是因為寫程式的人能力不足？還是既有的app過於複雜，所以要加任何新功能都很難？


按部就班的貼近事實是讓該程式設計師先行「分解」這12個工作天。讓專案管理人員了解，他打算如何利用這12個工作天。

如果該程式設計師說「我這個是大概估計，12天就拿來做這一個功能阿，你還要我花時間去分哪天做什麼喔！我哪來這個時間」。這表示事實是，12天根本只是沒有基礎的猜測，他可能22天才完成，也可能2天完成。

絕大部分軟體專案，程式設計師的某行動完成都應該至少可以以「天」為最小單位，(也可是以「小時」為單位，不過太細的單位也會造成不必要的麻煩)。

超過2天估計，就應該可以分成「兩個以上的事情」，超過12天的估計，應該是建立在至少6個以上的某行動完成。


不能分解行動，表示沒有計畫，也對此任務沒有任何基本了解。

假設該程式設計師將app如何利用facebook帳號登入分解為以下工作：

(1) 修改UI: 3天
(2) 登入的程式碼: 7天

(3) 測試: 2天


專案經理應該要能看出，這樣的WBS其實完全是在應付專案經理，對貼近事實沒有幫助。他等同是一樣沒有了解任務。

如果無法將此任務交給別人，專案經理應該參與「計畫」與「分解」的過程。和程式設計師一起坐在某台電腦前面，將android studio打開，了解登入在哪邊加icon，如何到facebook取得App ID，facebook sdk如何使用。

對於有技術領導背景的專案經理，頂多花上一小時，就應該至少可以分解此任務如下：

(1) 到facebook developer網站了解sdk：1天
(2) 申請App ID以及了解相關規定：0.5 天
(3) 登入Icon要和美工討論實作方式：0.5天
(4) 執行登入，取得session：1天
(5) facebook帳號與其他帳號在db處理的不同：2天
(6) 與QA討論測試方式：1天
(7) QA測試：1.5天
(8) 其餘模糊規格的討論，例如是否可登出：0.5天

加總起來可能僅需要8天。但重點不再於天數減少，重點在於此計畫已經破除進度迷霧。當這個計畫開始執行，到了第三天，如果該程式設計師已經開始撰寫登入程式，那麼表示進度和預測相同，但如果他還在申請App ID，表示進度落後，專案經理需要調整進度，或找人幫忙。但無論如何，絕對在計畫開始執行的前期就已經知道如何處理問題，而不是到12天之後，突然發現根本無法完成。


(Android如何利用facebook帳號登入，請參考這裡)

清晰的技術檢視

前述的app利用facebook登入，專案經理之所以能和程式設計師一起坐下來定好比較清晰的時間，其首要條件在於具備清晰的技術檢視能力。

簡要的說，能區分技術難度，區分使用該技術對於專案的影響，以及，使用技術可能產生的風險。清晰的技術檢視能力，會有效提高對整個產品或者專案的洞察力。雖然，洞察力可以經過訓練磨練取得相關經驗，但實質培養卻需要有意識地進行。

技術檢視需要對技術的深度與廣度，每個專案經理所需要的技術能力各有不同，以下有個簡單的軟體專案經理自我問題清單，回答「是」就得1分。

低於5分表示是沒有技術檢視能力的專案經理。
高於8表示是罕見的擁有技術檢視能力的專案經理。

* [Yes/No] 你可以自己從版本控制系統中了解專案目前大致規模：(行數, 檔案數, 平均每工作日增加的程式碼數量)，無須依靠其他專案成員嗎？

* [Yes/No] 你可以自己找出哪些程式設計師的程式碼常常會出現bug，無須依靠其他專案成員嗎？

* [Yes/No] 你每一週會隨意抽出幾個程式碼簽入(check-in)看看有沒有明顯的問題，無須依靠其他專案成員嗎？

* [Yes/No] 你會手動編譯專案，無須依靠其他專案成員嗎？

* [Yes/No] 你隨時知道目前技術文件(程式碼註解, api 手冊, 使用手冊)撰寫的實際情況？

* [Yes/No] 你知道專案成員實際花在專案的時間

* [Yes/No] 當某個進度完成時，你可以自己檢查該進度是否真的完成，無須依靠其他專案成員。

* [Yes/No] 你會用專案開發的主要程式語言撰寫工具用程式（例如查閱系統log之類），無須依靠其他專案成員？

* [Yes/No] 你能自己估計團隊能力和團隊完成某模組的大概時程，無須依靠其他專案成員？

* [Yes/No] 你能單靠記憶，繪出目前專案個模組之間大概關係，無須依靠其他專案成員？

如何組成團隊：三個步驟

分工合作，是人類社會進步的主要原因之一，也是幾乎所有人類活動的基礎（參見國富論：第一篇第一章論分工）

新創公司，資訊產業也不例外，建立一個好的團隊，是擴展未來的主要關鍵。雖然好的團隊沒辦法保證生意蒸蒸日上，一切順心如意。但是一個糟糕的團隊，卻是可以保證企業和組織的失敗指日可待。


市面上團隊合作的企管叢書，方法論，激勵理論，顧問大師...很多。但就和所有的事情一樣，越是很多人在談論的事情，越是困難。成功的團隊真實例子極為罕見。

萬事起頭難，「組織並成立團隊」是達到成功團隊的第一要務。許多人常依賴運氣，或者隨遇而安的隨意組成團隊，但其實組織團隊是一種可以學習的艱深技術能力。

資訊相關工作的人，如果有機會能扮演組成團隊的角色，並有意識的學習其中，將會是個人成長的重要關鍵。（無論未來是朝純技術領導方向前進，抑或管理方向前進）


有很多原因，會讓一個人扮演組織團隊的角色。也許是一個新的專案，讓你來領導專案，而恰巧專案開始的時候沒有既定的人。也許你是新創企業的創始人，你打算聚集一些人來開發創新事業。也許你是資訊相關科系的學生，因為課程需要必須組織團隊完成專案。

不管如何，如果你有「從頭開始找人選人，組織團隊，完成某件事情的機會」，請衷心的痛哭流涕的感謝上帝，這樣的經驗，在資訊科技領域裡是十分難得。

通常，由於各種背景壓力，組成團隊的方式通常就是先根據需要N個人，然後「儘速」透過各種管道，找到可能的人選，經過正式面試，或者非正式的聊天，就逐一邀入加入此團隊。這種方式沒有不妥，只是這樣的方式（如果算是一種方式的話）有很大的成分依賴運氣。如果不想依賴運氣，其實需要考慮的實務步驟也不多。


以資訊相關工作為例，組成團隊必須要有以下三個步驟：

步驟一：定義目標

--- Your goal shouldn't be to buy players, your goal should be to buy wins. And in order to buy wins, you need to buy runs.   (MoneyBall)

定義目標，必須要在團隊開始組成之前，就先找到並且定義完成...最起碼是團隊差不多組成的時候就應該決定。

定義目標並不容易。

例如，以類似的資訊系統外包案而言，有些明顯的目標是「在成本內完成專案並驗收通過」或者「在期限內通過驗收」。但是，倘若一開始的合約是低價得標，而且還是業務亂搶合約，那麼一開始就已經知道不可能在時間成本內驗收通過。則團隊目標必須要轉換，例如「完成專案過程可順便完成重複利用的元件讓未來標案能大幅降低成本」。

大部分的資訊團隊真正的目標並非「技術達成」。例如，「完成iOS APP線上購物」這通常不是真正目標，真正目標通常是「在某移動通訊市場上，讓使用者可以線上購物」。

在營利企業裡，大部分的真正目標通常關聯到增加收入或者降低成本。而在非營利企業（例如研究單位）團隊的目標有可能非常模糊。例如，一個碩士班的實驗室團隊，他的目標可能是「培養人才」，也可能是「讓主持的教授獲得升遷的點數」。

定義目標雖然不容易，但掌握以下三點可以除去大部分的誤差：

(1) 定義目標後，審視檢查這個目標背後是否還有目標。例如，籃球比賽目標，某球員目標是得30分。但其背後還有個目標就是球隊要贏球。在球隊沒贏球的情況下得30分可能沒有意義。

(2) 定義目標後，檢視此目標是否只是某個大目標的一小部分。例如，某些NBA的球隊，會談論是進入季後賽的目標，然而背後的大目標其實應該是拿到總冠軍 - 無論有多艱難。

(3) 定義目標後，檢視此目標是否因為其他條件未達成就失去意義？這時候所謂「其他條件」或許可能是目標。例如，一個團隊負責營運線上購物網站，其目標是「網站每分鐘必須可以提供10萬個使用者同時進行交易，7x24服務不中斷不當機」。然而，若此線上交易網站平均上線交易人數每分鐘才1人，即便營運團隊達到技術目標，商業目標肯定無法達成，則此團隊目標也沒有太大意義。不如改成「與業務團隊合作線上行銷活動，讓每分鐘平均交易人數成長XX%」

步驟二：組合優勢

--- The greatest improvement in the productive powers of labour, and the greater part of the skill, dexterity, and judgment with which it is any where directed, or applied, seem to have been the effects of the division of labour. - (Adam Smith)

無論用什麼方式找到團隊成員，資訊相關的團隊必然有分工，而分工必須要能讓成員發揮相對優勢。而每個相對優勢，都可以達到步驟一的目標之一。

構成團隊過程可能很多，但無非是找到某人，詢問意見，在某時間此人加入。然而，「加入之後做什麼」著重於考慮組合優勢。

台灣經濟學的入門書通常會用蓋木屋與磚屋的例子（參見這裡）簡單的說，組織團隊時，把成員的時間投入在相對優勢的工作上，可以達到1+1>2的效果。

實務上，分工時請考慮一下三點：

(1) 根據相對優勢來分工：盡量只考慮優勢，而不是先考慮缺點。

(2) 分工的結果，還是必須朝「真正目標」前進

(3) 整個團隊需要了解分工與分派任務的原因 

步驟三：產生運轉動能

--- All things are difficult before they are easy.


團隊組織完成，要開始運作，不會像籃球比賽一樣，十個人在場上，裁判吹哨跳球就開始。

團隊前進需要累積動能。就像騎腳踏車一樣，從靜止到穩定前進，會花比較多力氣，然而一旦穩定前進，就很輕鬆。

產生動能指的是團隊成員已經彼此合作，彼此鏈結工作，發生問題也可以彼此協調解決。

以資訊科技為例：

最常見也是最糟糕的產生動能方法是由專案經理透過一連串的方式 - 通常就是開會 - 持續讓事情前進。團隊成員花在正式會議上的時間比例只要超過10%(也就是每週超過4小時)就屬於這種類型。


最佳，但是最罕見的產生動能的方式是由每個團隊成員，透過自身的判斷，做會讓事情前進的動作。類似足球或者美式足球的比賽。在資訊科技團隊中，這種組合需要時間磨合成員，而且也須一點點運氣，讓團隊的成員大部分的能力都可以足以某種程度的獨當一面。

如果你剛好是資訊科技/軟體開發的團隊領導者，至少要先避免最差方式，並且透過你的領導能力，讓團隊慢慢的朝向最佳的方式前進。

實務上有三個重點方式：

(1) 資訊透明：讓所有進行的事情透明的讓所有人取得。要注意，資訊透明指的是針對確定的事實透明。非確定的事實就是所謂謠言，要緊記：謠言止於智者，起於智障！

(2) Scrum中的豬雞原則：請參考這裡。在組織產生動能過程，豬負責的事情就由豬來決定，雞只是提供參考意見。

(3) 檢討 retrospective：需要團隊自我檢討任何不正確或可以強化的地方，檢討並非開批鬥大會，目的在於讓團隊能更有效率的，以及確保團隊真的朝向目標前進。