顯示具有 資訊產業 標籤的文章。 顯示所有文章
顯示具有 資訊產業 標籤的文章。 顯示所有文章

8/07/2017

快速學習技能 - 解決職場困境


快速學習工作上需要的技能,而技能與知識同時成長,是在職場上能空出時間,進而控制時間的最好方式。

在這世界裡,「在N小時內學會XXX」的書籍研討會不在少數。這些都很有參考價值,然而,學習是非常「個人化」的事情。例如:國高中花很多時間在補習班的學生不在少數,但真能夠發揮補習的目的 - 也就是考上最好的學校 - 卻僅有少數。

有些書籍,宣稱找到共通的方式可以在N小時內,學習「任何」技能。並且當然以自己過去一年學習到的技能,作為鐵 證 (參考文末的註1)。不過,共通的方法都僅能參考,每個人終究都還是需要找到自己的方式 - 只要是真的想學。

在職場工作,會遇到的困境很多,有很大一部分是「人」的問題。但無論哪種問題,如果你是個「技術上的狠角色」,你就有很大的機會撇除人的問題。即使無法排除,擁有更多技能,就表示有更多選擇 - 大不了就是離開現在的環境。

技能的快速學習,首要之務,應該是找到自己的方法。

在還沒找到之前,或者,自己現有的方法似乎有所侷限。倒是可以考慮以低成本的方式,嘗試一下各個企業巫醫所提供的方式。

重點在於:有方法遠比沒方法好!

以下是幾個常見共通步驟與確切花費時間:


(1) 原因與目標確立

不知為何而戰,當然容易半途而廢。

有些原因很清楚,例如:目前會寫java,而現在因為工作需要學習Scala。有些是個人喜好,例如:常喜歡去日本旅行,想學基本對話比較方便。有些則是好奇性質,例如:聽說Big Data大數據分析很紅?不知道到底是那是什麼。有些技術是「執照類型」:例如開怪手,駕駛遊艇。

無論是哪種原因,需要一個簡單的目標,例如:學會Scala,了解Big Data,學會日文會話,學開船等等

不應該花太多時間在目標確立,最多0.5小時。



(2) 階段性成果確立


長期預測是很難,而且接近不可能。因此,快速而踏實的方式是計畫階段性成果。

階段性成果指的是一個「可以衡量的」,「有意義的」,「可展現的」,「務實的」極短期目標。

所謂極短期,是指20小時之內:也就是禮拜一到禮拜五,每天2小時,連續兩週。

這並不是指,超過20小時就是太多,也非20小時就能夠變成專家。而是必須要讓自己在20小時內「有所成果」。

舉一些例子如下:

Scala:撰寫網路爬蟲程式,可針對wiki做特定字串資料檢索和統計。

日文會話:用日文會話辦理飯店check-in,詢問餐廳資訊和找路。

Big Data大數據:選擇並且看完三本大數據的科普書籍。

學開船:考取動力小船執照


階段性成果的確立,其實和每個人對該技能瞭解程度的不同而有所有不同。了解的越淺,就會訂出越模糊的階段性成果。但其實無妨。因為這只是第一階段的成果而已。

其實,要能確立階段性成果,某種程度已經完成一個小型計畫。計劃本身是死的,「做計劃」這件事情才是重點。這個階段應該花費3-4小時的時間。


(3) 找到練習與取得知識的方式



取得知識和練習的方式非常重要。這方式必須要同時符合「階段性成果」和「目標」。

要快速學習知識和技能,必須「專心花一點時間」得先找確切練習方式,取得知識材料,和額外獲得協助的地方。

取得知識最踏實而且快速的方式,其實還是圖書館。先考慮,或者試用一下圖書館堆書法(參考這裡)。

然而,許多技能是需要練習的。例如:寫程式,學日文,Linux操作等等,就需要找到最適合自己的練習方式。

以學會寫Scala程式而言:即便只是做個簡單的網路爬蟲,仍要再細分小階段,先準備環境,簡單了解語法,知道怎麼使用Scala來執行http get...等等。每個練習的動作,都是為了達到階段目標。

以學日文會話而言:最好而且便宜的方式應該是「馬上去找」語言交換。其次則是去借幾本基本會話的書,再加上幾個app/網站。(註2)

當然,有些技能最簡要的方式,還是花錢受訓,例如「動力小船駕駛」。這反倒是最簡單的,只要有決心即可。

除了花錢受訓之外,這階段恐怕需要額外的時間,預計6小時是合理的。


步驟(1)到(3),最好是不要花超過8小時,也就是一個假日的時間。


(4) 練習與取得知識


這一階段的重點在於「專注」。如果計畫是兩個星期,共計20小時,則這時候,就該專注於自己決定的方式,無論如何,都要在兩星期/20小時之後來檢視成果。

這也是為什麼,設定階段性成果時間不能太長(註3)。

如果的目標過於抽象,例如要「瞭解什麼是Big Data」,在這段練習與取得知識的過程,就會變得更加含糊不清。以因此,階段性目標才會設定成「看完三本科普書籍」,這樣才能檢視成果。

要讓自己專注的方式有很多:短時間專注可用番茄工作法。長時間則需要計畫與經驗,而目前你在看的這篇文章,實務上就是在解釋,如何將學習技能知識時間專注於學習。

在這個階段,根據計畫的不同有不同的時間。但是切記「越短越好」。如果不確定時間長短,那就以10個小時,每天2小時為準。


(5) 自我評量



必須要有客觀方式自我評量。

因為是自我評量,當然一定要確實。

以學習Scale的第一階段:完成網路爬蟲為例,如果在20小時內完成,那麼就可以有信心的說學習Scale已經前進很多。

以學習日文會話來說:如果可以和日本人測試對談飯店用語,那就表示階段性成功。

再次強調:快速學習技能的階段性成果,必須要以務實為主。許多人在學日文一開始是以背熟50音為第一階段。但這其實不太務實。因為死背永遠是無聊的,而且即便你可以把50因背得滾瓜爛熟,在日文能力 - 特別是會話 - 的務實進展也等於零。




(6) 收成:前進或者換目標



達到目標後,請隨意犒賞自己。

而接下來,就是要決定往下一個階段前進,或者更換目標。

這時候的更換目標,並不是半途而廢,畢竟你已經前進了一段務實的路。這和達不到目的而放棄,無論在心態上,還是事實上都有很大的不同。

往前進的時候,記得也是重複設定一個「短期可達到」的務實目標。

例如:

學習scala,已經完成網路爬蟲程式,接下來的目標是在Spark中,以scala撰寫一個可分析http log的分散式程式。

瞭解Big Data大數據:已經看了三本書,接下來的目標是找一個有意義的主題,寫一篇部落格文章。



這樣的快速學習,真的能解決困境嗎?


快速學習能讓你在職場上,取得更多的「選擇性」,讓你對事物有所掌控。這才是針對困境的真正解決之道。

或者也可以跟我們聯繫取得困境的快速協助。





註1: 有幾個例子

   * Fluent in 3 Months: 三個月內可以流利的學會任何語言。作者甚至示範了中文學習,對外國人來說,學非拼音文字真的難為了他們。

   * The First 20 Hours: How to Learn Anything FAST. 作者示範了如何快速學會各類不一樣的技能:瑜伽,寫程式,風帆板,圍棋...但個人覺得比較難以置信的還是「新鍵盤佈置:colemak 」

   * The 4-hours 系列:作者Tim Ferriss寫的幾本書。內容從健身到創業都有,其中都會涵蓋快速學習的方式。

註2: 請參考Fluent in 3 Months 一書

註3: 當然如果你是想考動力小船執照,由於上課時間是固定,當然沒辦法「更快」。

8/04/2017

不玩一樣的遊戲 - 準備面試的真正技術


程式設計師如何在面試中展現真正價值:最好的方式當然是不要跟其他人玩一樣的遊戲,也就是在面試中,找出幾個能突顯自己技術能力的要點。針對這些要點,做延伸性的準備。




不管什麼原因,當一個軟體工程師下定決心要換工作時(註1 ),面試通常是免不了的。

作為軟體工程師,鐵定會上網搜尋各種「面試技巧」文章。

例如:常見面試問題的最佳回答:這篇或者這篇。也有些人會說,面試除了回答問題,更重要的還是會問對問題,例如這篇

但是,人資與主管,通常比面試者更知道這些所謂「標準問題」。也很清楚面試者可能會去找的「標準答案」。這些面試技巧文章只是一再重複大家都知道的常識,多複習這些常識是有很大的好處,至少可以避免緊張或者不必要的誤解。

但常識不會是關鍵。


在面試的時候,除了回答標準問題之外,最重要的是「確實展示自己的價值」才是關鍵。

軟體工程師/程式設計師的價值展現,其實第一時間點是在「看履歷表」的時候。短暫的面試時間是在「檢查履歷的正確性」。假設面試者的履歷寫的中規中矩,沒有什麼誇大,也沒有過度謙虛(註2),會讓你進入面試階段,就表示在履歷表上展示的技術能力是公司願意接受的。

面試展示自己的價值,通常是在幾個關鍵點。而這些關鍵點,都是「面試之前」可以先做好準備的。

(1) 應答技術問題
(2) 解釋過去做的事跡
(3) 詢問技術相關的問題


(1)  應答技術問題


大部份的軟體工程師工作,通常都會有程式考試題目。只要你在Leetcode, topcoder之類的網站,用你本來就熟悉的程式語言,多練習幾次,應該就不會太離譜。事實上,技術問題不可能考得過於艱澀 - 因為公司組織通常沒這麼多閒功夫在一個面試者身上。

其他的技術問題應該要根據你在履歷表上的專長做「延伸性」的準備。延伸性準備,才是展現價值的最好方式。

例如,倘若履歷表上你的專長是WebUI,那麼你就得延伸準備到HTTP:至少了解一些重要的header。如果你的專長上有寫Linux,那麼就必須準備回答曾經使用linux做過什麼事情?

