顯示具有 搞定工作問題 標籤的文章。 顯示所有文章
顯示具有 搞定工作問題 標籤的文章。 顯示所有文章

7/24/2016

為自己工作 - 契合組織目標



雖然這幾年,創業蔚為風潮,但在台灣,大部份的人還是受雇於組織或企業。

「為自己工作」這句話看似自私,但其實所導引的結果才是對企業組織以及對個人有利。至少,對白領階級的知識工作者是如此。(註1)

表面上,大部份的人似乎並不是為自己工作。實際上,會去工作的原因是可獲得報酬(報酬涵蓋:薪資,技能知識學習,個人成長,成就感,社會參與感...等等),因此,無論表面原因為何,也無論自己是否有認知到這個事實,即便是受僱用者,絕大部份的人是為了自己,或者自己的家庭,而工作。

然而,在職場上常聽到各種抱怨心聲。其中有很大部分,其來源是沒有認知到自己是「為自己而工作」:

例如:

  *  工作很無聊學不到東西
  *  自己的價值不受到老闆重視
  *  對公司貢獻超級高,但是相對報酬卻很少
  *  做事人少,出嘴巴的人多 (特別是在政府單位)
  *  組織方向不正確,快要完蛋了

抱怨不是大問題,但失去自我方向之後,就很難在職涯上突破。個人的工作目的,必須要「由自己想辦法契合組織目標」。否則,就會有「不是為自己而工作」的念頭。一旦有這種念頭,很快的就喪失信念以及工作熱誠。

誠如前述:「為自己工作」這句話看似自私,但其實所產生的結果才是對企業組織以及對個人有利。

如果真切的認知到事實是「即使是受雇用,但自己其實是為自己工作」則進一步更能在工作上展現能力,切合組織目標。也更能給予組織更多的價值。因此,認知事實,才是生涯展開的最重要的事情。前述的理由就根本不會存在。

例如

  *  工作很無聊學不到東西:請隨意google一下就知道,企業組織雇用員工,不是為了讓員工學東西。而是解決問題或者產生新的價值。而工作學不學得到東西,也請google一下,都是取決於自己而非工作的本身。

  *  自己的價值不受到老闆重視:員工的價值就像在擺在口袋裡的針,只要你夠尖,有一天一定會穿刺而出。如果你覺得不是被擺到口袋,那就找到一個會擺你到口袋裡的組織。光是抱怨是沒有意義的。

  *  對公司貢獻超級高,但是相對報酬卻很少:先確定是自己的貢獻真的超級高。以業務員為例,許多大企業的業務,其業績是靠著大企業的品牌和產品,而非個人能力。以程式設計師為例,其程式產出,絕大部分是靠團隊能力,而非個人能力。

  *  做事人少,出嘴巴的人多 (特別是在政府單位):也許你的生涯規劃就是要去這類型地方?如果是這樣,也沒什麼好抱怨。如果不是,就趕快離開,也沒什麼好抱怨。

  *  組織方向不正確,快要完蛋了:在一個快沉的船上,就是你發揮能力的時候。如果你自認為是個策略舵手,當然應該矯正組織方向。如果你覺得自己是在大組織裡的小螺絲,那麼你為何能「判斷」組織方向不正確?或許是你的判斷不正確?無論如何,你永遠有離開組織這個選擇。



在大部分時候,人總是可以找到契合組織目標的方式?主要有三種:「自然篩選」「個人規劃契合組織」「創業」

1. 自然篩選


當然,企業組織會自然的篩選「契合組織目標」的人。自然篩選的程度與經濟學上的「看不見的手」有過之而無不及。

例如:一個長期處於保守狀態的組織,自然而然會留下不積極的人。一個以退休津貼優渥的組織(例如公務員),自然而然,就會吸引「為了退休而工作」的人。當然,當一個人拼命念書,絞盡腦汁的通過高普考,一進去公家機關就數饅頭等著退休,自然就不會抱怨「工作無聊學不到東西」以及「自己的價值不受老闆重視」,畢竟,進來這個組織的真正目的,其實是為了退休...。

反過來說:一個新創事業,自然而然會吸引想要透過自己的能力,積極開創一片天地的人。而「退休津貼」就不可能是工作的首要目的。但工作是否有趣,組織方向正不正確,就成為關鍵因素。

雖然,個人沒辦法影響「自然篩選」,但如果你的工作目標,和「自然篩選」的目標不一致,當然會工作的很痛苦,而抱怨連連。

解決自然篩選的方式有三種:(1)離開 (2) 改變自己 (3)改變環境

其中,離開是最簡單的。辭職換新工作,自己創業,創業失敗後再創業等等,都是離開。

改變自己很難。但潛移默化之下,很多人會因為自然篩選的環境而改變自己。

改變環境其實難上加難!但是,一旦有機會做到改變環境,你就擁有一個難以言喻的經歷。這個經歷對職涯有絕對的幫助。



2. 職業生涯規劃契合組織


傳統企業組織都知道,激勵員工很重要。但組織出錢出力,費盡心思的「各種激勵」其實遠遠不如讓員工的生涯規劃契合組織目標。

就前段所述,其實無論如何,自然篩選會讓組織留下契合其目標的員工。但這需要起碼數年的時間,而前提也是組織沒有大的變故。 如果組織 - 特別是營利企業 - 的目標和其展示的行為不一致,自然篩選會失衡,要達到平衡。

因而「以個人力量做出契合組織的規劃」才是最簡單,最容易,最能獲得三贏的選擇。

除了工作內容外,每個人常遇到工作上乍看之下不可伉儷的因素,而認為自己無法契合組織目標。在你還沒有丟出辭呈之前,可以執行的個人能力與選擇非常的多。這些選擇都可以有機會做出契合組織的目標。

例如:

* 每天都做無聊的工作:既然是無聊的工作,表示是重複簡單類型,試著將這類工作最佳化,並自動化(註2)。 不知道怎麼自動化?那就去學阿,在工作中學習成長,並透過自動化的貢獻,不但提昇自己的能力,也讓組織獲取更多價值。

* 工作太多,常常超時加班,生活品質太差:所有企業組織,其存在的目的,絕對不是要員工加班完成目的。其存在的目的都是為了獲利。隨著組織分工,以及各種環境變化,容易產生以「加班」的方式來解決問題。這完全可以避免,請參考:解決專案困難的最爛方式; 如何提高工作效率; 80/20法則。也可以網路搜尋一下任何增加工作效率的方式。

重點在於去做!Just Do It!不去做,永遠不知道加班問題能否解決。

* 加薪升遷不如預期:如果是在大企業工作,加薪升遷的確常常不如自己預料。但如果你確定自己有這樣的價值,一段時間一定會被發現,如果不被發現,在離開之前請先想清楚「自己是否真有這樣的價值」?想清楚的方式也很簡單,可以去試著去應徵其他組織,看看有沒有其他組織願意提供給你更好的薪資福利。如果沒有,表示在當下你的確無此價值。如果是在小企業,薪資福利可能無法有大幅成長,但小公司能提供的通常是更多的自由和自我成長。既然你已經自然被篩選到小企業,或許本來就不是很期待制式的加薪升遷了吧。


* 組織做犯法或遊走在法律邊緣的生意:趕快辭職離開!越快越好。你確定你想要加入犯罪組織或者遊走在法律邊緣?!


3. 創業

創業,當然就是為自己工作,當然也一定會契合組織目標 - 因為你就是組織。倘若你創了業,卻因為各種原因,去做不是你訂立的目標的事情,那等於是沒創業。(註3)

不過創業成功難非常高(參考如何確保創業成功)。富貴險中求,高風險當然比較能伴隨高獲利,如果生涯的志向在此,盡可能參考已經成功的典範,或許能降低失敗機率。







註1: 藍領階級的勞動工作者可能不全然適用。

註2: 同註1

