辛苦做出來的報告,老闆才看了兩頁就說缺了太多東西,丟回來叫你重寫。 
一個客戶管理系統,依進度執行到驗收階段,程式設計師準時將程式寫完了,但驗收時出現了數十個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

Blog:http://www.dotblogs.com.tw/jimmyyu/Default.aspx

 

comments

登入

會員消息

最新消息 (站長有話跟你說)

線上直播專區

■追蹤PM編『互動圖文』讓你無痛學習

■註冊為新會員可以獲得專案點數10點

■不要用手機下載範本!

■記得每天登入有一點,

■怎麼註冊?怎麼輸入點數序號?

■忘記密碼嗎?快點來信

■找文章請善用『搜尋』功能

■點我闖關搶點數~

■點我去範本軍火庫