顯示具有 工作效率 標籤的文章。 顯示所有文章
顯示具有 工作效率 標籤的文章。 顯示所有文章

8/31/2019

如何處理抱怨 (成為主管的31堂課)


只要是人都會抱怨,然而只要是有經驗的主管,一定也都知道處理抱怨的重要性。過度並且持續擴張的抱怨不但會降低士氣,而且對團隊,對個人都沒有任何好處。

抱怨有分不同的層級,如果僅只是抒發心情,發發牢騷當然無妨。其界限在於,在平常閒聊,抱怨的只會佔不到1/3的時間,而在平常正式討論事情,正式的會議上,抱怨應該只是會佔不到1/20 (5% 或2分鐘)的時間。
主管在閒聊時後聽到的抱怨,大部分應該不用特別處理,畢竟是閒聊。 然而在正式會議上的抱怨則應該妥善紀錄並處理。因為抱怨的本身可能是和工作流程有關,更有可能的是潛在的問題,必須要試圖檢討解決。


案例一:工程師E技術能力向來不錯,然而跟他一起工作的同事,總是會反應他是個悲觀的人。追究原因發現,E無論如何都在抱怨,抱怨目前的現況和組織的做法,抱怨福利薪資等等。過了一段時間之後,團隊成員有些會受到影響,跟著開始抱怨,有些則會忽視他的抱怨。

案例二:在跨國團隊中,另一個國家的工程師會抱怨無法取得某些系統權限,而本國工程師常抱怨另外一個國家的工程師常想要干涉目前自己工作的範圍。



主管處理嚴重的抱怨有幾個方式:

(1) 了解抱怨的事實,根據事實決定行動


如果軟體主管覺得這個抱怨的人其實是為了組織好,而且,大部分的時候抱怨者其實不那麼常抱怨,也不是士氣低落的人,他除了反映工作困難之外,也許也揭露了應該改善的現況。應該進一步了解實情。並且在根據事實來決定行動。

以上面的案例二,雙方雖然都有道理,但主管進一步了解事實後,會發現其實某些系統的權限並沒有分group,這會讓該系統只要有權限的人統統都是最高的管理者權限,所以表面上是合作問題,其實是個技術問題,應該讓系統有不同層級的權限,另一個國家工程師也不是真的想管理這個系統,只是為了工作必須要直接使用,透過另一組人間接使用也很麻煩。而本國工程師也不是真的不想讓其他人使用,只是考慮安全性不應該給很多人管理者權限。


(2) 擁有改變的力量,而不是擁有「叫別人改變」的力量


許多抱怨的工程師常常會忽略「在公司裡面,我是來解決問題,而不是製造問題」

對於主管來說,如果抱怨者其實績效能力都很好,那麼應該化抱怨為力量。舉例來說,當團隊成員抱怨「現在的某系統在部署常出問題,害我需要做額外的工作」。那麼就可以先就事實詢問:「你覺得這對你很重要嗎?這是不是我們應該先解決的問題?」如果是的話,進一步應該跟抱怨者溝通:「既然這樣,你現在在做的是XXX和XXX,這兩件事就先不做,先來把某系統的部署改善,這樣以後你就不用做額外的工作」

讓抱怨者擁有改變的力量 - 就是要調整工作內容和時間。這樣久了,也可以清楚地塑造團隊會往解決問題方向前進,而不會只抱怨問題。

(3) 概念性問題:先記錄並且追蹤


概念性的抱怨是指對公司政策概念的抱怨,例如:為什麼我們公司沒有work-from-home(在家工作)的政策,為什麼上下班要打卡。這類型的抱怨很多時候和「實質工作」沒有很大關係,然而,不處理或者直接用「這個是公司HR政策 我也沒辦法」這種說詞也對大家沒好處。

對於概念性抱怨,應該先行記錄,並且追蹤對團隊成員的影響。舉例來說,對於work-from-home的要求可以先了解團隊成員需要work-from-home的原因:例如需要專心工作,還是需要兼顧家人。如果是需要專心工作,可以提出會在他需要專注的時候。幫忙直接訂一個會議室,或者讓他在距離公司很近的咖啡廳工作,並且記錄一整個月,看看有沒有實質影響。也許,他以後就不想真的work-from-home,也許他會覺得在咖啡廳工作也很好。

重點在於,概念性抱怨其實應該轉為實際可追蹤執行的內容。



主管對於團隊成員的抱怨絕對不能做以下的事情:


(1) 隨意附和,隨意認同抱怨: 表面上這似乎可以拉近團隊與主管的感情,事實上,一起抱怨對大家都沒有任何實質好處。

(2) 忽略重大抱怨:如果這個抱怨是很嚴重的,忽略拖延也沒有好處

(3) 不查證事實根本原因就行動:雖然所有人都知道要查證事實,然而許多事實的根本原因其實不那麼簡單。



8/28/2019

人手不足?資源永遠都是不夠的 (成為主管的31堂課)



大部分的情況下,所有研發與軟體主管都會面臨到人手不足的情況,特別是新創企業和快速發展的公司。資源有限,人手不足是必然的「現實」,能夠有效解決此問題也是普通主管和好主管最大的差異之一。解決的方向有三個:(一) 事實是事太多而非人太少。(二) 突破性思考,至少想出解決方案。(三) 必要的犧牲 


案例:主管V負責一個長期專案,已經有接近30個工程師是直接由V管理。然而,最近一段期間由於主要客戶的變更,加上CEO的臨時任務,讓這部門的員工疲於奔命。主管V也沒有什麼對策,只好和業務盡量模糊客戶需求以及驗收方式,看能不能減少工程師的工作量。


一:真正的事實是:事太多而非人太少


人手不足的真正意涵是「事情太多」。在以人才導向為主的組織裡,人力不足採取的短期策略如果是「增加人力」通常也不會真正解決問題。但如果短期採取「調配人力」也就是說某些事情先不做,有些事情先做,的確是可行的做法。

作為主管的你可能會說:我這些事情都很重要,每一件事情都要做。在營利組織裡,所有事情都很重要根本不可能發生。絕大部分的情況是:主管無法針對事情的優先順序做必要的排序。除非你管理的組織是急診室或者核電廠,不然不可能什麼事都很重要。要做必要的排序表面上很簡單,將事情列一個「優先順序的清單」,從1排到N,數字都不能重複,1就是最重要的事情。實務上,需要主管本身的本職學能判斷以及個人意志力。

二:突破性思考,至少想出幾個不同的解決方案


關於思考問題的框架,請參考這裡和這裡。在此就不重複。

但要提醒的事,在盈利企業裡面,不可能有什麼事情是「只能」這麼做的,一定會有不同的解決方式。問題只在於有沒有想到,還有這樣做效果好不好而已。

三:必要的犧牲 

必要的犧牲並不是指長期加班。長期加班最後通常也是三輸。必要的犧牲指的是幾種可能:
(1) 犧牲不必要的事情,請參見第一段
(2) 極短暫的加班,和長期加班不同,短暫加班是為了解決特定問題,並且要確定能盡快補假,讓團隊成員合理的休息
(3) 縮小範圍,犧牲部分功能
(4) 延長時程,犧牲時間 

然而請謹記,不能犧牲組織重要的長期目標的前進,以及不能犧牲組織文化價值。主管一旦犧牲不該犧牲的事務 (即便是無意間),就表示其領導方式有極大的問題。


陷阱


案例中的主管採取的作法非常糟。會直接踩到許多陷阱。要注意的陷阱是:
(1) 任何情況下降低品質都是飲鴆止渴,很少看到好下場。然而縮小功能範圍(例如MVP的概念)卻常常能夠成功
(2) 滿足政治因素(要和CEO打好關係)而非滿足實際困難,短期雖然可能有效果,但長期通常也不會有好下場
(3) 任何變化仍然要滿足組織整體方向,以此案例來說,必須要了解CEO這些臨時任務和目前專案比較起來何者重要

8/26/2019

系統化思考的秘訣 (成為主管的31堂課)


系統化思考 Systems Thinking 是解決複雜困難問題的科學方式。而作為主管的工作,時常遇到困難的狀況,如果身為主管的你沒有一個科學性的方式來分析與處理困難狀況,自認可以依賴直覺和經驗,那麼很有可能你依賴的是運氣而已。


案例一:有位資深的HR M,憂心忡忡的問說,過去三個月我們的資深工程師招募好像不順利,快要一百人無法通過我們的評估,Hunter看到我們這樣都不太願意再送履歷表來了。我們是不是標準太高?要不要降低標準。