如果曾經在linux上架設web server (nginx, apache...),至少也得知道設定檔在哪裡,如何開始停止服務,如何列出執行的行程(process),如何在不得已的時候強迫結束服務。當然,如果你會回答kill -9,最好確實知道為什麼是-9。

應答技術問題的不僅只是「防禦性」告訴面試者你的能力。而透過簡要地回答,「順便」展示自己對技術能力掌握的額外價值。就以上述kill -9為例,以筆者過去15年,面試超過400個人經驗,在履歷表上寫「熟linux」的起碼也有150人。這些面試者,八成都知道kill指令。然而,僅有不到10個人,知道為什麼要用kill -9,並能說明kill預設single 15是比較好的選擇。

在回答簡要技術問題,只要能有正確延伸性的回答,就能展現與他人不同的價值。而這絕對事是先可以準備的。


(2) 解釋過去做的事蹟


只要有2-3年工作經驗,面試時,一定會被詢問過去做了什麼。

因為,要了解未來一個人在組織的貢獻,最好的方式是看他「過去貢獻了什麼」。以下是一些解釋過去事蹟的要點。

** 妥善呈現事實而非感受。


當你已經離職時,過去的事蹟就已經成為「歷史」,而你可以準備的是「妥善呈現歷史的事實」,切勿扭曲或用「感受」呈現。

例如:「在那個專案裡面,幾乎事情都是我在做」。這其實是你的個人感受而非事實。事實必須要用無可扭曲的方式呈現。

又例如:「這個專案扣除html/css之外,前端javascript在git上大約有3萬行左右,其中兩萬五千行是我commit而且到專案結束也都是我負責維護」。這只是說明在程式碼上的「事實」,你並沒有貶低別人的貢獻,因為也許那其他5千行極端重要也說不定,但你也呈現了以code base而言,你的貢獻在事實上絕對不低。

**過去事蹟,絕對可以,而且也絕對需要在面試前妥善準備。


因為,你對過去自己真實貢獻越了解,就越能掌握過去事實。越能掌握過去的事實,就越能表示自己在技術上更有未來潛力。

例如,假設你是IT部門員工,過去都是協助內部系統上線,這些系統其實也是外包商提供。在面試時,被詢問做的內容,如果只是簡短回答「將公司委外開發的系統上線」當然也是可以。

但如果你在事實上,也會做「自動化檢測系統」「建構上線風險評估」「上線後的使用分析」「成本分析」以及「有沒有達到預期目的評估」,這些才是IT真正產生價值,並且與眾不同的地方。

最好的情況會是,公司之前並沒有此做法,而是你主動完成這些有價值的事,讓公司變得更好。可是,如果你已經離職,來不及產生事實 (當然也不可能去捏造說謊)。那麼,至少還是可以說「當時其實應做自動化檢測系統」,雖然那時候沒有完成,但你也可以在面試自己做一個小規模的自動化檢測系統,而在面試的時候就可以大大方方的說,當時雖然沒做,但是自己覺得應該要做,所以主動在事後做了。

當然這表示你需要在面試前付出時間準備。這樣的付出不會是沒有代價的。即便這次面試沒用到,你所做的事情是不會消失不見,只要是你做的「技術上正確」的事情,未來一定會對你的職業生涯有所助益。



(3) 詢問確實的問題


通常面試的最後,都會給面試者問問題的機會。

許多文章中,的確會說明問問題的重要,例如這篇。有上網查過的面試者,也了解不該問一些瑣碎小事,上下班時間,或者公司基本福利,因為這些問題只是等於打發時間。雖然沒有害處,但是也沒有價值。

軟體工程師最適合的就是詢問有價值的技術相關問題(註3) 。而這些問題也可以讓你稍微判斷此公司的狀況。

基本問題

一些很基本的問題,可以簡單展示你對軟體專案成熟度,也可以讓你了解這個公司的狀況:

* 請問目前是用什麼樣的版本控制系統,管理程式碼?

    該組織用什麼樣的版本控制系統不重要,無論是git, svn, cvs, p4...都可以。重點在於,的確還有些組織連版本控制系統都沒有。

* 請問目前組織是使用哪種專案管理方式?

    最近幾年是流行Agile/Scrum,

* 假如我有幸錄取,前三個月你希望我能完成哪些事情?

    這個問題代表自己的積極程度。主官如果對這個問題講得過於籠統抽象,很有可能該面試官(主管)並非實際的技術管理者。

* 團隊最近一次做code review是什麼時候?
* 團隊的bug追蹤流程目前大概是怎麼做的?
* 目前自動化測試的涵蓋率大約是多少?

    這些問題是展現自己對軟體開發的成熟度。特別注意的是,如果這些問題被籠統的回答,也不需要追根究底找別人麻煩。


進階問題

可能會引發進一步討論,也可能被反問,所以要事先準備被反問時的技術回答。

例如:

* 就現在的資料和面試的情況,您個人覺得會錄取我嗎?

* 最近一次在團隊裡面遇到最大的技術困難是什麼?

* 組織如何判斷成員的技術產出?




高級問題,


很有可能被認為是反過來刁難面試主管的問題。必須斟酌採用。例如: 

* 目前軟體專案程式碼的entropy有多高?

* 目前自動化建構和測試是採用哪些工具,涵蓋率有多高?

* 就您個人而言,最近在組織內學到新的技術是什麼樣的技術?新的程式語言或者新的工具?







面試是可以事先作準備地,軟體工程師的面試準備,應該花時間以事實展現價值作為準備方向,而非準備一些大家都知道的常識或者花時間準備外在行頭口語表達...等等。當成功地完成許多面試,就可以在工作機會上有所「選擇」。


參考文章:
(1) Scrum認證!不要再浪費你的時間了
(2) 如何充實自己
(3) 畢業前六個月 建構職業生涯
(4) 年底才績效評估或考慮轉職 已經太遲了
(5) 因為沒挑戰想轉換跑道,先檢討自己吧


註1:要轉職換工作區分成「主動」與「不得已」兩種。不得已:例如公司倒閉之類,當然就不用討論。但是如果是「主動」,就要先想清楚「真正的原因」。因為這個原因,可能不會因為你換工作而消失。

註2:剛畢業的學生可能是怕履歷表太空洞,通常都有誇大的傾向。而在業界打滾數十年的老鳥,有時候會有過度謙虛的可能。

註3:當然不應該「窺探機密」,因此可以在一開始的時候先說「如果這個問題不小心牽涉到公司機密,請告訴我,在這個時間點我無意探究貴公司的機密」



4/20/2017

數據分析 - 獵人頭如何從Github尋找人才?


前陣子遇到某特殊的獵人頭hunter公司(參考:這裡),竟然是透過分析統計在github, gitbucket的程式庫,來找到軟體人才。

目前,github使用者數量仍屬商業機密,但估計約在2千萬左右(參考:這裡)。當然,使用者大部分從事軟體相關的行業。

資訊科技,特別是軟體的實際成果,容易在網路上展示。因此,如果要找到「軟體開發人才」,github是一個很好切入的地方。一般獵人頭可能會人工搜尋,但身為工程師,當然是寫程式找到大量資料。

從github找人,這做法有一些顯而意見的好處:

1. 有可能看到此人實際上寫的程式碼
2. 有可能了解最近此人的工作範圍
3. 很快找到此人的聯絡方式(email)部落格或其他技術相關資訊
4. 有可能找到此人合作對象
5. 有可能看出此人的英文語言能力

當然也有些顯而易見的缺點:

1. 當然找不到那些不在把專案程式擺道github的人
2. 此人可能只是擺放玩樂性質的程式
3. 只能有機會看得出技術能力,非技術能力仍然需要其他佐證
4. 資料範圍過大,很難逐一肉眼看完

雖然我不是獵人頭,但基於工程師的精神,就嘗試一下解決「資料範圍過大,很難逐一肉眼看完」的問題。看是否能透過程式取得並處理gitbub資料,找到潛在挖角對象清單。

實際上做的步驟如下:

1. 了解gitbub資料如何取得:


github提供api可供程式使用。和許多Web Service一樣,也有完整的文件,請參考這裡


2. 以程式取得少量測試資料

github的web api測試起來很簡單。舉例來說,如果你已經登入github,用以下這個URL request就可以找到,以javascript與nodejs為關鍵字的所有程式庫:

https://api.github.com/search/repositories?q=topic:javascript+topic:nodejs

當然,他的回應是json格式,需要簡單地用程式轉換。例如下圖,乃是搜尋和javascript相關,並且其位置在台灣的使用者:



測試資料回傳乃是json,調整格式成為csv,以便於日後在excel做簡單分析。


3. 了解測試資料內容


如果已經有在使用github,那麼對於回傳的資料應該很清楚其內容意義。

如果不太了解github,就需要找對軟體版本控制系統有些認識的人幫助瞭解其含意。

這上述的範例:「搜尋和javascript相關,並且其位置在台灣的使用者」來說,程式會刻意收集following(有多少人在跟隨這個人的更新),follower(這個人跟隨了多少其他人)。此外,程式會額外計算push和javascript相關的程式庫的次數,取名為work,表示和javascript的相關工作在過去一段時間的次數。


4. 撰寫簡單統計程式,大量取得資料


當然,這個程式就放在github上。請參考這裡

程式本身是python撰寫,需要有github帳號密碼才能使用。


5. 結果


以上述範例:「搜尋和javascript相關,並且其位置在台灣的使用者」大量取得資料並且「過濾可取得公開email」的人數一共是661筆。並且取最前面的199筆,給熟識的headhunter (獵人頭) 鑑定看看是否有效果。

目前的回應都是此資料非常有用。

3/31/2017

企業巫醫 - 向上管理的實務作為?



向上管理是個歷久不衰的名詞,它和「人格特質分析」「領導與管理」等名詞雷同,每隔一小段時間就會以各種形式,出現在企業巫醫們的討論中。

近期隨意查詢就可以找到不少相關文章: 向上管理(cheers雜誌),如何讓老闆聽我的反對老闆的六種方式向上管理的四步驟 ......

