迭代模式的最终总结(10)where you are?(转)

其实做一个项目经理真不是一个好的职业，它需要太多的千锤百炼才能修炼出来。这不仅需要反复经历“失败-总结-再失败”的轮回，而且需要有一颗无比坚强的心，能够在无数次经历无比艰难并且令人沮丧的时刻而能坚持不懈、毫不气馁。一个项目经理就像一位将军。将军百战死，而项目经理呢，经历无数项目以后沉淀下来的，更多的是疲惫与沧桑。 但凡一个好的项目经理都是要经过一次又一次项目失败的教训，似乎只有失败才能留给他们更深刻的教训与更巨大的提升。当然，这种失败可大可小。即使一些项目最终是成功了，也只是结果的成功，而项目进行过程中的失误，以及因此带来的成本的提高，过程的曲折，同样是一种失败。项目管理之难，作项目经理之难可见一斑。 项目管理之难，其真正的难处就在于，要将其做好，需要注意的地方实在太多。任何一个方面没有做好，都会造成项目的失败。文章之初提出的软件开发的风险，实质就是软件需求的风险，在项目管理中就是需求管理。需求管理的失败是大多数项目失败的根本原因，这其中包括需求理解的准确性、需求变更的管理，等等。这篇文章讨论迭代式开发，就是给大家需求管理带来一种思路。 而另一个非常重要的方面就是项目进度管理。当项目计划制订出来以后，就必须按照项目计划进行，任何的项目延期都会是一种巨大的风险。如何避免项目延期，是项目成功的关键因素。作为项目经理，如何避免项目延期呢？那就是在项目进行的任何时刻都要清楚地知道“where you are”，让用户清楚地知道“where you are”。 where you are，对于我们来说就是项目进行到什么程度了。我们要随时问我们这个问题，随时评估项目进度的偏差，及时进行调整，才可能使项目如期交付。如何做到这一点呢？我们制订了详细的项目计划，计划中将每一项工作的进行时间都制订出来。这个计划就是我们的航标，将计划与进度比较，就可以随时清楚项目进度的偏差。同时，制作Burn-Down Table，随时关注还有多少工作没有完成，还剩多少时间，就可以从另一个角度直观地认识项目的进度。 当需求发生变更时，必然造成工作量的增加。重新调整我们的项目计划，就如同重新调整我们的航线。这还包括重新调整我们的人员、我们的分工，以及我们的工期，使其符合实际情况。然后我们就可以按照新的航线前进了（以往很多项目的失败，正是因为发生变更以后还是按照原有的航线前进，其风险可想而知）。 完成项目计划修改的同时，不要忘了我们的Burn-Down Table。我们要重新评估我们的剩余工作量和剩余时间，绘制到当前的时间上。只有这样，我们才能随时知道“where you are”，才能有效地监控项目进程。 那么，为什么要让用户清楚地知道“where you are”呢？一个软件项目的进行其实不光是我们自己的事情，也是客户的事情。项目一旦进行，其实客户与我们是绑在一根树上的蚂蚱。让客户知道我们的进度，能增加客户对我们的信任感；让客户知道我们的难处，会让客户与我们共同想办法去解决问题，去规避项目风险。这样做，其实对大家都有好处，何乐而不为呢？ 所以，迭代式开发对有效避免软件开发的风险，作用是巨大的。但问题是，如何在项目中实际运用起来，挑战也是巨大的，很多难题需要解决，我们只有不断上下而求索，总结、总结、再总结••••••

转自http://fangang.iteye.com/blog/1222687