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

老馮是軟體專案經理，在專案進行的某一天，被高層找去開會。高層：「最近雲端計算很火紅，你的專案既然是跟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] 你能單靠記憶，繪出目前專案個模組之間大概關係，無須依靠其他專案成員？

資深與中高階人才選用：三個要點

在資訊科技領域裡，資深或中高階人才選用遠比找到剛畢業很有潛力的人來的困難重重。

詭異的是，幾乎所有已經在資訊科技領域工作7年以上的資深專家，通常多少都會遇到獵人頭(hunter)的引誘。事實上，中高階的職缺其實很少，由組織內部升遷的機會很大。然而，如果真的從組織外部尋找，雖然看似符合條件者眾多，但能有效媒合卻是難上加難。

要點一：情境實例面談

絕大部份的中高階人才之所以是「人才」，乃是根據其真實的過去事蹟。而非未來想像。

在書面篩選階段，通常是根據過去工作經歷，決定要不要請來進一步面談。

而在面試階段，卻常落在討論未來的理想和展望。的確，未來的理想跟展望，的確很重要。不過，在面試階段，要判斷此人能否實現理想和展望，應該是根據其過去的「理想與展望的實際產出」。

一般外商HR的實務操作方式為：面談時著重於情境「實例」。(SAR: Situation Action Result) 

例如，有個軟體研發部門RD主管的履歷表中，表示有帶領軟體開發團隊開發軟體。此時開放性問題無法真正展現該主管的經歷，應該採用情境實例問題，了解過去的「真實例子」。

-- 爛問題範例 --

未來取向的開放性問題：「未來你如何帶領開發團隊？」「你覺得RD團隊應該如何與業務團隊溝通？」....這種問題的回答必定是十分鐘不著邊際的長篇大論。

-- 好問題範例 -- 

初級情境實例問題：「目前你的團隊共多少人，其中有直接report給你？」「此專案你本人有參與寫程式嗎？」「此專案你本人有執行code review嗎？」「這個專案一共大約產生多少行程式碼？」

......初級問題著重能取得簡單而無可偏頗的答案，答案可能為「是或否」，可能是「數字」。回答應該是在10秒內。




中級情境實例問題：「在帶領N個人的團隊裡，你個人做過哪一件事情對團隊合作最有幫助？你怎麼做的？結果是什麼？」「在之前的工作裡，你做過最糟糕的決定是什麼？為什麼此決定是最糟糕？」

......中級問題著重於過去的某單一事實，必須引導回答針對這個人的實際作為，以及產生的結果。如果詢問的問題是負面資訊，例如犯下的錯誤。必須確定是問到犯下「最大的錯誤」。在面談過程，如果一個中高階主管，在過去7年的職業生涯沒犯任何錯誤（或者拿一些小小的失誤當作談話材料），很可能是隱藏事實，但更糟糕的是，他不覺得自己有任何錯誤的地方。


高級情境實例問題會和另外兩個要點：「本職學能」以及「獨立執行單位有關」請參考以下兩節。


簡而言之，SAR的基本概念很簡單：找出事實，而非空想；討論實際，而非理想；了解過去，而非未來。這部不代表理想與未來不重要，而是要判斷中高階人才的理想與未來，應該是看他「過去實踐過多少」，而非不是他「打算未來實踐多少」。


參考資料：(Careerly, SAR)

要點二：本職學能

已經位於組織中高階，很有可能早已不具備，或者喪失本職學能。因此，正確判斷是否具有合適的本職學能極端重要。

然而，中高階位階的人，其本職學能比較抽象，需要有方法加以判斷。

資訊科技領域的判斷方式有：(1) 基礎經歷 (2) T型延伸 (3)培育人才


(1) 基礎經歷：

以職業籃球為例，目前NBA的總教練，必然曾經在他人生的某個時期是「頂尖球員」，也許只是在NBA眾多明星中的候補球員，但也至少是NCAA某個第一級學校的球星。縱使不是，至少也是在高中時期，某一個州的的MVP等級球員。總而之之，他必然曾經當過明星球員，因此在當總教練的時候，能夠了解一整隊明星球員的思維，球員在比賽時的「真正作為」

同樣的，假設在軟體開發，找尋中高階的帶人主管，他本人必須「曾經是軟體開發人員」，最最最起碼也需要有3年以上實務寫程式的經驗。一個的SA或PM，也許工作的經歷還不錯，但如果沒有務實的寫程式經驗就來帶領開發團隊，就好像一個資深的球隊經理，看過很多比賽，卻沒有實際上打過球，就來當總教練一樣的危險。

或許有人會說，有些人屬於「將將之才」，他當將軍比當士兵還適合，不應該以過去的基礎經歷來斷定。在其他領域，或許是，但在資訊科技領域，「沒寫過程式」就是「沒寫過程式」。


其他的基礎經歷，必須有「清楚的事實」的佐證。例如，在履歷表上有AWS的使用經驗，就必須要清楚地知道何謂使用經驗？是用過EC2/S3/Route53，還是用過那數十個服務的哪些服務？是自己親自使用還是「指揮」別人使用？使用的規模有多大？等等


(2)  T型延伸

T型延伸的基礎是先有「基礎」，因知識與職責擴展的關係，延伸到其他相關領域。例如，在已經有智慧型手機應用程式開發的「基礎之上」，延伸到線上行銷，社群開發等等。

誠如前一節所述，沒有基礎，延伸不具意義。

關於T型人才，請參考這裏與這裏。

(3) 培育人才 

並不是每個人都會是好老師，不過如果中高階人才承擔的任務與管理有相關時，能否「培育人才」將會是團隊成功的關鍵。在SAR的方式裡要找到培育人才的方式很簡單。初級問題像是「你個人過去六個月以內，做了哪一件事情最能幫助團隊培育人才？」。中級問題像是「」

要點三：獨立執行單位

資深的工程師和初入社會的新鮮人最大的差別之一，應該是能夠自我成為一個執行單位。判斷是否已經成為獨立執行單位，是選才關鍵要點。


判斷的基礎方式有：(1)自我培養，(2) 計劃未知，(3) 人才培育。



(1) 自我培養

可以在組織裡，自行培養自己，發起並參與適當的事件。在中高階人才中，不存在「組織要協助培養能力」的情況。

這並不代表不用學習，只是不應該透過組織來建構自己的職業生涯和學習計畫。資深與中高階人才，應該要能自己規劃學習計畫，主動學習，並且「主動」將自我成長與組織成長「整併」。

僅專注在自我成長，對組織沒任何好處。努力使組織成長，放棄自己的成長，對組織也沒有好處。雙贏才是長久之計。



(2) 計劃未知