案例二:某主管A被要求和直屬於CEO辦公室的專案經理D合作進行系統整合,然而專案經理D常常會有不合理的要求 ,並常在會議中酸言酸語,讓A在系統整合上花了很多人力時間,但又打不到D的要求,而D又有CEO作為後盾。


上述案例都很複雜,牽涉的範圍廣泛。為了解決複雜問題,系統化思考會牽涉到各式各樣圖形工具,例如這個,或者這個。這些圖形工具其實都是為了簡化問題。系統化思考的理論與應用廣泛,但是針對軟體主管的工作特性,有幾個祕訣(捷徑)可以先試看看

(1) 無論如何,先畫張心智圖或者魚骨圖


心智圖可以拓展思考,魚骨圖可以先探索遺漏因素。更重要的是,圖形可以將你的思考模式放在紙面上,讓你用鳥勘的方向,有機會重新思考問題。並且,這圖型還可以留供未來檢討使用。

(2) 無論如何,先透過5Why找到真正的目的或原因。


以上述案例一,當我們先從一個方向使用5why探究原因,可能如下:

為什麼HR會覺得不順利?是因為招募人數不足。為什麼招募人數不足?是因為hunter不願意積極尋訪多送履歷表。為什麼hunter不積極?是因為我們篩選比較嚴格。為什麼篩選比較嚴格?是因為....

但是,從另一個方向使用5why可能如下:

為什麼HR會覺得不順利?是因為面試的多但都沒錄取。為什麼面試多但都沒錄取?是因為hunter送來的履歷不符合我們徵才的要件。為什麼不符合?是因為hunter不了解我們要什麼樣的人才。為什麼不了解?是因為....

找到事情的真正源頭,或者自己想達成的真正目的會是系統化思考要達成的第一個目標。

(3) 實驗性質的行動!兵聞拙速 未睹巧之久也


任何形式的研究調查,都可以無限期地進行下去,可能永遠都不會有結果。然而作為主管,透過行為有效的將事情推進下去才是重點。

案例二:當展開5why與心智圖,了解CEO的辦公室經理D其壓力來自CEO對他有時間限制時,而D由於無真正的技術能力,導致會將各種事情盡量轉交給主管A,探究其目的在於,萬一整合失敗,不會被歸咎責任。而A的做法就是互相對抗,兵來將擋。這樣的情況,可以持續下去永遠沒有結果。而後改變的做法是,先實驗性透過提供各式各樣教育課程給D的部屬,讓其部屬更了解系統如何運作,並且在各種會議中提及教育訓練一事,讓CEO理解其直屬的團隊的能力不足,因而會讓系統整合的設計本身交由A來進行,自然系統整合的最後結果就會順利達到CEO要求,也讓A與D之間的關係不會永遠惡化。

案例二看似政治問題,但其實透過實驗性質的活動(提供教育訓練)可以讓A快速證實D的團隊能力不足,即便教育順練活動辦得很粗糙簡陋也可以。


提醒一下,無法進行系統化思考的主管,最後更容易透過「恐懼」「運氣」「政治手段」等方式來管理團隊,至於能否達到目的就很難說。








8/25/2019

如何讓一對一面談變得有用! (成為主管的31堂課)



做為軟體相關工作的主管,固定和自己的團隊夥伴一對一面談,在外商俗稱 one-on-one:是絕對不能省略的事情!如果無法和自己直屬部屬(direct report)每個月至少一小時的懇談,那麼絕對無法有效的激勵與維持團隊。


案例:C是在大公司的資深工程師,他常常跟我抱怨他的主管不了解情況。而由於該公司是有規定主管需要跟團隊成員固定one-on-one,所以我自然就問「你不是有跟他固定one-on-one嗎?」,C則回答「是啊,但是那也是聊聊天而已,改覺反應什麼也不會改變」


作為主管,要避免上述案例發生,一定要知道如何有效率的進行one-on-one並且讓他變得有用!


如果你的直屬成員超過10人,一對一面談反而更不能忽略或省略。如果你的直屬成員超過15人,那麼你的現行組織必須分層或者分開,除非你的組織是「人力導向」而非「人才導向」否則,超過10人的直接管理已經是極端困難,超過15個人是幾乎不可行。有些主管會驕傲地說,我的直接report-line有35個人,通常這樣的主管已經默默地分出階層,會找尋team leader來取代主管的工作,而大部分的時候team leader才是真正的主管。

一對一面談(one-on-one, 以下簡稱1-on-1)主要的目的有幾個:
1. 了解該成員的士氣情況
2. 了解該成員工作上是否遇到困難
3. 了解是否有需要處理的人際問題
4. 給與成員過去工作表現的精簡摘要:做的很好,或者做得還好,或者做得不好
5. 讓成員給自己回饋


一般來說,1-on-1不應該用來解決「技術問題」,技術問題應該是透明解決,而非兩個人私下解決。除非團隊人數剛好就是兩個人。

1-on-1的推薦作法:


一:固定架構與取得事實優先


當談話有固定架構時,部屬在每一次談話自然就有期待,以及自然地提供所需要的資訊,而這些事實資訊就反映到一對一談話的目的。

所謂固定架構很簡單,就是鎖定2到5個基本問題,這些問題是取得事實,並且應該很快可以回答。舉例來說:

(a) 請問你上次1-on-1到今天為止,有沒有遇到讓你很生氣的事情
(b) 從現在到未來2個月內,你有離職的「打算」嗎
(c) 今天有什麼事情,是你認為我要馬上去做的
(d) 從上次1-on-1到今天為止,你覺得工作開心嗎

這些問題都可以簡要的了解此成員的現況。重點是要用張簡單的紙長期追蹤這些問題。

二:自由討論時間以傾聽為主,下次必定追蹤!


固定問題需要紀錄,自由討論時間更是需要傾聽紀錄和追蹤!

自由討論當然以傾聽為主,在團隊成員還沒徹底講完,只做記錄千萬不要打斷。在結尾時,要說明你記錄了什麼。如果是組織做的事情好壞,公司目前現況,專案進度等等相關的,不用在1-on-1之間有結論,但一定要能夠紀錄,並且承諾會重視他講的所有事情。

重點在此!下一次1-on-1必定要重述他曾經重視的事情。並且,說明這些事情目前的現況,同時也和他討論這些事情對他現在還重要嗎?畢竟很多時候團隊成員只是需要抒發心情,並不真的重視這些,他們可能更重視的是「主管有重視」而已。

三:陷阱!不要做這些事情!


請注意以下陷阱!

1. 千萬不要和團隊成員一起抱怨公司政策,或者一起抱怨某個公司員工或主管
2. 絕對不能承諾無法100%達到的事情
3. 傾聽抱怨是應該的,但導向抱怨成為可執行的行動是最重要的一步
4. 切勿打聽A成員對B成員的個人看法!但可以詢問A成員關於其他員工某個特定時間點做的某件特定事情。
5. 1-on-1必須要有自己的筆記,千萬不要忽略紀錄


2/08/2019

如何在工作中成長


過去招募時,常聽到軟體工程師的離職原因,是因為在公司已經沒發展空間,無法成長。在某些情況下的確有可能,但更多情況下是工程師限制了自己成長,並非公司已經沒有成長空間。

每個人所謂的成長有很多種類,有些人追求的是技術的成長,有些人則是職位的成長,當然每個人多少都會追求薪資的成長。無論如何,環境確實是職涯成長的重要因素,只是工作環境的選擇,通常只決定了個人成長的一部分,而非全部!

如何在工作中成長有幾個要點:

(1) 培養成長心態


成長心態與固定心態在過去幾年中常被討論,無論是ted還是書籍皆如此。

簡單的說,擁有成長心態的人會視問題與困難為自己的挑戰,知道克服了挑戰之後,自己會成功並且有所成長。並且,擁有成長心態的人,會審慎看到自己以及環境的問題,不會一昧地把問題歸咎於外在因素。並且,擁有成長心態的人比較容易知道努力不見得會成功,但是不努力鐵定不行。

關於成長心態還有很多常見故事,請自行上網搜尋。但在此舉個反面的例子:完全不具備成長心態的人,會將自己的問題歸咎於環境問題,直接的表現在職場上就容易極短時間換了許多工作,詢問過去做得不好的事情時常歸咎於環境等等。


(2) 建立能和現在環境結合的學習清單


只要是正常合理的公司,通常都有值得學習的地方。有時候,光是公司仍然還能賺錢這點,就已經值得學習。

然而,軟體工程師的天性就是學習「新事物」。對於已經熟練的技術和事物,久了總是會覺得厭倦。厭倦倒是無所謂,重點是厭倦之後怎麼辦?成熟的軟體工程師通常會了解,真實的環境需要的是「能正確無誤並且低成本有效率的工具與環境」,而非需要「最近好像很熱門的嶄新技術」

