顯示具有 檢討 標籤的文章。 顯示所有文章
顯示具有 檢討 標籤的文章。 顯示所有文章

7/28/2016

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



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

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

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

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

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

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

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

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

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

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


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


1.  即時會議記錄:


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

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


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

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


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

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

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





2.  分析與設計:


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

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

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

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




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


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

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



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


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





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

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