|
|
本帖最后由 总是一个人忙 于 2013-6-24 15:59 编辑
项目经理成长记-15：法务签核系统项目往事
2011年我新加入一家IT公司，从之前的开发、测试人员转型成项目管理型人员，也算是我职业生涯的一个新开始。
软件行业有一名老话是：软件质量是设计出来的。在我们公司，当时正在推行敏捷方法，所以更是如此。没有一些基础的实践活动，无法产生出高质量的软件。这当中，不可不提的是需求管理。敏捷方法分为三部分，敏捷项目管理，敏捷需求分析，敏捷软件开发。任何一个部分做的不好，都会让敏捷开发模式的作用打折扣。当时在我看来，我们公司在敏捷项目管理方面已经有一些进展，比如我们有各种计划会议、晨会、迭代会议、总结回顾会议、以及一些统一的跟踪管理平台等;在敏捷开发实践部分也正在作尝试，比如FDD产品特征驱动开发、编码规范宣导、代码审查、持续集成、自动化构建、自动化测试、自动化发布等;但在敏捷需求开发分析方面可能还有待进步。
作为有技术背景的人来说，管理项目常常会从技术人员的角度来看问题想问题。因为本人不仅有开发工作经验，同时也具备了测试工作的经验，于是相对来说，能够从比较全面的角度来看待项目的各种问题。但也正因为如此，对一个项目的整个生命周期来说，启动、计划、执行、监控和收尾这五个过程，依据曾经的经验，我在启动和计划上应该是最没有发言权的。下面我要讲的这个项目就是这样，在启动和计划中的问题最大，特别是在需求管理方面，同时在其它过程中也出现了不少问题，项目最终虽然成功按时上线，但可以说是勉强“胁迫”客户进行了验收。
该法务签核系统是用于公司集团内部的，但因为是不同子公司，而且是应用于法务，所以对于系统各方面的要求都很高。这个项目的背景是，客户和产品经理在A地，项目经理和项目其他团队人员在B地，属于“遥控”项目。我总结的重点问题主要有以下几个方面：
1. 时间紧
项目一开始还没怎么想清楚，就开了kick off会议，项目正式启动了，甚至产品经理就已经直接属意，要开发人员动手进行开发了。因为之前有个差旅系统有可借鉴复用的部分，所以团队成员们不管三七二十一的动起手来，未经过仔细思考评估即把别的系统的代码拿过来复用，这导致了很多的冗余以及潜在问题，在后来查找问题阶段吃尽了苦头。
2. 需求不明确
在时间紧的情况下， “大概”“也许”“应该”这样的词汇却还总是在需求定义中出现。A地的产品经理与客户沟通后，常常不加背景地转述给B地的开发人员，为了抢时间，有时甚至直接跳过B地的项目经理。而武汉的开发人员，因为需求理解的不透彻，没有经过系统的梳理和分析，导致了有些不合理的需求被实现，后又要被移除，而且因为需求理解的误差，也导致了后期测试阶段很多问题出现。
3. 需求变更频繁
其实和前一点是相互影响的，当需求开发和分析工作未做到位时，需求变更就不可能逃得过了。在这个项目中，反反复复的需求变更，比如一个表格的表头排列顺序如何展示的问题，就从“默认字母顺序排序”到“单击排序”到“双击排序”到“小三角图标排序”等等各种方案，这其中还存在反复的过程，这对开发人员士气的影响是致命的，这同时也说明开发人员没有以专业的态度来反馈专业的意见，帮助产品经理和项目经理来判断。
4. 沟通机制混乱
前面已经说了，A地产品经理经常直接属意开发人员进行某需求的开发，而开发人员常常混乱地听命于产品经理、项目经理，甚至还有技术经理。这导致有的需求不是整个团队都清楚明白，更别谈如何实现，以及实现方案是否进行了评估，有何风险等，这些都被忽略掉了。项目经理博客
针对以上的这些问题，我们一一来识别、检讨、制定解决方案、再实施、监控、反馈后改进，虽然最后也没能在短短几个月内改进得很完美，但最终至少吸取了教训，学习到了经验，我们团队都成长了不少。
下面先重点谈谈计划吧，成功的计划，就是计划着成功。对于以上问题，总结来说，可以说是启动和计划阶段没做好导致的。到底有哪些内容呢，我这里总结为Project Estimation Plan ，Environment Plan，Quality Plan ，Communication Plan，Release Plan & Iteration Plan。wwwnet
1. Project Estimation Plan & Environment Plan & Quality Plan
这基本应该是在启动阶段就需要完成的工作，在后续进行完善。
对于Project Estimation Plan，要求对于软件要实现的feature list要清楚定义，即项目的范围要基本确定，同时还需要针对这些范围，评估工作量、进度安排以及资源安排等;
对于Environment Plan，要求对于软件需要的设备进行计划，提出需求，提前安排，防止由于资源原因引起的工作延误;
对于Quality Plan，要求对于软件的质量标准、质量活动以及如何达成进行定义说明，对整个团队的质量方向、方针、政策和执行进行指导。
这个由于项目已经开始实施，所以后来并没有完全实施，只在过程中贯彻了这个思想，但我相信，这些启动阶段的工作做好了，对项目的帮助应该是巨大的。
2. Communication Plan
沟通计划定义了沟通对象、方法、时间和方式等内容，统一了沟通窗口，防止沟通的混乱。特别是在这个项目中，我们在A地B地达成一致情况下，清楚定义了需求的沟通窗口。即A地的产品经理负责和客户进行沟通，然后在进行必要的整理、开发和分析后，再统一传达给B地的项目经理，A地产品经理只与B地项目经理进行需求的沟通，他们互相负责。B地项目经理再与B地团队成员进行需求讲解，帮助团队成员进行需求理解，同时进行必要的分析评估，他们互相负责。最后，B地项目经理再反馈给A地的产品经理。同时整个过程有需求跟踪矩阵进行跟踪，对需求的提出时间、内容、状态、负责人进行了清楚的定义，这样就比较好地保证了需求的双向跟踪，避免了一些需求管理上的风险。在这样做了之后，我们团队不再有沟通上的困惑了，也知道自己应该对谁负责。
3. Release Plan & Iteration Plan
发布计划和迭代计划，在敏捷中，很重要的一点就是用来应对需求变更，快速响应需求变更的。在这里，要谈一下我们后来学习了，如何用用户故事来定义需求，作为我们发布计划和迭代计划中的backlog。
用户故事的作用有两个，一个是作为进度跟踪的依据，一个是作为与人交谈的备忘录。用户故事卡片并不是很精确的需求，因此不需要把事情描述的非常清楚。将需求的详细分析推迟到实现前夕来完成，这是敏捷需求分析的精华所在。任何提前做好的东西都会导致浪费，敏捷过程提倡足够就好，避免浪费。敏捷需求中强调商业价值和优先级的做法。每个迭代内分析好恰好足够下一个迭代开发的需求，就是产品经理每个迭代的主要工作内容。产品经理的需求分析工作在上一个迭代完成，包括需求的了解，分析，评估和排列优先级。在每个迭代开始的时候，由产品经理和项目经理主持召开迭代计划会议，在会议上向所有的成员解释这个迭代要完成的用户故事，然后由成员自由提问，直到他们能够获得足够开始实现该功能的信息。敏捷过程并不是没有需求分析，而是把需求分析过程分散到整个开发的过程中，让开发和需求分析并行进行。
针对这个项目中需求变更频繁，客户传达的需求常常模糊不清，或者变化不断。这有两方面的原因，一来客户是真正没有想清楚自己要什么，二来是我们没有引导好客户，帮助客户想清楚他们真正想要的是什么。由于我们团队都没有法务的背景和经验，所以，在这方面确实比较吃亏。但我们可以做的是更好地对需求变更进行管理，把风险降低到最小。
对一个项目开发来说，release拥抱变化。对于一个iteration，要拒绝变化。iteration计划前，产品的 backlog都可以变化。 所以在后来，我们要求A地产品经理根据客户的需要，定义好release计划，然后我们制定iteration计划，并提交给产品经理以及客户，在进行充分的沟通澄清的情况下，作为需求的开发基线进行开发。当一个iteration开始了，我们不再接受需求变更，把已经通过审核并确认要变更的内容登记到我们的需求变更表上，由产品经理决定何时加入到哪一个release计划中。同时我们根据release的变化也相应的对后面的iteration计划进行调整，但整体的time-box是固定的，而且尽可能地避免了返工，团队士气后来就好多了。当然，我们的计划也及时反馈给了客户，让客户知道我们不是不做这个需求变更，而是把我们的专业分析以及后面的计划安排反馈给了客户，让他们更明白他们这次的需求变更所要付出的代价以及何时能得到他们想要的东西，这样做了后，他们的满意度至少没有很差，最后还验收接受了我们的软件系统。项目管理论坛
这个项目后来成功按时上线并得到了客户的验收，但因为前期工作的混乱不足，后来的改进还是效果有限的，后来这个项目还做了二期三期来进一步完善和提高。但不管怎样，所有的经历都是一笔财富，都是自我成长的一部分，这样的经验和教训多么的难能可贵。
上一篇：项目经理成长记-13：西藏某公路口岸物流车辆监控系统项目往事
下一篇：项目体系文档连载：18阶段进度报告 |
|
service@step365.com
0571-87357690
狗仔卡
发表于 2013-6-6 06:53:57
QQ好友和群
QQ空间
腾讯微博
腾讯朋友
收藏
转播
分享
淘帖
支持
反对
提升卡
置顶卡
沉默卡
喧嚣卡
变色卡
抢沙发
千斤顶
显身卡