成熟的軟體工程師能找到環境與自己的平衡,如果要學習新事物,就應該建立學習的方向,最簡單的方式不外乎就是建立學習清單。

技術上的學習清單容易取得,但是,能和個人現在身處的環境結合就需要認真的想一下。

(3) 主動執行

執行自己的計畫聽起來容易做起來難。大部分的情況下,軟體工程師(特別是處於大公司中)都會認為自己在為別人工作。

事實上,至少在台灣就業市場上的勞工都是在「為別人工作的情況下為了自己而工作」。因為現行的台灣就業市場,已經非常接近自由透明的市場,只要「有能力」通常都可以有非常大的選擇。

執行各種學習計畫的要點在於「這是為自己而做」而非為了別人。



一個考慮離開目前環境的軟體工程師,通常會將「能在工作中成長列為尋找新公司的重要條件」。但其實更重要的是要讓自己有能力「無論在任何環境中成長」是為更重要要做的事情。





10/28/2018

企業巫醫:手寫的工作筆記,讓你跨越困難



筆記本加上一支筆,大概是最便宜,最容易改善工作的工具。

網路上有非常多「如何做筆記」的相關文章,特別是如何做學習筆記(例如這裡,這裡,這裡)。在職場上,特別是知識工作者,幾乎都有做記錄的必要,然而由於資訊工具的改良,許多人會改用手機,平板,電腦來做筆記。畢竟數位化還是資訊快速膨脹的主流。

在此並非建議走回頭路。數位化記錄,絕對是必要而且有幫助。企業裡面的知識庫,wiki以及追蹤工作工具(jira, redmine, trello等等),絕對是讓組織整體提高做事的透明度,持續傳遞經驗知識的最好方式。

然而,對於個人職涯發展而言,還是建議要透過工作筆記,來提升職涯發展,增加自己的能力與視野的人,最好還是擁有一套自己手寫記錄的方式。

原因如下:


(1) 手寫的學習效果遠遠超過打字


有太多太多研究顯示,手寫的理解與記憶效果,遠遠超過打字。請參考:這篇這篇這篇這篇。或許有人會說,工作筆記又不是學校筆記,但如果深究這些研究會發現,其實概念相當一致,也就說,手寫某件事情,會增強對這件事情的「理解力」,「創造力」與「想像力」,然而打字卻不會!而廣泛知識類型的工作也是,職場上對事情的理解和掌握越高,越有想像空間,當然工作本身做得越好。


(2) 成本低

當然,現在平板也可以手寫,所以廣義地說,如果習慣的話,平板也是可以。然而,再貴的筆記本,其運用成本,仍然比平板低。除了價格之外,運用成本包含環境限制(例如要充電)。


(3) 手寫讓思考聚焦


無論是用哪種輸入法,即便是最簡單的注音,只要一段時間,每個人的打字數度都會遠超過手寫速度。然而,正因為如此,手寫可以讓頭腦有思考聚焦的功能。腦中會自己思索,應該聚焦的關鍵,進而思考關鍵的意義,這對掌握工作的要點,並且讓一個人在繁忙工作中,找出一條正確的道路有絕大的幫助。請參考這篇


那麼,要如何做工作筆記?


(1) 立刻買一本


假設你沒有筆記本,也沒有做工作筆記的習慣,那麼就「現在馬上去買一本」。習慣的建立是需要時間。不建議去買很貴的Moleskine筆記本,即使是代購團購的Moleskine也是頗貴。當然它的質感,可長期保存,書寫良好,硬殼和收納設計都首屈一指。不過其實隨便到文具店買不到一百元的即可。



(2) 上班中隨身攜帶,隨時紀錄



聽起來簡單,但要養成比帶手機更隨身的攜帶是有點難。無論是開會,還是座位自己位子上,確保重要的事情,都應該即時簡單的紀錄。筆記本應該是隨著時間紀錄。而且,並不限制記錄內容。如果是開會,建議使用心智圖的方式記錄。
提醒一下,筆記本並不僅止手寫手畫,也可以將重要的檔案email,直接列印貼在筆記本上。未來當重新檢視工作時,有莫大的幫助。

紀錄的內容以「事實」為優先,同時當然要記錄時間。工作記錄並非你自己的日記。雖然,這是自己私人的紀錄,但最好不要紀錄感想或情緒;而是確切記錄事實,因果,困難,解決方案,效果等等。

除了記錄之外,筆記可涵蓋「簡單計畫」,也就是「本來打算如何做」。例如,在工作中發現你對某技術不了解,於是你就在筆記本中草草紀錄一行「學習某技術」。隨即在這行字下面,就可以做得簡單的計畫,例如:1. 10分鐘上網查詢。 2.問一下某某同事。 3.在本週末練習此技術。

當你有任何打算做的事情,拆解成為執行的行動,簡單紀錄,日後就很快可以檢查這些行動是否完成,或者計畫是否要改變。

要注意!工作筆記是幫助你「動起來」的最好方式!


(3) 每月摘要,自我檢討


工作筆記,最最最重要的功能就是,每個月找個20分鐘的時間,將過去一個月自己做的筆記認真看過。然而透過紀錄,回答自己以下問題:(a) 這個月我有做幫助公司組織哪些重要事情 (b) 這些事情做完了沒 (c)隨便換個人也能做這些事嗎? (d) 過去一個月我有沒有學到新事物(e) 有沒有遺漏重要的事情還沒進行。將這些問題,自我回答到筆記本中。
這種檢討方式,特別適合在坐捷運的時候進行。


筆記本加上一支筆,大概是最便宜,最容易改善工作的工具。如果你認為自己的職涯發展受到侷限,或者遇到困難,而你又沒有做筆記的習慣的話,那麼其實不妨一試,只要長期累積必有成效。





7/20/2018

企業巫醫:應該要在同一間公司待多久?



一個在就業市場工作的人,到底應該在一間公司待多久才算「正常」。就產業的不同,自然有截然不同的答案。就資訊科技領域來說,過於頻繁地更換工作,會讓求職者更難找到好工作。

何謂頻繁更換?當在現有工作遇到瓶頸,自己有機會透過自身能力改善瓶頸,然而卻選擇離開就算頻繁。

真要講個數字的話:
* 工作7年以上,在最後7年的職業生涯中,但不在任何組織中待超過2.5年,就會被列入低優先考量 - 並非完全不考慮,而只是不優先聯絡。
* 工作3-7年,但不在任何組織待超過1.5年,也是屬於低優先考量。
* 工作3年之內,其實到不用太在意。

理由是 考量「大部分的情況」,而非考慮「極端情況」。

大部分的情況是:

工作7年以上,但最後的七年,沒有在任何組織待超過2.5年,表示曾經換過起碼4~5個工作。然而資深的工程師,通常其工作內容是比較困難的,並應該能展現其架構設計與實作的經驗。可是,如果其架構設計,並沒有被「市場驗證」那就很難用各種方式評斷他的真實能力。講得更直白的是:也許這位資訊工程師,雖然有N年工作經驗,但搞不好每次都挖洞給別人跳,自己拍拍屁股就走了。或者是,也許他工作能力其實普通,但「自我感覺太好」因此老是覺得自己應該找到更好的工作。而更重要的事實是,他的確離開了,這事實也表示這4~5個工作並沒有「留才」的意願。兩年半是最低限度檢驗一個工程師,在技術上能取得「市場驗證」的時間,兩年半表示工程師至少經過兩次以上的績效考核,並且其工作的正面負面評價也容易以事實檢驗。

極端情況是:這位資深工程師運氣太差,雖然各方面能力都好,但就是遇人不淑,常常遇到公司倒閉。或者有不得已的家庭因素。

許多企業巫醫都有各種不同的見解(請參見最下面的參考文章),但整體來說,職涯長短雖然因人而異,但最好不要把自己視為特殊例外。而應該以市場上的事實,來推估自己職涯最適合的況狀。

舉例來說,有些人認為只要沒有成長學習性,就應該換工作,但是過去七年沒有一個工作做超過兩年半,難道表示這五個工作的內容「統統都學精通」?如果老是遇到不好的工作機會,是否就表示「自己對專業工作機會的好壞判斷有問題」而專業機會的判斷,通常也是資深工程師應該要具備。

就業市場的事實是過於頻繁換工作「通常」表示有問題,頻繁換工作的大部分人是屬於通常,而非特殊例外。


參考文章:
* 在一個公司裡為何要待十年的十個好理由
* 在一個公司待太久不好嗎?
* 在同一公司內部發展職涯才聰明
* 在同一間公司不要待超過四年喔
* 你在公司待很久了嗎
* 在一個公司待太久會對職涯不利嗎?






