1。需求確定的情況很少，因為客戶的需求總是在變，即使確定下來，驗收的時候也會提出新的問題，這個要靠專案經理溝通，使用者當前的問題在這個版本中解決還是下期合同來做。因此來說，需求大體確定以後，拆分子系統組成---子系統的組成模組--細分模組組成，這個是相對粗粒度的，然後就要考慮你手頭隊伍對細分模組的開發實現能力，大體就知道工作量了，如果不趕工期，時間要放長，軟體開發，沒有一帆風順的，肯定會有很多問題，簡單來說就是常見的需求變更。
2。評估成員工作量，首先要了解隊伍組成，哪些人規劃流程清晰，哪些人對技術攻關能力更好，哪些人適合測試，哪些人編碼快速，哪些人對資料庫精通，哪些人對介面佈局更擅長，哪些人有技術的同時更善於溝通。所以通常都是更善於溝通的做組長，及時把流程清晰的告訴組員，反饋每個組員的工作進度，協同組員進度並決定何時由何人做技術攻堅，何時組織測試。
3。專案完成以後就好統計了，每個小組的程式碼行數，實現的功能模組數量，供其他小組呼叫的模組，用時多少天，涉及多少領域等，其實這個統計不能說a組完成專案的40%，b組60%這樣，比較合理的應該是在某個方面，各個小組的組成比例的表格，然後有個小組工作的總結比較合適。如程式碼統計，a組2w行，佔40%，b組3w，佔60%。 模組數量：a組6個，佔60%，b組4個佔40%，並附模組結構的說明。當然，各個公司的管理不一樣，統計方式不一樣，反正一個原則就是儘量兄弟們多說點好話，因為一個軟體做成，每個環節都不能差的，再好的汽車，如果沒有一個很普通的小小鐵板當剎車踏板，你敢開嗎。
1。需求確定的情況很少，因為客戶的需求總是在變，即使確定下來，驗收的時候也會提出新的問題，這個要靠專案經理溝通，使用者當前的問題在這個版本中解決還是下期合同來做。因此來說，需求大體確定以後，拆分子系統組成---子系統的組成模組--細分模組組成，這個是相對粗粒度的，然後就要考慮你手頭隊伍對細分模組的開發實現能力，大體就知道工作量了，如果不趕工期，時間要放長，軟體開發，沒有一帆風順的，肯定會有很多問題，簡單來說就是常見的需求變更。
2。評估成員工作量，首先要了解隊伍組成，哪些人規劃流程清晰，哪些人對技術攻關能力更好，哪些人適合測試，哪些人編碼快速，哪些人對資料庫精通，哪些人對介面佈局更擅長，哪些人有技術的同時更善於溝通。所以通常都是更善於溝通的做組長，及時把流程清晰的告訴組員，反饋每個組員的工作進度，協同組員進度並決定何時由何人做技術攻堅，何時組織測試。
3。專案完成以後就好統計了，每個小組的程式碼行數，實現的功能模組數量，供其他小組呼叫的模組，用時多少天，涉及多少領域等，其實這個統計不能說a組完成專案的40%，b組60%這樣，比較合理的應該是在某個方面，各個小組的組成比例的表格，然後有個小組工作的總結比較合適。如程式碼統計，a組2w行，佔40%，b組3w，佔60%。 模組數量：a組6個，佔60%，b組4個佔40%，並附模組結構的說明。當然，各個公司的管理不一樣，統計方式不一樣，反正一個原則就是儘量兄弟們多說點好話，因為一個軟體做成，每個環節都不能差的，再好的汽車，如果沒有一個很普通的小小鐵板當剎車踏板，你敢開嗎。