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

11/24/2016

企業巫醫 - 如何拒絕或調整客戶不合理的需求




在各類型的軟體開發情境中,有時候開發人員會有機會面對客戶的需求。而最近就有一位研發團隊的工讀生,在即將離職時,問了一個經典的問題:

--------------
你們是如何拒絕或調整客戶不合理的需求?
--------------


問題的本身很經典,但是卻必須要追本溯源。

首先,需求(requirement)本身是很難被界定清楚,因為客戶也許也不能清楚的界定需求。Henry Ford 福特 - 福特汽車的創辦人,現代化造車的始祖 - 早在一百年前的名言,至今仍難屹立不搖:
--------------
“If I had asked people what they wanted, they would have said faster horses.”
"如果我問客戶要甚麼,他們會希望跑得更快的馬"
--------------


然而,「直接了當的詢問」仍然是基本的第一步。不過也要先確定問到正確的對象,問了正確的問題,正確地理解回答。透徹的了解問題,才能知道客戶的需求是不是真的不合理,抑或,其需求背後有另外的需求。接下來才能知道怎麼反應。

還沒經過深思熟慮就直接拒絕,很有可能是自己故作姿態,甚至是知識技能不足的表徵。(註一) 

反過來說,隨意「答應」客戶,風險也很驚人。因為也許答應了一件根本不應該做的事情,或者答應了一件其實客戶表達錯誤的事情。最悲哀的結果是雙輸:客戶與企業都受害,甚至三輸:客戶企業與社會三者都受害。

而這聽起來極端荒謬的事情,卻一直在企業界發生。


因為誤解客戶需求,或者不夠及時調整需求導致於雙輸的例子,在近20年內的有很多,隨便找一些範例如下:

* FoxMeyer的SAP引入案例(1,2)

* Waste的SAP引入案例

* 台灣戶政系統當機事件(1,2,3)




那到底要怎麼做?


1. 根據事實的正確溝通


抽象化的形容詞,對溝通不會有助益。

例如:「高可靠度的系統」「網路速度很快」「網站介面很好用」「滿足業務需求」「盡快完成」

抽象化的言語,在務實的書面報告中越少越好。當然某些摘要形式的報告,會很抽象,但隨後必定附上務實的參考依據。

例如:

「高可靠度系統」:已兩台伺服器互為備援的方式,達到高可靠度

「網路速度很快」:過去對外連線的速度是1MB,現在提高到1TB,因此網路速度很快。

「網站介面很好用」:過去每個月平均有150次客服電話,是在詢問網站某些功能要怎麼使用,現在每個月僅有10次。並且,每個月平均使用人數並沒有減少。


2. 透過具體內容決定接下來的執行事項



互相理解現在的情況是第一步。接下來要做什麼是第二步。

為什麼決定接下來要做什麼和「客戶不合理的需求」有關?

首先,合不合理的判斷本身就很難客觀。對某人來說不合理的事情,對另一個人可能完全正常。彼此價值觀的差異不可能在短時間彌平。但是「具體要做的下一個動作」卻是清晰可見,只要接下來的執行「事項」,確實都是雙方認為最重要的事項即可。

和第一段相同,具體內容必須是清晰可見的動作(action)

例如:

* 將第一批手機抽15%樣本共150隻,進行電池過度充電放電測試。並在N月N號之前,給出測試結果報告。

* 將iOS app送到apple-store進行上架審核。

* 在使用者帳號管理系統上,增加可以使用fb帳號登入的功能,在N月N號之前,給出設計文件。

不是清晰可見的動作,會造成很多不必要的誤解,而誤解就會產生不合理的需求。


不清晰的動作例子如下:

* 產線上的手機抽樣測試一下有沒有爆炸問題 -- (這是要多少樣本測試,一隻也可以嗎?要測試哪種類型的爆炸?太陽曬到玻璃破碎也算嗎?)

* 我們的iphone app要趕快上架了 -- (?是要上架到哪邊)

* 讓fb帳號也能登入系統  -- (是什麼時候要完成?只要登入就可以,細節我們自己決定就好了嗎?還是要先看一下設計文件)






3. 務實的密集檢討事實



這可能是最重要,但最被台灣企業所忽略,也最容易被企業巫醫上下其手的地方。

可參考這幾個地方:(a) 錯誤檢討,(b) 自我反省,(c) Scrum檢討


「務實」:指的是根據事實來檢討,而非根據感覺。即便是需求檢討也是。

例如:某中國企業要求網站系統必須能讓IE8使用。但是IE8上的javascript版本實在太舊,這樣的要求讓專案經理非常不高興,覺得根本不合理也太不可思議。

如果不務實檢討,那麼每次與客戶的會議,大概就在針鋒相對中度過。但是探究事實,其實是因為該企業內部系統無法擺脫WinXP,而又因為WinXP能使用的IE就是IE8,導致客戶有此需求。就網站廠商來說,當然不可能協助內部全面升級為Win10,但卻可以提供其他在WinXP上,仍然持續更新的瀏覽器(firefox)。


「密集」:指的是Scrum的精神。需要在一定時間(sprint)讓客戶看到,並且用到那段時間產出。確保客戶對團隊前進的方向是一致。也確保即便團隊方向有誤,也會在一定時間內被發現。

「事實」:有時候事實很難全面探究完整。有時候細節太多,即使都是正確的資訊也過於繁複。

巫醫在同樣的事實上,都會有不同的詮釋。例如:經過鞭打火烤病人之後,病人仍然掛了。巫醫的詮釋通常是:惡靈不願意離開病人,是天命所致。

而以「事實」詮釋「事實」才不是誤人一生的巫醫。當軟體開發團隊常常客戶不合理的需求。不應該隨隨便便將此視為「惡靈不願意離開,乃是天命」。而應該「改變」執行方式,應對不合理需求。如果巫醫不願意改變(註二),換一個醫生是根據事實最合理的方法。





註一:違法的需求,當然是要直接拒絕。這類型的基本常識,不在此討論範圍之內。
註二:如果巫醫很容易以事實說服,那就不是巫醫了

7/28/2016

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



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

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

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

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

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

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

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

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

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

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


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


1.  即時會議記錄:


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

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


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

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


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

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

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





2.  分析與設計:


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

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

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

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




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


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

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



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


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





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

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