「向上管理」向來是一個譁眾取寵的話題,眾多企業巫醫仍然以泛泛之談,試圖教導並解決一個現實而又務實的問題。

企業巫醫,總是能選定看似重要的無法辯駁,共通的話題,而且此類話題完全視個人情況而有截然不同的作為。因此,企業巫醫可以提出極端空洞的說詞,卻又多少讓人覺得有趣。除了「向上管理」之外,「創業」「創意」「領導與管理」「人格特質」等等都是屬於這類。

實務上,「向上管理」不能是打算進行的行為,而是產生貢獻中的其中一個結果。換言之,追逐向上管理,等於是捨本逐末的追逐影子行為。

因此,先務實地做到基本三件事情,假如踏實的做到了,向上管理就不是問題,而是附帶的結果。

1. 真正了解關於自己的現況事實

事實現況聽起來簡單,要找到也很簡單,但是要承認自己的現況事實其實有點難。

事實必須是清楚的,不模擬兩可的。例如,假設你是NBA球員,去年平均上場25分鐘,平均得分14分,這就是事實。至於你的技術能力好不好,並不是「事實」的一部分。以資訊科技的相關工作來說:參與過專案是事實,寫過java/python程式是事實,取得JSCP證照是事實,有Scrum證照是事實,帶領過開發團隊是事實,參與open source相關研討會是事實。

然而,具有良好溝通能力不算是一種事實,喜愛資訊科技不算是一種事實,

現況也必須是清楚的,不可能模糊。例如,目前薪資是現況,工作年資是現況,是否有直接report的人(也就是是否為管理者)是現況,最近一年有沒有拿到其他公司的offer也是現況,曾經拿到比現在薪水高的offer也是現況。

然而,覺得自己薪水被低估不是現況,覺得自己不受到重要不是事實,幾乎大部分的感受也都不是現況的一部份。

請參考這裡這裡這裡


2. 讓自己的實際產出超乎期待 


二因子激勵理論,描述「保健因子」和「激勵因子」兩種個人激勵因素。而其實這也是務實的評斷自己工作的方式。請參考這裡

要確定自己的產出超過期待,必須要確定產出有「超出」。

以基層程式設計師而言,在過去一年該寫的程式功能都有如期完成,並且品質在一定範圍之內。這樣的工作內容並沒有「超乎期待」,只是滿足「現在的薪水」而已。

要超乎期待的方式有很多。最容易的方式,是在目前工作範圍之外,「額外」並且「主動」完成有意義的事。例如,以基層程式設計師而言,在過去一年該寫的程式功能都有如期完成,並且品質在一定範圍之內,並且,主動地在額外的時間舉辦小規模研討會,分享工作上技術的進展。另一個例子,以基層程式設計師而言,在過去一年該寫的程式功能都有如期完成,並且品質在一定範圍之內,並且,由於主動學習其他程式語言,因此在其他專案上也能做額外貢獻。


3. 建立短中期職涯計畫並確實執行


在資訊科技產業中,實踐長期職涯規劃幾乎是不可能(註1)。

然而這並不代表自己現在就應該隨波逐流,看主管決定什麼就做什麼。個人應該要維持短中期的職涯規劃。特別是短期規劃。

短期規劃,必須要和技術能力以及現在工作有密切相關。

例如:

「作為一個程式設計師,未來8個禮拜,要能學會Scala基本用法,並且提出現在產品裡用Scala做分析的計畫」

「作為一個QA新鮮人,未來4周,要能將現在100個手動測試的case,至少其中20個變成自動化測試。同時,原本的工作也不會拖延」

中期計畫乃是半年到2年左右。必須要是「可以明白斷定達到與否」的目標。

例如:

「作為一個QA新鮮人,在2年內我想要變成資深QA,斷定是否為資深QA是以是否升遷或取得其他公司資深QA的offer」

當你完成數個短期計畫,通常表示你也踏實的逐步成長。即便有些短期目標沒有照時間完成,也沒關係,幾次之後,仍然是踏實往中期目標前進。

重點在於:這些目標是你自己決定的,並非主管或其他人硬塞給你。而目標既然和目前工作有關,自然就會協助你在工作上成長。


......
如果你非常非常確定已經完成以上三點,但覺得在這個組織中的成長仍有阻礙,還是很需要「向上管理」,用以獲得好的評價,獲得升遷?這基本上是不太需要,因為你應該儘速離開這樣的組織才是最好的方式。




註1: 「長期職業規劃」和「個人理想夢想」並不同。個人理想夢想可以需要很長很長時間實踐,也可能只需要很短的時間,也可能和職業無關。當然個人夢想就需要長期投入,也可以規劃,也可以不規劃。不過,不投入自己時間的夢想,通常就是空想而已。

3/07/2017

畢業前六個月 - 建構職業生涯



在台灣的碩士生,畢業前六個月通常忙於論文。如果不考慮繼續就讀博士,畢業前六個月其實是建構職業生涯的最佳機會。

更確切的說:畢業前六個月是讓你日後容易取得理想工作的最佳準備期間!

為什麼需要強調在6個月前建構職涯規劃?

環境上有許多現實的情況,例如,大部分好工作機會,其主管都傾向雇用有經驗的程式設計師。然而,絕大部分剛畢業學生並沒有實際軟體開發經驗。

因此,剛畢業的學生如果剛好獲得一個適合自己,能夠成長,能夠有所貢獻的工作,那麼就會進入良性循環。這個工作會讓這個學生更容易找到下一個好工作,或者即便不換工作,也能在目前的組織中成長。


反之,剛畢業的學生如果找到一個不適合自己,到處瞎忙,只是以時間換取薪資的工作,那麼就進入惡性循環。這個工作會讓該學生不容易找到比較好的工作,即便勉強換工作,也得靠運氣。

如果不想靠運氣,也沒有富爸爸,也不想自行創業(註1),則要做的事情很簡單:

(1) 考慮現況
(2) 設定短中期目標
(3) 建立事實


考慮現況


首先,最重要的是,取得一些關於自己的事實。是不是想要做關於軟體開發相關工作?想要做哪一類型的相關工作?是否知道自己還缺乏哪些能力?哪些地方的工作,可在短時間有巨幅成長?

如果想要當個程式設計師,要考慮的現況:

1. 能使用哪些程式語言:是真的會,而不是只寫過hello world和學校作業。並且有「事實」可以佐證。例如在github上的project,或者工讀經驗。

2. 能掌握資訊技術工具:是真的能掌握,而不是用過一兩次或者學校作業。並且有「事實」可以佐證。例如:工讀經驗,利用資訊工具做的個人專案等等。

3. 能掌握團隊專案合作方式:例如是否有Scrum相關證照(註2)。

4.....<其他還有很多請自行想像>

如果想要從事資訊業,但是一開始就做SA/PM類型的工作,在軟體開發職涯裡其實不太腳踏實地,不過,真不得已可以參考這篇:資訊科技學生畢業後只想當SA/PM (三個創意作法)



設定短中期目標


某些職涯教練,或許會建議新鮮人設定長期目標。甚且透過各種神奇的方式推展或瞭解自己的熱情(passion)所在:例如希望自己五年之後賺10億之類的。

大部分的長期目標雖然有趣,但是用處不大。設定可預計的中短期目標更為重要。

以6-12個月為期,讓自己在畢業前達某些技術性和非技術性目標,對未來職業生涯非常有幫助。以未來想要當程式設計師的學生為例,在畢業前六個月可以訂立以下目標:

* 開發並且將一個Android APP放在googlestore上:熟悉在android平台上開發APP,因此需要熟悉Java。

* 取得Scrum Master證照

* 閱讀3-4本關於軟體QA的書籍,並且運用在現在的專案上。(含建構測試案例,執行測試,系統化記錄錯誤,...)

訂立目標必須要是

(1) 有非常清楚的結果。如果目標是「熟悉java」,則最後有沒有達到此目標是非常模糊的,但是目標是開發android APP並且上架,就表示必須要寫java到某個程度才行(註3)。

(2) 可以在6個月之內達到。不要設定一個花10年才會達到的目標。如果真的有長期目標,當然可以設定長期目標,但是需要伴隨可以逐步前進的短期目標。例如,或許你想要成為java大師中的大師,這可能要花上數年,但必定可以有個6個月能達到的前期階段,例如:「不靠任何補習方式,就取得SCJP」

(3) 其結果會伴隨建立事實。請參考下一段


建立事實

在畢業前六個月,是最適合建立「事實」的時候。

建立事實,和畢業前花時間美化履歷表有很大的不同。

美化履歷表,是可以靠一兩個禮拜,找一些專業人士協助就可以很輕易的達到。但如果自己的「事實」不夠充分,再怎麼美化也沒有意義。

前一段關於短中期目標,只要你的短中期目標定義夠清晰。這些就是你要建立的事實。

如果你是在未來6個月即將畢業的學生,對自己的技術能力非常沒有自信,然而又想從事軟體工程師的工作,可以考慮建立以下三個事實:


* 透過自己決定的開發專案(例如Android APP),徹底實踐品質管理(QA) 

     (a) 找一個不用錢的QT工具:可以參考這裡
     (b) 在開發專案的過程中,徹底運用此工具,確保自己的專案品質。
     (c) 將結果詳盡記錄,就成為自己能當QA的事實


* 透過自己決定的開發專案(例如Android APP),徹底理解並且妥善運用git(或任何版本控制工具)

      (a) 版本控制是軟體專案的基礎中的基礎
      (b) 需要徹底了解如何branch,如何merge,如何處理conflict
      (c) 其結果構成了解專案開發的基礎事實

取得Scrum Master證照

     (a) 參考這裡
     (b) 雖然大部分的管理類型的證照意義都不大,但是取得成本不高的情況下,展現了你至少是瞭解Scrum。






註1: 想要自行創業的準備不太一樣,首先要了解創業如何必然成功,再參考其他相關資料

