企業巫醫 - 贅字 廢話 泥巴仗

在組織中，溝通合作是大部分的人一定會做的事情。

溝通合作說起來簡單，畢竟人類是靠群體合作而存活在地球上。不過，在企業內部的有效溝通並不如想像中的容易(註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: 以資訊科技來說，最基本的本職學能是寫程式，其他可以參考這裡或這裡。

建立軟體開發團隊 (1) 計畫 組成

... of the 20,000 notable players for us to consider, I believe that there is a championship team of twenty-five people that we can afford, because everyone else in baseball undervalues them...(Moneyball 魔球)


軟體開發團隊的建立和運作，不可能有完美的狀況。但是，妥善的計劃，能大幅降低軟體團隊的運作風險，並且讓團隊成員專注於發揮專長和創意，減少不必要的浪費時間。

特別是浪費時間在於解決非技術性問題。


問題有可能來自各方面，例如：

(1) 目標極端困難。例如：要在3個月內完成類似AWS EC2的雲端運算平台。

(2) 目標不確定性極端的高。例如：團隊目的是要完成一個不知道誰簽訂的模糊合約。

(3) 團隊還沒組成，目標也還沒確認，就已經有時間壓力。例如：一個2-3個人合作的新創公司，剛剛獲取資金成立。

(4) 團隊的組成有時間壓力。例如：在大企業中，因為高層要求，一定要在某月某日找齊7個人組成團隊

(5) 團隊已經有部份是問題成員，在此同時還要因組織任務擴張而增加人力。

(6) 因為組織變動(例如企業改變目標，併購等等)，讓某個團隊大幅流失人才，而需要重整補齊人力。

(7) 因為文化與跨國合作困難，導致前期人力大幅流失而需要重整團隊。


負責組織團隊的人，最最基本的認知就是：

軟體團隊組成這件事情：本身一定會有困難與挑戰。不具備困難與挑戰的軟體團隊，其實沒有存在的必要。(註1)


以下三個步驟可以供組織團隊負責人參考：

(1) 了解探索事實，盡可能將事實攤在陽光下

許多新團隊一開始就建立在「各種假設」上。例如新創團隊「假設大家對Scrum都有相關經驗」，或者「假設在3個月後可以找到2個優秀的iOS開發人員」，或者「假設大部分的使用者都有fb的帳號」，或者「假設3個月內某個模組可以先行開發完成」。

在許多情況之下，很多事情的確有假設，才能進行下去。

但是，在建立團隊的時候，除了瞭解背景假設之外，先確認事實才重要。

以下事情必須要儘早確立。

(a) 團隊目標願景：

可參考下節「確切定義短期中期目標」。如果是非營利組織，團隊願景就非常重要。因為這可能是召集成立團隊的最大動力。一般企業，營利組織，除了獲利之外，也可能會伴隨其他更遠大的目的。例如：「讓人類可以移民火星」之類的(註2)。

一個有崇高理想的非營利團體，也就不應該將盈餘拿來作為績效獎金。而是以團隊能達到的願景作為激勵人心的最大方式。(例如Kiva)

相對的，如果只是單單純純想賺大錢的公司，例如某東南亞賭場在台灣的軟體部門。也就不需要唬爛一個崇高的偉大目的，就只要讓團隊了解「大家來歡喜寫程式賺錢吧」即可。因為有正確的認知，才能集合正確的團隊。一個誠實的宣稱「大家來寫程式賺錢吧」的團隊，自然不會將社會責任活動當作是團隊成員想要做的事(例如：到沙灘撿垃圾，協助獨居老人)，當然「培育企業人才」也不太需要，甚至Scrum裡面的「自己選取task來做」也根本不用，採用由上而下的軍隊式管理，讓工作以最有效率的方式完成，才是這種團隊的最好方式。


(b) 資源現況：

目前的現況是不可否認的事實，但許多人一開始的時候，會將現況和未來的希望混為一談。在此時此刻擁有的資源就是現況。

例如：現在有1個專案經理，以及1個剛剛到職的工程師，未來可以找10個人。...這就是資源現況。

但也有可能是：現在有1個專案經理，以及1個剛剛到職的工程師，未來可以找10個人，但是辦公室座位目前只有4個空位。...這也是資源現況。

更有可能是：現在有1個專案經理，以及1個剛剛到職的工程師，未來可以找10個人，但是辦公室座位目前只有4個空位。而團隊目前總薪資預算為1千萬台幣，其中還得包含筆記型電腦採用費用。扣掉已經到職的兩個人，年預算只剩下600萬台幣，所以可以找10個人，但是平均年薪只能為60萬，或者找6個人，平均年薪為100萬。...這也是資源現況。

作為一個建立並組織團隊的人，資源現況的瞭解和掌握，必須要越清楚越細節越好。實際上，絕大部分的情況下，只要稍微多花個幾個小時，就可以掌握到很多現況細節。


(c) 組成專長：

即使已經是軟體開發的專家，這仍然是一件需要擔心的事情。

如果團隊的短中期目標確定，組合的專長可能大致確認。然而，某些專長不見得是「團隊成員需要有的」，這些專長可能可以用「短期購買」取得。

團隊領導者在取得事實的階段，需要清晰可見的專長分佈圖。

以上圖為例：簡單地列出做一個購物網站可能需要的專長，並且也把目前團隊已經擁有的人才能力列在其上。未來在組合團隊時候就比較容易考慮周詳。

要注意的是，這樣的圖並不是要完全技術上正確，而是要做為未來計畫的參考。因此有可能一再修改，也不見得需要用了不起的繪圖軟體製作。


(d) 關鍵成功因素：

哪件事情做好了，會讓這個團隊成功。成功關鍵因素應該只有1-3個，不應該太多。 這個關鍵成功因素必須要很「實際」，能夠被「衡量」，當然也必須要是能「達成」。至於困難不困難就不一定。以xspace的火箭設計為例，他的關鍵成功因素不只是火箭能發射，還要能「掉回地球後，能自己站立，以便低成本回收」。

軟體開發團隊的「建立組成」的通常是願景能否達成的關鍵成功因素。然而，建立組成的本身也有關鍵成功因素。例如，在2個月內吸引3個具有5年工作經驗，並且容易合作的工程師到職。



....其他需要搜集以及展現的事實還有不少。完整清單請參考(註3)。當然，不可能花幾百天的時間，只是為了收集事實，只要在合理的時間內，盡量收集了解重要的事實。

(2) 確切定義短期中期目標

前段所述的事實如果了解的夠完整。定義短期中期目標就很簡單。

短期目標是1週到4週內「必須」完成的事情。中期目標則必須要能夠「完成一項的關鍵成功因素」。

以建構軟體團隊而言，八九個短期目標完成後，差不多就等於一個中期目標完成。

任何軟體開發計畫，必定會有目標，而讓團隊朝向「同一個方向」前進。所謂團隊，當然是一群人往同一個方向前進，才能叫做團隊。一群在同一個組織架構的人，或者在同一個老闆底下工作的人，不見得是一個團隊，很有可能每個人在軟體開發

(3) 根據目標擬定計劃和備用計畫- Plan B

兵法有云「夫未戰而廟算勝者，得算多也；未戰而廟算不勝者，得算少也。多算勝，少算不勝，而況無算乎！吾以此觀之，勝負見矣。」

計劃本身並不重要，但是做計畫這件事情很重要。

計劃要達到的目的要非常清楚。而且必須「至少」包含兩件事情！

*** 達到短中期目標的做法 
*** 實質建立工作環境與實際做法

建立軟體開發團隊的初始計畫至少需要涵蓋以下內容：

(a) 團隊目的，短中期目標

....請參考前兩段...

(b) 團隊組成

需要哪些專長的人在這個團隊。更重要的是，哪些技術背景的人的組成最適合這個團隊。最好的方式是將所需要的「實質技術能力」清楚地列個圖示，根據分佈圖，來劃分團隊組成。

切勿用想像的方式。

以上圖為例：這是一個打算建立電商網站的技術分布圖，和目前團隊成員(四個人)所擁有的技術連結。可以很清楚的看到哪些領域還沒有適當專長的人。也可以清楚地展示，團隊目前組成和未來最需要的地方。

這個草圖並非正確的描繪出細節，而且也把技術不相干的東西納入（例如裡面有個API doc，其實是還沒有去做的事情）。但整件事情的精神在於「視覺化」。透過視覺化，對團隊的變化才有整體性的考量和規劃，而不會落於枝節上。


(c) 團隊運作原則

近年來流行Agile的Scrum方式。可以參考這裡。


(d) 初始化工作項目

當團隊的成員是逐漸到職，最初的工作項目是能夠讓團隊快速形成共勢。這看似枝微末節，但是是隱含的關鍵成功因素。

初始化工作項目，在新成員到職的前幾天，最好是鉅細彌遺。規劃了新成員第一天到第五天，「每天」要做的事情和達成的結果。並規劃前4週，要達到的大項目，以及前3個月的必須要的貢獻程度。

團隊是由一個個單一個人組合起來。將個別成員的適應期縮得越短，對團隊的組成越有利。

規劃前五天的細目，絕對不會讓這個新成員變得沒有創意，也絕對不會扼殺他的潛能。反而是讓他可以在極短的時間之內，先擺脫掉和「智慧創意」無關的邊緣事項。因為這些邊緣事項，如果在前一段時間沒有擺脫，之後會一直出來煩大家。

以下是某個電商開發團隊的前三天初始化工作項目，同時也是檢閱清單：

Day-1  
    - Mentor介紹工作環境，取得電腦和其他硬體設備
    - Mentor協助取得email和其他必要的帳號
    - 取得目前程式碼版本控制系統權限，確定可以clone
    - 確定clone目前的程式庫

Day-2
    - 取得目前的UI/UX設計文件，Mentor協助了解文件內容
    - 參加Scrum會議，理解Scrum雞與豬的原則 
    - 在Mentor協助下，建立自己開發環境

Day-3
    - 在Mentor的協助下，在自己的開發環境確定能修改程式/簽入(commit)/建立branch，最後產生自己的build。
    - 了解基本的測試項目

以上僅是3天的範例，這些看似細節，但要在三天之內完成也不並容易。


(e) 定期檢討方式

檢討方式可以參考這裡和這裡。

簡而言之，建立團隊的過程也需要被檢討。

例如：

新加入的成員，在當初面試的時候所呈現的能力，和實際上工作的產出，是否吻合。

新的成員對於非技術類型的雜事，是不是很快能找到資訊。例如git的位置，目前各個branch的狀況，自動化建構的方式，建立開發環境的方式等等。

---

註1：如果這個挑戰對負責組織團隊的人來說太過困難，最好不要接受這樣的任務。一個失職的程式設計師頂多讓專案推遲幾天，或者品質降低一些；但是一個失職的領導者，會讓整件專案崩壞。


註2：例如xspace

註3：建立軟體開發團隊的事實搜集清單

(a) 團隊目標願景
(b) 資源現況
(c) 組成專長
(d) 關鍵成功因素
(e) 關鍵風險 - 一旦發生就可能會失敗
(f) 關鍵技術 - 是否有必須具備的關鍵技術，需不需要招募這樣的人才
(g) 利害關係人 - 哪些人跟這個團隊有實質的相關
(h) 外在環境 - 辦公室設備 是否有遠端甚至跨國合作團隊等等

企業巫醫 - 誰掌握你的升遷？

只有自己掌握了自己的命運。沒有別人。(註1)

升遷也不例外。只有自己掌握自己的升遷，沒有別人。

大部分無法獲得升遷的理由，都只是自己的藉口而已。常見藉口(註2)如下：

- 自己的努力沒被別人及主管看到
- 受到主管不公平的對待
- 主管不賞識甚至打壓
- 組織內制度有很多問題
- 負責的工作實在太艱難資源又少
- 負責的工作實在太簡單沒有挑戰性
- 景氣不好公司不賺錢就罷了，還在裁員
- 比我資深的還很多，很難輪到我


在大組織裡，個人升遷(promotion)仍然是職業生涯重要考量。因而，企業巫醫們的一些闡釋也頗有道理，例如這篇，或者這篇。但有些過於偏激，而且會舉一些憑自己想像的例子。這類型的巫醫頗多，在google上搜尋"升遷"就可以找到不少。


那麼，自己要如何掌握自己的升遷？

超乎期待：做出超越目前工作職掌的成績

升遷指的是企業組織認為你可以「增加」工作範圍或內容。而要讓企業組織，或者主管，要認定你可以承擔更大的工作範圍，最好的方式就是你「已經」做出超越目前工作職掌的成績。

超越工作職掌的方向有兩種，這兩種和雙因子理論/激勵保健理論(參考激勵保健理論)的概念相同。

方向一：保健因素

保健因素指的是，沒達成會有負面影響，但是有達成，且做得再好也不會是超越工作職掌的事情。換言之，有絕對的必要性，但是超過也沒有意義。

例如：

作為員工，準時參與會議，準時上班，按組織規定請假。
作為一個程式設計師，準時交付符合品質的程式碼。
作為客服人員，在時間內回復顧客問題。
作為專案主管，讓控制並管理團隊時程，沒有延誤

有些是屬於規定類型，有些是屬於職務範圍。這些都是歸類於保健因素。換言之「沒做到」是非常糟糕的！非但不用考慮升遷，甚至應該擔心被資遣。

要注意的是兩種對保健因素的誤解：

(a) 誤解一：消極應對

既然這並非升遷，或者有額外價值的項目，那麼也許我就做的勉強符合，60分就好。這樣的心態會讓這些的保健因素，很快的變成你自己的風險。保健因素的最佳處理方式是採用cynefin模型的「簡單因果」類型工作的處理方式。以最佳化，(或自動化)的方式處理。

消極應對，只會讓保健因素變得個人缺點，得不償失！

(b) 誤解二：這不是保健因素

在智慧型職業(例如程式設計師)最常出現的誤解是「這工作不是保健因素，我做到這件事情就是超乎期待」。

事實上，絕大部分的由上而下指派的任務，幾乎都屬於保健因素任務。

例如，你負責撰寫android app任務，根據自己的努力，確實在規範的時程內，以規範的品質上架完成。這「本來就是」你的任務。完成這件任務，的確是好事，但如果沒有做出超越任務的範圍，那就是預期內的職掌。既然是預期內的職掌，當然會取得預期內的「報酬」，例如薪水。自然也不會取得「額外」的報酬，例如鉅額加薪或升遷。

試想，你搭計程車，司機在合理的時間內，安全的把你載送到你要求的地點。你自然會付出正確的車資，不太可能付出「額外」的費用吧。

方向二：激勵因素

如果有做到，會讓人感到「很滿意」。

這個方向並不容易，但其實是「最能自己掌握自己升遷」的真正方式。

激勵因素根據工作內容而有所不同。以前述的搭乘計程車為例，如果計程車司機在車上「額外」提供一般計程車不會有的卡拉ok服務，並且未要求額外收費，在你開心的抵達要求的地點時，非常有可能自願的拿出額外報酬。

智慧型職業比較難找到激勵因素的方向。有幾個尋找方式可供參考：

(a) 參考方式一：擴增保健因素

這個方式比較基本。例如：一個app的程式設計師，被要求在6個月內完成app並上架，結果在5個月就完成，並且其品質也在要求的範圍內。對企業組織來說這個事件就算合理的「激勵因素」

(b) 參考方式二：額外的相關支援

類似計程車卡拉ok。例如：android app程式設計師，被要求在6個月內完成app上架。結果的確在時間內完成。並且，由於他採用react native，竟然也順便完成了iOS app。這就是額外的支援項目。

(c) 參考方式三：擴大 

主動執行擴大職掌範圍的任務。例如app程式設計師，其任務是開發app並上架，如果主動協助開發伺服器端，或其他功能模組，就算是擴大範圍。

更顯著的例子是：app程式設計師，其任務是開發app並上架，但主動組織團隊，做出新的實驗性質的計畫。那的確證實了擴大職掌和展示了領導潛力。

其他：

離開組織，以及自己建立組織-創業。 也是都是合理「自我升遷」的方式。

當然，離開組織之前，要先確定問題不在自己身上。如果問題出自自己身上 - 無論是能力或溝通問題 - 換到其他地方，也不可能解決問題，只是碰運氣而已。參考這篇，或者這篇，或者這篇。

創業是自己造成升遷的最簡單方式。在那一夕之間，你就變成董事長兼CEO了。然而，能不能生存並獲利，又是另外一回事。創業需要另一方面的能力與知識。要成功並不容易，參考這裡，與這裡。

---

註1：在某些地區，某些情況下，當然有不得已的時候。例如，如果你是生在阿富汗，伊拉克，索馬利亞等國家，確實很難掌握自己的命運。所以，本篇指的是一般在台灣的普通上班族。

註2：為什麼這些是藉口？請參考說明如下：

-- 自己的努力沒被別人及主管看到
-- 受到主管不公平的對待
-- 主管不賞識甚至打壓

(a) 短時間或許有可能自己的努力不被發現，甚至可能被瓢竊或者搶功勞。但長時間不可能！而且事實上，如果你真的能力極佳努力也夠，僅只是沒被看到而已？那你應該很容易可以找到更好，並且更容易看到你的能力和產出的地方！

(b) 爛主管的確有可能打壓好員工，但沒有人強迫你為某個主管工作，你當然可以離開。但是在離開之前，請先參考這本書(我愛白痴老闆)。也可以參考（得罪老闆怎麼辦）


-- 組織內制度有很多問題

(a) 大企業制度上不可能完美，因為制度目的通常是為了企業生存。只要企業符合法律規範(在台灣是勞基法)就沒什麼好抱怨。並且，適應制度也是能力的一環。當然你也可以自創一個擁有好制度的組織。


-- 負責的工作實在太艱難資源又少

(a) 如果你覺得能力不足負擔這個工作，那不升遷的確是合理
(b) 如果工作真的太難，那應該自己去換個簡單的工作
(c) 所有企業組織的資源都是缺乏的，資源缺乏不是問題，只是現實

-- 負責的工作實在太簡單沒有挑戰性

(a) 如果你覺得工作太簡單，可能是因為主管覺得你無法負擔更重要的工作
(b) 也有可能對你來說工作太簡單，但是對主管來說你沒把簡單的工作做好，以致於無法給你有挑戰性的工作


-- 景氣不好公司不賺錢就罷了，還在裁員
-- 比我資深的還很多，很難輪到我

(a) 如果升遷是你最重要的考量，應該離開這類型的工作環境

軟體專案的現實：解決人的問題

無論是否採用agile的開發方式，所有軟體專案，最大問題的來源都是人。

人的問題，通常會極現實的影響專案的進行。然而，妥善運用agile的精神和Scrum的方法，有機會讓人的問題降到某個程度。

某個朋友，姑且稱為K，在專案扮演專案經理的角色，遇到以下狀況：

我最近有遇到一個問題，不知道怎麼辦，下面的人一直做不到我的要求，或者動作很慢，即便壓日期給他，他還是沒辦法達到，但實際上它任務並不多，只是開test case，我不太知道怎樣push他，我又不想來硬...他只有這個任務 平常又常常看他在上facebook, line....覺得要當一個讓人喜歡的lead真的蠻難的....


這個問題非常典型。

以敏捷開發(agile)來說，解決方式似乎也很簡單。首先專注於優先項目，接下來根據事實檢視工作，最後才考慮能力問題。

一：專注於優先項目

每個人在Sprint之中一定有正在執行的項目。確保每個人都是「專注」於目前最優先的項目是Scrum master最基本的任務。

即便不是採用Scrum也一樣。團隊成員必然在某個時間點有一個特定任務。專案經理或領導者(leader)當然必須確保，在這個時間點他只會專注在這個工作任務上。

對於剛剛成立的團隊來說，要確保團隊成員專注於目前任務上的方式很簡單：就是腳踏實地的「問」。在該成員一來辦公室的時候，就坐到他座位旁，親切的詢問他昨天早上在做哪些事情，昨天下午在做哪些，並實際上「看」到做的結果。就可以確定他是否專注，而能確定是否做到真正的效果。

整個詢問的重點都是在了解事實，而不是監督細節。因此每天頂多也只針對「需要幫忙的成員」，一起坐著看實際上的狀況。

二：工作檢視

以Scrum而言，每天的會議(無論是不是站著)就是為了統一工作情況檢視。完成就是完成，沒有完成即便是已經達到99%也一樣是沒有完成。當然，前提是在Scrum開始時有定義「什麼叫做完成」 - Definition of Done。

如果不是採用Scrum，則應該盡可能在團隊開始時，就先定義何謂「完成」。

以開test case為例，完成是指把要做的功能的test case詳述在某個測試文件管理系統上？還是只要先用excel或者wiki列出來即可？test case完成後是否要先讓團隊成員審閱，看看有沒有問題？要不要先估計每個test case執行會花的時間？test case的前置作業 - 例如建立測試資料等等，是不是也要涵蓋在其中？

當有完整的工作完成定義之後，要讓負責進行工作的人「決定時間」，而非「被決定時間」。

以軟體專案而言，任何超過2天的工作項目(task)，都應該分階段完成。畢竟，就事實而言，一個人不可能「連續工作2天」，每天一定會停住工作，下班回家。而這些階段應該要有階段產出。以test case而言，假設有10個新的user story需要建立test case，則今天完成了4個，表示還有60%尚未完成。

三：能力分配

如果團隊成員的確很專注於工作，而且也對時間/產出有正確的體認。最後的問題就是「能力問題」

團隊成員的能力組成其實非常複雜而且麻煩，牽涉範圍廣。以軟體專案而言，能力並非只是撰寫程式，測試程式，理解規格等等。能否和其他人合作，也是能力的一環。

一個規模中等的軟體開發團隊(4-7人)，如果有一個人的能力「極端」的差，確實會造成專案很大的問題。

在Scrum的情況下，這樣的問題在前兩三個Sprint應該就可以被控制。因為雖然他的產出差很多，但未來的sprint的進度，是以團隊能力來考量，因此Scrum master仍然可以有效掌握專案產出和進度。

在不是Scrum的情況下，可以先找到該成員的相對優勢。排定一些學習項目，來提昇該成員在這個專案中的相對優勢，並且在未來安排相對優勢的工作。值得一提的是，根據經濟學的「比較利益法則」，每個人一定會有所謂相對優勢：請參考這裡，和這裡。

關於軟體開發團隊的個別能力，還需要注意以下幾點：

1. 每個人都會成長，但是....

每個人都會成長學習新知識和能力。但是！在中短期專案裡，必須先考慮個別能力與優勢。

換言之，團隊領導要像下象棋一樣，找到每個人的「專長」，能妥善組合專案，就是個好的領導者。

而差強人意的領導者，則是常常試圖規避個別成員的「缺點」，這樣比較不會出大問題，但也容易產生差強人意的結果。而最糟糕的領導者，則會把人當做圍棋，看到人非黑即白，見到專案漏洞時，看到有空閒的人就直接填塞。這在某些有數百個人的硬體專案或許可行(因為數量在此可以產生品質)，但在軟體開發專案鐵定行不通。

2. 能力是綜合考量...

能力必須綜合考量「全方面」：例如是否好溝通，是否能處理複雜的設計問題，能否開放心胸的就事論事等等。不能僅僅考慮寫程式的能力。

另外，如果覺得整個開發團隊能力都很差。作為一個能自我思考的領導者，應該先思考自己是不是「問題的來源」，甚至要思考自己是不是根本不適合作為團隊領導。

3. 讓不適任的成員離開...

讓不適任的成員離開，某些時候是個可行的解決方案。特別是某些企業管理派別認為，投入時間在不適任的人身上，他有可能變得適任，也有可能不會改變，然而投入時間太多，會造成專案延誤。

以Scrum的角度來說，這個情況不太會發生，因為2-3個sprint之後團隊速度已經確立，無論適不適任，專案產出速度不太會再改變。因此剩下的問題僅在於「換個人會不會更好」。而以中短期(3-6個月)的軟體專案而言，讓破壞性的不適任者離開，當然是解決方式，但不見得要「找另一個人進來」。

---

相關文章：人才管理，心智圖，為自己工作...

企業巫醫 - 實習生的三贏

巫醫通常會告訴病人事情的「權衡」：是想要錢還是健康？是想要貢獻祭品還是得罪惡靈？當需要獲得健康，當然就要犧牲其他東西。

許多事情的確是如此...總不能要馬兒跑，又要馬兒不吃草。

不過，對於需要創造性思維的現代企業，權衡在於真正的目標，和創意的達成方式。把馬車換成內燃機驅動的汽車，就是革命性的方式讓移動的東西大幅加速而且不用吃草。

企業實習生也是如此。

高明的策略，就可以達到三贏。普通的策略，就會犧牲某些地方。愚蠢的策略就是三輸。

以資訊科技產業來說，三贏的情況是：

對企業組織來說：有低成本的方式，獲得高潛力的「人力」。讓工讀生能先處理簡單，可學習，重複，但是可改進的工作，使團隊成員專注在複雜的開發活動上(註1)。藉此了解這些工讀生未來的潛力，同時也能透過有效分工，提升績效和產出。還能順便展現企業的社會責任決心。甚至，透過實習生循環來訓練組織內部未來的領導人才。

對社會來說：降低新鮮人「嘗試錯誤」的成本，增加投入的生產力。

對新鮮人來說：提早知道自己的興趣和能力。在還沒踏入職場之前，至少對工作有所體認，瞭解軟體工作真實的一面。無論未來是不是要從事同一行業，踏實並且正確的工作經驗，都能引導未來的發展。

普通的情況是：

對企業組織來說：在暑假期間，統一由HR辦理招募活動，發配到各個部門，和夏令營一樣在兩個月期間和團隊一起合作，可能有產出也可能沒有。

對社會來說：讓大學生研究生在暑假能有除了閒晃打電動之外的選擇。

對新鮮人來說：可能像參加夏令營一樣，但只要有認知，還是能學到很多。

有三輸的情況嗎？

會有三輸的狀況，通常是乩童式策略規劃，和不正確的預期：

乩童式策略就像是有件困難的事情，是在我們的智慧能力尚且不能了解，所以我們就去問乩童，而乩童也不懂，但是他可以「起乩」，透過起乩，從其他地方得到智慧，來回答問題。在各個部落的巫醫也都有類似「起乩」的行為。即便只是實習生策略也會有淪落到乩童式規劃的可能。而這樣的策略結果等於是靠運氣，運氣好的時候甚且可會收到好的效果，但不可能永遠都是好運氣。

對企業組織來說：只是因為「聽」企業巫醫起乩之後，覺得弄幾個工讀生來好像很不錯。因此，就隨便找幾個進來。但由於沒有組織，沒有計劃，就只能做沒有意義的工作。更有可能還會故意製造的沒有意義的工作給工讀生。參考這裡。

對社會來說：浪費了人力

對新鮮人來說：對企業造成不必要的負面印象。也沒有真正學習到工作的意涵。

如何達到實習生的三贏策略

達到三贏的方式，當然是以事實為基礎，避免乩童式目的，達到漸進式目標。

以資訊科技，或者，軟體開發相關企業來說，掌握以下事實，就容易達到三贏。

(1) 培訓是必要的：

的確有很多自動自發學習，又很聰明的學生。但是稍稍有計劃的訓練，可以大幅降低走錯路的時間。而培訓不只是「教」而已，找一些主題讓實習生自行學習也可以。

(2) 長期：

對資訊科技相關的工讀生來說，

A: 一個禮拜來兩天，連續6個月。

B: 全天候，但只有2個月。

這兩個方案看起來實際工作時間似乎一樣，但是，最後能達到的學習效果和產出，永遠是A比較好。因為，資訊科技並非勞力型的工作，而是思考智慧型的工作。當實習工讀生對技術產生興趣時，自然而然會再額外的時間，補足在技術和知識上的不足。而且，考慮到前期的培訓時間，超過6個月以上的實習才能可能達到三贏。

(3) 務實：

讓工讀生參與真正任務，但由基本開始。讓實習生去撰寫核心模組，是本末倒置的行為(註 2)。但只讓工讀生去打掃辦公室也沒太大意義 - 除非這是一間專業清潔公司。以軟體開發而言。以下幾件事情都是比較適合的切入點。

A: 簡單的執行測試計劃(test case)：是最容易入手，並且也比較能直接產出貢獻的事情。

B: 驗證文件：例如將api文件中的範例依照手冊執行看看會不會有意外，也是產出貢獻的一種。

C: 專案助理，協助收集進度，現況，簡單統計目前在版本控制系統(例如git/cvs/p4)裡的程式碼增減狀況...。這些看似助理類型的工作，可以讓工讀生對軟體專案的進展有很完整的概觀。

(4) 實習生的週期循環：

工讀生從開始招募，訓練，到離開，最好是6-18月之間。必須要簡單完成的循環規劃。實際的例子如：

A:  招募大三四研一二的資工資管資科相關學生。
B:  為期最短6的月 每週來兩天 時薪固定為XXX元。
C:  到期根據實際表現可能會續約一次。大部分會續約。
D:  座位和電腦設定已經事先準備好 (已經有check-list)。
E:  主要先進行測試相關工作，但偶爾做點瑣事（例如訂下午茶)。
F:  每年的都是由某資深工程師負責，今年負責人為某甲。
G: 合約到期離開的check-list。




