追求專案夢想（轉）

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

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

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

夢幻情節

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.

[@more@]