註2: 花大錢考管理類型證照其實不划算,但是可以考慮花小錢,請參考這裡

註3: 對,我們知道React Native可以讓你不需要寫java,但是這裡只是舉例而已。


11/14/2016

台灣博士生與大數據分析:如何評估對大數據分析的本職學能?



最近有個真實故事:



(為保護當事人,內容與細節均有所改變) 

台灣人F,目前就讀於某知名國立大學,已經是博士候選人。

最近為要爭取某一私立學校E的教職。在其履歷表上是以雲端計算大數據專家自稱。而E校的某系評會要求他面試15分鐘,用以評估他的能力。試教主題不限。

然而,F其實對大數據除了看過一些商管叢書之外,其實根本一竅不通。因此,他找了以前大學時候已經在業界工作的好友J,問了一些「技術問題」如下:

F:我聽說過spark,是不是大數據分析都用它啊?spark是不是個作業系統?

J:如果這是你的問題,那你壓根離spark太遠。後面就不要再談了。

F:哎喔,我覺得教學只是個演出啦,看表面而已。以你在業界打滾多年,就幫我個忙。couchbase是什麼?有什麼如果講出來會讓大家知道我很厲害的地方?

J:如果這真的是你的問題,你真的什麼都不懂啊,就算你去E校當教授,也是害了別人。

F:....



這個真實故事乍看之下太過駭人!但或許反映了學術與實務之間的鴻溝。

其實,台灣有許多學術界的人才,不但學術淵博,技術根底也厚。從數十年前的硬體產業蓬勃發展就可見一般。近幾年的軟體也是,許多教授幫業界「產出」能產生價值的知識性員工,並且也讓業界的知識持續推進。

然而,M型社會反映的層面,不指是一般在職場工作的人,在學術界中也越趨嚴重。

也有不少學術蟑螂。他們靠著極致的生存能力和夠厚的臉皮,穿梭在三流研討會,大企業策略部門,顧問性質演講,以及不在乎學生品質的大學院校中。

這些學術蟑螂做的事情,大概也不會真正傷害到誰,只是,也不會對任何人有好處。只要不是在「自己家裡」,一般人在路上看到蟑螂只會視而不見,也不太會去追打。

但是,如果是在自己家裡呢?

評估對大數據的本職學能,才能判斷來者是學術淵博的長者,還是費力在夾縫生存的蟑螂。如果是像E校一樣,原本的教授群並沒有這方面的背景,要如何在沒有足夠的知識情況下,判斷對方有沒有知識?這雖然有點難,但是,透過一些方式還是可以把誤判機會降低。



(1) 實際經歷探詢(情境實例面試法)


情境實例面試法很基本,但是事先有所準備。做法很簡單,只詢問「過去實際上」發生的事情,用以判斷被面試者現在的情況。而且絕對不詢問開放性問題!!

對於couchbase而言,就不會問「你對couchbase瞭解程度如何」或者「分散式資料庫你有哪方面研究」。因為這類型開放性問題,會浪費大家的時間。也會讓學術蟑螂有機會以混淆視聽的長篇大論,大打模糊仗來損耗面試者的判斷精力。


簡單問題像是:


* 請用1分鐘定義何謂nosql

* nosql的實作有很多,請舉一個你最熟悉的nosql平台工具,一個你實際最常用,最熟悉的就好(在此假設他回答couchbase)。

* 請問你實際接觸couchbase多久了?  (用判斷他最熟悉的工具有可能有多熟,如果少於6個月大概也等於是不太熟)

* 你利用couchbase為平台,撰寫並發表過哪篇論文?(學術界而言,沒有發表相關論文等於是沒有相關方面的研究)


稍微麻煩的問題像是:


* 你有沒有加入couchbase的任何相關的mail-list? (沒有加入mail list也沒關係,但表示其實只是單純的使用者,不會有太多深入的了解)

你利用couchbase為平台,撰寫並發表過哪篇論文中,所使用的研究資料量有多大?100G?10T?(資料量極小的nosql,並不代表不正確,只是代表不是大數據而已)

* 你用過哪些版本的couchbase(起碼要記得大版本編號吧)

* 你最近讀了哪一篇論文是以couchbase實作其研究?是大概什麼時候讀的,內容是什麼?


總之,事先準備好不能模稜兩可的問題,並且也定義好不能模稜兩可的期望回答。事先準備的問題也不需要太多,只要7-10提及可。這樣,比較不容易被蟑螂溜進來。並且,在準備的過程中,其實也會讓團隊(無論是學術還是技術團隊)對這方面的知識有基本的增長。


(2) 真實展示


簡單的說,就是請他拿一台電腦,展示一下他對大數據分析中最會「做」的事情。無論是撰寫程式碼,還是建立模型都可以。

真實展示其實很容易騙得過沒有相關知識的人。但是,如果事先已經提醒會有真實展示,可以簡單篩選掉連打開電腦都不敢的小蟑螂。

E校要求試教15分鐘,其實是真實展示的好方法。然而,盡可能展示「動手」而不僅只是「動口」。雖然君子動口不動手,但是蟑螂恐怕也是。


(3) 自我反省

當在一個地方看到蟑螂的時候,通常表示附近還有另外10隻蟑螂(也有人說是數百隻),只是沒看到而已。會有蟑螂來面試 - 無論是工作還是教職 - 是不是這組織已經有很多蟑螂。更重要的是,自己是不是其中一部分。

自我反省是極端困難的工作,對生活優越的自己,在心理上也不見得好過。但是,在陰暗狹小的地方求生存,總是比不上光明正大的貢獻自己的能力。

請謹記,「自信心」和「自我感覺良好」只有一線之隔。或許,透過實際經驗探詢,先自我檢查自己,才是去評估別人之前,真正自己應該做的事。












9/13/2016

數據分析從零開始 - (2)資料取得和前處理




既然要分析資料數據,自然要有資料數據才能分析。資料取得是必要的事情。

資料來源有很多種,取得並且事後處理的難易度各有不同。

但可以確定的是基本情況是:

1. 資料的時間,會遠超過自己的想像

2. 在開始進行分析之前,資料整理的所花的時間精力,也會遠超過自己的想像

3. 資料整理,幾乎不可避免

4. 資料整理,沒有捷徑也沒有神奇的密技,只能靠不懈怠的努力耐心以及經驗

5. 實際上有創意,有價值的數據分析,都不能免除資料取得和整理。 



第一手資料:


在「嚴格的一手資料」定義下,做資料分析的人真的拿到一手資料的機會極端的少。不過如果你是購物網站的大老闆,則購物網站上產生的營運資料,web server的log等等,對你而言就是第一手資料。

實務上最常看到的第一手資料,應該就是網頁存取日誌(web log)。在2016年網頁伺服器市場上,apache加上nginx仍然佔了半數以上,其他的網頁伺服器種類雖然也不罕見,但網頁的log格式反倒似乎都很統一,因此,以網頁存取來說,資料取得跟分析都已經存在既有的工具。剩下就看規模和個人技巧。

其他類型第一手資料就包山包海,以業務來說,發票檔案(invioce)當然是貨真價值的第一手資料。以軟體開發來說,git上所有的commit log也是第一手資料。

以現在軟硬體的成本之低,第一手資料原則上都可以盡量保持「原來的樣子」,頂多保存的時候壓縮而已,不太需要進行破壞性過濾處理。

要點一:使用shell 做基本的確認以及雜訊處理。


mac或linux可以用的基本文字處理的技術太多。伺服器的log最基本的處理方式,應該先用shell快速瞭解一下現況。

舉例來說:

以下指令可以把access.log中的第11欄,http response code列出來,並且簡單統計一下各return code的次數。


#cat access.log | awk '{print $11}' | sort | uniq -c
以上圖來說,結果就是有3個http return 400,有134個return 200,沒有任何500的回傳值。至於什麼是http return code,請參考w3規範

要點二:用excel做最基本統計檢視


過去許多excel版本都有筆數的限制(最多六萬五千多筆),2013之後就放寬很多(大約一百萬筆),請參考官方網站

即便有數量的上限,也非常值得資料中,先擷取樣本來試著分析。使用樞紐分析表,可以很快看到資料欄位彼此可能的關係,在未來進行分析時候是很有用的參考。

如果到現在你還不知道什麼是pivot-table(樞紐分析表),那表示你根本不懂excel。  怎麼使用樞紐分析,請參考官方網站的說明。下一篇,我們會用政府公開資料簡單做個樞紐分析表。


要點三:以自動化的方式產生濃縮的摘要(二手資料)


只要能取得第一手資料,盡量使用自動化方式,自動產生有意義的濃縮摘要,這個摘要就算是二手資料。

當然,這要配合要點一的shell文字處理,例如以下指令:


#cat access.log | grep "GET /login" | awk '{print $6}' | cut -d ":" -f 1 | sort | uniq -c

這可以產生簡要報告,說明登入(login)頁面每天有多少人次來使用,執行結果如下圖:

這圖上的執行結果顯示,9/12有15個人次,而9/13有2個人次。


現存二手資料的資料


所謂二手資料當然就是不是直接產生資料的來源的資料。資料分析採用二手資料的機會非常高。

所有組織外部取得的資料,絕大部分都算是二手資料。因此在下一節中會特別說明外部資料的取得處理。

要點一:取得過程的紀錄,以及基本分析


無論資料是自己拿或者這別人給,都需要紀錄取得的過程。

舉例來說,如果IT「自動」會給你一份,wifi的使用者登入時間,以及最後封包產生時間,你就需要有方式「自動」記錄這個過程。

如果是外部網站,也應該要記錄當時取得的方式,假設是curl取得,則用了哪些參數,執行多少時間等等。

基本分析則和前一節相同,先用shell和excel對資料有基本理解。

要點二:正確性判斷


二手資料很可能不正確,或者,對資料的解釋不正確,會大幅影響資料的使用方式。

