用户直接给一个解决方案，怎么办？

        经常遇到这样一种情况，用户号称提一个需求，结果直接丢过来一个解决方案，而这个解决方案并不是一个好的解决方案，甚至有可能是错误的。这个时候，作为敏捷团队，应该怎么办呢？

        下面以一个实际的案例，来描述一下需求沟通中需要关注的地方。

        XX公司采用敏捷开发方法，需求管理和任务管理统一在TFS上，采用迭代的方式，迭代周期有一周的和两周的，小李负责TFS的维护。

        一天，XXX开发部主管老王提了一个需求，要在任务的属性上增加一个字段：重要性，来表示该任务的重要程度。

        TFS上对任务增加一个字段？可能很多对TFS熟悉的同学会说：简单，分分钟的事。可是作为敏捷开发的拥护者，小李不这么认为。我们来分析这个需求，从需求的描述来看，用户直接提了个解决方案。那么，用户提这个解决方案，到底解决他的什么问题呢？小李找老王沟通，问三个问题：谁需要用这个功能？在什么场景下用？为什么要用？大家知道老王怎么回答的吗？老王说：我们的项目组要用，在任务拆分时用，为了做好项目管理。小李说：任务已经有一个属性，叫做优先级，能否利用这个字段来进行管理？老王说：优先级跟重要性不一样，优先级表示紧急程度，有重要紧急的，也有重要不紧急的。

小李听到这里，心里想：“这不是瞎扯吗，任务都是在迭代内了，同一个迭代内，还管什么重要紧急重要不紧急；迭代内先按照用户故事的优先级做，然后同一个用户故事下的任务一起做，1~2天完成一个用户故事，还管任务的重要性干嘛呢？”。小李心里想着，可只能跟老王解释：我们在特性上有业务价值，可以代表重要性，迭代内的用户故事有优先级，我们要求先完成优先级高的用户故事，后完成优先级低的用户故事，至于任务方面，同一个用户故事的任务，尽量一起做。

老王听了说：特性的业务价值，是PO来管的，项目组不关心，我就是要在任务上加一个重要性的字段。

小李说：如果真的要加，你们可以先在任务的标题加上重要性标识，先用用看。

老王说：不行，任务的标题太长了，不能再加了。（任务的标题上包含：版本号、特性名、用户故事名、任务名，有的还包含人名）。

小李说：你们的任务标题，版本号、特性名、用户故事名、人名都是多余的，建议去掉。

老王说：不行，我是用户，我就要在任务的属性上增加一个重要性的字段。

小李说：这个做不了。

谈话结束。

回顾一下这段需求沟通过程，小李有几个地方需要改进：

1、内部客户也是客户，客户是上帝，小李的态度需要调整；

2、该需求的用户、应用场景、目的需要进一步深挖，了解到具体用户后，可以进一步跟实际用户进行沟通。

 

在第一次需求沟通无法达成一致的情况下，进行了第二次需求沟通，这次加入了PMO小张。

小张拿当前项目中的一个实际例子，问老王怎么加重要性，加了重要性后怎么使用？

老王说，这是项目组提出来的，需要问项目经理，把项目经理小周叫进来一起讨论。

小周进来后说：SE在拆分任务后，需要对任务的重要性做标记，级别高的任务，需要重点关注完成质量。

小张：怎么重点关注？

小周：比如要做代码走查，或者要出设计文档，进行设计评审。

小李：代码走查和设计可以单独作为任务来管理。

老王：我们不想增加任务，就需要增加一个重要性的字段。

小李：重要性字段填写后，怎么使用呢，谁关注这个字段，跟优先级怎么区分？

老王：我们做项目管理用，具体怎么使用，我们会在项目组内部说清楚。

小张：重要性是一个很泛的概念，如果是关注质量方面，是不是可以叫质量价值？

老王：可以。

小周：可以。

小李：……

小张：那这个字段可以加吗？

小李：暂时加不了，会加的人休产假了，等她回来吧，建议先直接在任务的标题上加标记。

小张：老王，小周，休产假大概下个月才能回来上班，到时候再加可以吗？

小周：可以，我们先在任务标题里加标记，先用着。

老王：不给加和没人做是两码事，可以暂时先不加。

最后达成一致，项目组先在任务标题上加标记，等休产假的同事回来再加一个字段，取值范围为1~9.每个数字表示什么意思，项目组自己搞清楚。

第二次沟通的结果跟第一次差别不大，但是效果好很多。分析以下有如下区别：

1、小李和小张联合，一个唱黑脸，一个唱红脸，缓和了气氛；

2、引入了实际用户，对需求进行了明确；

3、采用拖字诀，更好地让客户去使用替代方案（原型、MVP）。

后续再看实际的使用效果。