(5)利用實習生培育未來的領導人才：

成熟的企業組織通常趨於緩慢成長。也就是說，除非有人離開，不然從升遷為基層主管的機會將會越來越少。然而，在團隊培育領導人才，卻是必然進行。讓有潛力的團隊成員，負責整個工讀生的循環週期。藉此，歷練作為領導主管會經歷的所有關於「人」的大小事情。畢竟，並非所有技術專精的人都適合當領導者，而透過執行實習生的策略，不只培育了實習生，也可以培育團隊的未來領導人才。即便最後發現某些技術專精的人不適合作為領導者，風險也比較低，畢竟他僅只負責工讀生，不是突然之間負責領導整個開發團隊。

很多時候，即便實習生不能達到原本規劃的要求，光是能夠陪為組織內部未來的領導人才就已經十分划算！

---

註1：「簡單，可學習，重複，但是可改進的工作」和之後提到的「無意義的工作」截然不同。以軟體開發中的測試工作而言，雖然某些情況需要大量人力測試，但是，更多狀況是當工讀生了解測試的意涵之後，大多數都能改進測試的方式，在某種程度達到自動化測試。而「做出」自動化測試程式，對工讀生來說就變成可學習到很多的工作。

註2：但也不能排除剛好招攬到一個天才中的天才的可能性。因此如果真有這樣能力的人，應該直接讓他轉成正職。

