人工智慧的淺顯應用 - 製作Facebook或Line聊天機器人

自2022年有chatgpt之後，原本的fb聊天機器人已經停止使用。新的聊天機器人使用chatgpt, 想要試用的，可以email聯絡：consultant.3rd@gmail.com

聊天機器人(chatbot)並不是什麼新鮮事，早在1950年間圖靈(註一)在提出關於人工智慧判別方式時，就提到利用文字訊息 - 因要把人和機器分開 - 來和兩個對象聊天，其中一個對象是人，另一個對象是電腦，如果一個正常人在聊天的過程無法區分這兩者誰是電腦，誰是人，則可判別這電腦程式，是真正擁有智慧。

要達到這個目的難上加難，在wiki上可以看到目前僅有在2014年一個名為Eugene Goostman的聊天程式通過這個測試。

目前可取得的人工智慧演算法或相關技術都沒有太驚人的發展。然而，由於網路上的資料取得越來越容易，電腦執行速度越來越快，以致於不需要有驚人的技術能力，也不需要有對人工智慧會不會變成奴役人類的電影劇情的深思，就可以開發出有意義的應用。


Facebook聊天機器人也是其中之一。

商家，企業，甚至某些個人都擁有FB page (粉絲頁 專頁)，而從2015年開始，facebook開始出現具有固定反應或者訊息回應的聊天程式。不過台灣似乎比較少見非特定用途的聊天機器人，因此我們就做了一個在粉絲頁上。參考下圖：

https://www.facebook.com/sandy4ai/ 具有人工智慧聊天的粉絲頁

這個聊天機器人會回應你的訊息，根據她內建的知識庫和基本的語意分析，會回應你訊息。當然，她也會慢慢學習對話，這個聊天程式並不會需要額外的facebook權限，因此她沒有太多額外的功能。下圖是聊天實況範例：

和具有人工智慧聊天的粉絲頁聊天

Line在今年(2016)也開放bot api，作法和Facebook幾乎很雷同。不過雖然都是webhook，他們的api實際傳遞內容當然完全不一樣。

Facebook/Line 聊天機器人的可能應用：

1. 基本客戶問題：

企業組織在網路上最常「被」查。查詢營業時間，查詢電話，查詢服務項目等等。在台灣，這幾年用facebook來做生意來越頻繁，而聊天機器可以提供24x7的基本回答問題服務。

2. 促銷活動：

聊天機器人在某些權限下，可以主動傳遞訊息，或者貼文給facebook使用者。這和一般廣告貼文有些許不同，因為貼文之後，使用者可以持續和貼文者 - 也就是聊天機器人互動。

3. 例行客戶服務：

預約預定，提醒預約，服務調查，生日賀卡貼文等等。

如何製作Facebook臉書聊天機器人：

1.摘要步驟

  (1) 到AWS開設帳號。 開發過程會用到Lambda, API Gateway, elasticsearch, s3 cloudwatch 等服務。

  (2) 到facebook建立facebook app。（簡稱 fb app)

  (3) 新增並撰寫基本的Lambda 以回應 之後fb app webhook時的GET驗證。

  (4) 新增撰寫基本的Lambda 以用在 接下fb app message hook回應

  (5) 新增 API Gateway 的GET/POST，對應到Lambda

  (6) 設定fb app 的webhook 對應到API Gateway的URL
  
  (7) 讓fb app的設定頁verify(基本上就是http  GET) API  Gateway

  (8) 讓fb app設定頁訂閱message 並記得在lambda程式回覆訊息時使用page token

  (9) 此時可以進行知識庫的連結，在AWS建立elasticsearch並且匯入經過程式處理的資料，這裡我們以台灣e院資料為範例。

   (10) 修改lambda程式，讓使用者的訊息，在elasticsearch查訊相關訊息，並且回復給原送訊息者

   (11) 至此完成，其結果大致如下圖：

2. 詳細步驟：

    ....<待續>...

如何製作Line聊天機器人：

1.摘要步驟

  (1) 到AWS開設帳號。 開發過程會用到Lambda, API Gateway, elasticsearch, s3 cloudwatch 等服務。

  (2) 到line developer建立帳號以及channel。

  (3) 新增並撰寫基本的Lambda 和 api gateway 用以回應之後在line的channel上link時的驗證。Line的api基本上只用到POST

  (4) 將自己的line帳號 加入剛剛自己增加的channel。就是設好友的意思，這樣才能測試

  (5) 將line channel所需要的api key, secret以及token設定在lambda 要傳回給line bot api的地方。

  (6) 此時可以進行知識庫的連結，在AWS建立elasticsearch並且匯入經過程式處理的資料，這裡我們以台灣e院資料為範例。

   (7) 修改lambda程式，讓使用者的訊息，在elasticsearch查訊相關訊息，並且回復給原送訊息者

   (8) 至此完成，其結果大致如下圖：

2. 詳細步驟：


    ....<待續>...

---

參考: https://www.facebook.com/sandy4ai/ 

 註一：Turing 就是電影模仿遊戲的主角
 註二：詳細步驟還沒有時間寫...反正不見得有人需要:)

數據分析從零開始 - (1)事前準備

當你打算從零開始，變成一個有足夠能力的資料工程師，一開始會需要準備基本工具。而隨著時間過去，自然而然你會瞭解並且學習到更多工具。

在此提供簡單的確認清單(Check List)，讓在打算開始學習並應用數據分析時的準備參考。

1. 電腦

既然是資料分析，電腦自然是必備工具。