註3: 當然,也許你是共同創業,或者持有股份很少,那麼請視為在組織為自己工作,不要視為自己創業。


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法則之軟體專案的三個運用重點


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/29/2016

非戰之罪?組織變動的三個因應作法



世界越來越小,變化越來越快。企業環境更是如此

從2015年底的弊案開始,東芝一連串的裁員新聞便在網路上出現(參考這裡這裡)。最近,由於有要徵約聘員工,通常是很難在約聘的職位上找到有經驗的軟體工程師,通常也很願意找剛畢業雖然能力不足但很願意學習的年輕人。可是,這位林先生卻是個例外。他是自願前來面試約聘職缺,而且有十幾年工作經驗的專案經理。經過詳談才知道,他也是東芝海外大幅裁員的其中一員。過往,林先生充足的筆記型電腦專案管理經驗,讓他幾乎沒有其他的資訊科技能力,對於軟體開發自然也是完全沒有經驗。環境的變動,不是他的錯,但沒有先針對可能變動而準備,會讓他失去工作之後的6個月內仍然難以找到足夠幫他解決房貸問題的方式。是不是雇用林先生?還不一定。每個人都應該針對不預期的組織變動而有因應準備,這才是重點。



在一個超過150人的組織裡,一般的員工其實很難對企業環境的變化做出正確的因應。更直接地說,組織重組(re-org)目的各有不同,但一定會順帶調整人員,而作為資訊科技的組織的一員,在重組時很可能會受到不預期的影響。

可能發生的最糟糕的情況是「被汰弱」,其次的情況是「改變工作」,最佳情況是「被留強」。

而作為資訊人員,軟體研發人員,除了隨波逐流,隨遇而安之外,對於組織的變動,能夠有正確的因應作法會是最好不過。



變動因素


組織變動的因素很多,而絕大部份通常都非單一個人所能控制(除非你是CEO)。

好的情況有:獲利太多,而跨大經營範圍;獲得額外投資;併購其他企業。

壞的情況像是:賠錢要砍部門;被別人併購;移轉工作地點到低成本的地方。

不好不壞的情況也很多:改變經營策略;將寶貴的人力資源移到別的地方;停掉某些產品研發等等;組織汰弱留強,調整人力品質。


對個人影響


組織變化對個人的真正重點在於「因組織變動產生的行為」,當然不外乎以下四項:

離開組織(資遣/開除/離職):無論是被迫,自願,或者被自願。

執行讓員工離開團隊的任務(執行資遣/開除):通常是中低主管的任務,也許是會執行讓人離開組織的任務,也許是更換工作內容以及更換部門。無論是被迫還是自願。

改變工作內容環境:做其他專案,升遷,換到其他部門,換老闆,更換工作地點,改變工作時間等等。

改變工作報酬:加薪,減薪,更改薪資計算方式,更改其他相關福利等等。


如果不是CXO,幾乎不太可能在很早之前,事先知道組織變動。不過,對於資訊的技術人員(程式設計師之類),即便是一般員工也能有比「隨波逐流」更好的因應作法:




做法一:事先因應。




首先,所謂事先因應,並不是事先知道各種變動因素發生。通常你知道變動因素發生的時候,一定已經是「太晚了」。

事先因應,指的是因應「黑天鵝事件」,也就是試圖因應未曾發生過的,但是一旦發生,會有劇烈變化的事情。但是,既然是黑天鵝事件,就不可能事先知道事件的種類,發生的原因,發生的時間地點。

事先因應指的是,培養自己,因應「未知」的事件。

作為資訊科技技術人員,相較於其他行業,培養自己比較簡單。剛出社會的新鮮人,當然就繼續學習新的技術,不管是程式語言,系統工具,開發流程,都有極大的學習空間。

稍微麻煩一點的是,工作7-10年左右,在可能不上不下的階段。這個階段,必須要先確實「認知」自己對現在組織的價值,並且透過這樣的認知,

乍聽之下很抽象。例如,你現在可能是軟體公司的技術小組長,帶領3-4同事進行軟體開發,這時候顯而易見的有兩個未來的選擇,(1) 你可以往技術方向前進,未來成為架構師(architect)或者技術長。這時候,培養優勢就在於,應該有意識的讓自己的知識範圍,隨著時間越擴展越大,並且不會僅侷限在這個組織之內。(2)你也可以朝向專業經理人前進。未來成為帶人的主管。這時候,培育的優勢方向在於:必須要同時兼備技術能力和判斷決策的能力。判斷決策能力的自我培養,必須要是有意識地進行。



找到自己的價值,發揮優勢,培育優勢。並且試圖擴展的優勢,讓它不僅限定在特定時段,特定組織,特定產業,甚至特定國家,。



做法二:創造選項。



至少在台灣,絕大部份的人,在任何事情上都有「選擇」。

有些選項,顯而易見。例如,有個選項是:覺得不喜歡組織的某些事情,就「選擇」離職了。

有些選項,因為認知偏誤,不容易看見。例如,有個選項可能是:覺得不喜歡組織的某些事情,就「選擇」去改變這個事情。

大部份的人,都可以輕易看出既有選項。但是,能「創造」選項的,或者看出非既有選項的。其實不多。

軟體技術上,能創造選項的例子比較多。例如,即便到今天為止,在很多企業仍有winXP的存在,但是他所使用的IE(8)很老舊。如果你的網站應用程式,一定要給這些企業使用,擺明著選項有兩種,一個是苦幹實幹,讓網站遇到IE8的時候,用比較老舊的javascript library,另一種是說服企業升級winXP。不過,只要稍微想過,很多技術人員都可以「創造」其他選項。例如部署新的firefox/chrome到winXP上。


然而,非技術的選項,能「創造」的可能性變少很多。但其實,這僅是受限於自己的目標錯置,認知偏誤,或者錯覺。

以組織變動的情況而言。也許你是「被自願」離職的員工,似乎也只有自願離開一途,但如果真的很不想被自願離開,首先需要知道你不想離開的真正目的,和你真正想要達到的目標。例如:或許是因為家庭因素,你需要穩定的收入,而非真的喜歡這裡;或許是你喜歡這個工作環境;或許是你一時之間找不到其他工作。原因可能有很多,但如果你的目標沒先想清楚,能創造的選項自然受限。

如果是因為家庭因素,你需要穩定的收入,而並非真正喜歡這個組織。你的目標應該是「在短時間能創造有穩定收入」,對於有技術背景的人,這並不難達到。難達到的是:「短時間創造極高收入」

如果是你一時找不到其他更好的工作。你需要「創造」找到更好工作的機遇。到linkedin上認識headhunter,加入open source社團,到社福機構提供技術能力當義工...等等都是可創造選項的機會。




做法三:根據事實。執行。

執行選項,特別是執行不那麼容易的選項,需要克服很多心理上的障礙。


特別是以非技術選項而言。突破個人心理上的障礙,執行最適合的選項是知易行難。

遺憾的是,沒有人能夠代替你執行。因此在此只能提出幾個參考點,協助克服認知與心理障礙。

(1) 只有自己才能負責自己的職業生涯。

(2) 軟體技術人員,在技術上都有過度自信的傾向。

(3) 沒有人剛生下來的時候是會寫程式的。

(4) 學習特定的軟體工具,平台,程式語言很重要。但要注意的是,不能把雞蛋放在同一個籃子裡

(5) 組織領導者(主管)的優劣與否的判斷很難。不過,試圖讓所有相關人等都滿意,大家歡喜的領導者,反而容易引導至糟糕的結果。




  





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] 你能單靠記憶,繪出目前專案個模組之間大概關係,無須依靠其他專案成員?








2/12/2016

工作筆記的三個重點



這幾年來,市面上有如何做筆記的書。例如記事本圓夢計畫重點就是要這樣記不花錢學筆記(註1)等等。

