[專案管理]要五毛給一塊,關於交付產出的認定

在專案執行過程中,在每個工作項中,我們一般會定義「交付產出物」,也就是完成這項工作後會產生的結果,將此結果交予下手,讓下手可以執行他的工作,例如在開發一個系統時,SA交付給SD的就是系統分析規格,裡頭可能包含了系統結構、模組、介面、主要需求描述、需求配置等等內容,這些就是SA階段的交付產出物,而SD可透過這些來自SA的產出物往下開立SD規格。



辛苦做出來的報告,老闆才看了兩頁就說缺了太多東西,丟回來叫你重寫。
一個客戶管理系統,依進度執行到驗收階段,程式設計師準時將程式寫完了,但驗收時出現了數十個bug,結果又花了兩個禮拜才把全部的bug修復完畢。
ㄧ份行銷計劃書,花了很多時間寫完,結果老闆說跟我們預計的主軸不合,要你修正,你心理想:「XD,老闆你又沒講清楚」。

以上的狀況是否曾經發生在你的身上,其實這些現象很常在專案中發生,發生的狀況大致有兩種:
1.沒有定義什麼叫「完成」
2.有定義「完成」,但沒有定義什麼叫「做好」

在專案執行過程中,在每個工作項中,我們一般會定義「交付產出物」,也就是完成這項工作後會產生的結果,將此結果交予下手,讓下手可以執行他的工作,例如在開發一個系統時,SA交付給SD的就是系統分析規格,裡頭可能包含了系統結構、模組、介面、主要需求描述、需求配置等等內容,這些就是SA階段的交付產出物,而SD可透過這些來自SA的產出物往下開立SD規格。

如果今天PM沒有規定SA要產出的內容,SA可能只做了基本的需求分析文件,但沒有做介面定義,也沒有做需求配置,只是口頭跟SD說明相關內容,結果SD誤解了SA的意思,做出來的東西與需求不符合,這就會多了許多的重工動作,而如果PM明確的定義了SA要產出以下內容才算「完成」他的工作,那很多問題都可因此解決:
1.系統結構:主要模組間的關聯、與外部系統關連、Use Case
2.模組:主要模組的功能描述
3.介面:模組與模組間、系統與系統間的溝通介面
4.主要需求描述:客戶關係管理主要要實作的大項功能說明
5.需求配置:將需求收集階段所收集到的客戶需求一一配置到模組中,確保客戶的需求在此分析文件中完全被滿足

有了以上的要求,SA大致上就可以依此完成他的SA文件,在工作上,如果你沒有跟member談妥你希望看到的內容,讓member自己去發想,固然可以讓member自己在發想中獲得啟發,但更多的時候你得到的可能是更多的重工與退回,如何在引導與自己發想間抉擇,就必須要視事情的輕重緩急與member的能力而定了;而若你是承接來自主管或者老闆的任務,那你應該要清楚的問到老闆的需求是什麼,若沒搞清楚就下去執行,那你得到的可能就是更多的額外的工作量,因為你還要做很多次的修改,如何明確的定義出「我想要什麼」、「我要交出什麼」,這通常是工作能否順利完成的重點。

而「完成」不等於就是沒有問題的,在事情做完之餘,我們也同時要講究其品質,也就是「做好」這件事,舉例來說,一個系統上線,功能看起來都有了,但就是畫面太陽春、Bug一堆,因為程式趕工交件,雖然完成了你所定義的需求,但卻忽略了品質這個議題,這個系統雖然在專案上定義是「完成」了,但卻沒有做好,因為我們知道一個系統要上線,總不能有太多的bug,所以實際上這個系統還是不能稱之為「完成」,因為當我們把品質的議題列入需求後,滿足品質的測試報告就成了交付產出物的一部分了,程式撰寫人員必須要滿足這個品質需求,若你重視品質議題,那請你在交付產出物中定義此項內容,否則你得到的可能永遠都是一個沒有品質的半成品。

交付產出物的驗收一直都是專案的一部分,也會出現在我們的日常工作中,定義清楚,並確實的做驗收,才不會讓專案失控。

游舒帆 (gipi)

探索原力Co-founder,曾任TutorABC協理與鼎新電腦總監,並曾獲選兩屆微軟最有價值專家 ( MVP ),離開職場後創辦探索原力,致力於協助青少年培養面對未來的能力。認為教育與組織育才其實息息相關,都是在為未來儲備能量,2018年起成立為期一年的專題課程《職涯躍升的關鍵24堂課》,為培養台灣未來的領袖而努力。