李燕云/譯

當你聽到客戶這樣說,你會作何感想?”我們希望盡快拿到軟件,但我知道在弄清楚你們需要多長時間才能開發(fā)出軟件之前,我們還需要在需求溝通階段多花些時間來幫助你們. 不要擔心到底需要多長時間才能得到我們完整的需求.放心,我們將同你們一起面對這個問題.另外,我們已經(jīng)為你們每個人都準備了一份比薩.”

嗨,醒醒,不要做夢了…這是絕不可能的事. 不過,話雖如此,你還是可以往這個方向聯(lián)想. 你自然期望你的下一個項目比上一個項目成功,你可以在項目的這個階段聯(lián)想到這些,并使用本文最后提到的方法讓你的客戶加入進來,激勵他們多加溝通以對他們的期望作出更詳細的說明.

不要哀嘆了解客戶期望是如此之難,而應代之于用最好的心態(tài)去同客戶溝通,看看你能做到何種程度. 如果你有良好的意愿去了解客戶期望,事情也必然會往這個方向發(fā)展.

夢幻情節(jié)

Joe是資深用戶專家,非常熟悉用戶需求.幸運的,他被任命為項目經(jīng)理.Joe知道用戶有怎樣的需求,他們能從軟件中能得到什么樣的管理方法以及系統(tǒng)如何提供這些方法.他能獨自設(shè)計這些系統(tǒng)并編碼,不需要借助其他人的幫助.(這真是夢寐以求的情節(jié))

另一種理想情況

好了,如果你不能從用戶組得到象Joe這樣的最佳角色來幫助你開發(fā)軟件,那么你該怎樣去讓你的設(shè)計開發(fā)人員去了解客戶?我有一些經(jīng)歷,一接觸到剛開發(fā)出的軟件便立刻發(fā)現(xiàn)開發(fā)者從沒有同用戶坐在一起討論過.交接會上,用戶并不理解軟件的每一個過程及功能,選項以及結(jié)果.然而,這仍已足夠讓你的項目獲得通過.(這也是個夢?)

現(xiàn)實情況

現(xiàn)實情況則是,我所管理的多數(shù)項目,其用戶組同我們的開發(fā)人員之間都相距一到兩個時區(qū),我們必須通過電話和電子郵件來傳遞用戶的相關(guān)要求.如果你面臨的情況同我相似,那么我們就得回到現(xiàn)實,停止夢想.但是,我們?nèi)匀黄谕纳莆覀兯匦璧目蛻粜枨笪募馁|(zhì)素.

建立期望 充分溝通

在項目的項目需求階段建立起客戶期望說明文件至關(guān)重要,你可以說:”是的,我們能夠開發(fā)出軟件來滿足你的需要.但這要靠團隊的努力.我們預估每周需要兩小時的時間同你的團隊人員見面,以檢討你們的期望.呵呵,你們所有人都將會有額外的工作了.”
建立溝通計劃時,我提倡以用戶為中心的表現(xiàn)方式,”用戶在接受軟件測試結(jié)論前,他可能不會見到軟件.當他們見到后,就會經(jīng)常地提出一些有價值的意見供我們改進,但這時候軟件已經(jīng)完成,變更將導致交貨期延遲數(shù)周.還有,有時一項遺漏的功能還會讓軟件無法使用.所以我建議在開發(fā)軟件時最好有一個個人或者團隊引導你充分理解用戶需求.”
在建立起客戶期望說明文件并得到客戶充分合作的承諾后,請督促他們提供一份他們的工作流程圖給你.另外,還要有他們的培訓資料及品質(zhì)控制文件.特別地,要弄清楚他們現(xiàn)在的流程是怎樣的以及將來他們因使用新軟件而預期的新流程又是怎樣的.這或許并不夠充分,但它能幫助用戶組以及你的開發(fā)隊伍懂得你的項目將來會為用戶提供怎樣的溝通平臺.
另外,最好多同客戶建立好關(guān)系,讓他們愿意充當你的眼睛和耳朵,幫助你理解并定義他們自己的需求.好了,你可以使用下面的方法幫助你的用戶組去理解客戶需求.

為什么收集客戶需求有如此多的工作?

如果有人問你:”寫一本書需要你多長時間?”你可能問自己下列問題.
·書名是什么?
·虛構(gòu)情節(jié)或相反,小說或教科書?
·什么樣的讀者群…專家還是新手?
·精裝本還是平裝本？
·工作手冊還是圖畫書?
·多少章節(jié)?
·使用什么樣的字體?需要大量印刷嗎?

你可以想象得到,一個基于網(wǎng)絡(luò)平臺的應用軟件或網(wǎng)址可能需要考慮更多更詳細的問題.
·每一項工作內(nèi)容,用戶先做什么后做什么最后做什么?
·一項功能完成后,是否需要用戶給出注釋文字?
·需要同其它軟件連接的接口嗎?
·用戶有什么樣的保密要求?
·需不需要系統(tǒng)管理員部門管理員?或者用戶自我登記自己管理?
·需不需要系統(tǒng)日期及時間,及上一次的更改日期?
·需不需要系統(tǒng)使用情況的報告以及工作結(jié)果的匯總報告?
·報告中的每一個數(shù)據(jù)是否都需要同源數(shù)據(jù)建立連接?計算結(jié)果是怎樣的?
·每一個頁面都有什么樣的習慣性要求?站點的每一頁的每個區(qū)域所附帶的業(yè)務規(guī)則是什么？
·當你敲擊”Enter”鍵時,電腦進入下一個新功能區(qū)還是顯示一系列選擇項?
·區(qū)域?qū)傩裕簠^(qū)域長度，角度或文字數(shù)字的定義是有要求的或沒要求的還是有確定要求的？

這些用戶的期望必須反映到系統(tǒng)要求中去,并最終變成編碼形成軟件.
精確地嚴格按照正確的順序來描述你的工作是非常困難的,也是不可能的.如果你的開發(fā)組能夠緊跟用戶要求,把這項工作當作自己工作的一部分,他們就將得到非常精確的客戶對該軟件的愿望.記錄下所定義的客戶要求,將他提供給你的開發(fā)團隊,并隨時準備回答他們向你提出的任何問題.如果這一步成功了,就意味作你將有一個成功的首次演示.盡管收集客戶需求需要費些時間,但如果能夠幫助準確理解客戶需求, 那么它最終將幫你節(jié)省時間,還幫助你開發(fā)出一個讓客戶滿意的用戶軟件,你所進行的工作也將是更加高效的工作.

原文：
　　　　　　　　　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.

【?發(fā)表評論?0條?】