顯示具有 資訊產業 標籤的文章。 顯示所有文章
顯示具有 資訊產業 標籤的文章。 顯示所有文章

3/13/2016

如何組成團隊:三個步驟





分工合作,是人類社會進步的主要原因之一,也是幾乎所有人類活動的基礎(參見國富論:第一篇第一章論分工)

新創公司,資訊產業也不例外,建立一個好的團隊,是擴展未來的主要關鍵。雖然好的團隊沒辦法保證生意蒸蒸日上,一切順心如意。但是一個糟糕的團隊,卻是可以保證企業和組織的失敗指日可待。


市面上團隊合作的企管叢書,方法論,激勵理論,顧問大師...很多。但就和所有的事情一樣,越是很多人在談論的事情,越是困難。成功的團隊真實例子極為罕見。

萬事起頭難,「組織並成立團隊」是達到成功團隊的第一要務。許多人常依賴運氣,或者隨遇而安的隨意組成團隊,但其實組織團隊是一種可以學習的艱深技術能力。

資訊相關工作的人,如果有機會能扮演組成團隊的角色,並有意識的學習其中,將會是個人成長的重要關鍵。(無論未來是朝純技術領導方向前進,抑或管理方向前進)


有很多原因,會讓一個人扮演組織團隊的角色。也許是一個新的專案,讓你來領導專案,而恰巧專案開始的時候沒有既定的人。也許你是新創企業的創始人,你打算聚集一些人來開發創新事業。也許你是資訊相關科系的學生,因為課程需要必須組織團隊完成專案。

不管如何,如果你有「從頭開始找人選人,組織團隊,完成某件事情的機會」,請衷心的痛哭流涕的感謝上帝,這樣的經驗,在資訊科技領域裡是十分難得。

通常,由於各種背景壓力,組成團隊的方式通常就是先根據需要N個人,然後「儘速」透過各種管道,找到可能的人選,經過正式面試,或者非正式的聊天,就逐一邀入加入此團隊。這種方式沒有不妥,只是這樣的方式(如果算是一種方式的話)有很大的成分依賴運氣。如果不想依賴運氣,其實需要考慮的實務步驟也不多。


以資訊相關工作為例,組成團隊必須要有以下三個步驟:


步驟一:定義目標

--- Your goal shouldn't be to buy players, your goal should be to buy wins. And in order to buy wins, you need to buy runs.   (MoneyBall)

定義目標,必須要在團隊開始組成之前,就先找到並且定義完成...最起碼是團隊差不多組成的時候就應該決定。

定義目標並不容易。

例如,以類似的資訊系統外包案而言,有些明顯的目標是「在成本內完成專案並驗收通過」或者「在期限內通過驗收」。但是,倘若一開始的合約是低價得標,而且還是業務亂搶合約,那麼一開始就已經知道不可能在時間成本內驗收通過。則團隊目標必須要轉換,例如「完成專案過程可順便完成重複利用的元件讓未來標案能大幅降低成本」。

大部分的資訊團隊真正的目標並非「技術達成」。例如,「完成iOS APP線上購物」這通常不是真正目標,真正目標通常是「在某移動通訊市場上,讓使用者可以線上購物」。

在營利企業裡,大部分的真正目標通常關聯到增加收入或者降低成本。而在非營利企業(例如研究單位)團隊的目標有可能非常模糊。例如,一個碩士班的實驗室團隊,他的目標可能是「培養人才」,也可能是「讓主持的教授獲得升遷的點數」。

定義目標雖然不容易,但掌握以下三點可以除去大部分的誤差:

(1) 定義目標後,審視檢查這個目標背後是否還有目標。例如,籃球比賽目標,某球員目標是得30分。但其背後還有個目標就是球隊要贏球。在球隊沒贏球的情況下得30分可能沒有意義。

(2) 定義目標後,檢視此目標是否只是某個大目標的一小部分。例如,某些NBA的球隊,會談論是進入季後賽的目標,然而背後的大目標其實應該是拿到總冠軍 - 無論有多艱難。

(3) 定義目標後,檢視此目標是否因為其他條件未達成就失去意義?這時候所謂「其他條件」或許可能是目標。例如,一個團隊負責營運線上購物網站,其目標是「網站每分鐘必須可以提供10萬個使用者同時進行交易,7x24服務不中斷不當機」。然而,若此線上交易網站平均上線交易人數每分鐘才1人,即便營運團隊達到技術目標,商業目標肯定無法達成,則此團隊目標也沒有太大意義。不如改成「與業務團隊合作線上行銷活動,讓每分鐘平均交易人數成長XX%」



步驟二:組合優勢


--- The greatest improvement in the productive powers of labour, and the greater part of the skill, dexterity, and judgment with which it is any where directed, or applied, seem to have been the effects of the division of labour. - (Adam Smith)

無論用什麼方式找到團隊成員,資訊相關的團隊必然有分工,而分工必須要能讓成員發揮相對優勢。而每個相對優勢,都可以達到步驟一的目標之一。

構成團隊過程可能很多,但無非是找到某人,詢問意見,在某時間此人加入。然而,「加入之後做什麼」著重於考慮組合優勢。

台灣經濟學的入門書通常會用蓋木屋與磚屋的例子(參見這裡)簡單的說,組織團隊時,把成員的時間投入在相對優勢的工作上,可以達到1+1>2的效果。

實務上,分工時請考慮一下三點:

(1) 根據相對優勢來分工:盡量只考慮優勢,而不是先考慮缺點。

(2) 分工的結果,還是必須朝「真正目標」前進

(3) 整個團隊需要了解分工與分派任務的原因 



步驟三:產生運轉動能

--- All things are difficult before they are easy.


團隊組織完成,要開始運作,不會像籃球比賽一樣,十個人在場上,裁判吹哨跳球就開始。

團隊前進需要累積動能。就像騎腳踏車一樣,從靜止到穩定前進,會花比較多力氣,然而一旦穩定前進,就很輕鬆。

產生動能指的是團隊成員已經彼此合作,彼此鏈結工作,發生問題也可以彼此協調解決。

以資訊科技為例:

最常見也是最糟糕的產生動能方法是由專案經理透過一連串的方式 - 通常就是開會 - 持續讓事情前進。團隊成員花在正式會議上的時間比例只要超過10%(也就是每週超過4小時)就屬於這種類型。


最佳,但是最罕見的產生動能的方式是由每個團隊成員,透過自身的判斷,做會讓事情前進的動作。類似足球或者美式足球的比賽。在資訊科技團隊中,這種組合需要時間磨合成員,而且也須一點點運氣,讓團隊的成員大部分的能力都可以足以某種程度的獨當一面。

如果你剛好是資訊科技/軟體開發的團隊領導者,至少要先避免最差方式,並且透過你的領導能力,讓團隊慢慢的朝向最佳的方式前進。

實務上有三個重點方式:

(1) 資訊透明:讓所有進行的事情透明的讓所有人取得。要注意,資訊透明指的是針對確定的事實透明。非確定的事實就是所謂謠言,要緊記:謠言止於智者,起於智障!

(2) Scrum中的豬雞原則:請參考這裡。在組織產生動能過程,豬負責的事情就由豬來決定,雞只是提供參考意見。

(3) 檢討 retrospective:需要團隊自我檢討任何不正確或可以強化的地方,檢討並非開批鬥大會,目的在於讓團隊能更有效率的,以及確保團隊真的朝向目標前進。




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/19/2015

軟體專案的啟動:三件必要事項



萬事起頭難,但是軟體專案的開始卻不很難,至少比收尾容易。


專案在開啟之前,相關人等必須一定要聚集在一起,至少達成一件事情:就是要討論專案如何開始。這個討論很多地方稱之為Kick-off會議。(專案啟動會議)。

