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