透过湖工项目浅谈项目管理过程

透过湖工教务项目浅谈项目管理过程

1、项目背景介绍：

湖工项目是湖北工业大学教务系统，是一种专注于大学和高等院校的教务管理系统。其中包括一些校园基本信息管理，教学培训计划管理，学生排课系统，成绩管理，排考管理等一系列业务管理体系。

湖工项目与我们接头的是教务处，其中管理人员曾经也是做程序的，喜欢代码Sql，就算是加班工作他也很乐意，该院校原有的教务系统就是他个人创作的，所以对教务管理这一块有非常丰富的管理经验。

2、项目情况：

项目持续有一年左右的时间了，项目需求频繁变动，人力投入了却不见成效，一直亏损，导致项目到现在仍然无法结项。

3、问题归纳总结与应对措施：

a、客户现场目标不明确，去客户现场事先准备不充分。到了客户现场像无头的苍蝇一样，不知道该演示什么，该跟客户从什么地方开始谈需求调研。

这样就会导致你很被动，谈需求时也让客户会认为你不够专业，对本行业不够了解，对你丧失信心，这是很致命的。

人非圣贤，不可能什么都知道，什么行业都了解。但作为项目经理，对客户的项目事先必须得先了解。

每次去客户现场，在内心中必须整理出一个大纲，首先演示什么，然后我们接下来谈什么需求，带回去给我们的小伙伴做，对于这些需求你有什么看法，构想下客户针对你的看法会有些什么疑问，你将如何应对，如何回答。

针对需要演示的功能，去之前项目经理必须整理出一个稳定的版本，即使这个版本功能不够完善。去客户现场前一天或几个小时，都要发布一个版本给测试部门进行功能测试。确保本次去演示的功能无误，如还有功能为完成，分析应对策略，将其中本次版本中剔除，本次不演示，并向客户说明原因，不要留一个半吊子功能。

然后一一实现你今天来客户现场的目标。

b、需求调研需要抓住客户对需求的偏重度。偏重点这个不能一概而论，需要你对客户的了解和分析客户最近的偏向来决定客户此次谈论需求的偏重点。

很多次我们在与客户沟通的时候不能深入了解客户所说内容的重点，往往只停留在理解客户的表面描述上，这样分析出来PBI不够准确，导致开发出来的东西不能打动客户，就会无限期的返工，开发成本就是无底洞了。

记得在与客户沟通一次网上评教模块时，客户就描述了一系列他的想象，并结合了他们学校的评教业务来跟我们讲解了下需求，并批评了我们前期做的一个版本，当时我们听完后，感觉完了，这个功能得重做了(前期做过这个模块)。

但是回去后深入的理解了下客户描述的需求与学校的实际业务规则，发现与之前我们开发的版本差异不是很大，这让我们喜出望外，立马就在以前版本的基础上改进了，此次交付就得到了客户的认可。

c、详细的产品BackLog和业务规则。

开发过程中详细的产品用户前景是很重要的，只有站在客户的角度去想问题，去实现客户的需求，才能真正的贴合实际应用场景。往往在与客户的需求沟通过程中，客户讲解的需求是A，我们理解为了B，然而客户却以为我门理解的是A，这样就会产生需求的偏差，所以了解客户想要这个功能是要达到什么目的，起到什么效益这才是根本，产品BackLog一定要尽可能的详细。

Backlog的校验规则在一定程度上是类似测试用例的，所以校验规则越详细越好，这能提升我门开发质量和测试效率。

d、持续按敏捷开发的流程执行，但在实际开发周期中，我门往往会由于项目时间紧，赶项目功能而忽略一些敏捷开发中的环节。

所以我列出了几个重要的环节1、迭代计划会议，计划会议是PM向开发人员讲解产品需求，然后将产品前景分配给开发人员设计，这是一个需求理解的会议，所以不能少。2、设计评审会议，评审开发人员设计的功能模型，对需求理解有无偏差的过程，这是纠正需求理解偏差的会议，所以不能少。3、迭代演示会议，将本轮迭代的内容内部演示，暴露问题，将项目问题内部消化的会议，俗话说不出现在客户现场的bug不叫bug。所以也不能少。4、迭代回顾会议，寻找不足，下次改进，持续改进的会议。

敏捷开发是一种持续改建模式，以最小的代价来应对客户频繁变更的需求。

4、项目回顾：

其实管理是一门艺术，是一种双赢的下注，更是是一门技术活。

团队是在不断的磨合中成长起来的，没有生来就很强的团队，只有更专业，更默契，更团结的团队。