在啟動會議結束前,就必須要能至少完成,或理解以下三件事情。如果不能完成或理解以下事項,當然還是可以開始。不過好的開始,雖然是成功的一半,但壞的開始,一定是失敗的八成。

要注意的是,這三件事情只是開始,並沒有涵蓋技術上的真正開始(例如High Level Design)

(1) 了解專案目的


一個軟體開發專案的目的,一定不會是完成某些程式碼功能。通常是帶有應用意義。瞭解其應用意義,才是真正的專案目的。在不了解專案目的的情況下,隨著專案進行走偏的機會很大。

舉例來說,也許某企業組織在一些腦力激盪之後,想要有自己的即時通訊app(類似line),並且也組織了一個小組來進行開發。而它的目的是希望企業員工在用手機的時候能有完整保密的訊息功能,而且非企業員工不可能使用。

單就以上描述而言,重點是在於(a)企業員工使用手機(b)完整保密的訊息估能(c)非企業員工不可能使用。

然而,是不是手機app並不是目的。是不是自己重頭到尾開發,還是利用現有套件也不是目的,有沒有上架也不是目的。

有些時候,專案目的不是這麼容易清楚了解,許多大組織有很多隱晦的目的。即便是人數極少的新創組織,有時候也容易把將組織目的和戰略執行方式混淆。因而,在專案啟動會議的時候,務必再三確認專案真正目的。

有一個簡單的方式可以判斷是否為真正目的。如果目的的描述,非常具體的指名特定技術,在盈利企業的專案裡,它就很有可能不是目的。舉例來說:『我們要開發一個Android APP他可以在開機的時候就自訂在背景執行,而且當發現手機的GPS位置到某一個範圍時,就寄出email』,這非常有可能不是真正的目的,而如果團隊照著進行,也許沒有大問題,但如果能真正了解目的,有可能有截然不同的開發方式。例如真正目的可能是:『我們是個高級西餐廳,需要一個行動裝置,了解某個之前的客戶,如果剛好在我們餐廳附近,我想們要通知他一些折扣訊息』。當目的和技術脫離,軟體團隊才會找到更正確地解決方式。以這個例子來說,寄email大概不是什麼好方法,在背景執行的app也遲早會被使用者發現過於浪費電而停掉。

專案目的也許隱晦,但是要再三確認,實務上也花不了多少時間。

(2) 專案設定


任何專案一定有其限制和背景因素。這些暫且叫做專案設定(setup/config)。

專案的限制有很多來源,有可能是先天限制,例如奧林匹克訂票系統,自然就有在某月某日結案的先天限制。也有可能是後天限制,例如最多能花多少經費。不過無論如何,一定有很多很多限制。在這一階段我們要了解的限制,最少要有以下這一點:在範圍,時間,成本這三個變項之中,哪一個是可以犧牲的。所有專案管理最基本的認知:範圍,時間,成本中一個專案最多只能控制兩個,細節可以參看這裡

當然有些人可能會列出6個變項,或甚至9個大項目。但重點不在有多少變項,重點在於專案的開始就要先有認知。

專案的重要背景因素,如果有的話,也需要先行認知。背景因素有可能是限制的一種,有可能和目的有關。例如,企業目前營運狀況極為良好,是一種背景因素,他可能會讓專案遇到困難時,有額外的助力。又例如,這個軟體專案是為了新產品,而目前,在市面上已經有競爭對手:這是一個可能在不預警的狀態下,改變專案目的或者增加專案限制的背景因素。

通常只要開口多問幾次,不需要花多少時間就可以了解很多專案設定。

(3) 如何合作

專案成員如何合作的方法論有很多,但最根本的概念就是,合作的本身,不會造成合作的困難。合作本身,能讓團隊效益提高,讓1+1>2。

(a) 認知事實

團隊活動有很多事實會發生,最不好的事實就是『大部份的人都有認知偏誤』。偏誤很難完全屏除,但盡量貼近事實是最好的做法。

事實最好在一開始就是大家所先認定好,特別是困難的事實。舉例來說,專案有三個人,其中兩人才剛畢業,另一個人已經在公司工作35年,事實就是一定會有溝通障礙,技術銜接障礙等等。另一個例子:專案有三個人,其中一個人正在負責其他專案,一旦認知到這點,就一定要把此人在專案未來時間分配上,特別減少某個比率。而這減少的比率應該在這個階段就已經先認知。


(b)角色定義

許多專案管理的方法論,會對角色有各式各樣的定義,例如RACI,PMP都有各自的角色定義。然而,也許比較適合軟體專案的還是Scrum的定義。

但不管採用什麼方法論,至少有個角色一定要有明確的指名。那就是這個專案的負責人,無論是叫他PM也好,team leader也好。明確地找出這個人,讓他負責專案合作上的各種安排。

(c)工具

而軟體專案最少的必要使用工具也要在這裡簡單定義。例如使用git來作為版本控管工具,簡單的使用便利貼加上白板來作為目前進度顯示的工具。工具不見得要是某軟體,在專案執行過程中,要確定工具的本身不會變成專案的負擔,不會變成阻礙,不會耗費過多時間,更重要的是,一定不能成為某些事情的藉口。如果在專案過程中聽到有人反應:『XXX還沒做,是因為build server要執行編譯android的時候,』因此過多的指定工具只會造成問題。

(d)溝通

專案溝通最好還是以面對面為主,我個人是非常反對大型報告會議,但是非常贊成Scrum的每日站立會議的務實方式。每日站立會議作法是:每天固定某一個時間,大家聚在一個地方,每人用1-3分鐘的時間,只說明三件事情(要記得大家先說明,然後要討論是說明完之後再討論):

   第一:上次會議到現在為止,完成了什麼事情。

   第二:接下來到下次會議之前,打算完成什麼。

   第三:遇到什麼困難。

所有人都說明完畢之後,再根據每個人遇到的困難,也許是一起討論,也許只有某幾個人討論。這樣的會議,會讓大家集中心力在之前決定好要完成的事項上,而且有兩個人在會議室裡面相談甚歡15分鐘,其他人都在看自己的筆電的情況。

如何合作有可能是最花時間去討論的項目。採用過去成功經驗,摒除失敗的經驗是最好的方式。



以上三件事情在大型專案中,也許頂多花上一兩天的時間就可以完成。最不值得做的,就是因為『乍看之下專案好像很急』而草草啟動,忽略了這三個必要事項。



沈思


如何知道這三件必要事項有產生?這三件必要的事情完成後,應該有相對應的簡要文件。如果專案開始的時候,沒有簡單的一頁說明以上三件事情,恐怕表示大家沒有真正的共識,或者這些共識很快就遺忘。

但是相對的,假如在這個階段,就已經產生了鉅細彌遺地各類型文件,那麼專案成員也應該要警覺。帶領專案者,可能有很大的管理上的障礙或疑慮。也有可能這個專案的真正目的和實際上說明的不同。










11/16/2015

創新公司軟體專案時程管理 (三個基本概念)




絕大部份創新公司,其實在衡量任何事情的時候,其所消耗的標準,並不是真正的金錢,而是創業夥伴們的時間。

每個人一天只有24小時,雖然今年是2015了,但是你還是不可能有時光車讓你爭取更多的時間。因此,專案的時程管理變得很重要。

時間管理的技巧方法很多,如果沒有概念可以先參考這裡。但最好先建立一些基本的觀念:

(1) 觀念一:每個人的時間效率有天壤之別


特別是技術類型公司,單指寫程式的效率來說,最好的程式設計師,和最差的有很大的差距。有些研究說是10倍,有些說是上百倍。

不只是程式設計,其他工作類型也一樣。更有甚者,品質的產出也被證實和速度沒有很大的關係。換言之,又快又好是絕對有可能的。

(2) 觀念二:每個人時間的比較利益不同,因此可以分工