資料解釋不正確:舉例來說,只要有用過就知道,政府公開資料很多都宣稱編碼是utf-8,但實際根本就是Big5(例如 房地產實價登陸)。

資料不正確:二手資料取得的資料本身判斷正不正確很困難,特別是在大規模的資料收集下,很難簡單判斷正確與否。而且有些資料的正確性,可能連第一手資料來源都不能保證(例如天氣觀測)

但是可以透過「多面向」的方式來探究單一資料的正確性。簡單的說就是多找幾種資料來交叉比對。舉例來說,如果你的天氣資料來自不同的網站,如下兩個圖:



雖然這兩個圖在同一個時間點的氣溫還是差了兩度,不過起碼是一個合理的範圍,因此大致還能知道資料是合理。

要點三:自動化進行轉換格式以及二次儲存


二手資料無論是什麼格式,幾乎都會被轉移格式,或者合併,或者改換儲存媒介。例如csv檔案,常常就被改為json格式並且存進nosql中。

但重點是要「自動化」進行。雖然格式轉換或者改變儲存的形式,幾乎都有現成的工具可供匯入匯出,但是只要太多「人為手動操作」,都會讓資料處理越來越花時間,越來越難保證整個流程的品質。


外部取得資料



9/01/2016

企業巫醫 - MBA無用矣



企業巫醫The Witch Doctors(中譯本為商周出版)是一本距今十一年的老書,但書中對於盛行於商業界的企業管理顧問的見解卻始終精闢。這本書的標題雖然聳動,但內容卻是不只是流於隨想批判,而是踏實的先提出數據,做橫跨時間與空間的研究,最後提出見解。破解在招搖撞騙的「大師」形象。

作者對「大師」的批評相當有建設性,幾乎在1990~2000年間的企管大師,都被他非常精闢而有建設性的評語跟分析過他們所提出的方法論:彼得杜拉克,麥可波特,愛德華戴明等等。而史蒂芬柯维,吉姆柯林斯則是被他列在不入流的範圍。


組織與企業經營的是合併藝術與專業的範圍,在因果模型中屬於複雜的範圍(參考這裡)。換言之,企業的大大小小的決策,與是否能達到效果,很難在事前看出,只能事後瞭解其因果關係。而有趣的,具有戲劇性的論點,逐漸就取代了嚴謹的研究。這讓迷惑於複雜邏輯的人,有了某種追尋的方向,從這個角度來看,「真正」的企管大師也知道這種現象,但他們一方面提出淺顯易懂的見解,另一方面也持續進行研究,這也讓大師的研究結果可供大家參考與學習。

「企業巫醫」則利用根本沒有人可能了解其因果關係,讓自己以有趣的方式解釋因果關係,從而謀利 - 開設顧問公司,提供考取證照方式,提供分析報告,寫書,演講等等。




萬一,自己解釋的因果關係沒發生,當然會拿另一套關係來彌補。就像在原始叢林部落裡的醫生一樣,當有疾病-例如嚴重流感時,會先說明和惡靈的關係,接下來可能拿某些植物的葉片猛力槌打你,打的你又痛又麻的時候叫你回家躺幾天。如果好了,證實的確是惡靈的問題,如果因此病情加重,併發肺炎,表示這樣的懲罰惡靈仍然不滿意,則會換一套方式,直到你痊癒或者死亡 - 當然死亡就表示惡靈趕不走(此段說明彷自企業巫醫一書)

在企管書籍,個人認為最最最有名的巫醫例子應當屬於「從A到A+」。用google搜尋「從A到A+」可以找到非常多人閱讀記錄,甚且有精闢的閱讀心得。該本書所說「嚴謹的長期觀察和研究取得」,分析好公司和「卓越」公司的差別,並且這些從數百家篩選出來的好公司中再篩選的卓越公司,肯定可以「永續經營」?

但是實際上根本不然。

2005年的研究就顯示A+公司,在1996-2005年間,就已經不太算是A+。不到幾年後:11家卓越公司倒了2家,9家之中僅有1家沒受到太大的金融海嘯影響。其中8家在2008危機期間甚至績效平均比其他SP500的公司還差

從結果來看,從A到A+的理論根本沒用,但是,如同企業巫醫,作者後來竟然還寫了一本「為何A+巨人會倒下」用以自圓其說。非常典型的巫醫行為。

相對於企業巫醫,MBA的價值是否真正有用也很難說。某些研究都顯示,擁有MBA學位的CEO和沒有MBA的CEO在公司經營的成效上,沒有差異(參見這裡)。

然而,某調查顯示,擁有MBA學歷似乎對薪資有幫助(參見這裡),就這個角度來看,擁有MBA似乎還是有用的。但如果仔細看過這類調查,很明顯排除了MBA低薪,以及MBA本身的成本。

反倒已經有百年歷史的最最著名MBA產地的期刊 - 哈佛管理評論的一篇高學歷管理者的迷思誠懇的點出問題:管理學位取得者,在學習過程中沒有學到真正學到務實的作法,而只是為了取得學位。開始工作之後,如果又沒透過工作經驗,學到新的技能,當然就沒用。

如果沒能對複雜的問題,保持清澄的理智,分析可能的問題,簡化並反覆查證因果關係,踏實的從不同的角度看問題,MBA的學歷可能會創造出一個一個的企業小巫醫,在組織裡三不五時的拿一些最新的企管叢書,當做驅趕惡靈的樹枝,到處鞭打真正在做事情的人。


企業巫醫相關文章:

如何拒絕或調整客戶不合理的需求 

實習生的三贏

時間乃最終之敵人? (上) 

時間乃最終之敵人? (下)

6/03/2016

剛畢業準備加入開發團隊 - 三個必要的Scrum突圍方式



真實故事 1:

某個陰暗的冬天早上,悠晃進辦公室的當下,看到二十多個人圍成一個大圓圈。既不可能是營火晚會團康,也不會是祈福默禱活動。好奇的在旁邊觀察一下,在圈圈邊上的某個中年男子開始要求大家在這個stand-up會議報告進度,並祈許新採用的Scrum方法可以讓軟體開發有良好的發展。

真實故事 2:

某一次專案研討會中,演講者詢問與會人士,Scrum估計工時的時候,每個人每個工作天應該是多少小時才合理?新鮮人多半回答6-8小時。某些資管企管碩士生,大概讀了許多書,回答:「4小時」。而一個在軟體外包廠商工作的專案經理回答:「10小時」。






Scrum是最近幾年很流行的Agile(敏捷)開發方法之一。它的概念照理說簡單易懂,很容易在現有的團隊中採用運作,或許是因為趕流行?許多資訊產業開始以採用Scrum方法為榮。而各類型顧問也都開始教授Scrum,也開始頒發各種結業證書甚至Scrum Master的執照。就在短短數年之內,在台灣業界Scrum似乎無所不在,成功案例一個比一個容易找到。

但是就像其他簡單易懂的事情一樣。Scrum說起來比做起來簡單。實際實施的時候需要克服慣性與人性,克服與目標之間的各種障礙。但也因此,把握住Scrum的精神,最能夠讓畢業的學生以正確的方式加入軟體開發團隊 - 即便這個團隊此時並未實施Scrum。

追本朔源後,總是可以看出:太陽底下始終沒有新鮮事。Scrum最早正式出現在1986年的一篇文章中(Scrum最早的文獻):透過個案的深入觀察,兩位日本學者對於有彈性,有效率的產品開發過程中發現一些相似的點:內建的不穩定性,自我組織的團段,互相重疊的開發流程,多面向學習,精微的控制,組織裡習得經驗的轉移..等等。文獻中的產品大部份都是硬體,例如汽車或者影印機。

乍看之下,和現在的軟體開發方法論似乎沒直接關係,但是,而後在經過其他學者的後續觀察歸納。這種以事實為基礎的彈性結構,遠比傳統官僚結構,更能在短時間達成高效率,甚且更容易產生創造性思考的價值。


理論歸理論,如何實踐理論在工作上才是重點。


近年來畢業的資訊科技背景的學生,的確在學校多少聽過Scrum,許多資管的學生甚至上了不少相關的課程。但就實務的角度,除非教授像這位荷蘭的老師(eduScrum)一樣,真心誠意的採用Scrum在課程的本身上,否則對剛畢業的碩士生或大學生而言,Scrum就只是個似乎看的到,卻無法做得到的事情。學界與業界間的藩籬,仍然巨大看似難以突破。

因此,提供以下有三個務實的方式,可以作為剛畢業的學生突破藩籬的參考。


1.理解事實



對於剛畢業的學生來說,理解事實,是基礎中的基礎,但也確是整個職業生涯需要不斷強化的地方。

以Scrum而言,每一個要做的事情 - 也許稱之為一項backlog - 在正在執行人的手上只有三種狀態:「還沒開始」,「進行中」,「已經完成」。

在每日stand-up,最常發生的是產生另一個狀態「快要完成」,也有可能混淆「已經完成」和「進行中」,更糟的是混淆「還沒開始」與「進行中」。

舉例來說,小馮在每日stand-up會議說:「訂單查詢功能已經差不多了,因為訂單查詢結果的排序雖然弄好了,可是分頁還有點問題,但是快要好了」。也許在學校裡和指導教授報告論文進度這種描述是可接受的。但是在Scrum的精神裡,這種描述不但沒有必要,而且會引發更多問題,因為,接下來大家就需要探究所謂快要好了,是還要多久?最簡單正確的描述應該是「訂單查詢功能正在進行中,原本預計2天完成,已經花了1天,接下來1天會繼續完成,目前估計和預估所需時間一樣是兩天」

重點並不在於咬文嚼字,而是在於對事情的清楚認知。當意識到一件事情沒有完成,在產品開發裡,終究是沒有完成。

每個人多少都有報喜不報憂的心態,也多少都希望別人對自己有好印象。因此,常會有自己也欺騙自己的時候。Scrum的每日Stand-up站立會議,僅說明三件事情:1. 從上次會議到現在完成了什麼 2. 在下次會議之前打算完成什麼 3.有遇到什麼困難。僅只三件事情而已,不多不少。

