进度估算

当碰上预估性问题时，作为程序员，你会怎么回答？第一类，项目用时估算：这对于程序员而言，从来不是个陌生的问题，而且每每因此陷入尴尬的窘境。首先，问题条件不明确，因为没有人会将全部影响因素纳入深度分析；其次，任何新特性都有可能直接影响到你此前的代码假设，而结局往往是大面积重构；再者，对于已经完成作业的部分，依然存在需要你时不时费心的附加内容，而在做总时长估算时，又必须要把这段耗时纳入考量；此外，“项目完成”的定义也很模糊，是以“写完代码”为界，还是以“用户使用中”为标，都需要加以明确；最后，即使你对于上述所有可能存在的干扰项都有一个清晰的把握，所谓“程序员的自尊心”也会迫使你给出或是接受比你原有预计值更短的时间，尤其当你感受到来自 deadline 和管理期望值的双重压力时。总体来看，用时预估困惑大多是组织性及文化性问题，显然不是一朝一夕可以解决的，但无论如何复杂，你最终都需要按照要求做出估算，并给出一个期望中的合理数值——这是你工作的一部分，并不能用一句简单的“我不知道”胡乱搪塞过去。但很多程序员对此评论称，这类估算的结果往往是自己会给出一个最终经证实完全无法实现的答案。在《程序员修炼之道》一书中曾谈到过这个高频率问题，书中对此给出的答案是“我稍后回复您”。而在这之后就需要考虑以下几个关键点：

1. 确定你对准确性的要求，根据持续时间的长短，你可以选用不同精度下的估值；
2. 明确问题内容，划定问题范围；
3. 系统建模，其中包括心智模型、图表及现有数据记录，分解这些模型并据此展开估算，算出每个值及其误差范围；
4. 在上一条的结果上进行总体估算；
5. 结果追踪，比对估算值与实际值轨迹；
6. 其他相关因素一并纳入考量，包括规格说明的要求或更改、文档更新、测试、通信、假期及会议消耗等。

业务流程分析，角色流程分析