最推薦的是Mac的notebook，如果沒有太大的經濟壓力，最好買記憶體越大的越好。13吋MacBookPro，RAM 16G價格大概四萬八。其他可以考慮dell的linux desktop。


選用Mac或者OS為Linux的電腦有許多原因，內建的終端機(terminal)可在bash等環境快速執行各類型資料處理的前期工作。現在windows也有powershell，並且至今技術工程師在對比unix/linux的shell時，常常會有各種爭論。

不過，就打算從零開始的數據工程師，別想太多，就選unix/linux吧！

2. 作業系統

無論你的電腦是桌上型還是筆記型，無論他原本是什麼作業系統。你都需要一個Linux作業系統。在MacOS上可以安裝VirutalBox或者VMware來執行Linux虛擬機器(VM)

3. 基本知識技能與其標準

雖然說是基本，但真要搞定以下知識與技能需要很長的一段時間，就從零開始的情況而言，「盡你所能」的了解以及練習是不二法門。

(1) Linux基本操作：在終端機(或者Shell)中，完全了解以下幾圖中的指令的意義：
（圖一）

   (圖二)

   (圖三)

(2) 網路工具自我學習與操作：能有耐心的看完這篇AWS CLI，並且能用AWS CLI上傳檔案到S3。在整個過程，僅使用官方文件，不在google上搜尋非官方說法。

AWS有提供許多免費工具，用在資料分析上非常適合。但是如果你有PB等級的資料，在AWS上做大數據分析是非常花錢的。

(3) 程式設計基本能力：利用python或任何程式語言，將台北市的住宅竊盜公開資料處理分析加總之後，列出各區的竊盜案件次數表。這裡要注意編碼(encoding)的問題。
如下圖：

(4) 英文閱讀能力：

其實英文閱讀能力對數據分析，甚至其他技術學習是非常重要的基礎。如果不習慣閱讀英文，而老是只查中文網頁，那麼就等於少了60%的網路知識存取。

如果對自己的英文閱讀能力有疑慮，可以先試著不查字典看完這本書：How To Read A Book，這本書用詞遣字相當簡單，而書的本身就是「增加閱讀能力」的方式。因為是本很老的書，應該很便宜，或許早已經沒有版權？

企業巫醫 - MBA無用矣

企業巫醫The Witch Doctors（中譯本為商周出版）是一本距今十一年的老書，但書中對於盛行於商業界的企業管理顧問的見解卻始終精闢。這本書的標題雖然聳動，但內容卻是不只是流於隨想批判，而是踏實的先提出數據，做橫跨時間與空間的研究，最後提出見解。破解在招搖撞騙的「大師」形象。

作者對「大師」的批評相當有建設性，幾乎在1990~2000年間的企管大師，都被他非常精闢而有建設性的評語跟分析過他們所提出的方法論：彼得杜拉克，麥可波特，愛德華戴明等等。而史蒂芬柯维，吉姆柯林斯則是被他列在不入流的範圍。


組織與企業經營的是合併藝術與專業的範圍，在因果模型中屬於複雜的範圍（參考這裡）。換言之，企業的大大小小的決策，與是否能達到效果，很難在事前看出，只能事後瞭解其因果關係。而有趣的，具有戲劇性的論點，逐漸就取代了嚴謹的研究。這讓迷惑於複雜邏輯的人，有了某種追尋的方向，從這個角度來看，「真正」的企管大師也知道這種現象，但他們一方面提出淺顯易懂的見解，另一方面也持續進行研究，這也讓大師的研究結果可供大家參考與學習。

「企業巫醫」則利用根本沒有人可能了解其因果關係，讓自己以有趣的方式解釋因果關係，從而謀利 - 開設顧問公司，提供考取證照方式，提供分析報告，寫書，演講等等。

萬一，自己解釋的因果關係沒發生，當然會拿另一套關係來彌補。就像在原始叢林部落裡的醫生一樣，當有疾病-例如嚴重流感時，會先說明和惡靈的關係，接下來可能拿某些植物的葉片猛力槌打你，打的你又痛又麻的時候叫你回家躺幾天。如果好了，證實的確是惡靈的問題，如果因此病情加重，併發肺炎，表示這樣的懲罰惡靈仍然不滿意，則會換一套方式，直到你痊癒或者死亡 - 當然死亡就表示惡靈趕不走(此段說明彷自企業巫醫一書)

在企管書籍，個人認為最最最有名的巫醫例子應當屬於「從A到A+」。用google搜尋「從A到A+」可以找到非常多人閱讀記錄，甚且有精闢的閱讀心得。該本書所說「嚴謹的長期觀察和研究取得」，分析好公司和「卓越」公司的差別，並且這些從數百家篩選出來的好公司中再篩選的卓越公司，肯定可以「永續經營」？

但是實際上根本不然。

2005年的研究就顯示A+公司，在1996-2005年間，就已經不太算是A+。不到幾年後：11家卓越公司倒了2家，9家之中僅有1家沒受到太大的金融海嘯影響。其中8家在2008危機期間甚至績效平均比其他SP500的公司還差。

從結果來看，從A到A+的理論根本沒用，但是，如同企業巫醫，作者後來竟然還寫了一本「為何A+巨人會倒下」用以自圓其說。非常典型的巫醫行為。

相對於企業巫醫，MBA的價值是否真正有用也很難說。某些研究都顯示，擁有MBA學位的CEO和沒有MBA的CEO在公司經營的成效上，沒有差異（參見這裡）。