問對問題，如履平地。問錯問題，萬劫不復！

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

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

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

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

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

例如：

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

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

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

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

2. 真正的問題很難找到

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

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

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

真正的問題也許是：

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

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

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

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

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

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

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

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

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

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

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

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






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

成長的最好方式 - 反省

曾子曰：「吾日三省吾身：為人謀而不忠乎？與朋友交而不信乎？傳而不習乎？」

反省是進步的最好方式。然而，檢討專案，檢討工作內容，或者檢討自己做對了，或做錯了什麼，卻是需要有結構性的方式來進行。光在腦袋裡想像是很難有具體效果。

普通人大概沒辦法跟曾子一樣每天反省自己，不過，新的一年通常是反思的最好時機。

檢討反省有三個要點：

重點一：目標導向

檢討需要有目標，就算是很隱私的個人檢討也是。反省的目標不同，就會有截然不同的結果。

以帶家人出去玩為例：

如果「全家開心出去玩」是「目標」。則旅途中的延誤，改變行程，物品遺失的檢討目標就應該是如何在意外發生的時候，讓家人仍然很高興的享受意外，享受旅程。

然而，如果心理設定的目標雖然是 ：全家開心出去玩，但檢討的目標卻是怎樣更有效率的旅行，那最後很可能導致全家旅行越來越有效率，但大家心情越來越不好。



