在每周的需求版本规划中，产品经理会讲一下需求的内容和需求带来的优化点、业务目标的提升点。对于开发来说一方面是评估需求的可行性和价值，判断需求是否可实现以及是否有必要投入开发资源，总不能真的做
根据用户手机壳颜色改变页面的主题色这样的需求；另一方面则是快速理解需求的内容，对需求实现时的各个功能点有个大体的认知，知道需求的难度和关键功能点的实现方式，进而合理地将需求分配出去。 因为刚接触这块的工作，还是有很多不够熟练或是做得不够好的地方。先记录一下现在的一些想法，随着工作进行可以不断完善这块相关的工作心得。
一般我会先快速浏览一遍需求稿，知道需求对应的工程和大概要做的东西，形成初步的需求理解。之后产品经理会顺着需求稿的目录开始详细介绍需求的内容，在这一步中就会进一步完善理解，也会把疑惑或是和产品有分歧的地方提出来，达成一致的认识；同时从前端的角度去评估可行性和实现难度，如果不能实现或是性价比很低的功能点（投入大量开发资源只为实现非刚需的功能）就看看换种实现方式或是把这个功能点去了。
很少碰到砍整个需求的情况，通常是因为在过需求的过程中发现流程有纰漏才会打回把需求稿完善一下。
评审完之后需求就会被确定下来流入到具体的开发手中，一般我会粗暴地把需求分成大、中、小三种规模，根据大家手头的工作量再分配出去。
小需求
小需求是版本迭代中最常见也最简单的了，像什么加个搜索条件啦，简单的交互改动啦，页面显示、文案调整啦这类两天内能完成的都算小需求。这类需求流转起来也比较简单，负责相应工程的同学有两天空闲的就可以把需求拍进去。
中需求
需要3~5天开发时间的需求会被归类到中需求里，与小需求不同的是它会改动到系统的多处地方，或是改动/新增到一个比较大的功能模块，比如给落地页新增一个组件，就需要建站端和渲染端都增加这个组件的逻辑；同时因为改动到了落地页（渲染端）的逻辑，需要进行更完善的自测和回归验证，因此需要更多的开发时间投入。与小需求相比，中需求有一定的实现难度和工作量，不是脸滚键盘就能完成的，并且有一定的代码风险。
大需求
我粗暴地把一周以上工作量的都算入大需求中，因为无论是开发难度大还是开发的代码量大，最终都会体现在需求的工作量上。大需求一般会对系统进行比较大的改动，甚至会改动到整个系统的架构。这里面又会分为两种需求，一种是完全增量的内容，一种是对老逻辑进行改动的需求。
- 完全增量的内容
这种类型的需求风险比较可控，需求难度更多地体现在技术层面。只要工期给得足够，就能很好地完成开发和测试的工作，并且因为是完全新增的功能，测试也能准确地回归功能点。
- 对老逻辑进行改动
这类需求是难度最高的，也是大需求中最常见的——对于一个比较成熟的工程来说很少会大量地增加新功能，更多地是在迭代现有的功能。而现有的代码逻辑错综复杂，互相关联，进行系统层面的改动需要非常细致地评估并给出改动点和影响面，测试也需要投入比较多的精力去回归这些影响面。
比如这周进行的一个
组件接入事件行为的需求，简单描述就是希望各个组件在用户触发交互（比如按钮、图片、轮播图的点击）、组件本身事件触发（比如视频的播放暂停、计时器的完成）时派发事件；同时组件本身也能订阅组件派发的事件，完成组件的显示隐藏、视频的播放暂停。
举例来说：按钮A在点击时派发事件event-A，图片B订阅该事件，在事件触发时隐藏图片B。
具体到代码实现，新增一套发布订阅系统，这个很简单直接用第三方库就能实现；需要添加事件的组件在触发交互时发布一个事件，需要添加行为的组件在初始化时订阅事件。麻烦的地方在于需要对所有组件都进行一次接入，还要处理对应的显示/隐藏的逻辑，肯定会改动到现有的渲染逻辑。而且在给出影响面的时候，几乎可以说整个落地页系统所有组件都需要回归一遍。开发和测试的工作量都比较大，特别是在测试本次需求内容时，14个组件都会派发事件，8个组件会订阅事件处理一些诸如显示隐藏、播放暂停的行为，仅仅是一个组件的事件对应一个组件的行为测试起来都有超过100个case，更不用说一个组件可以订阅多个事件，排列组合一下case量爆炸，不知道测试同学会怎么处理。
因此这个需求我按照大需求来进行排期。相比于中需求，大需求的技术挑战更大一些，需要细致的技术方案；涉及到的影响面更大，需要完整地评估影响点并进行回归；有更大的代码风险，因此会需求更多的工期来完成需求的开发测试，减小生产风险。特大需求
这类需求很少很少，一般都是如系统重构这类的内部优化项目或是一条业务新开需要从0到1搭建个系统。碰到的比较少，具体情况具体分析。