做最细致的项目跟踪

1.4. 决定任务的优先级

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

案例：

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

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

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

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

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

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

平常Jack还是工作蛮高效的，可是现在事情一多，Jack就不知道自己该优先处理那些任务了。

其实项目中的任务总会多于你的精力和资源。那么怎样完成任务才能把你带向成功呢？的答案就是总是把你手上的任务细分，并排定任务的优先级。

         什么决定任务的优先级？

       在你的手上，可能有很多任务，究竟什么任务是应该优先处理的呢？这是一个普遍的问题。这个问题没有标准答案，但是存在一些判断的原则，只要你掌握这些原则，并且真实地用到你的项目中去，你就会成为一个高效能人人士。传统项目管理中经常应用“重要且紧急，重要但不紧急，不重要但紧急，不重要也不紧急”“四象限原则”来指导个人对事情的处理优先判断准则，但是这比较空洞，具体到软件项目任务，可以参照如下一些判断准则：

       原则1：如果这个任务完成起来非常轻松，所消耗的资源和时间都很少，那么它的优先级要比那些复杂难办的任务要高。

       这个原则其实体现了一种“心理战术”，任务不管大小，完成了总会有或多或少的成就感。这就跟考试答题一样，先易后难往往可以在心理上帮助自己逐步取得胜利的信心。

       原则2：如果这个任务的完成可以使一批任务告一段落，从而取得阶段性的成果，那么它的优先级要比其他的高。

       无论是你自己还是你的领导，都渴望听到成功的消息。优先完成一个任务如果可以把一批任务的状态改为“OK”，这将能鼓舞士气。对于软件项目，士气无疑是许多事情成功的必要条件。

       原则3：如果这个任务是否能够完成，将直接或者间接影响团队中其他人的任务完成，那么这个任务的优先级要高。

       软件项目的成功必定是整个团队共同努力的成功。优先完成被依赖项，可以让整个团队并行工作，从而在整体上取得更好的进度。

       原则4：如果你的上司更在意你这个任务的完成，那么这个任务的优先级要高。

       帮助项目成功也要帮助自己成功。而帮助自己成功了，你的信心、能力也将必然有助于项目的成功。

1.5. 对每个任务进行预期和反查

       任务在分配的同时，或者稍后一段时间，应该给出这个任务完成时间的预期。对于项目成员来说，尽管一开始，要准确预期任务的完成时间非常困难，但是从实践中我们看到，只要整个团队的每个成员都坚持这样做，日久形成了习惯，那么整个项目的任务看起来将比不这样做明朗许多。

       软件开发的最大特点就是非常依赖于成员的工作状态和成员之间的沟通和协调。对任务保持预期的习惯，有利于使整个项目的工作量和工作进度在整个团队保持透明，这是充分调动每个人的积极性，保证整个团队力往一处使的关键。

       谁给任务做预期？

       我一直相信，最了解任务的往往是亲历亲为的设计人员和开发人员，那么任务完成的预期也理应由他们自己给出。我坚信在团队内竖立诚信跟做买卖一样重要，尽管“大胆去相信你的下属吧”，让他们自己决定自己的任务什么时候完成。决定好后，你就只管根据他计划的时间来跟踪即可。

       其实你没有理由相信你的下属会故意拖延任务的完成时间。因为聪明的下属往往总想超乎你的预期去完成任务，以取你的欣赏。只有傻瓜才会故意把自己的任务完成时间做不符合逻辑的拖延。

       让项目成员自己给出任务预期，体现了领导者的充分信任。这种信任其实会成为一种无形的压力。“领导都让我自己预期任务什么时候完成了，如果我到时候没有完成，如何解释得过去？”。

       每日Review

       通过任务预期，管理者和下属之间其实达成了某种时间契约。作为下属，唯一的想法就是按时或者提前完成自己预期的任务。对于管理者，也要重视这个契约，需要积极、按时、细致地去review任务的完成状况。

       敏捷的项目管理由于把任务的粒度细分到天，那么每天都理应对预计完成的任务进

行Review。Review的好处是可以以天为单元控制项目进度的误差，同时让整个团队保持知己知彼的良好沟通状态。

是不是需要时才做review呢？我的建议是最好确定一固定时间来对项目状态进行Review。固定时间，有利于整个团队形成良好的时间观念，这一点非常重要。

       什么时候Review

       Review在什么时候开始呢？这里面也有学问。我的一个同事Yew曾经建议安排在每天早上上班后半小时，并给出了下面的原因：

1.         促使项目成员不迟到

2.         让项目成员在一天的开始即进入紧张的工作状态

3.         强调每个人当前的任务，帮助项目成员明确当天工作目标

4.         给项目成员预留了晚上作为按时完成任务的Buffer

       每日晨会

       一个非常有效的Review制度就是每日晨会。在每日晨会上，项目各成员可以汇报自己的项目进度，工作中所遇到的问题、需要协调的事项等，而项目经理可以检查工作进展，布

置新的工作任务和传达上面新的指示和动态。作为一个团队，让每个成员对项目达成一致的认识，尤其是风险认识是极其必要的。

       晨会的技巧

       我想不会有人怀疑晨会带来的好处，但是会有很多人怀疑这样做是否太浪费时间，得不偿失。这里就涉及到一个晨会的技巧。

首先，我们要认识到晨会的目标是什么？晨会的目标应该是了解昨天的状态和布置今天的任务。记住“昨天”和“今天”两个时间范围。既然我们每天都安排晨会，其目的就是要达到今日事今日毕，不要把任务拖到明天以后。在每日召开的晨会上，我一听到成员谈论非昨天和今天的事情，我就立即让他们打住，“请大家不要越界！”

晨会的时间要尽可能短，这样它的“得”就大于“失”。如何控制晨会的时间呢？这里有几个启发性的意见与大家分享：

1.         让每个人树立时间观念，晨会不迟到，讲话不拖沓，简明扼要。

2.         让每个人在进度汇报上采取一致的方法，比如汇报表格，纸条等。

3.         把晨会的例程固定化，并限定讨论的范围。

4.         严禁讨论具体的技术问题和管理问题

5.         如果可以，请大家都站立发言

6.         让承担独立性任务最强的人优先发言，发言完后即可离开

7.         围绕1，让每个人轮流做组织者，学会控制晨会的时间

让项目成员更有责任感

晨会中最容易出现的就是项目成员任务没完成，在晨会努力为自己寻找各种借口。“我的任务基本完成了，但是还有一个问题没解决”；“我本来可以完成，但是碰巧某某不在，没有他协助所以我没能解决它”；“昨天事情很多，没来得及完成这个任务”。各种借口不一而足。更加可怕的是，项目成员有时候会谎报军情，本来没有完成的任务，谎报自己完成了或者含含糊糊不给你明确的状态。如何解决这样的问题呢？我想这是摆在每个项目经理难题。这里作者也有一点经验与大家分享。

1.         约定汇报的任务只有“完成”，“未完成”两种状态。即使你的任务数量上完成了“99%”也属于“未完成”状态。

2.         如果任务没有完成，要给出合理的解释。请不要告诉我大堆的各种原委，你的解释要求非常简洁。只要在下面的分类中打个勾：

【】客观原因

              【】个人原因

                     【】身体原因

                     【】技术原因

                     【】主观原因

              而上面只有非主观原因是可以接受的。累计这些“延迟事件”，作为对个人的工作考核

3.         每个任务的完成在列表上要标记＂ＯＫ＂，告诉你的成员,你最不希望看到一个任务从“OK”回退到“不OK”。