今天先不講流水帳，來說說每個工程師或是PM都很頭痛的問題

那就是估時程!! 我想也許對資深工程師來說，應該不太是問題。

且慢， 資深? 資深的定義是?

身為軟體工作人員，我們的首要條件就是大家討論的時候要有共同的基準點。

畢竟我們的成果在做出來之前，都是看不見跟摸不著，總不能只說著 "發大財"這樣吧。

不管你用什麼方法，用UML畫圖，還是給很詳盡的文件SPEC，建立彼此溝通的準則是談時程的基本。

資深??

關於資深工程師，我自己的定義是這樣，絕對不是年資，而是專案資歷。

再更進階一點的是，同類型的專案經歷。

這個定義我覺得其來有自，相信大家都聽過一個故事，有三個工程師，一個資深，一個是天才

一個是資質駑鈍的代表可以說就是我啦，共同接受到一個要求。

抽象化一點就是穿過一片埋有地雷的陣地，平安到達對面，且比誰用最少的時間。

首先是天才型代表，很有自信地往前衝去，一路上雖然觸動不少地雷，但是各種花俏閃躲。

根本就是閃避點滿，加風騷走位，儼然就是搭配舞孃的歌詞:「旋轉，跳躍，我閉著眼」。

花了一個上午的時間，順利完成任務，雖然地雷有引爆但是對人沒有什麼影響。

再來就是一般工程師，單兵全副武裝，手持掃雷器，緩緩漫步前行，雖然差點觸碰到地雷。

但是最後還是化險為夷，但是整整花了十二小時。等他到達對面，測驗已經結束了。

最後是資深工程師，只見他一派輕鬆，大步一邁就這樣緩步走過。

全程加上抽菸，喝茶，跟主考官聊天，還順便幫忙拔草。

只花了一個多小時。

路人工程師，用崇拜的眼神看著他問說:您究竟是如何辦到的?

資深工程師回答:很簡單啊，因為我一開始就沒有埋地雷。

光看到這邊可能又會以為是什麼神話，或是要講心態論，各種雞湯之類的。

不過抱歉各位，如果我要給各位雞湯我會直接揪團煮一鍋，最近天氣也涼了啊。

以前剛入行，或是我在外面觀望的時候我也覺得這種文都是各種仙拚仙，看久了看多了

就跟用磁鐵在硬碟上編出一個win95，或是linux 一樣的唬爛廢文。

但是在這行時間越久，我發覺真的有些人可以做到這樣。

這些人不一定有很久年資，也不一定是會寫出很神的演算法。

但是他們對於整個程式運作流程，卻都是了然於胸的，他可能不知道這個語言，或是framewrok的細節

但是對於OOP，還有restful,rpc 等等的流程跟規定卻都很清楚。

有的時候儼然就是一本行走的RFC，其實雖然我在業界翻滾五年，對於時程上的掌控度

我其實是沒有很高的把握的，一直到這一年，我覺得我突然想通很多事情。

主要是我自己個性也很發散，當自己置身其中的時候就不夠客觀，又因為冒牌者效應

力求表現跟證明，最後就導致自己陷入了失去流程理解跟控制的心態。

說到這裡，我們的重點出現了，要學會估計時程然後越來越熟練之前。

我們要具備的首要條件就是，你對整體開發流程的掌握度要夠。

什麼叫夠呢? 說到開發流程一定又會有人開始敏捷跟瀑布分流了，或是隕石。

但是這個都太大塊了太遠了，不是我要說的尺度內。

先讓我們回到餐飲業，廚房最重要的只有兩件事情，一是安全，二是衛生。

安全是廚師個人對技術上的要求跟修養，而在廚房的業態發展了幾千年的現代社會，我們借鑑了同樣工程界做法。

還是從NASA拿來的。

那就是 HACCP（Hazard Analysis Critical Control Point）危害分析重要管制點

任何東西有縮寫感覺都很高大上，但是其實他的涵義跟初衷很簡單，甚至可以說是單純。

基本上就是對流程進行節點控管，將整個食品食物餐點產出，切分成各種階段，並且找出其中最有可能
產生危害的危機點。

這種從源頭控管的作法，讓太空人免於在太空中拉肚子。

在廚房具體的做法就是，by partition 做各種的生菌數，溫度，儲存時間，採樣化驗等等的控管。

而這些又會根據各種食材的特性相對應的儲存方式去做特化變化。

運送過程，廚房用的冷鏈..等等的。