那麼,這樣來說我們雇用三個強人不就搞定一切事情了?首先你不可能有機會在一開始找到三個強人,因為強人早就已經有非常好的工作。就算你運氣好到不行,真的雇用了三個強人,有趣的工作可能只有一個,也不可能三個人做同一件事情。

所以分工變得很重要。比較利益法則(參見wiki)解釋了為什麼多人合作有可能1+1>2。只要大家負責的部份,是相對其他人比較專長的部份。

不過分工是否得當,會有相當大的差距。在超大型組織裡面,以現代科技發展的程度而言,分工會自然發現,即便沒有效率也會發生,例如,任何開發中國家,經濟發展的時候,投入初級產業(農林漁牧)的人自然就會慢慢變少,換言之,只要少數人的努力就可以提供食物給其他人,而其他人就可以去做更多讓生活更愉快的事情。

但是在小型組織,例如只有5個人的startup,就必須要時常檢視這樣的分工是否合理,能否達到綜效。


(3) 觀念三:中短期的專案,其完成時間早就已經固定

一個為期1-5個月的專案,當目標和資源已經定義出來的時候,其實完成的時間早就已經被上帝決定好了。問題在於,創業夥伴們,能不能事先看出來。如果一開始對時間的估計有誤,接下來新的專案就要把失誤考慮進去。

對,沒錯這就是Agile/Scrum的基本要素,無論什麼理由,當你打算完成的事情決定好產出的目標之後,時間早就已經被決定,你能夠做的就只是盡自己的能力,縮短預測的失誤,而經過幾次中短期專案,理論上,創業夥伴們的能力和資源調配方式,已經讓大家可以準確預測完成的時間。



越是能了解時間的控制,就越不被時間控制。



沉思:


考慮以下說明:時間基本觀念很重要,因為創新公司,事情完成度是以時間來衡量,而不是以事情的進展來衡量。為什麼呢?


11/05/2015

選擇跨國委外開發商的務實流程:三個要點





不管委外開發什麼東西,東西有多複雜,時間有多長,正確的選擇委外廠商就等於成功了一半。

會使用委外開發的目的一定涵蓋兩點:

(a) 讓組織專注在重要的事情,
(b)成本效益。換言之,選擇委外開發的廠商或個人,也至少要涵蓋這兩點。

而對於新創公司來說,委外還有另一點優勢:就是

(c)迫使你自己更瞭解自己在做的事情

因為你需要完整的把細節用文件簡要說明清楚。如果你自己沒辦法把事情說明清楚,那麼不用說無法委外,你可能根本無法有效率的創業。這樣的創業只會讓你日以繼夜的努力,卻事倍功半,就算成功也是運氣成份居多。

在做任何選擇的時候,都要把握20/80法則,也就是用最省時間方式,確認最多關鍵成功因素。建議使用以下三個實際要點:

(1) 要點一:要確定理解規格


確認理解規格,很多人以為是外包商的責任,其實應該是業主的責任。因為業主不應該雇用一個不理解規格的人!換言之,業主要能在委外活動開始之前,確定外包商能理解規格。

這點聽起來很直覺簡單,簡單到就像大家都知道不能闖紅燈,上班不能遲到,開車不能喝酒,寫程式應該要有Unit Test一樣。可是實務上就是有很多人做不到。

根據經驗,所有外包的失敗,有起碼75%的源頭,可以追溯到對規格的不理解。因此確定外包商理解規格才能外包是第一要務。

那要怎麼在還沒簽約前,確認外包商理解規格?

用電話/email問他:Do you understand the spec?然後他會回答:Yes。....這做法是100%完全沒用。

請他看完規格書之後,問他一下:Do you have any question。然後他會回答:No。...這做法一樣100%沒用。

另外,規格也要對QA稍作定義,倒是不需要洋洋灑灑列出421的test case,只要簡要的把最重要的幾個使用者行為定義清楚即可。

最簡單的作法是用過濾刪選。實務作法如下:

1. 篩選掉不認真看文件的。


首先在發標之前,先把規格簡單的描述一下。然後在文件的中後段,穿插一句話:If you see this, please add the secret code "Bravo" in your proposal。這個目的很簡單,就是要刪掉,連看都不看就想要來投標的人。因為透過網站來投標的成本很低,所以有很大的機會亂槍打鳥。要投標的人,一定會提供proposal,而實務經驗來說10個來投標的,竟然只有5個有真的看文件,並且把Bravo這個字眼放在proposal的第一行。

換言之!用一個簡單的方法,就可以篩選掉一半根本沒認真看文件的人。沒認真看基本說明的人,可能壓根錯估時間跟成本,萬一選到這樣的外包商,最後吃虧的一定是業主。


2. 篩選掉無法回答三個技術問題的。


準備三個簡單但是重要的問題,讓外包商回答。舉例如下:

(a) Did you use dynamodb (aws) if you did, let me know why you use it.

(b) Please simply describe how to let android app use fb login.

(c) what is the most difficult things on our specification?


依照這三個問題的回答,業主很快可以判斷,剩下來個5個之中,哪些對於要做的事情比較有信心,哪些是完全沒信心。


3. 篩選掉估計時間不合理的。


前兩個問題都通過之後,就請剩下來的人估計時間。這時候估計的時間,請他要給完成的時間點,而非要花多少天完成。外包商花多久時間,多少人力完成,其實業主不會需要知道,也不可能知道。然而,業主需要知道,幾月幾號幾點,會取得什麼樣的東西。

如果完成的時間本來就預期很長 - 所謂很長是指超過2週。就應該請外包商分里程碑(milestone)分階段產出,分階段驗收完成。時間估計不合理的長或者不合理的短都會有問題。但是,在這個階段倒是可以多花幾分鐘,了解問題在哪?例如也許是他剛剛好這禮拜要畢業,準備畢業考試之類的?有些時間的延宕是可以接受,但是一定要知道原因。


以上三個篩選步驟都很簡單,任何複雜的專案,都只需要花15-20分鐘就可以完成上面三件事情。但是這三步驟絕對會讓你節省不少寶貴時間。

另外強調一下。規格不在於細節,所以鉅細彌遺地250頁規格書一定也沒用。不如一個兩頁的精要版。


(2) 要點二:要確定目標


讓外包商理解目標,以及確定外包商理解目標,也是業主的責任。

所謂的目標是指,根據規格完成的東西的真正意義。例如,規格書上詳述要完成一個android APP,並且可以用fb login,並且可以記錄帳款...等等內容。但是,所謂真正目標可能是:必須要在某月某日之前,讓具有某些功能的APP上線,並且可供使用者免費下載。這目標的確和規格書一樣,但通常規格書沒辦法表達優先順序,以及真正的完成,以此例子來說真正的完成是要放到google play上線通過。

當選定外包商之後,一定要花20分鐘,以電話或者視訊溝通這次外包的真正目的,而規格書是達到真正目的的最大參考,可是規格書本身不是目的。這點一定要說明清楚。

(3) 要點三:要有plan-B


選擇委外開發,通常不會是把核心項目委外開發。因此,理論上外包失敗應該不會有滅絕性的結果。

所謂的Plan-B就是要有外包失敗的計畫。Plan-B類似危機管理(Risk Management)不過遠比危機管理簡單,它只需要知道:外包失敗的結果,以及如何因應。


1.  定義何謂失敗:


首先一定訂清楚定義何謂失敗,每次外包行為只有失敗跟成功兩種,沒有中間的。模糊不清的選項只會讓事情變得更複雜。以前述APP開發為例,所謂成功指的就是在某月某日之前,具有某功能的APP上線,並且通過所有定義好的當初簡要的QA測試。所謂失敗指的就是不滿足成功的所有條件。換言之,失敗不見得我們就不付給外包商費用,有可能外包商分階段完成,但最後完成的日期比預期晚,那仍然是失敗。


