一直以来，研发人员都在抱怨需求的不明确与变化，这样大量造成了研发的无效劳动。
软件工程，过程管理，流程定义，我们寄希望与此，希望通过这些方式减少无效劳动。
需求-》需求分析-》概要设计-》详细设计-》代码-》测试。大概的流程都一样，但是，在每个流程域中，我们应该达到什么目标？作到什么程度？
产生混乱的是从需求到详细设计的阶段，在这个阶段中，我们定义三种主要角色：用户/需求人员/研发人员。
我的观点如下：
需求，由需求人员编写，达到的目标为使用户接受，作到的程度为说明白这是一个什么产品就OK。
需求分析，由研发人员（系统架构师/项目负责人/顾问角色）编写，达到的目标是决定能不能做，做到的程度为使用什么平台与技术实现。
概要设计，由研发人员（系统架构师/项目负责人）编写，达到的目标是分析需求分几个模块，做到的程度为各模块之间的通信协议接口。
详细设计，由研发人员（模块负责人）编写，达到的目标为各模块具体的实现机理。
注意：在各个流程域中，这些流程是可溯源与变更的。
但是，在实际的操作中，由于研发人员被无谓的劳动与变更害惨了，因此都希望需求能够明确，最好能够直接引导代码开发。
这就造成了“越界”行为，例如需求就定义了平台的选择与各模块的划分，在需求分析中就定义了模块实现的具体机理。
“越界”行为的危害在于以下三点：
1、各过程的不明确。需求做了需求分析的事，那需求分析做什么？去做设计的事吧！饶来饶去，乱套了，反而什么都乱了。
2、项目进度的影响，让需求人员直接进行平台的选择，并提交模块的划分，这是非专业人士做专业人士的事，容易造成错误不说，而且浪费时间。
3、扯皮。由于非专业人士做专业人士的事，研发人员只对需求人员负责，只是照做，出现错误后经常“掐架”。
为了不“越界”，我们是否可以定义以下各阶段的重点呢？
需求阶段：需求人员说，我了解了用户业务上的要求，针对这些要求，我想做这样一个产品，…………
需求分析阶段：研发人员说，恩，我明白了你的想法，我想用这个平台实现，用这个技术去做…………，但是，可能这个要求做不了，你看……（如果有的话）
概要设计阶段：研发人员说，恩，业务了解差不多了，基于平台与技术的特性，我想把这玩意分成这几个模块，各模块的接口定义如下…………
详细设计阶段：研发人员说，恩，业务就这些，接口也有了，伙计们，我们想想怎么实现吧……
这个模式或许不是最好的模式，但是我们回归本源，思考一下造成研发无谓劳动的根源是什么？
1、需求人员不了解用户业务上的需求。这是最致命的，他们如果连用户想要什么，想怎么用都不清楚，必然造成无谓劳动。
2、需求人员的不跟踪。多阶段，多角色，三人都能成虎，更不要说这么多角色了，如果需求人员提了需求就拍拍屁股不管后面了，往往会造成目标的偏移，特别在一些细节与用户感受度上，例如界面风格等。这时候有两种方案解决，一种是需求人员自己跟踪，另外一种是独立的测试人员进行文档测试，以确认目标没有偏移。
作为测试团队的负责人，在和各个角色沟通时，我一直秉承这样一个理念：对你最大的支持，就是把我该做的事做好。我们希望定流程，规范工作质量，但是我认为，在流程定义中必须坚持的是，各个角色做好自己该做的事，“越界”行为表面上看是做的更深入了，但是实际上却更容易制造错误。