以專案管理為例：

在專案完成，或者一個sprint的結束，在回顧檢討(retrospective) 會議的做法，通常是讓大家以「實例」，說明哪些事情做得好，哪些事情做得不好。接下來將這些實例分類，並且用投票的方式，選出最最最需要改善的幾點，指派專人在下一階段負責改善。

同樣的，負責人是以最終目標為檢討改善的目的。假設某手機APP的開發，最終目標是「能在耶誕節前有百萬使用者」，則列出最需要改善的幾點，都必須要朝最終目標前進才對。因此：「與客戶協調上架遞延到12/24日以便確保品質」就是一個不很合理的目標。

要點二：用事實去除人類偏誤

正常人都是以自己的主觀來看這個世界，因此每個人都有對事情的偏誤(human bias)。

檢討與改善的重點在於：盡可能認知人類認知偏誤的存在，讓偏誤在不造成致命影響。不過，要完全沒有影響幾乎不可能。

人類偏誤有很多，舉一些例子如下：

歸因謬誤：對於自己的行為，容易歸類為外在因素，對於他人的行為，容易歸類為內在因素。例如，自己遲到，容易認為是塞車，或者昨天太晚睡；別人遲到，容易認為是他的紀律問題。

負面偏見：人對於不好的記憶印象比好的記憶深刻。這可能和演化有很大的關係，人必須要先規避毒蛇猛獸之類的天然風險。