沒有人能預測未來。但資深中高階人才，應該能透過本身的技術能力，工作經驗，長久累積的直覺，有效看出至少數個月後的可能發展，並能有效制定計劃。

計劃(plan)本身並不重要，重要的是做計畫(planning)。中高階人才應該能在有限的已知情況中，盡可能計劃未來，建構真正的目標，評估控制風險。

而這計劃並不是為了展示，也不是文書作業，也不一定需要900頁巨作。關於計畫，請參考這裏。


(3)人才培育：

請參閱前一節的培育人才。

工作學不到東西：三個自立的方法

在資訊科技的公司裡工作的人，無論年資，大概常會聽到有人提到「在這裡學不到東西」「這個team沒有給足夠的訓練」「在這裡的發展有限」等等的牢騷抱怨。抱怨自然是人之常情，不過，個人職涯最終還是決定於自己。換言之，大部分的情況下：公司，環境，同事，工作內容...等等大概都不是「學不到東西」的主因。

任何情況下，都有以下三個實質的方式可以嘗試。

方法一：理解事實

任何事情，一開始都應該理解事實。

先確定是組織或者公司無法給予足夠的學習機會，還是自己沒辦法自我學習？假設沒辦法判斷，99%大概是屬於沒辦法自我學習的情況。

事實無好壞之分，事實只是單純的事實而已。然而，試圖了解事實有時候並不簡單。

一個剛畢業的學生，除非是高斯， 埃爾米特之類的天才，否則幾乎在任何組織裡，都有可以學習的事物。特別是在資訊科技領域裡，無論是正面學習，側面學習，甚至負面學習，在一段不長時間內(1-3個月)一定可以學到某些新技術，某些新觀念，某些應該避免的不正確的事情。

如何了解事實？可以試著問自己以下問題：

（假設處在一個軟體開發的組織中）

* 在這個組織裡面，所有相關技術你都能有效掌握？

* 組織中沒有人比你資深？

* 組織中比較資深的人，你都了解他過去的工作經歷？

* 目前組織中使用的程式語言，開發工具，你都已經徹底瞭解其優缺點？

* 目前整體開發過程的技術問題，都已經了解真正原因，並能務實地加以改善？

* 對於類似的軟體開發專案，類似功能的產品，都已經了解相較於自己團隊的優缺點，以及技術差異？

如果以上回答都是YES。事實就是這個組織真的無法讓你學到東西。不過如果有回答是NO，事實可能是你需要知道怎麼學習。

方式二：學習如何學習

請參考如何充實自己篇。

學習的本身是需要學習的。雖然每個人的學習方式略有不同，但提昇自己如何學習的能力，遠比把自己放在「可被教學」的環境來的重要。

簡而言之：花錢去上教學課程，在工作中有資深同仁可以帶領，參加各類型研討會...等等，這些雖然絕對益於個人成長。但是，「靠自己獨立學習」卻是一個難能可貴的技能。

而這項自我學習的技能也是需要學習。這衍生出看似複雜的問題：個人能否自我學到自我學習的技能？

撇除邏輯上的矛盾，找到適合自己的方式最為重要。若還沒有找到，可以參考如何充實自己篇。

舉個實際一點例子，假如你想學習作為一個好的軟體團隊中的QA，隨便在google或者youtube搜尋一下相關字眼，起碼可以找到數十個相關的教學文件甚至錄影。

認真花上幾個小時看完以下網頁以及教學錄影，相信你對這個主題肯定有某程度的瞭解。這都是僅透過"how to be a good software QA" 以及相關關鍵字搜尋得來：
1 http://www.guru99.com/software-testing.html
2 https://www.youtube.com/watch?v=sab0dblUpIE
3 https://www.youtube.com/watch?v=G5RpYi2dT04
4 https://www.youtube.com/watch?v=j8kY9txH2bc
5 https://www.youtube.com/watch?v=xCwkjZcEK6w&list=PLXXvO4OXeJrfbPrI0CV-re2VkdiV1dC7X 
6 https://www.youtube.com/watch?v=vimfiZZ4NI0&list=PLZTe0pWS8OYv3KYWJTZT_3chbtpXBoiOz&index=6
7 https://www.youtube.com/watch?v=OLayCNOPWIo

8 https://www.youtube.com/watch?v=hMfPCdF07hA

方式三：做出結果

資訊科技相關工作，特別是和軟體開發有關的工作，「學習」是很重要，但是「產出」卻更為重要。而產出就表示有具體的結果出現。

例如：這幾年data scientist相關話題非常熱門，有許多已經在職場2-3年的軟體工程師，常常會以這工作能否讓他有「data scientist經驗」為學不學到東西的考慮因素。

然而，其實特定技術領域，學東西最正確的方式，應該是自己能做出「某種結果」。

如果想要有data scientist工作經驗？有太多現成的「真實」工作經驗可以自行取得。

在大部份組織內部，都有很多無形產生的資料。這些資料，絕對足夠一個程式設計師學習以及做出學習的結果。

例如：

•  程式碼版本控制系統(git, subversion, svs)。含有整個專案開發過程的「實質進展」資料，可利用他做時間序列分析，程式設計師個人績效分析。目前早有許多專案提供工具。
• 組織的AD資料。正常情況下含有可供內部公開使用的資料，例如組織架構，人員變更。
• Web Log。現在大部份的專案多少都使用HTTP，他必然會產生足夠大量的Log。一般Log分析工具（例如AWStats）已經可以做基本的資料分析，再配合machine learninig就可以做出各種有趣的結果

至於在組織外部，機會更幾乎是無窮盡的，也可以透過某些網站取得真實的資料，做真實的工作。例如：kaggle :在此有真實的專案，任何人都可以取得資料，透過自己的能力，完成資料分析專案。其他像是一般外包的網站：upwork.com也會有類似的工作，但可能不見得可以取得真實資料。

以結果為導向的學習，會比較腳踏實地，並且容易達到想要的效果。然而需要個人的興趣以及決心來支持。

---

參考：努力的三個迷思

如何組成團隊：三個步驟

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

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


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

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

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


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

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

通常，由於各種背景壓力，組成團隊的方式通常就是先根據需要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：需要團隊自我檢討任何不正確或可以強化的地方，檢討並非開批鬥大會，目的在於讓團隊能更有效率的，以及確保團隊真的朝向目標前進。

工作筆記的三個重點

這幾年來，市面上有如何做筆記的書。例如記事本圓夢計畫，重點就是要這樣記，不花錢學筆記(註1)等等。

在 youtube上也有很多類似的教學影片，在youtube上搜尋"how to take notes"可以找到數十個教學範例：例如這裡。

大部份的筆記教學，大概都是透過個人經驗，指引筆記的技術。例如，有效使用不同顏色的筆，將一頁分成兩欄，左欄做為索引用途，右欄作為記錄重點用途，等等。