4/30/2018

在多個工作機會中的選擇


只要有數年工作經驗,一個還不錯的軟體工程師,在轉職的時候,應該都有可以拿到3個以上的錄取通知。然後,從中選擇一個最好的工作變成另一個快樂的問題。

如何在獲得錄用的公司中選擇?

扣除掉工作距離,家庭因素,法律因素之後(註一),有以下幾個方向可供在多個工作機會中選擇的參考:

(1) 優缺點列表


將你的選擇寫在紙上,例如A,B,C三個公司。並且將你認為的優缺點條列出來。

這雖然是很基本的做法,但將腦中的思緒,用另一個方式呈現,會讓思考者以較高而且抽象的角度思考選擇性問題。

大部分的人,會列出條列項目大概是:使用的技術,工作內容是否有趣,薪資,工作時間,壓力大小,未來發展性等等。

除了薪資與目前使用技術之外,這些項目大部分都「主觀的判斷」。盡可能在優缺點列表使用客觀的資料。

以未來發展性為例,一個成立不到一年的新創公司,無論其產品有多厲害,它的未來基本上有90%的機會會在2年內倒閉,這到目前為止是鐵的事實。而上市上櫃公司,未來發展性應該優先調查過去3年的財報來判斷,而非看目前的股票價格。

再以工作內容是否有趣為例:必須要是「你到職之後會做的工作」來判斷是否有趣,而非是這公司產品很有趣。因為,即使是資深軟體工程師,到一個新地方也有可能會先做最無聊的工作。

最後,壓力其實因人而異,但客觀的判斷也不可避免,應該以「過去一年有多少比例的人離職」這類型的數字做為判斷的依據。

(2) 自身能力所帶來的影響力


除非是你自己就是這公司的老闆,否則,當你加入一個工作時,透過自己能力的產出,對公司造成正面影響力,是唯一你能做得好做的開心的原因。其他皆屬次要。

某些工作的特性,讓軟體工程師本身的影響力比較低,舉例來說,所有傳統的IT工作恐怕都是如此。即便IT工作非常重要,但通常被歸類為「保健因素」:也就是沒有會死,但太好也沒用。

某些工作看似很重要,但由於組織結構龐大,讓資深軟體工程師發揮空間較有限。例如在超大型軟體公司,有上千名員工,即便是非常厲害資深的工程師,其實對組織而言相對重要性也低。一個超過千名工程師的公司,不會有任何一個工程師特別重。

小型公司對大部分的軟體工程師來說,都比較能透過自身能力,發揮較大的影響力。這也是為什麼過去數年,新創公司能蓬勃發展的原因之一。但的確也有可能,大型公司的某些小型部門,工程師反而會發揮巨大影響力,line的故事可作為參考

(3) 未來的主管


英文俗語: people quit their bosses, not their jobs.  
在有多個工作機會選擇下,未來的主管是誰變成是重大的考量。

(a) 不知道是誰?

特別是超大型企業,新建員工會有「儲備培訓期」因此有可能在加入此公司之後一段時間,都不太能確定未來主管是誰。這在軟體開發的領域機會不大,尤其是對資深工程師來說。

(b) 考量的方式

盡可能以「事實」來考量,而非憑「感覺」。面試時通常會有問問題的機會,此時可以探究事實。基本的事實像是:團隊有多少人,最近三次加班是什麼時候,最近一次績效評估中,產出最好的員工做了哪些事情。感覺則是「這裡看起來好像很溫馨」,「面試我的主管看氣來很溫和」。

大部分的情況下應徵者期待的是「一個好主管」。然而,人非聖賢,要考量的其實是管理風格上最適合的主管。因此,詢問管理上實質作法,就是考量的最大因素。

當然,這些考量的事實,也應該呈現在比較的優缺點表格中。






註一:法律因素是指,即便有超高薪水,不合法的工作還是千萬別碰。

11/16/2017

軟體專案管理 - 版本控制系統內的程式碼基本分析


孫子兵法:夫未戰而廟算勝者,得算多也;未戰而廟算不勝者,得算少也。多算勝,少算不勝,而況無算乎!

任何軟體開發專案的基礎都是「程式碼」。即使,專案經理不需要親身撰寫程式碼,但是必然要能夠透過程式碼,取得專案關鍵資訊,作為專案領導管理的最佳參考。(關於專案進度,請參見這篇。)

版本控制系統(git, cvs, p4, svn等等),則是有效控制程式碼的基礎,開發過程大部分的事情會發生在這裡,也應該發生在這裡。

如果你的軟體開發專案,沒有使用版本控制系統!!??...呃....請參考註1。

版本控制系統「至少」可以提供以下這些重要而且基本的訊息給專案管理者:

(1) 截至目前為止,有多少人實質參與專案
(2) 截至目前為止,專案的實質規模(程式碼檔案數量 行數等等)
(3) 一段時間內,此專案程式碼品質的推測
(4) 一段時間內,例如過去48小時,軟體團隊的實質產出
(5) 一段時間內,例如過去7天,有沒有人在非上班時間內工作


專案管理者(或者Scrum Master)應該自己取得這些訊息。為什麼??



"Доверяй, но проверяй
 - 俄羅斯名言,意思是 Trust, but verify  

冷戰期間美國總統雷根特別愛用此名言,根據wiki說明,雷根是受到一個作家的影響






因為,過去專案管理者常見兩種極端:

(1) 極端放任自由:在Scrum的精神下,雖然每天站立會議和燃燼圖,都可以揭露專案最確切的進展,完全相信成員的口頭回報
(2) 極端間接的繁複審閱:在沒有技術背景的情況下,透過頻繁而起瑣碎的會議,加上各式各樣文件追蹤,試圖了解目前進展。

這兩者都有明顯的問題,Trust, but verify才是正確做法。以Scrum的精神取得每日進展,並且,專案管理者應該「自己」想辦法檢查。專案管理者,如果沒辦法自己檢查,表示對此專案的本職學能不足。(註2)


專案管理者能夠做的程式碼基本分析有很多。好的專案管理者,至少需要能自己「動手」,利用工具或者程式,透過事實,了解下面三件事情:

(a) 基本專案狀態分析:哪些人寫了哪些程式碼
(b) 哪些程式碼檔案很重要:某些程式碼就是常有問題
(c) 哪些人需要額外關注:某些人工作壓力大常加班

以下以git為例,其他版本控制系統也能做到類似的事情。


基本專案狀態分析


靜態程式碼分析工具有很多。例如,gitinspector可以揭露整個專案的大致情況。gitinspector的安裝使用請參考這裡
以github上的serverless.com為例,在github上clone這個專案,並且執行#gitinspector的結果如下:


首先會大致列出作者和過去的產出摘要,例如Aaron在這個專案一共commit了8次,包含170行程式碼跟刪除87行。這個表當然不能作為績效考核用途,但是可作為參與度的重要參考。很明顯的Austen鐵定比Chris的參與度高很多。




接下來隨即會列出還存在的程式碼行數。以Austen來說,他還有2713行的程式碼存在。和他的總新增行數與刪除行數有很大的差別。這很有可能是他參與了開發初期,而開發後期的版本沒參與。




哪些程式可能容易有問題?

程式設計師每天辛勤的工作,自然會知道哪些程式常出問題。而專案管理者必須要由技術面來獲取正確的資訊。版本控制系統會記錄每次程式修改的原因(如果commit的備註正確的話)。最簡單列出「要注意的哪些程式碼檔案」

git log指令,可以加上 --grep=<string> 來濾出字串,以下例子只用fix當作過濾條件,並且配合linux其他指令:sort, uniq 就做出簡單的報表:


~/serverless# git --no-pager log --name-only \
--grep=fix  --pretty="%s" | sort | uniq -c | sort -n
     19 lib/ServerlessState.js
     19 tests/tests/actions/ResourcesDeploy.js
     20 lib/ServerlessProject.js
     23 lib/actions/EndpointDeploy.js
     23 lib/actions/ProjectInit.js
     23 lib/actions/RegionCreate.js
     23 lib/SerializerFileSystem.js
     24 lib/Serverless.js
     25 lib/actions/ResourcesDeploy.js
     25 lib/actions/StageCreate.js
     25 tests/test_utils.js
     27 package.json
     27 README.md
     28 lib/actions/FunctionRun.js
     34 lib/actions/FunctionDeploy.js
     38 lib/actions/FunctionCreate.js
     55 lib/utils/index.js
    101 tests/all.js

當然,以上報表只是列出有fix字串的commit中,哪些檔案出現次數最多。 tests/all.js 明顯是最多的,但也很明顯這檔案本來就是會被一直修改。此外,README.md也是一樣,大概也不是真正有問題。不過其餘的檔案倒是可以額外關注一下。

