Hello 線上的軟工夥伴好，
我們今天的主題來談一下『軟體開發時間怎麼做預估』。
通常客戶需求方只會給出名詞、概念。
例如：我想要一個APP可以看出現在還有多少需要執行工作？還有多少貨品沒收到倉庫？成本已經花了多少？之類的。
需求？啥？我怎麼把這鬼東西變成可以放在手機或網頁跑的程式？對~~~ 你還早的呢。
就像從台北搭高鐵去高雄，拿到需求頂多只是買到車票吧。
那，桃園新竹台中嘉義，個別又對應到甚麼呢？
1. 首先需要查看一下，需求裡面有沒有特殊需要解釋的名詞：
也就是不容易懂的詞、或是不容易計算數量的詞，有的話，一定要追根究柢的問清楚。
畢竟，大多數提需求的人，在他的那個行業打滾有一定的時間了，我們不是那個領域中，可能就不清楚細節、眉角做到哪。怎麼判斷是否滿足呢？想想看自己能不能通順、不帶迷惑的講出客戶想操作的故事？如果可以，那恭喜你過板橋站了。
2. 要記得問客戶，特別不希望有什麼東西出現：在初期，大多數人的習慣是從正面來訴說，但是這也造成軟體退貨率居高不下的狀況，因為你沒有避開客戶不要的。這點一定要特別筆記下來。
接下來，夥伴該我們上場了。
3. 開始在紙上畫個拆解圖、或是想像的堆疊圖。這些雖然是老掉牙的系統分析步驟，可是是有道理的。透過大部拆解，很方便可以理解：有沒有現成的輪子，場景該怎麼轉彎，有沒有現有資源可以搬來借用的。比較講究的就會開始畫流程圖、畫分鏡圖，這些都好，都有助於更深入的理解接下來的動作。
畫圖沒辦法一下子很細，可是透過動手畫，變相的強迫自己思緒轉了一圈，這是邁向專案經理最重要的動作哦。畫圖的過程，主要就是關注連結和轉折，透過甚麼功能連結等等....
拆解之後，理論上我們已經接近台中，也就是路程的一半了。專案管理這個學科中總在強調一件事：品質來自於設計，不再於QC，意思就是在設計的過程是非常重要的，想通了再寫事半功倍。邊走邊想事倍功半。
拆解後，我們自然會把注目焦點，從全流程降階到每一個重要步驟。人只有再聚焦的時候，品質和效率才會是高的
接下來開始往嘉義台南接近了。
4. 對一些重點段落，可找比較有經驗的人員準備較為粗糙，或說擬真的程式碼。透過這些堆疊，可以方便後面接手的同學做更加精緻的處理，然後串聯，測試，產出客戶需要的操作場景。
這樣一串的操作，大家應該對於怎麼把漂浮在半空中的需求，落地實現開始長出一些概念。我們可以找一些簡單的案例，慢慢的操作看看，實現並不難哦。
祝福大家有一個平安順利的軟件人生。
沒有留言:
張貼留言