那麼如何找出，哪段流程是關鍵點呢? 這點就是看制定準則的人的經驗跟素養

也就我前面對於資深的定義，他不一定要年資很深，但是要對這個程式的行為有一定熟悉程度。

也就是要清楚地知道，要做什麼，怎麼做，跟為什麼。

方法論的話我覺得UML大概就是循序圖，跟流程圖，但我覺得遠在走到這步之前。

其實，拿管理上的5W，跟SWOT來做基礎的分析，也滿有用的。

說到這裡，有點小小的心得就是，雖然各種業態會有各種不同的Domain

但是流程控管的面相來說太體上是相同的，舉一個簡單的例子來說，假設是開發一隻登入的服務

如果我是用5W的方法

Why

該需求需要處理的問題是? 「為什麼要這麼做？理由何在？原因是什麼？」

What

實際上做了什麼? 甚至是我可以選用那些技術? API WEBSERVICE 還是WCF 
「requset 是需要哪些 ， response需要那些?」可以衍伸出資料要怎麼處理

Who

「是client to server 還是 server 對 server?」 「由誰來發起？誰來完成？」
 
 

When

什麼時候會有這行為 是否會頻繁的存取該服務   「什麼時間完成？什麼時機最適宜？」     
如果是頻繁存取，頻率? 量級? 我該不該做cache機制? 前端做還是後端做?

Where

「服務存放在哪裡? 地端，雲端? 這個服務是屬於前台，中台，還是後台的服務?
或是使用者從哪裡存取? 我的服務是否直接露出? 還是要透過 NGIX代理? 」

以上每一項都可以衍伸出整段的流程，跟當中的各項節點

在這些盤出來以後，再去針對這些節點做SWOT分析。

你就可以得到比較完整流程，跟知道當中可能會埋有什麼地雷，也可以根據自身的能力和時間。

比方說是否有哪些跨組溝通的難點，技術上的選用，甚至是熟悉新技術上的時間。

需求上是否有哪些不清楚的地方，要不要再去做相關的確認?

還有其他庶務會耽擱到你的時間，排除這些後的工時估計，才會比較精準。

當然還會有些人事上的軟釘子，不管是其他組別的主管，還是老闆，或是客戶的。

不過，在我靜下心跟釐清這些之後，其實這跟我當初在飯店初宴會，或是外燴

甚至是自助餐開餐前，內外場主管都燴根據預定客數跟來客數

還有天氣，來估計今日備餐的量跟PT人數。

甚至可以估計出大概要多久可以下班XD

其實今年以前，我也是抱持著那種開發時期

該花多少時間就花多少時間的人，現在回想起來不免有點甩態。

可能除非是碰到了算法或是資料尺度的問題，其他大部分的開發時跟問題

應該都可以靠這個來做速度上跟時間上的估計才對。

當然，這是我目前的理解，如果是這幾年很有名X山的案子也有可能仆街。

但是我們不知道內情所以就只能霧裡看花了。

總之呢，今年為止到目前，在開發上覺得在面臨到技術的問題之前。

這些東西也應該要做好，畢竟從商業面的考量說，時間對公司來說就是金錢。

在廚房也是，PT多請了，時間拉長了，貨多叫了，餐點多準備了有剩餘。

都是消耗跟浪費。 以上大概是轉職到現在對時程的一些體會吧。

也期許在未來的路上，可以成為一個估計時程很精準的開發者，這也代表了

你對自己要做什麼，怎麼做，跟有哪些點可能會面臨問題跟技術選擇上有一定的了解跟自信了。

如果這次不準，那就去思考看看自己漏了什麼? 一次次求進步這樣。

其實，當你放遠一點跳出來看，會發覺得這些其實都是一些很基本的工作法則。

但是，當你在身陷在開發的過程中，時間壓力跟技術和流程不熟，就會很大的擾亂你。

今天有提到冒牌者症候群，這個我決定明天來講一下，在轉職的初期即便我有很強大的自信跟自我

追求(本人人生追求不二過)，還是會因為踩到雷，覺得自己真的是不行啊

好想當個海藻這樣.....

以上，就是今日的分享，之後應該還會針對，時間管理寫一篇吧，這完全就是我的死穴至今也還在面對。

如果人生GAME是機器人大戰，我大概就是熱血跟拖延點滿的人。

很多點子都在腦中徘徊，但是就像新創圈的那句話，好點子不值錢，做出來的點子才值錢。

好，明天讓我們來談談，輕薄的假象，冒牌者症候群。