iT邦幫忙

2023 iThome 鐵人賽

DAY 24
0
IT管理

好專案 VS 壞專案系列 第 24

【Day 24】好專案VS壞專案-專案實務-起始-客戶不清楚自己的需求(need)

  • 分享至 

  • xImage
  •  

客戶不清楚自己的需求(need)

任何專案一定都有自己的故事,可能是贊助者經過深思熟慮後制定的戰略目標,也可能是靈光乍現的實驗。不論是因為什麼因素要啟動一個專案,都一定會經歷從無到有的過程,而把抽象概念具體化的過程,就是「需求訪談」。訪談過程經常發生一個有趣的現象,需求提出者認為自己已經把需求講得很清楚,但是實做者卻認為User講的很模糊。甚至常常好不容易把User隱含的需求發展成需求規格書後,User單位還是不確定那是不是他要的。PM在此時最重要的任務就是把虛無飄渺的內容,確確實實的具體化並請與User達成共識,此步驟做的確實才能最大程度上降低專案範疇潛變(Scope Creep)的機率。

【壞專案】
曾經有個專案跨了三個處,目標是要建置一個新系統,所有人要討論出統一個規格。一個單位要權限卡控、一個要速度快、一個要搜尋精準,然後各單位就開始虛無飄渺的抽象思考,然後彼此雖然用同一個詞,卻有完全不同的詮釋,整場會議下來4個小時,卻連一個需求都確定不下來。

下一場會議開始,討論的內容又加了新的素材,細問之下原來是他們長官又有新的想法。之後每一場會議都會有新的題材加進來,在此起彼落聲中編織美好的需求想像,於是需求範圍不斷擴大到無法定案的情況。

過程中開發單位處於被動狀態,認為等User單位釐清處需求後,只要按照需求規格書開發就好。於是需求不斷發散,甚至到了一個地步,許多需求在現實的技術能力根本無法實踐。但由於開發單位的消極參與,也沒有仔細了解需求,直到開發遇到了瓶頸才慌張的反應需求無法實做。於是額外加開會議,重新更改專案需求,過程中又另闢蹊徑,在原需求上鍍金(有更好但沒有也行)。由於IT一個單位要面對三個User單位的需求,不願意在爭論需求上起衝突,於是只要提出的需求都照單全收,以致範疇不斷擴大。最終當然是以delay收場。

【好專案】
另一個專案,從一開始需求訪談時,便要求各方透過白板板書或PPT圖像化具體討論。當User單位講述抽象的概念後,PM立刻透過筆在白板上畫出概念,並依此向User當場確認正確與否。第一場會議結束後,即透過PPT或word將概念化成圖像做成紀錄,未來的每一場會議,都根據現有的圖像進行調改。不論User單位如何變化,各單位都能根據具體圖像來思考是否能實做與是否為需求單位的終極目標樣貌。

需求訪談過程中開發單位積極參與,會在User單位Brain Storming的過程中起到緩衝的作用,讓需求不會過度發散。遇到不可執行的情況,馬上出來詳細說明做不到的緣由;遇到User單位鍍金的情況,立刻詢問此鍍金的原因為何?是個人的主觀認知,還是另有Key man在背後遙控?若是主觀認知,開發單位會積極說服需求單位不要鍍金;若是有Key man,則會直接邀約Key man參與會議討論,雙方達成共識後將決議折成會議紀錄備查。

若是遇到某些單位需要內部討論後,才能給出進一步回覆的情況。PM一定會主動提出deadline,以確保開發單位有充足的時間進行開發,不會因為User單位無限制的討論期程,導致開發單位長期熬夜加班的惡性循環。

最終團隊歷經千辛萬苦完成了需求規格書,PM會請各單位利害關係人簽名畫押,不論是親筆簽名或email,會留下紀錄並通知所有利害關係人,未來產品的長相將依照需求規格書來進行比對。

【點評】
限定範疇的邊界就是專案成功的保證。一個沒有邊界的專案,可以確定100%會delay,如果你熬夜加班、加人,最終趕在deadline前完成,要不是原本就有預抓buffer,要不就是專案還不夠大,可以透過死亡行軍來蠻幹。

需求訪談不是一起參加同一場會議,讓User自行Brain storming就可以完事,它更是尋求共識的過程。當大家因為一個概念而有衝突時,那是現實與理想的衝突。千萬不要為了一時的和平,而輕易答應根本無法實現的需求。不然,你以為你在維繫專案的情誼,其實長期來講你在破壞的信任。

需求訪談是一個將願景與想像「固化」的過程,這個過程非常需要開發單位的參與。User單位是一個接觸終端產品的單位,經常接觸市面上一堆業務語言的推銷。業務員會把一些潮流的prototype拿來,當成已經完成且能落地的產品來銷售。此時開發單位扮演一個極為重要的角色,即擔當專業顧問,讓User單位知道,不是最新的技術就是最好的。最適合公司情境的需求規格才是最好的需求規格。

一個PM如果從來沒因為需求訪談跟User單位起衝突,別說你真正參與過需求訪談。對比無聲的和諧,爭執是激烈的溝通。有溝通的戰爭,永遠勝過沒溝通的和平。透過溝通,把不明確的範疇界線界定出來,讓User單位與開發單位拉在同一條基準線上,才能明確定義清楚的允收條件(acceptance criteria),可以確保專案達成什麼目標才能結束專案。

※PM_Coach目標:以成為「專案管理達人」為志業
歡迎加入Line社群(可匿名)討論專案管理
https://line.me/ti/g2/PaE0x_gPBuzIReP982aWwSphbpjx81Zw-LMlWg?utm_source=invitation&utm_medium=link_copy&utm_campaign=default
可掃QR code如下
https://ithelp.ithome.com.tw/upload/images/20230924/20161996HJI2aZY9qh.jpg


上一篇
【Day 23】好專案VS壞專案-專案實務-起始-成員人力不足
下一篇
【Day 25】好專案VS壞專案-專案實務-計畫-沒有Charter或SOW
系列文
好專案 VS 壞專案30
圖片
  直播研討會
圖片
{{ item.channelVendor }} {{ item.webinarstarted }} |
{{ formatDate(item.duration) }}
直播中

尚未有邦友留言

立即登入留言