前端该如何评估开发时间

一、需求分析

产品经理提出的需求可能不是很正确，这个时候需要工程师进行辅助，原因如下：

1、产品经理可能对技术的边界不是很了解，所以无法充分利用技术解决用户需求。优秀的产品经理是需要有技术广度的，他不一定要深入了解技术的原理，但一定要理解技术的边界。某个技术能做什么，不能做什么，最近是不是又有新技术了，和我的产品有关系吗？
2、对用户原始需求的理解是很难传递的。很多时候，产品只是发了个产品文档过来，然后就拉着技术做“需求评审”，但其实这份需求文档，是产品经理对用户需求理解的二次加工。工程师在这份需求文档里是很难看清用户的原始需求的。
3、产品经理对用户需求的理解有误。有时候用户反馈需求，或者产品经理在推测用户想要什么的时候，往往得到的答案是不正确的。因为有时候用户自己也不知道他需要什么。有一句名言非常有名：你如果问用户想要什么，他的回答是“一匹更快的马”，而不是汽车。所以工程师要理解用户的原始需求，并且有自己的看法，这样不光可以给产品经理提出建设性意见，并且还可以对技术方案进行“预判”，如何设计项目的架构？最重要的就是要对产品未来的发展方向进行“预判”，一方面要对未来的改动 “做足准备”，另一方面也要避免 “过度设计”。

总之需求分析不是简单的听一听产品经理提的需求，评估下开发可行性和难度，把实现不了的需求砍掉。而是去理解用户的原始需求，和产品经理成为“搭档”，在产品经理因为缺乏技术广度或其他原因导致提出坏需求时，给出提醒并提供建设性意见。

二、开发时间评估

所有前端项目开发，所有的界面都遵从着结构+表现+行为的三大组成原则。

结构指的是一个界面的整体骨架（HTML），从结构中，我们能看到这个界面的所有组件元素，如果是h5项目，那么标签便是界面的结构组成基本单位，如果是react项目，那么等组件便是界面的结构组成基本单位。

表现指的是界面结构的具体样式展现（CSS），加上表现，我们便能确定这个界面最终的静态呈现是什么样的，例如设置字体的大小颜色、设置按钮的样式、实现一个动效。

行为指的是这个界面功能动态实现（JS），例如列表的数据请求并渲染、按钮点击事件地响应处理等。

如何合理分解Task？

1、合理分解目的

• 有利于任务的分配，让不同的开发人员负责各自擅长的事，优化资源利用
• 有利于前端项目的整体进度及风险把控
• 让开发人员在开发的时候更聚焦，不会东做一点西做一点
• 当遇到依赖不能及时提供时，可以暂时搁置，不影响其他Task的开发
• 当前端项目出现风险时，协调资源，分担Task，解决项目风险

2、合理分解原则

不同团队在Task分解上可能存在差异，但应统一保持一些通用原则。

• 以界面作为基本单位
• 遵从结构+表现+行为的原则
• 保持对前端开发中的其他依赖进行解耦

3、分解方式

具体的分解方式是为了让前端项目管理者及业务开发者在项目开发中对功能点分解达成一致。分解的粒度要保持适中，不能过粗也不能过细。如果太粗的话，在项目开始前，不利于项目的任务分配，在开发中，不利于观察项目的进度和状态。如果太细的话，则会增大项目管理者及业务开发者对Task的管理成本，反而会影响到具体的开发任务。

按照前端的特性，我是按照一个界面（由结构+表现+行为组成个体）为基本单位来进行Task划分。

1、对一个界面来说，先以界面的静态呈现为一个维度来进行划分，将结构+表现的实现作为一个Task，如果界面有交互效果实现，则将交互效果的实现作为一个Task。

2、然后以界面的行为实现为一个维度来进行划分，将该界面的前端业务功能实现作为一个Task，将接口联调作为一个Task，如果还有第三方依赖，例如跨平台应用开发，需要原生提供相应功能，则将第三方依赖作为一个Task。

三、风险控制

风险控制的思想是我知道自己评估的工作日不准，那么为了应对各种意料之外的事发生，我需要安排一些额外的时间来以备不测。

常见的风险如下：

• 需求熟悉时间以及代码定位（尽量减少大量时间找代码，少数时间修代码的场景，也能避免改错位置）
• 前后端联调以及ui矫正（一般联调是比较占时间，字段不一致、各种场景、联调高效性、来回验证、产品以及ui的校验效果）
• 等待时间以及产品确定时间（某些不确定需求商榷时间，团队成员时间空档不一致）
• Buffer 时间（开发完成自测之后，需要对开发阶段暴露的问题进行记录甚至项目中统一优化，避免下个阶段的问题重现，个人时间的缓冲期，做下个阶段的预研以及本阶段可能遗留问题的方案的研究。）

下面提供我的评估的方法：

1.如果能够大致评估自己的开发时间，可以用下面的方法：

• 需求非常明确而且经常这样做：评估的工作日*1.5
• 需求不清晰，有可能变，但代码和技术方案熟悉：评估的工作日*2
• 需求不清晰，代码和技术方案也不熟悉需要探索：评估的时间*2.5

2、如果连不准确的开发时间都评估不出来，上面的方案不就失效了，那怎么办？

还有一个非常简单粗暴的方法：可以把需求难度分为三个等级：简单、中等、困难。

• 简单需求：需要2~3个有效工作日
• 中等需求：需要2~3周
• 困难需求：需要2~3个月

四、小结

• 涉及前端交互，实现细节要足够细化，不要开发阶段去确认细化。
• 报风险时间置前，如果开发开始或者任何过程有可能导致项目延期或者需求无法实现的时候就报警，不要等加班能实现或者存在侥幸心理。
• 根据实际得到的信息来决定估算的粒度，是精细一些还是粗略一些。
• 尽量提供工时、工期、评估说明等内容。然后找leader沟通确认。
• 精细评估的时候要做工作分解，加一些buffer。
• 平时多记录自己的工作情况，比如一个功能耗费了多少开发时间，耗费了多少优化时间，平均每天编码的真实时间有多长等等。
• 每个程序员都会用到评估技巧。为了提高你的这项技能，你可以在你从事的每个任务上进行锻炼。在任务开始时先预估开发所需时间，拿它跟你最终真正用掉的时间进行对比。这样，你不仅在对任务细节的理解上有提高，同时也提高了你对时间预估的技能。
• 当一个功能点交互可以做的很简单也可能很复杂，但是无法预知时，可以试着通过增加评估说明来缓解一下。这样大家会了解你是基于哪种前提做的评估，功能会有哪些风向，如果leader觉得你理解有错会纠正你的。如果到了开发阶段发现工期真的出了问题，你也可以拿出原来的说明来证明这并不是你的原因。所以提供评估说明，可以增进彼此的沟通，方便统一对功能的理解，即便是项目执行时出了问题，你也有一些证据能够捍卫自己的权利，同时也能为总结项目经验留下宝贵的记录和数据。