blog

# 如何正确的评估开发时间

# 结论

没有人可以准确估算出开发时间，准确估算开发时间几乎不可能的

# 为什么

比如aigle项目的拉新需求评估5个工作日，但实际开发需要8个工作日。 因为每天不一定一整天都在开发，还会去开会和处理其他杂事（例如 前后端联调/确认需求点）

# 原因

一般情况下我们评估的是直接开发时间，而且还是顺利的，都了解需求，没有问题和阻碍的情况下。实际上呢，这种非常顺利的场景基本上很少。

# 部分时间未考虑进去

除了正常评估的时间还需要有些时间要添加到评估中

  1. 熟悉需求，以及代码的时间

理由：由于公司的业务的特殊性会经常出现借调人员，投入到另一个的项目中去，这时候就会出现借调人员需要熟悉代码，原项目的人要辅助借调人员，两类人都要花费时间

时间占比：20%～50%

  1. UI调整及前后端联调

理由：一般是联调比较占时间，字段不一致，各种场景，联调来回验证等。但也有特殊情况例如apple项目重视ui体验

时间占比：20%～50%

  1. 需求不确定的

理由：某些不确定的需求，这个根据情况进行分析

时间占比：20%～40%

  1. 自测时间&优化时间

理由：自测时间是为了减轻测试的压力以及估时，使得后续链路稳定。完成自测后，需要提对开发阶段暴露的问题进行记录和优化，避免下次重现。

时间占比：20%～30%

  1. 个人缓冲时间

理由：生病/请假等不可预料的

时间占比： 10%

  1. 被甲方压缩工时

理由：交付的特色 已在顾家项目中遇到

时间占比：20%～30%

综合起来看 一个项目至少要预留50%时间，这个50%的前提是，没有风险/不确定需求/团队没有不熟悉的情况。如果都有，建议将评估改为： 200%～250%，以保证项目的进行顺利

如果觉得估时太长，可以将需求细化，比如一个模块你真实需要1小时完成，你写成1.5小时可以吧，2个小时也没问题吧。细化后的操作空间很大的

最终的结果是让评估的时间具有可参考性

# 技术方案没有

一般情况下，需求评审都会有一次详细的评审，需求评审结束或者过程中进行技术分析。但大多数情况下，给技术评审的时间非常短（甚至没有），而且缺少业务场景条件，更坏的情况是，产品及技术没有响应的备案一般，这样就导致技术可行方案给的很粗糙，就说可行，因为看见过或者感觉可行，没有代码实践过；或者说不行，但没尝试过具体方案

另外一个问题就是整个技术团队没有技术架构或者成系统性的技术方案，大多数都是去百度

这些问题，需要产品在提出需求之前给技术去做技术预先研究，，研究后在添加到项目中；作为长期规划，技术方案应该有文档沉淀以及维护，并宣讲。

其它要注意的：

  1. 切记事后反馈 （比如遇到没有做过的功能，无法给出具体方案，建议将问题前置）
  2. ued一般都会涉及到交互，实现细节一定要细化，千万不要开发阶段去确认
  3. 如果开发的任何过程中有可能导致项目延期或者无法实现的时候及时向上沟通

# 风险管理

既然结论是评估的时间根本不准，那就不评估了么？和产品经理说我不知道需要多久，开发完了我再找你？肯定不行，产品经理一定会要一个开发时间，必须得给一个，哪怕不准。 既然开发时间是无法准确评估的，而我们又必须给一个开发时间，那么我们要做的事就不再是如何评估开发时间了，而是变成了“风险管理”。

# 风险管理

风险管理最常用的方法叫：留点余地。

# 评估技巧

# 评估开发时间的重要性

首先，在一个项目中，所有的环节都是承上启下的，上一个环节结束的时间节点正是下一个环节开始的节点。那么在一个项目或者一次迭代正式启动前，所有的环节都应该有个时间评估。以一次APP需求迭代为例，项目计划像这样：

  1. UI设计图 11.01 - 11.03（3工作日）
  2. API接口讨论与设计 11.04（1工作日）
  3. 移动端开发 11.05 - 11.15（8工作日）
  4. 后端具备联调条件：11.11
  5. 产品体验 11.16 - 11.17（2工作日）
  6. 测试11.18 - 11.25（5工作日）
  7. 发布11.26

根据项目计划，各个部门自己要分配人员和时间。如果其中一个环节延期了，那么后面的各个环节都要顺延，就会造成损失。

其次，对于程序员来说，一个清晰的开发计划有助于自己有条不紊地开展工作，也能避免疏漏某个功能点。评估时间的过程，也是对需求详细拆分的过程，了解要做什么，做成什么样子。

在评估的过程中，根据专业知识和经验，充分预估会遇到的风险，怎样的解决方案，预留多少时间？都想好了的话，项目也就没啥风险了。

然而，开发时间评估，最大的好处是程序员受益。认真地评估开发时间，会让你在开始动手写代码之前搞清楚要怎么写，每个模块的设计心理得有个谱。从宏观上拆分模块，然后详细地分解任务，具体到一个很小的功能点。

这样你就能清晰地设计代码，而不是堆代码。也避免了很多时候写着写着发现不对，然后拉到重来的境地。就是要让你动手写代码之前胸有成竹！

# 初学者为什么评估不准