在 youtube上也有很多類似的教學影片,在youtube上搜尋"how to take notes"可以找到數十個教學範例:例如這裡

大部份的筆記教學,大概都是透過個人經驗,指引筆記的技術。例如,有效使用不同顏色的筆,將一頁分成兩欄,左欄做為索引用途,右欄作為記錄重點用途,等等。

而筆記教學的目的,則和筆記教學的內容有根本上的差距。筆記的「目的」,通常極為崇高,例如實現人生夢想。但筆記教學「內容」,卻是極為底層,例如,試圖說明為什麼紅色的筆,適合書寫哪些東西。

其中的差距,其實只有三個難以實踐的重點。

找到並擷取重點,採取正確形式,定時審閱檢討。


重點一:重點



無論是會議紀錄,執行工作中的紀錄,在學習新技術的筆記,都應該擷取並且記錄重點。

這是無庸置疑,但不見得容易做到。

以軟體開發而言,會議記錄的首要重點在於「結論」,而結論的重點在於「會議後執行的行動」。會議的過程,熱烈討論的經過也可以摘錄重點,但都沒有最後結論來得重要。

以學習筆記而言,如果是要學習既存的軟體程式,以便於接手未來開發工作,學習的紀錄重點在於「為什麼」程式會這麼撰寫,而非程式怎麼被執行。因為「為什麼」的理由可能只有當時的工程師才知道,而怎麼被執行,卻是原始碼的本身就會告訴你的。

以日常工作記錄而言,工作八個小時之後,重點在於紀錄「今天你認為已經完成的最有價值的事」。並記錄為什麼這是有價值的。

重點的節錄,不見得只有「寫下來」這種方式。當特殊email出現(例如變更規格email),可以直接列印出來貼在筆記本上,不但節省記錄時間,還可以完整紀錄email時間和收件人。當技術討論會議結束時,將白板的複雜圖形拍照,直接email,或者列印,或者交由虛擬助理後續處理,都是簡單有效的方式。

庶務(註2)上的重點,也應該當重點擷取紀錄,但要切記不要將紀錄庶務,當作有價值的東西。應該統一記錄在某處即可。

補充一下:

在工作中,重點難以找到的原因很多。例如:每個人認為的重點不一樣;重點有時候會轉移;這事情壓根就完全不重要...等等。

根據自己對團隊組織的存在價值的正確理解,再加上對自己目標的認知,才能記到真正的重點。

以startup為例:三個初創的創業夥伴,各有1/3的公司股份,則必須要對組織未來存在價值有正確共識。假設其中一個人目標是希望能在2年內損益兩平,而另外兩個人則是希望在兩年內能獲得某程度的市場佔有率。這兩個目標就非常不一致,透過工作筆記「重點」的紀錄,很快就可以察覺不同(請參閱第三段審閱)

以在大企業工作為例:一個10人的軟體開發團隊,其目標是在某日之前完成某產品功能。其中有3人是負責品質(QA),另外6人負責開發(RD),還有1位是專案經理(PM)。作為QA的人,其工作記錄重點,就應該會與PM有很大的不同。QA的所有工作相關記錄重點,應該是「到目前為止」的品質狀況。PM則應該是「到目前為止」所有利害關係人的期待是否被滿足。





重點二:形式



工作相關的筆記,正確的形式能獲取效率。

形式的優先順序應該是:

1. 圖
2. 表格
3. 條列式
4. 一段文字
5. 沒有紀錄

換言之,可以畫圖就不應該做表格,可以是表格就不應該條列,可以條列就不要用一段文字描述。可以有機會紀錄,就避免沒有紀錄。

以軟體工程師而言,mindmap (心智圖)可以擴大思慮完整性,並且將事情想得完整。UML的各種圖形標準,則已經涵蓋各種技術的表達的可能性,幾乎不需要其他規格的圖形。

如果是專案管理的角色,則RACI(表格)會很容易表達各種則關係。但是,如果要和利害關係人報告,則不可避免的應該使用投影片(slide)形式,作為表達的形式。

形式似乎很簡單。但是缺乏對形式的正確認知和練習,只會事倍功半。

一些例子:mindmap(心智圖)可以作為決策樹的前身或練習。任何文件(ptt,word)的表格,應該先在excel中實作之後,在插入投影片。任何excel的條列,必須是二維,並且應該先試圖使用pivot做簡單的分析。



重點三:審閱



定時審閱工作筆記,構成對於過去工作價值的概觀。


審閱的方式很簡單。固定時間(例如每兩週,每個月)把過去一段時間的筆記攤開,快速看過一遍。誠實的面對自己,「二次紀錄」需要改善的地方,特別是哪些事情「浪費時間」。然後,每年,固定時間(例如剛過完新年)審閱過去所有的二次紀錄的地方,再次誠實面對自己,審思如何改善。

如果你已經每天固定紀錄「最有價值的完成事項」,每個月應該花10分鐘,審閱過去的筆記。了解這些最有價值的事項,累積起來,確實讓這個月過得有價值。如果沒有,則應該「現在馬上」進行改變,即便只是稍微調整工作的方式,工作的目標,有改變都比沒改變好。

工作的會議紀錄,則要審閱並且演討「會議後執行的行動」。特別是沒有達到的行動。

工作的學習筆記,則要審閱之前有問號(?)的記錄之處,是否已經都了解。在工作中如果有發現之前紀錄沒有發現的問題,則應該額外紀錄遺漏之處。

沒有固定審閱筆記,跟沒有做筆記基本上是差不多的。


沒有審閱並事後查核會議紀錄,等於會議沒有紀錄。

審閱,能達到筆記真正的崇高目的,也就是幫助「未來」而不是僅只記錄過去。





註1:不花錢學筆記,這本書不是免費,還是要花錢買。

註2: 所謂的庶務,指的是某些資訊或者行為,本身也許有價值,也許沒價值,但無論如何,它不是這個團隊存在的重要過程或目的。例如:某個特殊系統的帳號密碼,大企業裡某些申請經費的特殊流程,辦公室阿桑固定掃地時間,福委會團購產品方式,某些高層主管定時會議的地點等等。很多大組織(特別是公務機關)中的老員工,把熟知庶務當作本身的價值。在資訊不發達的時代確實如此,但在今日已流於荒謬。



沈思:

1. 工作筆記的其實和紀錄的工具沒有太大的關係。不過,如果你是在西元2006年之前投入職場的人,在哪邊可以看到10年前你的筆記呢?今年(2016)你的筆記,以哪種形式存在,會留存比較久?


1/19/2016

努力才會成功:三個錯誤方向




有努力不見得有收穫,但沒有努力就沒有收穫。因為努力是通往成功的唯一道路。

然而,對於努力有很多錯誤的認知方向。

以下列舉最常見的三個錯誤方向:


錯誤一:「用力」就等於「努力」

「努力」和「用力」是兩回事。

試圖只用雙手去移動開一整座高山是「用力」;研究各種方式和技術,挖出一條筆直的隧道是「努力」。

在專案遇到困難時,千篇一律的超時工作,無止盡加班是「用力」;探究各種技術的突破,讓專案有進展是「努力」。

在傳統企業推廣資訊科技應用時,苦口婆心的淳淳告誡是「用力」;透過強迫的方式,逼使使用者改變習慣是「用力」;透過各種巧思,讓人願意自己使用新系統是「努力」。



錯誤二:努力一萬小時就會成為天才