程式有問題的的判斷方式有很多,除了在commit的紀錄中說明是[fix]或[bug fix]之類。但也可以考慮總行數,刪除的行數,增加的行數,並且配合QA/bug tracking系統,才較為完整。


哪些人需要額外關注?


「人的問題」,永遠是最難解決的問題。然而,卻也是要優先解決的問題。組織中必然有需要「被關心」的人。

專案組織中,最要被關心的人是「表現好且有潛在壓力大」,以及「表現不好且對團隊有負面影響」這兩種。其中,表現好的人更是要優先處理。

除了每天例行工作接觸之外,專案管理者應該要有確切的「數字」。假設,我們想知道在此專案中,哪些人常常「晚上」工作。最簡單的方式是分兩步驟,先用git列出作者時間,然在寫個簡單的統計程式,列出所有人的「晚上」工作時間和「平常」工作時間次數。

* 步驟一:先取得所有的branch, 然後, 以下git log指令可以列出作者和時間,並且輸出到檔案author_time_log

 

# for BRANCH in $(git branch -a | grep remotes | grep -v HEAD | grep -v master); do git checkout --track "${BRANCH}"; done
# git --no-pager log --all --pretty="%an,%ai" > author_time_log


檔案內容大概如下
....
Austen Collins,2015-08-05 18:28:18 -0700
Austen Collins,2015-08-05 17:26:26 -0700
ryanp,2015-08-05 17:04:37 -0500
Derek van Vliet,2015-08-05 09:31:56 -0400
Michael Friis,2015-08-04 18:54:03 -0700
Austen Collins,2015-08-04 15:04:46 -0700
Colin Ramsay,2015-08-04 22:03:48 +0100
Chas Warner,2015-08-04 14:53:59 -0600
Austen Collins,2015-08-04 11:19:31 -0700
Austen Collins,2015-08-04 11:15:44 -0700
Austen Collins,2015-08-04 11:11:06 -0700
Austen Collins,2015-08-04 11:09:24 -0700
....


* 步驟二:撰寫簡單的分析程式,設定正常時間是早上7點到晚上8點,其餘都算不正常時間。用人名為單位加總之後,就可以產出簡單的報表。簡單的統計程式原始碼請參考這裡

此表中,Eslam幾乎有一半的commit都是在晚上產生,而Kamil則是標準完全正常時間工作。

Joe Turgeon [1, 0]
Erik Erikson [15, 7]
Ian Serlin [1, 0]
David Hérault [1, 0]
Peyton Zhou [2, 0]
Kazato Sugimoto [2, 0]
Nick den Engelsman [1, 0]
Kiryl Yermakou [0, 1]
Austen Collins [575, 267]
Kamil Burzynski [101, 0]
Frank Schmid [9, 2]
Jacob Evans [13, 1]
Michael McManus [1, 0]
Eslam A. Hefnawy [158, 132]
Dave Newman [0, 1]
Ryan S. Brown [35, 6]
doapp-ryanp [129, 48]
Michael Friis [1, 0]
Matthew Chase Whittemore [2, 0]


當然這並不代表Eslam的表現好而且壓力大,這只是提供給管理者參考的事實。專案管理者,必須要事實層面,檢查軟體專案的狀況,因為很多時候「會吵的小孩有糖吃」,只單純被煩就會給糖的專案主管,其實對團隊是沒有價值的。


小心統計陷阱

統計數字都可能會有陷阱,程式碼的基本分析也是統計的一種,自然要小心陷阱的存在。專案管理者應該要善用統計數字,切勿被統計數字所左右。請參考統計與謠言


 


註1:軟體開發專案不使用版本控制系統,會讓專案本身暴露在極端的風險中。如果你是專案管理者,讓專案暴露在風險中就是你的責任。如果你只是個開發人員,儘早離開高風險的環境才是上策。

註2:某種情況是,專案規模過於龐大,例如參與開發者超過100人,某些技術確實不見得能完全掌握,但專案管理者,仍然要保有部分自行檢查的能力。




10/17/2017

工作中速度與效率的迷思




孫子兵法:兵聞拙速 未睹巧之久也

媒體大亨Rupert Murdoch:不是大的打敗小的,而是快的打敗慢的


效率以及速度,在職場上的重要性應該眾所皆知。然而,速度並不見得會產生「效率」,當然也就可能沒有「績效產出」。

工作中的速度與效率常見有幾種迷思如下:


速度的相對論


在職場上,速度時常是相對的。

有個笑話最適合描述這樣的相對論:兩個好朋友去非洲野營,在帳篷睡到半夜,聽到有獅子在附近低鳴,似乎打算把這兩人當作食物。其中一人開始穿衣服鞋子,另一人惶恐地問「我們有辦法跑得比獅子快嗎」,已經穿完鞋子正在做熱身操的那位仁兄回答:「我不需要跑得比獅子快,我只要跑得比你快就好」

然而,相對論的確有其迷思與限制。例如,在大型企業中,或許你已經是個主管,相對於其他同事,你也有創意,而且你辦事速度也很都快,看似一切穩當。但是有一天,你所屬的部門被公司老闆出售給外國企業,而該企業也表明只需要技術人才,不需要主管階級時,你才發現原來速度的比較對象,不應該僅僅是在自己的組織之中。(沒錯,這裡說的是HTC最近的賣部門給google的事情)


過程與結果的本末倒置


速度應該是「過程」,而效率和產出,才是「結果」。

把速度當作結果等於是本末倒置。

所以,讓網頁的使用者回應時間,從2.5秒,加速到0.25秒,看似一個有指標性質的結果。但已產出的觀點來看,其實可能是要達到「服務更多使用者」「增加效率」或甚至「減少電費」這些確切結果的「過程」。

工作中單以「速度」作為結果的績效指標,很快就會導致局部最佳化的組織問題。


沒有目標的ASAP


當詢問同事/主管說「請問這件事情應該何時完成」,如果時常聽到ASAP-as soon as possible 越快越好,而沒有具體的解釋,其實是危險的指標。

沒有具體衡量的速度,可能導致幾種錯誤想法:

(1) 這是不計一切代價要越快完成越好的事情,即便犧牲性命也在所不遲,因為一旦完成就會有很美好的事情發生。這樣的想法過於革命性的危險,事實上,僅有極端少的事情是不計一切代價,連生命都可以不要的。

(2) 每個人的時間感受不同。也許CEO的告訴中間主管的ASAP,在當時他的心中是指3個月,而中間主管告訴工程師的ASAP,在他當時的心中是指3個禮拜,可是,工程師的感受可能是5天。最糟的情況是,工程師會誤以為ASAP表示可以犧牲品質,如同上段所述,是可以不計一切代價達到速度。

(3) 有太多事項都是ASAP時,表示根本沒有設定正確的目標以及優先順序。




附註,關於速度突破職場困境,請參考這篇

5/22/2017

企業巫醫 - 講重點!




在許多企業巫醫的書籍文章演講中,都繪聲繪影的描述「講重點」是極端重要。但也僅只是說它很重要,卻擺明著忽略這件事的真正重點:「關鍵重點難以找到」,或者更直接的「怎樣找到重點」。


就只是像提醒健康很重要的提醒「講重點」的文章像是:這裡這裡

另一些文章,表面上提出一些找到重點的方式,但是壓根也是一堆廢話。例如:從對方觀點找到真正價值。聽起來很有道理,但就像部落巫醫說:「得罪了祖靈,所以你生病了」,看似有理,但是到底做了什麼得罪了祖靈才是重點吧。「如何」知道對方的觀點,才是找到重點的重點。這類型的文章例如:這裡這裡這裡

只而更有些文章,提出了似乎務實的步驟,但都是太過一般化的案例,不是類似秘書處理好老闆的行程,就是與別人討論時的對話重點。這些在技術為主體的組織裡也根本派不上用場,例如:這裡這裡


絕大部分的人在工作上,並非不講重點,而是講不出來或找不到。而很遺憾的是,複雜環境(參考Cynefin架構)下的關鍵重點,並沒有簡單的三步驟,也沒有五個必備SOP之類的方式就可以取得。

關鍵因素的掌握,需要知識與經驗的累積。

知識的累積會堆積成智慧,經驗的累積會變成靈感,而智慧與靈感綜合起來,就能在複雜事物上以很短的時間將其抽象簡化,而抽象簡化的事物就容易看出重點。

雖然沒有捷徑,但就像是健身減肥一樣,從任何時間開始都不嫌晚。而且從任何時間點開始,都可以在比自己想像的時間內還早獲得效果。

知識的累積


