標題是個笑話來著，但是如果你看不懂的話

就~~用POST看看吧，新的十篇應該會是職場篇啦，今天會選這個標題主要也是想要銜接一下前幾篇

需求跟時程問題的另外一個重大因素，就是溝通，很多人看到可能會想，不就是開會嘛?

有SPEC，有文件，開過會有會議記錄但是最後，還是我不懂你的明白，你不解我的感受這樣。

在我剛去工作的時候，因為覺得自己剛轉職要拿出12萬分的拚勁跟力氣去證明自己，所以戰戰兢兢搞得自己壓力很大。

常常會搞錯需求的方向，最常發生的就是，架構上跟流程上還沒有理清楚就開始要刻個功能出來。

有時候會發生，自己覺得功能做完了，但是要驗收交付的時候怎麼跟需求不一樣? 好加在當時主管時間都抓得很鬆

還可重新理清楚再火速產生一版。 解決這種問題最好，也最直接的辦法就是畫圖。

不用到UML，而是用圖增加你們彼此溝通的理解程度。可能會沾到一點流程跟循序的邊。

不過你可以簡單表示這樣，資料流的走向是往哪裡，request 跟相對應的response是什麼?

DB真正該撈的是什麼? 再來思考，可以在現成的程式上重構作修改嗎? 一開始進去新公司是寫store procedure

最常發生的事情就是沒有做對需求，往往花了時間但是沒有達到應有產出，不僅自己洩氣，還會拖累到團隊的時間。

除了跟組內同事溝通外，再來就是跟USER溝通，不過初期也是看SPEC工作。一直到後來有擔任過SA角色後，才會去盤點

紀錄需求，也因為軟體部分摸不著，也看不到，你的儲存可能定義上就不等於我的儲存。 如果再遇見多DB，複數環境

多不同網段，有時候會真的很讓人感受到壓力，跟困惑，有陣子我都會覺得，我究竟是在寫程式，還是在tun環境。

所以，不管是對外溝通，或是橫向溝通都是需要做紀錄跟精細化的，我是滿推薦用筆記的，可以速記這樣。

現在手機也越來越方便，微軟的onenote ，或是GOOGLE線上筆記跟表單， 都是很好的選擇，我也還是會帶筆記本。

速記之後，回來再花時間理清楚一下，然後作紀錄，有問題的話就發個mail問一下，有結論後再CC給相關人員。

大家都確認清楚之後再開始動作，比較不會發生牛頭不對馬嘴，東西做出來不符合需求的情形。

在進這行之初，甚至現在有時候，即便是在已經做了紀錄，但是每天一睡醒進開始要工作的時候，還是會有一下摸不清

楚。所以養成作紀錄的好習慣，除了可以幫助自己理解，將來有維護需求還可以去查找一下，一些舊有的規則，最常見

的是金融體系裏面配合監管法令修改，那常常會看見在SQL COMMAND 加上因應法規修改怎樣的註解。

也會有，before跟after的紀錄，command,還有異動後資料這樣，留存文檔。雖然繁文縟節，感覺很麻煩。

但是當真正有需要的時候，你就會覺得，哇!! 好在有他!!

然後再回到溝通，我會建議，先確認好整個功能相關資料流的走向，來去，目的才不會發生去錯地方的情形，或是撈不對資料庫。

也才知道要去哪裡找資料，然後不要急，這個滿重要的。要顧慮到系統的方方面面，團隊的好壞都是來自於這裡。

另外開發中，有問題盡可能馬上確認，不管事在通訊軟體上或信件上，如果這件事情會影響到你工作，就真的一定要確認。

因為就在你在操場上畫圖一樣，一不小心就會偏非常遠，那時候如果加時間修的回來還好，最怕是錯誤已經造成。

那就只能期望說，DB backup 可以做得很好，也沒有空窗期。不然真的會很刺激。

好在，我還算幸運。在我的職場小年輕生涯中，沒有發生過從刪庫到跑路，但是真的是在需求上有時候彼此的理解真的

會有誤差，我已建議團隊一定要有圖說，太詳細的spec我覺得就看個人，但是架構上的流程上的，盡可能不要單純用

文字去描述，有方向性的圖說，勝過千言萬語，還有注解，DTO部分對應的property也應該要有相關的加注。

這樣的話在整體多人開發，橫向溝通上可以省下很多事情，然後時時關心同事。如果覺得文件檔跟圖片，沒有集中很麻煩。

其實現在各大GIT類型的服務都有提供相對應的功能，甚至還有WIKI可以自己自建使用。

我一直是覺得，不用強背程式碼，基本流程的pseudo code可以產出即可，畢竟大家語言可能不同，但是行為上
會是一樣的吧?

最後如果你的團隊，不擅長留文件，或是產出文件，這個時候最好是要畫圖，然後多問幾個人了解環境設定。

跟需求的真正定義，再結合系統環境和架構，切記在真正確認跟了解需求之前不要動作。

寧可慢一點，也不要做錯再去修。 推薦多做紀錄，留文件，不是因為要給廠商是也可以便於管理自己的時間。

以上

明天來說說什麼好呢? 上班時間?