[讀書心得 part4] 交辦時，務必說清楚、想明白

大家好，我又來分享讀書心得啦 ^^
今天跟大家分享訣竅三

1. 勉強他的能力，不要勉強他的意願
• 話說沒有意願，能力再好都是枉然，可見意願的重要性。所以平常一定要跟member混熟，指派工作的時候，一定要了解他的能力是否有辦法完成這個交辦，如果有辦法完成自然比較好說服，如果比較難完成，那在指派的時候也一定要想辦法說服他。我很常會用的招式是:你把這件事情完成，你就會學習到以後該怎麼處理這樣類型的工作了。目前看起來成效很爛(冏)
2. 他有沒有個人目標，會影響工作成敗
• 說真的，我也覺得這點很重要，但問題要讓member有個人目標其實真的還蠻難的，我也曾經幫member訂過目標，但效果其實不符合預期，或許我該找時間好好來跟member談談他的目標到底在哪?
3. 不合理的工作要求，交辦給誰最好呢?
• 我覺得交辦給誰都不好，所以如果可以把不合理的工作要求合理化，那交辦出去的機會可能會大一點。例如寫程式，一隻程式可以花一天沒架構沒規劃的方式寫出來，也可以花三天好好的規畫寫出來，當時間急的時候，你要一個很有sense的member花一天寫出來，你該如何說服他?去年我就常遇到這樣的事情。那時候跟我合作的member能力非常好，但對程式撰寫有一定程度的潔癖，說真的，要我寫出一個很糟的程式，對我來說也是一種虐待。所以我會先跟他討論，跟他說目前事情的急迫性，以及目前會跟老闆報告說現在的方式會產生的問題，日後我們需要再額外花時間來refactor目前寫的程式，讓老闆知道。還好那位member跟我交情還不錯，我們就這樣完成了大多數的程式，之後有被refactor的部分也有80%以上。
• 所以我寧願先讓事情盡量合理化，再來做所謂的交辦，萬一不行，也跟member討論出平衡點。
4. 他不是你的分身，做法不一樣，千萬別跳腳
• 話說寫程式裡有一個流程叫做code review，通常是組織裡比較資深的member幫比較資淺的member review code，review的過程中，可以提出建議的做法，以及指出有問題的地方。我覺得code review 對我來說也是練功的一種，有時候可以看到自己沒想過的作法，當然有時候也會看到讓自己氣得跳腳的寫法。從寫程式就可以知道，針對同一種需求，不同的人去寫程式，通常不太可能寫出一樣的code，但只要知道目標在哪(這真的很重要)，確定過程中都是往目標的正確路徑，我想就算中間稍微停頓看個風景也不為過。

[讀書心得 part3] 硬塞前，先慎選人與事

今天來跟大家分享【交辦的技術 讀書心得 Part3】