只要抱著開放的心態,多閱讀,多請益,大概就很容易做到知識的累積。(知識快速累積可參考這裡)

值得注意的是,知識也有分軟硬兩種類型(註1)。

軟知識:談判技巧,溝通技巧,專案管理,人際關係,等等都屬於軟知識。換言之,軟知識可能會隨著文化背景改變而有截然不同的結果。

軟知識,容易落入「嘴砲唬爛」的範圍。軟知識的累積因為太多太多地方可取得,就不在這裡討論。要稍微注意的是,無論是什麼樣的人對「軟知識」都有自己的一套煞有其事的說法,要注意不要落入「純唬爛嘴砲」的範圍之中。

硬知識:數學,工程,程式設計,等等都屬於知識。換言之,硬知識不會隨環境的改變而改變,但它會隨時代的進步而進步,容易站在巨人的肩膀上前進。

硬知識,容易變得「極端」,不是容易被忽略,就是容易被過度強化。

絕大部分在組織工作的人,只要有數年以上工作經驗,都知道軟知識的重要。而各類型心靈成長,溝通協調,領導管理的書籍課程就孕育而生。在組織中,最極端的中階主管就會有意無意透露出「軟知識」遠比「硬知識」來得重要的許多(註2)。

最佳的情況是:硬知識和軟知識必須要互為成長基柱。兩者兼具的成長。

硬知識的累積:非常簡單,(1) 先設定知識累積範圍,例如設定為軟體品質改善 (2) 利用mindmap圖,整理自己已經在腦海的知識 (3)去圖書館至少借7本相關書籍,(4)上網尋找相關知識 (5) 閱讀並且搜尋完之後,僅憑自己的記憶和腦中統整結果,再次畫出mindmap圖,有必要的時候進行實作(例如寫程式)


經驗的累積


經驗可以解決在Cynefin framework中,「複雜」與「渾沌」這兩個象限的問題。(關於Cynefin請參考這篇)

不過,經驗的累積方式是經驗是否能「持續累積」的關鍵。

同樣一件事情做20年,有些人會取得20年的寶貴經驗,有些人卻是像是只做了1年一樣:只是做了20次一年。

以軟體開發為例:

1. 在SAP的ERP環境下,撰寫相關模組20年,如果沒有產業相關知識的成長,只負責出各種報表,那麼和2年經驗也差不多

2. 做為專案經理超過20年,如果遇到事情只會加班解決,那麼和1年經驗也差不多(參考這裡)。

3. 做為有10年開發經驗的java程式設計師,如果遇到組織調整,需要使用其他程式語言,但用各種方式拒絕推託,那麼未來可能就變成只有數年經驗值的程式設計師。因為推託學習不但會讓技術停滯不前,還會退後。

經驗的持續累積也很簡單。重點在於「持續」:每隔一段時間檢視自己的工作筆記,看看自己是否做了任何改善現在工作的技術的事情。如果沒有,就表示沒有持續累積經驗,經驗僅只是停滯而已。

沒有工作筆記?趕快去買一本吧,筆記本太便宜好用了。







註1:當然有些知識很難分軟硬,這裡只是概述而已。
註2:例如,軟體開發有個傳言:「coding co的好,要飯要到老。」

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/23/2017

企業巫醫 - 贅字 廢話 泥巴仗




在組織中,溝通合作是大部分的人一定會做的事情。

溝通合作說起來簡單,畢竟人類是靠群體合作而存活在地球上。不過,在企業內部的有效溝通並不如想像中的容易(註1)。

某些人在對話或文字表達上,有意無意的更增加溝通的難度。如果是無心的,僅只是造成困擾而已。但如果是刻意為之,會讓溝通困難,讓事情滯礙難行。

無論有意無意,溝通上常見三個問題:「贅字」「廢話」「泥巴仗」

在這三個之中,贅字和廢話很煩人,但真正要解決的是可怕的泥巴仗。


贅字


典型的例子,像是最近淡江大學解聘兼任教師的新聞:高教工會主任:「學校也一再地向(兼任教師)表示說,也是因為今年的8月1日,勞基法要開始適用於,未具本職的兼任教師身上,學校不想負擔這樣的人事成本,所以他們才會做了一個解聘跟不續聘的動作。」

有人稱這類型的贅字為「語言癌」。(註2)

凡舉「關於XXXX這個部分」,「做一個XXX的動作」,無意義的拉長語句都是。

當然也有些人認為拉長語句是「敬語」的表達方式(註3)。

此外,狀聲詞:「嗯」「唉」「阿」因為在對話中,有實質表達情緒的功能,所以不算是贅字。

不過,贅字真正的影響其實很小,只是太多贅字會讓聽的人很不舒服而已。



廢話


在說明事情,或者文件上,用過多虛浮的形容詞,掩飾無意義的內容。或者,重複不證自明的真理,用以掩蓋無法找到重點的對話。

在政府機關的公務人員出國報告網,可以輕易地查詢到充滿廢話的報告。

例如:一個公司是多面向的結合。(簡單的說,整句都是廢話)

例如:透過本次會議實際瞭解大陸生醫相關市場現況,就本所研發之核醫藥物推廣應用極具參考價值,可納入本所未來研發方向之參酌。 (簡單的說,出國去參加這個會議,最後只是參觀看看而已,沒什麼東西是真的影響組織的研發方向!)

另一個例子:不論是什麼樣類型的數位化工具,除了便利性外,都應兼顧到安全性,日後推動電子化政府的過程中,應與各級資訊安全主管機關做密切的合作,確保資訊科技的演進不會成為資安漏洞。(資訊科技本來就不應該是資安漏洞,各級安全主管機關本來也就應該合作,哪會需要出國參加會議之後才知道這兩件重要的事?)

當然,某些企業網站資訊,也是廢話很多。不過,大部分是似是而非的術語,構築專業能力的感受。

例如:透過嚴格的專案控管與扎實的系統建置專業能力,我們有信心提供客戶最安心、最可靠的大數據優質服務。(如果把形容詞拿掉,這句話其實很短:我們提供專案控制和系統建置的大數據服務。但更具體一點,就是:其實有案子我們就可以接來做,大數據只是個行銷名詞)

有時候廢話很煩人,因為要花些力氣才能抵達事實真相。廢話浪費的很多時間,不過如果採用Scrum方法論,在會議上只專注於現況和事實,應該不太可能會有廢話太多的問題。至於網頁資訊和技術文件,就應該盡可能去除廢話。

泥巴仗


最高級,並且更難應對的是泥巴仗。

特別是在中大型組織,中階主管通常都位於關鍵職位。而好的中階主管,仍具備本職學能(註3),會根據事實來溝通。也因此,優秀的中階主管通常會強調技術事實,產業事實,專案事實,資源分配事實...等等諸多事實根據,作為溝通以及決策的基礎。因此,反倒不會強調本身的溝通協調能力。因為這樣的能力,如同影子一般隨附在工作之中。

然而糟糕的中階主管,由於已喪失本職學能(註4),就會強調其「協調溝通」成為其最重要的工作。然而,不基於事實和邏輯的溝通,會變得混亂不堪。某些糟糕的中階主管,在遇到爭議性問題時,會用打模糊的方式,試圖讓大家在泥巴仗中度過。而最高階的泥巴仗,會用看似合理的邏輯,但展示對技術完完全全無法掌握的事實。

例如:這個影片,非常經典,看似誇張,但在資訊科技產業其實常常發生。在該影片中,真正做事情只有一個人,而中階主管遇到技術難度的問題會省略甚至推諉,不能體會真正的重點而死咬不重要的細節,而技術人員要探索細節又會說這是專家的工作範圍。當然該影片是太誇張了一點,但其實在中大型組織時常發生類似的事情。

另一個例子:在老大靠邊閃中的有名片段,first thing or second thing。主角完全是用打泥巴仗的方式,在黑幫大老會議裡,刻意激怒某老大。而其他大老反倒會覺得生氣的老大很沒風度,一開始沒發現主角在打泥巴仗。

在此徵求案例:徵求在資訊科技中,重要會議裡打泥巴仗的案例。 


混亂泥巴仗是很可怕,要對應泥巴仗有先決條件,就是這不能是在「只有兩個人」的情況下。換言之,會議或者文件,至少要有三個人在場才有機會擺脫泥巴仗。

只有兩個人的情況下,只要有一人刻意打泥巴仗互相把對方弄的髒兮兮的,而且這個人還是中高階經理,另一個人根本不可能解決。唯一的方式是,儘速逃離現場,在下次確保有第三人以上在場。

在有起碼三人的情況下,以下方式可以解決泥巴仗問題。


1. 不隨之起舞


