李燕云/译

当你听到客户这样说,你会作何感想?”我们希望尽快拿到软件,但我知道在弄清楚你们需要多长时间才能开发出软件之前,我们还需要在需求沟通阶段多花些时间来帮助你们. 不要担心到底需要多长时间才能得到我们完整的需求.放心,我们将同你们一起面对这个问题.另外,我们已经为你们每个人都准备了一份比萨.”

嗨,醒醒,不要做梦了…这是绝不可能的事. 不过,话虽如此,你还是可以往这个方向联想. 你自然期望你的下一个项目比上一个项目成功,你可以在项目的这个阶段联想到这些,并使用本文最后提到的方法让你的客户加入进来,激励他们多加沟通以对他们的期望作出更详细的说明.

不要哀叹了解客户期望是如此之难,而应代之于用最好的心态去同客户沟通,看看你能做到何种程度. 如果你有良好的意愿去了解客户期望,事情也必然会往这个方向发展.

梦幻情节

Joe是资深用户专家,非常熟悉用户需求.幸运的,他被任命为项目经理.Joe知道用户有怎样的需求,他们能从软件中能得到什么样的管理方法以及系统如何提供这些方法.他能独自设计这些系统并编码,不需要借助其他人的帮助.(这真是梦寐以求的情节)

另一种理想情况

好了,如果你不能从用户组得到象Joe这样的最佳角色来帮助你开发软件,那么你该怎样去让你的设计开发人员去了解客户?我有一些经历,一接触到刚开发出的软件便立刻发现开发者从没有同用户坐在一起讨论过.交接会上,用户并不理解软件的每一个过程及功能,选项以及结果.然而,这仍已足够让你的项目获得通过.(这也是个梦?)

现实情况

现实情况则是,我所管理的多数项目,其用户组同我们的开发人员之间都相距一到两个时区,我们必须通过电话和电子邮件来传递用户的相关要求.如果你面临的情况同我相似,那么我们就得回到现实,停止梦想.但是,我们仍然期望改善我们所必需的客户需求文件的质素.

建立期望 充分沟通

在项目的项目需求阶段建立起客户期望说明文件至关重要,你可以说:”是的,我们能够开发出软件来满足你的需要.但这要靠团队的努力.我们预估每周需要两小时的时间同你的团队人员见面,以检讨你们的期望.呵呵,你们所有人都将会有额外的工作了.”
建立沟通计划时,我提倡以用户为中心的表现方式,”用户在接受软件测试结论前,他可能不会见到软件.当他们见到后,就会经常地提出一些有价值的意见供我们改进,但这时候软件已经完成,变更将导致交货期延迟数周.还有,有时一项遗漏的功能还会让软件无法使用.所以我建议在开发软件时最好有一个个人或者团队引导你充分理解用户需求.”
在建立起客户期望说明文件并得到客户充分合作的承诺后,请督促他们提供一份他们的工作流程图给你.另外,还要有他们的培训资料及品质控制文件.特别地,要弄清楚他们现在的流程是怎样的以及将来他们因使用新软件而预期的新流程又是怎样的.这或许并不够充分,但它能帮助用户组以及你的开发队伍懂得你的项目将来会为用户提供怎样的沟通平台.
另外,最好多同客户建立好关系,让他们愿意充当你的眼睛和耳朵,帮助你理解并定义他们自己的需求.好了,你可以使用下面的方法帮助你的用户组去理解客户需求.

为什么收集客户需求有如此多的工作?

如果有人问你:”写一本书需要你多长时间?”你可能问自己下列问题.
·书名是什么?
·虚构情节或相反,小说或教科书?
·什么样的读者群…专家还是新手?
·精装本还是平装本？
·工作手册还是图画书?
·多少章节?
·使用什么样的字体?需要大量印刷吗?

你可以想象得到,一个基于网络平台的应用软件或网址可能需要考虑更多更详细的问题.
·每一项工作内容,用户先做什么后做什么最后做什么?
·一项功能完成后,是否需要用户给出注释文字?
·需要同其它软件连接的接口吗?
·用户有什么样的保密要求?
·需不需要系统管理员部门管理员?或者用户自我登记自己管理?
·需不需要系统日期及时间,及上一次的更改日期?
·需不需要系统使用情况的报告以及工作结果的汇总报告?
·报告中的每一个数据是否都需要同源数据建立连接?计算结果是怎样的?
·每一个页面都有什么样的习惯性要求?站点的每一页的每个区域所附带的业务规则是什么？
·当你敲击”Enter”键时,电脑进入下一个新功能区还是显示一系列选择项?
·区域属性：区域长度，角度或文字数字的定义是有要求的或没要求的还是有确定要求的？

这些用户的期望必须反映到系统要求中去,并最终变成编码形成软件.
精确地严格按照正确的顺序来描述你的工作是非常困难的,也是不可能的.如果你的开发组能够紧跟用户要求,把这项工作当作自己工作的一部分,他们就将得到非常精确的客户对该软件的愿望.记录下所定义的客户要求,将他提供给你的开发团队,并随时准备回答他们向你提出的任何问题.如果这一步成功了,就意味作你将有一个成功的首次演示.尽管收集客户需求需要费些时间,但如果能够帮助准确理解客户需求, 那么它最终将帮你节省时间,还帮助你开发出一个让客户满意的用户软件,你所进行的工作也将是更加高效的工作.