2. 失敗如何因應:


一但確定失敗,就一定要用預設因應方式。以前述例子來說,因應方式可能有很多種。

例如,雖然功能都可完成,QA測試也沒問題,可是已經確定無法準時上線。所以因應方式就是把計畫往後推延N天。然而,這個N天必須要是事先定義好。不能是當失敗發生才定義。原因在於,唯有事先定義好的失敗處理,才不會讓其他事情跟著失敗,如同骨牌一樣,一路倒個沒完,那就等於是把核心關鍵任務外包。因為延宕N天是事先定義好,換言之,其他事項早就已經把N天計算進去,因而這個N天就變成無關緊要。

然而,如果不是時間,而是外包商倒閉,或者壓根就消失,當然就要啟動重新委外行動。一樣會延宕N天。這N天,一樣也是必須事先定義好。

換言之,失敗因應其實都和時間有關係。當然和外包成本也有關係,只是通常這樣的外包最後真正付出金錢損失通常不大,因為現行的外包平台大部份的情況下,都會保障業主不會付出冤枉錢。反倒時間與精神損失才是重點。


這三個要點,無論專案有多麼大,有多複雜,都可以在1.5個小時之內完成。根據我們過去N次規模不同的外包經驗來說,採用簡單的三要點作法,讓我們自己將外包成功率從30%提高到90%。







11/04/2015

email服務的市場:三個其他選項。




對很多台灣學生而言,email似乎不再是有趣的地方。因為email成為生活中一個簡單的存在。一旦考慮需要有自己的email而不用學校的email,幾乎就直接使用gmail。在組織過去三年的面試投遞履歷表中,幾乎沒看過用其他email服務的。

這點其實很可惜,因為這個世界上曾經存在很多有趣的email服務。直到今天還是。

email是Internet最早的應用之一。但其實在還沒有Internet(TCP/IP)的時候,email早就以各種不同的hosting形式,運行在各種早期商業電腦上。當然,主要是以商務應用為主。

在還沒有gmail之前,email通常是由某組織提供,免費的email服務雖然存在(例如yahoo, hotmail)但是限制很多,更有甚者,大部分的人似乎仍然傾向pops/smtp的收信方式,把email留在自己的硬碟裡面。

email服務在gmail推出之後成為一個轉淚點,在剛推出的時候提供1G的免費空間,現在一直在增大中,後來也導致yahoo乾脆推出1T免費空間的email。

現在,如同各種所謂cloud服務一樣,越來越多人不再將email存在自己的硬碟。而也讓email市場突然之間開闊了起來,企業組織(特別是中小型)再也不需要自己管理email server。

如果資訊產業的學生,在畢業前如果只知道自己學校的email和gmail,是非常可惜的。再此簡單的介紹三個其他較為不常見的選項(yahoo, hotmail在台灣比較常見就不多說了):

(1) yandex.com


最近似乎也有幾篇文章在介紹yandex。它等同是俄羅斯的百度。yandex是斯拉夫語系最大的搜尋引擎,也提供了雲端儲存以及email服務。它的免費email空間有10G而且似乎在增大中。從台灣連線竟然沒有想像中的慢,所以拿來作為自動備份是不錯的選項。

yandex似乎也很在意介面的顏色跟背景,所以三不五時會幫你換一個背景照片,大部分的照片是來自俄羅斯的都市。

如果使用它的email服務,大概就會順便看一下它的雲端儲存(disk yandex)。其實和googledoc很像,只是沒辦法線上編輯文件。不過,某些不知名的原因,yandex竟然強調可以線上修圖!
yandex線上修圖


順道一提,單用javascript就做到線上,並且還能支援相當不錯的離線編輯的,截至今天(Nov/2015)為止只有googledoc。


(2) mail.com

這公司存在市場很久了,不過在台灣也鮮少聽到人在用。光是mail.com這個網址應該就值很多錢,所以可以想見它對email的專注程度。

mail.com有很多創意,例如它應該是最早推出無限制的免費email空間。然而,只有收費版本,才會讓你由pop3/smtp收信,並且才會拿掉廣告。它的收費版本一年600元台幣。

同樣的mail.com也提供雲端儲存服務,免費版本只有2G的空間,不過可以預見會逐漸擴大。

其實,個人最喜歡mail.com的是可以選擇很多不同的domain name。而且是免費的。

舉例來說,如果你的名字是edward,但早就被人註冊走了,所以你不得不用edward212@mail.com註冊。可是,在你註冊成功之後,mail.com有上百個不同的網址(domain name)可以讓你額外附加,例如asia.com, usa.com, consultant.com等等,並且在附加的過程,你可以嘗試看看edward是不是還沒有人用。由於domain選項超級多,所以讓你選到喜歡的名字的機會極大。

個人最喜歡的是post.com,專門用來撰寫文章以及投稿。

如果是技術宅,不妨試試null.net?自開診所的醫生也可以嘗試看看dr.com?總之,拜託不要再用ms93.hinet.net來當自己的email了。

(3) zoho.com

從名字大概可以猜得出來是給soho族使用。

沒錯,他專注於提供中小企業服務。申請好帳號之後,基本上不只有email可以使用,另外還有類似googledoc的整套服務。他的線上編輯功能,是大概googledoc以外最完整的。另外還有一整套CRM服務,以及雲端檔案儲存空間。

他的免費版本的email空間是5G,另加5G雲端檔案儲存。相較於其他免費的服務是很小。不過大部分的人會用zoho通常是為了購買網址之後,將網址的mail由zoho來管理。舉例來說,如果你註冊了shop.com,就可以透過dns設定,把mail轉交給zoho的帳號,所以你就可以在zoho使用ceo@shop.com來收你的email。免費的版本只能處理10個email帳號。收費版本就無此限制。

個人最喜歡的就是zoho.com對於domain name的支援。因為通常這樣的dns設定在其他地方都是要收費的(例如googleapp)。如果你考慮自己創業,zoho可能是市面上最好的選擇之一。目前最大的競爭對手應該是bitrix24(yandex的分支),不過zoho還是佔具比較大的市場。


網路免費服務有很多,對於一般使用者來說,快速找到一個簡單好用,對自己有利的大概就夠了。但是對於資訊產業的學生而言,多嘗試一些新事物,才不會侷限自己的思考。




沉思:


* 這感覺上好像單純在批評,但是考慮到交通部仍然是中華電信最大的股東(參考這裡) 也就是說,中華電信資產等於是全民的資產,所以還是得來批評一下:

   (1) 作為一個ISP,感覺上提供email是某種為民服務,但現在到底還有多少人還在用中華電信的ms14.hinet.net的email?hinet.net前面的msXX這個數字,在今天作為負載平衡根本沒有任何意義。只是浪費大家打字時間。

   (2) 作為商用email服務,現行的價格實在很荒謬,大概只有不上網搜尋資訊的人,才會使用每個月至少1500台幣的有限email服務。這個服務不但貴的嚇人,可儲存量也驚人的少,竟然少到和bitrix24.com免費版本差不多。



10/27/2015

委外(outsourcing)軟體開發的三個要點



委外開發outsourcing行之有年,它只是另一種形式的分工方式。

然而,委外的軟體開發,卻是困難異常。即便是簡單的網站設計,不複雜的智慧手機程式(app),在缺乏正確的溝通認知情況下,還是有可能以意想不到的結果。如果你的專案經理,或者是負責與外包商溝通的人,以下是你最少需要知道的要點。對於不了解的事情,有些時候可以用嘗試的方式學習經驗,但很多時候最好還是參考一下過來人的經驗。

這三個要點,是在已經透過正確的方法選到正確的廠商的前提下。如果還不知道怎麼選擇正確廠商,可參見這裡。


(1) 知道這次外包想要的結果是要什麼


作為專案負責人,你需要知道期待的外包的結果。