泥巴仗成立的條件是互抹泥巴。例如,在軟體專案中,當大家在解決A模組為何落後時,如果有人反覆提及一些沒有直接關連的事情:也許是另一個專案也落後了,也許是某RD的溝通態度不好。這些都是泥巴仗的徵兆。


2. 以白板展現事實


人的思考和言語是線性,因此在看穿複雜問題時,光是在腦中想是很容易被泥巴仗牽著走。

最好的方式是,一旦發現「同時」討論兩件以上的事情,就應該在白板畫圖或者條列。

畫圖是最好的選擇,最簡單的可以考慮心智圖或者魚骨圖。一旦有人試圖混淆事情,只要指一指說明我們現在在討論這個點,等討論完有決定之後,再往下一個點前進。而如果兩件事情有關連,就用線條與另一個點來說明此關連。

這也是為什麼,幾乎所有優秀的資訊從業人員(無論是低階還是高階)在會議中都喜歡坐在白板附近。


3. 耐心


簡單的說,就是有耐心的條理事情。透過工具(白板或紙)讓事情呈現。當知道對方採用泥巴仗手法-無論他是不是故意,就表示事情不會很快結束,因此要秉持著耐心條理問題。更重要的是,把這件事情當做類似刷牙洗臉的小事,在處理過程中沒有心情起伏 - 當然就不憤怒生氣)。






註1:特別是為求避免衝突,每人的說的話和實際心裡想的都有差距(參考left hand column),這讓組織 - 特別是資訊科技組織 - 運作上增加不必要的難度。

註2:  並不是去除重複字眼,極端簡潔就是好事。在文學作品中,言詞的優美有時候會透過層層疊疊的語句產生,請參考這裡。不過單就企業組織的溝通 - 例如開會 - 應該和寫小說是不一樣的。

註3: 參考這裡

註4: 以資訊科技來說,最基本的本職學能是寫程式,其他可以參考這裡這裡


12/10/2016

企業巫醫 - 提昇效率的秘方



這裡有幾本書...


- The Productivity Project 最有生產力的一年
- Four hours work week 一週工作四小時
- The Art of Non-Conformity不服從的創新
- THE $100 STARTUP三千元開始的自主人生
- Do over(不確定是否有中文翻譯)
- Nomad Life遊牧生活


這些書籍有很直接的共通點:


(1) 個人經驗


和一般以二手資料的企業巫醫的書不同,這些書籍都是以「個人實際經歷」為主要組成。可能沒有精湛繁複的巫醫術語,但是「因為自己有做過」也比較容易說服別人。


(2) 專注,效率,生產力


這些書籍或多或少都強調個人效率的重要。基本上不外乎討論80/20法則,生理因素,心靈意志,工具方法等等。


(3) 個人品牌創業


這些書籍的作者,其實都是「個人品牌創業家」。個人品牌創業大約在2006-2008年之後,在網路上蔚為風潮。特別是在北美,這些個人品牌創業家通常都會有(a)自己的blog (b)自己的書籍 (c) 一個看似專精的知識領域...接下來通常就組合優勢開始以自己的名聲盈利。




為何強調效率與生產力的重要?


合理的推測,這類型的書慢慢也會在亞洲流行起來。雖然僅只以個人經驗與觀點來詮釋某個複雜的龐大主題,可能失於偏頗。但相較於純以「個人想像」和「無根據的推理」的企業巫醫書籍比較起來,還是踏實的多。


其中,「專注,效率,生產力」是三位一體的永不衰退話題。自從有工業革命開始,效率/生產力便是工業界主要獲利來源。在1995之後的網路時代,雖然「創意」與「變革」突然成為顯學,但究竟沒有效率,無法被執行的創意,等於是一種空想。創意變為有效可執行的事項,才有實務上的意義(參考這裡)



因此,能否有專注,高效率,高生產力的產出,變成知識工作者必備的能力。而也是「缺乏資源」創業者成功的關鍵之一(參考這裡)。

而也正是因此,「提高生產力的祕方」,在近年來變成出書的顯學,甚至也成為「被創業」的利基來源(註1)。


個人提升效率生產力的祕方


很遺憾,並沒有什麼祕方可以「簡單而且戲劇性」的提高個人效率或者生產力。至少,沒有不需要努力的祕方。

在業界確實有各種「顧問」,可以針對特定的個人,特定的案例,提供收費的咨詢服務(註2)。但最終,教練顧問只能提供指引,還是只有自己幫助自己。


先考慮以下低成本的「尋找自己的祕方」的三步驟,大概只要花2天:


(1)  4小時閱讀



花四小時專心看完以下五本書就好,應該都有中文版。

- Getting Things Done  
- The Productivity Project 
- The 4 hour work week
- Lean startup
- Do Over


這些書所提的做法都比較務實,然而,不見得適合每個人。單看一本書,也會讓你的視野受到侷限。花時間去找一堆書來選,也太浪費。請先看上述幾本即可。看書並將自己覺得有用的地方做些記錄即可。

其中一本看起來是在講創業?即便你一點都不想創業,它提供的方式仍然對一般工作很有幫助!


(2) 停止接受資訊一天


如果你花了4小時看完那五本書,應該可以體驗到讓腦袋休息的重要。找一個假日,無論採用什麼方式,停止接收資訊一天 - 電腦,手機,書籍等等一概停用。隨便去做點跟工作無關的事情。


(3) 檢視並決定提升效率生產力的做法


經過了4小時學習,又經過了1天的沈澱。是時候可以決定哪一些「做法」,是最適合自己。只要是最適合自己的做法,就是自己的祕方。

如果還是想不到好方法,可以參考這篇。這是經過看了那五本書之後,經過一天的沈澱,個人認為最簡單適合自己的方式。也許對讀者也是個好的參考。







註1:例如,隔一陣子就會冒出來的「增加記憶力補習班」「全腦潛力開發課程」「超級記憶力」.....不過最終的結果,通常是這些提供祕方的企業巫醫們,口袋裝滿無知大眾的錢,而這些花大錢上課的群眾,其生產力與效率卻鮮少聽過提升的例子.....至少從來沒聽過任何創業有成的人曾經說:「喔!對了我創業成功的祕方,就是上了XX人的腦部開發課程,讓我記憶力變得過目不忘喔」

註2:在台灣大多以企業開班的方式存在,但這種效果極端有限。而美國英國兩地,都有針對個人的「導師服務」。但其收費都很驚人,而且大概也無法遠端服務。例如這家seven coach。也有很多個體戶,例如這位John Spence


10/10/2016

軟體專案的現實:解決人的問題




無論是否採用agile的開發方式,所有軟體專案,最大問題的來源都是人。

人的問題,通常會極現實的影響專案的進行。然而,妥善運用agile的精神和Scrum的方法,有機會讓人的問題降到某個程度。

某個朋友,姑且稱為K,在專案扮演專案經理的角色,遇到以下狀況:

我最近有遇到一個問題,不知道怎麼辦,下面的人一直做不到我的要求,或者動作很慢,即便壓日期給他,他還是沒辦法達到,但實際上它任務並不多,只是開test case,我不太知道怎樣push他,我又不想來硬...他只有這個任務 平常又常常看他在上facebook, line....覺得要當一個讓人喜歡的lead真的蠻難的....


這個問題非常典型。

以敏捷開發(agile)來說,解決方式似乎也很簡單。首先專注於優先項目,接下來根據事實檢視工作,最後才考慮能力問題。


一:專注於優先項目


每個人在Sprint之中一定有正在執行的項目。確保每個人都是「專注」於目前最優先的項目是Scrum master最基本的任務。

即便不是採用Scrum也一樣。團隊成員必然在某個時間點有一個特定任務。專案經理或領導者(leader)當然必須確保,在這個時間點他只會專注在這個工作任務上。

對於剛剛成立的團隊來說,要確保團隊成員專注於目前任務上的方式很簡單:就是腳踏實地的「問」。在該成員一來辦公室的時候,就坐到他座位旁,親切的詢問他昨天早上在做哪些事情,昨天下午在做哪些,並實際上「看」到做的結果。就可以確定他是否專注,而能確定是否做到真正的效果。

整個詢問的重點都是在了解事實,而不是監督細節。因此每天頂多也只針對「需要幫忙的成員」,一起坐著看實際上的狀況。


二:工作檢視

以Scrum而言,每天的會議(無論是不是站著)就是為了統一工作情況檢視。完成就是完成,沒有完成即便是已經達到99%也一樣是沒有完成。當然,前提是在Scrum開始時有定義「什麼叫做完成」 - Definition of Done。

如果不是採用Scrum,則應該盡可能在團隊開始時,就先定義何謂「完成」。