而筆記教學的目的，則和筆記教學的內容有根本上的差距。筆記的「目的」，通常極為崇高，例如實現人生夢想。但筆記教學「內容」，卻是極為底層，例如，試圖說明為什麼紅色的筆，適合書寫哪些東西。

其中的差距，其實只有三個難以實踐的重點。

找到並擷取重點，採取正確形式，定時審閱檢討。

重點一：重點

無論是會議紀錄，執行工作中的紀錄，在學習新技術的筆記，都應該擷取並且記錄重點。

這是無庸置疑，但不見得容易做到。

以軟體開發而言，會議記錄的首要重點在於「結論」，而結論的重點在於「會議後執行的行動」。會議的過程，熱烈討論的經過也可以摘錄重點，但都沒有最後結論來得重要。

以學習筆記而言，如果是要學習既存的軟體程式，以便於接手未來開發工作，學習的紀錄重點在於「為什麼」程式會這麼撰寫，而非程式怎麼被執行。因為「為什麼」的理由可能只有當時的工程師才知道，而怎麼被執行，卻是原始碼的本身就會告訴你的。

以日常工作記錄而言，工作八個小時之後，重點在於紀錄「今天你認為已經完成的最有價值的事」。並記錄為什麼這是有價值的。

重點的節錄，不見得只有「寫下來」這種方式。當特殊email出現(例如變更規格email)，可以直接列印出來貼在筆記本上，不但節省記錄時間，還可以完整紀錄email時間和收件人。當技術討論會議結束時，將白板的複雜圖形拍照，直接email，或者列印，或者交由虛擬助理後續處理，都是簡單有效的方式。

庶務(註2)上的重點，也應該當重點擷取紀錄，但要切記不要將紀錄庶務，當作有價值的東西。應該統一記錄在某處即可。

補充一下：

在工作中，重點難以找到的原因很多。例如：每個人認為的重點不一樣；重點有時候會轉移；這事情壓根就完全不重要...等等。

根據自己對團隊組織的存在價值的正確理解，再加上對自己目標的認知，才能記到真正的重點。

以startup為例：三個初創的創業夥伴，各有1/3的公司股份，則必須要對組織未來存在價值有正確共識。假設其中一個人目標是希望能在2年內損益兩平，而另外兩個人則是希望在兩年內能獲得某程度的市場佔有率。這兩個目標就非常不一致，透過工作筆記「重點」的紀錄，很快就可以察覺不同（請參閱第三段審閱）

以在大企業工作為例：一個10人的軟體開發團隊，其目標是在某日之前完成某產品功能。其中有3人是負責品質(QA)，另外6人負責開發(RD)，還有1位是專案經理(PM)。作為QA的人，其工作記錄重點，就應該會與PM有很大的不同。QA的所有工作相關記錄重點，應該是「到目前為止」的品質狀況。PM則應該是「到目前為止」所有利害關係人的期待是否被滿足。

重點二：形式

工作相關的筆記，正確的形式能獲取效率。

形式的優先順序應該是：

1. 圖
2. 表格
3. 條列式
4. 一段文字
5. 沒有紀錄

換言之，可以畫圖就不應該做表格，可以是表格就不應該條列，可以條列就不要用一段文字描述。可以有機會紀錄，就避免沒有紀錄。

以軟體工程師而言，mindmap (心智圖)可以擴大思慮完整性，並且將事情想得完整。UML的各種圖形標準，則已經涵蓋各種技術的表達的可能性，幾乎不需要其他規格的圖形。

如果是專案管理的角色，則RACI(表格)會很容易表達各種則關係。但是，如果要和利害關係人報告，則不可避免的應該使用投影片(slide)形式，作為表達的形式。

形式似乎很簡單。但是缺乏對形式的正確認知和練習，只會事倍功半。

一些例子：mindmap(心智圖)可以作為決策樹的前身或練習。任何文件(ptt,word)的表格，應該先在excel中實作之後，在插入投影片。任何excel的條列，必須是二維，並且應該先試圖使用pivot做簡單的分析。

重點三：審閱

定時審閱工作筆記，構成對於過去工作價值的概觀。


審閱的方式很簡單。固定時間（例如每兩週，每個月）把過去一段時間的筆記攤開，快速看過一遍。誠實的面對自己，「二次紀錄」需要改善的地方，特別是哪些事情「浪費時間」。然後，每年，固定時間（例如剛過完新年）審閱過去所有的二次紀錄的地方，再次誠實面對自己，審思如何改善。

如果你已經每天固定紀錄「最有價值的完成事項」，每個月應該花10分鐘，審閱過去的筆記。了解這些最有價值的事項，累積起來，確實讓這個月過得有價值。如果沒有，則應該「現在馬上」進行改變，即便只是稍微調整工作的方式，工作的目標，有改變都比沒改變好。

工作的會議紀錄，則要審閱並且演討「會議後執行的行動」。特別是沒有達到的行動。

工作的學習筆記，則要審閱之前有問號(?)的記錄之處，是否已經都了解。在工作中如果有發現之前紀錄沒有發現的問題，則應該額外紀錄遺漏之處。

沒有固定審閱筆記，跟沒有做筆記基本上是差不多的。

沒有審閱並事後查核會議紀錄，等於會議沒有紀錄。

審閱，能達到筆記真正的崇高目的，也就是幫助「未來」而不是僅只記錄過去。





註1:不花錢學筆記，這本書不是免費，還是要花錢買。

註2: 所謂的庶務，指的是某些資訊或者行為，本身也許有價值，也許沒價值，但無論如何，它不是這個團隊存在的重要過程或目的。例如：某個特殊系統的帳號密碼，大企業裡某些申請經費的特殊流程，辦公室阿桑固定掃地時間，福委會團購產品方式，某些高層主管定時會議的地點等等。很多大組織（特別是公務機關）中的老員工，把熟知庶務當作本身的價值。在資訊不發達的時代確實如此，但在今日已流於荒謬。

---

沈思：

1. 工作筆記的其實和紀錄的工具沒有太大的關係。不過，如果你是在西元2006年之前投入職場的人，在哪邊可以看到10年前你的筆記呢？今年(2016)你的筆記，以哪種形式存在，會留存比較久？

努力才會成功：三個錯誤方向

有努力不見得有收穫，但沒有努力就沒有收穫。因為努力是通往成功的唯一道路。

然而，對於努力有很多錯誤的認知方向。

以下列舉最常見的三個錯誤方向：

錯誤一：「用力」就等於「努力」

「努力」和「用力」是兩回事。

試圖只用雙手去移動開一整座高山是「用力」；研究各種方式和技術，挖出一條筆直的隧道是「努力」。

