小項目特點：麻雀雖小，五臟俱全
- 功能相對較少
- 開發人員較少（通常 2-10 人）
- 開發周期較短（數周至數月）
- 常由中小公司承接，人員流動性大
雖規模小，但軟件工程基本規律不變，必需步驟不可省略，執行可靈活適度。
小項目開發五大常見錯誤
- 缺乏可行性與工作量估算：草率排期，實際與估算偏差大
- 無正式設計過程：口頭討論接口/數據結構，無文檔 → 理解偏差、模塊組裝失敗、人員變動導致知識斷層、維護困難
- 跳過單元測試直奔系統測試：嫌編寫測試數據麻煩 → 定位錯誤效率極低、邊界情況遺漏
- 缺乏協調角色：無人監控整體進度與一致性
- 文檔缺失：事後維護與版本升級極其困難
合理的小項目開發流程
1. 需求獲取：投入充分時間
- 專用軟件：合同只定框架，必須深度溝通確認細節，避免後期返工
- 通用軟件：市場調查（市場規模、技術指標：硬件/軟件/網絡/數據庫環境）
- 工具輔助：VB/Delphi 原型確認界面；UML Use Case 圖討論流程（原型可作增量開發基礎）
2. 需求分析：面向對象建模
- 提取類 → 類關系 → 迭代完善分析文檔
- 關鍵區分：問題域（所有相關部分）vs 系統責任（軟件應完成功能）。外部系統（如程控機、現有數據庫/服務器）建模為外部約束而非內部類
- 分析與設計銜接：需求穩定用瀑布模型（保留完整分析文檔便於多平台移植）；需求變化頻繁用迭代模型（少量分析→設計→編碼→測試），可能無完整分析文檔
- CASE 工具不分析/設計階段不意味著可混淆，工具只是筆，用法靠人
3. 設計階段：技術落地
- 分析模型必要修改（編程環境、復用舊代碼）
- 定義界面層、數據訪問層（可視化工具常將界面設計留到編碼階段）
4. 編碼與測試
- 編碼中發現上游錯誤及時回溯修正
- 嚴格執行單元測試 → 集成測試 → 用戶驗收測試，邊界測試不可省略
人員安排與角色分工
小項目通常由項目負責人（兼任分析/設計/協調/編碼）+ 2-5 開發人員組成。
項目負責人三大原則
- 協調優於編碼：隨時監控進度偏差、內容偏移，完成協調後再編碼
- 明確任務書：每人獲得具體文檔化任務，而非模糊口頭分配
- 全員熟悉設計模型：理解自己工作在系統中的位置，及早發現設計漏洞
微軟軟件開發管理快照（摘自《Debugging the Development Process》）
三大管理角色
- 項目主管：最終對代碼負責，監控進度、培訓、匯報，通常最資深且仍寫代碼（次要工作）
- 技術主管：最懂代碼，保證技術完整性、文檔更新，同為資深程序員
- 程序經理（產品主管）：協調市場/文檔/測試/支持，負責「盒子裡的一切」質量與進度，定義產品願景、編寫規格說明、可用性測試、驗收質量關
典型項目流程
- 程序經理與市場/開發/支持提出改進列表
- 編寫產品規格說明（功能細節：對話框繪制、宏函數參數）
- 全團隊審核規格 → 確定最終版本
- 可用性研究驗證直觀性，修改規格
- 開發並行，程序經理驗收每項功能質量
- 可視冰點：所有影響顯示功能完成 → 截圖寫手冊 → 之後禁止修改顯示
- 代碼完成 → 修復重大 Bug、必要改進
- 生成「金主盤」 → 復制生產、裝盒發布
文化細節
- Email 為主溝通工具，減少打擾；自發大廳會議補充
- 人人帶門獨立辦公室，關門即「勿擾」
- 扭轉困難項目需 2-6 個月，前兩月見效最快
領導力核心：做團隊一員，而非「高人一等」
四分衛不是超級巨星，只是承擔特殊任務的隊員。高效項目負責人：
- 視自己為團隊成員，承擔非編程職責（目標設定、跨組協調、創造高效環境、促進學習）
- 不因權威壓制異議，不搶功推責，不攻擊優秀成員，承認錯誤
- 分歧時尋求更站得住腳的解釋，而非固執己見
態度決定一切：把自己看作團隊一員，工作更順利，無需對抗權威挑戰，樂於與超級明星合作共贏。