小提琴家Auer曾回答學生說:「用手指練琴,可以練一整天,但是如果用頭腦練習只要一個半小時」(參考這篇

「努力」是需要花時間,然而,努力更要花的是思索以及驗證事物的本身是否朝著正確的方向。瘋狂的往錯誤的地方磨練一萬小時,不會讓錯誤變成正確。那努力一萬個小時變成天才,指的是有用頭腦的一萬個小時,而非不經思索的一萬小時。

是,努力所花的時間容易被人看到,而且容易讓人產生「同情」。因而,在企業中長時間加班的人,很容易被表揚;在專案延誤時,帶領團隊不眠不休努力,容易被認為是負責任;讓專案順利完成,讓系統保持為定沒有問題,容易反倒被認為沒事做。如果你是領導者,切記不要過度獎勵沒有功勞也有苦勞的情況。


錯誤三:努力的筆直前進


如果目標與達到目標的方式是錯的,努力就變成可怕的慘狀。許多人常被一個故事所誤解(掉到奶油桶的青蛙)認為只要堅持下去,也許事情會有轉機。然而,故事裡的青蛙其實已經採用正確的方式 - 也就是一直游蛙式。如果青蛙使用更有持續性的方式維持生命 - 也就是水母漂,那麼無論如何不可能攪動成為乳酪。

幾乎任何情況下使用googlemap規劃最短時間的路程,絕大部份都不會是筆直:最短時間的路徑,通常不是最短的路徑。

努力的目標要正確:確定努力的目標是你真正想要的目標。

努力的方式要改進。努力的增加知識與能力,讓進行的方式可以朝向最正確的路徑,而不是看似最筆直的路。

在盈利企業裡面,整體努力目標應該是合法的獲取利益;然而,在企業裡面投入工作的個人,在工作上卻應該是根據自己的工作內容訂立正確的目標,如果是業務當然是獲取訂單,如果是生產部門,也許是極大化產量,也許是平衡品質與成本。但是,下班後,目標應該是自己的目標,例如陪伴家人之類。

一個業務,無論採用什麼方式當他的業績,一年後沒有達到目標,當他要「繼續努力」的時候,一定要採取別的方式。繼續堅持用舊的方式,也需要「努力」了解為什麼舊的方式可以持續使用,而不應該改變。

大部份的專案,目標通常都已經定好,然而執行的方式卻應該根據實際的情況改變。例如:在前期中期發現有重構(refactoring) 的需要,就應該先考慮重構,而不是試圖先達到某個帳面上的milestone。

大部份的辦公室日常活動,其價值都越來越低,努力的方向不是增加手指打字的速度,也不是加班完成任務,而是朝向去除完全不必要的事情,簡化或自動化簡單的事情前進。









沈思:

努力而失敗的例子太多,可以找到在你的工作領域上的例子嗎?


12/30/2015

大學或研究所玩太久.(三個解決方式)






























有幾次面試新鮮人,發現有些學生自覺得在大學研究所時代"玩得太久",而對於即將投入就業市場有些自覺能力不足。

首先,如果照著學校教育做好該做的事情,就算沒有「玩很多」,老實說能力一樣是不足。想要在還未就業之前,就達到一個好企業的標準是有點難。當然在學時期,有很多事情,對就業有極大的幫助(至少就軟體以及網路產業而言),但是大概都不是台灣學校教授能教的。

這些事情像是:加入open source的開發工作,找暑期工讀,到外包市場接專案等等,都對自己有幫助。

但如果你已經來不及這麼做,就面臨畢業了。那麼除了延畢,隨遇而安看命運安排,拒絕面對事實...之外,其實有三個實質的作法可供參考。

對了,要記得,任何時候都為時不晚 只有覺得太晚的時候才太晚。



三個解決方式:



(1) 解決方法一:快速學習技術能力

想要投入資訊產業,不管擔任什麼角色,擁有技術能力永遠是對的。

找一個喜歡的目標,全面性的學習相關能力。不見得一定要花大錢上課,網路上現有的免費資源一定可以讓你在2-4週之內(最遲不超過4週)學會某種東西到一定程度。不管是Java programming還是HTML5,不管是Big data analysis還是photoshop應用。

如果對於快速學習技術能力有進入障礙,要記得這一定只是進入障礙而已。只要有興趣,願意專注,到目前為止還沒看過學不會的。真正問題在於有沒有專注的付出時間,如果確定資訊科技對你來說是完全沒興趣的,那也好,就此打住,改換跑道為時不晚。


(2) 解決方法二:尋找互蒙其利的機會,藉此重建履歷


很多時候,你需要的只是找到一個可讓你有學習機會的環境,這個環境可以促使你成長。如果不花錢,有什麼機會有這種環境呢?可以去看看upwork.com, guru.com, fiverr.com到上面以賠本的價格接專案來做,就會知道目前市場環境中缺乏什麼。


(3) 解決方法三: 打工與學習


這和解決方法二有什麼不同?打工是泛指先去做你不是很想做的事情,例如contractor。這除了可以讓你舒緩生活費用的問題,增加獨立性,也能獲取一些時間,讓你想一下自己有什麼選擇。

打工與學習,泛指各種範圍。在網路時代,只要知道怎麼找,資訊幾乎很容易取得。例如,如果你是26歲以下的女性,喜歡小孩想要學德文,au pair是一個看似誇張,但是合理的選項,參考這裡




創意沒有極限。不要只接受片面的資訊,即便是這裡也一樣:)




沈思:

1. 經濟學鼻祖書:國富論一開始就是在說明分工的重要。這也是就業市場上,各種職業產生的真正原因。能不能找到自己相對於別人的比較利益優勢?

2. 以長期而論,自己想要什麼很重要。但是短期來說,自己有什麼選擇才是關鍵。

3. 這三個解決方法,看起來都沒什麼創意,但是跟隨波逐流比起來,還有其他方法可選嗎?



12/28/2015

新鮮人如何提昇在組織中的價值:三個方法



請務必先看關於價值的這篇


稍微提醒,價值與績效的不同。

績效著重的是將評量標的量化,所以通常都會有明確的時間點、目標以及數字;而價值則看重在一個連續時間的累積。

比如說餐廳擦桌子 ,績效可能會訂成:在客人離開以後的五分鐘內要把桌子擦好,桌面必須全部擦過,不能有菜屑湯汁;而價值可能是:在客人離開後迅速把桌子擦乾淨,展現本餐廳專業乾淨的形象,並提供下一位客人舒適的用餐體驗。

所以你會發現,這兩個本質上其實是同一件事,只是觀看切入的角度不同;績效跟個人日常工作內容習習相關,而價值則是較與公司的整體特質相關。


(1) 了解組織需要的價值

身為一個新鮮人,通常前輩不會大費周章的跟你解釋組織需要的價值是什麼;而另一個悲傷的現實是:有些前輩自己也搞不懂組織要的價值是什麼?

所以這一部分通常必須要自己有意識的去了解。至於要怎麼能夠了解組織需要的價值?若完全沒有概念,可以參考以下方式

1. 參考資料:有些公司會寫出他們的價值,比如:IBMGoogleMicrosoft,或者公司內部訓練裡會提到,但大部份很可能只是打打高空,只能給一個很粗淺的概念。

2. 角色扮演:想像自己是老闆或是主管,想想要怎麼提升組織整體的價值?比如是處理財務的事務,精準的重要性一定會高於迅速;而若是救火隊或急診室,快速解決問題一定會比完美來得重要。想想客戶為什麼要買公司的產品,它對使用者最大的幫助是什麼?

3. 工作觀察:倘若組織不大,可以從日常工作中觀察下列事項:什麼樣的工作有比較高的優先權?什麼樣的錯事大家會很嚴厲的對待?什麼樣的錯事大家可以一笑置之?想想為什麼?

組織需要的價值是會隨著時間變動的,了解組織需要的價值可以幫助自己更快的進入狀況,甚至做得好的話可以提前走下一步路,而不是每天被績效的項目追著跑。



(2) 發揮長處避開缺點


了解組織所需要的價值,同時你也要了解自己(相關文章)長處與缺點。把自己的長處放在組織要的價值上,就可以達到相輔相成的效果。比如說你是一個很細心有耐心的人,那就可以主動接下財務、編輯、校稿之類的工作;你若擅長收集統整資訊,那麼研究、匯整、之類的工作就比較適合你;若你可以在資訊不夠充足的時候,在短的時間內做出決定,那麼也許可以嘗試第一線的工作。