在專案遇到困難時，千篇一律的超時工作，無止盡加班是「用力」；探究各種技術的突破，讓專案有進展是「努力」。

在傳統企業推廣資訊科技應用時，苦口婆心的淳淳告誡是「用力」；透過強迫的方式，逼使使用者改變習慣是「用力」；透過各種巧思，讓人願意自己使用新系統是「努力」。

錯誤二：努力一萬小時就會成為天才

小提琴家Auer曾回答學生說：「用手指練琴，可以練一整天，但是如果用頭腦練習只要一個半小時」（參考這篇）

「努力」是需要花時間，然而，努力更要花的是思索以及驗證事物的本身是否朝著正確的方向。瘋狂的往錯誤的地方磨練一萬小時，不會讓錯誤變成正確。那努力一萬個小時變成天才，指的是有用頭腦的一萬個小時，而非不經思索的一萬小時。

但是，努力所花的時間容易被人看到，而且容易讓人產生「同情」。因而，在企業中長時間加班的人，很容易被表揚；在專案延誤時，帶領團隊不眠不休努力，容易被認為是負責任；讓專案順利完成，讓系統保持為定沒有問題，容易反倒被認為沒事做。如果你是領導者，切記不要過度獎勵沒有功勞也有苦勞的情況。

錯誤三：努力的筆直前進

如果目標與達到目標的方式是錯的，努力就變成可怕的慘狀。許多人常被一個故事所誤解（掉到奶油桶的青蛙）認為只要堅持下去，也許事情會有轉機。然而，故事裡的青蛙其實已經採用正確的方式 - 也就是一直游蛙式。如果青蛙使用更有持續性的方式維持生命 - 也就是水母漂，那麼無論如何不可能攪動成為乳酪。

幾乎任何情況下使用googlemap規劃最短時間的路程，絕大部份都不會是筆直：最短時間的路徑，通常不是最短的路徑。

努力的目標要正確：確定努力的目標是你真正想要的目標。

努力的方式要改進。努力的增加知識與能力，讓進行的方式可以朝向最正確的路徑，而不是看似最筆直的路。

在盈利企業裡面，整體努力目標應該是合法的獲取利益；然而，在企業裡面投入工作的個人，在工作上卻應該是根據自己的工作內容訂立正確的目標，如果是業務當然是獲取訂單，如果是生產部門，也許是極大化產量，也許是平衡品質與成本。但是，下班後，目標應該是自己的目標，例如陪伴家人之類。

一個業務，無論採用什麼方式當他的業績，一年後沒有達到目標，當他要「繼續努力」的時候，一定要採取別的方式。繼續堅持用舊的方式，也需要「努力」了解為什麼舊的方式可以持續使用，而不應該改變。

大部份的專案，目標通常都已經定好，然而執行的方式卻應該根據實際的情況改變。例如：在前期中期發現有重構(refactoring) 的需要，就應該先考慮重構，而不是試圖先達到某個帳面上的milestone。

大部份的辦公室日常活動，其價值都越來越低，努力的方向不是增加手指打字的速度，也不是加班完成任務，而是朝向去除完全不必要的事情，簡化或自動化簡單的事情前進。

---

沈思：

努力而失敗的例子太多，可以找到在你的工作領域上的例子嗎？

成長的最好方式 - 反省

曾子曰：「吾日三省吾身：為人謀而不忠乎？與朋友交而不信乎？傳而不習乎？」

反省是進步的最好方式。然而，檢討專案，檢討工作內容，或者檢討自己做對了，或做錯了什麼，卻是需要有結構性的方式來進行。光在腦袋裡想像是很難有具體效果。

普通人大概沒辦法跟曾子一樣每天反省自己，不過，新的一年通常是反思的最好時機。

檢討反省有三個要點：

重點一：目標導向

檢討需要有目標，就算是很隱私的個人檢討也是。反省的目標不同，就會有截然不同的結果。

以帶家人出去玩為例：

如果「全家開心出去玩」是「目標」。則旅途中的延誤，改變行程，物品遺失的檢討目標就應該是如何在意外發生的時候，讓家人仍然很高興的享受意外，享受旅程。

然而，如果心理設定的目標雖然是 ：全家開心出去玩，但檢討的目標卻是怎樣更有效率的旅行，那最後很可能導致全家旅行越來越有效率，但大家心情越來越不好。



以專案管理為例：

在專案完成，或者一個sprint的結束，在回顧檢討(retrospective) 會議的做法，通常是讓大家以「實例」，說明哪些事情做得好，哪些事情做得不好。接下來將這些實例分類，並且用投票的方式，選出最最最需要改善的幾點，指派專人在下一階段負責改善。

同樣的，負責人是以最終目標為檢討改善的目的。假設某手機APP的開發，最終目標是「能在耶誕節前有百萬使用者」，則列出最需要改善的幾點，都必須要朝最終目標前進才對。因此：「與客戶協調上架遞延到12/24日以便確保品質」就是一個不很合理的目標。

要點二：用事實去除人類偏誤

正常人都是以自己的主觀來看這個世界，因此每個人都有對事情的偏誤(human bias)。

檢討與改善的重點在於：盡可能認知人類認知偏誤的存在，讓偏誤在不造成致命影響。不過，要完全沒有影響幾乎不可能。

人類偏誤有很多，舉一些例子如下：

歸因謬誤：對於自己的行為，容易歸類為外在因素，對於他人的行為，容易歸類為內在因素。例如，自己遲到，容易認為是塞車，或者昨天太晚睡；別人遲到，容易認為是他的紀律問題。

負面偏見：人對於不好的記憶印象比好的記憶深刻。這可能和演化有很大的關係，人必須要先規避毒蛇猛獸之類的天然風險。

稟賦效應(Endowment Effect)：同樣的東西，如果已經在手上，則會難以放棄；但如果不在手上，卻認為比較容易取得。例如，自己的車子想賣，總是會想要賣比較高的價格，並且自己也會對這個高價格找出自認為合理的原因。這也是大部分物價易漲難跌的因素，因為銷售物品的人，如果已經用100元能賣出某物品：即便成本降低，即便知道降低售價可能增加業績，但在心理上很難主動降價。





誠如前述，要去除自己「所有的偏誤」是絕對不可能：沒有人是聖人，永遠不會犯錯。但是，去除不必要的偏誤讓自己朝正確的方向前進，卻是不難達到。去除自己的偏誤最好的方式就是根據事實。

因此，在檢討事情的時候僅就「事實」加以檢討。

例如：

事實是「專案每日會議，5個人有3人一定會遲到30分鐘」，根據事實檢討如何讓這3人不會遲到，不需去研究3人遲到的個別因素。也因此，根據事實，將會議時間往後延30分鐘是合理選項。

