將在12月參加這堂課，事先閱讀了老師及學長姐們的心得，發現可以應對上過去的經驗以及現在工作上遇到的困難。因此寫了這篇心得，以作為紀錄，也期待上完課後能夠更進一步的自已。
【溝通】
溝通的重要性不用多說，無論是在男女交往、工作對上對下對同儕對客戶、朋友間閒聊打屁交換情報，都與溝通有關。然而甚麼才是好的溝通呢？如何才能避免有溝卻無通呢？
首先溝通的目的在於「讓雙方彼此清楚了解對方所想要表達的」。也就是說，重點在「對方」。在傳達之前，首先要釐清自己的想法，確認自已清楚自己想要對方了解甚麼，畢竟如果連自己都不知道要說啥，那就更不用期待對方會知道你真正想要表達的。再者，對方的背景、知識、認知、當下狀態，都會影響到要怎麼樣表達才能夠順利地傳達到對方的腦中。
這讓我想起之前帶領PM團隊時，當公司上頭有個指示，或是客戶有個需求，我都會盡量針對整個需求的全貌先做解說，讓團隊成員對於整體面貌有個初步的認識後，再來針對不同部分的細節做解說，否則就會很容易造成誤解，硬體部門覺得這樣就可以，結果發現跟軟體部門完全搭不起來，然後又影響到機構的設計，就造成整個產品的設計要重頭來過。
而有了整體概觀，了解對方的狀況後，透過適當的表達方式就足夠了嗎？答案當然是否定的！最大的問題是，你怎麼知道自己不是一廂情願呢？
在日常中我們都常聽到，「我以為她知道了....」 「我覺得他應該要懂阿...」 「這不是本來就該想到嗎？」 「這不是本來就該懂嗎？」
因此，確認雙方有共同的語言，確認對方真的理解是非常重要的。無論是在網際網路的設計，或是各種需要互相連接溝通的硬體設備上，我們都會先確認「通訊協定」，也就是在確認雙方有相同的語言、相同的認知、並且確認收到並理解對方傳達的訊息。另一個案例是我們都在電影中看過的：「老鷹呼叫小雞，over」 「小雞收到，Over」，就是在確認對方溝通管道暢通且有相同的語言。當然人跟人溝通不完全是一樣的做法，但概念上是一致的，確認自己的成員理解自己說的，確認自己理解了客戶說的，確認自己理解了老闆說的，都是溝通中非常重要的。每一個認知的確認、每一個小階段的確認，雖然感覺覺得「好像」有點多餘，但如果等快完成才發現一開始就錯了，除了時間問題外，彼此的情緒可能更難平靜下來。
最近回溯過往，其實也發現了一樣的問題：「在確認需求前就自己用過往的經驗來認定。沒有考慮到人的不同，時間的不同，環境的不同，風向的不同，就自顧自己照著以往的做法去做，當然結果是慘烈的。」在前題假設就已經錯誤的情況下，怎麼可能去期待會有正確良好的結果呢？以前老闆總是說著我們要Respect其他人，這也是Respect的一種表現吧。
另外一個好的溝通方式是先呈現出自己的概念，以前還是軟體工程師時，會先完成介面的 mockup，讓客人確認符合他的需求，再開始實作細節。在作產品時，也會先把機子的樣品作出來，然後再藉此確保細節沒有問題。這也都是溝通的一種模式。或許是我總是一直在往前走，疏忽了回溯的重要性，明明之前習慣的做法，卻沒想到相同的概念可以應用到不同的地方。
最後一項關於溝通，是取自於誠一學長的心得(心得見此)「拋棄虛偽的自尊及高傲，真實面對及努力挖掘」。這一點很難達成，卻也很難做到。我們總是說著自己很open mind，然而卻經常不願意面對自己的問題跟缺點，只怕自己那不直前的自尊受到傷害。然而這通常也是我們往下一階段邁進的最大阻礙。
【團隊合作】
團隊合作是另一個重要的議題。而其中最重要的就是：「對於團隊成員的了解是否足夠」。而這個足夠又是要知道哪些訊息才算是足夠呢？畢竟每個人都有不同的背景跟狀況，要了解甚麼？要了解多少才算是可以的？這個問題的答案很難，但就目前的我，我會想要先知道「為了要達成目標所需要知道的資訊」。舉例來說，今天要一起參加接力馬拉松，那過去跑步的經驗，運動的經驗，體力，當下的狀態，都是需要知道的，並以此來安排棒次。那他喜歡吃甚麼，平時喜歡看甚麼書，這些就相對比較可以放在後面一點。
我一直相信，世界上沒有完美的個人，但會有完美的團隊。身為主管，要把人放在適合的位子，他的表現不好，可能不是能力不好，而是放錯了位子。貝爾賓理論說的好，但如何看清楚一個人，如何用適當的方法把一個人擺在真的適合的位子，卻不是三言兩語可以說清楚講明白的。而身為一個成員，如何了解自己的腳色、如何了解自己的定位、如何完成自己的工作，也同樣這要。在工作中，總是會討論R&R，確認各方的責任義務，確認中間要如何銜接，每個人的腳色、每個人的定位、每個工作的職掌範圍與應盡責任。一個好的團隊，有清楚的R&R定義，但成員不會只侷限於R&R的定義，而是願意站在更高的位子去思考：「除了自己應該完成的任務外，可以怎麼更多的幫助整個團隊。」
其實在很多組織中，都曾經討論過「PM存在的必要性」，總是會聽到不同單位說，「如果這個我們做了，那要 PM 做甚麼？」而這個問題，同樣也出現在Google中，當年Google的管理層認為：「Google的成員都非常自動自發又有熱情，我們可以不需要PM，各單位自己可以串的起來，不會有問題，讓我們取消PM這個機制吧。」然後就取消了。然而這個改變並沒有實行多久，幾個月後，因為所有的專案都大幅delay，各單位之間爭吵不斷，無法整合，因此又讓這個職位復活了。在一個團隊中，一個總是知道大目標的角色，一個總是注意時間的角色，一個總是給予大家壓力去符合時程規劃的角色，會是專案與團隊是否成功的關鍵。身為工程師，我們總是希望追求更好更完美的結果，如果放任我們這些只想要滿足自己技術慾望的工程狂自己做自己的，可能永遠都交不出東西。
團隊中每個角色都很重要，每個人負責自己的工作，完成自己的部分，而這個角色的工作就是確保所有進度跟狀態都符合規畫。有野心很好，追求卓越也很好，但這一切都不能脫離目標，若野心跟目標衝突，理所當然要有人出聲提醒，並已達成目標為優先。Alex老師曾經說過：「如果有兩條路，一個是有效，但成功率低，一個是成功率高，但效果沒這麼好，那就選擇成功率高的那條路。」有的人可能會認為這樣太過保守，但如果豪賭一把後來甚麼都沒有，為什麼不選擇穩定可以達到目標的那條路呢？即使那條路看起來沒有這麼帥氣，但以終為始，能達成目的才是最重要的事。注意所有的限制，在這個限制下達到最佳的成果，並非保守的不去挑戰，而是在風險可掌控的情況下勇於挑戰。
當然，你不會永遠都遇到超強的神隊友，也不會永遠都有足夠的資源給予你足夠的人手去完成團隊配置。遇到這情況，溝通與目的的釐清跟目標的設定就更顯出他的重要性，為了達成目標，每個項次的優先權，哪些事是最重要一定要做的，這些事情的時間先後順序與資源上的運用會是怎樣的。在專案管理中提到的「Critical Path」告訴我們最關鍵的那條路，是必須要被找出來並時時緊盯。
最後一個關於團隊合作想記錄的是：領導者。
我總是跟 PM 們說：「要心懷感恩的面對你們帶的專案成員。就像我一樣，我總是跟老闆說，如果我們團隊成功，是整個團隊每個人的功勞，如果我們團隊失敗，一定有我的責任。我最大的工作就是，盡一切努力幫助你們成功。」
一個好的演員，總是盡力的幫助對手那位演員呈現出最好的樣貌，在彼此互相扶持的情況下，才能成就一齣好的對手戲。
正如同雅樂學姐在心得中(心得見此)提到可以分享自己成功的方式，不一定是給自己的member，甚至可以分享給自己的主管，來幫助整個團隊都更加進步，這種幫助他人後讓自己也更好的想法，非常適合用在平時團隊的合作上。
【問題解決】
要解決問題前，要先知道問題在哪，要先能夠擁有自己定義問題的能力。沒有找到過去的問題，只會一直重複著相同的錯誤。最近跟團隊在回溯過往的幾個月，列出時間軸，透過回溯、解構、換位、重做的概念去檢視過去(1) 哪裡做得好？背後的原因跟做法 (2) 哪裡做得不好？背後的原因跟做法。老師說：「丟一個銅板也有50%的機率是正面。」如果結果是好的，一定要知道自己到底是哪裡做得好，為什麼會成功，如果連自己為什麼會成功都不知道，再來一次又怎麼會成功呢？檢討失敗很重要，每個人都會犯錯，但如何讓自己不再相同的錯，累積起來後會產生巨大的差異。然而，一個常被忽略的是，檢討成功，經常成功後就會忘記要去檢討為什麼成功，那些導致成功的行為跟動作是否可以做的更好？
除了檢視自己外，透過觀察競爭對手也是一個好的策略，透過詳細的觀察對方為什麼成功，對手的進度跟方法，背後的關鍵原因是甚麼？可能不容易一眼就看出到底關鍵點是甚麼，但如果不深入去思考，很容易就被表象所蒙蔽欺騙。為什麼 A公司那樣做會成功？為什麼 B公司做同樣的事會失敗？如果沒有發現關鍵原因，只覺得人家成功照著做就會成功，那可能只能靠銅板的運氣了。
看懂問題，了解現在進行的節奏，然後跟著節奏去踏穩腳步，在不同的時間下進退之間的掌握，會影響最終的成敗。
在尋找問題時另一個常見的問題是：陷入了思維的小框框，只看到眼前的這棵樹，卻看不到整片森林。我們要提醒自己要注重細節，要知道如何實行如何落地，但也不能忘記大方向，不能忘記目標到底是甚麼。有時換個角度去看，會發現其實真正要解決的問題並不是眼前這個問題，而當我們解決了另一個問題，眼前這個問題也將不再是問題。找出真正的問題，具體的描述他，找出執行的細節，做出一個任何人只要找表操課都能完成的提案，當計劃夠周詳，執行就只是執行。
這邊想提另一個關於談判的小例子，上完談判課後，我回溯了無數次，也列出了自己的問題點，然而，針對這些問題究竟要怎麼改善呢？我思考了很久，最後的作法是把這些問題再細化到每一個小步驟，確認自己能夠做到每一個小步驟，然後再一關一關往前挺進。當然，為了要確認自己是否有在正確的路上，時間的紀錄，進度的紀錄，回溯的檢討都是十分重要的。讓自己可以更快地鎖定目標、更快的下決策、更快的看到問題，這不是口號，而是要透過一次次的檢討，一步步訓練，讓自己擁有足夠的敏感度才能達成。
回過頭來，關於規劃跟執行，記得當年在寫程式的時候，花最多時間的都是在思考跟規劃架構，一但在紙上把想法都釐清後，最後的實做都沒有花很多時間。
然而，這個世界才沒有這麼美好！是誰說規劃的就一定會照自己的想法進行？當然不！而且大部分的情況可能是想的不夠周全而跟自己預期的結果就是有落差。所以，我們可以透過像是SCQA的方式去思考並規劃，在規劃後，該做的就是「快快做、快快改」！
【加強績效】
說到績效，總是會想到 SMART、KPI、OKR等工具，有的主管會把業績訂得很高讓成員去追，就算只能達到八成也會比原本的結果好。有的主管會要求我們KPI中定出來的只是基本盤，如果只做到這個，那考績也就是B，要自己能夠提出自己有甚麼額外的貢獻，才有可能讓自己的考績再往上爬。我想這都是加強績效的手法，然而如果從專案管理的角度，還有一些更細節的做法，例如在專案中增加檢核點，在時間上壓縮不給buffer，而把最後的buffer都抓在手中，都可以有效加速專案的進度與完成度。
然而，這些招數是不是對所有人都有用呢？不同的老闆是不是喜歡不同的表現方式？針對老闆的想法跟你的想法不一樣，身為主管卡在中間的情況下，能有甚麼方法可以加強成員的績效又同時滿足老闆呢？這些問題說真的，我也沒有答案。讓我們一起期待上完課後是不是能夠得到進一步的想法跟答案。(絕對不是要留些東西當作上課心得來寫 XD)
最後，要感謝老師開這堂課，以及感謝學長姐們精采的心得讓我可以從中學習這麼多東西。我沒有上過課，所以其中可能有些地方跟課程想要傳達的有所偏差，但能夠透過心得來結合自身過去經驗，依然是個非常好的體驗。
