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

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

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

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

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

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

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

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

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

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

，没能把需求描述清楚。

需求规格

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

我们再看看部分截图：

的：

• 业务流程图（数据流图）

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

• 原型图功能描述

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

用户故事

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

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

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

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

则是最容易忽略的，也是产生扯皮的关键环节。既然容易扯皮，我们就在一开始把它定义清楚。怎么才算做完需求呢？验收标准说了算，达不成就不算任务完成。而且验收标准可以由开发、测试、产品共同使用而不会产生歧义。

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

角色定位

侵权的事情。

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

实现上。

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

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

。相信我，事前分析绝对比你拿一个写好的系统给老板，而他却告诉你这不是他想要的，好太多了。

的。产品思考的是做什么（方向），开发思考的是怎么做（手段）。

。

总结

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

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

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

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