|
转自项目管理者联盟
在一个与我们平行的世界中，Gary
很郁闷地坐在他的办公室里。在他刚到这个公司短短的2周内，他已经帮助项目经理解决了不下10个问题。但是老天好像在跟他开玩笑。他还没郁闷多长时间就又一个项目经理
Hammer 敲响了他的房门。Hammer
怨气很大，一进门就抱怨说：“业务人员太烦人了，我写了这么详细的需求并和他们挨个需求进行确认，现在他们还说我们需求理解的不对，开发有问题!” Gary
知道他正带领着一个给公司内部做项目管理系统的一个项目，业务需求的提出者是PMO的成员。“别急，你能把你的需求文档先给我看看么?”Gary微笑着说。Gary
顺利地拿到需求文档，他发现这个需求文档一共有100多页，“你们和业务需求人员确认了很长时间吧?”Gary
问Hammer。Hammer气愤地说到：“可不是，从下午2点到晚上9点，足足的8个小时呀!”Gary听了，专门为业务需求人员“默哀”了一下。“我们可以换一种需求分析和确认的方式么?”Gary问道。Hammer眼睛要瞪出来了：“为什么，原来的做法有什么问题么?我们一直这么做的呀!”
Gary : 汗!项目经理圈子
“我们看看原来的方法有什么问题，你也看看这些问题是否会经常的出现：
1、你在项目前期就试图把需求写得很详细，但是业务需求人员往往在这个阶段也是比较模糊的，所以你的需求还是会随着需求的逐渐明确而不断地变更。项目管理系统因为是按已有流程进行设计系统，所以这个项目还算明晰，如果你的这个项目都没法干，那么其他项目更是一塌糊涂了。项目管理者联盟
2、你这篇文档一共100多篇，一下子讨论8个小时，我估计你和业务需求人员都晕了。而且后续这些需求肯定还是细化，你只是想一次就都确认也是不太可能的。项目经理圈子
3、你文档中过早地列出了界面原型，从UI设计和用户体验上进行了约束，这个你可能没有意识到。项目管理者联盟
4、这个需求文档中只涉及了业务流程和一些数据字典，但是没有明确每条功能在什么条件下算正常实现的标准，这个在开发时可能会出现较大的歧义性。转自项目管理者联盟
还有很多问题，我就不一一说出来了，你觉得这些问题是否是经常出现的?”项目管理者联盟
Hammer现在眼睛瞪得更大了，不过这时他已说不出来话了。等了半天他才说：“那你说怎么搞?”项目管理论坛
Gary：“你听说过用户故事么?这是敏捷开发中的一种需求分析方法。” Hammer 默然地摇摇头。bbs.mypm.net
Gary：“让我们一起来做做吧!”项目管理者联盟
Gary 让Hammer召集了他的团队进行了两次头脑风暴，并让业务需求人员也加入到了其中。项目管理者联盟
在第一次头脑风暴中他们找到了用户角色：项目管理论坛
项目管理者联盟
首先：是找出了用户角色，如：项目经理、系统管理员、部门领导、公司领导、流程审核员、业务管理员……项目管理者联盟
然后：他们又把这些用户角色进行了整合的讨论，比如：他们认为系统运营后的维护也是由业务管理员进行(比如分配权限和异常手动更改流程、信心等操作)，所以他们决定将系统管理员和业务管理员合并，成为了管理员角色。经过业务需求人员对业务流程的介绍，大家觉得还要将审核人员细分为;PMO审核、财务审核的角色。blog.mypm.net
接着：他们对上述这些用户角色进行了用户画像的分析。分别定义出每个用户的系统使用频度、系统使用的熟练程度等，这样可以分析出系统可能会针对某些用户进行易用性等非功能性的需求。项目管理者联盟
最后：他们为了使重要最为重要的项目经理这个角色“活”起来，他们进行了虚拟角色的描述：项目经理博客
项目经理：AI项目管理者联盟
他对自己的项目非常熟悉，并且项目已评审通过。他会在项目管理系统上填写项目基本信息并保存。在发起流程前，他可以随时增删改项目信息，但当发起流程后，所有项目信息将被冻结，直至流程完成(审核通过;审核不通过被打回AI处)。项目管理者联盟
在分析完用户角色后，Gary又组织了第二次头脑风暴，他们描述了用户故事并进行了讨论和整合：项目管理者联盟
l 1、Gary：“我们要采用一种新的方法描述需求。我们用故事卡来描述。用户故事包含三部分内容：项目管理论坛
1)简述：故事简单的题要，作为计划和提示的标题。blog.mypm.net
2)对话：有关故事的详细描述，用于故事的细节。
3)测试：对故事细节的再细化，以及确认故事完成的判定依据。PgMp.mypm.net
本文为项目管理者联盟联盟会员原创文章，授权发布，非经同意不得转载！
|