然而如果反過來,急性子選到財務對帳的工作;要收集完資料整體評估才能下決定的人被要求馬上要下決定,這樣就算工作做完沒出事,工作起來也是很累的。

事先了解自己與工作的屬性,當有適合的工作出現時,主動接下來,還可以塑造出工作積極的加分效果。另外有時身為新鮮人不一定有辦法選擇工作,但知道手上的工作跟自己屬性不合時,就要特別小心,才不會不小心出包。




(3) 專注於產生價值

如上一點所說,你找到一個極能夠發揮自己長處的工作,你也很認真地做好了它,但結果沒有人在意這件事?!

知道組織要的價值所在,才不會走冤枉路。專注在幫組織產生價值的事情上,對組織以及自己才有意義。

回到一開始餐廳擦桌子的例子:假設你是那位服務生,在尖峰時刻忙到都要「搓草」了,眼看有一張桌子前一組客人已經離開過了四分鐘還沒清理,而下一組客人已經站在桌子旁,甚至有人已經等不及入座了,此時你會怎麼做?

1. 直接衝過去在一分鐘內把桌子清理完畢,好符合擦桌子的績效要求。

2. 過去客氣地跟客人道歉,不影響到客人的情況下,儘速把桌子清理完畢以後再請客人入座,可以的話清理的時候還跟客人寒喧兩句。

或是你覺得有更好的作法呢?歡迎跟我們分享





沈思:
了解組織所需要的價值,想辦法提升組織的價值,就等於提升自己在組織中的價值。如此一來,等同讓自己跟組織站在同一陣線上,而不是讓自己在組織中陷入一個你做工、我監督的對立狀態。


12/22/2015

解決專案困境的三步驟(軟體主管的31堂課)





一個完美被執行的專案幾乎不存在,特別是越是有潛在價值的專案,通常會伴隨一定的風險,因此很難不遇到問題與困難。

有經驗的專案管理者,可以在問題發生之前先行規劃解決,這和專案一開始的結構設定有很大的關係。然而就像扁鵲的父兄的故事一樣,能在問題出現之前防範未然者,讓專案順利執行,這樣的人在台灣的環境,似乎難以被定義其價值,即便有也難以被發現。

總之,有價值的專案,無論如何,難題總是會在某時候出現。

在接案公司中,最常出現的可能是時程,需求過度擴張,等等常見問題。例如:協助政府建立某APP用以查詢政府


透過以下三個務實的步驟,協助解決問題

在這裡假設問題已經發生,必且這個問題不在專案進行的時候的風險規劃之內。

這些步驟乍看之下,可能會讓人覺得簡單到需要特別說明嗎?不過,實務上遇到專案困難時,由於時間的壓力以及人類固有的習慣,能保持平靜看待困難是不太容易的。因此,透過簡單的步驟。

某些人常會對於既定的步驟有些許誤解,認為規劃好的步驟可能會失去彈性,減低創造力。但如果掌握真正的精神,結果會正好相反。



(1) 第一:了解事實



大概不少人會認為這是一句廢話。不過,在遇到真正困難的時候,困難的本身通常會隱藏事實。


舉例來說,看似最常遇到的困難就是資源缺乏。以軟體專案來說,就是沒足夠的人力,或足夠的時間來做事情。

但是,絕大部份的人力不足,其根本原因都不是人力不足。

根本的因素可能是:現有的人沒有執行這方面專案的經驗;負責的專案經理能力不足,無法有效協調人力;現有的人員無心執行任務;規格不明確,而導致執行方向不正確,因而使專案到中後期看似沒有足夠的人力或時間完成...等等,諸如此類,才是真正的事實。

人力不足,沒有時間,只是表象。

專案負責人(可能是專案經理),必須要先找出事實。

一個很簡單的原則:如果有表象是「沒有人手」,「沒有時間」,「規劃的進度常常延誤」,專案負責人幾乎99%可以斷定背後必有其他原因。


了解並且面對事實是務實的第一步驟。缺乏這個步驟,任何其他的解決方法都沒有意義。





(2) 第二:模擬不同的解決方案



通常界定真正的事實之後,解決方式大概就隨即而出。然而,既然是困難的問題,就應該想出一個以上的解決方案,然後模擬可能的後果。

這裡強調提出不同的解決方案,因為既然是困難的問題,表示一定在有限的時間以及資源之內,無法簡單的解決。換言之,任何可能的解決方案都可以會犧牲某些東西。因此「模擬」就有必要性。

最簡單的模擬是拿一枝鉛筆一張紙,描述接下來會做的解決方案跟可能結果的流程圖。

舉一個最常遇到的例子:時間不夠,而時間不夠的主要因素已經界定為專案進行過程,常常有需求的改變,但是專案期限卻沒有改變。

假設,可採用方法有以下幾種:

Plan-A:開始軟性或者硬性延長工作時間。

Plan-B:與專案業主坦承需求改變已經造成專案延誤,用Scrum的方式讓專案繼續推進到期限,但在此之間,專案完成的定義也會被改變。

Plan-C:與專案業主談判,取得延期或者需求限制。

Plan-D:...(還有其他很多)

這些解決方式也許彼此是有相關的,例如B與C,其實都需要和專案擁有者(就是出資的人)協商。


模擬Plan-A:

拿出紙筆,寫下所有已知的資訊或事實:

* 目前為止團隊每週的產出
* 目前為止需求的改變數量,和造成的延誤時間,假設延誤10天
* 規劃需要加班時間總數:假設延誤10工作天,目前到期限仍有4週,等於是每週需要額外20小時工作
* 加班之後可能能夠多做的哪些功能
* 加班的總長度,這個例子是連續4週
* 過去加班的耗損率:每週超過10小時的額外工作時間,會讓人請病假的機率
* 長時間加班之後人才的保留率:每週超過10小時的額外工時
* 加班的這段時間,還是會有需求改變。
* ...等等...

將這些已知資訊,不過心裡知道與否,還是盡可能寫在一張紙上,在腦中想像這些資訊「拼湊」起來之後,對於目前專案,有沒有可能使用這個方法解決,而這個方式,其副作用是不是過大。


模擬Plan-C:


拿出紙筆,寫下所有已知的資訊或事實:
目前為止團隊每週的產出
* 目前為止需求的改變數量,和造成的延誤時間,假設延誤10天
* 專案業主對專案的瞭解程度
* 專案期限往後延,對於業主的損失
* 專案業主的協調能力
* ...等等...

將這些已知資訊,不過心裡知道與否,還是盡可能寫在一張紙上,在腦中想像這些資訊「拼湊」起來之後,模擬與業主溝通時的可能對話,以及可能產生的結果。


選擇:

將模擬的過程,用心智圖(Mindmap)或其他圖形化方式,寫在同一張紙上。這麼做是為了盡可能排除個人主觀意見,將自己的思緒,用鳥瞰的方式呈現給自己。

模擬數個方案之後,最重要的是選擇一個自己認為相對最佳的方案。


(3) 第三:執行解決方案


如果前兩個步驟,已經竭盡所能。那麼,第三個步驟就變得很簡單:根據第二的步驟模擬之後的決定,執行解決方案。

然而,既然是困境,就不應該預期解決方案一切順利。如何克服困難去執行,就看專案經理的智慧與能力。

執行解決方式同樣有很多需要注意的地方。不過內容絕大部份取決於每個不同專案的特定現況,因此不會有放諸四海通用的銀色子彈。

但是,由於專案困境常有相似性,因此尋求有經驗的朋友或顧問的建議,倒是一個永遠不會吃虧的選項。






沈思:為什麼有價值的專案總是會遇到困難?
參考->解決軟體專案困境的最爛方式


12/14/2015

