接到需求，你要先做哪件事？

{"type":"doc","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"郑晔老师在","attrs":{}},{"type":"link","attrs":{"href":"javascript:void(0);","title":null},"content":[{"type":"text","text":"《10x程序员工作法》","attrs":{}}]},{"type":"text","text":"中给了一个例子，程序员小李接到一个单点登录功能的需求，小李经过几天的奋战写完了代码。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"在给产品经理小王演示时，小王对整体很满意，就是觉得不支持验证码不太符合常规设计。但是小李觉得这个需求里面没有提，就没做......","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"小李觉得很辛苦，小王觉得没做完。我平时接一些私活儿时，也会处于这种局面，根据前期讨论的需求，我很快就做完了，然后拿给用户演示，发现这不是结束，而是刚刚开始。因为用户在一开始并不能把自己的实际需求想得很明白。","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":1},"content":[{"type":"text","text":"描述需求的方式","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"不同需求的描述方式，可能会影响程序员对需求的理解。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"信息传递会衰减，如何传递，直接决定了衰减的比例。","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"基于功能列表的描述方式","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"我们公司以及在平时私活儿中，开发模式都是基于功能列表的。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"公司项目中负责需求的同事，先会跟用户讨论需求，整理出需求文档，项目经理根据需求文档中的功能点拆分开发任务，开发领到任务开始写代码；私活儿中，我自己扮演了需求与开发兼项目经理的三个角色，干的事情都差不多。","attrs":{}},{"type":"text","marks":[{"type":"strong","attrs":{}}],"text":"功能列表其实只是一些简单的描述，并不能看到全局","attrs":{}},{"type":"text","text":"。这种功能列表式的需求描述方式，将一个完整的需求敲成了碎片，只有所有功能完成时，才是破镜重圆的时刻。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","marks":[{"type":"strong","attrs":{}}],"text":"开发过程中，大多数人都无法看到完整的图景，项目会在最后遇到很多意料之外的事情，让大家都手忙脚乱","attrs":{}},{"type":"text","text":"。我们现在公司的项目就出现了这种情况。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"如果时多个组协同工作时，这种基于列表的需求描述方式的弊端更加明显。每个组都会按照自己的理解排列开发任务。当你所在的组完成了某功能的开发任务时，却上不了线，因为还要依赖别的组。像之前我做过的一个项目里面n个子项目，每个子项目之间会互相依赖，如果还按照基于列表的需求拆分，工作安排，兼职要令人抓狂啊。","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"“用户故事”需求描述","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"它需要一个完整的场景，将用户的需求将出来。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"一个完整的用户故事包含以下几部分：","attrs":{}}]},{"type":"bulletedlist","content":[{"type":"listitem","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"标题","attrs":{}}]}],"attrs":{}}],"attrs":{}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"概述","attrs":{}}]}],"attrs":{}}],"attrs":{}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"一般的描述格式：As a(Role),I want to(Activity),so that(Business Value)","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"详述","attrs":{}}]}],"attrs":{}}],"attrs":{}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"bulletedlist","content":[{"type":"listitem","content":[{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"验收标准","attrs":{}}]}],"attrs":{}}],"attrs":{}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"这里会描述系统的正常操作流程，以及各种异常流程系统的响应。大多数情况，我们都是流程跑通，结果发现要么是正常操作流程不完善，要么异常流程处理不到位。就是因为在写代码之前没考虑清楚。在这一环节给出了本次需求最基本的测试用例，保证了开发人员完成需求最进本的质量。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"如果在基于列表的描述方式中，加入验收标准的描述，也会提高协作效率。","attrs":{}}]},{"type":"heading","attrs":{"align":null,"level":2},"content":[{"type":"text","text":"关于角色","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null},"content":[{"type":"text","text":"拿到一个需求后，先分析清楚比蒙头就做好太多。","attrs":{}},{"type":"text","marks":[{"type":"strong","attrs":{}}],"text":"分析需求时，你需要学会扮演各个角色，比如假设自己是用户、是产品经理、是测试，这样你才能分析得更透彻","attrs":{}},{"type":"text","text":"。做出来的东西质量会更高。","attrs":{}}]},{"type":"paragraph","attrs":{"indent":0,"number":0,"align":null,"origin":null}}]}