1. 交辦標準，不是看他做不做得到
• 作者說交辦是指把這件事情的【責任】交付出去給member，member在接到工作的同時也同時擔負起完成這件事情的【責任】。身為Leader腦袋真的要轉過來，雖然明明知道很多事情member其實並沒有足夠的能力來完成，但如果一昧的攬在自己的身上，到頭來只是讓自己更累，團隊產出更少，而且少了培養member的機會，會讓整個團隊的競爭力降低。
• 當member承擔這個任務成敗的【責任】後，勢必會更用心的去處理，過程中千萬別插手，一插手，事情的責任馬上就轉到自己身上了。例如，你叫member寫一個專案Deploy的SOP，過程中如果你插手給予意見，則member勢必認為只要把你的意見加入，就萬無一失，有問題的話也不是自己的問題，因為已經參照你給的意見來執行了，所以身為Leader千萬要忍住。
• 當然還是要評估這件事情是不適合由該member來執行，如果難度太高，一樣會陷入【交辦失敗】的魔咒，所以身為Leader可能還是需要想一些方式讓Member可以較順利的執行該任務，藉由完成該任務來提升member的能力。
2. 三種工作，別突然硬塞
1. 陌生的工作
2. 非緊急重要事項
3. 指派人力的工作
• 針對上述三項工作，我覺得比較有趣的是【非緊急重要事項】。前陣子剛好看了某時間管理的文章，文中將事情分為四個象限，分別是【緊急】、【重要】、【非緊急】、【非重要】。將這四個象限去組合，則可以得到【非緊急重要事項】。而處理這四個現象的先後順序分別是1.【緊急重要】2.【非緊急重要】3.【緊急非重要】4.【非緊急非重要】。很多人常常把2,3處理搞混，連我都不例外，不過只要接受這個理論，就可以順利地交辦的事項一一完成。
• 所謂【非緊急重要事項】通常是長久規畫的策略或方針，將這類的事情交辦給部屬，無疑是主管自己無能(機會高)，或者真的是member能力超好(機會低)。member對於due date還很久的事項，通常較缺乏經驗去執行，而且這類的事物通常有很多事情並非member的權責可以決定，例如:半年後的新專案開發架構。身為Leader必須將這類事務細分成多個工作包(WBS)，當細分成WBS後，即可讓每個WBS依序成為【緊急重要事項】，則member依WBS的順序去執行，則每個階段就都可以有產出，最後完成這個【非緊急重要事項】。
• 至於另外兩個【 陌生的工作 】和【 指派人力的工作 】接導因於member對這類交辦經驗薄弱，例如 指派人力的工作，member可能連自己要完成某個交辦需花多少時間都估不出來了，你還要他去指派別人工作? 
3. 預防災難，你得會看人
• 其實這個部份我還很少機會用到，書上指的是要會用【領導人】，小弟我還沒機會成為可以指派【領導人】的人。不過重點還是開船著船長要知道目的地在哪，路線規劃要漂亮，相關環境變數收集齊全，才能順利帶領船員，快快樂樂的出航，平平安安且順順利利的到達目的地。
4. 菜鳥和老鳥，交辦方式肯定不一樣
• 這應該是廢話，但不知道會不會有人白目到連這個都不知道。不過菜鳥分兩種【能力好的】跟【能力差的】；老鳥也分兩種【能力好的】和【能力差的】。針對菜鳥當然再交辦事項的時候要給予適當的指導，但遇到能力好的，更需要給予適當的發揮及尊重，這是我個人的感覺。而老鳥部分，能力好的就給予極度的尊重，但別忘了還是要訂一下schedule，能力差的我會跟他討論，並希望盡量藉由討論來取得他願意執行的平衡點，重點還是schedule要訂一下，不然滑掉的機會很高。

[讀書心得 part2] 做中學你硬塞給他就對了

今天來分享【交辦的技術 part2】

1. 交辦工作，不用等到【對他有信心】
• 我覺得像我這種菜鳥leader，或者好人leader絕對想不到這一點，腦海中想到的都是怎樣把member有辦法處理的事情交辦給他，所以都會自己花時間把難的部分先解決掉，剩下比較簡單的部份還會先跟member講解該怎麼處理。作者說的對，想當初人家assign給我job的時候也很少教我該怎麼去處理，或許懂得如何自己去處理的人才可以真正的成長，我覺得我腦袋沒轉過來反而阻礙了member成長的機會。
2. 成長，都是勉強來的
• 同上，記得有一個理論是說，如果你針對一件task要達到至少80分，那你就要求自己或member往100分的目標去邁進，就算沒能達到100分，應該至少都有八、九十分的水準。雖然自己很討厭別人凹我，但我不去凹member，那到頭來只是讓整個團隊的績效都卡到自己身上而已，於團隊的進步跟產出沒什麼幫助。
3. 你得【保障】他的失敗機會
• 作者說，當你把工作指派給member的時候，他就同時被賦予需要擔負這項工作成敗的責任了。也因為擔負了這個責任，他才能更用心地去完成這項工作；不過並不是每件事情因為擔負了責任，努力去做就一定可以順利完成，當Leader的我，通常腦海中想著該怎麼樣讓事情順利的進行不要出錯，但這卻是最要不得的想法，待我說來。
• 首先如果自己想讓事情進行順利的想法，必定就不希望member往錯誤的方向邁進，或著允許他交出錯誤的成果，但像寫程式這種事情，不讓他去try error幾次根本就學不到經驗。我有時候會太龜毛幫member寫一個template讓他照著寫就好，孰不知這樣讓他少學習到很多，到頭來事情做完了，他還是沒學到東西，講白一點，下次一樣的事情要他做他可能還不知道從何開始，因為我的雞婆讓他少了學習的機會。
• 唯有接受member失敗的結果才能讓他真的去學習到東西，雖然這真的很天人交戰，尤其老闆壓我schedule的時候更是難以實行。但如果不狠心讓schedule滑個幾次，永遠都沒有讓member學習的機會，永遠事情都只會壓在我自己身上而已。當member有從交辦的事項中學習到，下次處理類似的交辦工作才能真的獨立去完成，但是要在schedule與讓member學習抉擇，真的是一件很難的事。
4. 想培養他，就從【分外】工作開始
• 其實作者說【分外】的工作指的是leader的工作，像是協調利害關係人相關的事務，以及做一些規劃類事情。我覺得這一點真的要睜大眼睛去看你的member是怎麼想的。如果你常把這類的工作交辦給member，正面一點的member會覺得有磨練的機會，負面一點的大概就會覺得你在凹他了，就像我常常覺得有某人在凹我一樣。這時候怎樣把交辦這類的事項用漂亮的方式包裝好再交給member就是一項學問了。
• 講白一點，就是想辦法說服member能心甘情願的去處理這類的事物，而不要讓他覺得被凹了，我本人就很討厭被凹的感覺。但我也知道事情總是要有人處理，今天這件事情會落到我身上，大概也是凹我的人schedule嘎不過來了，但如果他能說出漂亮的理由說服我，我可能就傻傻地覺得處理這樣的事務也不錯，可以學到額外的經驗，反之，下一秒我就會跟別的同事抱怨說:【你看，XXX又那凹我了!!!】。相同的道理，身為leader有這類的事情要指派，還是要學會察言觀色比較重要。