資訊系所學生就業 (三件值得注意的小事)


除了少部分往學術界持續邁進的人之外,畢業生遲早要就業。

但就過去數年面試新鮮人的情況來說,大部分的學生並沒有對就業有所準備。這似乎是理所當然,本來就不可能有充分準備,不然就不叫新鮮人。

而業界常常把問題放在學校並沒有充分"教育"學生該有的知識與技能,使得學界與軟體業界脫節。

這似乎也不是台灣單獨的問題,早在數年前有人在美國抱怨此事。而且類似的抱怨一直都沒停過,例如這裡。新鮮人面臨的困難,很多也都是像這些文章中一樣,是認知上的問題,例如:絕大部份的人,可能一開始只是會被要求做個小螺絲釘的工作。這和他幻想中,技術高超的程式設計師經過不眠不休的努力,就可以達成驚人的成就,然後改變這個世界有很大的不同。這裡有相關的認知現實描述。

因此一開始得先適應周圍環境,而大部份的學生畢業的時候(不管是哪個學校畢業)都須要先認知自己知識(或者常識)不足以適應環境。越有這種認知,適應的可能越快。

所以,以下是快要畢業,打算就業前,或者選擇公司的時候,建議學生先做好準備。

(1) 暫時不要看BBS,新聞,facebook一段時間。


PTT大概是台灣獨有的特殊環境,它很有趣,有時候資訊很快速。可是很遺憾的是隨著資訊量越來越多,他的正確性越來越差。如果你不是極端理性,意志堅定,很容易受到不良資訊的影響。如果可以的話,至少為期一個月。至於台製新聞跟facebook就更不用說了。


(2) 確實知道自己在搜尋什麼(當你打算google一下?)。


剛加入的新鮮人,特別是畢業於2008年之後的,在遇到困難的時候,一定習慣google。而google也很少讓人失望,通常都能找到某種答案。

但要注意的是,答案也許正確,但是資訊過於片面。日子一久,就很難獲得全面的視野。例如,查詢"android AsyncTask",如果你想要看中文資料,前幾個結果都會是某些人的blog,當然不是說這些人寫的一定不對,而是blog(特別是中文)常常是片面資訊,就算他好心貼上正確參考資料,可能也不會有人耐心查詢。對於中文閱讀者來說,最好是google之後自己找看看哪一個才是官方正確資訊。歹事,目前沒有中文的官方資料,api最好的參考是-> http://developer.android.com/intl/zh-tw/reference/android/os/AsyncTask.html

(3) 謹慎選擇工作 但更要謹慎選擇主管。


在台灣能夠選擇的工作實在太多,台灣優良的企業也很多。第一份工作,當你有難以決定的情況時,請謹慎擇一個好主管。

面試的時候,不只是面試者選擇你,而且你也必須要選擇面試者。當然如果面試你的人,不是你的主管,那這個公司等於是跟公家機關沒啥兩樣,不如乾脆去考公務員。


如何在面試的時候知道是不是好主管?

一個好主管能夠清楚地知道自己負責組織的真實情況,而夠培育員工,能夠掌握現實,並且能夠處理困難
。因此由詢問以下問題來判斷這個主管是不是個好主管:

  (a) 請主管描述自己未來1-3個月工作內容。


     如果講的比較含糊,可以單刀直入的問清楚。如果發現永遠都問不清楚,很有可能你進來這個公司的時候,發現這個主管無法控制組織前進的方向,做的工作和面試談的完全不同。要注意的是,工作的確一定要有彈性,以及隨時應變市場變化,但是市場的變化,不會讓一個新鮮人無法確定未來1-3個月的工作。而如果要靠一個到職不滿新鮮人來"負責"各類型的變化,那這個公司風險也太大了。

  (b) 請主管說明,上一次有新鮮人進來的時候,他是如何培育新人。

     同樣也是要清楚了解,是單純指派資深員工指導,還是有培育時程規劃,如果有規劃,可否讓你看一下,參考一下。當然也有可能上一次有新鮮人來的時候是10年前的往事,那就要考慮這個組織的老化性。

  (c) 請主管說明,當你來加入團隊的時候,他最有可能擔心哪件事情你做不好。


     這是要清楚了解,主管經過面試,對你有沒有清楚的認知,如果認知差距過大,那可能大有問題。舉例來說,如果你非常精熟java,但是並不熟悉Linux上的開發環境,在一個完全Linux的開發環境的團隊裡,如果主管認為你學習linux一定沒有困難,可以三天搞定,要不就是他不認清現實,要不就是你在面試中已經證明自己是天才。




沉思:


* 網路上的資訊很多,事實上無用的瑣碎的資訊,遠比切實的資訊來的多太多!短時間切斷資訊聯繫,對整理思緒有幫助嗎?






12/12/2015

工作太忙沒時間?改善的務實三步驟


圖片來源為Hakan Forss的部落格,要引用此圖需要連同其網址一起引用:http://hakanforss.wordpress.com


在資本主義社會下,有效率的工作是基本條件,但是在資訊科技的發展中,有效率的工作逐漸顯示人的本身才是無效率的源頭。這並不代表資訊科技的進步與有效性,這只是代表人扮演的不可取代價值。

人的價值在工作上會順帶產生工作的壓力,因為所有的企業都會要求成長,不只是企業的成長,還有個人的成長。

不過,無論如何,在你還沒有丟出辭呈,自己開創事業之前,最好的選擇永遠都是強化自己的能力,改善現況,為組織產生更多價值。

對於很忙碌的人而言,要改善現況最常的反應是:「每天都那麼忙,哪有時間做這個」「哎唷,講都麻很簡單,你又不是做我的工作」「我常跟老闆提啊,可是他都沒這麼做」。

這些理由都和明明知道運動有絕大的好處,但是卻會找理由無法持續運動的人一樣。其實只是心理不想去做,或者恐懼未知,或者不真心認為這很重要,因此都能事後找到很多藉口。

很多理由並非是藉口,「事情太忙沒有時間」可能是真的。但是,這可能是最容易,而且是最需要先解決的一件事情。

只要你不是以下職業類別:核電廠工程師,急診室醫護人員,駐守太空站人員,戰地記者,美國總統...。都可以透過以下三個務實的方式,改善「事情太忙沒有時間」。

這三個步驟,極其簡單,只要願意做,幾乎沒有做不到的可能。這三個步驟,沒有引用任何了不起的學問,也不具備任何學理基礎,它就是簡單到值得讓有心改善的人一試。
執行這三步驟的成本極端的低,但效果卻非常驚人。更重要的是,產生「有空時間」是充實並精進自己能力的最基本的一步。

三步驟為:記錄,分析,去除。

步驟一:紀錄


拿一本筆記本,或者excel檔案,或者googledoc,如果是手機app的狂熱者可以考慮使用Toggl。每天花5分鐘紀錄所有的工作花的時間,工作內容,工作價值區分,工作分類。如果可以的話,順便連生活的事物也一起記錄(例如通勤,睡覺等等)。

這個紀錄是給自己看的,所以不需要欺騙自己。

工作內容:當然就簡單記錄做什麼事情,軟體工程師大概就是寫程式,開會,處理email,與他人討論規格等等。

工作分類:根據組織本身的情況,因任務而給的分類,例如為了某A專案寫的程式,為了某B專案而開會,為了交接某C舊的軟體產品而開會等等。

工作價值區分:根據自己的想法,以重要不重要,緊急不緊急,將工作分成四個象限:重要而且緊急,重要而且不緊急,不重要而且緊急,不重要而且不緊急。

所花時間:可以是小時為單位,也可以是10分鐘為單位。但是,必須要是連續。換言之,不太可能有連續24小時的寫程式時間。因此最簡單的方式是有開始和結束時間。


再次強調紀錄必須簡單確實,紀錄本身不能太時間,不需要很精確。紀錄只會給自己看,千萬不要欺騙自己。