剛加入任何形式的開發團隊的人,能先確切的掌握和自己相關的事實,是看似簡單卻需要時間實現的基礎。

2.控制時間


既然Scrum是屬於Agile的方法論之一,當然符合最早的Agile 12項基本精神(參見這裡)。其中幾個精神和時間有莫大關係,例如,可用的軟體大重於詳細的文件,回應變化重於遵循計畫。而Scrum是最能達到的方式。

以團隊的角度,burndown chart(燃盡圖)是最能表達團隊目前能力,與專案時間預估的方式。他的做法極端簡單,請自行參考wiki。burndown chart展示了血淋淋的事實,可以透過過去一段時間的完成速度,有效預估專案可能的完成時間。由於這種做法去除了人類心態上的偏誤(例如:大家再努力一下,接下來某東西可能比較簡單...諸如此類),因此在沒有能力,沒有創意,沒有實務開發經驗的產品或專案經理的眼中,burndown chart只是拿來參考用,不能給長官看到。

以剛畢業的學生而言,最難的事情在於預估時間,特別是在比較長期複雜的任務。


解決方式為兩步驟:
  (I) 決定第一件要做的事情並且去做 
  (II) 額外增加研究項目(也額外增加時間)


(I) 決定第一件要做的事情並且去做  


對於很長的項目(backlog),表示他可能隱含數個子項目,而每個子項目可能也不小。例如,讓系統可以支援facebook帳號登入。這可能就要分成數個項目。當然對於新鮮人,分拆項目可能會遺漏,但是,有分拆比沒分拆好,有估計比沒估計好。有分拆之後,如果有漏列項目,也可以清楚知道有漏列。有估計之後,估計的錯誤以後還可以作為其他項目的參考。
而分拆之後,就直接進行第一件要做的事情!確實的腳踏實地去做!不用等,也不用試著把項目分拆的很精細,估計得很詳盡。因為萬事起頭難,當已經開始進行,就很容易知道之前想法是不是正確,還有沒有遺漏。關於項目的分拆(breakdown)可以參考這篇


(II) 額外增加研究項目


如果分拆之後,很明顯的仍然難以著手,就額外列出一個有限定時間的研究項目在最前面。換言之,花個固定的4到12小時進行學習與研究,將這件事情也列入整個開發流程中。時間必定要是有限的,畢竟絕大部份的產品開發,無論多困難,都還是在有限時間一定可以找到解決方案。

從另外一個角度而言,如果在有限時間無法找到合理的解決方式,對新鮮人而言或許你也並不適合做這個行業,可預見的未來裡,或許你會勤能補拙,試圖用更長的工作期間達到成效。但是這並沒有太大的意義。因為你並不拙,只是專長不在此,在有限的時間投入內,了解自己的專長不在此,或許更能幫助新鮮人找到最能讓自己發揮專長的地方。


3.確保產出


每個backlog表示一項「產出」。只要前兩個精神:理解事實跟控制時間,已經有效掌握,那麼這一項應該不會有太大意外。然而,對於剛畢業的學生來說,無論程式能力有多強,對於產出的完整性,常常會有誤解。不過這樣的誤解其實也很容易釐清。

一般軟體開發團隊,某人的某功能程式碼寫完之後,會經過以下階段:

1. 程式碼完成
2. Unit Test完成並通過
3. 簽入版本控制系統(commit)
4. 通過code review會議
5. 合併到產品主線
6. 通過自動化編譯建構
7. 通過自動化整合測試
8. 通過QA測試
9. 經過產品經理(Product Manager)確認

在Scrum一開始,便應該定義何謂backlog完成?
- 會是 1.程式碼完成就算完成?
- 還是 6. 通過自動化編譯建構 才算?
- 甚且是要等 9. 經過產品經理確認 才算?

有許多開發團隊,產出的本身是透過「默契」來達成。然而就新鮮人而言,一開始一定比較難取得「默契」。開口詢問,並且在三確定產出的「要件」是剛畢業的學生常忽略的要點。

參考閱讀-> 如何快速充實自己








5/06/2016

80/20法則之軟體專案的三個運用重點




軟體專案的Scrum的一次sprint之後,照例的檢討會議(retrospective)中,張經理收集了成員的意見,經過投票整理與排序,發現"不夠專注在重點上"是成員們最希望改善的地方。於是,張經理發表他的見解:「看起來大家可能是覺得瑣碎的事情太多,沒辦法專注於工作,這次新的sprint開始,大家試著把心思專注在重要的事情上」,接下來,張經理開始順道交代其他事情:「呃,上次要給法務部門的3rd party版權清單,老馮你準備一下;明天我們要定個下午茶,小陳你有空的時候幫個忙...」。....於是乎,最希望改善的地方就從未改善過。


Pareto Principle,又稱為80/20法則,指的是80%的結果來自20%的原因。這個法則是取名字義大利的經濟學家帕雷托。他觀察到1906年義大利的80%總資產屬於20%的人口。而此一情況被學者們,在其他領域也觀察到重複類似情形,因此被簡約成此法則。

80/20法則中的數字,有時候,會和實際領域不同而有所改變。例如,絕大部份的軟體,其90%的執行期間,執行的是其中10%的程式碼(參見這裡)。


在軟體專案管理中,能掌握80/20法則,等於是掌握80%的成功。

