本來只想寫一篇的，沒想到寫著寫著就成了系列了。關於這個系列的前兩篇文章：《談談專案的開發》《談談專案的執行》。在寫這篇文章之前，先答覆一些朋友的疑問，專案的開發，有沒有必要到那以細呀？究竟有沒有必要，見仁見智吧，畢竟每個管理者在管理時所面臨的問題都是不同的。首先說說一名team leader往往會面臨到的問題吧：
1、保證專案的質量與可維護性。人員很多都是剛畢業的，編碼的方法、變數命名都很不好。
2、提交的**，看似完成，但是細節差得太遠了。
比如說，tab鍵的處理；enter鍵的處理；esc鍵的處理；按鈕的排列，哪些按鈕的放右邊，哪些按鈕放左邊；頁面的邊距等等這些細節。由於是新手，往往是會不注意這些的，所以必須明確下來，否則做出來的各式各樣。
4、開發人員之間缺乏溝通，很多可以重用的方法，卻各自都寫一遍。
5、作為team leader，要去閱讀他們的**，如果不知道問題的解決思路，閱讀起來就要花費多時間。還有乙個問題，就是新人的能力往往是比較欠缺的，以其在做的時候問，倒不如前事就告訴他們怎樣去做。同時，也讓他們有個準備，不致於按排的任務因為能力的原因而無法完成。
6、準確匯報專案的進度，每週都要向上匯報一次進度。
7、合理分配任務，協調好各人的開發進度。
由於以上幾點，所以必須清楚專案細節，以便掌控整個專案開發，往著自己所期待的方法發展。
另外還有朋友問到的幾個問題：
1、關於介面的細節制定：由team leader來制定。
2、關於介面的變動。一般都是由於設計的時候沒有想好，或者需求的變更。關於需求變更引起的變化後面再討論。由於設計的不足，隊員在開發時候常會碰介面的引數不夠，某些功能缺乏相應的介面，關於介面，還有引數，這個應該是在開發前，就應該討論好，想好的。在後期需要變動，應該是比少。應該怎麼變，需要些什麼介面，如果隊員已經知道是誰負責的，直接找相關人員。否則向team leader匯報，再按排人員。由於變動的介面比較少，team leader對整個專案還是在掌握中的。
關於需求的變更，這人是在每個專案開發的時候的都是會碰到的。一般來說，在對專案進行初期的分析調研後，或分成幾個里程碑，每個里程碑都都要完成哪些內容。現在假定有v1，v2，v3…… 這些里程碑版本，其中v1是給客戶演示的乙個版本，v2是待演示的乙個版本，v3是正在的開發的乙個版本，其中演示版本和開發版本都好理解，為什麼還要有個待演示版本呢？主要是避免當前開發版本出現意外，無法按時發布。
當我們接到需求變更的時候，應該極力避免接到乙個需求變就立馬修改**這種情況。需求的變更設為三個等級，輕微、普通、來得。
1、輕微。一般指的是對之前所寫的**，基本上沒有影響。比如說增加顯示的字段。
2、普通。一般指的是增加乙個功能，但是增加的功能和之前的**沒有太大的衝突，基本上通過增加表或者欄位就可以實現。
2、嚴重。一般指的是流程的變更。就是之前的需求分析中，少了乙個流程，或者流程錯了。
當需求的變更只是輕微和普通的時候，還是按原來計畫進行開發。在這個階段中，接到的需求如果不是嚴重性的，都放到下乙個版本去。在這個過程中，要做好設計方案 ，也就是說，要改哪些api，要怎麼去改，和之前文章提到的基本上一樣。對於需求的變更，盡可能採用批量修改的方式，而不是有乙個改乙個。主要是因為：
1、盡量給開發人員乙個穩定感。避免他們因為頻繁的修改而做出一些過激的行為。
2、這樣做會有更有條理，不容易有遺漏。
當接到乙個需求變更是屬於嚴重等級，也就是說，對當前開發影響很大的，很多地方的**都改動的。這個時候首先要做的就是設計了，然後進行討論，和前面說的基本上一樣。在開發之前，記錄好當前已經完成的功能，還有未完成的功能。然後開乙個分支，不要直接在原來的基礎上改，否則哪天客戶一拍腦袋，又要改回去，估計你會恨不得撞牆的。不知道你們有沒有碰到過，反正我是碰到過的。開乙個分支的好處是，在n個版本之後，客戶說要改回去，可以把對應的版本找出來，進行合併。
這就是我對需求變更的處理。溝通是需要花時間的，但是我認為，總得來說，還是值得的。
談談需求變更的使用者簽字確認問題
在軟體專案執行過程中，需求的變更在所難免。讓使用者對需求變更簽字確認往往是專案組比較頭疼的事情之一。一般來說，正常的需求變更還是需要使用者簽字確認的，當然要做通客戶的工作，讓客戶理解 簽字是為了更好的保障開發人員理解真正需求。一般來說，使用者不簽字有兩種原因 一是使用者認為不是變更，是應該做的工作 ...
需求的變更
需求的變更 2005 07 01 在專案開發的過程中，經常會出現需求發生變更的情況。從變更的結果上看，主要有以下幾種需求變更的情況 1 需求增加 2 需求刪除 3 需求發生改變 我們在實施專案的時候，往往做著做著，突然發現專案的進度已經落下了這麼多。查詢其原因，我們往往會發現，專案的某些需求在悄然的...
需求變更的代價和如何減少需求變更
需求變更的代價 一般來講，需求的變更通常意味著需求的增加，需求的減少相對很少，而且處理需求減少方面的問題也比較容易。當客戶提出新需求的時候，專案開發人員應該分析這些新需求對專案現階段帶來的風險，得出雙方實現變更需求的需要的成本，包括時間 人力 資源等等方面。變更都是有代價的，應該評估一下變更的代價和...