產品與專案
整理.撰文 劉燿瑜
客戶需求模糊不清,團隊無所適從?釐清 3 個不同層次要求,讓專案逆轉勝
2022-04-19
專題主題 市場多變、客戶善變!用「敏捷管理」回應明日的變局
蘋果創辦人史蒂夫.賈伯斯(Steve Jobs)曾說:「如果只靠客戶主動告訴我,他們需要什麼,以此打造產品,等到產品完成時,客戶又會改要其他東西了。」
賈伯斯認為,客戶反覆無常,因為多數人並不真正清楚自己需要什麼,而這也可能成為專案團隊最大的惡夢。舉例來說,客戶或許會這樣描述自己的需求:「我想做一款年輕人喜歡的飲料。」
為何鎖定年輕人?為什麼選擇飲料這個產品?《SCRUM 敏捷產品管理》一書指出,這些可能都是客戶無法一開始就釐清的核心問題,而需求愈模糊,客戶對專案的要求也愈容易更動。
《我懂了!專案管理》將這種情形稱為「無頭雞專案」,意即專案像是被剁頭的雞隻,不知道方向、胡亂衝刺,直到力氣耗盡、血流不止才倒地斃命。書中指出,很多數專案的失敗都源自在初始階段時,沒有釐清客戶做專案的目的、建立對專案的正確願景。
不要接到需求就開規格,釐清深層想法再提方案
因此,主動問清楚客戶需求,是專案邁向成功的第一步。《完全圖解計畫力》作者、專案管理顧問芝本秀德指出,想在初次討論時,就摸清客戶真實需求,建議使用「抽象階梯」方法,將客戶提出的要求,由上往下分為需求、規格、指示 3 種層次。
階梯頂端的需求指的是「為何要做」、規格是「用何種手段滿足需求」,作業則是落實規格的詳細執行計畫、行動步驟。舉例來說,當對方請你規畫某間門市的宣傳活動時,先別急著制定活動計畫書,因為規畫宣傳活動,只達到抽象階梯中的規格層次,而擬定執行活動的計畫書,則屬於指示層次。
企業想辦宣傳活動,背後一定有個更深層的需求,可能是為了行銷新產品或提升品牌知名度。專案團隊必須掌握到需求層次,才能找到更能滿足客戶需求的方法,像與社群網紅聯名、舉辦貴賓限定的座談會,宣傳效果可能都比辦門市活動更能提升品牌知名度。
芝本指出,多數客戶之所以只提得出規格層次的要求,是因為上層的需求較為抽象,規格則相較好表達。像前述的門市活動,就比提升品牌知名度更好理解。芝本秀德認為,透過 4 個連續問題,能讓客戶更具體描繪抽象需求、協助對方從規格,推導至需求層次:「發生什麼狀況?」「這個狀況對我而言的問題是什麼?」「該用什麼方法解決這個問題?」「為什麼要用這個方法解決?」
若以前述例子解釋,「發生什麼狀況?」可能是品牌知名度不如同業,「對客戶而言的問題」則是銷售動能低落,因此客戶想到的解決方法是辦門市活動,此時專案團隊可用「為什麼要用此方法解決?」來確認客戶原先開出的規格跟需求間的適配性。
「電梯行銷」簡潔陳述專案願景,確立共識仍須測試、修正
在掌握客戶的真實需求後,《敏捷專案管理基礎知識與應用實務》一書建議專案團隊可用電梯行銷術,簡單複述客戶期待的解決方案,凝聚雙方對專案的共識、建立共同願景。
電梯行銷術是透過以下 6 句話、在坐一趟電梯的時間內,簡潔向客戶陳述該專案、產品如何滿足、解決需求:
1.「該專案是為某人/某事(目標客群、欲處理的問題)而做。」
2.「因為他們想要⋯⋯/造成⋯⋯問題。」
3.「所以提出 XXX 這個產品/解決方案。」
4.「這個產品/解決方案,提供⋯⋯等功能。」
5.「不像其他產品/解決方案,有⋯⋯缺點。」
6.「此產品/解決方案有對手沒有的特色。」
《SCRUM 敏捷產品管理》提醒,在凝聚專案或產品願景的同時,請謹記少即是多的原則,報告的專案特性、功能盡量濃縮在 6 點內,才能凝聚、激發客戶對這些功能的興趣。
《產品專案管理全書》指出,即便雙方對專案有穩固願景,但在落地、執行的過程中,仍可能因消費者行為改變、市場趨勢等外在因素,需要改變執行方向,才能抵達雙方原本預期的目的地。
產品陽春也無妨,用核心功能測試市場
《SCRUM 敏捷產品管理》建議透過打造最小可行性產品(MVP,minimum viable product),縮短專案執行期間、產品開發時間,提早讓產品進入市場,好頻繁測試、取得客戶與市場的回饋,這樣一來,如果客戶的需求更動,產品也能盡早修正,所冒風險與損失的成本都相對較低。
《精實創業》作者、知名創投顧問艾瑞克.萊斯(Eric Ries)指出,有時最小可行性產品甚至不用做出實際原型,也能測試產品符不符合客戶期待。像是在個人雲端共享服務 Dropbox,2008 年首度問世時,僅以 3 分鐘的影片向市場介紹、模擬產品功能,一夕間吸引7萬多名用戶排隊預訂。
但如果專案目標並非面向消費者市場的產品,也沒有消費、使用者回饋當作評價,專案團隊該如何替最小可行性產品,設定成功標準?《專案管理:玩一場從不確定到確定的遊戲》一書提醒,專案團隊在設定目標時應謹記「數字+時間」原則。
無論設定任何指標,例如專案要提升產品多少良率,或替組織省下多少材料成本,都得加上期限。例如良率提升 5 個百分點是要在一年內還是一季內?如果太晚達到成效,就失去執行的意義。且在原指標上,設定更細緻的時間期限,例如專案內容是 3 個月內替某產品減少 20% 材料成本,拆分成每周該達到的進度,也有助隨時確認執行方向是否落後目標。
打點利害關係人,避免各方意見干擾執行
即便與客戶、團隊溝通好目標,但後續執行卻常遇到供應商或贊助商等利害關係人的意見加入,造成專案需求不斷增加。《學會專案管理的 12 堂課》指出,有這樣的狀況是因為組織內各部門的利益不一致。舉例來說,一項避免水庫淤積,而興建攔砂壩的專案,水利局會想要用最划算的成本興建完成,但當地村長,則會希望攔砂壩上頭增建行人陸橋、涼亭,當地居民才不會覺得工程破壞景觀,於是專案很容易因為多方干擾,需求膨脹,浪費許多資源。
此時除了透過利害關係人矩陣,平衡為達原本專案目標,需維繫的權力關係外,還可透過「目標與關鍵結果」(OKR,objectives and key results)的方式對標,讓專案不因閒雜人等的要求偏離計畫。
《產品專案管理全書》舉例,如果是一項設計 App 的專案,用戶體驗團隊在乎介面互動功能、工程部門則在乎程式編碼夠不夠安全,以避免駭客攻擊。這時專案領導者應聚集不同部門,溝通專案的頂層目標(objectives)為何,將原本各自在乎的指標,整合成從大目標拆分下來的關鍵結果(key results),協調不同職級、部門的利益。