摘要:開發心得-會議完後需要做些什麼？
這一場會議，來自PM的循問，因為他被業務端指派說我們接到了一個東西，需要做什麼東西。
問我這個系統該怎麼做？
我好像是架構師，畢竟這個小系統，是我維護產品系統的一小部分，我的確很熟，而且遇過的狀況百出。
我就告訴他怎麼做這個系統，需要誰幫忙，哪些技術人員，十幾分鐘的時間，隨便畫畫個草稿說，
照著這樣做，可以做出穩定的系統出來，一勞永逸。（就不會像我現在維護的產品，有很多問題需要修補）
然後PM就招開會議，將IOS工程師、PHP工程師、我(雖然是Android工程師，但前身是產品維護、後端工程師、網頁工程師），然後就去幫忙他們講解這個系統怎麼做（奇怪了～這不是我份內工作呀～冏～不過我是沒在乎是不是職責內的事，因為是朋友幫幫忙呀～如果不是朋友呢？有時為了避免系統被搞爛，留洞給後面的同事，有時插手一下，是為了讓公司不會造成很多工程師變累，而造成同事因前人留洞，導致後續花很多時間處理，也相對於公司是浪費資源，插手一下也是為了讓公司空閒呀～其實我也沒拒絕～畢竟公司人都很好～又不是勾心鬥角，也不需要分你的、他的、我的～這是團隊、這是我們）。
這次開會討論，很多人參與後，反而激起更多的想法，
就變成，前端要做什麼，需要什麼，後端要做些什麼，PM要做些什麼。
然後，因這場會議，我好像又想到什麼，雖然都不干我的事，我只說，這前端要做什麼，後端要做什麼，要考慮什麼，但這份工作都沒我要的事，我只來幫忙告訴他們怎麼設計系統（其實我就是架構師顧問～～）
然後，跟PM 講，你要出什麼文件。
系統需求、系統設計文件，也就是前端要做什麼，後端要做什麼，後端要注意哪些東西，前端有哪些Gateway 串接，後端要開哪些Gateway，做哪些邏輯處理，非同步、同步、資料表設計、索引設定、防呆處理、還有前後端的大概流程圖的動向。
所以初步認為會有
1.系統需求文件。(大概描述前端要做什麼，後端要做什麼，有要哪些東西，例如SSO，適用哪些狀況）
2.系統設計文件。(一些細節的邏輯設計，當遇到什麼，要做什麼）
3.資料庫文件。(Table Schema)
4.Gateway文件。(Web API文件)
5.會議記錄(標題、目的、參與人員、日期、結論）
後序文件準備好了，應該會開始動工吧（這不在會議討論中，但我想想如果是要開始做的話呢？）
會需要什麼？
1.系統環境圖(哪些Server、哪些機器）
2.SDK說明文件(要產品化，Lib就要設計好）
3.Backlog、Story、Task。(哪個功能，要多久時間）
4.人員資源分配文件(其實就是人員在哪些Task的意思）。
5.時程表(甘特圖）。
6.燃盡圖(工作燃燒狀況）。
7.測試文件(QA測試需求文件、QA的測試結果文件、Bug解決狀況與Feedback)
8.伺服器文件（機器的帳號密碼位置）
9.版本管理文件(SVN、GIT)
這以上都是我想出來的，不是什麼必要做，還是業界就是這樣做，
我是想用一個，我要怎麼做這些東西，或我如果是一個新人，來接手時，我知道哪些東西，可能會容易接手，不會漏掉什麼（像是伺服器文件，如果接手的人，不知道帳號密碼不就完了），或我是一個管理者，我要知道我指派的PM，做了些什麼，身上還剩多少資源或能不能指派東西給他。應該就會比較瞭解。
像這次隨便開一個會後，我想，PM如果能將各工程師要做的事，都設定好了，問他們要做些什麼，要多久時間，何時能做，何時能開始測，然後協調後續的動作。安排測試，或延長時間，或告知客戶，或協調資源等。
就這樣，我好像又懂了什麼？
