一般这样的人会分为这几种。
- 淡定派：端着装有枸杞的保温杯，笑眯眯的看着产品，看着ui,看着后台一个个争的不分上下。
- 吐槽派：不管能不能做，先吐槽一波。“这什么需求啊，哪有这么个反人类的设计，产品，你能不能做个人。这不行，这得加工期，UI，你能不能把这帮我直接切成图，我好直接用。后台，能不能数据在后台直接做好，我前端只负责用”
- 假装简单派：这类人通常也是淡定的一种。拿到需求后不管内心表现的如何慌张，外表总是一副淡然的样子，这需求吗，做过。给我一周。项目经理：“XXXXX”！。
那做为前端，在接到需求的第一时间，我们应该去做些什么呢？ 正确做法应该是这样的。
第一：熟读需求，列出来不懂的需求点以及模糊的需求点。准备提问。
第一点，也是最初的点，这个点对前端来说尤为重要，那就是快速理解业务及内心通过以往的知识快速构建实现方式采用框架，技术点等。这时候一定要着重于不理解的业务，因为一步之差有可能十万八千里，这里一定要将自己不懂的需求点以及不明确的点，列出来。后面来与其它小伙伴对，看看是不是你想的这种方案。千万不要为了省事模糊的去做，不然返工的时候，就有你后悔的时候。
第二：阅读需求的同时，回想之前是否有类似的东西可以直接用的模块，可以搜索相关产品，查看他们的展示方式及功能实现需求。
当你第一步做完之后，到第二步，就可以根据以往的经验以及做过的功能来判断当前需求应该使用怎样的技术，怎样的实现方式来达到目得，如果之前有做过的类似的东西，也可以直接拿过来用，或者实在没有头绪，不知道如何开始的时候，推荐你，先上网搜索一下，通过类似产品及项目的使用，来确定你的实现是如何进行的，一定记得，没有最好的实现方式，只有最贴近用户使用方式的实现方式。不要过于刻板的必须用哪个，只有适合你，适合用户的功能，才是一个好的功能。如果之前有做过类似的最好，可以抽象成自己的公共组件库，直接用。
第三：与UI讨论，判断两个人的阅读完需求文档后，思想是否统一。
在你完成了第一第二之后，基本上根据需求文档，你能看懂得部分在你心中已经大概有了一个简单的实现思路，那么下来就需要的是，找参与项目的其它工种人员来核对，当前需求及你内心的实现方式是否可行。第一个肯定就是UI，毕竟UI是前端的指路灯，如果你的实现方式与UI的图差的远，那么你的思路则只能作废重新考虑。所以第一个必须是找UI来达成一致。对业务的理解，业务实现方式的建议与意见。是否有什么需要要点需要考虑等。
第四：与后端讨论，判断两个人对业务的理解是否统一。
当你与UI只要能打城一致，那么后台基本上也就稳了，毕竟后台也是看UI及前端的实现方式来给予接口数据。所以，与后台的沟通，只要没什么太大的需求理解差距，基本上都会随着你走。但是不妨有一些后台性子比较轴，这时候非得你跟他的数据接口走，那也没事，一般来说，前端后台都是有可处理数据的能力，谁处理不是处理呢。毕竟他后台也得根据UI图来设计数据库不是。
第五：拉产品小组进行开会讨论，提出疑问与异议。
搞定了UI与后台后，基本上你对已经理解的需求已经没有什么太大疑惑了，但是同时为了保证需求理解是一致性的，这时候你需要将你的需求疑问点表带着拉动产品，UI，后台来进行一次需求确认会议。说先说清你对已理解的需求的看法，同时你需要将之前自己没理解清楚的需求疑问点也拉出来 ，让产品进行讲解，现场提出疑议。
第六：前端小组开会，确认需求及统一需求功能界限。
到这一步的时候已经基本说明，你们的需求已经大概理解清楚了，所以这时候你需要给前端组的其它小伙伴来讲解需求，确认统一需求思想。回答他们的疑问与异议，确保前端小组内对于需求的认知是一致的，以免下阶段分任务开发后，做成了不同的两个模块从而没法整合在一起。
第七：需求模块分工。
这里就已经是大家最常见的工作了，一般有的公司是抽卡领任务，有的是自由领任务。有的是组长直接分配。所以这里就不多说了，按照大家常用的方法来即可。
以上，为做为前端，在拿到需求的第一时间应该做什么的全部内容。欢迎各位伙伴补充或者提出意见。毕竟各个公司的有可能不太一致，而我也是站在自己所接触的层面这样感觉。~ 欢迎拍砖 。么么哒~
