目前問題與改善(OLD)

--- lang: zh-tw title: '目前問題與改善(OLD)' tags: '看' --- 目前問題與改善<code class="red">(未完成)</code> === :sweat_smile::face_with_head_bandage: 目前問題 --- - **有經驗 PG 拿到沒開好的規格，卻採用「經驗」+「通靈」之邊開發邊問模式，長期會造成不良後果?!** - 當有經驗 PG 拿到一份沒有開好的規格(不明確的規格)時，只要在規格說明時大概聽懂規劃的大方向、邏輯、規則、流程，就選擇收了這份規格，直接採用「經驗」+「通靈」之邊開發邊問模式，然後就會先開發出一版給 PM，除非...在開發中遇到真得需要再釐清或缺的東西還沒給或資訊不正確導致無法往下開發時才會發問，而會這樣的原因大致有 : - 時間已經不夠了，不想浪費時間，因為問的風險太大了 - 發現是開規格時根本沒想清楚，問了之後，東西還是不能一次給正確、清楚、足夠，會發生只給不太重要的資訊，真正重要確資訊反而沒給到，再追問後，常常是必須還要等 PM 再想想再規劃或是還要再等跟客戶來回確認，如果再一直追問下去，發現會來來回回太多次數，真的是太浪費時間、太累了，那不如我用經驗+通靈先寫一版，不然...這樣搞下去一定會來不及 - 怕一問反而工作更多，甚至要大變動，這也是在開規格時沒想清楚、沒想到、沒想法，等 PG 問了之後才有想法或才認真去想，這種狀況肯定會走到開發時間不夠用的田地 - 這樣的方式，之前的客戶是比較沒主見，就我們給什麼就接受什麼。或是只要稍微說服一下就過關，那就皆大歡喜，但是...現在的客戶是有主見的比較多，不管是真的有主見還是被逼得必須要裝一下有主見，總之，狀況漸漸跟之前不一樣了，所以不可以再這樣了 - 這樣的方式，會讓 PM 以為規格不用開明確，只要大概開一下就好，也不用太在意是否要去跟客戶確認，反正 PG 看不懂會自己來問，沒問也會出一版程式，到時候看狀況再說 - **規格太晚給，開發時間不夠** - 如果規格開得夠明確(正確、清楚、足夠)，那可能靠加班或 PG 們互相幫一下還可以解決 - 如果規格開得不明確，那就不是靠加班就能解決了，還必須「不斷的來回確認需求」+「通靈」，會消耗相當多的開發時間與動力，有時又要等客戶回覆，那就更浪費時間，最後連開發時間也變不夠。 - **規格沒開好，也就是規格開不明確(正確、清楚、足夠)** - 規格開的太簡陋或開規格時沒想清楚，規格根本不完整，重要資訊沒有提供完整，缺東缺西，還必須「不斷的來回確認需求」+「通靈」，會消耗相當多的開發時間與動力，有時又要等客戶回覆，那就更浪費時間，最後連開發時間也變不夠 - 更可怕得是...都開發到一半，甚至都已經開發好了，才發現規格根本不對，不是客戶要得，那就只能不爽的大改或重寫。 :::warning **以 PG 的立場，為了讓專案可以順利結案，如果規格太晚給但有開好，是可以加班的，但是規格太晚給又沒開好又要加班，在實際經歷過後，真得很不願意，因為必須一次一次來回的確認規格，真的很浪費時間，也真的很沒效率，這種狀況如果次數多了，甚至變成常態，會非常反感** ::: - **沒跟客戶溝通確認規格，直接開發** 在開規格時，會出現以下兩種不好的狀況 : 1. ++需求資訊未收集/挖掘完整++ ➜ 就自行依據經驗或自行腦補開規格 ➜ 但是沒有跟客戶溝通確認所開的規格是否符合需求(通常應該會再來回個幾次) ➜ 就直接開發 ➜ 導致作出來的功能有~~很大~~落差 ➜ 最後就又必須~~大~~改版 <code class="orange" style="color: transparent !important;background-color: transparent !important;">**➜ 這時候 PG 會想說:改版很容易嗎?是不用花時間嗎?要不然你來寫~**</code> 2. ++只收集到極少的需求資訊，因為客戶沒想法、沒時間、不想參與++ ➜ 真得只能依據經驗與自行腦補開規格，基本就規劃出1個版本，後續再作確認，有些視狀況可規劃2~3個版本，後續再作選擇與確認 ➜ 到這裡都還 OK，因為現實中真的有滿多客戶就是要等你有東西給他後，他才願意有想法、有需求 ➜ 但可怕的是...就沒有後續了，規格開好沒拿去跟客戶作溝通確認(通常應該會再來回個幾次) ➜ 就直接開發 ➜ 導致作出來的功能有~~很大~~落差 ➜ 最後就又必須~~大~~改版 <code class="orange" style="color: transparent !important;background-color: transparent !important;">**➜ 這時候 PG 又會想說:改版很容易嗎?是不用花時間嗎?要不然你來寫~**</code> - **PM 與 PG 之間互動、溝通的頻率過少，這種狀況久了，會產生「認知落差」+「不爽心情」** - PM 很少主動去了解 PG 在開發過程中狀況、是否有需要協助或溝通的地方，「功能小、功能少」可能無所謂，但是如果「功能大、功能多」+「一直都沒有進行工項管制」，最後 PM 將無法知道 PG 開發的進度，也不知道 PG 在幹什麼，常常都只有開發前交付工作項目與要交付前一天或前幾天才會去找 PG，中間幾乎都沒有 - PG 很少主動跟 PM 說明跟回報功能開發得難易度與進度，導致至 PM 無法理解為何要花這些的時間，也會導致 PM 在評預估功能開發時間會錯誤 :face_with_rolling_eyes::blush::label: 改善 --- **主要是想讓大家有相同的概念、觀念，跟執行時的大方向、大原則。** - **專案中，PM 必須是積極主動的，不管是對客戶還是對 PG** - **專案中，有技術相關事項需要協助，PG 必須積極支援** - **專案中，PM 與 PG 必須持續溝通與調整，達成共識(減少認知落差)** - **專案中，PM 在管控專案的同時，必須主動適度去了解 PG 的處理狀況** - **專案中，PG 在撰寫程式的同時，必須主動適度回報處理狀況給 PM** - **專案中，要讓執行進度透明化，不要呈現出 :** - PG 不知道為什麼 PM 要我作這個，也不知道專案目前的狀況 - PM 不知道 PG 目前的開發進度與狀況，也不知道目前在作哪一個功能 --- ```graphviz digraph { fontname="Helvetica,Arial,sans-serif" fontsize=20; rankdir=LR; node [fontname="Helvetica,Arial,sans-serif"] node [shape=box,style="filled",color="#9370DB",fillcolor="#ECECFF", fontcolor="#333"]; 協助撰寫RFP 協助撰寫RFP -> 撰寫服務建議書; 撰寫服務建議書 -> "進行需求訪談 (需求收集)"; "進行需求訪談 (需求收集)" -> 開需求規格與工項管制表; 開需求規格與工項管制表 -> 開發與維護; } ``` - 在 ==協助撰寫RFP==、==撰寫服務建議書==、==進行需求訪談(需求收集)==、==開需求規格與工項管制表== 階段，以專案處為主(執行者)，技術處為輔(協助者) - 在 ==開發與維護== 階段，以技術處為主(執行者)，專案處為輔(協助者) ___ - **專案開工前一定要有啟動會議，主要是要讓所有參與者知道專案內容(工作範圍)、方向、時程與查核點(查核時間與項目)，讓大家知道我們是在做什麼東西?要做到什麼程度?什麼時候要完成什麼東西?目前的進度如何?這樣，大家才會有明確的目標、才會作的安心、才會有向心力** - **[**需求訪談**](https://hackmd.io/@SuperBin/ByCseBrqs#-%E9%9C%80%E6%B1%82%E8%A8%AA%E8%AB%87)一定要積極主動的去收集/挖掘與溝通確認出客戶的真實需求，過程中必須確認方向、框定範圍，並確定所收集的需求資訊足以拿來開出明確的規格，並且在完成需求訪談後，將彙整的結果給客戶確認，~~最好可以簽名畫押~~** - 經評估後，如需 PG 到場協助，就要通知 PG 並協調出時間 - 需求訪談在實務上、經驗上，它常常是需要多次的，而且也常會在開規格、開發、測試、上線、維護階段時，也需要再作需求訪談，只是我們必須、應該、期望在開規格前將大多數主要、必要的真實需求給它收集/挖掘出來 - **[**需求規格**](https://hackmd.io/@SuperBin/ByCseBrqs#-%E9%9C%80%E6%B1%82%E8%A6%8F%E6%A0%BC)的開立，是對所收集的需求資訊進行彙整、分析、規劃出滿足真實需求且必要可行的規格，而規格內容的描述必須是正確、清楚、足夠的** - 開需求規格時，如需了解技術可行性，就快讓 PG 加入吧 - 開需求規格在實務上、經驗上，它很有可能會出現邊開規格、邊作更進一步的需求訪談、又邊跟 PG 溝通討論技術上的可行性 - 實務上會發生，已經到必須開規格的時間，但需求資訊卻還不完整或極少，先去除 PM 是否有積極主動的因素，常是因為客戶配合度不高，有可能是 : 客戶沒想法、沒時間、不想參與，這種狀況，趕快主動去追著客戶進行需求訪談，如果真的無法如願完成，那就先將可以開規格的部分先開，並跟客戶(主要是承辦)反映，也讓 PG 知道狀況，然後採取邊需訪邊開規格的模式 - **所開的規格如果連自己都覺得不行，那就不要拿給客戶進行確認，也不要交付給 PG 進行開發，建議可以使用情境模擬（使用者故事）的方式來協助自己確認規格是否明確，就想像使用自己所開的規格，是否可以正確且順利的模擬各種所規劃的使用情境** - **規格開好後，是先給客戶，讓客戶先看過，並進行溝通確認，如有落差，必須針對該部分作修正，最後，將完成的規格給客戶確認，~~最好可以簽名畫押~~，再進行下一步(建工項管制表)** - 不管客戶會不會看，會不會想好好地進行溝通確認，我們至少要將規格文件給客戶，告知客戶如有需要作調整/修正，可再進行溝通討論，如沒有就依規格開發 - **客戶確認規格後，需再建立[**工項管制表**](https://hackmd.io/@SuperBin/ByCseBrqs#-%E5%B7%A5%E9%A0%85%E7%AE%A1%E5%88%B6%E8%A1%A8)，必須清楚列出每個工項，並對每個工項定出預計完成日、優先順序、實際完成日⋯等有助進度管控的資訊，供查看或回報，其中預計完成日一定要給足夠的開發時間** - 在定每個工項預計完成日時，如需 PG 的技術協助，以了解工項執行(功能開發)的難易度與預估花費時間，讓預計完成日可以定的更精準，就快讓 PG 加入吧， --- - **交付規格書與工項管制表給 PG 的時間點不可以太晚，而且要面對面進行口頭說明與溝通，如雙方有認知落差，必須先釐清確認後再進行下一步(開發)** - **PG 在開發前，一定要再次確認規格有搞懂、該給的參考資料也都有給齊，才可以進行開發，如有不 OK 的地方，必須先處理好再進行開發** - **PG 在開發時，原則上是依據工項管制表所定的優先順序開發各個功能，每完成一個功能或一組功能，除了必須自行測試外，也必須主動適時回報** - **關於專案中「留紀錄」這件事，它除了讓我們作事有一個依據、也可以讓我們回顧與追蹤過程、也可以透過它來了解進度(建立工項管制表的用意也是如此)、也可在未來如果出事時拿來當證據，是一個保障，尤其是我們跟客戶之間處理事情一來一往的紀錄或任何簽名畫押的動作** --- - 為了讓大家作事要有紀錄有依據，所以依據目前問題與狀況，在專案執行中，分別針對「需求收集與變更」、「規格書」、「工項管制」有對應的表格要請大家確實填寫。 - [:memo: 1-1.需求訪談記錄表範本(docx)](https://210.71.231.36/docs/1-1.需求訪談記錄表範本.docx) - [:memo: 1-2.需求變更訪談紀錄表範本(docx)](https://210.71.231.36/docs/1-2.需求變更訪談紀錄表範本.docx) - [:memo: <code class="red">**2-1.需求規格書範本(docx)**</code>](https://210.71.231.36/docs/2-1.需求規格書範本.docx) - [:memo: <code class="red">**2-2.專案工項管制表範本(xlsx)**</code>](https://210.71.231.36/docs/2-2.專案工項管制表範本.xlsx) :::warning - **其實...以上都是中文字，除非內容真得寫得很爛很爛，讓大家看不懂，那寫的人就要改進表達方式** - **不然...上述想傳達的概念、觀念，應該多多少少都有所理解，最難的是<code class="red">++積極主動的執行它++</code>** - **當然...上述得不一定全對，也不是全部，也可能表達的不好，那就要請大家提出來討論討論** ::: :link: 參考 --- <style> code.red { color: #e91e63 !important; font-size: 1.6rem !important; } code.blackred{ color:#900000 !important; font-size: 1.6rem !important; } code.blue { color: #337AB7 !important; font-size: 1.6rem !important; } code.orange { color: #F7A004 !important; font-size: 1.6rem !important; } font.pm{ color: #bd0000 !important; } font.pg{ color: #006700 !important; } </style>