稟賦效應(Endowment Effect)：同樣的東西，如果已經在手上，則會難以放棄；但如果不在手上，卻認為比較容易取得。例如，自己的車子想賣，總是會想要賣比較高的價格，並且自己也會對這個高價格找出自認為合理的原因。這也是大部分物價易漲難跌的因素，因為銷售物品的人，如果已經用100元能賣出某物品：即便成本降低，即便知道降低售價可能增加業績，但在心理上很難主動降價。





誠如前述，要去除自己「所有的偏誤」是絕對不可能：沒有人是聖人，永遠不會犯錯。但是，去除不必要的偏誤讓自己朝正確的方向前進，卻是不難達到。去除自己的偏誤最好的方式就是根據事實。

因此，在檢討事情的時候僅就「事實」加以檢討。

例如：

事實是「專案每日會議，5個人有3人一定會遲到30分鐘」，根據事實檢討如何讓這3人不會遲到，不需去研究3人遲到的個別因素。也因此，根據事實，將會議時間往後延30分鐘是合理選項。

但是，如果有人試圖追尋某個老是遲到的人的「個人紀律」，「團隊精神」這並非不是事實，只是這類型的事實，沒辦法客觀認定，也不可能客觀評量某一個人的「個人紀律」比另一個人來的好。因此，這些主觀的「事實」，因太容易有主觀偏誤，不應該作為檢討的項目。


