需求与设计的继承关系
问题:
在指导项目组编写用户需求说明书、产品需求说明书、概要设计、详细设计过程中，针对这些文档的相互继承关系和内容的粒度上有困惑。通常来说，模板要求非常细致和详细，也有相关示例，但是实际上如果完全按照模板的方式写，对于我们目前小规模项目来说，负担太重，几乎沉没于文档编写工作中，重要的市场突破、战略工作无法有效的开展。
那么，我们应该如何对各方面取得好的平衡，既能保证质量又不牺牲效率呢？麻烦杨老师不吝指教啊：）
回复：
谢谢你的问题。
我们很多事情，都是自己把它变得非常复杂。其实过程改进不是这么复杂的。我最近跟深圳这边一个单位交流，就是谈你现在提的问题。我们的项目很多是规模满小的。都有同样的疑问。
这个疑问，反映了我们的思维。我们一开始就把CMMI当成一个步骤。因为我们的思维，是“流程”的思维，是表面的，是形式的。所以是额外的负担。我已经非常强调这个是一个错误的态度。错误，因为这是低效的。
我们应该用“过程”的概念。这包括了每一个步骤后面的原因,包括不同事务之间的因素。“流程”只是一系列的步骤，他限制了，规范了我们的行为。“过程”呢，是一个框架，有优化过程本身的机制，也有帮助员工自己提高的机制。知道了这些，才能自主地符合优质过程的要求。
但是我们的EPG不明白这个，而且EPG的技术知识，比不上项目的人员，所以他们定义的规程与模板，很多都是多余的，提供的价值不大。
答案其实在你的问题上：“针对这些文档的相互继承关系和内容的粒度上有困惑。”解决这个问题不在于模板，是吧？我们要解决了这个困惑，了解了这些继承关系之后，制定出来的规程与模板才可能有意义。否则一定没有意义。
所以我不能直接回答你的问题。我不清楚你们的项目，你们的规程，你们的模板。但是我看过这里的规程、模板。也跟这里的项目经理谈过。我正在安排基于他们给我的需求文档，来做一个工作坊之类的活动，让大家了解如何“描述”需求，来体现你说的“文档之间的继承关系”。只有项目经理和系统工程师了解这一点，能够做到这一点，制定出来的规程与模板才可以有效，才不会如你所言的，“负担太重”, 因为模版反映的，是他们自然的、高效的工作方法。对了，规程就是用来固化最佳实践的。
我以前的需求文档，里面有很多需求项。也有其他的描述与解释参杂其中。但每一个需求项都需要是完整的。每一个需求项都有一个独一无二的编号。模板，其实就只是每一个需求项的开始与完结的符号而已。我们在需求开始的符号里，隐藏了需求项的编号和与上层需求的关连性。如此而已。其他的描述与解释，使自由发挥的，没有规范。这样的模板，其实额外的负担是非常小的。
需求项的粒度，要越小越好。明确、精细的需求，可以减少误解，提高开发效率。当然，过份的“精细”是可以失去意义的。如果我们规定每一个需求项，都包含一个需要验证的因素，就可以防止无意义的细化。需求项的大小，在我们不断实践的过程中，就自然会慢慢地稳定在一个水平上。这就是一个合理的需求项粒度。
无论是你的感觉，或是整个单位的，当我们觉得对粒度有困惑，是因为我们没有实践过使用需求来规范产品，和规范下游的工作。这里是规范，因为下游的工作，视需要与需求一致的。了解了这个要求，通过实践，才能体会需求的最佳粒度。呢一个粒度，才能规范产品，才能规范开发活动？答案是在系统工程师自己。他们要通过承担责任的态度，追求达到规范产品与开发活动的目标，这样的思考来培养自己的分析能力，才可以解决你提到的困惑。
但是过程管理是不能不做的，因为过程管理要求考虑的因素，就是系统工程师需要考虑的。所以这里其实是很有学问的。请留意，“过程”里要求的，不一定是员工现在知道的，“过程”要求的，是这个岗位需要能够做到的。所以是一个提高的方向。
建议你的步骤如下：
第一，规程定义与模板，还是要开始的。
第二，同时，我们要知道规程的意义，在于提高项目效率。不是每一个项目的每一次
效率，是项目的总体效率，和组织里总体的项目的效率。
所以我们要知道，开始的遵从度，只是建立纪律而已。
过程定义本身，还是需要优化的。
因为这样，我们不能拿过程来考核！否则这个优化过程的机会就没有了。
第三，项目经理，系统工程师，高层经理，是过程改进第一批受影响最大的人。这些
岗位上的人，都需要有改变。你的问题，是系统工程师的改变。
第四，系统工程师要提高对各个文档之间的继承关系进行了解。这个是知识与技能水平。
提高需要一个过程，一段时间。所以过程改进本身，需要提供这些学习的机会。
第五，领导或是高层需要要求每一位员工能够符合岗位的要求。（这是 “企业培训” 里说明的。)
我们不能姑息。
谢谢你的努力，希望你能够成功。