2021年12月15日星期三

面對一句話的需求,該如何開展項目?

自大學畢業後,出來基本上都是做項目管理的工作,有做過只有3個人做的小型項目,也有做過整個機構動員超過200人參與,橫跨數年的項目。不過,項目大與小本身不是問題,問題是那些需求不清不楚的項目。而隨着項目變大,這種情況更是經常出現。

很多時在大型項目上,尤其牽涉跨團隊跨部門那種,都會出現需求良莠不齊的情況。有些需求寫得很仔細,也有些寫得很粗淺。最粗淺的做法,是用一句說話概括一個開發項。 

例如說,需要一個報表,但沒有提邏輯,也沒有明細,甚至乎給誰看,報表有些什麼主要內容也不定義。又例如說,要一個審批流程,不定義流程內有什麼節點角色,如何啟動流程,更不提流程的目的和定位。

通常遇到這些情況,都會說是因為時間所限,或者不希望需求書太長,或容後再談,實際上是沒有做好範圍管理,到要正式開發時就出現大量修改,更差的是到測試驗收時才說與需求不符。

遇到這種情況,如果開發項是不太重要且能夠拆出來容後上線的倒還好,如果是重點項或必要項,即必須要在上線第一天就要完成的,項目周期也會因而大失預算。 

故此,需求質量絕對是項目管理上的一個重要課題。對於那些只粗淺提出一句話的,我們或者可以先稱之為「訴求」,而不是「需求」。

一般來說,「訴求」會有幾種特徵。

有的是沒有主體,例如看完也不理解服務的目標和價值。有些會寫參考XXX的,雖不清楚XXX的內容和底細,總之就是先抄過來再說,反正不是自己做。

大多的則是沒有內容,例如缺乏業務邏輯、公式運算、流程,或與用戶之間的互動等。而最經典的「訴求」例子,是更換一個系統,所有流程保持不變。

實際上,只有一句話的所謂「需求」,是真的不可能開展項目的。只有一句話的,可以視為「目標」,但這也是不可能達到的目標。就連需求也未能清晰定義的話,項目內出現差錯的機會實在太大,重新做的成本也太高,不如稱之為「喊口號」算了。

那麼,如何可以從本質上判斷出一段話是屬於「訴求」還是「需求」? 以下有兩個基本準則可作為參考。

一個準則是可估算。

就以家居裝修工程為例,我們向裝修工程公司提出需求後,一般會期望工程公司給出報價單。理想的情況,是報價單上能單點列出各個裝修項目的費用,所需材料及費用亦分項列出。

按照報價單上的明細,我們可以大致判斷出工程範圍是否有遺漏,或者有沒有一些地方需要釐清,動工前互相簽字作實,成為有法律效力的文件。

不過,基於經驗的不足,很多首次做裝修的用家,也會提出一些類近「目標」的訴求,例如要一個全白色的廚房,不提廚櫃間隔,不提是否要熱水裝置,就連生火煮食打算用電磁爐或煤氣爐也不定義,哪些家電放入廚房又不知。對工程公司來說,這種客戶的真正「需求」真的是難以想像。

當然,正常的工程公司遇到這種客戶,一般會先按經驗提出一些問題,嘗試引導客戶給多一點明細資訊。但如果客戶仍然只打算以回答問題形式打發,而不重新詳細考慮的話,有良心的公司應會寧願不接項目,也不會冒法律或聲譽風險去接手。

至於沒有良心的,則可能會先開一個大數,到用盡預算後就說是需求沒有提,當做項目變更項處理並另行收費。這種情形,項目大失預算,超時超支和重做,都是可以預期的事。

至於另一個準則是可測試。

作為提交「需求」的用家,可在制定需求時就開始制定測試計劃。因為,優質的「需求」,應該都是可測試的。

事實上,在制定需求時就制定測試計劃,最主要是協助團隊去想清楚開發項可如何驗收,如何才可稱之為完成。

套用以上的裝修工程做例子,除非閣下真的只需要一個白色的廚房,例如用來做拍攝場地佈景,正常來說也應該會想出一系列確認完工的標準,或者說得出哪些事情希望在廚房內完成。把這些標準和場景也同時向工程公司提出的話,絕對有助於工程公司理解真正的用戶需求。

以上的兩個原則其實不難理解,不過在真實的辦公環境,則還是經常會出現偏差。 

眾多因素中,時間限制往往是一個主要因素。趕期、不夠時間、以後再算,辦公環境內經常都會出現類似的表述。而問題的根源,還是在於團隊以舊式部門思維,而非真正的產品思維去營運業務。

舊式部門思維配以流程形式,把項目各個階段當做流程般管理。從需求到開發,到測試到上線,各個階段由不同部門負責。如果各部門都以「交功課」心態處理,就很容易出現「我只是負責提需求」的心態,和那種「要一個全白色的廚房」的訴求。

從長遠產品角度出發,我們應可以清晰地認識,今日走偏門省下的時間,將來有朝一日還是要還的,從來也沒有例外。需求階段的馬虎了事,多數是在開發或測試階段原本奉還。

只不過,在傳統機構的部門架構下,把問題送了去另一個部門,有時真的是可以省下自身的時間的,也讓不少人會禁不住誘惑去嘗試。不過,這真的絕對不是可長遠維持的,也會造成團隊之間失去信任,只適合短視之徒。 

要做好需求,我們實際上要做的是回歸基本、實幹,和做正確的事,用一部一腳印的方式去做好產品開發的每一步。最難的是下地幹活,最簡單的也是。真正把產品作為團隊的核心,減少在項目裹仍然以部門作為界線,是較可行的做法。

沒有留言:

發佈留言