再舉另一個例子：

事實是「目前手機APP是使用者付費9美金才能下載，目前每個月約有1個新使用者」

檢討的目的如果是要增加收益，則在現在的事實基礎上，資訊是遠遠不足。因此，這個事實的討論結果勢必是「沒有足夠的事實」可以檢討。

當然要找到所有的事實也是不可能。所以，在這個例子中，起碼找到「新使用者為什麼會買」，「其他類似APP是否收費」，「其他類似的APP在不收費的情況有多少使用者」等等資訊，以便作為檢討的基礎。

方向三：行動優先

反省檢討的目的，不僅只為了知道「我錯了」，重點在於「如何才不會再錯一次」，或者「怎樣讓事情變得更美好」。

誠如前述，人非聖賢，要變成完美的人是不切實際的期望。然而，改變自己的一小部分想法跟行為，讓自己的未來變得更好，卻是可以腳踏實地的達到。

行動必須要和反省與檢討一致，至少邏輯上一致。行動的本身不見得一定要有所「行動」，有時候不做任何事情也是一個選擇，但如同這裡所描述，要確定「不行動」這個選項是和其他選項一起考慮過。

例如：「目前手機APP每個月有1個新的使用者，想推廣給更多使用者」，經過檢討之後，覺得「利用社群網站」：這裏的行動就是利用社群網站推廣。可能是利用facebook的廣告，也可以利用團隊成員每個人都到facebook上貼文，也可以建立粉絲頁。

