如何有效的评估工程师的时间进度

今天我在知乎上回答了一个问题《怎么跟工程师沟通时间进度问题？》，回答完之后又思考了很多，觉得有必要总结下如何有效的评估工程师的时间进度？这个问题。

 

1、任务拆解

 

我在这里不论述计划如何制定，只是讨论任务拆解对一个工程师评估工期的重要性。通常情况下，大部分工程师不做任务拆解，也不知道怎么进行拆解。当你问一个工程师这个项目开发要多久时间时，他会告诉你要10天，但是，你并不明白为啥要10天，可能他自己都不清楚为啥要10天，只是凭着以往的经验评估出来的。还有10天不等于10个工作日，这是一个陷阱，一定不要被10天所迷惑到，如果是10个工作日那就代表2周，就是14天了。

 

任务拆解最重要的一步是系统设计，无论你使用何种方式，书面的、口头的、黑板上画，还是很NB的使用UML，你都必须要完成这一步，根据项目需求、应用场景等因素设计系统，将一个大的功能拆解成一个个小的功能。通常我喜欢面向接口的方式来设计系统，这样所有参与项目开发的人员（前端、后端）都是面向接口开发，大家在讨论、沟通时，只需要针对接口的输入、输出以及合理性进行论证，不必关心各自的接口内部实现。当一个大的功能拆解到足够小的粒度时，只针对单个的接口实现进行时间评估，这样会容易很多，得出的时间也会相对的合理。

 

2、沟通

 

在项目开始开发之前，项目人员必须充分的沟通，必须要做到无障碍的沟通，沟通的过程要主动，特别是开发人员。我以往的经历，很多开发人员不会主动的寻求产品、需求、交互人员的帮助，在遇到不合理的需求问题时，不会主动的提出来，等到快开发完成甚至是开发完成才发现这个问题，到那时候可能问题就会严重很多。将项目的信息与参与人员共享，并且做到大家的理解都一致，对于开发人员来说十分重要，不清晰的、错误的需求会直接影响到系统设计的过程，从而导致开发的功能偏差。

 

需求变更一定要慎重，任何一点需求的变更，都可能导致工期变化。通常一个接口定义好并开始开发之后，这时变更需求是存在很大风险的，一个需求的变足以严重得让整个系统回滚到设计阶段。在变更之前，必须充分的与工程师沟通，然后再酌情变更需求。

 

3、合理评估时间

 

想做大合理评估工程师的时间，要充分的了解工程师的作息规律，知道每个工程师每天都在做什么是否重要。通常工程师每天会有一段固定时间在处理相同的事，在这段时间内处理的事情可能包括：

• 处理日常BUG
• 阅读技术文档
• 一小部分的休息时间（刷微博、看知乎等）

在评估一个工程师每天能花费多少时间在项目开发上时，应该除去这部分固定时间。比如，完成项目开发总共需要100小时，工程师每天有3小时固定时间，那么，这个项目的开发周期就是100/(8-3)=20工作日。

 

另外，在项目期间，可能还会有突发状况，比如一些紧急事件的插入，或者工程师请个病假什么的，这些是需要考虑到的风险，一般都会在这个基础上增加1/4至1/3的时间作为一个开发的缓冲期。

 

以上3点如果全部做到，应付一些小项目足够了。对于大型的项目就需要更加充分的系统设计，包括可行性分析、设计文档、技术调研、测试用例等等，项目管理也需要更加专业的人去完成（风险控制也是项目管理中的一部分）。

 

PS：第3条对于艰苦的创业团队不适用。

 

For Example:

 

以我的手机搜狐图库2.0项目为例，推荐你先打开《http://m.sohu.com/p/419214/》看一个图库2.0实现的功能。图库2.0是之前图库1.0的改版，这个项目我并没有参与开发，而是交给另外两个开发人员完成的，我参与到了设计的过程，并制定了后续的开发以及上线计划。

 

当时图库项目启动初期，在与产品、交互人员充分沟通需求之后，我抓住了最重要的一个需求，单击新闻正文页中包含的图片时，打开图库展示大图浏览。但是，正文页浏览大图与图库列表浏览组图的最终页是有功能差异的，为了解决这些功能差异，我将组图浏览的主框架设计成一个核心功能，并以插件的方式加载不同功能组件，实现差异化的显示。最后，为了让正文浏览大图与组图核心功能解耦，我为正文页设计了一个组图适配器，让组图与正文页彼此隔离，组图完全不关心正文页如何使用它，正文页也可以根据本身的需求实现一些组图核心功能意外的特殊功能。

 

在完成了前端设计之后，将所涉及到的接口详细的描述出来，包括：输入、输出以及实现的功能。大家在讨论与工作的时候都是面向接口，彼此对接口负责就可以了。图库2.0总共确认了1个核心功能、6个插件以及1个正文页适配器。对于组图核心功能其实还可以再继续拆解，但是，我觉得已经没必要了，因为这个功能花2天时间就能完成开发。两个开发人员都是新人，并没有太多的JS开发经验，所以会相对比较慢一点，最后和开发人员确认，开发这些功能并完成调试总共需要50个工作时，按每天花费5小时开发，那么需要10工作日，就是2人5个工作日，最后与产品沟通时，我为定为7个工作日交付，预留了2天抗风险时间。

 

最后，这个项目完成得非常顺利。明确的项目需求，开发中只做了一些细节调整并不影响工期。实际上只花费了5天就开发完成，与预估的时间完全一样，按照7天交付，我们还提前2天完成了项目。

 

小结

 

以往经历了很多大大小小的项目，写过正规的设计文档，画过详细的UML，编过完善的测试用例，我觉得这些都不是保证工程师开发进度的必要条件。应当在日常工作中多了解工程师，多沟通，熟悉每个工程师的能力，将项目需求分析完之后做到信息共享，将任务拆解得足够细，并让大家达成一致的项目目标，合理的安排开发时间，最后保证开发进度能按照项目计划进行。

 

最后，和大家分享一篇有意思的文章《几种华丽无比开发方式》。

 

原创文章，转载请注明出处http://zhangdaiping.iteye.com