顯示具有 充實自己的方法 標籤的文章。 顯示所有文章
顯示具有 充實自己的方法 標籤的文章。 顯示所有文章

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: 以資訊科技來說,最基本的本職學能是寫程式,其他可以參考這裡這裡


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,但是這裡只是舉例而已。


12/22/2016

企業巫醫 - 年底才績效評估或考慮轉職?已經太遲。



年末,巫醫們會試圖對迷惘的人們,提供某些指引。

因此,在各部落,社群網站總是有各式的「轉職衡量」,「績效評估」,「個人職涯規劃」,「獵人頭的建議」...等等相關文章。(註1) 

不過,就實際情況來說,假如你到「年末」才考慮這些重要事情,那麼已然太遲。


為什麼?


績效評估要及時


大部分的企業在年尾都有績效評估。但以個人職涯而言,這些事情,應該是每隔一小段時間 (例如一個月) 就應該自我有所評估,並調整未來的做法。

就好像今年初打算減肥20公斤,並降低體脂肪到20%以下,而直到年底才量體重體脂肪,基本上已經太晚。即便最後仍然達到目的,也可能只是運氣好。

無論層級高低,無關老闆是誰,無論組織狀態,每隔一段時間,個人應該就事實以及個人產出部分自我評估一下績效。更重要的是,了解別人(特別是主管)對自己的「真正評估」。

自我評估,必須要根據「事實」,與其他人的「衡量」。不應該根據自己的想像,以及感受。

舉例來說,如果你是個軟體程式設計師,每個月你都如期產出符合品質的程式碼,並且bug數量也很少,那麼確實是個好工程師。

反之,如果相較於其他軟體程式設計師,你的程式碼產出低於其他人,bug數量也多,即便你有參加福委會,搞了很好的尾牙活動,你的績效評估恐怕依然很糟。

但由於,許多績效評估是根據「相對績效」來判定。而由於人類有天生的偏誤,自我評估一定會趨向「好的結果」。

因此每一小段時間,你一定要試圖取得主管或其他相關人的「真正看法」。越嚴格的越好。如果在2016年2月,你知道主管對你的績效是不滿意的,那麼你還有很長的時間可以改變(註2)。但如果你是在2016年底年終考核,才赫然發現主管與你對績效的「看法」不同!那幾乎沒有翻盤的可能。

另一個重點在於:績效評估是為了自己的職業生涯,不是為了組織,也不是為了讓主管決定薪資。

如果你覺得,如果要做每月的績效評估,公司/主管應該要主動進行才對?那表示你根本不是個能獨力處理事情的人,同時也表示你的主動性太差,也很難自己成長。



轉職衡量要完整


年底並不一定是換工作的最好時機。只因許多人因為領到年終,所以剛好離開「忍受很久」的工作,所以一時間就似乎有很多職缺出現。然而,某個人忍很久的工作,通常表示下一個人也不一定好受。

換工作的考慮有很多,無論哪一種考慮,都需要基於事實(請參考這裡)。簡單的說,在這份工作遇到的困難沒有解決,下一份工作一樣會遇到。

完整的換工作衡量需要對自己在「事實」上的長期認知。包括過去一段時間有去哪些地方面試?並且被錄取?自己倘若離開這個組織,對組織有沒有影響?自己如果沒收入,可以支撐幾個月?

更重要的考慮是:自己真的想要的是什麼。



那麼,年末可以做什麼?


當然還是得進行轉職衡量,績效評估,個人職涯規劃,參考獵人頭的建議...等等。可是更應該進行的是「檢討自己」與「改變自己的實際做法」。



1. 不設定一年為單位


以個人生涯規劃而言。應該將「一年的結尾」。從新定義為「一個月」或者「一季」的結尾。

並自現在開始,設定自我評估的時間單位,例如一個月。

每個月直接詢問主管或者工作上最相關的人:「有哪些地方需要改進」「哪裡做的事情有問題」「這個月哪邊沒有超乎期待的表現」...。

對於調整職業生涯也是以比較小的單位取得回饋。

當然,這並不代表不能有年度目標,或者五年以上的願景。只是,檢視願景和目標的單位必須要有及時回饋的可能(註3)。而單指個人而言,每個人的記憶有限,根本不可能有效回顧12個月前發生的事情。因此採用Scrum的精神,以大約一個月為單位應該是最適合。



2. 不重複過去無效的做法


恆毅力是一本在誠品門口有超過5公尺橫幅廣告的書。作者以她數年的研究顯示恆毅力是成功的重要因素。

毅力耐心確實是朝著目標前進時不可或缺。不過,實際作法的調整也很重要。以創業為例,pivot幾乎是必要。

每過一段時間,應該就事實來檢討,目前做法是否達到效果。如果沒有,就應該衡量原因,考慮改變執行的方式。不見得一定要改變,但一定需要檢討。

改變當然有可能帶來風險,甚至會比沒改變的時候更糟糕。然而,不改變就沒有前進的可能!



3. 不等候重要的事情


誠如第一段所述,年末考核等到年末就太遲。其他和職涯有關重要事情也是,不應該年末才進行。

因此,今年年末可以設定未來「重要的事情」頂多等到下個檢討點 - 例如一個月後。

每個人所意識到的重要事情都不同,有很多時候心裡覺得一件事情重要,和實際上真的很重要是截然不同的事情。一個人的真正行為,才是斷定他認定重要不重要的指標。





參考:

努力的三個迷思

工作上學不到東西

因沒挑戰想要換跑道

工作太忙沒時間?

職業生涯的突破

成長的最好方式:檢討


註1: ....對... 這篇也不例外

註2: 所謂調整,一樣要考慮手邊有的選項:可以針對不好的地方改善,也可以試圖換個工作項目。甚且也可以換工作。

註3: 有些人可能會用「爬樓梯可以一步一步,但是要跳過鴻溝不能分步驟吧?」來辯解過短的時間區間會有其他問題。不過,這真的是問題嗎?跳過鴻溝的確是一次跳過,但起碼助跑的時間和助跑距離的測量,也是必要的前一步啊!



11/14/2016

因為沒挑戰想換跑道:先檢討自己吧!




新的一年,總是容易遇到討論換工作的事情。目前,台灣資訊科技領域整體仍然缺乏人才,因此要換新的工作是非常容易的事情。

真正的問題在於:什麼原因想要換工作?如何換?新工作或事業會不會比較好?自己到底想要什麼?

這些問題根深蒂固地存在每個人的身上。不會有一體通用的方式為所有人解答。

不過,如果單純只是因為現在的工作沒挑戰性,無趣而想要換跑道,還請以下三點簡單的自我審思一下。



檢討一:「沒有挑戰很無趣」的真正源頭


