接到需求任务，我们就开干吗？

你好，我是张飞洪，本文共2094字，预估10分钟读完。

冲突是怎么产生的？

我们见过很多类似的场景：

小飞：流程引擎做得咋样了？（和颜悦色）

小洪：做完了，我给你演示一下。（心情愉悦）

小飞演示了一遍自己做的功能，小洪看上去很满意。

小飞：不错。不过，怎么没有支持流程审核？（质疑）

小洪：为什么要做这个？（质疑）

小飞：这不就是流程的一部分吗？（不舒服）

小洪：哪里规定要做流程审核了？（不舒适）

小飞：现在做流程哪有不用审核的？（火药味）

这个时候如果双方都不能很好地控制自己的情绪，那接下来一场体力的较量可能就一触即发了。

分歧

为什么会出现这种分歧呢？其中一个重要的原因是，开始实现这个需求之前，任务双方都没有清晰地定义好边界，没能把需求描述清楚。

需求规格

不知道大家接受的需求说明文档都长成什么样，有没有固定规格。我这里先罗列我见过的需求文档大纲：

需求大纲

我们再看看部分截图：

功能描述

大概总结一下，有几个核心内容是我们重点要关注的：

业务流程图（数据流图）

界面原型图（静态和动态）

原型图功能描述

有些文档还会提供用户故事或者用例图来辅助说明，总之对开发者来说，保证核心内容的基础上，需求越规范当然是越好的，我们最不希望看到的是模棱两可、碎片化的需求清单，因为，通常这种功能列表只是一些简单的描述，你并不能看到全局。

用户故事

除了关注流程、原型和描述之外，用户故事（User Story）是我喜欢的一种方式。它是站在用户的角度来描述了一个用户希望得到的功能，关注用户在系统中完成一个动作需要经过怎样的路径。既然它是“故事”，它就需要一个完整的场景。

用户故事

相比较需求列表清单，不知道你对用户故事的感受是什么？列表是一种碎片化的内容，内部逻辑和全景图都是不清楚的；而用户故事有角色，有流程，有因果链，逻辑性更加强烈。

在前面的例子中，小张和小王之所以会对需求是否完成产生分歧，是因为大家对于需求完成的定义不同。

用户故事采用的是以终为始的交付方式，用户故事的核心是验收标准，它清晰地定义出产品的边界。

验收标准非常重要的一环是异常流程的描述。大部分程序员都擅长解决正常流程，而异常流程则是最容易忽略的，也是产生扯皮的关键环节。既然容易扯皮，我们就在一开始把它定义清楚。怎么才算做完需求呢？验收标准说了算，达不成就不算任务完成。而且验收标准可以由开发、测试、产品共同使用而不会产生歧义。

如果你的团队采用用户故事的格式进行需求描述固然好，如果不能，在功能列表中，补充验收标准也会极大程度地改善双方协作的效率。

用户故事

角色定位

也许你会感慨需求规格和用户故事很好，但是“臣妾做不到啊，我们是小公司”。首先我们要明确自己的定位，我是一个产品经理还是开发人员，还是无所不能的全栈人员，不要做越界侵权的事情。

产品和开发是两种不同的角色，但是对一些小公司可能分得不是那么清楚，开发会兼职产品经理的角色，产品经理也会兼职开发。对一些大公司来说，产品经理也会有技术背景。总之，这两个角色分分合合，统一于软件的生命周期。

用户故事的验收标准主要是业务上的，程序员最后不要越界，徒增浪费，我们的发挥空间应该是在技术实现上。

然而，在现实情况中，很多团队做不到这种程度。

假如你们团队没有产品经理，用户故事验收标准来写？

没办法，答案只能是你自己。虽然你名义上是程序员，但当拿到一个需求的时候，你要做的事不是立即动手写代码，而是扮演产品经理的角色，分析需求，圈定业务范围。相信我，事前分析绝对比你拿一个写好的系统给老板，而他却告诉你这不是他想要的，好太多了。

另外我想提醒你注意的是，扮演不同角色的时候，我们的思考模式是不同的。产品思考的是做什么（方向），开发思考的是怎么做（手段）。

另外，如果你要兼顾两个角色，建议你先扮演好产品经理，多花点时间把验收标准制定好，再回到开发人员的角色上去写代码。毕竟，最容易维护的代码是还没写出来的代码。

角色定位

总结

最后，我们总结一下：接到需求立刻开工是不成熟的表现，因为你可能会南辕北辙，交付的产品是有歧义的，最后导致的结果是扯皮和争吵，白白浪费资源。

在向目标行进的过程，我们要先想清楚自己想做什么，先明确需求规格和用户故事，特别是验收标准，最后还要知道自己的角色分工和定位，避免该越界的不越界，不该越界的乱越界的混乱。

如果今天的内容你只能记住一句话，请记住：在做任何需求或任务之前，先定好验收标准。最后，我想请你回想一下，在实际工作中，你接到需求后是如何开展工作的，或者你希望的需求规范应该长什么样？欢迎在留言区写下你的想法。

感谢阅读，我是张飞洪，如果你觉得这篇文章对你有帮助的话，也欢迎分享给你的朋友。