誰該清楚客戶需求？需求和規格，到底是啥？

這邊我認為該釐清的是，何謂需求？何謂規格？
我個人認為，需求即為客戶問題和需求。規格即為客戶環境限制和我們建議的藥方。環境限制該如何知道，應於系統分析前，就應該從客戶端詢問和確認，不是嗎？但我現在遇到的問題，居然都說「業務沒跟我說」，這是何等的廢話。但業務單位應不應當協助，當然應當。假設說，技術人員一直就開發環境的限制尋求明確的定案，客戶或是相關人員不願意說明，自然這個時候業務才需要出馬，但我看到的狀況都是…應對能力的不足（或是不願意），假設得到到了某個錯誤的規格訊息從客戶端，那出了問題，自然就應該要抱怨回去，請其取得「正確的資訊」，而不是在家哭著說「他們給我的資料好像都是錯！」。這簡直莫名其妙！

何謂時效性？何謂正確性？轉述或是傳述，到底是能把事情正確的做好？還是只是一個推託責任的工作手段？

如何清楚的釐清需求和規格？最終目標不就是「你們的驗收依據為何？」不是嗎？

真的匪夷所思…。但也無所謂啦～
我現在的目標，就是努力讓每個人在自己的位子能夠把自己的事情作對！講個不要臉一點的，也許我也太看得起自己，我現在似乎在幹那些主管們應該做的事情。主管的責任，不就是要領導下屬，用對的作法把目標完成嗎？但…很可惜我看不到這樣的現象…。而是每叫一次，才走一步，也許只是安撫…也許又像過往一樣，我只是配合用個案處理…。

這是文化嗎？哪們子的文化？不能理解。

這個工作單制度很屌詭

在我處得公司有種類似『工作單』的制度，類似像是派工單一類的東西，用以在於業務端和技術端，在溝通時最後有個工作的依據。但奇怪的就是在這個地方了。你說這樣的工作模式，就沒有衝突或是溝通變得比較好嗎？事實上，一點都沒有…舉例吧：

1. 業務口頭溝通的需求，未寫入工作單需求項目
2. 業務口頭溝通的需求，未涵蓋工作單所有項目
3. 業務口頭溝通的需求，與工作單需求項目理解不符

我就很想問啦～如果又要口頭溝通和工作單，到底最後依據那種方式為主呢？依照現在的企業習慣，是要工作單為主。但實際上，不管誰都是貪方便，弄下來工作單不過就是一個用來『你捅我，我捅你』的小東西。完全沒有發揮原本設計他的意義。今天傍晚，就一整個溝通和處理這樣的miss。說真的，這次發生的錯誤，真的頗大，如果真要鬧大，那張單子有簽名的主管，各個都要倒楣。和同事決定，私下就把單子退了吧～叫對方重新發一張新的，另外把該做的東西處理處理…。

當工作程序出現這樣大的紕露，那是否該檢討成因和預防方式呢？也許我該找我同事們討論，but whatever…那些傢伙肯定進到會議室就互槓，一點問題都解決不來。

我認為的問題…

• 首先『需求管理』，如何正確的、簡單的、清楚的將所有的需求轉述給執行單位，並讓執行單位清楚知道自己應該處理何種問題，做何種工作，應該是第一要務。
• 第二在於溝通時的工作協議範圍，是否應該重新檢討前述的需求，並比對後面溝通的項目，確實的紀錄下差異，作為後續工作check的依據。
• 最後在工作產出時，是否有一份check lists確保工作產出沒有遺漏或是錯誤。

但或許說來簡單，做來難…但我深深相信沒有踏出嚐試的第一步，也沒有任何改善的機會啊！