另外,這一步驟通常1個月就可以進行第二步驟。如果第二步驟的分析過程,讓你覺得有問題,那你需要額外的3個月的紀錄。換言之最多4個月的紀錄就足夠進行分析。



步驟二:分析


分析的本身是不難,把所有紀錄用excel加總分析,數字必須要是有總量和百分比。

第一要分析的是:工作價值區分。這些工作所佔的百分比,例如:

「不緊急而且不重要」: 50%
「不緊急而且重要」    : 15%
「緊急而且不重要」    : 20%
「緊急而且重要」        : 15%


在分析階段,最重要的是了解事實。而非改善事實。如果「不緊急而且不重要」+「緊急而且不重要」的時間比率,也就是所有不重要的工作比例,加起來低於60%,很有可能你沒有正確認知任務,或者是對自己說謊,或者是記錄的時間不夠長。因為這樣的事實是有違統計常理(參考資料)。

一旦了解事實,就可以往第三步邁進。不過分析的時候,可以順便注意一些事情:

(1)「緊急而且不重要」+「緊急而且重要」,也就是所有緊急工作的比例,加起來超過60%。表示幾種可能,一種可能是:你是長時間被工作逼著跑的人,你的任務幾乎都很緊急:老實說這個機率很低。另一種:你是自己認為工作會逼著你跑,你的任務幾乎都很緊急:這個機率比較高。

如果是"是長時間被工作逼著跑的人",使用流程,半自動化,轉移專注的方式是之後要考慮的重點。不過誠如前段所述,這種情況除了特殊職業之外,其實極端的少,大部份是屬於下一段的情況。

如果是"是自己認為工作會逼著你跑的人",先在記錄和分析上,重新正確分類事情才是能繼續往第三步驟前進。如果你真的認為所有事情都很重要,都很緊急,在心態上無法設定優先順序以及分類,那不管怎麼做都沒有人能幫得了你,本文的後段也不用再看了。

(2) 了解「緊急而且重要」「不緊急而且重要」的工作所含的工作分類。

也就是說,你能要試圖列出所有重要工作裡面,哪些緊急,哪些不緊急。而這些工作分類,這個階段,探討出:如何將緊急而且重要的工作的緊急因素去除。

(3) 「不緊急而且不重要」的工作分類。每個人多少都會去做這類事情。然而,如果你認為的工作的本身,幾乎統統屬於「不緊急而且不重要」的象限,那麼你可能對工作本身有很大的認知差距。

舉例來說,你可能是負責舊軟體產品的支援工程師,舊產品可能用戶少,營收少,也沒有未來的可能性,你直覺就會認為幾乎所有事情都不緊急而且不重要。首先,假如真是如此,那組織應該乾脆就會將舊產品汰除。舊產品仍然存在必有原因,可能是維持與舊客戶的關係,確保這些舊客戶滿意度,並且讓舊的客戶有機會試用新產品。因此,任何讓舊客戶滿意的事項,應該都屬於重要的範圍。



步驟三:去除


李小龍有很多名言,以下是其中最重要的一個:

One does not accumulate but eliminate. It is not daily increase but daily decrease. The height of cultivation always run to simplicity.

當已經知道事情的分類,意義,加總之後,並不是要著手去修改事務,而是先「去除」。

去除的本身最為困難,需要勇氣,知識,技術,經驗。

從最簡單的方向開始去除最容易。但在開始之前,一定要先確認"步驟二:分析"的結果是大致正確。

(1) 不做「不緊急而且不重要」的類型工作:不做這類型的工作,一旦發現這類型的事情出現:直接不做,不用多做考慮。不需要解釋,也不用感到慌張。

(2) 將「緊急而不重要」類型的工作,先行移轉,半自動化,或者流程化。「緊急」和「不重要」這兩者是某種程度的自相矛盾。但通常矛盾的產生在於,「緊急」先出現,可是你無法馬上判斷重不重要,直到完成任務之後,事後才知道重不重要。

這時候原有的記錄和分析就派上很大的用途。例如你是程式設計師,你的老闆常常打斷你的思慮,跑來問一些產品功能上的問題,說要給業務人員馬上回應。如果整個團隊都是這個情況,就會落入大家困於緊急但不重要的情況。移轉:指的是將這類的情況移轉到其他地方:或許是專門一個處理,或者外包給工讀生,或者是透過清楚地固定訓練,讓業務人員自己了解情況。

(3)將「緊急而重要」類型的工作,設定篩選。半自動化,或者流程化能簡單的重分類問題。例如急診室,所有進來急診室的人當然都是緊急且重要,但是,急診仍需篩選,護士會以最標準的流程,很快的評估進來的病人的緊急程度。讓真正緊急的事情能最快速處理。在軟體研發工程師,如果是在產品研發階段,幾乎不太可能遇到緊急而重要,有的話十之八九應該是天災人禍。因而,只要注意這類型的工作的區分正確與否即可。

(4)將處理「不緊急而且重要」的時間與價值提升。這點相當重要,不過並不是本文要討論的範圍。在此我們專注於”去除“

經過去除的過程,你會多出起碼少則20%,多則60%的空閒時間。


再次強調一下,這三步驟不是什麼秘密,也不需要用到高深的技巧,你僅需要對你的工作加以了解,並且執行正確即可。

人生唯一公平的地方只有時間,每個人每天都有24小時。有額外的時間,就能思索自己的未來,不會淪於找不到方向。

參考:如何提昇工作效率 





沈思:
轉移,流程化,半自動化似乎很重要?

11/26/2015

資訊新鮮人:三個關於價值的概念



亞當斯密,在國富論中描述商品的價值只有三種來源:勞力,土地,資本。雖然那是1776年的事情。但至今變化仍然不大。勞力:泛指人的各種智慧以及努力;土地:指的是各種天然資源;資本當然就是投入的錢。


村上春樹,在尋羊冒險記中描述組織的價值有兩個部分:意志,收割。雖然那是小說,而且還是現實與科幻混合的小說。意志是指推進組織的能力,具有統御可能性的能力;收割可能是指將即將得到的利益完成。



Dave Snowden,在他的研究裡面,定義了Cynefin架構,將事件的反應系統分成:簡單(simple),複合(complicated),複雜(complex),混亂(Chaotic)。

簡單:指的是事情的反應有很明確的因果關係定義,根據定義來做事情即可。

複合:指的是事情的反應之間,確實有因果關係,但是這個因果關係可以透過分析,學得而來。

複雜:指的是事情的反應之間,雖然有因果關係,但這因果關係沒辦法事先知道,只能事後知道。

混亂:指的是事情的反應之間,沒有因果關係。



這三個人講的事情看似沒關係,但是對於社會新鮮人對於價值的三個重要概念,卻是重要的參考。



(1) 何謂價值


幾乎任何東西都有價值,只是每個人評估價值的方式不一樣而已。在經濟學上最簡單的方式就是,你的某個東西,願意和別人交換什麼東西。那就是對你來說的價值。當然,交換太過麻煩,因此金錢變成一種簡單的衡量媒介。

在經濟學上常用價格來當作價值的衡量方式。不過價格本身就有很多種定義。

如果將範圍縮小到,投入資訊產業的新鮮人所關心的方向。價值可以縮小到:個人的智慧與努力,去交換某種東西。當然這某種東西很容易就被歸類為薪資,而如果是創業家則是利潤。

交換只有已經交換才有意義。因此,價值只有在交換成立的時候才有意義。例如,當新鮮人在104要求月薪5萬,這並不真的是他的價值,他的價值可能是4萬,也有可能是50萬,只有在成立的當下 - 也就是雙方同意月薪的那一瞬間 - 價值就成立了。所以,更重要的觀念是:價值沒有所謂的高與低,只有當時的事實。換言之,以價值的觀點來看,沒有過高的薪水,或者過低的薪水,只有雙方同意交換的成立價值。