其實在寫這些心得的同時，我也常常在想遇到相同的事情自己該怎麼處理。也希望大家能分享一下自己的經驗及想法。

[讀書心得 part1] 交辦的技術

 這本書是透過博客來的eDM才看到的，剛好這陣子遇到了。看了一下書的介紹感覺還蠻有趣的就用禮券去金石堂買了(哈)。

雖然說我不是主管，但卻一職被賦予要帶team member做事的使命，我從事軟體相關工作，從工作到現在大概六年，除了第一年沒有帶member，之後幾乎每一年都需要帶member做事，這時候member能力的好壞，以及我跟member之間的關係就嚴重地影響到工作的成果。

底下要分享的是我自己的心得對應書裡的章節

當主管第一件要學的事 (先說我根本不是主管)

1. 放手讓他做，他就會成材
• 我的經驗來說，要放手讓member還是要考量member的能力。如果member能力不足，放手讓他做只會造成他的壓力，但我卻一直忽略了壓力才能讓人成長，不過我個人覺得只有適當的壓力才會讓人成長，過多的壓力只會壓垮member，所以要衡量交辦一件事情對member造成多少壓力其實不好評估。我只知道能力好的壓力應該會比較低，能力差的壓力應該很大。
2. 交辦失敗會摧毀一個人
• 最近一位我帶的member因為能力不太足夠，我所交辦的每一件事情感覺對他都造成了莫大的壓力，但這件事情我卻是過了一陣子才發現，喪失了讓他學習的機會，因為能力不夠的關係，應該已經讓他連學習的時間或想法都沒了，尤其我所從事的工作是需要寫程式的，寫程式這種東西會的就是很快，不會的你給他再多時間可能都不夠。如果我能早點發現他的能力不足，或許可以提早訓練他，但目前因為專案時程都很趕，有時候跟他的對話都會因為他完成事項的不足而露出不滿意的話語，我想這部份真的很值得學習。與其交辦失敗摧毀一個人，倒不如想方法讓這個member變成可用之材還比較好。
3. 糾正【無法交辦】心態的訣竅

• 這裡主要是說，對於事情要不要交辦，主管的心態會去衡量說
1. 這件事情太難，還是我自己來好了
2. 這件事情太簡單，我來處理比較快
• 其實身為一個leader如果不適當的把手中的事情交辦出去，最後只會造成自己生產力降低而已，對老闆來說身為leader的你的產出，不應該跟身為你member的產出是一樣的價值的。身為leader應該著重在規劃，再把規畫要做的事情交付給member，這樣才能提升團隊的績效。所以不管什麼事情，只要是可以交辦給member的應該都要盡量的交辦出去，不然最後member沒事做，自己卻因為事情太多處理不完而成為團隊的bottleneck，對團隊來說是一點幫助都沒有，所以應該要往這個方向去邁進，member也能從交辦的事項當中學習到處理事情的經驗，就由交辦事項提升能力，期望能一舉兩得。

其實在PMP中也有一個領域是在講Human Resource Management的談到獲得專案團隊、開發專案團隊及管理專案團隊，遇到人的問題真的去實施都是很難的。