1.1 需求變化
專案的需要變化是肯定有的，而且變化一般都很頻繁，我們怎麼應對客戶的這種需求變化呢，以不變應萬變。首先在前期的需求調研要做好，盡可能的替使用者考慮，達到功能質量滿足最大化。需求調研前期的《目標與範圍》和需求調研末期的《功能規格說明書》都要跟客戶簽字確認，這樣既能保證我們所理解的需求就是客戶所要的，也使得專案末期跟客戶驗收時有據可依。在專案中期是發生需求變更是很常見的，這時要做好需求變更管理流程。需求變更表，小的變更自己掌握，客戶要求的變更有開發人員和設計人員共同商討後提交專案經理，專案經理預估變更損耗工程時間，在一定階段一起提交給客戶，大的變更直接提交客戶，並且要把需求變更對專案產生的影響讓客戶知道，把球盡可能的踢給客戶，讓客戶在進度、功能、資源三者中取捨出乙個平衡來。對需求進行分類評級，關鍵部分不能改動的做特別確認（如系統架構等，如果改變等於從頭再來）。同時完成客戶簽字確認，當然如果能將這部分寫成合同細節中去是最好。以下是我認為變更的步驟：
¢ 第一步：客戶提出變更內容
l 客戶提交的變更必須基於書面形式
l 客戶提交的變更必須有充分理由
• 如果變更被拒絕，對業務的負面影響
• 如果變更被接受，對業務的正面幫助
¢ 第二步：為能否實現變更作評估
l 從實現方式上考慮新的變更可否實現
l 對於較複雜的情形，輔以簡單的說明。欲詳述，可作附件處理
l 對於簡單情形，例如頁面布局更改，則無須說明
¢ 第三步：可以實現看進度
l 進度幾乎是絕大部分專案關注的第一要素
l 對於活動級別的進度影響
l 對於專案整體工期的影響
¢ 第四步：變更成本
l 人力相關的變更成本
• 是否需要額外的專案組成員
• 專案組需要增加的工時數
是否正常工時（工作日加班、節假日加班）
• 專案工數**
l 非人力成本
• 軟硬體費用
• 資料費用等
¢ 第六步：質量和風險
l 變更對質量的多方面影響
• 分階段影響（需求、設計、編碼、測試、維護）
• 可靠性、安全性、可維護性、可用性等
l 可能對團隊士氣的負面影響
l 可能引發的間接任務對工期的負面衝擊
l 開發方的成本負擔可能超出力所能及的範圍
¢ 第六步：需求變化的確定
1.2 架構設計
撰寫詳細設計是乙個逐步細化、深入的過程。沒有人能一次就設計出完美的東西，需要及時的溝通，包括與客戶的反饋，與其他專案組成員的討論，這樣有助於降低開發時偏離需求的風險。也就是說，在開發之前題，是建立在設計者的想法有客戶的確認和開發人員的理解的基礎之上設計撰寫人必須與系統分析員反覆討論，以透徹理解使用者需求；
一項需求可能有多種方式實現，設計者必須與系統分析員確定該需求將採用何種方式實現，將達到何種效果，以消除將需求對映為設計的歧義；討論過程中還可能會發現需求有不完備甚至錯誤的地方，在需求重新確定後設計者需修正設計。設計文件必須寫清楚各個模組/介面/公共物件的定義，列明程式的各種執行條件與期望的執行效果，還要正確處理各種可能的異常。此外設計文件應該遵循一定的寫作模式與版面風格，使用統一的術語或慣用語，使得小組成員很容易理解。以上這些活動綜合起來將是乙個很細緻、很耗時的工作過程。就個人所知，一些公司的詳細設計通常是由程式主管或少數核心的程式設計師撰寫的，他們通常也是系統架構的主要作者或維護者。因為他們在開發團隊中技術最為精湛，對架構最為熟悉，他們最有資格評價現有架構是否能適應新的使用者需求，採用何種方式實現需求對架構的衝擊最小。但是由少數人來負責所有的詳細設計可能造成開發過程中的瓶頸甚至是設計的錯誤。當任務比較集中的時候，設計者可能忙得透不過氣，而負責實現的同事反而在等公尺下鍋，比較清閒。於是為了讓自己不成為拖累進度的「罪人」，某些設計者就會採用一種快捷方式來交付設計：他們會與系統分析員進行初步的討論，然後撰寫乙份粗糙的但仍然叫做詳細設計的文件，把它交付給負責實現的同事，再通過討論、即時通工具、電子郵件等方式解答對方提出的疑問。但由於詳細設計本身不完備，他們不得不花費更多的時間和精力與負責實現的同事溝通；而且他們卻很可能忘了把這些交流的成果更新到詳細設計中去！（或許是他們太忙，沒有足夠的時間，又或許是他們認為既然產品已經實現，那麼詳細設計也就不必維護了。）其結果很可能是當產品開發出來後，我們才發現它跟使用者要求的完全兩樣！原本在詳細設計階段就應該發現的需求漏洞與在那時應該確定的技術方案在實現階段甚至測試階段才暴露出來，而這時大家往往有木已成舟的感覺，改動的難度比設計階段高數倍甚至十倍以上，畢竟任何再牛的人都有自己的侷限。
對於以上問題我提出全員設計，全員設計的含義就是把詳細設計的工作進行適當地分解，把它們分攤到小組內其它同事身上，讓大家都參與設計。這可以說明如下：
當一組使用者需求基本確定下來後，程式主管需要估計需求的相關性、需求的優先順序、設計的難易程度、設計的工作量等，將該組需求分解為一或多項設計任務，並指定給適當的同事。參與設計的每個人必須負責至少一項設計的撰寫任務。設計者從系統分析員處獲得詳細的使用者需求，並與系統分析員反覆溝通以透徹理解使用者需求。他還要分析系統架構及產品的已實現與/或已規劃部分，理解架構的設計理念，理解產品不同模組之間的協作關係，理解架構與產品之間的約束和依賴。當然對系統架構和產品的分析不可能窮盡每乙個細節，只要分析與即將開發的模組相關的內容即可。
一項設計任務，它可能需要多個程式設計師完成。比如使用者介面或網頁由某位或某組同事負責，而業務邏輯元件則由另一位或另一組負責，資料庫部分則又由其它同事負責。設計者必須考慮他們的立場，以各方面都相對容易理解的方式寫清楚主要的模組/介面/物件定義，明確相應的呼叫規則與主要邏輯處理。如果某項設計任務所涉及的內容太專業化，設計者並不熟悉相關的內容（比如某位c#程式設計師並不熟悉如何編寫乙個儲存過程），他可以用描述性的文字說明該部分的設計要求，並知會相關的同事補充。其它同事在補充時可以對這些描述性的文字重新整理，以更加確切地表達設計內容，更符合文件的書寫慣例。在設計文件完成後，設計者必須把他提交給程式主管或由程式主管指定的程式設計師審閱。個人推薦由其它程式設計師而不僅僅是程式主管來審閱。不用擔心等待多個人的審閱意見是否可能導致乙份設計滯留很久。大家可以並行地工作，不必是a審閱後才能b審閱。可以交叉審閱，即a的設計由b、c審閱，b的設計由a、c審閱等。審閱意見可以用多種方式（如討論、即時通工具、電子郵件）反饋給設計者，設計者負責彙總這些意見並修正設計。以個人的經驗而言，通常設計交付審閱後半天內就可以收到反饋意見了。設計經過反覆地修正直至沒有人再提出修正意見，這時就可以由程式設計師實現了。以個人的經驗而言，乙份設計通常兩、三輪反饋後就可以定稿了。如果多次反饋後仍不能定稿，極有可能是：
a)需求尚未明確，各個方面（包括客戶、系統分析員或設計者）對需求的看法不統一
b)技術或系統架構存在嚴重的限制，無法用較方便的方式實現
全員參與設計好處、風險與不適用的團隊如下：
1.2.2 推行全員設計的潛在風險
1.在某種意義上，全員設計可能增加交流的成本。兩個人之間有一條交流途徑，三個人之間最多有三條，四個人之間最多有六條。途徑越多，資訊量就越大，而這些資訊不見得都是有用的資訊。詳細設計的任務分解後，不可避免地有更多的人參與交流和溝通，大家要花更多的時間來理解他人的想法，也可能要花更多的時間向他人闡述自己的觀點。特別是在並行撰寫詳細設計的過程中，系統分析員反而可能成為另乙個瓶頸了。但從總體上來看，在設計階段花費適當的代價發現更多的問題，比在實現階段或測試階段再發現問題，仍然是划算的。
2.分解後的詳細設計可能引入衝突的設計內容。由於設計由不同的程式設計師撰寫，他們考慮問題的角度和思維的方式不可能完全一致，這增大了不同的設計內容之間的計算口徑或互動方式不一致的可能性。這需要設計者們盡可能遵循一致的設計原則，也需要審閱者們盡可能找到這些不一致的地方。
3.並不是所有的程式設計師都適合參與設計。很明顯，例如剛入職的同事就不適合參與設計，他們對系統架構還缺乏足夠的認識。另外兼職的同事也不適合參與設計，他們的工作方式可能無法保證及時提交設計文件與參與討論等。
1.3 溝通
在專案的開發過程中，在團隊中的成員之間以及和客戶之間是乙個不斷的交流和溝通的過程。我們的開發過程最好是乙個迭代式的開發過程（尤其是國內的專案）。這樣我們可以盡早發現開發出來的功能是不是符合客戶的需求，以免開發完了，客戶說這個不是我們需要的後果。
1.4 計畫執行控制
制定系統得整個計畫，任務的劃分以及分配工作，跟蹤任務的進度，使我們的專案進度在控制範圍之內。
1.5 風險管理
風險是隨著專案的不同階段變化的，不同的階段風險是不同的，我們必須分析我們當前面臨的風險的數量、影響程度等，以及怎麼去解決這些風險。
1.6 測試
測試工作目前在國內的中小公司做的都不太好，但是從我們做專案或者產品必須重視測試工作，把握好質量關。
1.7 驗收為目的的思想
在開發過程中，內部管理還要注意的一點是時刻強調以驗收為目的的思想，每個任務的最終可交付成果一定要是可以被檢查的，比如，【介面要求：美觀大方、簡潔明快】，這個要求我就不知道如何檢查。所以，給開發小組布置任務的時候就要考慮如何檢查結果，比如我見過乙個計畫，裡面有乙個任務【開發人員熟悉ejb程式設計】，這個任務，除了讓這些人去參加一些專業認證考試，否則，結果很難被檢查。所以，時刻考慮如何檢查結果、如何向客戶交付是專案經理一直要注意的事情，我聽說有些老專案經理拿到專案是倒排計畫的，即首先看如何驗收和驗收標準，然後決定工作計畫。很多專案開始了很久，還不知道如何驗收，那麼這個專案出問題的可能性就很大了。做專案就是為了驗收，我們的角色不是研究機構，我們的目的就是在付出那麼多勞動後得到結果
專案開發經驗談（二）
1.1 需求變化 專案的需要變化是肯定有的，而且變化一般都很頻繁，我們怎麼應對客戶的這種需求變化呢，以不變應萬變。首先在前期的需求調研要做好，盡可能的替使用者考慮，達到功能質量滿足最大化。需求調研前期的 目標與範圍 和需求調研末期的 功能規格說明書 都要跟客戶簽字確認，這樣既能保證我們所理解的需求就...
專案開發經驗談（二）
1.1 需求變化 專案的需要變化是肯定有的，而且變化一般都很頻繁，我們怎麼應對客戶的這種需求變化呢，以不變應萬變。首先在前期的需求調研要做好，盡可能的替使用者考慮，達到功能質量滿足最大化。需求調研前期的 目標與範圍 和需求調研末期的 功能規格說明書 都要跟客戶簽字確認，這樣既能保證我們所理解的需求就...
專案開發經驗談（二）
1.1 需求變化 專案的需要變化是肯定有的，而且變化一般都很頻繁，我們怎麼應對客戶的這種需求變化呢，以不變應萬變。首先在前期的需求調研要做好，盡可能的替使用者考慮，達到功能質量滿足最大化。需求調研前期的 目標與範圍 和需求調研末期的 功能規格說明書 都要跟客戶簽字確認，這樣既能保證我們所理解的需求就...