標題是個笑話來著,但是如果你看不懂的話
就~~用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可以產出即可,畢竟大家語言可能不同,但是行為上
會是一樣的吧?
最後如果你的團隊,不擅長留文件,或是產出文件,這個時候最好是要畫圖,然後多問幾個人了解環境設定。
跟需求的真正定義,再結合系統環境和架構,切記在真正確認跟了解需求之前不要動作。
寧可慢一點,也不要做錯再去修。 推薦多做紀錄,留文件,不是因為要給廠商是也可以便於管理自己的時間。
以上
明天來說說什麼好呢? 上班時間?