軟體開發流程，什麼是MVP、POC?系統規格設計時PM要做哪些事?自動化測試才是王道!
步驟一：Define Needs
在開始軟體開發之前，必須做這兩件重要的事情：
1.收斂需求：包括確定系統功能、使用者需求與期望和任何技術限制的初步評估。（Data Input、Output、是否要第三方平台串接、API設計等）。
需求可能從哪裡來？
- C-Level：老闆們在市場經營策略上找到的突破口或新點子都會批哩啪拉的湧現，如果剛好又遇到想像力非常豐富的。
- Sales：業務會有一套自己的pipline流程，當進入到需要技術程面評估範疇與時程時，PM與PDM等角色就會浮現。
- Inside：通常這問題會發生在內不使用系統，又被分為被動回饋與主動優化，被動是指執行者主動回饋系統使用操作，主動優化當然就是指主動去分析每位執行者操作流程，並在系統上實現功能引導使用者操作。
若公司具有一定規模則會獨立部門運行內部系統改善，據我所知，在台的幾家半導體供應商（經銷或進出口代理）內部使用系統是非常複雜的。
因此，會有獨立單位（e.g. 數位轉型部門、企業規劃部門）應運而生，這些部門的PM負責收集各部門（e.g. 研發、生產、客服、廠務部等）使用情境與操作問題，並優化系統，當然這常常是需要實地訪查（e.g. 倉管人員進行物料的標示、理貨、揀貨等作業）。
2. 確定利害關係人：不管是Project Manager或Product Manaegr的角色，皆 必須確保專案或產品能夠順利執行，其中就包含對上的客戶、老闆、主管或對下的團隊成員甚至是會有外包廠商的合作夥伴，因此，在計畫開始前要先釐清誰能夠在專案或產品發生瓶頸時協調解決。
提供幾個例子，例如當專案資金緊縮時，除了要準備對策外，資金資源應該要找誰獲得? 或者是當部門間有人力資源衝突時應該要找哪切有權利權衡的角色協調。
可以使用「User Story」協助釐清需求👆👆
步驟二：Design spc & Prototype
有了較明確的需求後，會由SA或PDM開始設計系統規格、系統架構等，此時會有更詳細的設計規格出來，在固定範疇(需求定義)下，考慮功能範圍、細節、使用流程、主視覺等，甚至在一些比較嚴謹或特殊需求下也需要考慮例如是否要設計web accessibility。
最終再藉由UI/UX繪製Prototype模擬呈現最終樣貌，而Prototype不只是要給客戶看!! 一部分原因是要提供給開發的團隊成員，俗話說「有圖好說話」，工程師也是視覺化動物，除了接收SA開出的規格外，每一位團隊成員都要對最後的產出概念有一致性，以確保往後每個RD都理解最終開發目標。
舉個例子好了，若今天要開發Saas服務平台，而後端資料庫僅知道要開發哪幾隻web API，Request Header, Request Body欄位設計，但對於最終使用者藉著UI畫面呈現毫無概念，這在團隊溝通的過程中往往會帶來許多「代溝」，再加上當團隊沒有成熟的Unit test則會更不利於每次開發者更動代碼的風險。
關於單元測試的自動化設計、注意程序和單元測試影響力下面幾個步驟會稍微提一下，但詳細內容後續章節會在介紹給大家。
步驟三：Software Development
在完成系統的設計之後，開發人員可以開始編寫代碼。在此階段，必須使用最佳實踐和編碼標準來確保代碼的質量和可維護性。
有時候會使用POC(Proof of Concept)進行可行性驗證，主要是確保開發方向正確以及目標概念的實作可行性(使用較小可達成目標力氣完成模型的概念)，有些人可能會好奇那跟MVP(Minimum Viable Product)還有剛剛提到的Prototype有什麼差異呢？
以下就來比較MVP、POC、Prototype吧！！
MVP = 一種實體產品的驗證，需投入市場進行驗證，是針對投資者或企業主所評估 。
POC = 一種概念的驗證，用於技術和測試的驗證，是針對開發或研發者所執行的驗證方式。
Prototype = 一種想法實體化的外觀顯示。
步驟四：Testing
QA與QC?
大家都知道測試有分QA（Quality Assurance）與QC（Quality Control），這兩者又有什麼不同?
QA：指有一套機制檢驗品質有沒有問題，強調「預防」問題發生，在既有規格行況下開發確保最後產出是有符合預期產出。
QC：指發現問題後的分析、改善那些不合格品的控制，意思就是確保此物件的缺陷之後不會出現，簡單來說就是透過檢驗找出潛在性問題，大部分製造業才會有QC。
仔細聊解QA、QC兩者在工作、技術層面都有不同，但現在很多企業都把QA、QC角色職責合併執行，可能更傾向主要負責QA則QC為輔。
手動測試還是自動化測試?
起初一定都是靠手動去測試，當需求規格明確後，測試者會依照最終呈現畫面、資料輸入格式等逐一測試，但當系統功能越來越多、越來越強大時，每一次的發版更新會是一大災難，這時候就可能收到nUser「奇怪，這功能本來不是可以輸入特殊符號嗎?這功能怎麼不能用了?」之類的回饋，因此，這時候就需要導入自動化測試。
自動化測試主要就是四項目的「降低人為因素、節省成本、降低風險、提升覆蓋率」。
當系統越來越複雜時，很多功能會隨著版本迭代導致原本功能突然不能正常使用。則自動化的開始是先將手動測試的方式「分階層」在選擇階層進行自動化，著名的「捲筒冰淇淋」測試即說明由執行時間長到短間的測試分類，測試人員需要花較多的時間與精力在「用戶驗收測試」階段。但其實這樣長期「頭重腳輕」是不利於持續整合，道理很簡單，若每次都要到發布測試版本時測試人員才能夠進行整合測試，當需要頻繁迭代發版或在scrum環境中，總部會每一次都直到最後發布使用者驗收的版本才進行整合測試吧!!!
我們試著把冰淇淋「倒」過來吧!!
金字塔測試（Pyramid Testing）把握主要三個原則：
⭐花更多的時間在建立單元測試、系統整合測試
⭐增加單元測試數量
⭐減少用戶驗收測試數量
這麼做有幾個優點：
⭐增加測試品質，將較多的時間放在單元測試及系統整合測試上，能確保較高的測試品質。
⭐減少用戶驗收測試數量，因為通常在用戶驗收階段，發現問題的成本很高（重新測單元、系統整合等），而且會影響整個系統，若系統與系統間有相依性，那問題可就更大了。
⭐提高團隊效率，因為單元測試和系統整合測試可以在開發過程中進行，而不需要等待用戶驗收測試。
推薦好文：SØREN PEDERSEN — How to Avoid the Ice Cream Cone of Test Automation
總結
最後的步驟五與步驟六就是Release與Maintenance and Updates啦!!
雖然我本身是Project Manager，但在公司組織改動後，我的角色漸漸的開始接觸開發與測試部門的管理，更多需要理解的是當需求方提出目標後，如何與技術部門的leader討論收斂與轉化問題，有時候並不是做與不做的決策，而是如何做才對整體團隊最好，或者說「如何才是符合產品開發路線與目標」，因此，在這過程中會更密切的與 Dev Leader, Product Leader決策者溝通，以及管理Dev team, QA team。
但如果你只是個”純軟體專案經理”也需要懂得軟體開發的步驟與流程，因為有可能你就是為團隊帶來需求的人，你甚至需要花更多的功夫在溝通需求的軟實力中，既要了解客戶想要什麼目的，又要了解團隊的開發的過程，千萬別當一個為了管理而管理的人！！
謝謝大家花時間閱讀！
如果想給點小鼓勵可以給我1–10 個拍手；👆
如果文章對你有幫助可以用11–20 個拍手讓我知道；🤚
如果真的很喜歡這篇文章，想看更多內容的話，拍好拍滿也沒問題!🤲
非常歡迎大家一起交流，歡迎留言給我~