以程式撰寫為例:最重要的10%程式碼,關係到軟體運作的90%時間,掌握最重要的10%的效率與品質,就掌握系統的本身。當然,80%的bug來自於20%的程式碼。(參考這裡

以測試為例:1000個測試案例(test case)如果能有效掌握哪20%的測試案例可以測出80%的潛在問題(bug),就可以有效縮小測試。

以人員管理為例:在有一定人數的情況下,30%的程式設計師完成70%的主要功能。而有追蹤問題(bug)的來源時,80%的問題來自20%的模組撰寫者。


因此,掌握並改善20%重點,是任何專案的成功關鍵因素。

不過,這件事情知易行難。以反面來看,作為專案管理人,如果整個專案過程的每天都忙得焦頭爛額,隨時都有不同的人來進行不同的會議,螢幕旁邊有數十張待辦的便利貼。這很明顯的表示你一定沒有掌握到20%的重點,而你雖然很努力的想要完成任務,但並沒有朝向正確的努力方向。更慘的是,假如你認為這種忙碌可以顯示自己在組織的價值與貢獻,這種想法做為專案的領導者只會害死大家。


每個專案都是獨一無二,因此每個專案的重點20%都有所不同。然而,掌握關鍵的「20%」倒是有三個共同切入點。


1. 目的 - 真正目的


軟體專案的真正目的各有不同:有些是新產品開發,有些是既有產品增加新功能,有些是客製化專案。大部份的情況下,其目的通常不是「技術目標」,而是「達成效果」。

例如,網路商店需要開發mobile app,其目的鐵定不是為了要有一個Android APP或是iOS APP,而可能是要讓客戶在智慧型手機上也能購物。但也有有可能目的是要讓客戶在智慧型手機上容易查詢訂單。當然也有可能兩者兼具。但無論如何,技術目標:也就是有Android/iOS APP,與達成效果通常有相關,但專案管理者必須清楚兩者的不同:

達成效果是勢在必行不可或缺,但技術目標永遠都有其他選項

網路商店不見得需要有APP才能讓使用者在智慧型手機上購物,可以使用符合智慧型手機規格的網站(所謂的響應式設計),讓使用者利用手機瀏覽器進行購物,也可以透過簡訊或者撥打電話的方式購物,開發APP只是其中一個選項而已。

掌握真正目標之後,列出這個目標中的所有使用情境(user story)中最重要的20~40%的功能,而軟體開發的重點就放在這20~40%重要功能。集中力量完成最重要的20%,才不會「先」耗費力氣在無謂的事情上,「最後」才做真正重要的事情。



2. 時間 - 不倒退的沈默成本


時間是不會倒退的(參考這裡)。軟體專案裡的時間成本一旦投入,都屬於不會退還的沈默成本。也因為時間無法退回,一旦投入就是投入。因此,必須要確定「先」運用時間在重要的事情上。

80/20法則的重點在於:計劃運用「未來的時間」,在有效果的事情上以達到80%的產出。

舉例來說,一個程式設計師,在早上抵達辦公室,打開電腦的第一件事情,應該試圖確認「今天什麼事情對我最重要」,而一個開發團隊,每天第一件事情應該是「今天團隊完成什麼事情最重要」。因此,典型的scrum都會在一早展開standup meeting(快速會議),以15分鐘的簡單開場讓專案團隊確保先投入在最需要進行的事情。

這也是一個聽起來簡單,執行起來並不容易的概念。有很多情況,團隊成員並未「徹底」實踐快速會議時的精神。

例如:某甲陳述:今天會開始開發模組A,預計今天會完成,而這也是他今天最重要的事情。然而某甲可能無意識地忽略掉昨天他的功能B的程式碼尚未簽入版本控制系統,因此實際上會議結束,其實他花了一早上在簽入程式碼,並且執行合併/建構系統。某甲並非不應該完成昨天尚未完成的事情,而是他對於「未來即將使用的時間」沒有腳踏實地的認知。

80/20法則運用在專案的時間管理上,最重要的精神在於「腳踏實地」,並且「確實展現事實」-- 缺乏這兩者,會讓80/20法則淪為壓榨程式設計師的幫兇。



3. 激勵因素與保健因素


激勵保健理論(參考這裡),將影響人工作時心裡的滿意度因素分為兩類:激勵因素與保健因素。簡單的說,保健因素是「沒有會死,但是有也不會很高興的因素」,激勵因素是指「沒有的話不會怎樣,但有的話會很高興」。

激勵與保健理論,乃是在軟體專案管理中,80/20法則運用的最容易忽略的一環。特別是在兩個面向上:(a)軟體團隊經營
(b) 技術決策


(a)軟體團隊經營:

保健因素(薪水,電腦設備,工作環境):無論加碼到什麼程度,對程式設計師的績效成長極端有限,然而一旦失去基本下限 - 例如減薪,則其他的激勵方式會突然失效。軟體專案負責人,應該在一開始,就先確保:保健因素是成員可以接受的。爾後專案執行過程,不要特別關注它即可。

激勵因素(個人成長,價值觀,成就感):激勵因素才是大部份軟體開發專案成員「願意保持工作熱誠」的真正原因。負責人或者領導者,應該將團隊經營的80%重點時間放在保持激勵因素。然而每個人的激勵因素皆有不同,因此了解團隊成員個別的「真正需求」,才是需要花時間的地方。

舉例來說,有些團隊成員可能會抱怨沒有雙螢幕,雙螢幕對於撰寫程式的確很重要,專案經理想辦法弄給他雙螢幕之後,千萬不要以為這樣就會讓他心甘情願賣命。雙螢幕只是保健因素,是必要取得,但不是重點。專案領導者在團隊經營上,應該花20%的時間快速搞定保健因素,而後,花80%的時間確保激勵因素的存在。

缺乏激勵因素的團隊成員,並不代表一定會離職,也不一定代表任務不能完成。一個能力很強的人,可能因為暫時沒有其他選項而在現在的位子上滿足最低限度貢獻。這樣成員,反而成為一個潛在的問題,他隨時有可能因為任何短暫膚淺的因素而離開,更糟的是不離開而成為團隊困擾。而這種情況並非是該團隊成員的問題,而是團隊領導者,沒有辦法找到並維持適合的激勵因素。



(b)技術決策:


既然是軟體開發專案,必然會歷經各種技術決策。80/20法則一定是技術決策的主要運用重點。

以功能而言,如果有A功能與B功能在短時間之內,只能選擇完成一個。則技術決策應該從幾個方向考量:

方向一:中大型軟體專案一定有20%的重要功能,會滿足80%的使用者需求。哪一個功能屬於這類。

方向二:如果A與B都滿足方向一,則考慮哪一個功能會直接滿足「專案目的」。

方向三:如果A與B都滿足方向一與二,則考慮兩者哪一個對於此專案是屬於保健功能(沒有會死的功能),哪一個屬於激勵功能(有的話會很高興的功能)。並且考慮專案目的,是屬於維護且保守的專案,還是開創性的新專案。開創性的專案自然優先考慮激勵功能;而維護型或保守的專案,當然要先考慮保健功能。



80/20法則的有效運用是判斷一個優秀的專案領導人的條件。以反面例子而言:有很多15年以上專案管理經驗的所謂專案經理,他所有的經驗可能都在於無謂的忙碌與焦頭爛額中度過,這樣的15年和1年沒有什麼不同。如果你是這樣的專案經理,為了團隊好,或許應該考慮轉換適合的工作跑道。












4/27/2016

軟體專案品質控制的三要點


老馮是軟體專案經理,在專案進行的某一天,被高層找去開會。高層:「最近雲端計算很火紅,你的專案既然是跟Cloud有關,看能不能早點完成」。老馮就問:「那可不可以auto-scaling的功能不做?」。高層:「沒有auto-scaling哪能算雲端計算平台,當然要做啦」。老馮就又不死心地說:「怎麼可能功能不減少又要早點完成?我們都已經是早9晚9在加班」而老馮心裡沒說的是,加班也絕對不是解決的方法。高層:「那就看你們的能力啦,不然我在多加3個人給你好了?」。老馮:「...」


專案管理過程中,品質是最容易忽略的項目。在狀況複雜的專案,品質常常是自動被犧牲的事情。在沒有良好控制的專案,品質是最容易被省略的事情。

品質Quality的定義其實有點複雜(參考這裡)。基本上,在軟體上,一個可接受的品質通常是指:功能如預期的正常運作,並且沒有不預期發生的壞事。

例如,一個手機購物程式,在你執行登入,往下捲動查看最近的商品目錄,點選商品,下單,這幾件事情都如預期的運作,就表示功能沒問題。從看到商品到購買,整個過程沒有讓你覺得很慢,那就算是沒有不預期發生的壞事。

又例如:當你點選商品之後,看到商品大的照片,接下來你就橫向擺放手機,照片因而旋轉之後,再轉回原來的正向,結果手機程式就當機直接跳出,這就表示功能有問題。當你點選商品到購買,整個過程讓你等得很心煩易燥,每個動作都要5秒鐘的等候,那就算是不預期發生的壞事。



軟體專業經理人,應該都知道一條鐵律:品質,範圍,成本,三者不可能兼具。

軟體專案的成本指的是:時間,人力,金錢或其他投入的資源。

軟體專案的範圍指的是:軟體的功能,規模,支援的硬體範圍等等,範圍修改自然就是功能增多或減少。


三者不可兼具,指的是要顧全某一項或者某兩項要素,就一定會犧牲另一項。例如:某APP可以支援google+ 以及facebook 帳號登入,後來因為時間(減少成本)考量,最後決定僅支援facebook登入。又例如,某APP原本可支援google+ 以及facebook帳號登入,後來又希望可以額外支援維博登入,這時候就決定花錢(增加成本)找外包廠商實作此功能。

軟體專案中,另一條鐵律是:試圖三者兼具者,會自動犧牲品質。例如:某APP可以支援google+以及facebook帳號登入,而後又想要支援維博帳號登入。專案經理想要在不增加成本,又不減少其他功能的情況下,又不增加實作時間。硬是要額外增加此功能的結果,必定是品質會自動犧牲。

不知道品質會自動犧牲的專案經理,必定不適合做軟體的專案管理者。

軟體專案品質控制有三個要點:

要點一:來源


品質的來源是整個開發過程,從一開始的計畫以及團隊組成,就已經決定了品質的一半。

一個簡單合理有效的計畫,可以控制改變,掌握進度事實。開發方法是不是採用Scrum並非最關鍵。重要的是,計劃中的開發方法是否簡單並合理的被團隊認知。

舉例來說,傳統SI常會有RFC,也就是需求變更的管理計畫。在開發過程中,如果有需求變更,基本應該是1.先填一份表格,2.在專案會議中與客戶討論,3.互相同意修改之後進行變更。換言之,有需求變更(RFC)管理的情況下,必定是前期的架構,設計細節,規格等等都先完成了,才會開始進行開發,因此,就不可能使用Scrum的開發方式。


假如團隊的組成是可以選擇的,那這件事情也是掌握品質的關鍵因素。



要點二:架構


在實作上,架構是另一個品質的主要關鍵因素。一個優良而且簡單的架構,比較有可能在多人而且複雜的開發情況下,獲取最容易達到的品質。

精煉的軟體架構設計表面上容易,實際上困難。架構的設計要素,眾所皆知:內聚力高,耦合力低,不同模組之間首重介面溝通。

然而,任何有3至5年工作經驗的程式設計師,都可以規劃出極為複雜的架構,普通並且沒有實務經驗專案經理,會容易「讚嘆」這種複雜的架構。這會在不久的未來讓品質很快降低。

實務上,只要沒特別的控制以及重構,正在運行的軟體的熵(entropy)值通常會隨著時間越來越高。同時也讓軟體品質越來越低,或要花很大的成本達到高品質。



要點三:創意


在品質控管中,創意是最被人所忽略。特別是在傳統的開發環境裡,負責品質的相關專業人員通常傾向於「找到問題」,事實上,這的確是QT或者QC的主要責任,但軟體專案中,作為QA(Quality Assurance)扮演的任務就不僅如此,而是在整個開發過程中確保品質符合規格(註一)。

而有創意的QA是第三個重要的品質來源。

普通的QA會執行QT/QC的任務,在開發過程中參與設計討論,並且撰寫測試案例(test case)。在功能完成之後,會認真執行測試案例,或者撰寫測試程式碼以便自動化測試,而在過程中找到並且記錄問題,並督促程式設計師修正錯誤。以上這些都很好,而且也沒什麼不對。

但是!當時系統複雜,時間壓力大,程式設計師能力參差不齊等等困難情況發生時,普通的QA流程並不會對「範圍」以及「成本」有所幫助,因此很容易被壓縮或者犧牲。

有創意的QA會根據專案的情況,找出最好的解決之道。而非死命地抱著舊有的測試流程,在確定有問題的情況下還不進行改善。

創意的可能行動有很多,但總之就是要有「行動」。空想的創意是沒有意義的。有創意的QA行動,可分為技術類型和非技術類型:


技術類型


例如:透過pair-programming主動參與開發;除了自動化測試之外,撰寫當介面改變時的監視程式;對於程式設計師的commit做自動化分析...這些都是透過QA的技術能力,提早發現可能的問題並提早解決。


非技術類型


例如:著重架構的精煉與簡化;改善測試流程;利用其他資源(例如業務人員)進行測試;改善code review的方式;簡化bug記錄以及追蹤方式...等等,這些都是透過QA的協調作業能力,縮短或減小品質差距。


簡而言之,絕大部份的軟體專案品質控制,其實是需要有創意的QA,才能突破既有限制,創造更多價值。而QA要有創意也並不困難,只要願意嘗試,通常都有很好的效果。


參考:沒有QA?如何確保軟體開發品質

註一:ISO對於QA的定義:"part of quality management focused on providing confidence that quality requirements will be fulfilled"






4/12/2016

你真的知道專案進度嗎?



只要是從事程設式設計相關工作的人,必然曾經參與某專案(Project)。專案的大小不一而足,有些只有幾天或幾週,有些橫跨數年。

如果有幸負責專案管理,則無論規模大小,掌握進度是除了管理利害關係人期望之外的第二重要的事情!!而實際上,要管理利害關係人期望的最好方式就是能有效掌握真實進度。

「掌握進度」之後,才能調整應變可能發生的意外,降低風險。


只要看軟體專案進度的「掌握方式」,就大致可以判斷一個專案經理的「本職學能」到什麼程度。

一個好的專案經理,可以單靠自己,就能足以掌握專案進度。

一個普通的專案經理,可以利用流程,規範,加上開發成員的協助在一個合理的時間範圍內,掌握專案進度。

一個很爛的專案經理,會利用各種會議,各種形式文件的填寫(WBS之類),直接或者間接的資訊,花很多時間,仍然不能掌握專案真實的進度。


很遺憾的是,好的專案經理很少,好的軟體專案經理,更是極端的少。因為他同時需要具備技術能力,透悉問題的能力,以及有效的專案管理能力。



要點一:以時間為單位


非軟體專案管理上,掌握進度的單位有很多種,例如「以執行預算」或者「實獲值」來掌握進度。(請參見PMP相關網站)

以軟體專案而言,「時間」才是真正掌握進度的單位。

當詢問負責的程式設計師:「A功能進度如何?」,而他回答「只剩下UI整合,加上DB欄位定義調整,就快好了」。這樣的回答,對於掌握進度幾乎完全沒有意義。因為,該程式設計師可能在A功能花了1天,然而UI整合與DB欄位定義調整,可能還需要另外花上3天,換言之「就快好了」根本不是真的,基本上只完成了25%。但該程式設計師並不是故意要說謊,因為或許最難的就是那25%。


程式設計師若以困難度為考量,進度就像下圖,功能完成之後,就「快要好了」。





但如果以實際時間進度為考量,則如下圖,功能完成之後,只完成了25%。離「快要好了」有很大的距離。




大部份的軟體工程師,著重於困難度。這並非不正確,只是專案管理在掌握進度時,實質進度必然是以時間為考量單位。即便「這件事情很簡單」,也必須要考慮「簡單的事情還是要有人去做」。



要點二:產出的事實


直覺上,大部份的產出當然是程式碼。實務上,非程式碼的產出許多時候會超過想像中的多 -  特別對於比較沒有專案管理經驗的人而言。


基本情況


最基本情境是,根據規格要完成功能A。一開始,程式設計師寫好了程式碼,並且自己編譯(compile)並簡單測試之後,簽入(commit)到版本控制系統中,並且和其他相關程式碼合併(merge)之後,整合成新的版本,並且新的版本經過QA測試後也沒問題。這個功能A就算完成。

在這個情境中,寫程式(coding)可能佔了70%的時間,另外merge以及測試可能佔了另外30%的時間。

專案經理要掌握的「事實點」在於:整合成新版本並經過QA測試後也沒問題,至此,功能A才算完成。


進階情況


在一個稍微複雜的專案裡面,根據規格要完成的某任務,實務上可分為「功能A」與「功能B」。一開始,幾個程式設計師分頭完成自己負責的功能,並分別自己compile並簡單測試之後,功能A與功能B就commit到版本控制系統的不同版本線(code line)。此時,QA分別進行測試,沒問題之後,協調某人「分別」合併功能A與功能B到主線(main line)並且整合成新版本。在整合過程,或多或少有需要修改的程式碼,也許在合併工能A的時候沒問題,但是在合併功能B的時候有出現問題,並也修正完畢。最後新的版本經過測試也沒問題。至此該任務才算完成。

專案經理要掌握的「事實點」在於,最後新版本經過測試也沒問題。至此,某任務才算完成。

但是,這和基本情況不同的是,整個過程很長,從數天到數週都有可能。coding本身可能僅佔50%。而合併,測試,在合併,修改等等可能佔了另外50%的時間。

與前述要點一相同,專案管理者要能掌握實際上的進展,跟「未來還需要花的時間」。在複雜的情況中要掌握,除了最後的產出事實之外,中間的進度掌握,需要靠專案管理人員對專案本身實務的了解。

專案進度的掌控,大部份是由專案經理個人獨立可以完成。其中,技術上的要素就是能否「判斷產出的事實」

而以軟體專案為例,專案管理者如要能判斷產出的事實,必須要能做「自己獨立」做下列幾件簡單的事:

1. 在版本控制系統中(git, p4, cvs等),找出過去一段時間的所有commit過的程式碼變更,誰去變更,為什麼變更。

2. 在最近的新版本測試中,看到哪些新功能確實增加

3. 自行檢查目前bug的清單,並且找出幾個關鍵的bug



假如你是專案管理人員,而你不認為上述事情是自己應該獨立進行,或者你認為上述事情會花太多時間,


請參見下節:除去迷霧。


要點三:除去迷霧


許多「非技術背景」的專案管理人員,常常用各式各樣的大大小小的會議,來獲取專案進度的掌握:每天早上例行會議,每隔兩天來執行bug review,每個禮拜來討論整合進度...開會的本身並不會「加速」專案進行,過多的會議,肯定會「拖累」專案進度。

如果你是一位主管或專案經理,而你迫使專案成員每天花超過10%的時間(也就是40分鐘左右)在正式的會議上,並且只是為了呈報「目前進度」。那麼,你實在是個很糟糕的主管,要麻,你就盡快辭職,要麻,盡快提升自己的專案管理能力,否則你的存在只是浪費大家時間

了解目前專案的進度,等於是除去迷霧,看清事實。除去迷霧的方式,必須要是「貼近事實」與「清晰的技術檢視」。


貼近事實


事實有時候很容易了解。例如:app要可利用facebook帳號登入。此功能容易判斷有完成,或者沒完成。

但有些時候事實很複雜。例如:某程式設計師宣稱,app要可以利用facebook帳號登入,他需要花12個工作天完成。12個工作天到底是長還是短?如果覺得太長,是因為寫程式的人能力不足?還是既有的app過於複雜,所以要加任何新功能都很難?


按部就班的貼近事實是讓該程式設計師先行「分解」這12個工作天。讓專案管理人員了解,他打算如何利用這12個工作天。

如果該程式設計師說「我這個是大概估計,12天就拿來做這一個功能阿,你還要我花時間去分哪天做什麼喔!我哪來這個時間」。這表示事實是,12天根本只是沒有基礎的猜測,他可能22天才完成,也可能2天完成。

絕大部分軟體專案,程式設計師的某行動完成都應該至少可以以「天」為最小單位,(也可是以「小時」為單位,不過太細的單位也會造成不必要的麻煩)。

超過2天估計,就應該可以分成「兩個以上的事情」,超過12天的估計,應該是建立在至少6個以上的某行動完成。


不能分解行動,表示沒有計畫,也對此任務沒有任何基本了解。

假設該程式設計師將app如何利用facebook帳號登入分解為以下工作:

(1) 修改UI: 3天
(2) 登入的程式碼: 7天

(3) 測試: 2天


專案經理應該要能看出,這樣的WBS其實完全是在應付專案經理,對貼近事實沒有幫助。他等同是一樣沒有了解任務。

如果無法將此任務交給別人,專案經理應該參與「計畫」與「分解」的過程。和程式設計師一起坐在某台電腦前面,將android studio打開,了解登入在哪邊加icon,如何到facebook取得App ID,facebook sdk如何使用。

對於有技術領導背景的專案經理,頂多花上一小時,就應該至少可以分解此任務如下:

(1) 到facebook developer網站了解sdk:1天
(2) 申請App ID以及了解相關規定:0.5 天
(3) 登入Icon要和美工討論實作方式:0.5天
(4) 執行登入,取得session:1天
(5) facebook帳號與其他帳號在db處理的不同:2天
(6) 與QA討論測試方式:1天
(7) QA測試:1.5天
(8) 其餘模糊規格的討論,例如是否可登出:0.5天

加總起來可能僅需要8天。但重點不再於天數減少,重點在於此計畫已經破除進度迷霧。當這個計畫開始執行,到了第三天,如果該程式設計師已經開始撰寫登入程式,那麼表示進度和預測相同,但如果他還在申請App ID,表示進度落後,專案經理需要調整進度,或找人幫忙。但無論如何,絕對在計畫開始執行的前期就已經知道如何處理問題,而不是到12天之後,突然發現根本無法完成。


(Android如何利用facebook帳號登入,請參考這裡)


清晰的技術檢視



前述的app利用facebook登入,專案經理之所以能和程式設計師一起坐下來定好比較清晰的時間,其首要條件在於具備清晰的技術檢視能力。

簡要的說,能區分技術難度,區分使用該技術對於專案的影響,以及,使用技術可能產生的風險。清晰的技術檢視能力,會有效提高對整個產品或者專案的洞察力。雖然,洞察力可以經過訓練磨練取得相關經驗,但實質培養卻需要有意識地進行。

技術檢視需要對技術的深度與廣度,每個專案經理所需要的技術能力各有不同,以下有個簡單的軟體專案經理自我問題清單,回答「是」就得1分。

低於5分表示是沒有技術檢視能力的專案經理。
高於8表示是罕見的擁有技術檢視能力的專案經理。

* [Yes/No] 你可以自己從版本控制系統中了解專案目前大致規模:(行數, 檔案數, 平均每工作日增加的程式碼數量),無須依靠其他專案成員嗎?

* [Yes/No] 你可以自己找出哪些程式設計師的程式碼常常會出現bug,無須依靠其他專案成員嗎?

* [Yes/No] 你每一週會隨意抽出幾個程式碼簽入(check-in)看看有沒有明顯的問題,無須依靠其他專案成員嗎?

* [Yes/No] 你會手動編譯專案,無須依靠其他專案成員嗎?

* [Yes/No] 你隨時知道目前技術文件(程式碼註解, api 手冊, 使用手冊)撰寫的實際情況?

* [Yes/No] 你知道專案成員實際花在專案的時間

* [Yes/No] 當某個進度完成時,你可以自己檢查該進度是否真的完成,無須依靠其他專案成員。

* [Yes/No] 你會用專案開發的主要程式語言撰寫工具用程式(例如查閱系統log之類),無須依靠其他專案成員?

* [Yes/No] 你能自己估計團隊能力和團隊完成某模組的大概時程,無須依靠其他專案成員?

* [Yes/No] 你能單靠記憶,繪出目前專案個模組之間大概關係,無須依靠其他專案成員?