給追求高效工作的您：懂得歸納團隊目標陣行持續前進

圖片來源：FIFA WORLD CUP粉絲團

試問自己在工作上您自己、或您待的團隊、甚至您領導的團隊常常有以下狀況：

• 覺得事情又多又雜，無法決定哪件事情該先完成
• 覺得高層主管老是空穴來風，常常拍板分配一堆芝麻蒜皮卻又一定得做的工作
• 覺得客戶永遠有找不完的碴，三不五時就要來打斷既有工作規畫與進展
• 覺得團隊成員無法跟上自己的腳步，千叮嚀萬交代還做不好事情
• 明明團隊用了著名的敏捷框架，也執行每日站立會議、每週review會議，但事情永遠像是炸了鍋處理不完

如果有以上症頭，代表團隊已經出現工作量與產能入不敷出的狀況，不管如何，以下提供個人、團隊運行兩種建議。

【給團隊】

• 首先我們要有一個認知，工作量已經無法讓團隊消化，那身為主管的您，是否有辦法把不重要但卻要花時間的瑣事給減量甚至直接幹掉。舉例來說，每日站立會議是否能避免流於形式的流水帳工作報告，把落落長的每日30分站立會議縮為5分鐘的有效溝通會議。舉例來說，弊司在2019年全公司導入SCRUM作為敏捷開發的框架前，個人早在2013年領導團隊時就已經率先運行，因為有著多年一線開發經驗，我知道怎樣的溝通細節會是團隊所需，加上每天都在站，所有團隊成員的進度早已聊若指掌，所以常常在專案一忙起來，我就會直接不讓團隊成員一一報告，取而代之是我用幾句話直接總結，然後散會。
• 或是有些例行性報告，乾脆省略讓團隊專心在客戶或長期目標需要的產出即可。
• 身為主管(或是PM)要非常清楚專案短、中、長期分別要完成的目標有哪些，千萬不要連自己在哪邊都不知道，然後接近Deadline時都還沒把進度分配給成員去執行。
• 如果主管忙不過來，請適時的授權；好的授權不僅可以加速產出，提升團隊成員成長，而不是嘴上說一套要培養優秀接班人，但卻連放手都做不到。
• 溝通效率：當面 > 電話 or 遠端語音 > 訊息 > 郵件 >>>>> 糾結於團隊內部討論，卻不實際找業主、第三方討論確認。
• 只參加跟團隊有關的會議，請把時間用在領導團隊而非到處開會。

【給個人】

• 雖然最近很流行Quiet quitting一詞，但其實學會有效率的工作才是達成此心流狀態的最佳實踐。
• 對於有升任主管企圖的同仁，學會向上管理、適時向主管反應你想擔更多的責任。不過世間本來就無法事事順心隨意，常常你很努力工作、也能高效並超越期待的完成目標，但主管還是無法放手... ...如果是這樣沒必要讓自己委屈，講到這應該就懂了吧。
• 只參加跟自己有關的會議。

【Best Practice】

• 找一個頭腦最清醒的時間，依個人經驗是早晨，所以個人非常、超級、無敵討厭早上就要浪費時間開會。
• 不要一到公司就馬上收信、什麼都不想開始工作，請先保持清醒的把事情全盤統籌review，快速排出優先順序，規劃出來，畫出一張心中對於團隊的短、中、長期的目標陣行。
• 有了目標陣行後，不管此時再來什麼樣雜七雜八的瑣事基本上也無所畏懼，依著目標陣行讓團隊持續前進即可。

之所以能成為賈伯斯(Steve Jobs) | 陪你讀冊 | 皮克斯動畫的管理心法

    今天在這裡介紹一本管理書籍，是由皮克斯(Pixar)動畫的創辦人卡特默爾(Ed Catmull)經由超過40年匯集的管理經驗，也許大家會狐疑，市面上有這麼多的管理教科書，為什麼又要特別花時間來讀他(台灣銷售量似乎也不好)，就讓我們脫離東方奴才式管理的思考來看看這件事情吧。
    一切，我們先從賈伯斯(Steve Jobs)來說...

