你好，我是张飞洪，本文共2094字，预估10分钟读完。
冲突是怎么产生的？
我们见过很多类似的场景：
小飞：流程引擎做得咋样了？（和颜悦色）
小洪：做完了，我给你演示一下。（心情愉悦）
小飞演示了一遍自己做的功能，小洪看上去很满意。
小飞：不错。不过，怎么没有支持流程审核？（质疑）
小洪：为什么要做这个？（质疑）
小飞：这不就是流程的一部分吗？（不舒服）
小洪：哪里规定要做流程审核了？（不舒适）
小飞：现在做流程哪有不用审核的？（火药味）
这个时候如果双方都不能很好地控制自己的情绪，那接下来一场体力的较量可能就一触即发了。
分歧
为什么会出现这种分歧呢？其中一个重要的原因是，开始实现这个需求之前，任务双方都没有清晰地定义好边界，没能把需求描述清楚。
需求规格
不知道大家接受的需求说明文档都长成什么样，有没有固定规格。我这里先罗列我见过的需求文档大纲：
需求大纲
我们再看看部分截图：
功能描述
大概总结一下，有几个核心内容是我们重点要关注的：
-
业务流程图（数据流图）
-
界面原型图（静态和动态）
-
原型图功能描述
有些文档还会提供用户故事或者用例图来辅助说明，总之对开发者来说，保证核心内容的基础上，需求越规范当然是越好的，我们最不希望看到的是模棱两可、碎片化的需求清单，因为，通常这种功能列表只是一些简单的描述，你并不能看到全局。
用户故事
除了关注流程、原型和描述之外，用户故事（User Story）是我喜欢的一种方式。它是站在用户的角度来描述了一个用户希望得到的功能，关注用户在系统中完成一个动作需要经过怎样的路径。既然它是“故事”，它就需要一个完整的场景。
相比较需求列表清单，不知道你对用户故事的感受是什么？列表是一种碎片化的内容，内部逻辑和全景图都是不清楚的；而用户故事有角色，有流程，有因果链，逻辑性更加强烈。
在前面的例子中，小张和小王之所以会对需求是否完成产生分歧，是因为大家对于需求完成的定义不同。
用户故事采用的是以终为始的交付方式，用户故事的核心是验收标准，它清晰地定义出产品的边界。
验收标准非常重要的一环是异常流程的描述。大部分程序员都擅长解决正常流程，而异常流程则是最容易忽略的，也是产生扯皮的关键环节。既然容易扯皮，我们就在一开始把它定义清楚。怎么才算做完需求呢？验收标准说了算，达不成就不算任务完成。而且验收标准可以由开发、测试、产品共同使用而不会产生歧义。
如果你的团队采用用户故事的格式进行需求描述固然好，如果不能，在功能列表中，补充验收标准也会极大程度地改善双方协作的效率。
用户故事
角色定位
也许你会感慨需求规格和用户故事很好，但是“臣妾做不到啊，我们是小公司”。首先我们要明确自己的定位，我是一个产品经理还是开发人员，还是无所不能的全栈人员，不要做越界侵权的事情。
产品和开发是两种不同的角色，但是对一些小公司可能分得不是那么清楚，开发会兼职产品经理的角色，产品经理也会兼职开发。对一些大公司来说，产品经理也会有技术背景。总之，这两个角色分分合合，统一于软件的生命周期。
用户故事的验收标准主要是业务上的，程序员最后不要越界，徒增浪费，我们的发挥空间应该是在技术实现上。
然而，在现实情况中，很多团队做不到这种程度。
假如你们团队没有产品经理，用户故事验收标准来写？
没办法，答案只能是你自己。虽然你名义上是程序员，但当拿到一个需求的时候，你要做的事不是立即动手写代码，而是扮演产品经理的角色，分析需求，圈定业务范围。相信我，事前分析绝对比你拿一个写好的系统给老板，而他却告诉你这不是他想要的，好太多了。
另外我想提醒你注意的是，扮演不同角色的时候，我们的思考模式是不同的。产品思考的是做什么（方向），开发思考的是怎么做（手段）。
另外，如果你要兼顾两个角色，建议你先扮演好产品经理，多花点时间把验收标准制定好，再回到开发人员的角色上去写代码。毕竟，最容易维护的代码是还没写出来的代码。
角色定位
总结
最后，我们总结一下：接到需求立刻开工是不成熟的表现，因为你可能会南辕北辙，交付的产品是有歧义的，最后导致的结果是扯皮和争吵，白白浪费资源。
在向目标行进的过程，我们要先想清楚自己想做什么，先明确需求规格和用户故事，特别是验收标准，最后还要知道自己的角色分工和定位，避免该越界的不越界，不该越界的乱越界的混乱。
如果今天的内容你只能记住一句话，请记住：在做任何需求或任务之前，先定好验收标准。最后，我想请你回想一下，在实际工作中，你接到需求后是如何开展工作的，或者你希望的需求规范应该长什么样？欢迎在留言区写下你的想法。
感谢阅读，我是张飞洪，如果你觉得这篇文章对你有帮助的话，也欢迎分享给你的朋友。