不管是Scrum Master或者扮演Product Owner，抑或是傳統的專案管理者，在整個專案執行過程中，酸甜苦辣大概只有自己才知道吧。我碰過年輕的工程師表達想要晉升主管的想法。每次碰到這樣的同仁，我心裡面都在想：你真的知道主管要幹嘛嗎？

專案執行面上所要付出的心力，這部分我不再贅述。帶領大家困難的部分，一向都在「人」而不在「事」。如果連面對事情投入的精力都沒有，可能在面對人的事情上會讓你大崩潰。

團隊中如果出現頭痛人物，該怎麼辦？如果想當好人，把人留著，那麼你要怎麼面對認真工作的同仁？如果把人直接炒了，那是否告訴同仁你最好乖乖當順民就好？好，兩個極端都不可行，那還有什麼方式？循循善誘，不斷的一對一晤談，拉近同仁與團隊的共識，然後挑選適當的專案不斷給同仁機會。如果還是無法達成共識呢？丟給人資嗎？人資會開始問一堆過去處理的方式，同仁的回應，例常的考核等等，心裡有沒有浮出一句話：請神容易送神難。

就算順利送走了，每當夜深人靜時，你會不會想起這個同仁的培養過程，你真心盡了全力輔導同仁了嗎？

好，假設團隊成員沒有頭痛人物，大家都互相合作盡心盡力完成專案，那在專案結束或者年度績效評核，你要怎麼給？給不出來所以大家都一樣？或是硬是依照年資高低就交卷了？

就算順利送出考核了，每當夜深人靜時，你會不會想起你的評核方式並沒有真正激勵那些默默努力的人，而讓他失望了？

好，假設你的負責範圍也很單純，不用管人，不用管績效考核，你只需要把大家的工作安排好，那有沒有想過現在這樣Product backlog 排序是最佳的嗎?當外部壓力來的時候，你有全力捍衛開發團隊，還是讓壓力從你身上by pass出去，讓工程師盲目加班?

這篇感觸文，是來自於<領導者的光與影>這本書。當我們在談工程師的敏捷，需要不斷進步與更新時，管理者是否也會不斷的反省，對錯誤道歉與整裝重新進步?

難，但是這是我拿來評量主管適格與否的最重要的標準。