沉潛的背後

   賈伯斯(Steve Jobs)，應該是現代少數無人不知曉的人物，因為他成功讓Apple Inc.打造 智慧型手機 iPhone，這項跨時代產品，不僅讓消費者為之瘋狂，更讓某些企業也想跟隨腳步打造"所謂產品"這檔事，東施效顰之事屢見不顯。

    個人一直很欣賞幾個企業家，賈伯斯是其中之一，Walter Isaacson的賈伯斯傳(Steve Jobs)個人中英文版都有入手，中文版至少從頭到尾看了三次以上，甚至連Audio都被我搞到手...

    另外一本號稱是蘋果公司授權的成為賈伯斯(Becoming Steve Jobs)最近個人也已拜讀，要說這兩本書最大的差異是成為賈伯斯(Becoming Steve Jobs)由數十年來與他很親密的財經記者撰寫，其中增添許多賈伯斯不為人知(起碼在我看了這麼多網路文章、訪談)的個人小故事，例如他為何要接受到史丹佛大學進行他這一輩子唯一的畢業生演講(後來被譽為少數經典演說之一)，在入場前他與全家人一家五口的小故事；還有賈伯斯並非一個殘酷的暴君，他與同事、合作夥伴間的親密互動相處。

    以上只是前言，我們要思考的是，賈伯斯因為人為廣知的火爆個性，加上自己太年輕並不具備管理一間大型企業能力，而在1985年被自己一手創辦的Apple逐出；卻在11年後的1997年回到Apple，然後不過13年的時間就把Apple推向世界最有價值的企業，詳見下圖。

圖片來源：https://vktailormade.files.wordpress.com

    所以我們要思考這樣的轉變，或是為何Apple可以達到這樣的成功，是怎麼來的？

十年磨一劍

軟體開發真的沒有銀彈嗎？淺談世界級軟體開源社群運作

圖片來源：One Piece

無人不知的軟體神書人月神話：軟體專案管理之道(The Mythical Man-Month: Essays on Software Engineering, Anniversary Edition)其中一個章節提到人月神話這個迷思，簡單解釋，以工程學來說，今天我用50個人建一間房子需要100天，那工程上因為可以拆解工作，所以理論值(大量的平均數來看)可以用500個人在10天內建一間房子；這就是一種人月工時結構的估算。

很可惜，軟體並不是工程。軟體開發是一個很殘酷用智商高低決定勝負的領域，以開著同一款車，一個頂尖的賽車手頂多就比普通會開車的人快個2-3倍，但軟體頂尖程序員跟普通程序員可以差到百倍(the measure indicators should be include quality, scalability and stability)。

但今天透過網路無遠弗界的集結，開始有著一絲可以打破人月神話的運作機制存在，這個機制就是開發者社群(Community)。一個好的開放原始碼社群透過制度、標準、流程、規範有效集結世界各地志同道合的夥伴。以OpenStack開源社群為參考說明。

開源社群運作基礎流程：

1. 先有個code base，最小可能就只有幾千、幾萬行程式碼，然後由一個或兩個單位維護研發，eg：NASA, Rackspace。
2. source被open，並且License Agreement被擴張為Apache License，簡單的說就是拿到這個授權的程式碼，你可以無償的使用他，拿來改、賣都沒關係，隨便你搞，但前提是組織不負後續責任。通常這時候就會開始吸引到市場的鯊魚。
3. 忘了說，一定要有個源碼版控系統。
4. 社群建立，會開始進行幾件事情：
• 建置官方網站，繪製個吉祥物mascot感覺比較沒這麼枯燥乏味。
• 釋放Release Note(說明這個版本主要完成哪些功能)、發佈各種進程的版本(alpha, beta, candidate, stable, )、發布版本、定出版號、
• 針對社群貢獻者(contributors)會給幾條較有法律性的規範CLA(Contributors License Agreement)

研發主管職秘辛

圖片來源：http://s1.djyimg.com/

一些心得分享。

所謂團隊：自主運作、團隊產出與人力(數)成正比、隨時可以增添或拆解人力。
現在的團隊已經處於一個穩定狀態，透過兩週固定一次的例行會議，或是臨時性任務的E-Mail電子郵件交代，設定好人員、目標、時間，成員就能自行準時完成並且回報進度，以公司經營來說有點算是達成人力與目標的break even。雖說團隊規模還不大，但依照這樣的模式要擴大、因應新任務承接根本不成問題，並且依照人力的增補可以獲得相對應的工作產出，才是真正的團隊！這時候我就不需要注意細節部分的領導，可以把時間分配並專注於新領域的技術、市場導向研發。