但是，如果有人試圖追尋某個老是遲到的人的「個人紀律」，「團隊精神」這並非不是事實，只是這類型的事實，沒辦法客觀認定，也不可能客觀評量某一個人的「個人紀律」比另一個人來的好。因此，這些主觀的「事實」，因太容易有主觀偏誤，不應該作為檢討的項目。


再舉另一個例子：

事實是「目前手機APP是使用者付費9美金才能下載，目前每個月約有1個新使用者」

檢討的目的如果是要增加收益，則在現在的事實基礎上，資訊是遠遠不足。因此，這個事實的討論結果勢必是「沒有足夠的事實」可以檢討。

當然要找到所有的事實也是不可能。所以，在這個例子中，起碼找到「新使用者為什麼會買」，「其他類似APP是否收費」，「其他類似的APP在不收費的情況有多少使用者」等等資訊，以便作為檢討的基礎。

方向三：行動優先

反省檢討的目的，不僅只為了知道「我錯了」，重點在於「如何才不會再錯一次」，或者「怎樣讓事情變得更美好」。

誠如前述，人非聖賢，要變成完美的人是不切實際的期望。然而，改變自己的一小部分想法跟行為，讓自己的未來變得更好，卻是可以腳踏實地的達到。

行動必須要和反省與檢討一致，至少邏輯上一致。行動的本身不見得一定要有所「行動」，有時候不做任何事情也是一個選擇，但如同這裡所描述，要確定「不行動」這個選項是和其他選項一起考慮過。

例如：「目前手機APP每個月有1個新的使用者，想推廣給更多使用者」，經過檢討之後，覺得「利用社群網站」：這裏的行動就是利用社群網站推廣。可能是利用facebook的廣告，也可以利用團隊成員每個人都到facebook上貼文，也可以建立粉絲頁。

無論如何，既然要檢討，就應該有行動。沒有行動的檢討，不具任何意義。

---

沈思：你大概多久會檢討自己一次？

大學或研究所玩太久.(三個解決方式)

有幾次面試新鮮人，發現有些學生自覺得在大學研究所時代"玩得太久"，而對於即將投入就業市場有些自覺能力不足。

首先，如果照著學校教育做好該做的事情，就算沒有「玩很多」，老實說能力一樣是不足。想要在還未就業之前，就達到一個好企業的標準是有點難。當然在學時期，有很多事情，對就業有極大的幫助（至少就軟體以及網路產業而言），但是大概都不是台灣學校教授能教的。

這些事情像是：加入open source的開發工作，找暑期工讀，到外包市場接專案等等，都對自己有幫助。

但如果你已經來不及這麼做，就面臨畢業了。那麼除了延畢，隨遇而安看命運安排，拒絕面對事實...之外，其實有三個實質的作法可供參考。

對了，要記得，任何時候都為時不晚 只有覺得太晚的時候才太晚。



三個解決方式：

(1) 解決方法一：快速學習技術能力

想要投入資訊產業，不管擔任什麼角色，擁有技術能力永遠是對的。

找一個喜歡的目標，全面性的學習相關能力。不見得一定要花大錢上課，網路上現有的免費資源一定可以讓你在2-4週之內(最遲不超過4週)學會某種東西到一定程度。不管是Java programming還是HTML5，不管是Big data analysis還是photoshop應用。

如果對於快速學習技術能力有進入障礙，要記得這一定只是進入障礙而已。只要有興趣，願意專注，到目前為止還沒看過學不會的。真正問題在於有沒有專注的付出時間，如果確定資訊科技對你來說是完全沒興趣的，那也好，就此打住，改換跑道為時不晚。

(2) 解決方法二：尋找互蒙其利的機會，藉此重建履歷

很多時候，你需要的只是找到一個可讓你有學習機會的環境，這個環境可以促使你成長。如果不花錢，有什麼機會有這種環境呢？可以去看看upwork.com, guru.com, fiverr.com到上面以賠本的價格接專案來做，就會知道目前市場環境中缺乏什麼。

(3) 解決方法三： 打工與學習

這和解決方法二有什麼不同？打工是泛指先去做你不是很想做的事情，例如contractor。這除了可以讓你舒緩生活費用的問題，增加獨立性，也能獲取一些時間，讓你想一下自己有什麼選擇。

打工與學習，泛指各種範圍。在網路時代，只要知道怎麼找，資訊幾乎很容易取得。例如，如果你是26歲以下的女性，喜歡小孩想要學德文，au pair是一個看似誇張，但是合理的選項，參考這裡。




創意沒有極限。不要只接受片面的資訊，即便是這裡也一樣:)

---

沈思：

1. 經濟學鼻祖書：國富論一開始就是在說明分工的重要。這也是就業市場上，各種職業產生的真正原因。能不能找到自己相對於別人的比較利益優勢？

2. 以長期而論，自己想要什麼很重要。但是短期來說，自己有什麼選擇才是關鍵。

3. 這三個解決方法，看起來都沒什麼創意，但是跟隨波逐流比起來，還有其他方法可選嗎？

新鮮人如何提昇在組織中的價值：三個方法

請務必先看關於價值的這篇


稍微提醒，價值與績效的不同。

績效著重的是將評量標的量化，所以通常都會有明確的時間點、目標以及數字；而價值則看重在一個連續時間的累積。

比如說餐廳擦桌子 ，績效可能會訂成：在客人離開以後的五分鐘內要把桌子擦好，桌面必須全部擦過，不能有菜屑湯汁；而價值可能是：在客人離開後迅速把桌子擦乾淨，展現本餐廳專業乾淨的形象，並提供下一位客人舒適的用餐體驗。

所以你會發現，這兩個本質上其實是同一件事，只是觀看切入的角度不同；績效跟個人日常工作內容習習相關，而價值則是較與公司的整體特質相關。


(1) 了解組織需要的價值

身為一個新鮮人，通常前輩不會大費周章的跟你解釋組織需要的價值是什麼；而另一個悲傷的現實是：有些前輩自己也搞不懂組織要的價值是什麼？

所以這一部分通常必須要自己有意識的去了解。至於要怎麼能夠了解組織需要的價值？若完全沒有概念，可以參考以下方式

1. 參考資料：有些公司會寫出他們的價值，比如：IBM、Google、Microsoft，或者公司內部訓練裡會提到，但大部份很可能只是打打高空，只能給一個很粗淺的概念。

2. 角色扮演：想像自己是老闆或是主管，想想要怎麼提升組織整體的價值？比如是處理財務的事務，精準的重要性一定會高於迅速；而若是救火隊或急診室，快速解決問題一定會比完美來得重要。想想客戶為什麼要買公司的產品，它對使用者最大的幫助是什麼？

