同事给我发的邮件，谈及上周参加项目会议，关于项目Delay的深刻体会（分析篇）。

续（挖掘篇）

其实想了解业主IT方对项目的底线，压根也不需要举这样的理由，但是项目经理已经在周会上在用户面前这么说，其实已经没有责怪他的必要了，而且现在不是责怪的时候，而是应该接着深入分析项目情况，了解项目目前的困难以及症结，才有可能给出正确的、具体的指引。

因此，我们管理中心的同事接着询问目前项目的主要问题以及改进措施。项目经理回答主要是

1. 沟通效率的问题，目前改进措施是：正式发邮件给业主IT方，要求周会业主的业务方必须参会；另外，要求监理人尽快熟悉系统；
2. 落实责任，责任到人，落实我们汇报给谁落实，避免监理职责不清；

我们又询问了管理该项目的部门领导，他的回答如下：

1. 项目组对需求目前还没有形成统一想法，需要准备一致；
2. 计划不清晰，目前Delay的影响说不清楚！

读者，你会如何分析目前的情况呢？管理中心是这么评点的：

1. 项目经理提的只是想法，根据经验，很难落实和跟踪。譬如：要求监理人尽快熟悉系统，是要求他们什么时候熟悉系统，熟悉到什么程度？
2. 一旦无法跟踪落实，这些处理措施将不会在短期内解决问题；而且，向用户说了也没有大效果；
3. 前期准备工作不足，譬如：针对项目组对需求目前没有统一的想法，我们要分析，这个系统对于我们是属于新进入的领域还是继承的领域，如果是已经做过的领域，那么是否是在继承上有不同意见；如果是新进入领域，那么是否是我们没有在初始化时，集中优秀业务分析人员达成方向的一致后给项目组跟进；
4. 计划方面，涉及多方，但是在计划中没有看到多方工作的前后置依赖关系，计划定义肯定是太粗线条，否则应该能够告诉我们Delay的影响；

读者，除了对同事的点对点评论外，还应该给项目组什么指引呢？管理中心是这样的：

1. 心态上，项目组要去除依赖心理，必须在需求的源头——“业主”上下功夫，牢牢掌握自己的命运；
2. • 很多事实证明，当我们躲在监理方或者接口人后面，一定不会有好结果，而且当我们做的不好的时候，监理方和接口人怎么可能为我们说话呢？到时候，哭都不知道找谁！
   • 当我们躲在其他后面，就是给了其他人广阔的施展空间，给了监理“大显身手”的机会。
3. 尽快开展项目内部生产自救工作
4. • 让队伍以客户的业务/术语为导向，集结部门内部优秀业务专家，进行导向式需求分析，在内部取得一致；
   • 加强需求阶段的过程管理，不能只看着SRS产出，借鉴hong同事的过程性产出方法；
5. 要求部门领导亲自参加一次和业主方的开会，必须拿到第一手资料，才能采取果断、有力的措施；
6. 要求在2周内改变目前项目的格局，建立业主方和我方的直接沟通通道，解决需求不明确的问题。

另外，管理中心的同事为了避免遗留问题，再次向项目经理询问。

管理中心（简称管）问：是否有资源不足导致项目Delay？

项目经理（简称项）答：有的，主要再调研时，资源不足，有一同事还负责一部分外项目的工作。

管问：你对这个同事是什么定位和要求？

项答：我要求他要和我谈需求，他以前做过这个方面的一些工作。

管说：姑且不谈该同事投入在项目的时间比例多少，我们觉得即使该同事全部时间都投放，你的项目还是会碰到现在的问题。因为：

1. 该同事不是擅长于需求分析；他之前是有一些了解，可以进行整理等书面工作，但是不是这个一个定位；
2. 项目经理是希望找一个需求分析能力以及控制能力水平相当的人，这在Build Team上存在目标定位不一致的情况；
3. 再次强调了项目经理如果不牢牢地掌握业务，一定很难取信客户，控制力的下降将直接导致压力转嫁为技术人员的数量以及技术人员的水平要求。

最后，管理中心要求该项目经理和部门领导针对以上提出的意见，进一步分析，明确目标和行动内容，提交更加可执行的工作任务计划。