假設所有的軟體開發,都是外包商進行,那表示你必須期待外包商有負責管理整件事情

所謂的整件事情,是從設計,細部設計,定義管理的方法(例如Scrum, agile),程式碼版本管理(例如github),測試,檢查驗收。換言之,雖然你不負責整件事情,但是你卻要比外包商更了解,這整件事情要怎麼處理。這樣你才能有效控制外包結果。

當然如果外包的範圍很小,例如繪製android logo,那麼你只要確定外包廠商知道android logo有哪些尺寸與標準,約定好時間,就可以等著看結果。

如果外包的範圍中等,例如處理前端網頁javascript以及html部分,但是需要存取後端的API,而後端API是核心任務,因此是內部自行開發。那麼就要界定清楚範圍,你需要能完整提供API文件,不然至少要有API簡單的訓練課程,以及範例程式。由於開發活動必須有一致性,因此還得提供廠商版本控制系統的權限(例如gitbucket),另外還需要控制開發週期,以及哪些使用者功能(user story)需要先完成,哪些後完成。換言之,如果外包範圍是軟體開發的一部分,那有可能關鍵的結果在於某段程式的正確產出。

(2) 清楚說明規格


在台灣對規格書(spec)其實不那麼重視。尤其是所謂的系統整合商的IT專案。因為有太多情況,規格和最後實際的結果已經截然不同,而規格書很有可能是一邊開發,一邊才跟著寫。根本不切實際,最後都淪為最菜的SA所負責最無聊的工作。

清楚說明規格並不代表要有250頁這麼厚的規格書。而是要有在做重要的事情上,有不可否定的結果。舉例來說,google.com的搜尋畫面,其實也有很多功能,但是必有一個規格是:一個讓人輸入資訊的欄位,並且按下enter之後會直接進行搜尋。某些SA/PM在撰寫規格時會無窮盡的增列細節,例如欄位是要多寬,最多輸入多少字元,反斜線要不要處理,諸如此類。當然重要的規格細節要詳述,但是不能無止盡的窮數之。

對於規格書沒有基本認知的話,可以先參考這裏

已經有很多撰寫規格書的經驗,但自覺從來沒寫對的話,可以參考這裏。這個spec只有短短20頁,去頭去尾真正的spec可能只有17頁,他沒有很多細節,也沒有用很複雜的UML圖。而且spec徹底與實作方式無關。

(3) 確定對方理解什麼


這點聽起來很不可思議。但是在現實,實在常常發生。那就是即便語言上沒有問題,在溝通認知上,還是有極大的差距。有些幫助有效會議的技巧,通常會提到,會議結束的時候,請最重要的幾個人,用很短的時間,簡單說明會議之後他要去做的事情。如果在一個常常進行無聊會議的組織裡面,可能會有很戲劇性,很荒謬的效果。(請參見"開會開到死")

對委外開發而言,很多時候不是面對面的會議,再加上語言的不同,更容易產生誤會。執行者(就是外包商負責人)必須要有創意的使用結構性合理的方式,來讓彼此理解工作內容。

首先,使用文件是最合理的。尤其是對跨國廠商而言。而文件的長短與格式並不是重點,重點在於有沒有表達你要傳達的資訊。

更有甚者,文件常常有先後次序,你需要知道外包商到底有沒有看那份最重要的文件。

一個簡單的作法是:在最重要的文件(例如規格書Spec)的莫約3/4處,夾一段文字,說如果你看到這份文字,要立即email給某人,並且夾帶一段簡單的"口令",因為這可以證明他有認真看過,如果在X月X日前,沒有回覆給某人,你會假設他無法完成第一個milestone。

這個作法不管在第一次有沒有達到目的,接下來外包商自然就自動被訓練為,你的重要文件,他一定會看。

管理委外廠商有很多創意的作法。可惜的是,這些作法必須根據靠經驗和實際情況而改變與適應。很難光是用教學的方式就體會。





參考:

* 虛擬助理




10/26/2015

務實專案管理(FLA)的三個重點...(從team leader的角度)

軟體工程與專案管理的方法論以及參考書籍非常多,無論是最傳統的PMP,到近幾年強調的Agile, Extreme programming,以及創新公司最常用的Scrum,這些方法都不外乎希望能盡可能圓滿達成專案目標。

而越後面產生的方法論,似乎都盡量想要化繁為簡,貼近事實,以便彈性的因應改變。例如Scrum就是將需求變更控制在sprint開始或結束,並且讓每個短暫的sprint(3-5週)可以專心於現在的計劃,改變於是乎就受到控制。

專案經理的角色和技術領導相輔相成,只是目的截然不同。專案經理最終的目的其實是”管理利害關係人的期望” (Manage stakeholder expectations)。實務上,這個目的甚至比專案在時間成本內達成來的重要。

技術領導雖然不是專案經理,但實務上,技術領導的小團隊是專案執行的最適切單位,因而技術團隊領導者也是反映真實狀況的適切人選。

技術領導當然不見得一定需要知道專案管理的細節,然而在軟體專案的執行中,技術領導者瞭解得越多,越能讓專案有機會成功。瞭解得越少,越容易受困於專案管理的本身。

(參考案例一)

專案經理(PM)在專案一開始就召集所有分析師(兼為小組長)進行傳統的WBS製作,完成了一份洋洋灑灑專案管理文件。在缺乏專案管理的知識下,三個月後在專案中期,某小組長發現有很多事情其實未列在WBS中,他就很掙扎要照常繼續回報列出來的項目?還是要重新修改WBS?

(1) 萬事起頭難:起初,專案計劃


作計劃這件事很重要,相關的名言也很多:
  • 廟算者勝,得算多也;未戰而廟算不勝者,得算少也;多算勝,少算不勝,而況於無算乎。
  • A goal without a plan is just a wish
  • Fail to plan, plan to fail
  • Plans are of little importance, but planning is essential.
  • You can't predict the future, but you can plan for it
  • The general who loses a battle makes but few calculations beforehand
  • Planning is everything. Plans are nothing!


任何專案管理方法論都會涵蓋”做計畫”(planning)這件事情,原因也很簡單因為這實在太重要。可是也太容易被忽略誤解或輕視

無論任務範圍大小,多寡,範圍,一個適切的”文字化計劃”對於軟體專案絕對重要!特別是有任務是整個團隊曾經執行過類似的,”原則上”只要根據以前的經驗”照著作”就可以達成,這種特別容易被資深員工忽略的任務特別容易出錯,更何況”照著作”等於是打算重覆過去的經驗,而不是打一開始就意圖要精進。

忽略:"現在時間很急迫,不趕快做來不急,就不先搞計劃了"

越是急迫的事情越不能出錯,減少出錯的最基本方式就是先行計劃。更重要的是簡單的思考整件事情,並且寫下來,適事情大小,不但不花太多時間,而且最能降低的風險以及未來避免浪費時間來修正錯誤。

誤解:"作計劃要花很多時間"

一個複雜的任務絕對需要花時間計劃。但是一個簡單的任務,可能只需要花15分鐘把心裡想做的事情簡單地寫下來。這個過程就可能會讓團隊避免發生前述案例中無聊的錯誤和不必要的問題。

輕視:"作計劃是給老闆看的,反正事情都不是照計劃進行,計劃對我們沒有用"

這種想法跟不打算作計劃完全一樣。等同於靠運氣跟個人當時心情來決定最後任務的好壞。

做計畫並非僵化,計劃的本身形式也不拘,一個簡單的心智圖(mindmap)就可以整理思緒 揭露許多未來的可能性。

下圖是本文撰寫的第一個計畫,可以和最後的結果比較看看,雖然粗糙,而且之後順序以及結構也有很大的改變,但是計劃的本身卻是很簡單可以引領思考。


 

(參考案例二):

