軟體工程與專案管理的不歸路
前一陣子有機會整理一下自己對於軟體工程的認知與了解，讓非程式設計師對於軟體工程有更多的了解，這邊將相關資訊更詳細地整理分享給更多的人了解，首先，何謂軟體工程？
軟體開發是運用既有的程式語言與相關技術基礎開發出想要的功能呈現，但他的結果不一定是好的，例如最終功能不符合最初期待、開發時程遠超過當初的預期、開發成本暴增造成團隊無法負荷、客戶提出的最原始需求並非客戶真正要的需求等等問題，因此軟體業界提出了各種理論來控制上述的問題，這就是軟體工程，大家可以Google軟體工程就可以找到很多軟體工程理論與方法，但這些方法不斷地被驗證與修改，至於哪一個方法是最好的方式可能跟你的團隊能力、成員多寡、團隊主要開發領域有關，沒有一個最好的方法，以下我提到的方法也不會是最好的方法，但可以給大家參考軟體工程師究竟在想甚麼。
首先，最標準的軟體工程定義了甚麼？他的內含主要是針對軟體專案管理需要做甚麼事情做出建議，例如ISO 9001與CMM-I等方法論，他們定義的內含很多，甚至不只是定義給軟體開發產業，ISO 9001是給所有產業的建議，這其中最重要的一環就是『專案管理』，沒有專案管理，團隊只是一盤散沙，但要當好一個專案經理可不是一朝一夕可及，他要懂得所有專案開發階段的相關細節，並且根據實際狀況調整這些流程的應對策略，那軟體開發階段包括哪些步驟，以下是我整理的簡易說明
上圖示一個軟體開發過程中主要會經歷到的階段，其中還有很多細節，例如CMM-I還定義到可行性評估以及風險管理等等(ISO 9001:2015也把風險管理納進流程)，但主要還是以上幾個步驟，而軟體開發過程中，越前面的流程失控都會導致後續流程的更大失控，所以專案經理就要在這些流程中隨時反覆地將步調拉回主軸，而除了將一切拉回主軸外，專案經理也要意識到這整個專案的成敗是由專案經理一人所繫，沒有任何藉口。
專案管理的失控原因有哪些，下圖是我整理的大致原因
主要的問題就在於大家輕忽了軟體工程的複雜度，很多人會以以下的觀念
這就是軟體開發的困難點，但即使你突破的這些，都還只是解決了軟體工程的一環，另外一環就是軟體工程的另一個主軸，也就是專案管理，好的專案經理最好是經歷過上面所說的階段，因為他可以真正了解問題的真正位置，並且根據自己的經驗協助團隊解決問題，如果專案經理沒有經歷過前面提到的過程，就很難與工程師進行有效溝通，何況是要完成工作。
專案經理在整個專案過程所要經歷的第一個問題是甚麼？一般就是需求確認，一個完整的團隊會有所謂的需求分析師(RA, Requirement Analyzer)，但台灣大部分的專案中，專案經理就是需求分析師，最常遇到的就是一開始客戶要的需求無法被正確理解，不然就是客戶根本不知道自己要甚麼，以下舉個例子，假設我們在談的需求是『開發一個註冊介面，可以輸入姓名、Mail、帳號與密碼』，這時候我們可能會很單純地理解，不就是一個登入介面，應該不用花到一天的時間吧，但工程師有時候要花一到兩周才會使客戶滿意，原因在於大家沒有把這個需求好好的解釋與釐清清楚，以下列出這個單一需求需要注意的相關細節
專案經理最後要經歷的問題則是驗收，驗收問題不一定是程式寫錯，有可能是
這些是專案經理需要面對的最可能問題，也是專案管理最重要的階段，這時候該如何處理呢？這一方面似乎軟體工程方法說得比較少，因為軟體工程是預防勝於治療，至於治療方法我想就是經驗吧。
回到軟體開發這個題目，有人提出過質疑，他能了解軟體的結果千奇百怪，可能有很多可能，但不就是找到問題然後解決問題嗎？當時我無法回答，經過一段時間的思考，我想軟體開發的難度在於程式語言並不是常人可以輕易理解的語言，我將程式語言列為下圖中的第四種語言
這樣其實還算比較好懂的寫法，但是不同程式語言有不同的語法，所以寫法可以千變萬化，上面這個程式有好好地對參數與函數做命名，而且有註解，所以看程式的人不會花太多時間理解，但如果同樣的程式寫成下面這個樣子
軟體開發是運用既有的程式語言與相關技術基礎開發出想要的功能呈現，但他的結果不一定是好的，例如最終功能不符合最初期待、開發時程遠超過當初的預期、開發成本暴增造成團隊無法負荷、客戶提出的最原始需求並非客戶真正要的需求等等問題，因此軟體業界提出了各種理論來控制上述的問題，這就是軟體工程，大家可以Google軟體工程就可以找到很多軟體工程理論與方法，但這些方法不斷地被驗證與修改，至於哪一個方法是最好的方式可能跟你的團隊能力、成員多寡、團隊主要開發領域有關，沒有一個最好的方法，以下我提到的方法也不會是最好的方法，但可以給大家參考軟體工程師究竟在想甚麼。
首先，最標準的軟體工程定義了甚麼？他的內含主要是針對軟體專案管理需要做甚麼事情做出建議，例如ISO 9001與CMM-I等方法論，他們定義的內含很多，甚至不只是定義給軟體開發產業，ISO 9001是給所有產業的建議，這其中最重要的一環就是『專案管理』，沒有專案管理，團隊只是一盤散沙，但要當好一個專案經理可不是一朝一夕可及，他要懂得所有專案開發階段的相關細節，並且根據實際狀況調整這些流程的應對策略，那軟體開發階段包括哪些步驟，以下是我整理的簡易說明
上圖示一個軟體開發過程中主要會經歷到的階段，其中還有很多細節，例如CMM-I還定義到可行性評估以及風險管理等等(ISO 9001:2015也把風險管理納進流程)，但主要還是以上幾個步驟，而軟體開發過程中，越前面的流程失控都會導致後續流程的更大失控，所以專案經理就要在這些流程中隨時反覆地將步調拉回主軸，而除了將一切拉回主軸外，專案經理也要意識到這整個專案的成敗是由專案經理一人所繫，沒有任何藉口。
專案管理的失控原因有哪些，下圖是我整理的大致原因
主要的問題就在於大家輕忽了軟體工程的複雜度，很多人會以以下的觀念
- 軟體開發不是很成熟的理論嗎？你的失敗一定是因為你沒有照著做
- 我都給你這麼多資源了，為何還無法如期如質如預算地完成
- 資訊相關科系畢業的人不是都應該懂這些嗎？為何我還要找你進到公司重新學習？
- 軟體開發不是軟體工程師的責任嗎？為何經常需要其他部門員工支援？
- .....
上面提到的算是整個觀念落差的冰山一角，要將軟體工程做法有幾個主要關鍵
- 專案經理自我學能的充實要不斷精進，並且對於專案有百分之百的負責態度
- 軟體開發不是軟體開發部門的事情，是整個公司要緊密配合的工作，包括採購管理、銷售管理、售後服務、組織訓練、決策分析等等多個面向，從企業管理者到各個部門都要緊密配合才能成功完成整個任務
- 學校會教軟體工程，但不會教你怎麼實踐，實踐一定是畢業之後到企業之後才會開始學的
這是幾個我自己認為比較重要的點，如果要談CMM-I，這篇文章可能會超過10萬字，容我以後有時間再分享，不過CMM-I的實踐在台灣環境確實很難，幾年前台灣還有幾個公司到達ML5，最近一查通通降到ML3，原本ML3的都消失了，主要原因在於實踐CMM-I必須全公司配合完成許多文件的留存與追蹤，這需要很高的成本，大部分的公司都無法在台灣這種軟體無價的環境中執行CMM-I理論，頂多是抽取其中的內涵，適度使用。
這邊說到的無價是指沒有價值，或者說沒有該有的價值，舉個例子，如果你要設計一個形象網站，價格大概是多少，目前市面行情價大約是五萬以內，但很多人對於形象網站的認知有所誤差，所以他會發現自己的形象網站怎麼報價快接近百萬，其實五萬以內的形象網站大都是由一個已經開發好的公版套用出來的，不會有任何你想要的客製化功能。而回到現實面，一般公司可以負擔多少費用建立形象網站呢？就我所知，大家的認知大都是一、兩千塊，其實這連網頁空間都租不起，這就是大部分人對於軟體價值的認知，有時間再寫個專文說明。
接下來要談談這篇文章的主題，就是軟體工程這條不歸路的困難點在哪？最近在網路上看到有人介紹一篇文章，叫做『Why Learning to Code is So Damn Hard』，你可以點連結前往原文，這篇文章直翻就是『為何學習程式開發會如此該死的難』，我想這應該道出不少程式設計師的心聲，這篇文章的主要內容就是下面這張圖
這張圖的總軸是Confidence，就是對於程式開發的信心，橫軸是Competence，可以翻譯成能力或者勝任程度，上面的字是我對於這張圖的一些補充解說，軟體開發的學習包括四個階段：
- 第一階段是指你可以透過Google等等方式找到你要的資訊，所以你以為自己很適合做程式開發，因此信心增加，但你的能力進展有限
- 第二階段你就會發現，怎麼程式問題一堆，不斷在debug(除錯)，這時候，你的信心降低了，但是能力還是有在提升，但很多人就在這個階段離開了軟體開發，而這個階段的最後會發現『You don't know what you don't know』，意思就是你知道你很多東西不懂，但是你根本不知道你不懂的東西是甚麼
- 第三階段應該是所有熬過第二階段的人停留的重要階段，這時候你的信心可能持續降低，但你願意去學前棉提到的所有未知知識，即使這些知識你可能完全無法由網路或者周遭資源獲得，也就是破除資訊焦慮症的過程，資訊焦慮症是很久以前就被提出的一個概念，他代表你很想學東西，但是發現永遠學不完，不過只要熬過這一段過程就可以進入第四階段
- 第四階段就是在信心與成熟度方面都持續增進，這需要不斷地累積經驗，讓自己漸入佳境，最需要的就是把這個工作當作興趣並且保持無悔的決心，你只要願意持續突破就可以漸漸走向高峰
補充說明：除錯為何叫做Debug，原因是因為過去的電腦主機都是很大一台，有一次工程師發現怎麼程式無法照著預期的方式執行，找了很就發現，機器裡有一隻飛蛾造成線路問題，所以從此之後，找程式問題就叫做DeBug-除蟲。(細節可以參考Wiki-https://en.wikipedia.org/wiki/Debugging)
這就是軟體開發的困難點，但即使你突破的這些，都還只是解決了軟體工程的一環，另外一環就是軟體工程的另一個主軸，也就是專案管理，好的專案經理最好是經歷過上面所說的階段，因為他可以真正了解問題的真正位置，並且根據自己的經驗協助團隊解決問題，如果專案經理沒有經歷過前面提到的過程，就很難與工程師進行有效溝通，何況是要完成工作。
專案經理在整個專案過程所要經歷的第一個問題是甚麼？一般就是需求確認，一個完整的團隊會有所謂的需求分析師(RA, Requirement Analyzer)，但台灣大部分的專案中，專案經理就是需求分析師，最常遇到的就是一開始客戶要的需求無法被正確理解，不然就是客戶根本不知道自己要甚麼，以下舉個例子，假設我們在談的需求是『開發一個註冊介面，可以輸入姓名、Mail、帳號與密碼』，這時候我們可能會很單純地理解，不就是一個登入介面，應該不用花到一天的時間吧，但工程師有時候要花一到兩周才會使客戶滿意，原因在於大家沒有把這個需求好好的解釋與釐清清楚，以下列出這個單一需求需要注意的相關細節
- 確定不需要其他欄位？註冊應該要有很多資訊吧！
- 哪些欄位是必填？
- 欄位是否要驗證正確性？要用哪種驗證方式？
- 密碼要用甚麼樣的複雜度？大小寫混合？有字母有數字？一定要同時有大寫和小寫？
- 登入介面要用哪種風格？要用哪一種主色？上下左右各要留多少空白？註冊按鈕要用甚麼顏色？要用甚麼字體？字體大小是多少？
- 註冊成功與失敗個要顯示哪些訊息？
- 帳號可以用中文嗎？
- 註冊要如何驗證？管理者驗證？電子郵件驗證？簡訊驗證？如果要簡訊驗證，那是不是還要電話？
- 註冊要單頁式還是多頁式？
- 是否要用Google驗證碼？
- 是否要做RWD？
- 要支援哪幾種瀏覽器？支援哪幾種作業系統版本？
- 要用甚麼程式語言？要用哪一種框架？
- 每個人天成本是多少？預計的交付時間是哪一天？客戶需要多少時間測試？客戶是否需要需求確認書？客戶是否需要使用手冊？畫面是否需要輔助說明？是否需要路影片作教學？
- 更多還沒想到的細節……
- 設計雛型給客戶確認
- 撰寫完整的需求確認書並配合合約約定好驗收條件
- 既然客戶提不出需求，那就請客戶讓我們全權負責，但要能說明有達成一開始要求的幾個基本要求
- 過程中不斷與客戶開會討論，縮短雙方差距 (這是最重要的一個工作，可惜很多專案經理都無法做到)
不過你要用哪一個在哪個客戶上就需要經驗了，如果客戶對於需求有很多想法，他怎麼可能讓你全權負責。
接下來就是另一個階段，開發與問題處理的無窮迴圈，這是最容易遠離如期如值如預算目標的關鍵階段，程式不可能沒有問題，即使交付驗收後還是會有些許問題發生，但如何將問題控制在最低，這就是要專案經理不斷地追蹤各個層面問題並且將問題及時解決，如果專案經理就是時間到了等著成果呈現，那成果永遠不會呈現，程式不會突然間寫好出現在你面前的，這期間有多工作要做，並不是指有時程管理而已，專案經理要做團隊管理、風險管理、問題管理、資源管理、時程管理等等工作，如果只是在做資訊溝通與傳遞，有時候我們會戲稱PM為Pass Message，這樣也是可以做專案管理，但那是複雜專案並且有多個PM的狀況。
這邊順便聊聊PM，PM至少有三個意思，但大部分是指專案經理，而專案經理經常會被期望三個角色都能做到
- Project Manager：專案經理要負責整個專案的成敗與時程的管控等等細節，是整個專案成敗的主要關鍵
- Program Manager：程式經理是指程式開發團隊的主管，他的主要工作是接收專案經理的需求，並且分配給工程師開發，但很多時候，不一定有這個人
- Product Manager：產品經理必須要開發過程中思考這個專案的成果是否可以作為未來產品的雛型，並且在未來產品的發展中，充分利用此次專案的成果
專案經理最後要經歷的問題則是驗收，驗收問題不一定是程式寫錯，有可能是
- 客戶最後發現這不是他要的
- 客戶還沒有錢付款或者公司要求延後付款
- 問題很多，完全無法使用
- 客戶當初參與的團隊通通換了一批人
- 客戶遲遲無法提供相關資訊，導致某個功能無法完成
- 更多其他可能...
這些是專案經理需要面對的最可能問題，也是專案管理最重要的階段，這時候該如何處理呢？這一方面似乎軟體工程方法說得比較少，因為軟體工程是預防勝於治療，至於治療方法我想就是經驗吧。
回到軟體開發這個題目，有人提出過質疑，他能了解軟體的結果千奇百怪，可能有很多可能，但不就是找到問題然後解決問題嗎？當時我無法回答，經過一段時間的思考，我想軟體開發的難度在於程式語言並不是常人可以輕易理解的語言，我將程式語言列為下圖中的第四種語言
- 第一種語言就是圖像語言，例如一間房子，他可能有各種不同的蓋法，但你只要一看到就知道他是『房子』
- 第二種是自然語言，也就是我們平常在說的語言，房子的結構可以用語言簡單描述，例如兩層樓、四個窗戶、一個樓梯、一個門就可以把房子的內涵說清楚了。
- 第三種是文言文或者現在流行的火星文，你很難透過文字知道他的意思，先不講火星文，如果是以文言文來說『甕牖』這兩個字，你懂他的意思嗎？
- 至於程式語言就是第四種，我把他稱之為冥王星文，冥王星比火星還遠很多倍，以下大概說明他的難度
如果你要形容一間房子，然後描述如何開門關門，程式可能像下面這樣
class
home{
//宣告窗戶
protected win window;
//宣告門
public bool door=false;
//宣告樓層
public int level=2;
//打開門的方法
public opendoor(){
door=true;
}
//關門的方法
public closedoor(){
door=false;
}
}
這樣其實還算比較好懂的寫法，但是不同程式語言有不同的語法，所以寫法可以千變萬化，上面這個程式有好好地對參數與函數做命名，而且有註解，所以看程式的人不會花太多時間理解，但如果同樣的程式寫成下面這個樣子
class
what{
//我不寫註解
protected w a;
public int b=0;
//我是錯誤的註解
public ob(){
b=7;
}
public nb(){
b=9;
}
}
這就很難了解他是甚麼了，他有幾個問題
- 沒寫註解或者註解寫錯
- 參數隨便取，很難猜出他的意思
- 程式根本寫錯了
所以，下次你覺得工程師的工作很輕鬆，可以回來看看這一段描述。
最後我用幾張圖整理一下軟體工程以及程式設計師遇到的問題，未來有機會再根據各個主題做更多的說明
以上花了點時間說明軟體開發遇到的困難點，但這也表示這是一條很有挑戰的路途，歡迎有興趣的後繼者共襄盛舉，唯有高度的決心才有機會達到高峰完成挑戰，如果大家有甚麼相關領域有興趣也可以留言在下面，未來可能會針對大家有興趣的題目做專文說明。
留言
張貼留言