然而，某調查顯示，擁有MBA學歷似乎對薪資有幫助(參見這裡），就這個角度來看，擁有MBA似乎還是有用的。但如果仔細看過這類調查，很明顯排除了MBA低薪，以及MBA本身的成本。

反倒已經有百年歷史的最最著名MBA產地的期刊 - 哈佛管理評論的一篇高學歷管理者的迷思。誠懇的點出問題：管理學位取得者，在學習過程中沒有學到真正學到務實的作法，而只是為了取得學位。開始工作之後，如果又沒透過工作經驗，學到新的技能，當然就沒用。

如果沒能對複雜的問題，保持清澄的理智，分析可能的問題，簡化並反覆查證因果關係，踏實的從不同的角度看問題，MBA的學歷可能會創造出一個一個的企業小巫醫，在組織裡三不五時的拿一些最新的企管叢書，當做驅趕惡靈的樹枝，到處鞭打真正在做事情的人。


企業巫醫相關文章：

如何拒絕或調整客戶不合理的需求 

實習生的三贏

時間乃最終之敵人? (上) 

時間乃最終之敵人? (下）

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台幣之間。

犯錯怎麼辦 - 光是道歉是沒辦法解決滔天大錯的

人非聖賢，每個人，在任何時間地點，都可能犯錯。而一個人的職業生涯長達數十年，多少都會做出各種的蠢事。

錯誤也有各種不同的情況，細微小錯自然可以迅速改正，但如果犯下滔天大錯，不見得是道歉能夠解決。

最好的情況當然是「永遠不犯大錯」，透過個人本職學能，讓工作不會出現大錯。

但天有不測風雲，有時候錯誤的來源並非是能力不足，只是純屬於結構性意外，更可能屬於前人留下來的問題和漏洞，但無論如何，錯就是錯，大錯就是大錯。

鑄下大錯最好的做法的三步驟是：「面對」「處理」「學習」。但最後最重要的是，發揮創意把劣勢轉為優勢。

(1). 面對 - 承認錯誤，負起責任

如果是自己做的蠢事，道歉當然是必要的。如果不全然是自己做出來的，有時候也需要道歉，例如：企業產品發生問題，而你剛好是產品的負責人，雖然並不是你直接造成問題，但由於你是當時的負責人，自然要負起道歉的責任。

承認錯誤道歉僅只是第一步。負起責任不是簡單的口頭道歉，或者是土下座而已。所謂負起責任是要能「做出」行為。

既然是滔天大錯，道歉之後，隨即就是「妥善應對計畫」。這個計畫，一定要讓受影響的人清楚明白的了解。做計畫要快速，不見得完美，但是要全面，可以使用心智圖來協助達到全面性。

妥善應對計畫就和所有的計劃一樣，計畫的過程(planning)可能比計畫的本身來得重要。計畫的過程會大幅降低「連環出錯」的可能性，計畫的過程會讓「處理方式」變得有效，計畫的過程更可以讓受害的一方的影響降低。

舉例來說，如果某購物網站，因網站管理員操作不當，不小心刪掉資料庫中所有訂單，如果你是該網站管理員，首要之務當然是通知相關人等，道歉再道歉自己發生的錯誤。接下來，擬定「妥善應對計畫」：(1) 評估受影響的客戶數量，試圖從log或其他任何蛛絲馬跡中推估有多少訂單被刪 (2) 評估受到影響的金額，以及已經結帳後如果想退款的快速方式 (3) 首頁建立道歉網址 (4) 建立快速反應小組，提供電話與email讓受影響的客戶聯繫 (5) 相關社群網站或產品網站如果也受到影響需要找負責人協助  (6) 每日固定時間固定地點呈報修復進度 (7) ....這些應對計畫的細項可能有更多，但重點在於，有計劃自然能穩定人心，讓事實可以持續前進，而不會有錯誤的骨牌效應。

(2). 處理 - 誠實處理，控制損害

有計劃之後，接下來就是按計劃處理。處理原則如下：

(1) 誠實

不掩飾，但也不誇飾問題的嚴重性。誠實的處理可以挽回補償的事情，承認並道歉不能挽回的事情。在能力範圍中承諾最大的努力，但也不答應自己根本辦不到的事情。誠實的說明自己的能力不足，但也不能推託自己應該盡的努力。 

(2) 損害控制

既然是滔天大錯，大概一定會有很大的損害。按照計畫，盡可能將造成的錯誤損害降到最低。

(3) 小心骨牌效應

無論是壓力過大，或者環境本身的變化，錯誤常常是一連串發生的。處理錯誤最怕的是一錯再錯。例如，發生重大意外，投入直昇機救援，而直升機又發生重大意外的機率其實明顯的高於一般直升機普通飛行（參閱論文）。

(4) 不馬上釐清責任

此階段的重點在於執行計畫，控制損害到最低。而不是追究問什麼發生，是誰的錯！

(5) 記錄，檢討，修正計畫

即便計畫的執行很短暫，並且很急迫，也不要忘記簡單的紀錄，隨時檢討補救計畫的本身。並隨時修正計畫的執行。畢竟planning本身才是重點，而非plan。

(3). 學習 - 建立不貳過的絕對能力

當處理問題到一定的程度。無法在減低損害，但也不會讓損害繼續發生時。就是檢討學習的階段。

在這個階段，能補救都已經補救，無法挽回也都無法挽回。因此，是要檢討並且未來不會再發生的最佳時刻。檢討的方式有很多種，比較正式的做法為「post-mortem會議」。

會議進行方式採三階段，(1) 事實說明 (2) 事情經過的改善 (3) 避免再發生的作為

(1) 事實說明：

由犯錯的人或者代表人，從事件的開始說明到今天為止發生的事實。僅只是說明事實，並且釐清事實而已。

例如，購物網站不小心刪除訂單，過程可能是因為要釐清報表問題，以commandline方式進入資料庫，由於新增加一筆測試訂單資料，想要刪除資料時，執行delete的動作過程中，竟然忘記加上where condition。

事實說明過程可以提問，但目的是把事實釐清得更清楚。因此不需要問說：「為什麼當初你不這麼做」，也不應該說「你那時候腦袋在想什麼怎麼這麼蠢」之類和事實無關的話。

 (2) 事情經過的改善：

指的是「妥善因應計畫」執行過程中，有哪些可以改善的地方。基本上就是前段所述「處理」過程中的的檢討。如果有紀錄，則應該可以很快找到哪些地方還可以改善。

 (3) 避免再發生的作為：

這個階段就是重要的釐清責任階段。這個錯誤單純是人為錯誤？還是系統性錯誤？環境天災？釐清的過程要伴隨著「為了避免再發生而做的事」

單純人為錯誤：把某個人解僱就之後就不會發生？或需要靠某個檢驗機制？或讓檢查的本身加入SOP？或者過於粗心的人不適合做這個工作？怎麼樣定義何謂粗心的人？

系統性錯誤：這類型的大錯是不是歸咎於之前某人的設計不良？系統設計如何改善？系統性錯誤出現比率高不高？如果不能避免有什麼簡單方式可以大幅降低損害？是不是該雇用高手中的高手做好系統？

環境天災：特殊大地震或者異常天候？很低的機率才會發生？是不是要特別有處理方式？還是因為機率太低，可以視情況見招拆招？還是機率比想像中的高？

可以將所有「行動」逐一列出來討論。

最後，一定要「行動」。沒有行動的檢討，就不具備任何意義。而既然是滔天大錯，就必然一定要行動，才能做到不貳過。

---

I never lose, I either win or Learn: Nelson Mandela

最後，比較罕見的另一個重點：個人的創意與技能，要能將錯誤的劣勢轉為優勢。畢竟既然滔天大錯已經發生，能補救檢討都已經完成之後，有創意的將劣勢轉為優勢，是犯錯的個人最應該想的事情。

例如：一個遊戲app的廠商，推出新版本時，在伺服器端發現可承受的連線數量遠低於預估，導致於許多新玩家無法玩新版本遊戲，而舊版本又已經自動更新成新版本。當然許多新玩家會不滿，但如果遊戲廠商在處理過程中，額外彌補玩家的損失(送出高等級寶物之類)，其彌補的方式有額外的創意，這類型錯誤甚至可以額外吸引新玩家加入，這就是一種以創意和技能，將錯誤的劣勢轉為優勢的可能。

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

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

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

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

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

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

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

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

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

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

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


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

1.  即時會議記錄：

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

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

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

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

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

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

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

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

2.  分析與設計：

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

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

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

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

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

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

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

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

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

app使用者登入討論大綱

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


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

---

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

為自己工作 - 契合組織目標

雖然這幾年，創業蔚為風潮，但在台灣，大部份的人還是受雇於組織或企業。

「為自己工作」這句話看似自私，但其實所導引的結果才是對企業組織以及對個人有利。至少，對白領階級的知識工作者是如此。(註1)

表面上，大部份的人似乎並不是為自己工作。實際上，會去工作的原因是可獲得報酬（報酬涵蓋：薪資，技能知識學習，個人成長，成就感，社會參與感...等等），因此，無論表面原因為何，也無論自己是否有認知到這個事實，即便是受僱用者，絕大部份的人是為了自己，或者自己的家庭，而工作。

然而，在職場上常聽到各種抱怨心聲。其中有很大部分，其來源是沒有認知到自己是「為自己而工作」：

例如：

  *  工作很無聊學不到東西
  *  自己的價值不受到老闆重視
  *  對公司貢獻超級高，但是相對報酬卻很少
  *  做事人少，出嘴巴的人多 (特別是在政府單位)
  *  組織方向不正確，快要完蛋了

抱怨不是大問題，但失去自我方向之後，就很難在職涯上突破。個人的工作目的，必須要「由自己想辦法契合組織目標」。否則，就會有「不是為自己而工作」的念頭。一旦有這種念頭，很快的就喪失信念以及工作熱誠。

誠如前述：「為自己工作」這句話看似自私，但其實所產生的結果才是對企業組織以及對個人有利。

如果真切的認知到事實是「即使是受雇用，但自己其實是為自己工作」則進一步更能在工作上展現能力，切合組織目標。也更能給予組織更多的價值。因此，認知事實，才是生涯展開的最重要的事情。前述的理由就根本不會存在。

例如

  *  工作很無聊學不到東西：請隨意google一下就知道，企業組織雇用員工，不是為了讓員工學東西。而是解決問題或者產生新的價值。而工作學不學得到東西，也請google一下，都是取決於自己而非工作的本身。

  *  自己的價值不受到老闆重視：員工的價值就像在擺在口袋裡的針，只要你夠尖，有一天一定會穿刺而出。如果你覺得不是被擺到口袋，那就找到一個會擺你到口袋裡的組織。光是抱怨是沒有意義的。

  *  對公司貢獻超級高，但是相對報酬卻很少：先確定是自己的貢獻真的超級高。以業務員為例，許多大企業的業務，其業績是靠著大企業的品牌和產品，而非個人能力。以程式設計師為例，其程式產出，絕大部分是靠團隊能力，而非個人能力。

  *  做事人少，出嘴巴的人多 (特別是在政府單位)：也許你的生涯規劃就是要去這類型地方？如果是這樣，也沒什麼好抱怨。如果不是，就趕快離開，也沒什麼好抱怨。

  *  組織方向不正確，快要完蛋了：在一個快沉的船上，就是你發揮能力的時候。如果你自認為是個策略舵手，當然應該矯正組織方向。如果你覺得自己是在大組織裡的小螺絲，那麼你為何能「判斷」組織方向不正確？或許是你的判斷不正確？無論如何，你永遠有離開組織這個選擇。



在大部分時候，人總是可以找到契合組織目標的方式？主要有三種：「自然篩選」「個人規劃契合組織」「創業」

1. 自然篩選

當然，企業組織會自然的篩選「契合組織目標」的人。自然篩選的程度與經濟學上的「看不見的手」有過之而無不及。

例如：一個長期處於保守狀態的組織，自然而然會留下不積極的人。一個以退休津貼優渥的組織（例如公務員），自然而然，就會吸引「為了退休而工作」的人。當然，當一個人拼命念書，絞盡腦汁的通過高普考，一進去公家機關就數饅頭等著退休，自然就不會抱怨「工作無聊學不到東西」以及「自己的價值不受老闆重視」，畢竟，進來這個組織的真正目的，其實是為了退休...。

反過來說：一個新創事業，自然而然會吸引想要透過自己的能力，積極開創一片天地的人。而「退休津貼」就不可能是工作的首要目的。但工作是否有趣，組織方向正不正確，就成為關鍵因素。

雖然，個人沒辦法影響「自然篩選」，但如果你的工作目標，和「自然篩選」的目標不一致，當然會工作的很痛苦，而抱怨連連。

解決自然篩選的方式有三種：(1)離開 (2) 改變自己 (3)改變環境

其中，離開是最簡單的。辭職換新工作，自己創業，創業失敗後再創業等等，都是離開。

改變自己很難。但潛移默化之下，很多人會因為自然篩選的環境而改變自己。

改變環境其實難上加難！但是，一旦有機會做到改變環境，你就擁有一個難以言喻的經歷。這個經歷對職涯有絕對的幫助。

2. 職業生涯規劃契合組織

傳統企業組織都知道，激勵員工很重要。但組織出錢出力，費盡心思的「各種激勵」其實遠遠不如讓員工的生涯規劃契合組織目標。

就前段所述，其實無論如何，自然篩選會讓組織留下契合其目標的員工。但這需要起碼數年的時間，而前提也是組織沒有大的變故。 如果組織 - 特別是營利企業 - 的目標和其展示的行為不一致，自然篩選會失衡，要達到平衡。

因而「以個人力量做出契合組織的規劃」才是最簡單，最容易，最能獲得三贏的選擇。

除了工作內容外，每個人常遇到工作上乍看之下不可伉儷的因素，而認為自己無法契合組織目標。在你還沒有丟出辭呈之前，可以執行的個人能力與選擇非常的多。這些選擇都可以有機會做出契合組織的目標。

例如：

* 每天都做無聊的工作：既然是無聊的工作，表示是重複簡單類型，試著將這類工作最佳化，並自動化(註2)。 不知道怎麼自動化？那就去學阿，在工作中學習成長，並透過自動化的貢獻，不但提昇自己的能力，也讓組織獲取更多價值。

* 工作太多，常常超時加班，生活品質太差：所有企業組織，其存在的目的，絕對不是要員工加班完成目的。其存在的目的都是為了獲利。隨著組織分工，以及各種環境變化，容易產生以「加班」的方式來解決問題。這完全可以避免，請參考：解決專案困難的最爛方式; 如何提高工作效率; 80/20法則。也可以網路搜尋一下任何增加工作效率的方式。

重點在於去做！Just Do It！不去做，永遠不知道加班問題能否解決。

* 加薪升遷不如預期：如果是在大企業工作，加薪升遷的確常常不如自己預料。但如果你確定自己有這樣的價值，一段時間一定會被發現，如果不被發現，在離開之前請先想清楚「自己是否真有這樣的價值」？想清楚的方式也很簡單，可以去試著去應徵其他組織，看看有沒有其他組織願意提供給你更好的薪資福利。如果沒有，表示在當下你的確無此價值。如果是在小企業，薪資福利可能無法有大幅成長，但小公司能提供的通常是更多的自由和自我成長。既然你已經自然被篩選到小企業，或許本來就不是很期待制式的加薪升遷了吧。


* 組織做犯法或遊走在法律邊緣的生意：趕快辭職離開！越快越好。你確定你想要加入犯罪組織或者遊走在法律邊緣？！

3. 創業

創業，當然就是為自己工作，當然也一定會契合組織目標 - 因為你就是組織。倘若你創了業，卻因為各種原因，去做不是你訂立的目標的事情，那等於是沒創業。(註3)

不過創業成功難非常高（參考如何確保創業成功）。富貴險中求，高風險當然比較能伴隨高獲利，如果生涯的志向在此，盡可能參考已經成功的典範，或許能降低失敗機率。

---

註1: 藍領階級的勞動工作者可能不全然適用。

註2: 同註1

註3: 當然，也許你是共同創業，或者持有股份很少，那麼請視為在組織為自己工作，不要視為自己創業。

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

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

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

長期，非自願的(註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法則之軟體專案的三個運用重點

如何充實自己：大量閱讀的三步驟

閱讀是充實自己的最簡單，便宜，有效的方式。

閱讀不需要花錢去買書，以新北市的居民為例，只要就近找一個新北市圖書館的分館登記成為讀者，就可以線上借書。如果在該分館沒有，還可以運送其他分館或者總館的書到你最近的分館領取。方便到幾乎沒有藉口不閱讀。

閱讀是許多人的休閒活動，在躺椅上一邊讀喜歡的書，一邊吹著微風，是悠閒人生的象徵。小說文學，遊記漫畫，在這個情景下是再好不過的書。

但如果為了充實自己，那麼大量閱讀是有很大的幫助。

所謂大量閱讀和傳說中的超強速讀並不一樣

傳說中超強速讀，則是存在某個不太認識的人身上的特殊技能，總是會人試圖花錢去學習這個從來學不會的特異功能。

大量閱讀是在同一個主題下，透過不同作者的觀點來建立自己在這個主題下的知識。大量閱讀是閱讀超過7本以上同類主題的書，並且透過前人的知識，建立對這個主題的全面性概觀。

步驟一：選定主題，取得大量書籍

為了充實自己的大量閱讀，需要有個主題。例如：「創業」。也可以將主題縮小或者放大。例如：「精實創業」就是縮小範圍，而「企業管理」就是放大範圍。

有了主題自然就要去取得書籍。除非很有錢，否則大量書籍會先從圖書館借。現在圖書館幾乎都有線上查詢的網站。在線上查詢網站，查詢該主題。

以「精實創業」為例，在新北市圖書館網站，竟然只查詢到兩本。基本上除非主題過於偏僻，這種情況太不可能，當改為「lean startup」查詢之後，就找到了52本，雖然裡面有幾本不太相關，不過數量也已夠多。稍微瀏覽一下書名和簡介，就直接利用線上借書功能，盡可能借到不能借為止！通常是10本左右。



切記！！先別在網路上搜尋這個主題！！

由於撰寫網路內容的成本非常非常低，確實有可能搜尋到片段知識，但對於充實自己的角度來說，弊大於利。除非已經對這個主題有一定熟悉程度，只是需要找到特定問題的答案，否則在這個階段完全不適合利用網路！

步驟二：閱讀

等拿到那幾本書，就要開始閱讀。

大量閱讀的「閱讀」要從目錄開始。假設相關主題的書共有10本，先將這10本書的目錄，大致瀏覽一遍。根據自己的感覺，先列出哪些「章節條目」是重要的，那些可能是不重要的。對於某些「條目」 如果有很明顯的「正反面意見」就要特別留意，這個條目可能很重要。

目錄瀏覽過，就表示應該產生基本的心智圖筆記(參見步驟三）。現在請排序找到前三本要讀的書，將三本書依序讀過。

接下來，在記憶中，將這三本書的重要關鍵項目，轉折點，列在心智圖筆記中。這時候心智圖可能會一改再改。鉛筆會是最好的選擇。

當心智圖筆記大致完成，檢視自己的知識，看看對哪些條目有更深入的興趣，將剩下的7本書，以「條目」的方式閱讀。剩下的書，不需要每本的從頭看到尾，但是，可以針對有興趣的項目，或者重要的項目，特別橫向閱覽所有關於這個條目的章節。當然在過程中，如果發現這7本書裡面，有寫得非常好的，當然也可以從頭看到尾。

步驟三：心智圖筆記

專案管理的心智圖筆記

雖然說是步驟三，但是其實在閱讀的當下，就應該先做筆記。而心智圖，是最好做筆記的方式。

在閱讀的開頭，可以先把「主題」畫在中央，然後把書本的「章節條目」根據自己的興趣以及自己的分類方式，「記錄」其關聯性。這樣的紀錄，並不一定以章節名稱。以右圖為例，這個圖示紀錄「專案管理」這個主題的心智圖，其中右邊第一項「Practical way」指的「實務做法」，因此從專案計畫，執行，產出，結束，都被分到這一類。

注意！心智圖筆記的關聯與分類，乃是根據讀者(也就是你)的想法和關聯而來，他並沒有所謂對錯，他是讓你的心緒能夠抽離。除非你有鄧不利多的儲思盆，否則，這是目前已知最簡單最快速能讓你的思維視覺化的方式。

---

參考：如何充實自己：三個務實的快速方法

如何提高工作效率：三個務實的快速步驟

Give me six hours to chop down a tree and I will spend the first four sharpening the axe. 

 - Abraham Lincoln

白領工作者，或者，知識工作者的工作，追根究底是利用智慧知識和經驗，做出一些行為。例如：行銷經理，就是擴大產品的市佔率；軟體工程師，就是產出程式碼；業務員，就是賣出產品； 言情小說作家，就是寫書；專業經理人，就是領導管理團隊完成任務。

只要是知識工作者，不管用什麼方式衡量工作效率，理論上都可以持續提高。

就概念上來說，工作效率來自於三大方向，(a)技術與知識，(b)環境，(d)心理層面。

技術與知識。需要靠學習與經驗累積，而正確的學習和正確的經驗累積更為重要。請參考這三篇相關文章：自我學習的方向，片段知識的危害，工作中學不到東西。

環境。如果週遭都是工作效率極高的人，自然而然就會主動提高效率，然而環境有點運氣成分，大部份的人很難控制周遭環境。

心理層面。從馬斯洛需求階層論，到赫茲伯格的雙因素理論，心理與管理學界不乏各種相關的研究以及結論。但知識工作者，可以先參考Ted的這篇。


工作效率，絕對會和「超過」的工作時間呈反比。長期的加班對絕大部份的知識工作者而言只會降低效率，拖延成果，殘害自己與家庭。尤其是對剛進入職場的新鮮人，提升工作效率是最最最最重要的事情。工作效率的提升，會伴隨知識技能的成長，更多的時間運用，以及對組織產生真正的價值。高效率地利用時間，可以產生對職業生涯的正面循環；低效率的長期加班，則會產生很難逆轉的惡性循環。


只要願意嘗試，每個人都可以利用以下三個務實的步驟，持續並快速提升績效。做法很簡單，只需要筆記本和筆：

(1). 15分鐘每日計畫

每天開始工作前，先不要開電腦收email，而是拿出筆記本和筆，把今天最重要的幾件事情寫出來，分類事項，決定今天要先做什麼，要完成什麼，參考這篇的分析。切記先完成重要且緊急，以及重要不緊急的事情。

每日計畫只是簡要列出「打算完成」的項目，並且花一點點時間，沈思哪些真的可以完成，哪些是在80/20法則中最重要的完成項目。 也可以加上一些「保留」時間，用以處理意外。

(2). 15分鐘檢討改進

每天結束工作「後」。拿出筆記本，看看今天開始計畫的事情，哪些完成，哪些沒完成，哪些真的重要，哪些其實後來發現不重要。自己檢討一下自己的判斷為何不正確，為什麼該完成的事情沒完成，並且，簡要記錄一下，完成的項目大概花了多少時間，未完成的事項是因為什麼原因。

(3). 15分鐘重點學習

改進檢討結束後，找一小段時間，再把筆記本拿出來，看一下那些比預期晚完成的事項，哪些是因為自己的知識技能不足，導致太晚完成。列出這些項目。特別是找到「厲害的人一下子就可以做到」的事項。舉例而言，excel的PivotTable是資料分析的最基礎的方式，也是做big-data模型時，小規模測試的最好參考，會妥善利用PivotTable的資料專家，會比不會用的人更節省時間的驗證自己的模型。

在筆記本列出需要學習的項目，每天花15分鐘，在網路上學習這個技術或知識。每天只要專注於「一個能提升效率的事情」就綽綽有餘了。




知識工作者最悲慘的情況，莫過於努力了好幾天去做一件完全不需要做的事情，或者完美的執行一個完全不對的方式。

如果還沒有找到最適合自己的方法，請按照這三個務實的方式，每天花不到45分鐘，在2-3週之後一定會有顯著的效果。

---

這篇文章的乃是根據以下書籍參考，匯整，並且實際執行之後的結果。
- Getting Things Done  
- The Productivity Project 
- The 4 hour work week
- Lean startup
- Do Over

如何學習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%的原因是出現在領導者身上。去除認知偏誤的方式，除了越級訪談之外，高級主管不應該詢問一級主管的「看法」，而是直接詢問可以獲得的事實。例如：目前的問題，一級主管採用哪些「有價值的作法」來解決。

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



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

---

剛畢業準備加入開發團隊 - 三個必要的Scrum突圍方式

真實故事 1:

某個陰暗的冬天早上，悠晃進辦公室的當下，看到二十多個人圍成一個大圓圈。既不可能是營火晚會團康，也不會是祈福默禱活動。好奇的在旁邊觀察一下，在圈圈邊上的某個中年男子開始要求大家在這個stand-up會議報告進度，並祈許新採用的Scrum方法可以讓軟體開發有良好的發展。

真實故事 2:

某一次專案研討會中，演講者詢問與會人士，Scrum估計工時的時候，每個人每個工作天應該是多少小時才合理？新鮮人多半回答6-8小時。某些資管企管碩士生，大概讀了許多書，回答:「4小時」。而一個在軟體外包廠商工作的專案經理回答:「10小時」。

Scrum是最近幾年很流行的Agile(敏捷)開發方法之一。它的概念照理說簡單易懂，很容易在現有的團隊中採用運作，或許是因為趕流行？許多資訊產業開始以採用Scrum方法為榮。而各類型顧問也都開始教授Scrum，也開始頒發各種結業證書甚至Scrum Master的執照。就在短短數年之內，在台灣業界Scrum似乎無所不在，成功案例一個比一個容易找到。

但是就像其他簡單易懂的事情一樣。Scrum說起來比做起來簡單。實際實施的時候需要克服慣性與人性，克服與目標之間的各種障礙。但也因此，把握住Scrum的精神，最能夠讓畢業的學生以正確的方式加入軟體開發團隊 - 即便這個團隊此時並未實施Scrum。

追本朔源後，總是可以看出：太陽底下始終沒有新鮮事。Scrum最早正式出現在1986年的一篇文章中(Scrum最早的文獻)：透過個案的深入觀察，兩位日本學者對於有彈性，有效率的產品開發過程中發現一些相似的點：內建的不穩定性，自我組織的團段，互相重疊的開發流程，多面向學習，精微的控制，組織裡習得經驗的轉移..等等。文獻中的產品大部份都是硬體，例如汽車或者影印機。

乍看之下，和現在的軟體開發方法論似乎沒直接關係，但是，而後在經過其他學者的後續觀察歸納。這種以事實為基礎的彈性結構，遠比傳統官僚結構，更能在短時間達成高效率，甚且更容易產生創造性思考的價值。

理論歸理論，如何實踐理論在工作上才是重點。

近年來畢業的資訊科技背景的學生，的確在學校多少聽過Scrum，許多資管的學生甚至上了不少相關的課程。但就實務的角度，除非教授像這位荷蘭的老師（eduScrum）一樣，真心誠意的採用Scrum在課程的本身上，否則對剛畢業的碩士生或大學生而言，Scrum就只是個似乎看的到，卻無法做得到的事情。學界與業界間的藩籬，仍然巨大看似難以突破。

因此，提供以下有三個務實的方式，可以作為剛畢業的學生突破藩籬的參考。

1.理解事實

對於剛畢業的學生來說，理解事實，是基礎中的基礎，但也確是整個職業生涯需要不斷強化的地方。

以Scrum而言，每一個要做的事情 - 也許稱之為一項backlog - 在正在執行人的手上只有三種狀態：「還沒開始」，「進行中」，「已經完成」。

在每日stand-up，最常發生的是產生另一個狀態「快要完成」，也有可能混淆「已經完成」和「進行中」，更糟的是混淆「還沒開始」與「進行中」。

舉例來說，小馮在每日stand-up會議說：「訂單查詢功能已經差不多了，因為訂單查詢結果的排序雖然弄好了，可是分頁還有點問題，但是快要好了」。也許在學校裡和指導教授報告論文進度這種描述是可接受的。但是在Scrum的精神裡，這種描述不但沒有必要，而且會引發更多問題，因為，接下來大家就需要探究所謂快要好了，是還要多久？最簡單正確的描述應該是「訂單查詢功能正在進行中，原本預計2天完成，已經花了1天，接下來1天會繼續完成，目前估計和預估所需時間一樣是兩天」

重點並不在於咬文嚼字，而是在於對事情的清楚認知。當意識到一件事情沒有完成，在產品開發裡，終究是沒有完成。

每個人多少都有報喜不報憂的心態，也多少都希望別人對自己有好印象。因此，常會有自己也欺騙自己的時候。Scrum的每日Stand-up站立會議，僅說明三件事情：1. 從上次會議到現在完成了什麼 2. 在下次會議之前打算完成什麼 3.有遇到什麼困難。僅只三件事情而已，不多不少。

剛加入任何形式的開發團隊的人，能先確切的掌握和自己相關的事實，是看似簡單卻需要時間實現的基礎。

2.控制時間

既然Scrum是屬於Agile的方法論之一，當然符合最早的Agile 12項基本精神（參見這裡）。其中幾個精神和時間有莫大關係，例如，可用的軟體大重於詳細的文件，回應變化重於遵循計畫。而Scrum是最能達到的方式。

以團隊的角度，burndown chart(燃盡圖)是最能表達團隊目前能力，與專案時間預估的方式。他的做法極端簡單，請自行參考wiki。burndown chart展示了血淋淋的事實，可以透過過去一段時間的完成速度，有效預估專案可能的完成時間。由於這種做法去除了人類心態上的偏誤（例如：大家再努力一下，接下來某東西可能比較簡單...諸如此類），因此在沒有能力，沒有創意，沒有實務開發經驗的產品或專案經理的眼中，burndown chart只是拿來參考用，不能給長官看到。

以剛畢業的學生而言，最難的事情在於預估時間，特別是在比較長期複雜的任務。


解決方式為兩步驟：
  (I) 決定第一件要做的事情並且去做 
  (II) 額外增加研究項目(也額外增加時間)

(I) 決定第一件要做的事情並且去做  

對於很長的項目(backlog)，表示他可能隱含數個子項目，而每個子項目可能也不小。例如，讓系統可以支援facebook帳號登入。這可能就要分成數個項目。當然對於新鮮人，分拆項目可能會遺漏，但是，有分拆比沒分拆好，有估計比沒估計好。有分拆之後，如果有漏列項目，也可以清楚知道有漏列。有估計之後，估計的錯誤以後還可以作為其他項目的參考。
而分拆之後，就直接進行第一件要做的事情！確實的腳踏實地去做！不用等，也不用試著把項目分拆的很精細，估計得很詳盡。因為萬事起頭難，當已經開始進行，就很容易知道之前想法是不是正確，還有沒有遺漏。關於項目的分拆(breakdown)可以參考這篇。

(II) 額外增加研究項目

如果分拆之後，很明顯的仍然難以著手，就額外列出一個有限定時間的研究項目在最前面。換言之，花個固定的4到12小時進行學習與研究，將這件事情也列入整個開發流程中。時間必定要是有限的，畢竟絕大部份的產品開發，無論多困難，都還是在有限時間一定可以找到解決方案。

從另外一個角度而言，如果在有限時間無法找到合理的解決方式，對新鮮人而言或許你也並不適合做這個行業，可預見的未來裡，或許你會勤能補拙，試圖用更長的工作期間達到成效。但是這並沒有太大的意義。因為你並不拙，只是專長不在此，在有限的時間投入內，了解自己的專長不在此，或許更能幫助新鮮人找到最能讓自己發揮專長的地方。

3.確保產出

每個backlog表示一項「產出」。只要前兩個精神：理解事實跟控制時間，已經有效掌握，那麼這一項應該不會有太大意外。然而，對於剛畢業的學生來說，無論程式能力有多強，對於產出的完整性，常常會有誤解。不過這樣的誤解其實也很容易釐清。

一般軟體開發團隊，某人的某功能程式碼寫完之後，會經過以下階段：

1. 程式碼完成
2. Unit Test完成並通過
3. 簽入版本控制系統(commit)
4. 通過code review會議
5. 合併到產品主線
6. 通過自動化編譯建構
7. 通過自動化整合測試
8. 通過QA測試
9. 經過產品經理(Product Manager)確認

在Scrum一開始，便應該定義何謂backlog完成？
- 會是 1.程式碼完成就算完成？
- 還是 6. 通過自動化編譯建構 才算？
- 甚且是要等 9. 經過產品經理確認 才算？

有許多開發團隊，產出的本身是透過「默契」來達成。然而就新鮮人而言，一開始一定比較難取得「默契」。開口詢問，並且在三確定產出的「要件」是剛畢業的學生常忽略的要點。

參考閱讀-> 如何快速充實自己