3. 工作觀察：倘若組織不大，可以從日常工作中觀察下列事項：什麼樣的工作有比較高的優先權？什麼樣的錯事大家會很嚴厲的對待？什麼樣的錯事大家可以一笑置之？想想為什麼？

組織需要的價值是會隨著時間變動的，了解組織需要的價值可以幫助自己更快的進入狀況，甚至做得好的話可以提前走下一步路，而不是每天被績效的項目追著跑。



(2) 發揮長處避開缺點


了解組織所需要的價值，同時你也要了解自己（相關文章）長處與缺點。把自己的長處放在組織要的價值上，就可以達到相輔相成的效果。比如說你是一個很細心有耐心的人，那就可以主動接下財務、編輯、校稿之類的工作；你若擅長收集統整資訊，那麼研究、匯整、之類的工作就比較適合你；若你可以在資訊不夠充足的時候，在短的時間內做出決定，那麼也許可以嘗試第一線的工作。

然而如果反過來，急性子選到財務對帳的工作；要收集完資料整體評估才能下決定的人被要求馬上要下決定，這樣就算工作做完沒出事，工作起來也是很累的。

事先了解自己與工作的屬性，當有適合的工作出現時，主動接下來，還可以塑造出工作積極的加分效果。另外有時身為新鮮人不一定有辦法選擇工作，但知道手上的工作跟自己屬性不合時，就要特別小心，才不會不小心出包。




(3) 專注於產生價值

如上一點所說，你找到一個極能夠發揮自己長處的工作，你也很認真地做好了它，但結果沒有人在意這件事？！

知道組織要的價值所在，才不會走冤枉路。專注在幫組織產生價值的事情上，對組織以及自己才有意義。

回到一開始餐廳擦桌子的例子：假設你是那位服務生，在尖峰時刻忙到都要「搓草」了，眼看有一張桌子前一組客人已經離開過了四分鐘還沒清理，而下一組客人已經站在桌子旁，甚至有人已經等不及入座了，此時你會怎麼做？

1. 直接衝過去在一分鐘內把桌子清理完畢，好符合擦桌子的績效要求。

2. 過去客氣地跟客人道歉，不影響到客人的情況下，儘速把桌子清理完畢以後再請客人入座，可以的話清理的時候還跟客人寒喧兩句。

或是你覺得有更好的作法呢？歡迎跟我們分享。

---

沈思：
了解組織所需要的價值，想辦法提升組織的價值，就等於提升自己在組織中的價值。如此一來，等同讓自己跟組織站在同一陣線上，而不是讓自己在組織中陷入一個你做工、我監督的對立狀態。

給不寫程式的人：發展手機APP事業的三步驟

這篇文章發表於2015 但是在2024之後，因為AI迅速發展，現實有很大的變化！因此，此文章已經失去時效性！步驟跟做法仍可以參考，但是必須要考慮AI的使用！

有智慧型手機的人，都會使用某些應用程式(APP)。

你一定也有常用的APP，多少也有自己想要的功能。也許你覺得自己有一些創新的APP想法。或許，你覺得現在用的Line總是有些地方很不滿，你覺得只要照你的想法去做，一定會讓使用者更滿意。

但是，也許你完全不會寫程式，或者雖然是資訊科技背景，但是對於手機應用開發缺乏經驗，也或許只是沒時間學... 最後自己總是覺得無法實現想法很可惜。

其實APP和一般的電腦應用程式不同，不會寫程式的人，其實也可以創造自己的APP，加入這個競爭激烈，但卻很有利可圖的市場。

如果規劃得當，是一個能以極少量成本，兼職創業的好方式。更重要的是，如果規劃得當，這是個極低成本的lean start-up，可以讓你多方嘗試可能性，但不用負擔失敗的風險。

不會寫程式，或者沒時間，但仍能發展自己的APP的成功案例是很常見的事情。例如airbnb，uber等。

事實上，有許多創業家一開始就選擇踏入手機市場，就是因為APP是能在極端有限的資源下，實現自己的創新想法的最容易的選項之一。

主要原因可能是：

在技術上：兩大主要智慧型手機陣營：iOS和Android都盡可能APP的開發方式標準化，簡潔化。目的是在於吸引更多開發群眾。而市面上也有太多工具，可以在某種程度上產生APP，例如appopus.com 或 appsgeyser.com 都可以把文件轉變成APP。技術上來說，等同於擁有一個可以個別銷售的電子書APP（註1）。換言之，APP的製作有越來越簡單的傾向。

在環境上：智慧型手機的市場遠比傳統電腦來得大，而進入市場的門檻極端的低。根據實際的經驗：以電子書而言，撇除掉撰寫的成本，僅就上架與行銷可能只要200美金。如果是具有傳遞訊息(類似Line)加上社群功能(類似facebook登入等等)，大概只要準備700-1000美金。如果是多媒體播放(類似youtube)則僅需要800-1200美金。而以上的參考數字，都涵蓋完整的完成具有完整前後端功能的APP，上架以及基本行銷。換言之，市場環境，大幅傾向低成本門檻。



在實際經驗中，任何人只要能學習以下三步驟，一定可以開發APP並藉此開創事業。（註2）

三步驟：想法具體化，找到正確的人完成APP，進入市場。

步驟一：將想法具體化

將想法具體化：是指把自己對APP的想法盡量用文字以及圖形表達出來，並且對於APP決定好基本的定義。

表達APP的方式有很多。首先要簡單地寫下自己的想法：例如一個可以互相傳遞即時訊息的APP（類似Line)但如果對方沒即時看到，就改用傳統手機訊息傳出。

接下來，使用網路上免費的畫圖工具，例如invisionapp.com 或者 fluidui.com，將自己的心理的想法具體化。

簡單的通訊APP(類似Line)的設計，練習個幾次，任何人都可以做簡單的設計。

想法具體化不是只有手機流程設計。最起碼還包含兩件事情的具體化：誰是使用者，以及：定義成功。

誰是使用者？

在你的心目中，用有哪些屬性的人會使用這個APP：就是所謂的市場區隔。雖然他可能會改變，但在這個階段，你需要自己具體化一個清楚的使用者描述。例如：「在台灣，25-35歲，單身男性，就業中，未與父母同住，使用Android手機」。

如果你的目標客群很大，例如：「在台灣，使用Android手機」。也並非不可，但是在之後進入市場時，可能不容易看到基本行銷的效果，或者需要極大的努力才能看到行銷的效果。目標客群越清晰，越容易看到行銷的效果。

如何定義成功？

在你的心目中，當APP完成放到市場上，經過3個月，達到哪些事情才算成功？自我具體定義成功，是發展APP的重要基礎。

成功可能是獲利。例如，假設APP是要收費，或者間接收費(例如廣告)，上架經過3個月，實際營收達總額達到1000美金就算成功。