當然,很多人互相同意的交換成立價值,就變成常見的成交價。股票某個時間點的價格,就是那個時間點的某一些股票的成交價,而非所有股票在那個時間點都是同一個價格。

最直接了當的說:如果覺得這薪水,對你來說太少,那就不要答應。但當你答應了某薪水,也不要抱怨 - 起碼在幾個月之內,沒什麼好抱怨的。而當你「自認」應該要提升價值時(就是該加薪了),必須要是有交換的可能,才叫做價值提升。(就是真有人願意以這樣的薪水雇用你)

價值當然可以互相比較,常聽人說性價比高還是低。然而不同事務交換的時候,比較的基準自然會不一樣。就此而言,在資訊科技產業的任何兩個程式設計師,都無法互相完整比較價值,因為兩個人的智慧勞動以及產出一定無法有效比較。

另外,同一件事情,在從不同人,不同時空背景取得,會有極大的價值差異。例如,你坐計程車上班會花錢,然而,如果在你搭車的時候剛好遇到同事,順道搭便車,他可能完全不會收你任何費用。



(2) 組織的價值產生


組織,特別是營利組織,其價值等於是可產出的商品(或服務)。而任何商品的價值來源有三種:勞力,土地,資本。由於資訊科技產業(特別是軟體)並沒有用到很特別的天然資源,因此土地幾乎可以排除。而勞力和資本就變成資訊產業最主要的價值產生來源。

資本的構成與取得也不那麼簡單,不過不在我們的討論範圍之內。當然政府政策的影響也不在這短短的文章討論範圍之內。

勞力當然包含智慧技能等等,而企業內員工對於工作的付出智慧與勞力的方向,大概可以分成Cynefin架構中的那四種。


簡單(simple):任何工作的行為是可以預知因果關係,必且可以透過各種手段最佳化,這些手段可能是由機器取代,可能無法由機器取代。例如銀行櫃台的大部份業務,都可以由ATM取代。某些日式的餐飲店,其服務流程經過妥善的最佳化,任何顧客的情境以及行為都可以編列在他們的制度與管理方式裡。因此,簡單類型的工作,可能產生最大價值在於能否提出最佳化。

複合(complicated):任何工作的因果關係可以透過分析與瞭解而取得。工作本身可能是困難的,但是工作的效率還是可以評量,工作的內容,可能需要少許技能,但也有可能需要很高的技能才能完成。這類型的工作,其價值高與低,取決人的能力,使用的工具,採用的策略技術。這類型的工作可以學習,但學習時間長短不一定。複合類型的工作,可能產生最大價值在於是否能提出好的架構,並且有訓練有素的專家。一般的程式設計師,維修瓦斯爐工程師,一般醫生,護士,理財專員等等都屬於此類。

複雜(complex):事件與工作的因果關係只能事後知道,無法在事前分析瞭解。然而,其因果關係仍然存在。聽起好像很複雜,然而這類型的工作,不見得很困難,只是要產生價值的時候,可能需要不停地進行嘗試與練習,才能事後了解因果關係,透過事後練習了解。例如,開一家新公司當創業家,獵人頭工作,業務類型工作,特殊類別的醫生,各類型的研究單位等等。

混亂(Chaotic):事件與工作沒有因果關係,或者就算有,也是人的智慧無法得知,藝術就是此一類型。這類型的工作可以透過學習,擴張知識,反覆練習獲得經驗,來提昇可能性。但是難以評量。例如,畢卡索的畫作,張大千的書法,可以由他學生們學習模仿,也無法就價值評量。在企業上常見的例子是賈伯斯,他對apple的貢獻無法被學習,也無法被評量。有人認為開拓性質的研發也算此類,例如具有極端價值的演算法工程師,組織微積分的牛頓,構思相對論的愛因斯坦等等。

當然在以上的例子非常粗略,只是拿來參考用。組織的價值產生,就在透過人的智慧與勞力,資本的投入用以執行四種系統架構的事物。這四種系統架構,其產生價值的地方都不盡相同。

但今天幾乎可以確定的是:(a) 簡單的工作會趨向被自動化方式取代,無法自動化(例如餐廳)則會被低勞力成本取代。(b) 複雜的工作,透過科技的進步會簡單化。(c) 混亂類型的工作仍然屬於個別人的天賦範圍,可以培養但無法預測。

因此,真正的組織價值,在於透過意志,驅動複雜工作的架構,屆此拉近因果關係的差距,以及建立相較於其他組織的優勢。


(3) 價值不公平的觀點


誠如"何謂價值"所描述。價值只有交換的時候才會成立,而既然雙方樂於交換,何來不公?

大部份的情況下,所謂樂於交換通常是在資訊互相全然透明的情況。然而資訊全然透明是幾乎不可能,因為人根本無法處理足夠大量的資料,也無法體驗所有可能的情況。例如,一個新鮮人,畢業之後最多也只能面試50家企業,不可能窮其心力面試完所有可能的工作。但反過來說,一個企業的工作(如果不是屬於「複雜」或者「混亂」類型)幾乎都可以找到起碼50個合格候選人。因而,由於資訊的不對等,大部份的情況下,企業比較容易可以找到性價比高的員工,但新鮮人比較難找到性價比高的工作。

換言之,以個人的角度,解決不公平的方式有很多種。從價值的觀點著手有兩個可能:

(a) 投入組織意志的部分。

投入職場的大企業的人,都不太可能一開始就是驅動組織經營策略的人。通常都是某個小部門的小螺絲釘。因而要成為組織意志的一部分是很難的。然而,如果是投入在小公司,假設是只有5個人,那麼投入組織的意志部分是非常輕而易舉的事情。

不在組織的意志部分,並非就沒有價值,而是在組織的意志部分,個人的能力與可產生價值很容易顯現 - 無論高或低,好與壞。

(b) 強化處理複雜或者混亂的問題的能力。

混亂的問題大部份是屬於藝術類型。藝術很多都是「無價」,因為無價,也難以在此討論。不過所有能處理混亂類型的人,幾乎都是在某一個領域知識廣博,經驗豐富。因此,不間斷的學習一定會有幫助。

處理複雜的問題可以透過自我能力的培養,經驗累積,從他人(例如職場導師)學習而來。複雜的問題相當困難,但是一旦累積了架構性解決的能力,這優勢幾乎不會消失。

(c) 將複合的問題簡化。

透過資訊科技,將複合的問題簡化,可能是最近幾年最常看到資訊科技對組織產生價值的地方。大數據(Big Data)對網路書店上推薦購書就數此類。許許多多不同的手機應用程式(app) ,提供人類各種溝通方式(例如line) 也是屬於此類型。


(d) 將簡單的問題加速或自動化,進而最佳化。

將簡單的問題加速或自動化,可能是資訊科技新鮮人常會忽略掉的一點,但這點其實對價值的提升比想像中來的重要許多,特別是在大組織內。加速或自動化處理簡單的問題,可以讓人專注於其他架構問題,縮短內部公文流程,自動記錄某些事件等等,都屬於此類。這做起來相當容易,而且假以時日效果也很好。

當事情或者問題可以自動化之後,進而就可以最佳化。例如,過去政府有複雜的公文簽核流程,在紙本的年代,很難統計看出真正的瓶頸,透過自動化公文傳遞,很快的看出到底哪些公文花多少時間流過哪些不必要重複的地方,進而就可以去掉不必要的地方。以開發手機APP的流程為例,當視覺設計師的mockup,可以自動產生可供UI/UX測試的可供驗證app時,就可以進而快速取得使用者操作的經驗流程,進而讓UI/UX能最佳化手機APP的使用便利。




將複合的問題簡單化,簡單的問題自動化,自動的事情最佳化:是最基本產生價值的概念。




沈思:
   - 資訊新鮮人能在多短的時間內對組織產生價值?