無論如何，既然要檢討，就應該有行動。沒有行動的檢討，不具任何意義。

---

沈思：你大概多久會檢討自己一次？

資訊科技學生畢業後只想當SA/PM (三個創意作法)

很多畢業生，資訊相關系所，擺明就不想要寫程式，但是卻又想要加入資訊科技產業。老實說如果是做行銷(Marketing) ，業務(Sales)，或者支援類型工作(admin, finance)倒是也無不可。

只是很多資訊科技學生，似乎想要當SA(系統分析師)或者PM(專案經理)，也許只是覺得名字好聽，或者認為：既然是資管學生應該做點管理工作也不為過。

這種想法其實很危險，也不可靠。

系統分析師(SA, System Analyst)扮演的角色在各公司都很不同，有些很像是業務助理，有些是專案經理的小跟班，有些是扮演IT對外採購的角色，不一而足，單看是去哪個公司。

而專案經理(PM, Project Manager)情況可能稍微好一點，顧名思義就是：負責某一個或者一些專案的進行。20年前PMP證照流行的時候，專案管理本身被視為一門複雜的學問，當然在軟體或者新創網路科技產業，PMP那套不太可行，Agile/Scrum/XP 等等方法論興起，讓PM多少都不太可能單純只做管理。

不管如何，缺乏實務經驗(指的是起碼3-4年努力寫程式的經驗)就去做SA/PM等同於是碰運氣，就算花大錢去取得PMP證照以及其他相關證照，也沒什麼用。這就像是從來沒打過籃球的人，想要當NBA籃球教練一樣幾乎不可能。

