需求與設計的繼承關系
問題:
在指導項目組編寫使用者需求說明書、産品需求說明書、概要設計、詳細設計過程中，針對這些文檔的互相繼承關系和内容的粒度上有困惑。通常來說，模闆要求非常細緻和詳細，也有相關示例，但是實際上如果完全按照模闆的方式寫，對于我們目前小規模項目來說，負擔太重，幾乎沉沒于文檔編寫工作中，重要的市場突破、戰略工作無法有效的開展。
那麼，我們應該如何對各方面取得好的平衡，既能保證品質又不犧牲效率呢？麻煩楊老師不吝指教啊：）
回複：
謝謝你的問題。
我們很多事情，都是自己把它變得非常複雜。其實過程改進不是這麼複雜的。我最近跟深圳這邊一個機關交流，就是談你現在提的問題。我們的項目很多是規模滿小的。都有同樣的疑問。
這個疑問，反映了我們的思維。我們一開始就把CMMI當成一個步驟。因為我們的思維，是“流程”的思維，是表面的，是形式的。是以是額外的負擔。我已經非常強調這個是一個錯誤的态度。錯誤，因為這是低效的。
我們應該用“過程”的概念。這包括了每一個步驟後面的原因,包括不同僚務之間的因素。“流程”隻是一系列的步驟，他限制了，規範了我們的行為。“過程”呢，是一個架構，有優化過程本身的機制，也有幫助員工自己提高的機制。知道了這些，才能自主地符合優質過程的要求。
但是我們的EPG不明白這個，而且EPG的技術知識，比不上項目的人員，是以他們定義的規程與模闆，很多都是多餘的，提供的價值不大。
答案其實在你的問題上：“針對這些文檔的互相繼承關系和内容的粒度上有困惑。”解決這個問題不在于模闆，是吧？我們要解決了這個困惑，了解了這些繼承關系之後，制定出來的規程與模闆才可能有意義。否則一定沒有意義。
是以我不能直接回答你的問題。我不清楚你們的項目，你們的規程，你們的模闆。但是我看過這裡的規程、模闆。也跟這裡的項目經理談過。我正在安排基于他們給我的需求文檔，來做一個工作坊之類的活動，讓大家了解如何“描述”需求，來展現你說的“文檔之間的繼承關系”。隻有項目經理和系統工程師了解這一點，能夠做到這一點，制定出來的規程與模闆才可以有效，才不會如你所言的，“負擔太重”, 因為模版反映的，是他們自然的、高效的工作方法。對了，規程就是用來固化最佳實踐的。
我以前的需求文檔，裡面有很多需求項。也有其他的描述與解釋參雜其中。但每一個需求項都需要是完整的。每一個需求項都有一個獨一無二的編号。模闆，其實就隻是每一個需求項的開始與完結的符号而已。我們在需求開始的符号裡，隐藏了需求項的編号和與上層需求的關連性。如此而已。其他的描述與解釋，使自由發揮的，沒有規範。這樣的模闆，其實額外的負擔是非常小的。
需求項的粒度，要越小越好。明确、精細的需求，可以減少誤解，提高開發效率。當然，過份的“精細”是可以失去意義的。如果我們規定每一個需求項，都包含一個需要驗證的因素，就可以防止無意義的細化。需求項的大小，在我們不斷實踐的過程中，就自然會慢慢地穩定在一個水準上。這就是一個合理的需求項粒度。
無論是你的感覺，或是整個機關的，當我們覺得對粒度有困惑，是因為我們沒有實踐過使用需求來規範産品，和規範下遊的工作。這裡是規範，因為下遊的工作，視需要與需求一緻的。了解了這個要求，通過實踐，才能體會需求的最佳粒度。呢一個粒度，才能規範産品，才能規範開發活動？答案是在系統工程師自己。他們要通過承擔責任的态度，追求達到規範産品與開發活動的目标，這樣的思考來培養自己的分析能力，才可以解決你提到的困惑。
但是過程管理是不能不做的，因為過程管理要求考慮的因素，就是系統工程師需要考慮的。是以這裡其實是很有學問的。請留意，“過程”裡要求的，不一定是員工現在知道的，“過程”要求的，是這個崗位需要能夠做到的。是以是一個提高的方向。
建議你的步驟如下：
第一，規程定義與模闆，還是要開始的。
第二，同時，我們要知道規程的意義，在于提高項目效率。不是每一個項目的每一次
效率，是項目的總體效率，群組織裡總體的項目的效率。
是以我們要知道，開始的遵從度，隻是建立紀律而已。
過程定義本身，還是需要優化的。
因為這樣，我們不能拿過程來考核！否則這個優化過程的機會就沒有了。
第三，項目經理，系統工程師，高層經理，是過程改進第一批受影響最大的人。這些
崗位上的人，都需要有改變。你的問題，是系統工程師的改變。
第四，系統工程師要提高對各個文檔之間的繼承關系進行了解。這個是知識與技能水準。
提高需要一個過程，一段時間。是以過程改進本身，需要提供這些學習的機會。
第五，上司或是高層需要要求每一位員工能夠符合崗位的要求。（這是 “企業教育訓練” 裡說明的。)
我們不能姑息。
謝謝你的努力，希望你能夠成功。