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