雖然很不贊成這樣的事情，但與其碰運氣，不如提供實務作法。

(1) 創意一：讓自己真實變成SA/PM (要花一點錢)。

在學校的專案課程中，讓自己變成PM然後讓某同學變成主Co*(註一) 是絕對沒有用的。任何有經驗的主管，一定看得出來你只是負責動動嘴巴，補補文件。

你可能需要付出一些代價，例如100美金，然後想一個app的好主意，到outsourcing網站，像是upwork.com，雇用一些印度，巴基斯坦工程師，實際上幫你寫程式，這時候你100%是PM，你控制了整個專案的進行，負責製作需求與控制工程師進度。更好的是，這還是個跨國專案。

不過，實際上這樣做出來的東西，失敗率很高，特別是假如這次你第一次當PM - 這裏的PM同時兼具Project和Product。因此，對此創意方式要有正確的期待，也就是說事情的成敗並不是重點，而是在此過程經歷了什麼。這非常接近NBA例行賽開打之前的練習賽，練習賽獲勝固然可喜，但比勝利更重要的是團隊的磨合以及戰術的演練執行。

註一： 主co = 負責主要coding。這個名詞是最近幾年面試學到的，意思差不多就是這個專案課程，程式都是我寫，事情都是我做，其他人出嘴巴。

(2) 創意二：組織同學來做專案

等一下，前一段不是說在學校專案當PM然後某同學來主co是絕對沒用的嗎？為何這裡又說要組織同學來做某專案？

不一樣是，組織同學來進行非課堂的任務，遠比修課需要的專案來得困難，但是更實際。

第一種可能是，到市場上接專案本身到不是問題，因為一開始取得專案的目的，並不是獲得高額利潤，因此價格競爭是有可能的，畢竟你的目的是要取得成為SA/PM的事實，並不是真的要從專案獲利。

然而，業主可能也知道，這種情況下的專案可能不見得做的很好，因此價格競爭有時候也沒太大用處。

第二種可能是，自己找事情來進行。十幾年前BBS風起雲湧的時候，大部份架設BBS的人，都並非學校課程，也不是因為賺錢獲利，只是覺得好玩有趣。架設BBS讓當時的學生取得寶貴的UNIX（FreeBSD等）的營運經驗。如果想當PM，也可以自己找事情，組織同學來進行。不過通常這種情況需要是以技術強度來領導，因此遠比接專案困難。

(3) 創意三：尋求業界導師

由於linkedin和其他社交工具的發展，很容易可以找到業界資深的學長學姊。只要是在他們時間允許的範圍，很容易可以請求協助。當然，每個人的時間有限，所以最好的方式是，互相幫忙，互蒙其利。當你在與不太熟悉的人聯繫上之後，可以用交換的方式，讓他們指導你，並且為你的成就背書。

舉例來說：你可以作為業界導師的私人虛擬助理*(註二)一段時間，幫他處理非機密的相關業務，例如，調查研究競爭對手產品，處理文件，處理linkedin或者其他socail media的日常文章，業務聯繫等等。而作為交換的是：他可以指導你實務專案上"他實際上做了什麼"。數個月後，你甚至還可以取得業界導師的背書以及推薦。

另一個做法是尋求成為學徒的機會。學徒制度是一個非常古老的學習方式，在某些情況下，學徒制度非常有用。如果你是一個剛進學校的研究生，尋找指導老師是最重要的一件事。而如果你是一個畢了業就想要當SA/PM的人，找到正確的業界導師，會讓你事半功倍。

我們會在未來的文章探索學徒制與軟體專案發展的關係。





* (註二)：關於虛擬助理，請查Virtual Assistant

---

沈思 

如果本文對你沒幫助，還請與我們聯繫取得免費協助。

1.  再次強調，在沒有技術背景的情況下，最好是別真的想做SA/PM

2.  如果真的想做，那麼務必考慮這三種方式。

3.  當你想要什麼，執行的方式如果是「碰運氣」或者「期望別人給」永遠都是最糟糕的選項，想要什麼最好是先構思自己要怎麼取得。