但所謂成功，更有可能不是設定為獲利。例如，APP是免費，而且也沒有廣告，但上架經過3個月，希望實際使用者達到1000人。因為很多APP一開始是希望有大量使用人數，等到夠多人使用時，再考慮獲利模式就變得很簡單。（例如Line是免費使用，一開始是沒有廣告）

有創意的定義成功，能夠讓不寫程式的人，更容易看到手機APP的事業的可能性。例如：APP是免費，也沒有廣告，但上架經過3個月，希望所有已經安裝的使用者，解除安裝的比率低於15%，而且每天使用這個APP的比率要超過65%。換言之並不在乎多少人使用，只在乎這些使用者是真心的黏著在這個APP上。

步驟二：找到正確的人完成APP

好像很明顯，你需要找人幫你寫程式。

但是，其實你真正需要的是：找人幫你完整完成開發APP這件事情。

完整開發APP指的是：

(0) 將想法具體化   <- 這一點在步驟一中，一定已經完成。
(1) 先把APP的流程決定好
(2) 根據流程畫出APP的樣子
(3) 加上自己認定的顏色，圖樣，Logo
(4) 根據設計，撰寫程式
(5) 測試程式，確保品質大致沒問題
(6) 將APP上架：放到googleplay或者applestore
(7) 利用各種行銷方式，讓使用者下載，安裝，使用APP。
(8) 每一段時間收集相關資訊，了解此APP是否成功。


(1)-(3) 就是APP的設計，完成APP設計之後產生出APP的mock-up。這件事情可能在步驟一中自己做，也可以找人來做。

一般人都直覺地認為，「找人去做」表示執行(4) (5) 這兩件事情。但其實你真正需要的是(1)-(8)都需要有人執行。

找到正確的人的方式有很多，首先，先確定自己(1)到(8)能做哪些事情。然後，剩下的事情都要「委外開發」。

委外開發的最直覺方法，就是到外包網站上招標。例如：upwork.com ，guru.com， freelancer.com。外包的價格差異很大，而且軟體產生的品質和價格沒有直接關係。關於如何招標尋找正確的廠商，請參考這裡。

基本的參考數字：一個類似line的訊息傳遞APP，開發需要120-200美金之間，如果要涵蓋基本的UI/UX設計，另外需要50美金，如果要含品質測試以及上架，另外還需要30美金。也就是整體大約200-300美金可以完成一個還不錯的APP。（這個數字不適用於遊戲APP）

委外開發的其他常見有：找有技術能力的志同道合的好朋友；找學校的相關科系學生專案，等等。不過，這些常見方式，都需要一段時間的磨合，以及一段更長的時間的互相體諒與了解。

步驟三：進入市場

進入市場包含「上架」，「基本行銷」。想要長期留在市場，還得進行「維護」以及「未來計劃」。

上架：

完成APP之後，當然就是要進入市場。進入市場第一步就是將APP上架。如果是Android，自然就前往googleplay，如果是iOS，就去applestore。

「上架」需要一些步驟，對於非資訊科技背景的人來說，可能稍微困難，因此，在步驟二：找到正確的人完成APP的階段，必須要把上架當作工作的一部分。

Googleplay上架請詳閱這裡。Applestore上架請詳閱這裡。強烈建議不要看市面上的書籍，或者參考某些部落格的文章來當作上架教學。因為，這些書籍文章可能都是「過期的資訊」。使用官方文件，作為上架的使用指引，才不會浪費自己的時間。

基本行銷：

不過，上架只是讓市場有機會看到你的APP。這個世界上有近千萬個APP存在，要讓使用者能真的下載使用某APP並不容易。因此所謂進入市場，必須考慮基本行銷。

行銷可以很簡單，也可很複雜。最基本的情況是：你需要盡可能讓很多人知道有這個APP，下載這個APP來使用，如果APP需要付錢才能使用，則還得包含說服使用者鼓起勇氣付錢。

最最最基本行銷的過程是：找到目標客群，針對客群送出訊息，等候以及檢視結果。

找到目標客群：

定義目標客群應該是在第一階段完成的事情。這階段的目的是找到目標客群的「資訊傳遞」方式。最簡單的方式，是透過小型行銷公司，直接把你要找的目標客群的email找出來。只要你的定義夠清楚簡單，可以在前述的外包網站，找到小型行銷公司，以30美金的價格，取得大約500個大約目標客群的email。或者，也可以用15美金的價格，送出1000個目標客群的潛在facebook貼文。如果願意在行銷投入更多的資金，可以用200美金，購買一個月的google ad，讓自己的APP廣告出現在某些google adsense能抵達的範圍。

針對客群送出訊息：

取得email之後，可以利用現有的email行銷軟體。常見的像是mailchimp.com，klaviyo.com或者zoho.com，送出廣告信。信中當然就是這個APP的介紹與連結，還有一些說服別人使用這個APP的方式（例如抽獎活動之類）

email 行銷是很老套，但也由於是老套，所以很容易看到效果：例如多少人有打開email，多少打開email的人真的有下載APP。

如果是facebook行銷，可以花15美金，送出1000個目標客群的潛在facebook自動貼文。也可以花60美金，雇用虛擬助理，以人工的方式，逐一在潛在的facebook粉絲頁或個人頁，貼上獨一無二的訊息。關於虛擬助理，請參考這一系列文章。

如果是google adsense行銷，或其他網路廣告方式，預期每個月，可能會花上200美金。

但無論如何，手機APP事業的基本行銷費用，其實並不高。盡量利用前述的免費或者簡單的方式。不會超過200美金就可以達到某個程度的效果。

檢查結果：

等候一段時間，檢查看看APP的成功定義是否有被滿足。

如果你的成功定義已經被滿足。那麼恭喜你：你的APP是千萬中選一的好APP。你的APP事業發展在未來可能輕而易舉。只有極少部份的情況，是可以在一開始就這麼順利。
如果你的成功定義，沒有被滿足。那麼還是得恭喜你：你知道過去的做法一定某處可以被改善。根據手上有的資料，回溯之前的過程，找到可以改善的點，加以修改，然後重新觀察。一半左右的APP是落在這個情況。重點在於，如何根據現有資料修正APP或者修正基本行銷方式。

如果你的成功定義，不但沒有被滿足，而且實在差距太遠。那麼還是得恭喜你：因為你只花自己一些思考時間，以及500美金左右的成本，就證明某個想法在目前不可行。目前你的損失很小，可以再多嘗試其他主意。更重要的是，簡單而低成本的經歷失敗的「失敗經歷」極為難得可貴，是創業成功的不二法門。請參考確保創業成功一文。

---

參考： 

