最近公司要求估出某需求的开发时间，来做成本计算，这是一项费时费力又消磨耐心的工作。因为没有人可以准确估算出开发时间，准确估算开发时间是不可能的。但是可以利用这个机会梳理一下大概的估时逻辑，在实践中逐步迭代，形成一个相对靠谱的估时公式。
前端的日常开发主要工作分为以下四个部分：
- HTML/JSX/Template主要结构搭建
- CSS样式处理/特殊组件UI定制
- 接口/数据处理逻辑编写
- 通用组件，通用Hooks,通用样式产出
估时是一种带有预测性质的行为，整体估时涵盖内容包括： 代码逻辑梳理时间（一般还是放在估时前），开发时间，联调时间，临时加需求点，UI返工时间，常规潜在性需求（加菜单，权限配置，埋点）。
与其说是估算开发时间，不如将这个阶段的工作称之为风险管理，而风险管理的原则是：留点儿余地。
估工时逻辑：
逻辑点种类分为：结构，样式，通用组件，逻辑处理 每个2H。
拆分过程：先按照业务功能拆分为模块，按照以下规则匹配出合适的复杂度。联调，UI整体优化，BUG修改，问题记录和code review时间，在此基础上 * 1.3。
结构
- 复杂度为1
- 有可复用的结构/相似案例
- 1-3个结构模块
- 复杂度为2
- 没有可复用的结构/相似案例
- 3-7个结构模块
- 复杂度为3 及以上
- 7个以上结构模块
- 复杂结构（日程表）
样式/交互
- 复杂度为1
- 1-2个组件的样式定制
- 复杂度为2
- 特效，动画，特殊布局，特殊交互
- 2-4个组件的样式定制
- 复杂度为3及以上
- 4个组件以上的样式定制
- 基于已有组件库复杂组件的样式修改和重构
- 精细化定制组件（日程表） 通用组件/HOOKS（复杂度在于设计工作）
通用组件
- 复杂度为1
- 单个业务场景
- UI组件
- 复杂度为2
- 2个业务场景
- 复杂度为3 及以上
- 3个业务场景，或有需要编写技术文档
业务逻辑处理
- 复杂度为1
- 对接1-2个接口
- 复杂度为2
- 对接2-4个接口
- 旧业务重构 / 修改（理解成本）
- 复杂度为3 及以上
- 对接4个接口以上
- 数据处理（复合数据校验，本地持久化） / DOM操作（显隐，拖拽排序）
以下是估时参考文章：
估时前要做充足的需求分析和技术预研。
一、需求分析 产品经理提出的需求可能不是很正确，这个时候需要工程师进行辅助，原因如下：
1、产品经理可能对技术的边界不是很了解，所以无法充分利用技术解决用户需求。优秀的产品经理是需要有技术广度的，他不一定要深入了解技术的原理，但一定要理解技术的边界。某个技术能做什么，不能做什么，最近是不是又有新技术了，和我的产品有关系吗？ 2、对用户原始需求的理解是很难传递的。很多时候，产品只是发了个产品文档过来，然后就拉着技术做“需求评审”，但其实这份需求文档，是产品经理对用户需求理解的二次加工。工程师在这份需求文档里是很难看清用户的原始需求的。 3、产品经理对用户需求的理解有误。有时候用户反馈需求，或者产品经理在推测用户想要什么的时候，往往得到的答案是不正确的。因为有时候用户自己也不知道他需要什么。有一句名言非常有名：你如果问用户想要什么，他的回答是“一匹更快的马”，而不是汽车。所以工程师要理解用户的原始需求，并且有自己的看法，这样不光可以给产品经理提出建设性意见，并且还可以对技术方案进行“预判”，如何设计项目的架构？最重要的就是要对产品未来的发展方向进行“预判”，一方面要对未来的改动 “做足准备”，另一方面也要避免 “过度设计”。
总之需求分析不是简单的听一听产品经理提的需求，评估下开发可行性和难度，把实现不了的需求砍掉。而是去理解用户的原始需求，和产品经理成为“搭档”，在产品经理因为缺乏技术广度或其他原因导致提出坏需求时，给出提醒并提供建设性意见。
二、开发时间评估 所有前端项目开发，所有的界面都遵从着结构+表现+行为的三大组成原则。
结构指的是一个界面的整体骨架（HTML），从结构中，我们能看到这个界面的所有组件元素，如果是h5项目，那么标签便是界面的结构组成基本单位，如果是react项目，那么等组件便是界面的结构组成基本单位。
表现指的是界面结构的具体样式展现（CSS），加上表现，我们便能确定这个界面最终的静态呈现是什么样的，例如设置字体的大小颜色、设置按钮的样式、实现一个动效。
行为指的是这个界面功能动态实现（JS），例如列表的数据请求并渲染、按钮点击事件地响应处理等。
如何合理分解Task？ 1、合理分解目的 有利于任务的分配，让不同的开发人员负责各自擅长的事，优化资源利用 有利于前端项目的整体进度及风险把控 让开发人员在开发的时候更聚焦，不会东做一点西做一点 当遇到依赖不能及时提供时，可以暂时搁置，不影响其他Task的开发 当前端项目出现风险时，协调资源，分担Task，解决项目风险 2、合理分解原则 不同团队在Task分解上可能存在差异，但应统一保持一些通用原则。
以界面作为基本单位 遵从结构+表现+行为的原则 保持对前端开发中的其他依赖进行解耦 3、分解方式 具体的分解方式是为了让前端项目管理者及业务开发者在项目开发中对功能点分解达成一致。分解的粒度要保持适中，不能过粗也不能过细。如果太粗的话，在项目开始前，不利于项目的任务分配，在开发中，不利于观察项目的进度和状态。如果太细的话，则会增大项目管理者及业务开发者对Task的管理成本，反而会影响到具体的开发任务。
按照前端的特性，我是按照一个界面（由结构+表现+行为组成个体）为基本单位来进行Task划分。
- 对一个界面来说，先以界面的静态呈现为一个维度来进行划分，将结构+表现的实现作为一个Task，如果界面有交互效果实现，则将交互效果的实现作为一个Task。
- 然后以界面的行为实现为一个维度来进行划分，将该界面的前端业务功能实现作为一个Task，将接口联调作为一个Task，如果还有第三方依赖，例如跨平台应用开发，需要原生提供相应功能，则将第三方依赖作为一个Task。这里明显用户交互比较多，或者业务有明确拓展方向以及可复用场景，需要加入额外时间进行通用化设计。
- 考虑到可能的学习曲线，特别是当涉及到新技术或工具时。
- 如果该过程中可以产出通用的组件/hook，则将通用组件/hook作为一个Task。如果该组件需要一些理解成本，还需要编写对应的文档。
三、风险控制 风险控制的思想是我知道自己评估的工作日不准，那么为了应对各种意料之外的事发生，我需要安排一些额外的时间来以备不测。
常见的风险如下：
需求熟悉时间以及代码定位（尽量减少大量时间找代码，少数时间修代码的场景，也能避免改错位置） 前后端联调以及ui矫正（一般联调是比较占时间，字段不一致、各种场景、联调高效性、来回验证、产品以及ui的校验效果）
如果视觉设计师、交互设计师给出的内容不够细致，就会有大量的UI上的返工，而且可能出现设计的交付晚于预期的情况，这种种因素势必会对前端开发工作的进行造成影响。
等待时间以及产品确定时间（某些不确定需求商榷时间，团队成员时间空档不一致）
预估时一定要计算一下参加会议的时间，把这些时间刨除在有效时间之外。各种开会，和pm讨论问题，code review。杂七杂八的算下来，每天真正编码的时间没想像的多，按每天8小时算排期，评估每天实际开发的时间。 Buffer 时间（开发完成自测之后，需要对开发阶段暴露的问题进行记录甚至项目中统一优化，避免下个阶段的问题重现，个人时间的缓冲期，做下个阶段的预研以及本阶段可能遗留问题的方案的研究。）
下面提供我的评估的方法：
1.如果能够大致评估自己的开发时间，可以用下面的方法：
需求非常明确而且经常这样做：评估的工作日1.5 需求不清晰，有可能变，但代码和技术方案熟悉：评估的工作日2 需求不清晰，代码和技术方案也不熟悉需要探索：评估的时间*2.5 2、如果连不准确的开发时间都评估不出来，上面的方案不就失效了，那怎么办？
还有一个非常简单粗暴的方法：可以把需求难度分为三个等级：简单、中等、困难。
简单需求：需要23个有效工作日 中等需求：需要23周 困难需求：需要2~3个月
四、小结 涉及前端交互，实现细节要足够细化，不要开发阶段去确认细化。 报风险时间置前，如果开发开始或者任何过程有可能导致项目延期或者需求无法实现的时候就报警，不要等加班能实现或者存在侥幸心理。 根据实际得到的信息来决定估算的粒度，是精细一些还是粗略一些。 尽量提供工时、工期、评估说明等内容。然后找leader沟通确认。 精细评估的时候要做工作分解，加一些buffer。 平时多记录自己的工作情况，比如一个功能耗费了多少开发时间，耗费了多少优化时间，平均每天编码的真实时间有多长等等。 每个程序员都会用到评估技巧。为了提高你的这项技能，你可以在你从事的每个任务上进行锻炼。在任务开始时先预估开发所需时间，拿它跟你最终真正用掉的时间进行对比。这样，你不仅在对任务细节的理解上有提高，同时也提高了你对时间预估的技能。 当一个功能点交互可以做的很简单也可能很复杂，但是无法预知时，可以试着通过增加评估说明来缓解一下。这样大家会了解你是基于哪种前提做的评估，功能会有哪些风向，如果leader觉得你理解有错会纠正你的。如果到了开发阶段发现工期真的出了问题，你也可以拿出原来的说明来证明这并不是你的原因。所以提供评估说明，可以增进彼此的沟通，方便统一对功能的理解，即便是项目执行时出了问题，你也有一些证据能够捍卫自己的权利，同时也能为总结项目经验留下宝贵的记录和数据。
一个页面中包含的交互元素越多，则页面开发越复杂。
组件化程度越高越简单。
开发者的因素
由于主题是“页面复杂度”，应该是页面本身的属性而与开发者无关，所以没有列入三大原则之中。但如果回归到现实需求中，开发者实在是无法绕开的一个关键因素。
- 开发者综合素质。除了技术实力之外，还有沟通能力、需求理解能力、责任心等，这些大家工作中已经有很多感触，就不再赘述。
- 开发者对业务的熟悉程度。这一点尤为重要，也是容易忽视的一点。有时候会出现这样的情况，同样的一个需求，小A只需要1天搞定，小B则需要3、4天，很有可能是因为小A一直是这块业务的开发者，而小B刚刚接手这块业务。由于代码本身的强逻辑性特征，哪怕同一个开发者去读自己三个月前写的代码，即使是最简单的一段几百行的代码，也很有可能不太记得其中的逻辑。对接手新业务的开发者来说，要读懂前人的几千行甚至是上万行代码绝对是非常艰巨的任务，会需要更多的时间和精力。