牌桌上的至理名言:「30分鐘後如果你還沒發現誰是冤大頭,那麼你就是冤大頭」。在企業中,如果你沒發現有任何值得挑戰的地方,那或許你自己就是沒有挑戰的真正原因。

當你的工作變得沒有挑戰,而且無趣的時候,請先確定問題的真正源頭。

是不是因為你的能力或者表現,讓你無法得到有挑戰有趣的任務?還是你的視野讓你看不出挑戰性?

還是這工作或事業的本身,真的沒挑戰性?你已經是有如NBA過去的Jordan或者現在的Curry已經快觸到這個事業和工作的極限?還是你抵達的是自我的極限?



檢討二:選項



選項,永遠是考慮決策的要件。

換工作或事業是一個好選項。但是,在既有的領域中,擴展自己的視野和能力也是一個選項。

換工作是個選項。在大企業中,換部門也是一個選項。換工作這選項中,嘗試新的技術領域是個選項,但是嘗試截然不同的工作類型(例如業務相關部門)更是更大的不同選項。

在現有工作內容中,改變自己的做法以求突破,也是一個解決的選項。

選項可能很簡單,也可能很複雜,而且還會參雜很多人的因素。去除自我偏誤,取得個人最想要的結果,比想像中的簡單。不過,要預設自己以及相關人等有完全的邏輯推理是很難的。(參考:沈思



檢討三:「沒有挑戰很無趣」有時候是真正的挑戰


在資訊科技的領域裡,多的是把原本看起來無聊的東西,重新找到價值並且延伸的例子。

如果你可以將無聊沒挑戰性的事情,轉成有價值,並且有挑戰的事情,等於是你證實自己絕佳的創意以及實踐創意的能力。

這樣的例子在不管在哪個領域很多,從很久很久以前的gmail,到近幾年的類似snapchat的app,許多都是一開始是沒很有趣,但是找到額外的創意之後,將舊有的東西突破。

隨著組織越來越大,表面上無趣的事情會越來越多,光是默默的忍耐並不會讓事情變得更好,只有把無趣轉換成價值,才能展現自己的創意能力。要怎麼做?可以參考這篇



參考文章:換工作的面試-軟體工程師如何展現價值




沈思
一個海盜集團中的5個海盜找到了100顆金幣,每一枚都一樣的大小和價值。 

由於海賊王想要這五個部下傷透腦筋,自相殘殺,規定他們分配金幣的方式如下: 

1。抽簽決定自己的號碼(1,2,3,4,5) 
2。首先,由1號提出分配方案,然後大家5人進行表決,當且僅當超過半數的人同意時,按照他的提案進行分配,否則將被扔入大海餵鯊魚。 
3。如果1號死後,再由2號提出分配方案,然後大家4人進行表決,當且僅當超過半數的人同意時,按照他的提案進行分配,否則將被扔入大海餵鯊魚。
 4。以此類推

 如果你是號碼1的海賊,應該怎麼分配金幣?

9/25/2016

企業巫醫 - 時間乃最終之敵人? (上)



在每年不可計數的企業管理勵志書籍中,有越來越多把「時間」視為判斷事務的重要標準。想當然,個人「時間管理」變成一種必要的技能。然而,更近一步是在越短的時間,達到越驚人的效果,從早期的「24小時學會某東西」系列,到「7分鐘運動燃脂72小時」,都是試圖在短的時間內達到CP(註1)值最好的結果。


時間似乎是最終的敵人?


也許,在某些時候,「搶先一步」是競爭的最佳方式。不是大的打敗小的,而是快的打敗慢的(註2):就變成企業主事者認定的最好成功方式。畢竟,如果可以用很少的投資(小),只要用比較少的時間(快),好像就可以打敗大但是慢的競爭對手?聽起來永遠不吃虧阿!再者,兵法有云:故兵聞拙速,未賭巧之久也。似乎,只要速度夠快,總比慢來的好?

更近一步的說,許多人逐漸視時間為最終測量維度。例如Compete Against Time,就將時間視為在商業上,衡量事務的最重要方式(註3)。甚至有人認為應該是唯一的度量方式

就經濟學始祖亞當斯密1776年的說法,企業組織價值的來源主要由三種事情組成:資本,土地,勞力。土地:泛指一切自然資源,勞力:泛指人類的智慧和努力。任何商品的價值,都是由這三者的其中一種,兩種,或者三種組合起來。

時間快轉到2016,隨著全球化經濟發展,資本以及自然資源,對於企業的影響已經遠遠不如「勞力」,更確切的說,是人的努力強化資本和自然資源的運用。即便現在存在著比1776工業革命初期更自動化的設備,更能節省人付出肌肉的努力,但面對更趨複雜的環境,人類的「智慧腦力」似乎需要付出的更多,某些人需要付出更多的腦力,讓其他人少動點腦?而最終,變成某些人在相較短的時間,付出較多的腦力,產生較好的結果,可以大幅讓商品的價值領先市場的其他人。


總之,各種訊息「似乎」都顯示,即便時間不是最終的敵人,也是先要處理的「衡量指標」


以廣大勞工而言,衡量生存的指標,就從古時候的「每天能耕多少田」,轉為「每天能在工廠做多久」,而再變成「每天在電腦前面完成多少工作」。只要能在越短的時間完成越高品質的工作,就會越有機會加薪升遷。


然而,事實上只有極端少數的人,能夠妥善駕馭自己的時間,也因此,「時間」變成企業巫醫用來恐嚇部落子民的惡靈之一。


巫醫有三種方式來處理「時間惡靈」

一:加速 - 跑的比它快


各種企業巫醫的,也在強化此信念,教導讀者「加速」用來增加巫醫的崇拜。

例如,最有生產力的一年超強時間術早上三小時完成一天的工作時間整理術... 請隨意搜尋類似標題,一定可以找到超過100種以上的方式,書籍,甚至mobile app。

這些加速的書籍,有些的確是有用的個人經驗,就像南美巫醫累積了數世代的經驗,分辨有效的草藥一樣的有些用途。然而,通常僅能適用於巫醫自己。關於「加速時間」,就像投籃命中率一樣,可以學習,可以練習,但是因為環境的因素,每個人終究有其極限。

事實上,「加速」全然是靠自己的經驗和能力,就像大部分的感冒是靠自己的抵抗力痊癒一樣。採用巫醫的建議手法,確實有幫助,只要自己意識到這樣樣的手法是在幫助自己的經驗與能力即可。過度崇拜「方式與手法」,會容易走火入魔。(參考:2013年的9個todo app)。




二:有效利用 - 80/20法則的極端利用


光是加速,能取得的效果總是有限。頂多取得20%-30%的進步就很了不起。唯有改變方式,甚至改變目的,才有可能取得3倍或者10倍的改變。

從「加速」改為「有效利用」,就成為在2008金融危機之後的顯學。

例如:為什麼菁英都是清單控Scrum一半的時間做兩倍的事少但是更好其實工作不必這麼累 ... 一樣有成千上百的書都屬於此累。

這類型的「找重要的事情做就好」的書,其實真只有這個重點,那就是掌握80/20法則,先做重要的事情,你的職業生涯就是彩色的。

但是,企業巫醫沒辦法告訴你,在你身上哪個20%是最重要要做的事情。誠實的巫醫永遠只能說「施主,這要問你自己阿」。而拐彎抹角的巫醫會用「斷捨離」,「時間矩陣四象限」,「人生優先清單」等等技術性的手法,告訴你,你還是得自己找到那重要的20%。


三:心靈層面 - 永遠都有的一招


幾乎所有的企業巫醫都會的一招:將所有的事情,推移給心靈與精神層面。

例如:心靈慢活療癒慢活從容的力量慢一點成功又何妨被討厭的勇氣...

就心靈層面觀點而言,這些巫醫也許可以帶來平靜,而平靜讓人的思慮或許可以更周延,並降低更多的壓力。但是,這些巫醫雖然好意的想要讓世界變得更美好,但是絕大部分的人類是社會性動物,試圖全然擺脫外在的影響,等於是要人類放棄天性。當企業組織內變得越來越快速,光是一個人在裡面「慢活」是難上加難。




那結論呢?


請參考下篇:企業巫醫 - 時間乃最終之敵人? (下) 。




註1:CP值,或者性價比,請參考這裡

註2:這句話很多人都講過,包含郭台銘和柯文哲。不過,這個名言最早應該媒體大亨:梅鐸所說。另外,這句話在2002年也是某本書的名字。

註3:將時間視為第四個空間維度來描述,請參考狹義相對論

註4:增加工作效率?聽起來和前述的巫醫有什麼不同?就想要達到的效果來說,有良心的巫醫和一般的醫生並沒有不同。最大的不同在於方法是不是合理,經過有效驗證,而且可以在未來檢討改善。



7/18/2016

解決軟體專案困境的最爛方式 - 加班





「加班」是解決軟體開發專案困難的常見方式,但也是最爛的方式。(好方法?請參考:解決專案困境的三個方式)

負責控管專案進度的主管或專案經理,如果只會用「加班」這招來解決問題,那就不適合做軟體專案經理。

長期,非自願的(註1)加班沒辦法真正解決問題的各種經驗實證,早在許多談論軟體專案的書籍中存在。例如:人月神話Peopleware約耳談軟體與熊共舞等等。從來沒有看過有任何「專案管理理論或實務認為加班有用」。

最根本的原因在於:知識工作者(軟體工程師),其產出和付出的「超額」時間根本沒有關係,也因此,加班從來都不會解決真正的問題。

既然如此,為什麼加班文化仍然存在?

常見原因有:

1.  短期效應


特定目的的短期加班:例如參加週末創業活動,或者,產品銷售大會之前的熬夜修正demo問題等等。這些特定的目的,固定時間的活動,確實會讓人拼了命「加班」完成目的。但是,短期效應絕對不能當作一般專案管理的方式,大部份的專案都不是百米賽跑!


2.  專案經理本職學能不足,利用要求加班來展示苦勞。


專案經理沒有其他辦法,只會加總人時。因此,即便人月神話從初版印刷上市(1975)到今天已經超過40年!仍然有不少軟體專案經理即便看過人月神話這本書,仍然不可自免得繼續要求加班。因為,如果有加班,即便專案失敗,以往也被認為「沒有功勞也有苦勞」。

但是,以現在環境變化迅速,一個軟體企業中,如果「一直都只有苦勞」,被淘汰的速度遠比過去還要快得多。



3.  模糊的合約。


在某些糟糕的情況下,銷售可能會簽下模糊的合約,當專案經理看到合約內容時,其解讀方式和客戶「截然不同」。在各種專案經理訓練課程,以及各類商管叢書裡,都會說「要良好溝通」,但實務上,當專案經理手上已經拿到不合理,而且驗收條件極為模糊的合約時,幾乎不可能以「溝通」來解決。如果專案經理,誤接燙手山竽,而又沒有足夠的創新能力和技術能力來解決時,通常會誤以為軟硬兼施的「加班」,或許可解決這個問題。

但是,如果這次不能非加班的方式解決,下次就不可能有更好的方式。其後就落入惡性循環。可以google一下「台灣  接案公司」看看目前的現實情況。


4. 心靈激勵。

無論是「要有創業家的精神!」,或者是「我們在做全世界最偉大的軟體」,甚至是「世界的和平,人類的未來就靠我們了」。而又有太多人誤以為,只要有正確的心靈激勵,軟體工程師就可以像電影劇情,日夜匪懈的工作,還能有創造性的思考解決問題。


5. ...很多其他的理由。


如果你是專案管理人員,之前要求成員加班的理由到底是什麼?如果你是軟體開發人員?曾經被哪些理由要求加班? 




既然如此,到底什麼是解決軟體專案困難的好方式?
除了可以參考這裡之外,還有三個原則:


1. 永遠都有選擇 - 「Say No」也是一個選項!


認為不正確的事情就應該說「不」。在正確的時間點不說,只會拖延,就不是個好的專案領導者。


以組織層面的角度:

就專案經理本職學能而言,一旦發現自己不是個好的專案領導者,應該要對自己說不,迅速辭職,改當一個好的程式設計師,或許是對專案最好的幫助。

就專案目標而言,倘若使用這的需求不確定,就應該選擇不做,或者選擇先做mockup,讓使用者確定需求,才不會浪費時間。

資源 - 特別是人力而言 - 在企業組織中,永遠都是有限。而良好的管理是透徹於在有限的資源中做有效的分配。加班不會讓分配變得有效,只會讓無效的分配繼續無效。

以技術層面的角度:

技術永遠有選項。一個複雜的功能,可能有起碼5種不同的實作方式,到底是選擇複雜但是有趣,還是選擇簡單,但是堅固耐用?就要視情況而定。

無論什麼事情,一定有選擇,絕對不會有「我們只能加班」這個選項。



2. 專案擁有人,必須參與專案!


近年來流行的Scrum,有一個必要的要點:專案擁有者(product owner)在每一個sprint之後要檢視產出。這個要點非常的重要,遠比正確做好燃盡圖,每天站著開會來得重要100倍。

專案擁有人,需要參與專案的每一階段進展,確實了解專案的人把時間用在哪裡,並且確實了解,每一個sprint產出都是專案擁有人最想要的產出。如此才能確保「做出對的事情」。

如何讓專案擁有者參與專案,就變成專案管理者「一定要做」的事情。

會把PMP的教材背的滾瓜爛熟 -- 溝通管理計畫書是要建立蒐集擷取散布各處的資訊,以及最終處置專案資訊的流程 -- 但實際讓連每一小階段讓專案擁有者「確定產出是他要的」都無法實際做到,簡直沒有任何意義。

在每個階段發個制式的email,裡面塞了很多複雜的圖表資訊,只會讓專案管理者「誤以為」一切都很順利。把確認每階段產出是他要的這件事情越往後延,風險就越大!


3. 磨利斧頭!


技術上的學習,會讓事情事半功倍。太陽底下沒有新鮮事,你所遇到的困難,可能已經有另外17個人遇過同樣的困難,而其中也許有9個人已經解決,解決的人之中有5個把相關資訊放在網路上。只要有正確的英文閱讀和google查詢能力,並能固定的自我學習,充實自己(參考如何充實自己),通常都能以更好更快更有效率的方式,解決軟體上的問題。

但是,千萬不要把「沒有時間學習」當作理由。當你的斧頭已經鈍到無法砍樹,還試圖用鈍斧頭砍樹來表現自己的努力,這是完全沒有意義。學習的目的就是磨利自己,將知識與技能銳化,才不會以無意義的舉動,做無意義的事情,加無意義的班。






註1: 凡事皆有例外,遇到天災人禍等不可抗力情況而加班其實算合理,不過即便如此,也應是極短的時間。例如,颱風天放假,隔天需要額外的工作時間。自願性質也絕對不會是長期,例如自己去參加創業週末,某種程度是自己為了自己額外工作,但頂多是一個週末,也不可能連續10個週末都在進行這樣的活動。

相關文章:
-->  換工作的面試-軟體工程師如何展現價值
-->  靠感覺做專案管理 - 鐵定失敗
-->  如何提高工作效率:三個務實的快速步驟
-->  心智圖:職場的第一個技能
-->  你確定知道專案進度嗎?
-->  80/20法則之軟體專案的三個運用重點


7/12/2016

如何充實自己:大量閱讀的三步驟




閱讀是充實自己的最簡單,便宜,有效的方式。

閱讀不需要花錢去買書,以新北市的居民為例,只要就近找一個新北市圖書館的分館登記成為讀者,就可以線上借書。如果在該分館沒有,還可以運送其他分館或者總館的書到你最近的分館領取。方便到幾乎沒有藉口不閱讀。

閱讀是許多人的休閒活動,在躺椅上一邊讀喜歡的書,一邊吹著微風,是悠閒人生的象徵。小說文學,遊記漫畫,在這個情景下是再好不過的書。

但如果為了充實自己,那麼大量閱讀是有很大的幫助。

所謂大量閱讀和傳說中的超強速讀並不一樣

傳說中超強速讀,則是存在某個不太認識的人身上的特殊技能,總是會人試圖花錢去學習這個從來學不會的特異功能。

大量閱讀是在同一個主題下,透過不同作者的觀點來建立自己在這個主題下的知識。大量閱讀是閱讀超過7本以上同類主題的書,並且透過前人的知識,建立對這個主題的全面性概觀。


步驟一:選定主題,取得大量書籍



為了充實自己的大量閱讀,需要有個主題。例如:「創業」。也可以將主題縮小或者放大。例如:「精實創業」就是縮小範圍,而「企業管理」就是放大範圍。

有了主題自然就要去取得書籍。除非很有錢,否則大量書籍會先從圖書館借。現在圖書館幾乎都有線上查詢的網站。在線上查詢網站,查詢該主題。


以「精實創業」為例,在新北市圖書館網站,竟然只查詢到兩本。基本上除非主題過於偏僻,這種情況太不可能,當改為「lean startup」查詢之後,就找到了52本,雖然裡面有幾本不太相關,不過數量也已夠多。稍微瀏覽一下書名和簡介,就直接利用線上借書功能,盡可能借到不能借為止!通常是10本左右。



切記!!先別在網路上搜尋這個主題!!


由於撰寫網路內容的成本非常非常低,確實有可能搜尋到片段知識,但對於充實自己的角度來說,弊大於利。除非已經對這個主題有一定熟悉程度,只是需要找到特定問題的答案,否則在這個階段完全不適合利用網路!



步驟二:閱讀


等拿到那幾本書,就要開始閱讀。

大量閱讀的「閱讀」要從目錄開始。假設相關主題的書共有10本,先將這10本書的目錄,大致瀏覽一遍。根據自己的感覺,先列出哪些「章節條目」是重要的,那些可能是不重要的。對於某些「條目」 如果有很明顯的「正反面意見」就要特別留意,這個條目可能很重要。

目錄瀏覽過,就表示應該產生基本的心智圖筆記(參見步驟三)。現在請排序找到前三本要讀的書,將三本書依序讀過。

接下來,在記憶中,將這三本書的重要關鍵項目,轉折點,列在心智圖筆記中。這時候心智圖可能會一改再改。鉛筆會是最好的選擇。

當心智圖筆記大致完成,檢視自己的知識,看看對哪些條目有更深入的興趣,將剩下的7本書,以「條目」的方式閱讀。剩下的書,不需要每本的從頭看到尾,但是,可以針對有興趣的項目,或者重要的項目,特別橫向閱覽所有關於這個條目的章節。當然在過程中,如果發現這7本書裡面,有寫得非常好的,當然也可以從頭看到尾。



步驟三:心智圖筆記

專案管理的心智圖筆記


雖然說是步驟三,但是其實在閱讀的當下,就應該先做筆記。而心智圖,是最好做筆記的方式。

在閱讀的開頭,可以先把「主題」畫在中央,然後把書本的「章節條目」根據自己的興趣以及自己的分類方式,「記錄」其關聯性。這樣的紀錄,並不一定以章節名稱。以右圖為例,這個圖示紀錄「專案管理」這個主題的心智圖,其中右邊第一項「Practical way」指的「實務做法」,因此從專案計畫,執行,產出,結束,都被分到這一類。

注意!心智圖筆記的關聯與分類,乃是根據讀者(也就是你)的想法和關聯而來,他並沒有所謂對錯,他是讓你的心緒能夠抽離。除非你有鄧不利多的儲思盆,否則,這是目前已知最簡單最快速能讓你的思維視覺化的方式。






參考:如何充實自己:三個務實的快速方法



7/06/2016

如何提高工作效率:三個務實的快速步驟





Give me six hours to chop down a tree and I will spend the first four sharpening the axe. 

 - Abraham Lincoln

白領工作者,或者,知識工作者的工作,追根究底是利用智慧知識和經驗,做出一些行為。例如:行銷經理,就是擴大產品的市佔率;軟體工程師,就是產出程式碼;業務員,就是賣出產品; 言情小說作家,就是寫書;專業經理人,就是領導管理團隊完成任務。

只要是知識工作者,不管用什麼方式衡量工作效率,理論上都可以持續提高。

就概念上來說,工作效率來自於三大方向,(a)技術與知識,(b)環境,(d)心理層面。

技術與知識。需要靠學習與經驗累積,而正確的學習和正確的經驗累積更為重要。請參考這三篇相關文章:自我學習的方向片段知識的危害工作中學不到東西

環境。如果週遭都是工作效率極高的人,自然而然就會主動提高效率,然而環境有點運氣成分,大部份的人很難控制周遭環境。

心理層面。從馬斯洛需求階層論,到赫茲伯格的雙因素理論,心理與管理學界不乏各種相關的研究以及結論。但知識工作者,可以先參考Ted的這篇


工作效率,絕對會和「超過」的工作時間呈反比。長期的加班對絕大部份的知識工作者而言只會降低效率,拖延成果,殘害自己與家庭。尤其是對剛進入職場的新鮮人,提升工作效率是最最最最重要的事情。工作效率的提升,會伴隨知識技能的成長,更多的時間運用,以及對組織產生真正的價值。高效率地利用時間,可以產生對職業生涯的正面循環;低效率的長期加班,則會產生很難逆轉的惡性循環。


只要願意嘗試,每個人都可以利用以下三個務實的步驟,持續並快速提升績效。做法很簡單,只需要筆記本和筆:

(1). 15分鐘每日計畫


每天開始工作前,先不要開電腦收email,而是拿出筆記本和筆,把今天最重要的幾件事情寫出來,分類事項,決定今天要先做什麼,要完成什麼,參考這篇的分析。切記先完成重要且緊急,以及重要不緊急的事情。

每日計畫只是簡要列出「打算完成」的項目,並且花一點點時間,沈思哪些真的可以完成,哪些是在80/20法則中最重要的完成項目。 也可以加上一些「保留」時間,用以處理意外。

(2). 15分鐘檢討改進


每天結束工作「後」。拿出筆記本,看看今天開始計畫的事情,哪些完成,哪些沒完成,哪些真的重要,哪些其實後來發現不重要。自己檢討一下自己的判斷為何不正確,為什麼該完成的事情沒完成,並且,簡要記錄一下,完成的項目大概花了多少時間,未完成的事項是因為什麼原因。


(3). 15分鐘重點學習


改進檢討結束後,找一小段時間,再把筆記本拿出來,看一下那些比預期晚完成的事項,哪些是因為自己的知識技能不足,導致太晚完成。列出這些項目。特別是找到「厲害的人一下子就可以做到」的事項。舉例而言,excel的PivotTable是資料分析的最基礎的方式,也是做big-data模型時,小規模測試的最好參考,會妥善利用PivotTable的資料專家,會比不會用的人更節省時間的驗證自己的模型。

在筆記本列出需要學習的項目,每天花15分鐘,在網路上學習這個技術或知識。每天只要專注於「一個能提升效率的事情」就綽綽有餘了。




知識工作者最悲慘的情況,莫過於努力了好幾天去做一件完全不需要做的事情,或者完美的執行一個完全不對的方式。

如果還沒有找到最適合自己的方法,請按照這三個務實的方式,每天花不到45分鐘,在2-3週之後一定會有顯著的效果。




這篇文章的乃是根據以下書籍參考,匯整,並且實際執行之後的結果。
- Getting Things Done  
- The Productivity Project 
- The 4 hour work week
- Lean startup
- Do Over

5/26/2016

問對問題,如履平地。問錯問題,萬劫不復!




在不到十歲的年紀,有一次流感重症去看醫生。那時候還沒有健保,醫生通常還是會跟家長講一下治療方式可能的價格。當然,如果打一針可以好的比較快的話,多花個幾百塊可能也是值得的。但是!小時候的我很害怕打針。也許恐懼的神情被醫生發現了,他就好意地問『有比較大筒的針跟比較小筒的針,看你要打哪一種?』小時候的我,毫不猶豫的當然回答『小的針。』。結果,最後護士是拿出「兩隻」小的針筒,左右兩邊各打一針。

這個慘痛的經驗,後來讓我學習到,要完整考慮「問題」,至少要從三個方向思考:


1.問題可能不能代表真正的問題


無論是一般工作進行,還是特定專案,通常都有各式各樣的「問題」產生。有些可能是單純的疑問,例如「這個功能什麼時候可以完成?」。有些看起來比較複雜,例如「帳號如果被管理者停用,則正在登入使用中的session是否要立刻中斷?」

單純的問題,可能要考慮的更多。以「這個功能什麼時候可以完成?」為例。可以循用5 Whys 五個為什麼,來了解看似單純問題的真正本質,

例如:

「這功能完成的時間已經在系統有紀錄,為什麼要額外詢問?」--- 原詢問者回答:「只是想要知道有沒有意外」

「為什麼會想要知道有沒有意外?」 --- 原詢問者回答:「之前某高層詢問專案進度,我覺得這個功能因為比較複雜,不知道會不會有風險」

「為什麼高層會詢問專案進度?」 --- 原詢問者回答:「因為高層覺得專案預計完成時間太晚,想要用一些方式提早」

「為什麼會覺得預計完成時間太晚?想要哪種方式提早?」---原詢問者回答:「我也不知道,不要再問了!!」



2. 真正的問題很難找到


事實與真相就像船頭和船尾,首先會看到船頭,然後根據整個情況有多大多複雜,才會在最後看到船尾。

要找到真正的答案,必須要先找到真正的問題。

在許多軟體專案中,經常會有專案管理者以「人力不足」作為問題並試圖解決。但是,這個問題在絕大部份的軟體專案中,根本不真正的問題。

真正的問題也許是:

(a) 許多專案成員另有其他任務,導致投入專案的時間太少

(b) 專案需求不明朗,時常增刪變更,導致時間浪費

(c) 「人才」不足,而非「人力」不足,像是:
       (C-1) 專案管理者沒有看透技術關鍵的能力
       (C-2) 專案成員訓練不夠
       (C-3) ...其他...

而每一個問題, 背後又隱藏其他的問題。絕大部份的專案中,問題看似很多,但最重要的可能只有幾個。

專案經理的重要任務在於:決定真正重要的問題(忽略不重要的問題),並且優先解決最重要的問題。


3. 真正的問題才能找到真正的答案


要找到真正的答案,必須要先找到真正的問題。

一旦找到真正的問題,等於已經產生一半的答案。不過,另一半的答案可能也不見得很簡單。

假設認為真正的問題是「專案需求不明朗,時常增刪變更」,答案的選擇可能有:

(a) 採取Scrum開發模式,確保每個Sprint的需求不會再改變,讓真正的專案擁有者能參與每階段的決定

(b) 暫停所有開發活動,在沒有完成細部設計與需求規格書之前,先不開始開發

(c) 再花時間去找到為什麼專案需求不明朗的背後原因,






最終,每一個成員,需要為自己找到最適切的真正答案。
隨波逐流,最終只能忍受左右兩邊各一針的結果。





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年沒有什麼不同。如果你是這樣的專案經理,為了團隊好,或許應該考慮轉換適合的工作跑道。












3/25/2016

資深與中高階人才選用:三個要點





在資訊科技領域裡,資深或中高階人才選用遠比找到剛畢業很有潛力的人來的困難重重。

詭異的是,幾乎所有已經在資訊科技領域工作7年以上的資深專家,通常多少都會遇到獵人頭(hunter)的引誘。事實上,中高階的職缺其實很少,由組織內部升遷的機會很大。然而,如果真的從組織外部尋找,雖然看似符合條件者眾多,但能有效媒合卻是難上加難。




要點一:情境實例面談


絕大部份的中高階人才之所以是「人才」,乃是根據其真實的過去事蹟。而非未來想像。

在書面篩選階段,通常是根據過去工作經歷,決定要不要請來進一步面談。

而在面試階段,卻常落在討論未來的理想和展望。的確,未來的理想跟展望,的確很重要。不過,在面試階段,要判斷此人能否實現理想和展望,應該是根據其過去的「理想與展望的實際產出」。

一般外商HR的實務操作方式為:面談時著重於情境「實例」。(SAR: Situation Action Result) 

例如,有個軟體研發部門RD主管的履歷表中,表示有帶領軟體開發團隊開發軟體。此時開放性問題無法真正展現該主管的經歷,應該採用情境實例問題,了解過去的「真實例子」。


-- 爛問題範例 --


未來取向的開放性問題:「未來你如何帶領開發團隊?」「你覺得RD團隊應該如何與業務團隊溝通?」....這種問題的回答必定是十分鐘不著邊際的長篇大論。



-- 好問題範例 -- 

初級情境實例問題:「目前你的團隊共多少人,其中有直接report給你?」「此專案你本人有參與寫程式嗎?」「此專案你本人有執行code review嗎?」「這個專案一共大約產生多少行程式碼?」

......初級問題著重能取得簡單而無可偏頗的答案,答案可能為「是或否」,可能是「數字」。回答應該是在10秒內。




中級情境實例問題:「在帶領N個人的團隊裡,你個人做過哪一件事情對團隊合作最有幫助?你怎麼做的?結果是什麼?」「在之前的工作裡,你做過最糟糕的決定是什麼?為什麼此決定是最糟糕?」

......中級問題著重於過去的某單一事實,必須引導回答針對這個人的實際作為,以及產生的結果。如果詢問的問題是負面資訊,例如犯下的錯誤。必須確定是問到犯下「最大的錯誤」。在面談過程,如果一個中高階主管,在過去7年的職業生涯沒犯任何錯誤(或者拿一些小小的失誤當作談話材料),很可能是隱藏事實,但更糟糕的是,他不覺得自己有任何錯誤的地方。


高級情境實例問題會和另外兩個要點:「本職學能」以及「獨立執行單位有關」請參考以下兩節。


簡而言之,SAR的基本概念很簡單:找出事實,而非空想;討論實際,而非理想;了解過去,而非未來。這部不代表理想與未來不重要,而是要判斷中高階人才的理想與未來,應該是看他「過去實踐過多少」,而非不是他「打算未來實踐多少」。


參考資料:(Careerly, SAR)





要點二:本職學能


已經位於組織中高階,很有可能早已不具備,或者喪失本職學能。因此,正確判斷是否具有合適的本職學能極端重要。

然而,中高階位階的人,其本職學能比較抽象,需要有方法加以判斷。

資訊科技領域的判斷方式有:(1) 基礎經歷 (2) T型延伸 (3)培育人才


(1) 基礎經歷:

以職業籃球為例,目前NBA的總教練,必然曾經在他人生的某個時期是「頂尖球員」,也許只是在NBA眾多明星中的候補球員,但也至少是NCAA某個第一級學校的球星。縱使不是,至少也是在高中時期,某一個州的的MVP等級球員。總而之之,他必然曾經當過明星球員,因此在當總教練的時候,能夠了解一整隊明星球員的思維,球員在比賽時的「真正作為」

同樣的,假設在軟體開發,找尋中高階的帶人主管,他本人必須「曾經是軟體開發人員」,最最最起碼也需要有3年以上實務寫程式的經驗。一個的SA或PM,也許工作的經歷還不錯,但如果沒有務實的寫程式經驗就來帶領開發團隊,就好像一個資深的球隊經理,看過很多比賽,卻沒有實際上打過球,就來當總教練一樣的危險。

或許有人會說,有些人屬於「將將之才」,他當將軍比當士兵還適合,不應該以過去的基礎經歷來斷定。在其他領域,或許是,但在資訊科技領域,「沒寫過程式」就是「沒寫過程式」。


其他的基礎經歷,必須有「清楚的事實」的佐證。例如,在履歷表上有AWS的使用經驗,就必須要清楚地知道何謂使用經驗?是用過EC2/S3/Route53,還是用過那數十個服務的哪些服務?是自己親自使用還是「指揮」別人使用?使用的規模有多大?等等


(2)  T型延伸

T型延伸的基礎是先有「基礎」,因知識與職責擴展的關係,延伸到其他相關領域。例如,在已經有智慧型手機應用程式開發的「基礎之上」,延伸到線上行銷,社群開發等等。

誠如前一節所述,沒有基礎,延伸不具意義。

關於T型人才,請參考這裏這裏

(3) 培育人才 

並不是每個人都會是好老師,不過如果中高階人才承擔的任務與管理有相關時,能否「培育人才」將會是團隊成功的關鍵。在SAR的方式裡要找到培育人才的方式很簡單。初級問題像是「你個人過去六個月以內,做了哪一件事情最能幫助團隊培育人才?」。中級問題像是「」




要點三:獨立執行單位


資深的工程師和初入社會的新鮮人最大的差別之一,應該是能夠自我成為一個執行單位。判斷是否已經成為獨立執行單位,是選才關鍵要點。


判斷的基礎方式有:(1)自我培養,(2) 計劃未知,(3) 人才培育。



(1) 自我培養

可以在組織裡,自行培養自己,發起並參與適當的事件。在中高階人才中,不存在「組織要協助培養能力」的情況。

這並不代表不用學習,只是不應該透過組織來建構自己的職業生涯和學習計畫。資深與中高階人才,應該要能自己規劃學習計畫,主動學習,並且「主動」將自我成長與組織成長「整併」。

僅專注在自我成長,對組織沒任何好處。努力使組織成長,放棄自己的成長,對組織也沒有好處。雙贏才是長久之計。



(2) 計劃未知

沒有人能預測未來。但資深中高階人才,應該能透過本身的技術能力,工作經驗,長久累積的直覺,有效看出至少數個月後的可能發展,並能有效制定計劃。

計劃(plan)本身並不重要,重要的是做計畫(planning)。中高階人才應該能在有限的已知情況中,盡可能計劃未來,建構真正的目標,評估控制風險。

而這計劃並不是為了展示,也不是文書作業,也不一定需要900頁巨作。關於計畫,請參考這裏


(3)人才培育:

請參閱前一節的培育人才。






3/17/2016

工作學不到東西:三個自立的方法



在資訊科技的公司裡工作的人,無論年資,大概常會聽到有人提到「在這裡學不到東西」「這個team沒有給足夠的訓練」「在這裡的發展有限」等等的牢騷抱怨。抱怨自然是人之常情,不過,個人職涯最終還是決定於自己。換言之,大部分的情況下:公司,環境,同事,工作內容...等等大概都不是「學不到東西」的主因。

任何情況下,都有以下三個實質的方式可以嘗試。


方法一:理解事實


任何事情,一開始都應該理解事實。

先確定是組織或者公司無法給予足夠的學習機會,還是自己沒辦法自我學習?假設沒辦法判斷,99%大概是屬於沒辦法自我學習的情況。

事實無好壞之分,事實只是單純的事實而已。然而,試圖了解事實有時候並不簡單。

一個剛畢業的學生,除非是高斯埃爾米特之類的天才,否則幾乎在任何組織裡,都有可以學習的事物。特別是在資訊科技領域裡,無論是正面學習,側面學習,甚至負面學習,在一段不長時間內(1-3個月)一定可以學到某些新技術,某些新觀念,某些應該避免的不正確的事情。

如何了解事實?可以試著問自己以下問題:

(假設處在一個軟體開發的組織中)

* 在這個組織裡面,所有相關技術你都能有效掌握?

* 組織中沒有人比你資深?

* 組織中比較資深的人,你都了解他過去的工作經歷?

* 目前組織中使用的程式語言,開發工具,你都已經徹底瞭解其優缺點?

* 目前整體開發過程的技術問題,都已經了解真正原因,並能務實地加以改善?

* 對於類似的軟體開發專案,類似功能的產品,都已經了解相較於自己團隊的優缺點,以及技術差異?

如果以上回答都是YES。事實就是這個組織真的無法讓你學到東西。不過如果有回答是NO,事實可能是你需要知道怎麼學習。




方式二:學習如何學習


請參考如何充實自己篇。

學習的本身是需要學習的。雖然每個人的學習方式略有不同,但提昇自己如何學習的能力,遠比把自己放在「可被教學」的環境來的重要。

簡而言之:花錢去上教學課程,在工作中有資深同仁可以帶領,參加各類型研討會...等等,這些雖然絕對益於個人成長。但是,「靠自己獨立學習」卻是一個難能可貴的技能。

而這項自我學習的技能也是需要學習。這衍生出看似複雜的問題:個人能否自我學到自我學習的技能?

撇除邏輯上的矛盾,找到適合自己的方式最為重要。若還沒有找到,可以參考如何充實自己篇。

舉個實際一點例子,假如你想學習作為一個好的軟體團隊中的QA,隨便在google或者youtube搜尋一下相關字眼,起碼可以找到數十個相關的教學文件甚至錄影。

認真花上幾個小時看完以下網頁以及教學錄影,相信你對這個主題肯定有某程度的瞭解。這都是僅透過"how to be a good software QA" 以及相關關鍵字搜尋得來:
1 http://www.guru99.com/software-testing.html
2 https://www.youtube.com/watch?v=sab0dblUpIE
3 https://www.youtube.com/watch?v=G5RpYi2dT04
4 https://www.youtube.com/watch?v=j8kY9txH2bc
5 https://www.youtube.com/watch?v=xCwkjZcEK6w&list=PLXXvO4OXeJrfbPrI0CV-re2VkdiV1dC7X 
6 https://www.youtube.com/watch?v=vimfiZZ4NI0&list=PLZTe0pWS8OYv3KYWJTZT_3chbtpXBoiOz&index=6
7 https://www.youtube.com/watch?v=OLayCNOPWIo

8 https://www.youtube.com/watch?v=hMfPCdF07hA






方式三:做出結果


資訊科技相關工作,特別是和軟體開發有關的工作,「學習」是很重要,但是「產出」卻更為重要。而產出就表示有具體的結果出現。

例如:這幾年data scientist相關話題非常熱門,有許多已經在職場2-3年的軟體工程師,常常會以這工作能否讓他有「data scientist經驗」為學不學到東西的考慮因素。

然而,其實特定技術領域,學東西最正確的方式,應該是自己能做出「某種結果」。

如果想要有data scientist工作經驗?有太多現成的「真實」工作經驗可以自行取得。

在大部份組織內部,都有很多無形產生的資料。這些資料,絕對足夠一個程式設計師學習以及做出學習的結果。

例如:

  •  程式碼版本控制系統(git, subversion, svs)。含有整個專案開發過程的「實質進展」資料,可利用他做時間序列分析,程式設計師個人績效分析。目前早有許多專案提供工具。
  • 組織的AD資料。正常情況下含有可供內部公開使用的資料,例如組織架構,人員變更。
  • Web Log。現在大部份的專案多少都使用HTTP,他必然會產生足夠大量的Log。一般Log分析工具(例如AWStats)已經可以做基本的資料分析,再配合machine learninig就可以做出各種有趣的結果



至於在組織外部,機會更幾乎是無窮盡的,也可以透過某些網站取得真實的資料,做真實的工作。例如:kaggle :在此有真實的專案,任何人都可以取得資料,透過自己的能力,完成資料分析專案。其他像是一般外包的網站:upwork.com也會有類似的工作,但可能不見得可以取得真實資料。

以結果為導向的學習,會比較腳踏實地,並且容易達到想要的效果。然而需要個人的興趣以及決心來支持。




參考:努力的三個迷思


12/03/2015

如何充實自己:三個自我學習的快速方法



資訊科技進展不只迅速,它順帶擴大自我學習的可能性。大部份的人只要能夠上網,就可以取得各種即時的訊息與知識。換言之,很多人都認為,資訊科技領域沒有什麼東西是學不會。

但是,沒有人一開始什麼都會。即便資訊工具改善過去知識的取得的不平等,但是自己要有意願和方式去學,這件事是沒辦法由技術來改善。


而為了充實自己而學習是沒有最好的方式。然而,多參考別人的方式,建立對自己最適合的方式是簡單並且直覺的選擇。

學習的目標,以及打算達到的廣度深度各有不同。如果只是很淺的了解個大概,只要用google搜尋,看看wiki大概就可以了。不過這樣的學習非常的片段,並且沒有組織。如果想要建立足夠的深度,這樣的方式獲取的知識過於片段,難以累積。(參考->片段知識的危害)


提供三種務實的方式,這三種方式的目標,廣度,深度,所需要的時間各有不同:


(1) 方式一:圖書館堆書



做法很簡單。只要你有想要充實並且學習的主題。無論是組織行為,還是憂鬱症;無論是個人領導力,還是專案管理。只要是社會科學,企管相關,科普等目標都蠻適合。

在這裏,假設你想要學習並盡可能瞭解"精實創業"。

首先帶著筆和紙,最好先不要帶手機或電腦,去附近的大學圖書館,或者比較大型的圖書館,例如新北市書館,台北市圖書館。

在圖書館的公用電腦,查詢"精實創業"以及相關字詞"創業"/"精實",記下列出來的書本期刊,當然最好連同英文書也查一下。列出這類型的書籍在哪一樓哪一櫃,直接到書櫃上把所有相關書籍全部搬到座位上堆成一堆。通常相關書籍都會集中在同一櫃,所以搬動起來應該很方便。

接下來,拿起筆和紙,打開第一本書。抄下書名,作者,出版日。簡單瀏覽一下目錄以及推薦簡介,看完目錄之後,把你認為重要章節名稱,手抄在那張紙中。再打開第二本書,重複剛才的動作。如果有20本書,大概只需要花一小時就有完整清單。

然後,仔細看一下清單,排列組合並且思考一下,哪三本書,所可能涵蓋的範圍最廣,時間最新。快速地將這三本書的目錄再度瀏覽一次,選一本先看完。然後休息一下再看另外兩本。這樣大概需要花兩小時,就可以對這"精實創業"有足夠的粗淺了解。

最後,記得先休息一下。休息完之後,在腦中思考這三個小時裡面學到什麼。憑藉這三小時的記憶,在腦中描繪「精實創業」的概念與自己認為重要,或者奇怪,或者有疑惑,或者有爭議,或者和其他領域連接的地方:這些地方稱為轉折點。回到那張有目錄的紙上,找出某些書上有解釋你認為重要的轉折點,閱讀並且理解這些轉折點。如果有20本書,起碼可以找到3本以上有這類型的地方。最後這個階段,能夠建立從別人身上了解的知識批判性,不過也最花時間,可能起碼要3小時以上。

因此,花上六小時,你就可以曾原本不了解精實創業,變得比大部份的人都了解,肯定比只在google搜尋,看看wiki的人瞭解更多。不過,請注意這只是充實知識了解而已,真正的精實創業就像打籃球一樣,是沒辦法光用看的方式是不可能實踐。

這個方式,我本來以為是自創的,但是後來發現有很多人都用類似的方式,只是做法各略不同。果然太陽底下真沒有新鮮事。

關於大量閱讀,可以參考這篇:大量閱讀的三個步驟

(2) 方式二:心智圖表徵


在已經有某些知識的背景上,試圖瞭解新的方向,或者找到自己缺乏的方向上,mindmap (心智圖)還蠻適合。他也很適合探索自己未知的事情,或者強化個人思慮的周密性。

在這裏,假設你想要學習並盡可能瞭解"軟體專案管理"。並且也認為自己想要擴張這方面的相關知識。


首先,拿一張紙(最好比A4大)一支筆,把主題寫在中間。將心裡認為可能的最重要項目連結起來。例如下圖:



把自己沒有經驗的,缺乏的地方做一些記號。通常我會使用問號?。接下來專心的根據自己缺乏的地方,尋找相關資料。重點在於,有組織的擴張知識,比片段搜尋來得有意義。

順帶一提,心智圖用法很多,"充實自己"只是其中一種。心智圖 (mindmap)不是什麼新科技,而且每隔一段時間就會有各式介紹文章,例如這裡,以及這裡。雖然介紹的範例與文章很多,但實務上,心智圖還是完全依賴人的過往經驗和創意連結。 


(3) 方法三:教學相長


這特別適用於資訊科技類型,例如程式語言,系統平台,或者任何技術。基本上,會先用其他方式(上網看書,練習實作等等)累積自認為足夠的知識與能力。接下來,想快速增加深度。或者充實自己想像不到的方向。教學相長是一個好方式。

就近找朋友或者同事,用你認為最精闢的方式,把技術和務實做法分享出去。光是在準備「教材」的過程中,就可以知道自己哪些觀念或者哪些方面不足,從準備教材的過程,就已經開始自我充實。

而最重要的是,取得聽眾的意見和問題。因為,他們可能會問出你想像不到的問題,讓你看到想像不到的視野。

實務上有幾個主動教學方式可以參考:



* 在大組織裡的主動分享

如果你是一個大企業裡面的員工,就自願性的訂一個會議室,訂一個主題,邀請一些相關的人來聽你分享某個技術。這樣的行為很簡單,而主管通常也很鼓勵主動進行。如果信心不足,可以訂一個極簡短的主題,這可以確保想來聽的人不會覺得浪費時間,也可以讓你精深的準備一個項目,提升自己的信心。



* 參加研討會:

參加研討會,並且把自己的知識在研討會上分享比想像中的容易很多。當然如果你要參加的研討會是類似IEEE的學術性質研討會,那你得花時間寫論文,而且不見得會被取用。不過,一開始先找lightning talk就很簡單,雖然只有幾分鐘,但是可以很快地獲取聽眾的真實回饋。



* blog/youtube教學影片:

近年來的分享知識方式。它無法立刻獲得聽眾回饋,但重點在於製作影片,或者撰寫blog文章之後,自己在試著重新閱覽一次,通常就可以找到許多漏掉的細節,或者過於瑣碎無用的地方,或者找到和其他人不同的觀點。

* 找到具體達成的目標:

例如:考取「低成本」證照,以Scrum為例可以參考這篇





其他相關文章:
   * 如何在工作中成長
   * 換工作的面試-軟體工程師如何展現價值
   * 自我學習的三個參考方向
    * Team Leader提升能力的三個方向
  * 如何提高工作效率
* 大量閱讀的三個步驟