以開test case為例,完成是指把要做的功能的test case詳述在某個測試文件管理系統上?還是只要先用excel或者wiki列出來即可?test case完成後是否要先讓團隊成員審閱,看看有沒有問題?要不要先估計每個test case執行會花的時間?test case的前置作業 - 例如建立測試資料等等,是不是也要涵蓋在其中?

當有完整的工作完成定義之後,要讓負責進行工作的人「決定時間」,而非「被決定時間」。

以軟體專案而言,任何超過2天的工作項目(task),都應該分階段完成。畢竟,就事實而言,一個人不可能「連續工作2天」,每天一定會停住工作,下班回家。而這些階段應該要有階段產出。以test case而言,假設有10個新的user story需要建立test case,則今天完成了4個,表示還有60%尚未完成。


三:能力分配

如果團隊成員的確很專注於工作,而且也對時間/產出有正確的體認。最後的問題就是「能力問題」

團隊成員的能力組成其實非常複雜而且麻煩,牽涉範圍廣。以軟體專案而言,能力並非只是撰寫程式,測試程式,理解規格等等。能否和其他人合作,也是能力的一環。

一個規模中等的軟體開發團隊(4-7人),如果有一個人的能力「極端」的差,確實會造成專案很大的問題。

在Scrum的情況下,這樣的問題在前兩三個Sprint應該就可以被控制。因為雖然他的產出差很多,但未來的sprint的進度,是以團隊能力來考量,因此Scrum master仍然可以有效掌握專案產出和進度。

在不是Scrum的情況下,可以先找到該成員的相對優勢。排定一些學習項目,來提昇該成員在這個專案中的相對優勢,並且在未來安排相對優勢的工作。值得一提的是,根據經濟學的「比較利益法則」,每個人一定會有所謂相對優勢:請參考這裡,和這裡

關於軟體開發團隊的個別能力,還需要注意以下幾點:


1. 每個人都會成長,但是....


每個人都會成長學習新知識和能力。但是!在中短期專案裡,必須先考慮個別能力與優勢。

換言之,團隊領導要像下象棋一樣,找到每個人的「專長」,能妥善組合專案,就是個好的領導者。

而差強人意的領導者,則是常常試圖規避個別成員的「缺點」,這樣比較不會出大問題,但也容易產生差強人意的結果。而最糟糕的領導者,則會把人當做圍棋,看到人非黑即白,見到專案漏洞時,看到有空閒的人就直接填塞。這在某些有數百個人的硬體專案或許可行(因為數量在此可以產生品質),但在軟體開發專案鐵定行不通。


2. 能力是綜合考量...


能力必須綜合考量「全方面」:例如是否好溝通,是否能處理複雜的設計問題,能否開放心胸的就事論事等等。不能僅僅考慮寫程式的能力。

另外,如果覺得整個開發團隊能力都很差。作為一個能自我思考的領導者,應該先思考自己是不是「問題的來源」,甚至要思考自己是不是根本不適合作為團隊領導。


3. 讓不適任的成員離開...


讓不適任的成員離開,某些時候是個可行的解決方案。特別是某些企業管理派別認為,投入時間在不適任的人身上,他有可能變得適任,也有可能不會改變,然而投入時間太多,會造成專案延誤。

以Scrum的角度來說,這個情況不太會發生,因為2-3個sprint之後團隊速度已經確立,無論適不適任,專案產出速度不太會再改變。因此剩下的問題僅在於「換個人會不會更好」。而以中短期(3-6個月)的軟體專案而言,讓破壞性的不適任者離開,當然是解決方式,但不見得要「找另一個人進來」。






相關文章:人才管理心智圖為自己工作...



7/28/2016

心智圖 - 進入職場第一個必備技能



在畢業之後,投入職場的那一瞬間,假如你突然失去記憶,喪失所有技術能力,你最希望先恢復什麼能力呢?

相信一定是「學習各種技能的能力」「連結不同技能的能力」「延伸整合技能的能力」這類型的選項。概念上類似神燈可以實現一個心願,稍微有智慧的人,第一個願望,一定是希望有無限多的心願。

「心智圖」mindmap是最簡單,最容易學習的能力,可以用來連結學習延伸其他的技能的基礎。它應該是踏入職場第一個必備的技能。

心智圖極端簡單(請參見心智圖wiki),不過就是把心中想的主題畫在一張紙的中間,把跟這個主題相關的重要「事情」「項目」「動作」...等等,用線連在一起,而後還可以再延伸這些「事情」「項目」「動作」到其他細節,或者其他主題。

雖然心智圖很簡單,有不少人宣稱在高中就已經會用,但實際上熟練地使用者卻很少。

下面這張圖就是在撰寫這篇blog的後所畫的第一張心智圖:

這篇文章所用的第一個心智圖

心智圖的繪製,沒有任何特殊技巧可言,它只是想法的延伸。換言之,心智圖本身無法代替思考。但他可以讓抽象思考具體化,讓你更容易有全面的視野來觀察任何主題。這和哈利波特裡面的儲思盆有異曲同工之妙。只是你不需要去念霍格華茲,也可以學會使用心智圖。

經常利用心智圖,對職涯發展有莫大助益。然而,在台灣職場上,卻並不常看到有人使用心智圖,更常遇到某些特殊事情發生之後,才想到「當時如果用心智圖做紀錄會不會好一點」的情況。

其中一個主要因素是:缺乏練習,以至於當下沒「聯想」到有此工具。


有三個工作項目,是最好練習心智圖的機會:


1.  即時會議記錄:


即便有超強的打字能力,有意義,並能快速呈現重點的會議記錄,遠比把所有人講的的話一字不漏的記下來來得重要。臨時的會議,有結論的會議更是如此。

一邊開會,一邊將主題相關的人事物,用心智圖快速連結起來,可以在開會的過程中,掌握要點,避免會議「歪掉」,減少會議常見的三大毒瘤:「會而不議,議而不決,決而不做」


會議還沒開始,先畫出主題以及會議之後的行動
做法很簡單。首先:如果你是主持會議的人,會議還沒開始前,先在白板中間畫個圓圈,中間寫會議的目的。接下來先把「Actions」先畫出來。在會議一開始,就確保會議結束前,一定會討論出作法。如果你不是會議主持人,可以畫在筆記本上,這樣確保會議結束前,萬一Actions的圖形之下,沒有任何行動,也沒有人提及要有會後行動,你也會「主動提出」。

接下來,在與會人士慢慢來到之前,先把會議的背景,要討論的事情大綱,畫在主題的周遭,並稍加分類。以簡單的圖像表示與會人士。


會議即將開始前,先將背景以及可能討問的事項在白板列出來。以簡單的圖像代表與會者的討論。

隨著會議的進行,白板會越趨複雜,當然可以簡單的照相紀錄過。

會議的目的,當然是為了「議」- 也就是為了討論。而討論最佳的方式,莫過於把彼此的思維,投射到可以視覺化的地方。心智圖是最簡單,成本最低的好方式。





2.  分析與設計:


有複雜問題的時,可用以分析。例如:專案資源不足,遇到瓶頸,解釋複雜的人際關係等等。

有需要進行的事情時,可用以分析。撰寫技術類型的文章,就很適合先使用心智圖。

以這篇文章為例,在撰寫之前先以心智圖繪製草稿大綱,然後經過一些考量修正,先修改心智圖大綱到自己滿意的程度,在開始撰寫內文。
這篇文章的最終心智圖草稿,和第一張圖有些不同

各類流程,事物的互動,也是很適合使用心智圖分析。以旅遊為例,如果你沒有精美的行程設計,使用簡單的線上心智圖工具來繪製旅遊計畫,是方便又好用的方式。
以線上工具繪製的東京旅遊計畫




3.  任何超過3分鐘的技術問題討論:


程式設計師,專業白領階級員工常常會有「技術討論」。而技術討論光用嘴巴講效果很差。一圖勝千言,簡單的流程圖,循序圖,物件圖,永遠勝過長篇大論。

UML需要比較長的學習與練習,而心智圖卻很簡單。特別是用於觀念討論,大方向的設計(註1),



app使用者登入討論大綱
以mobile APP為例,在討論技術上,也許有程式設計師,在討論之前,先花上幾天搞個極為細緻的流程圖(例如這個),但很多時候只需要只需要三分鐘,在白板畫個圖就搞定。以右圖而言,顯示這個APP在使用這登入的討論大綱


簡單的東西,通常可以運作得更優雅良久。心智圖並非萬能,它僅只是簡單。掌握心智圖的簡潔,快速,利用它來簡化,分析,記錄事務絕對可以讓職涯事倍功半。





註1: 資訊科技比較完整的分析圖形工具還是以UML比較適合