估算时间 程序员所想象的 程序员所忘记的 实际时间
30s 只需要做一个很小的代码改动。我准确的知道怎么改，在哪里改。花费30s敲键盘即可 启动电脑，开发环境和获取正确源码时间。用于构建，测试，检查和文档修复的时间 1小时
5分钟 小事一桩，我只需要上google查一下语法就可以修复它了 很少有一次就成找到完全正确的信息。即使找到，在它能工作前，也需要做一些调整。外加构建，测试等时间 2小时
1小时 我知道怎么做，但是写这些代码需要花费一些时间。 面对未来可能发生的问题，1小时稍纵即逝。有些东西总会出错的 4小时
4小时 需要写一些代码，但我是粗略的知道步骤。我知道标准框架中的xxx模块可以做到，不过我需要查文档，了解准确的使用方式。 这个大概是比较真实的估算。它的意外的错误不多，任务也足够小到足以把握 4小时
8小时 我先要把xxx类重构成2个，然后在xxx模块做一些改动，最后再添加一些字段 总会有许多系统的不同部分依赖着xxx类，假设大概40个不同的文件需要修改。添加字段也是需要后端配合的。 8小时太长，无法完全把握。总会有比估时更多的步骤出现 12-16小时
2天 真的有一大堆代码要写。我需要往页面添加一些新的组件，还有一些业务逻辑 对于大多数开发者来说，两天的工作量已经大到难以估算了，可定会有什么东西被遗忘掉。不仅仅是一些小事情，而是整个一大块功能会被遗忘在估算中 5天
一周 哎哟，这真是一项艰巨的任务。虽然我还没有思路，但我不能说我不知道。一周应该够了，我信网，我真心希望，但是我不能要求更多了，否则他们会认为我不够称职 这个任务已经大到超过大多数程序猿的理解了，它应该被发回给架构师，帮忙划分更小的部分，然后提供一些解决问题的方向。架构师可能会发现一种更简单的方法来完成它，或者发现其实有更多超乎想象的工作 2-20天

# 如何精确评估开发时间

核心：细化

  1. 任务拆分

拿到新需求后，对其进行充分了解，不清楚的就去问清楚，然后对其进行模块化。之后，再进行技术上的拆分。由大到小，再到细节。细到什么程度呢？细到一个按钮的实现，细到一个点击动作是要用按钮还是要用手势的定夺，最好能细到代码块的划分。

这个能力是需要锻炼的，做好拆分，然后在实际开发过程中根据实际时间花销，回顾时间评估的准确性，以便让下次更准确。慢慢地，就会越来越精确，评估时间有依有据，不再是拍脑门给出的时间。下面看一个例子：

  • 功能：右侧悬浮窗功能
    • 右侧栏的展示 8小时 （浮窗展示方法需要调研）
    • 右侧栏的逻辑和接口规划 15小时（历史未读消息/新消息/接口封装）
    • 点击右侧栏滚动到相应位置 12小时 （目前listView 不支持滚动到某一条，精确滚动到指定位置的方案还需要确认）
    • 进入聊天室根据未度数获取消息条数 4小时 为历史消息定位做数据准备
  1. 合理认知时间

一天工作八小时，但你不可能专注地连续八小时在编写代码。一天的工作中，有开会、讨论、阶段性休息（刷新闻、喝咖啡、发呆）的时间开销，真正有效时间其实不足六小时，杂事多的话可能是四五个小时。

  1. 预留buffer（缓冲区）

首先明确，预留buffer不是让你随便增加预估量，而是要明确知道buffer是给那些事情用的。要考虑到一下几点：

首先是沟通时间，你开发的时候不可能是闷着头一直写代码。要和UI设计师沟通，要和产品经理沟通，有可能还需要和组内的人沟通技术上的事情，以及和别的技术小组对接的问题。

等待时间。如果牵扯多部门协作，会有很多等待时间，因为你不能保证别的部门就能准确按照计划时间完成的。虽然等待过程中你可以安排其他任务，但你不能保证其他任务就能刚好填充等待时间，更何况任务切换也需要时间成本。

突发状况。例如，bug修改、需求微调、对接人请假。

不确定时间。和其他部门有交集的工作，最好多预留buffer。比如移动端和后台联调。后端信誓旦旦给你说11.11号可以进行联调，这次联调总共5个接口。如果你简单地认为他们给你提供的接口没问题，并且能顺利请求回来数据，预计一天联调时间足以，那你就等着delay吧。11.10号你已经准备好了所有联调准备，如果数据能正确返回，你的解析功能都是OK的，因为你之前用假数据已经处理的好好的。到了11号，你请求第一个接口就报错了，然后在即时通讯软件上问他们怎么回事，半个小时后给你回了“不好意思，地址变了，你用这个试试”。又错了……。终于回来数据了，然后发现缺少两个字段……。就这样，第一个接口调通已经快下班了。（当然很多后端技术人员也是很靠谱的，举这个例子只是为了让多考虑）

以上是可能会出现的状况，实际中有可能只是出现了一部分，这要根据实际情况而定。并不是让你能多预留buffer就多留，毕竟每个项目的时间都是很紧张的。一般buffer留在15%-25%。

  1. 回头看（复盘）

在实际开发过程中，测量实际花费时间，并与估算相比较。如果有些地方相差较大，就要看差在哪里，然后在下次预估中避免相同的差错。

# 其它

需求分析与开发时间评估 (opens new window)

技术管理 →