【IT168 技术文章】

    项目计划告诉了我们要如何去完成项目，但是项目计划的执行并非总能够沿着预定的轨道前进。可以肯定地说，如果没有健全的反馈机制，计划的执行定然会偏离预定的轨道，而唯一能够确避免的措施就——追求项目计划执行中最细致的项目跟踪，在计划的执行稍有偏离的时候就纠正其方向，这在控制理论中，就是基于反馈的控制。

    宏观上来说，重型项目管理方法往往倾向于花更多的时间来作一个细致的项目计划，以确保后期计划执行的可控。但是，细致的计划并不能替代细致的跟踪。

    1.1. 细化任务

　  现代控制理论告诉我们，控制的精确程度是建立在被控制量量化的粒度之上。量化得越细，就能够控制得越精确。因为在很少偏移量的时候这种趋势就得以纠正。但是量化并非没有代价，过细的量化会增加成本，所以这之间存在一个权衡。

    敏捷的项目管理要能做到随机应变，应付各种可能出现的情况，也是建立在对任务的细分，并对任务的状态采取高频度的探测并及时调整的基础上。那么任务究竟要细分到什么程度呢？这并没有确定的度量。不同规模的项目可能都存在不同，但是我的经验告诉你，如果可以的话，让你的任务的工作量尽可能控制在一天以内。

    1.2. 控制任务的粒度
　
　  项目计划的失控往往都是由于项目任务划分不够清晰，粒度过大引起的，我想这是我和很多软件从业者的深刻体会。

    当然，一个常见的反驳意见是“不是我们不想细化任务，而是项目刚开始，很多东西都很模糊，无法把任务划分得很细”。其实这句话中存在两点误解，我想从正面来说明：

    第一， 任务划分与产品的解析度是无关的。

    这里，我杜撰了一个词语“产品的解析度”，用来表达对产品的了解程度。的确，我们对一个产品了解得越多、越细，就越可以把如何完成这个产品的工作任务划分得更加精细。但是反过来，即使一个产品初期对我们来说是模糊的，难道我们的任务就不可以划分得很细吗？其实照样可以。产品从模糊到清晰的过程也是问题分解的过程，每个大问题都可以分解为许多子问题，而对于每一个子问题，其实完全可以对应到相应的子任务。即使我们以“盲人摸象 ”为比喻，要搞清楚大象是什么，也总可以分解为按照头部，身体，四肢，尾巴几个部分分别摸来细分任务。

    第二， 任务划分包含解决问题的思路

    所谓任务，都是为了解决某个具体问题，而如何解决这个问题，从逻辑上我们首先需要把问题分解。问题分解的过程就可以对应到任务划分的过程。比如：如何完成项目目标这个大问题就可以分解为 “如何完成需求定义？”，“如何完成系统设计？”，“如何实现？”，“如何保证质量？”等子问题，而这些子问题又可以进一步细分。那么问题被分解清楚了，任务也就清楚了。

    说到任务的粒度，现实中常看到过于粗陋的做法，比如项目任务分配表一般基于功能模块，最多也就划分到子功能。但是如果单单把这个子功能的实现指派给开发人员，你期望能够在任务指派的第二天了解到什么进度呢？

    任务的粒度要逐步细化，这是建立细致跟踪的必要条件。建议把任务的粒度控制在一天以内。

    1.3. 谁来划分任务？

　  任务的细分并不容易，因为这种细分反应了对求解问题的逐步逻辑分解。所以，划分任务的人必须是对任务真正了解的人，强调这一点非常重要。

    我们常见的错误就是认为项目经理既然是一个项目组的头，工作任务理应由他来进行分配和监控。但是，实际上，我们看到了这种方式带来问题：“项目经理并不了解项目工作的细节！”，“如果项目经理并不了解工作的细节，那么项目任务又如何能够细分呢？”。

    问题来了，“那么你告诉我谁应该划分任务？”，我的答案是：设计师、开发人员等等所有做具体活的主角们。

    没有人比设计师更清楚这个系统具体包括哪些功能模块，每个模块又分成了哪些类和类方法，每个方法的难易程度以及需要消耗的工作时间。没有人比开发人员更清楚还有多少方法目前没有完全实现，还有多少bug等待自己去fix，以及完成这些任务所需要的时间。OK，既然他们最清楚，就理应由他们划分工作任务。因为只有符合实际的任务被划分出来了，我们的跟踪和控制才能施加在点子上。

    问题又来了，“要是他们故意简化任务呢？”。首先，要批评这种怀疑。团队的成员应该相互信任而不是相互堤防，这样团队才能齐心协力走向成功。其次，我告诉你这也是有方法做到的。我们的产品最终要以能够符合需求定义为完成准则，如果以需求定义的清单去检查这些任务的完成，自然就知道每个任务是否在为完成需求定义的产品真正做贡献。

    案例：

    在Milkyway项目中，项目经理Cobo决定让设计师和开发人员共同来完成各自的任务列表清单。首先是设计师根据需求定义清单列出了自己的设计任务清单，并把该清单给需求人员审核，以便及时发现是否漏掉了某些工作。同样，开发人员在明确自己的工作范围并理解设计后，也开出了一份任务列表清单，同样该任务列表也必须通过设计师过目，以便及时发现实现能否覆盖设计。经过上述确认后，Cobo感觉任务列表还是非常明细、丰富而且真实的，即使存在微小的误差，也很容易调整过来。

    1.4. 决定任务的优先级

　  在讨论这个问题前，我给一个实际的案例：

    案例：

    测试部昨天给Jack提交了20个bug，Jack初初看了一下，这些bug可以分为三类：

    第一类是中断性错误，即测试人员在测试中被各种原因所中断，比如抛出异常、无响应，无故退出等等，导致无法继续测试下去。

    第二类是接口错误，由于无法正确获得用户的信息，很多模块都无法正常显示表单创建人。

    第三类是程序内部的验证逻辑错误，比如保存时那些非必录项被报告必须录入。

    除了修复bug，Jack今天还打算向负责控件开发的Daniel写封电子邮件以明确一个自己的一个新需求。因为Jack发现自己的用户管理界面左边的那颗用户树可能需要一个通过键盘可以快速定位的功能。

    当然，上周项目例会上项目经理对单元测试进行走查提出的几个代码问题也需要尽快修改，项目经理已经安排了明天进行复查。

    平常Jack还是工作蛮高效的，可是现在事情一多，Jack就不知道自己该优先处理那些任务了。
   
    其实项目中的任务总会多于你的精力和资源。那么怎样完成任务才能把你带向成功呢？的答案就是总是把你手上的任务细分，并排定任务的优先级。