發展自己的APP事業，看似複雜，其實就是這麼簡單的三步驟。當你了解這些步驟，甚至可以把整件簡單事情，交由專門協助產生POC(Proof of concept)的企業來處理。

而你自己，只要專注在於「出個好主意」就好。

---

註1：如果你寫了一本電子書，可以在亞馬遜銷售，也可以在其他APP管道銷售。那為什麼需要自己獨立產生單一電子書APP？有很多可能：例如你想單獨獲利，不想讓各類銷售管道分享微薄的利潤；或者這是免費電子書，你想要免費分送，因為裡面可能有置入性行銷的訊息等等。

註2：開創APP事業如同本文所說很簡單，但要確保事業能成功極端困難，請參考這篇。

解決專案困境的三步驟(軟體主管的31堂課)

一個完美被執行的專案幾乎不存在，特別是越是有潛在價值的專案，通常會伴隨一定的風險，因此很難不遇到問題與困難。

有經驗的專案管理者，可以在問題發生之前先行規劃解決，這和專案一開始的結構設定有很大的關係。然而就像扁鵲的父兄的故事一樣，能在問題出現之前防範未然者，讓專案順利執行，這樣的人在台灣的環境，似乎難以被定義其價值，即便有也難以被發現。

總之，有價值的專案，無論如何，難題總是會在某時候出現。

在接案公司中，最常出現的可能是時程，需求過度擴張，等等常見問題。例如：協助政府建立某APP用以查詢政府


透過以下三個務實的步驟，協助解決問題

在這裡假設問題已經發生，必且這個問題不在專案進行的時候的風險規劃之內。

這些步驟乍看之下，可能會讓人覺得簡單到需要特別說明嗎？不過，實務上遇到專案困難時，由於時間的壓力以及人類固有的習慣，能保持平靜看待困難是不太容易的。因此，透過簡單的步驟。

某些人常會對於既定的步驟有些許誤解，認為規劃好的步驟可能會失去彈性，減低創造力。但如果掌握真正的精神，結果會正好相反。

(1) 第一：了解事實

大概不少人會認為這是一句廢話。不過，在遇到真正困難的時候，困難的本身通常會隱藏事實。


舉例來說，看似最常遇到的困難就是資源缺乏。以軟體專案來說，就是沒足夠的人力，或足夠的時間來做事情。

但是，絕大部份的人力不足，其根本原因都不是人力不足。

根本的因素可能是：現有的人沒有執行這方面專案的經驗；負責的專案經理能力不足，無法有效協調人力；現有的人員無心執行任務；規格不明確，而導致執行方向不正確，因而使專案到中後期看似沒有足夠的人力或時間完成...等等，諸如此類，才是真正的事實。

人力不足，沒有時間，只是表象。

專案負責人（可能是專案經理），必須要先找出事實。

一個很簡單的原則：如果有表象是「沒有人手」，「沒有時間」，「規劃的進度常常延誤」，專案負責人幾乎99%可以斷定背後必有其他原因。


了解並且面對事實是務實的第一步驟。缺乏這個步驟，任何其他的解決方法都沒有意義。

(2) 第二：模擬不同的解決方案

通常界定真正的事實之後，解決方式大概就隨即而出。然而，既然是困難的問題，就應該想出一個以上的解決方案，然後模擬可能的後果。

這裡強調提出不同的解決方案，因為既然是困難的問題，表示一定在有限的時間以及資源之內，無法簡單的解決。換言之，任何可能的解決方案都可以會犧牲某些東西。因此「模擬」就有必要性。

最簡單的模擬是拿一枝鉛筆一張紙，描述接下來會做的解決方案跟可能結果的流程圖。

舉一個最常遇到的例子：時間不夠，而時間不夠的主要因素已經界定為專案進行過程，常常有需求的改變，但是專案期限卻沒有改變。

假設，可採用方法有以下幾種：

Plan-A：開始軟性或者硬性延長工作時間。

Plan-B：與專案業主坦承需求改變已經造成專案延誤，用Scrum的方式讓專案繼續推進到期限，但在此之間，專案完成的定義也會被改變。

Plan-C：與專案業主談判，取得延期或者需求限制。

Plan-D：...（還有其他很多）

這些解決方式也許彼此是有相關的，例如B與C，其實都需要和專案擁有者（就是出資的人）協商。

模擬Plan-A：

拿出紙筆，寫下所有已知的資訊或事實：

* 目前為止團隊每週的產出
* 目前為止需求的改變數量，和造成的延誤時間，假設延誤10天
* 規劃需要加班時間總數：假設延誤10工作天，目前到期限仍有4週，等於是每週需要額外20小時工作
* 加班之後可能能夠多做的哪些功能
* 加班的總長度，這個例子是連續4週
* 過去加班的耗損率：每週超過10小時的額外工作時間，會讓人請病假的機率
* 長時間加班之後人才的保留率：每週超過10小時的額外工時
* 加班的這段時間，還是會有需求改變。
* ...等等...

將這些已知資訊，不過心裡知道與否，還是盡可能寫在一張紙上，在腦中想像這些資訊「拼湊」起來之後，對於目前專案，有沒有可能使用這個方法解決，而這個方式，其副作用是不是過大。

模擬Plan-C：

拿出紙筆，寫下所有已知的資訊或事實：
* 目前為止團隊每週的產出
* 目前為止需求的改變數量，和造成的延誤時間，假設延誤10天
* 專案業主對專案的瞭解程度
* 專案期限往後延，對於業主的損失
* 專案業主的協調能力
* ...等等...

將這些已知資訊，不過心裡知道與否，還是盡可能寫在一張紙上，在腦中想像這些資訊「拼湊」起來之後，模擬與業主溝通時的可能對話，以及可能產生的結果。

選擇：

將模擬的過程，用心智圖(Mindmap)或其他圖形化方式，寫在同一張紙上。這麼做是為了盡可能排除個人主觀意見，將自己的思緒，用鳥瞰的方式呈現給自己。

模擬數個方案之後，最重要的是選擇一個自己認為相對最佳的方案。

(3) 第三：執行解決方案

如果前兩個步驟，已經竭盡所能。那麼，第三個步驟就變得很簡單：根據第二的步驟模擬之後的決定，執行解決方案。

然而，既然是困境，就不應該預期解決方案一切順利。如何克服困難去執行，就看專案經理的智慧與能力。

執行解決方式同樣有很多需要注意的地方。不過內容絕大部份取決於每個不同專案的特定現況，因此不會有放諸四海通用的銀色子彈。

但是，由於專案困境常有相似性，因此尋求有經驗的朋友或顧問的建議，倒是一個永遠不會吃虧的選項。

---

沈思：為什麼有價值的專案總是會遇到困難？
參考->解決軟體專案困境的最爛方式