原文：
　　　　　　　　　Keep Dreaming
Donna Boyette March 26, 2001

How would you like to hear this from a customer: “We want the application as quickly as possible, but I know we’ll have to invest some serious time in the requirements stage before we’ll know how much time your team will need to develop it. Don’t worry about how long it takes to get a complete set of requirements. We’re ready to work with you. And we ordered pizza for everyone!”
Hey, wake up! Stop dreaming…it will never happen. But you could come close. If you want your next project you to be more successful than the last project, use these hints and the user-requirements explanation at the end of this article to motivate your users to be intimately involved during this stage of the project.
Instead of bemoaning the fact that gathering requirements is as much fun as exploratory surgery, start with the best in mind and see how close you can get. If you could dream up the ideal scenario for gathering requirements, it might go something like this.
Dream Scenario:
Joe used to be a user in the group for which your team is designing a new application. He was then promoted to manager before finally coming on board your team. Joe is intimately familiar with what the users need, what management needs from the application and how the system can deliver it. He can design it and then code it to specifications with no help from anyone.
Next Best Thing:
Well, if you can’t hire Joe away from the user group and teach him to develop, what about getting your designers and developers to shadow users while they work? I clearly remember using new applications and immediately realizing that the developer never sat with the users. Users cannot possibly articulate each step and function, option and result of their jobs while sitting in a conference room, yet that is the level of detail you need for your project to be a true success.
Reality:
For most of the projects I manage, our user groups are one or two time zones away from the developers, and we must expect users to relay their processes and requirements over the phone and via e-mail. If your reality is like mine, we can stop dreaming but still hope to improve the quality of our requirements documentation.
Set Expectations, Give Explanations
It is critical to set customer expectations in the project-request phase by explaining, “Yes, we can create a site or application that will meet your needs, but it will be a team effort. We will need an estimated two hours per week from your team members for requirements meetings, and you will all have homework.”
When creating our communications plan, I encourage good user representation by saying, “The users might not see the application until user acceptance testing, and when they do, they frequently have very valuable input for improvements, but by then the application is already built, and changes would delay delivery sometimes by several weeks. Sometimes users even point out a missing function that makes the application unusable, so I recommend having a user or team lead you trust involved in requirements.”
After you have set expectations for your clients and gotten a commitment for their involvement, be sure they provide you with their processes--a process flow diagram they create for you, in addition to any training or quality control documents they might have. I typically ask them to define their current process as well as the process they envision using the new application. This isn’t quite as detailed as a use case, but it helps the users and your development team envision what-if scenarios and identify interactions with other groups that might have implications for your project.
The next best thing to being there is to inspire the customers so that they are willing to be your eyes and ears as they define user requirements by essentially shadowing themselves. Use the following description to help your user-group management explain the necessary commitment to the folks selected to help define requirements.
Why Is Requirements-Gathering So Much Work?
If someone asked you, “How long would it take you to write a book?” you might have a few questions of your own.
· What subject?
· Fiction or non-fiction, novel or textbook?
· What is the intended readers’ understanding level…expert or novice?
· Hardback or paperback?
· Workbook or picture book?
· How many chapters?
· What font should I use? Do any readers need large print?
As you can imagine, developing a web-based application or web site is even more detailed. User requirements must answer dozens of questions.
· What must the user do first, next and last for each function of the job?
· Is there a need for the user to enter comments after the function is completed?
· Does the application need to interface with another application?
· What are your user security requirements?
· Will you have a system administrator and department administrators, or will users self-register?
· Is there a need for system-stamped time and date and last-updated-by details?
· Will you need reporting of the system usage or work results?
· Is every piece of data in the report tied back to the field source in the application? What are the computations?
· What are the business rules attached to each field on each page of the site?
· When you select “enter” do you go right to a new function, or to a list of pending items?
· Define field attributes: field-length, alpha or alphanumeric, required or not, any validation required?
These user requirements must then be translated into system requirements and ultimately into code as the developer creates your site or application.
Describing the work you do in exact detail and in the proper sequence is difficult or impossible. If your design team can shadow users of the new application as they do their work, they will get a much more accurate picture of what the new application must accomplish.
If you must supply requirements without developers available to watch your every move, do the next best thing. Take notes to define requirements as you work. Provide this detail to the development team, and be willing to answer as many questions as they can throw at you.
Success in this stage can mean a successful rollout, and though requirements-gathering will take some time, the end result is time saved with accurately defined needs, and a user-friendly application that meets your business needs and streamlines your job.
Donna Boyette is a new project manager and freelance writer.

You’re a real project manager--do you have a real project management story to tell? We want to hear the good, the bad and especially the ugly. Send your war stories to the RPM Editor. If we use your story, we’ll send you a gantthead.com T-shirt, mug or hat. You’ve earned it.

【 发表评论 0条 】