新年伊始，反思自已的工作，总结了项目日程及费用评估经验。这几年做了不少项目日程及费用的评估工作，在日程上有近 70% 达到预期目标，当然还有一部是因为涉及多方联调引起的延误，如设备端或后端的不确定性。
一、引言
一个项目负责人能否精确评估开发时间，是一件非常重要的事情。评估人至少需要以下几点：
- 对需求很了解
- 对技术了解或者本身就是一名合格的工程师
- 靠谱
- 经验丰富
项目启动之前，所要进行的工作有：
- 可行性分析
- 日程评估
- 费用评估
如果没有经过上述三步骤，那在项目执行的过程中可能出现不断挖坑填坑的局面，项目的结项是遥遥无期！
二、日程评估
日程评估即是给每个阶段定下小目标，然后按规划好的日程去跟进、推动，虽然不一定非常准确，但至少做到有迹可循。
2.1 日程评估的重要性
在一个项目中，所有的环节都是承上启下的，上一个环节结束的时间节点正是下一个环节开始的节点。那么在一个项目或者一次迭代正式启动前，所有的环节都应该有个时间评估。根据项目计划，各个部门自己要分配人员和时间。如果其中一个环节延期了，那么后面的各个环节都要顺延，就会造成损失。
对于程序员来说，一个清晰的开发计划有助于自己有条不紊地开展工作，也能避免疏漏某个功能点。评估时间的过程，也是对需求详细拆分的过程，了解要做什么，做成什么样子。在评估的过程中，根据专业知识和经验，充分预估会遇到的风险，怎样的解决方案，预留多少时间？都想好了的话，项目也就没啥风险了。
然而，开发时间评估，最大的好处是程序员受益。认真地评估开发时间，会让你在开始动手写代码之前搞清楚要怎么写，每个模块的设计心理得有个谱。从宏观上拆分模块，然后详细地分解任务，具体到一个很小的功能点。这样你就能清晰地设计代码，而不是堆代码。也避免了很多时候写着写着发现不对，然后拉到重来的境地。就是要让你动手写代码之前胸有成竹！
2.2 为什么评估不准
如果项目经常 Delay，那么大概率是时间评估不准。有时并不是工作量评估的不准，而是没考虑其他任务的介入。
有个典故:
刚毕业的学生被问到什么时候可以完成的时候，脑门一拍：“三天”，但两个星期过去了还没完成。
修改一行代码可能只需要1分钟，但之后还要打包，测试等一系列流程下来，估计 2 - 3 个小时就过去了，这里只考虑功能正常的情况，也经常出现，明明只修改某个功能并不会影响其他功能，但实际上就是影响到了，这样的时间就更长了。还可能碰到技术难点等，这些都是需要考虑到的。
根据自已的经验评估： 日程 = 正常工作量 * 2 或 3
三、如何精确评估开发时间
最近几年，大都是以天为单位进行日程评估的，个别项目甚至以小时为单位评估日程，长期以来这样的习惯让我收获颇多。
3.1 任务拆分
拿到新需求后，对其进行充分了解，不清楚的就弄清楚（整理疑问点找客户确认），然后对其进行模块化。之后，再进行技术上的拆分。由大到小，再到细节。这个能力是需要锻炼的，做好拆分，然后在实际开发过程中根据实际时间花销，回顾时间评估的准确性，以便下次更准确。慢慢地，就会越来越精确，评估日程有依有据，不再是拍脑门给出的日程。
3.2 合理认知时间
一天工作八小时，但不可能专注地连续八小时在编写代码。一天的工作中，有开会、讨论、阶段性休息（刷新闻、发呆等）的时间开销，真正有效时间其实不足六小时，杂事多的话可能是四、五个小时。
3.3 预留周转时间
预留周转时间不是随便增加预估量，而是要明确知道周转时间是给那些事情用的。一般用到以下几点：
- 首先是沟通时间，开发的时候不可能是闷着头一直写代码。要和 UI 设计师沟通，要和产品经理沟通，有可能还需要和组内的人沟通技术上的事情，以及和别的技术小组对接的问题
-
等待时间，如果牵扯多部门协作，会有很多等待时间，因为不能保证别的部门就能准确按照计划时间完成的。虽然等待过程中可以安排其他任务，但不能保证其他任务就能刚好填充等待时间，更何况任务切换也需要时间成本
-
突发状况，例如，Bug 修改、需求微调、对接人请假
-
不确定时间。和其他部门有交集的工作，最好多预留周转时间。比如移动端和后台联调。你请求第一个接口就报错了，然后在即时通讯软件上问他们怎么回事，半个小时后给你回了“不好意思，地址变了，你用这个试试”，又错了……，终于回来数据了，然后发现缺少两个字段……，就这样下去
以上是可能会出现的状况，实际中有可能只是出现了一部分，这要根据实际情况而定。并不是让你能多预留周转时间就多留，毕竟每个项目的时间都是很紧张的。一般周转时间留在20%左右。
四、费用评估
谈项目签合同要评估费用，便项目还没开始，所以需要估算，估多了，客户不满意；估少了，自家的亏了，老板有意见。那么费用的评估依据是什么？当然是日程了。
总费用 = 项目经理投入的日程 * 项目经理的平均日工资
+ 产品经理投入的日程 * 产品经理的平均日工资
+ UI 设计人员投入的日程 * UI 设计人员的平均日工资
+ APP 开发人员投入的日程 * APP 开发人员的平均日工资
+ 测试人员投入的日程 * 测试人员的平均日工资
+ 15% 的项目管理费
在实际开发过程中，测量实际花费时间，并与估算相比较。如果有些地方相差较大，就要看差在哪里，然后在下次预估中避免相同的差错。
五、总结
作为软件开发出身的我，也体会到编程经验不等同于估算经验。一个不被包含在估算流程中的开发者将不会擅长估算。同样，如果实际的时间花费不被测量和用于与估算比较，那么将没有反馈来学习。
尽管进行了精确估算，也不能保证每个项目都会 100% 精确。偶尔会遇到一些突发情况和没预估到的风险是不可避免的。那么面对风险，还是有一些原则可以遵循的：
- 报风险时间置前，如果开发开始或者任何过程有可能导致项目延期或者需求无法实现的时候就报警，不要等加班能实现或者存在侥幸心理
-
对于不确定的需求，一定要沟通到位
-
涉及到交互细节，必须提前沟通好，充分明确细节
大项目会根据客户要求，拆解模块，然后让开发人员挑选，并给予三天的时间对 UI 及技术点进行分析和日程评估，最后再根据每个人的情况做总结；对于单个 APP 项目，根据客户的要求，会花 2 - 3 天做技术可行性分析、日程评估、费用评估。