個人領導原則：
個人其實在接下職務以前，早就對自己有所目標設定，兢兢業業不忘自己的領導原則。

自主型的團隊運作：
由於團隊是全新成立，為了讓大家及早進入狀況，採用敏捷式開發、每日站立會議方式提高成員間的溝通互動、大家對產品技術熟悉度。個人覺得強迫性導入敏捷的精神：時常溝通、不斷檢視是團隊現在能自主運作的最大成功因素，大家在需要的時候就迅速集合、快速討論、立刻下決定的處理方式，個人引以為傲。

除了滿足上級需求，更要培養菁英團隊：
一個主管的成功，如果只成功自己，個人不覺得是個成功領導。成功領導應是團隊性。怎麼培養真的是門藝術，要讓底下的人成長，成長到足以取代自己的位置，這樣自己才有基礎往更高的階梯上爬。
    至於如何滿足上級需求，這又是另一門學問了，簡單的說就是要用老闆的角度來思考事情，這裡不多述。

如何幫團隊擬定執行策略：
個人覺得這是件相當困難的事情，莫非定律表示：事情永遠在你很忙的時候，會冒出更多事情，所以幫團隊擬定最好的執行策略是當一個主管或領導最重要的任務：

1. 先找出最適合的人來負責事情，但要記得賦予權責：這裡講的是最適合，而非最好，大家都知道每個人專長都不一樣，有些人適合處理人際關係、有些人研發能力很強但可能文筆不是很好、有些人統御能力很強、有些人測試規劃很強，這些都是需要長期觀察並且試著去交辦任務才能發現，絕對不是把所有的事情往最強最厲害的人身上丟就沒事，那要你這個主管幹嘛？在強在厲害的人一天跟其他人一樣都只有24小時，主管要做的事就是去找出最適合的人選。找出人選後，要懂得授權，負責人有權利去調度人力或安排資源，不能讓他覺得綁手綁腳，最好也不要給其太多限制(除非觀念有所偏差，但這樣就不應該是你挑出來的人選)，讓成員有機會成長。
2. 給訂明確的目標

你在做，主管怎麼看

暨寫完軟體主管的喃喃自語：領導原則，這是給自己看的，藉以提醒自己不要走失了方向。領導團隊一陣子了，看到了一些現象，也有些心得與感想。

主管要幫你沒錯，但不是你的管家：
    每間公司都有既定的體制與規則，當然部門與部門之間也享有或是管理不同資源的責任，舉例來說，今天你的團隊明天要出外景，然後你發現自己沒有攝影機，臨時採購當然來不急，這時候就要去跟別的部門商借，這時候可能就要動到主管去跟其他部門交涉攝影機的使用資源(只是舉例)。但接下來的工作，包含借攝影機可能需要填什麼表單、是不是還要借電源線、是不是需要借鏡頭、機器的使用方法等等，就應該你要自己處理了，而不是還要主管幫你換這些工作層級的尿布。
    也許你會問，那到底什麼時候可以請主管來幫我？很簡單，就是這件事情你自己喬不動的時候，需要有權力的人來推一下。除此之外，個人建議盡量就別動用到主管，畢竟主管真的很忙。
    怎麼說忙，你又會問，我看主管都沒在做事情阿？有帶過團隊的人應該都能體會，當成員有問題來找你，假設光是一個對話(成員說明、內容對話、情境了解、給定決策)需要10分鐘就好，然後你每次打斷主管思緒後要讓他在回到原有思緒，總共算15分鐘好了，假設你的團隊有10個成員，大家每天都來問一件事情就好，主管就要花兩個半小時跟團隊周旋... ...這樣的算法還沒算到跟主管的主管、還有別的團隊的主管周旋。

工作分配下去，團隊都有定期開會，我還需不需要另外回報進度？

軟體主管的喃喃自語：領導原則

圖片來源：www.nipic.com

大方向：

不是很喜歡主管這個詞彙，主管感覺只是在管人、管事，但其實在管理階層要做的事情不能只是管理，要能找出團隊未來的方向，雖然對台灣人來說會很反感，個人倒是覺得用"領導"才是比較洽當的詞彙。


領導(主管)認知：(個人立場)