有個售前支援團隊,與各國業務長久一起合作習慣了,常常四處進行軟體產品展示任務。有一天得到通知要去東南亞某國家進行安裝測試,大家都以為當地業務會大致把前置作業搞定,因此就迅速訂機票出發。到現場才發現,客戶負責的技術人員當天根本就沒來上班!整個作業只好延宕一天。



任務分配

團隊合作必然涵蓋工作分配。在資訊科技領域中,分配的方式也有很多種。而對於一個團隊的技術領導者而言。當已經對自己以及團隊的能力有基礎認知之後,有效的工作分配是一開始就要先計劃的事情之一。

技術領導者必然是已經瞭解自己也大致瞭解團隊能力,同時也瞭解任務內容之後,才能進行計畫任務分配。任務分配可以是團隊所有人一起討論,也可以技術領導者自行決定,但無論如何一定要先考慮團隊成員能力彼此之間的比較利益。

比較利益法則最早出現在經濟學鼻祖大作國富論的第一章(亞當斯密,1776)。衍生的,基本概念很簡單,只要有效分配,任何情況下都可以達到1+1>2的效果,即便專案成員某些人明顯地比其他人能力還差。

(2) 專案專案執行中面臨的問題

專案執行面臨的問題 - 人的偏誤


人類判斷事情會先採用快速直覺,這乃是上百萬年來的演化,無論是視覺上還是意識上皆是如此。以下簡單列出常見的人類認知偏誤:


歸因謬誤(Attribution Biases): 

解釋別人的事情時,會傾向別人的內在因素,解釋自己的事情時,會傾向外在因素。例如:會議有別人遲到,心裡會想這是這個人紀律問題,沒志力起床。自己遲到,會解釋是因為交通問題,昨天事情太多太晚睡。


錨定效應(Anchoring):

有參考點或第一次接受的訊息時,會過度偏重參考點。例如某地區最近賣出的房價是一坪100萬,則臨近的房子無論好壞,預售價格為一坪50萬時就會被認為"很便宜",即便一坪50萬對絕大部分的受薪階級來說還是貴得要命。


沈沒成本(Sunk Cost):

過去已經付出去的,不管未來的選項如何,其成本都不會變。也就是說不同的選項無關過去的成本,只關係未來。例如當已經花錢買了張電影票,但是臨時聽說同一時間有某明星簽名活動。這時候有兩個選項,一個是繼續看電影,另一個是去參加喜歡的明星的簽名活動。無論是哪個選項,其該電影院票價成本都是存在,因為錢已經花下去。換言之,要考慮的只是,現在看這個電影是不是比得到喜歡明星的簽名重要,而不是考慮如果去參加簽名活動會損失電影票的錢。


過度自信(Over confidence):

人類對於評估自己的能力時都會過度自信。例如,在一個50個人班級裡面,所有人自我評估考試成績的"名次平均"在技術上說應該是25,但是通常自評估的平均值都會遠小於25。也就是大部分的人都會高估自己的能力。


羊群效應(Herding Effect):

在團體中,個別成員會不自覺跟著團體中心行動。例如,股票市場中,市場最常發生一直買或者一直賣的情況。而如果是在競爭市場,有特別突出的公司時,其他公司會學習特別突出的公司的行動。




專案執行面臨的問題 - 進度(時間進程 vs 距離進程)

在專案或者任務執行之中,技術領導者多少需要有效評估跟瞭解現況。而目前進度是最重要的"現況"。在比較嚴謹的專案管理領域裡面,有許多評量進展的指標,例如已投入成本和預計完成所需的成本比例(一般PMP常用方式)然而,在資訊科技領域中,比較適當的衡量應該還是以時間進度能準確反應事實。

所謂時間進度指的是,還有多少時間可以達到目的。舉例來說假設某人要去日本玩,從家裡到機場需要一小時,而飛行時間為兩小時,抵達機場之後到旅館需要一小時。因此當我們詢問他的進度時,當他的飛機抵達日本的當下,他會回報進度完成75%,尚有25%未完成。

然而,如果是距離進程,也就是以還有多少距離可抵達就有很大的不同。舉例來說,家裡到機場僅有50km,飛機實際飛行距離為1000km,機場到旅館假設有50km,所以當他的飛機抵達日本的當下,他會回報進度完成96%!只有2%未完成。





單以事實來看,這兩者都是事實,可是呈現於資訊科技控制進度與瞭解現況來說,恐怕是以時間進度比較能夠掌握。畢竟,當一個團隊成員說有件事情只剩5%完成,而且你知道他在這事情上做了3小時的時候,在沒特別問清楚的情況下,你大概直覺上認為只需要幾分鐘完成,而非剩下的5%距離,需要在1小時完成。


不過專案進程的事實搜集,有太多太多慘痛的例子是在混用時間進程和距離進程的估計。事實上,由於人類天生的偏誤,在距離很短的時候,會不自覺採用距離進程來回報狀態。這時候技術領導有意識的取得"時間事實"才最重要。

專案執行面臨的問題 - 技術問題

技術問題層出不窮,不過大部份專案的技術問題,通常可以解決。然而,技術問題通常也很難概化討論之,他和專案的特性以及屬性有關。

不過就軟體專案而言,有個兩個看似有些衝突的基本概念一定要知道:


(1) 每個人的技術能力與技術方面的產出差距可以達到10倍以上。而每個組織的能力與技術產出,也有近十倍以上的差距 


(2) Scrum的方法論裡面,假定短時間每個人的績效不會成長,也不會改變

我們以後會再來討論這兩點。不過建議先對agile, scrum有初步研究。


(3) 專案的結束:好的結尾比好的開始更難

第三個重點,專案的結束。很多大公司,無疾而終的專案很多,軟體專案通常無論如何都還是會結束,只是結束的方式好不好而已。

礙於篇幅,我們在日後的文章再來討論專案的結束


沈思:

* 為什麼這次有些項目會在日後再討論,沒辦法先提示一些重點嗎?

* 對於務實的專案管理方式的諮詢服務,請與我們聯繫


10/22/2015

技術領導者team leader 提升能力的三個方向




作為技術領導者,當然在技術力以及領導力上都能必須足以帶領團隊。實際上,能力只有下限沒有上限。因此有意識的提升自我能力必然是作為技術領導者的重要條件。

技術領導者(基本定義請參考這裡)自我訓練,提升能力的三個主要方向參考如下:

(1) 提升領導力


領導能力,乃是帶領組織的能力,與管理不同的是領導力主要產生於個人的能力以及影響力而非自己的組織地位。簡單地說,領導是讓團體一起朝著正確的方向,作出正確的事情,達到預定的成效。領導能力是抽象而廣泛的,但是產生的結果卻是清楚可見的事實。例如:溝通能力是領導者須具備的能力的一環,在某次開會之後,當詢問5個與會人員,開會的結論如果有5種不同的說法,那顯而易見的這次會議的領導者有很大的問題。

對於技術領導者而言,這樣的領導力是可以透過自我訓練以及培養不斷地提升。然而,更重要的是技術能力以及領導能力需要同時,有意識的自我提升,偏頗與缺一不可。

外商常用的360度回餽(http://en.wikipedia.org/wiki/360-degree_feedback) 其中一項常見問題就是”利用自己的影響力,而非職位來協調同仁完成任務“,誠實的根據過去自己的經驗,來回答這些衍生問題可以簡單探知自己的領導力。

誠實瞭解自己是提升的第一步。接下來根據自己缺乏的事情,自我提出學習計劃。以上看起來簡單,但是做起來極其困難。過分自信(參見偏誤)是人的主要認知偏誤之一,且人類傾向繼續做自己專長的事情,要移出舒適圈難上加難。


有幾個簡單的方式可以參考:

  • 閱讀
不僅只是閱讀企管類書籍,而是廣泛而長期的閱讀各類書籍。廣泛而有系統的閱讀,會讓思考全面,而養成長期閱讀習慣大部份好領導者的少數共同特質。

如果對閱讀沒有長期習慣的,建議先讀"How to read a book"。

關於資訊科技的市場以及分工,不免得先對經濟學有所瞭解,可以先看鼻祖書The Wealth of Nations(國富論)然後市面上有很多科普叢書,都能引人入勝。例如蘋果橘子經濟學。

小說類型可以考慮作者已經死很久的,而且篇幅不太大的開始,例如聊齋誌異,雙城記,基督山恩仇錄。近期可能還是稍有名氣作家,例如金庸武俠,村上春樹的小說系列,作為開始比較容易。

至於混合歷史知識和想像的書籍,像是丈量世界,哥倫布行動,萬曆十五年都是開拓視野的好開始。

當然在此沒有列出資訊科技書(例如Design Pattern)倒不是因為不重要,而是因為在此假設技術領導者已經有這方面的學習習慣。自然無需贅述。

閱讀清單(非技術類型):
- 雙城記
- 基督山恩仇錄
- 拷貝一瞬間
- 蘋果橘子經濟學
- 黑天鵝效應
- How To Read a Book
- 國富論 (The Wealth of Nations)
- 丈量世界
- 哥倫布行動
- 萬曆十五年
- 水滸傳
- 不花錢讀名校MBA
- 企業巫醫
- 孫子兵法
- 科技奴隸

(這個清單跟技術領導力沒有直接關係,但是從旁的間接關係不少,重點是要有自己的閱讀清單)


  • 記錄:

        記錄或者筆記,對於工作的執行以及回顧來說很有價值。記錄工作以及重要事項不見得會花很多時間。但是對於追溯自己的思緒有諸多好處。許多管理叢書強調筆記的各類祕技,但總歸一句話,有用的筆記自然有用,沒用的筆記就不會有用。對於強調隨時存取且無限量的"外部記憶體需求"的技術狂熱者而言,雲端服務似乎是某種終極筆記方式。

但請注意:首先,書寫的手感是無法用打字取代;其二,對長期保存而言,目前資訊科技尚未有可確保穿越時間的做法  (例如,1995年如果你有一張3.5吋軟碟片,和一本手寫的日記,在2015年的現在,哪一個可以正確無誤看到其內容?)

  • 練習:
領導能力跟很多可以學習的東西一樣,需要勤加練習。參加領導訓練課程就跟打籃球一樣,看一萬場NBA球賽,不如下場打一次。但是,要練習領導能力並沒有練習寫程式這麼容易。以下做法提供技術領導者參考:

首先,只要在團隊中,就有機會主動帶領"事情的發生",事情無論大小,只要還沒發生就值得主動組織人力執行。

其次,回顧過去的成功與失敗經驗,也是練習的好方式。要注意的是因為自己是自己的練習對象。


(2) 提升技術力

資訊科技的技術能力指的是對程式網路演算法作業系統協定軟體工具等等的瞭解以及應用能力。對於資訊科技瞭解以及能運用的範圍越深越廣,大致表示技術能力越好。

軟體工程師要評估自己最簡單的方式是先由程式語言能力開始。如果你自認為熟悉java那就從上網找SCJP相關測驗,在線上誠實的瞭解自己到底對java了。非程式設計師類型的資訊科技工作,例如DBA,一定也有相關的事實評估方式。自我評估重點在于自我誠實的瞭解。

只要能認清事實,技術能力培養並不困難。有簡短目標的實際練習,就是個簡單易懂的式。例如,雖然很熟悉c與java,但是從來沒接觸過python。想要學習python就應該簡單地定出一些目標。最後一點,如果技術能力的提升目前是個困難,那必須認真思考自己目前是不是能夠擔任技術領導者。


(3) 其他能力:英文能力.專案管理

由於大部分資訊科技資訊,以英文形式為最大量。因此英文能力絕對是團隊能力評估的一環。同樣的英文能力評估也不能靠猜測跟想像,現在有太多遊學留學生,在美國一整年但英文能力卻沒有如同想像中的好。以企業而言,目前最簡單的方式仍然是以TOEIC的實際分數為準。就資訊科技商用領域,TOEIC 785分應該是所謂”無英文溝通專業問題”的最低標。

技術領導team leader在很多時候,必然要了解軟體專案進行的各種細節。實務上Scrum也假設Scrum Master就是技術領導者。

不過在這邊因篇幅關係,先省略專案管理部分,待日後的文章討論。(軟體專案管理相關文章請看此




沈思:

1. 這樣看來當技術領導好像很困難?

2. 專案管理的技術領導要怎麼做?(參考資料




關於技術領導者-team leader 的三個基本概念


資訊科技產業裡面,常有稱呼為小組長,team leader的人,通常負責帶領小團隊前進。這裏簡單說明一下技術領導者的三個基本概念:

(1) 什麼是資訊科技的技術領導

傳統組織隨著人數的增長,通常自然會產生階梯(金字塔)型的結構。然而,這類型的結構把階級當作激勵員工的方式已經不太流行,反倒是以虛擬小組形態,組合不同的小團隊來完成階段性任務,已經逐漸變成常態,特別是在資訊科技領域。

因此一個專案任務,視其大小,需要某一個人負責帶領1-7個人,完成一件任務,而這1-7人並不直接在這個負責人的管轄,也就是另有管理經理負責。這種人,在此稱呼為技術領導人(tech-lead, 小組長, scrum master…總之有零零總總的不同稱呼) ,但其定義僅如下:

                (1) 領導完成任務或部分任務

           (2) 領導1-7個人

           (3) 並非這些人的直屬上司

台灣的學生第一次有機會作為軟體專案技術領導,可能是在學校進行專案的時候。屆時,雖然教授會給予方向上的指導,但事實上是由學生完成,數個學生所組合的團隊可能有各種方式選出一個”組長”。

投入職場之後,運氣好(或者運氣不好)在兩三年內可能會負責帶數個比較新進的同事,主要目的仍是完成某任務,如果組織比較扁平實際的主管也許不會直接帶領新同事,此時,所謂的資深工程師,就很快面臨必須做一個技術領導的挑戰。並非每個人一出生就是個好領導人,但是如果沒有意識到作為技術領導的重要性,則很有可能造成三輸的局面:新人很快陣亡;主管不滿意帶人的績效;自己也不高興。而成功的帶領同仁完成任務比較可能達到三贏:新人很快能貢獻給團隊;主管的期待被滿足;更重要的是自己在技術以及領導力上有所成長。

(2) 技術領導與管理階層截然不同


作為技術領導者,因不是直接管理工程師,所以只能透過領導以及可信服的技術能力來帶領成員。因此,相較於實際管人經理有優點也有缺點:

        優點:
                * 無須擔負直接管理責任(不需要負責解雇人)
                * 不需要直接負責成員的心態問題以及生涯規劃

        缺點:
                * 無法使用職位快速以上對下的方式達成小型任務
                * 對於明顯有心態上的問題的成員無法快速汰換
                * 難以對團隊成員提供誘因


(3) 就業市場非常需要技術領導


一個好的技術領導者Team leader在就業市場上奇貨可居。


資訊科技的就業市場過去數年一直在成長,每年畢業的學生雖然眾多,可是就業市場似乎傾向於取得及時戰力。而有實質經驗的技術領導者,比主管經理的市場更大,因為主管經理不見得一定能夠帶領技術,也可能距離實務已經有一段時間,然而技術領導者需要帶領小團隊前進,正常的情況下本身就需要具備技術領先的能力。

更有甚者,現代組織都希望層級不要太多,扁平化在成熟組織幾乎是常態,People Manager - 也就是所謂帶人主管,通常直接帶領的人數會越來越多,也導致非直接帶人的技術領導,通常才是直接參與開發工作的領導者。




沈思

* 如果我已經是技術領導者,我要怎麼提升自我的能力? -> 參考這裡



10/20/2015

委外(外包)對創新公司的三個主要協助


所有網路創新公司,幾乎都不可避免利用某些廣義的委外服務。這些服務可能是免費,也可能要收費,因網際網路的快速發展,數十年前自己得動手做的事情,現在都可以找到對應的服務。

隨便舉3個例子。

email:現在幾乎很少人架設自己的mail server,而都改用gmail/zoho/godaddy等等,但先千萬不要再用msXX.hinet.net這類不能設置自己的domain name而且甚至還要錢的email服務。

server:AWS/linode/digitalocean等等都是常見的cloud server服務,讓你不用擔心server架設維護問題。

金流:以前都要自己設置刷卡,匯款等等問題,現在有paypal可供國際化付款服務。

然而,除了顯而易見的網路服務之外,在台灣似乎比較少人用軟體開發的外包服務。

例如:fiverr.com,可以協助你產生企業logo,快速設計網頁,進行SEO,測試軟體,撰寫部落格文章。upwork.com,可以找到很多軟體工程師,撰寫定義好的程式,做好網頁服務,做出facebook app,撰寫mobile app等等。

這些看似接近核心的任務,其實妥善分工,外包之後反而對自己有利。

對新創公司主要有三個協助:

(1) 時間與資源專注

新創公司最重要的資源其實不是資本,而是少數幾個夥伴在一起努力的時間。如果你要做的事特殊的big data分析演算法。你和幾個夥伴應該把時間精力集中在這個演算法上面,而使用者介面,企業logo,企業網站,介紹的blog文章統統都應該外包給其他人,只要你們能清楚定義並且審閱結果即可。

(2) 強迫模組化分工

如果一個三個人的小公司,每個人的專長都是programming,但對UI/UX都不擅長,一開始根本不應該花大錢去雇用一個frontend+UI/UX專家,而是根據自己的需要把UI/UX模組化之後外包。這樣一開始的設計就已經考慮模組化,將view確實分開之後,以後的維護,成長也都容易得多。更有甚者,所有人都還是集中心力做最專注的事情。

模組分工強迫對工作有清楚的定義。如果沒有清楚的定義模組與時間,外包的時程會越來越長,成本越加越多,最後失敗的時候還會宣稱不應該找外包來做。實際上應該是在當時沒辦法好好控制以及定義工作。參見這裡

(3) 彈性

外包可以產生組織彈性。只要不是外包的工作,就表示某個夥伴要做。而一個工作要需要進行,則大家的時間彈性就變小。例如,根據marketing的需要,一個新創公司可能得花時間維護blog文章,以及關心回應潛在客戶需求,這時候應該利用具有專業技能的Virtual Assistant,而不是讓少數夥伴花很多時間在一個一個的客戶回應上。



沈思:

1. 為什麼台灣新創公司好像很少聽過大幅利用外包資源,但是國外公司倒是很常見?溝通語言(英文)是不是一個顯著的問題?

2. 什麼是Virtual Assistant?它能幫助我們什麼?參考這篇blog




10/19/2015

精實創業之 三個精華(MVP POC Scrum)



Lean Startup 精實創業是近年常見資訊時代創業方式。他著
重於確實以及快速。確實達到目標,以及快速反應變化。參見wiki https://en.wikipedia.org/wiki/Lean_startup


當然Lean強調速度也有些反面的意見

以下是三個精實創業的精華:

(1):POC實證觀念:


精實創業最精華的地方在於POC: Proof of Concept:實證觀念。唯有你的創業想法能夠被証實可行,而且在市場上獲得證實,你的主意才有意義,缺乏實證的就把想法大幅推廣只能靠運氣。這裏,會介紹做出MVP的最務實方式。

而在Lean Startup 作法上一般分成幾個層面:
(1) MVP: 最小可用產品
(2) 持續部署
(3) 測試產品(A/B test)
(4) 調整方向(Pivot)
(5) 做-衡量-學習

(2):MVP能達到POC:

在這些層面之中,最重要的還是做出MVP並且在市場測試。MVP講起來簡單,但做起來不容易。特別是在新創公司,大部份的工程師都會傾向做出完整的優良產品,MVP有時候是要做出最小功能的產品,這可能與工程師的天性互相違背。在Lean Start up 原創者Eric Ries的書裡面,描述了一個網路賣鞋的概念,去實現此概念不見得一定要做出有完整購物車以及金流的網站(強烈推薦看一下此書)。

當你靈光一閃的時候,如果沒有去實踐,終究也只是一閃。然而實踐要付出很多代價,最務實的方式會是用Scrum來做出MVP,由MVP進行測試產品,然後再由市場來決定這樣的靈光一閃是不是真的好主意。

(3):用Scrum限制成本達到MVP

Scrum是Agile的方法之一。Scrum可以用在很多地方,但MVP是Scrum能發揮的最佳之處。作法如下:


1. 定義功能
2. 排序
3. 限定時間以及成本
4. 刪除
5. 設計與實作
6. 投入市場
7. 收集反應資料

然而精實創業也常被人詬病為產品不完整,因此一開始有效定義MVP,之後以Scrum來實踐是比較實務的作法。


細節案例請參考如下節。


用以沉思的務實細節:


1. (定義功能)根據靈光一閃出現的絕妙好主意,定義出想要的東西的功能。舉例來說,你想要做一個具有特殊演算法用來計算一起用餐分帳的手機APP。列出的功能如下:

 * 能夠快速紀錄帳款
 * 特別紀錄和朋友一起用餐的分帳方法
 * 顯示欠款,被借款資料,以及目前帳不是平的
 * 一起用餐的餐廳資訊
 * 一起用餐的人數
 * 能夠登入,登出,帳號基本管理
 * 後端能未來做分析

2. (排序)根據你心裡的重要順序 把功能排序,結果可能如下:

 1. 採用特別分帳方法來均分帳款
 2. 能夠紀錄和朋友之間用餐的帳款
 3. 能夠登入,登出,帳號基本管理
 4. 後端能未來做分析
 5. 顯示欠款,被借款資料,以及目前帳不是平的
 6. 一起用餐的餐廳資訊
 7. 一起用餐的人數

3.(限定時間以及成本)這也就是MVP有意義的重點,任何事情都可以無限上綱地做到不可置信的完美,但是時間成本永遠是有限的。假設我們限定一個月,分成4個sprint,並且是2000美金。

4. (刪除)每個Scrum只能做有限成本的功能,剩下應該移入backlog。在這裡粗估每個sprint能完成一個功能,因此只留下四個其餘刪除。可能留下的結果如下:

 1. 採用特別分帳方法來均分帳款
 2. 能夠紀錄和朋友之間用餐的帳款
 3. 能夠登入,登出,帳號基本管理
 4. 後端能未來做分析

5. (設計與實作)根據留下的功能在每個Sprint進行設計以及決定實作:

 這一點牽涉比較多軟體開發知識,在此暫時省略。不過,如果已經固定了成本,可以考慮能實踐你的好主意的企業,例如TALENT-SERVICE

6. (投入市場)對於APP來說,投入市場當然就是上架。但要注意的是,上架本身牽涉到許多行銷以及相關知識。缺乏這種知識與行動的話可能會很慘。


7. (收集反應資料)對於APP來說,設計與實作的好,可以讓資料收集以及市場反應變得很容易。當然這個也牽涉到一些專業知識。簡單的說,盡可能利用已經存在的平台:例如google adsense, AWS, facebook等等來幫助你搜集資料。

Lean startup, MVP, Scrum是三個互相輔助的概念。透過Lean startup的精神,利用Scrum來做出"很多個MVP"才是成功的最簡單方式。參考這裡