1. 謀定而後定，避免朝令夕改：要認知主管的一舉一動、下達指令都是成員們的圭臬，要是今天主管請你研發A，後天跟你說改成研發B，再過幾天又跟你說要研發C，想必大家都會無所適從，專案進度永遠都在歸零。所以個人在下每個命令或指導棋之前，絕對不會脫口而出，都是在腦海中沙盤推演這個命令下去後會讓多少人投入資源，投入資源後會獲得哪些產出，再藉由這些產出能不能達到目的才會下這道決策。要知道主管的話語對下屬來說就是指南針，今天你自己都抓不準方向，又要如何讓事情獲得成功？
2. 必須有扛責任的覺悟：團隊成敗與否絕對是在主管身上，別想怪罪到下屬上；要是主管老是以"員工不認真"、"員工能力不足"來搪塞失敗，那上級長官又何必賦與你主管職，一個主管存在價值就是在於領導團隊的成功。
3. 不是只為上司負責，更要為成員的未來負責：設想一個情形 - "如果今天你所在這間公司突然倒閉了，你的成員都有辦法、有能力找到別的工作嗎？"主管的任務不僅是要完成上面長官交代的事情，同時間你應該要為下屬的能力培養盡到責任(除非你的下屬就是沒有心思學習，另當別論)，今天你交辦給他的任務應該是要有技能性、學習可能、有競爭力的。

Note of daily stand-up review 每日站立會議執行心得

圖片來源：http://martinfowler.com/articles

滾石不生苔的法則，適用於惡劣不斷學習的職場、男女之間的感情維持、朋友的交際應酬，當然軟體工程也不例外。

問題在於，要怎麼讓石頭滾起來呢？又要怎麼判斷有沒有滾起來呢？所以某人堅持要搞執行每日站立會議(Daily stand-up review)。

目前團隊跑了剛好一個多月，執行方式：

• 每日早上九點初準時開始，全員參與，因為開得很快，在其他團隊要用會議室前就結束了，連會議室都不用借。
• 站著開會，因為乳酸會在站立的姿勢下快速積累於雙腳，能有效加快會議速率。
• 用google doc進行條列式追蹤，追蹤項目只寫三件事情：昨天我做了什麼、今天我要做什麼、我需要什麼幫助。
• 在大家報告完後，再行同步其他資訊(某些情況這件事情可以當作熱場用)。

在這裡先澄清一件事情，並不是所有的開發團隊都適用於每日站立會議，首先有幾個條件要滿足：

• 人不能太少，四人以下團隊基本上就免了吧，因為整天就是這幾個人在你看我、我看你，幹嘛還花時間開會。
• 人不能太多，雖然目前個人團隊還沒超過十個人，但依現在的負荷量來說，超過十人來開每日會議就會浪費太多時間，每個人報告個3分鐘，全部人報告完就要半小時，還沒有加上其他議題的討論時間。
• 主席(可能是PM或SA)要有一定的技術能力，否則開了也沒意思，直接用功能完成度來追進度就好了。最好是能當場就決定某些技術環節要如何解決、誰來解決、何時解決，否則議而不決真的沒意義。

所謂的每日站立會議有幾項原則：

• 時間不能太長，因為腳會痠。
• 主席減少發言，最好是

陪你讀冊 | 當責，從停止抱怨開始

奧茲法則

當責(Accountability)一詞，是今年過年父親給我的一本管理教科書看到的，但當時書籍內容過於偏向理論、教條式解說，個人就沒仔細閱讀。而這次筆記書籍則是用全球著名小說綠野仙蹤桃樂絲的故事做為破題，舉了許多實際案例，採取引導式發問、問卷自我檢視等實作面向說明如何做好當責這件事情，以下是重點的心得筆記。

一、個人當責
[當責秘笈]如何辨識自己落在水平線下，落入水平線下被害者循環的18個警訊

1. 感到自己為際遇所困。
2. 覺得無法控制現況。
3. 當別人告訴你可以更努力更出色的完成結果時，卻是一場忠言逆耳。
4. 發覺自己在怪罪他人。
5. 討論問題時，越來越集中在自己做不到的事情，而非自己能做的事。
6. 無法面對艱難的問題。
7. 發現自己成為某些人的取暖對象，這些人告訴你，別人這回又對你如何不仁不義。
8. 發現自己不願提出深入的問題，以了解自己是否有能力當責。
9. 認為自己遭受不公平待遇，而且無能為力。
10. 不斷發現自己採取防禦的姿態。
11. 花許多時間談論無法改變的事情(例如：職場、股東、政府、景氣)
12. 發覺自己茫然失措，但