先前的文章我眼中的 pro programmer，討論到一位專業的程式設計師，該有什麼樣子，當時的文章最末段也想過，該找個人寫篇 pro leader 的模樣典範，而今天剛好看到InfoQ提供了一 篇文章的翻譯：優秀的領導與差勁的領導，原文是 Vlad Mihalcea 的一篇文章：Good vs Bad Leader，內容是討論一位專業的 leader 該是什麼樣子。
翻譯文章的內容雖然跟原文一樣，但是卻放棄了遵循原文表格對照的寫法，這降低了文章的可讀性。我並沒有得到原作者的同意，可以將整篇文章逐字翻譯，但我想我可以原作者的表格方式，然後嘗試用簡單幾句話做個整理。
| context | good leader | bad leader |
|---|---|---|
| 負責 | 承擔自己專案的成敗 | 永遠會怪別人 |
| 努力工作 | 以身作則，不管有趣或無聊的工作都做 | 不再寫程式 |
| 指導新人 | 注意新人的狀態，懂得在放手跟要求中間拿捏分寸 | 新人就是要操他才會進步 |
| 尊重 | 尊重每一個人 | 成員有人犯錯就落井下石 |
| 升遷 | 相信技術與專業會得到回報 | 沒料，只會逢迎拍馬、耍嘴皮子 |
| 信任 | 相信團隊成員，大家在互動中成長 | 不相信別人，技術差的只能做寫文件或做單元測試 |
| 任務分配 | 做大家不願意做的事 | 只會選自己喜歡的事做，困難的推給其他成員解決 |
| 問題回報 | 盡可能解決問題，也會及時向上回報狀態 | 掩飾問題，紙包不住火時就找替死鬼 |
| 代碼審查 | 相信 code review 的價值，重複發生的問題就寫到共享 blog 中 | 不做 code review，大家各自為政 |
| 挫折 | 吸收別人的經驗，提醒自己不重蹈覆轍 | 讓成員也經歷自己經歷的錯誤 |
| 新知 | 重視傾聽，接受 brain storming | 對無聊的建言嗤之以鼻，偷取成員提出有趣的想法，往上回報。 |
關於挫折的部份，原作者覺得 bad leader 會讓成員也經歷自己經歷的錯誤，雖然 leader 該想辦法讓成員避開一些顯而易見的石頭，應該給新人一些必要的協助，但我認為人類有時候，就是會有「不經一事，不長一智」的狀況，沒有痛過就不懂得要如何成長，總有些時候，是其他人不管怎麼苦口婆心嘮嘮叨叨，可是當事者就是沒辦法體會別人好意的提醒的時候，這也只能讓事情發生，然後再回過頭來一起檢討。
原文把團隊成員都假設是個成熟的個體，能跟 leader 有著良好的互動，但世事並非一直都很如意，有時會遇到一些無法跟團隊融合的個體，發生這種狀況時，已經沒辦法討論誰對誰錯了，一個 leader 就該承擔起來，採取適當的行動，如果真的沒辦法解決，也只能壯士斷腕，避免問題擴散到其他成員身上，畢竟一個 team 一定會有個共用的習慣與潛規則，這是不容被質疑與打破的默契。
我認為自己針對團隊管理上需要下些決定時，心裡抱持著的最高指導原則是：「我希望大家都能發揮自己的優勢，逐日進步，以接受更多的挑戰。」挑戰不單指是更高超的技術，有時候是為了大家可能會遇到的下一個職業生涯階段需要做的準備與練習。這些動作會讓直接減輕我在一些專案上的 coding effort或是管理的 effort，感覺上像是我的工作內容減少了很多，其實我是把現在手上的工作交給適當的成員，然後設法包些其他的事情去做，有點像是一直擴大工作半徑的團隊同心圓的感覺。
因為我在專案中不是扮演實作的角色，而是在建立與定義商業邏輯與規格，分配工作，盯進度，確認成品的品質...等等。有幾次我以講笑話的方式脫口而出：「反正我也不用寫這些程式」，但其實講出來之後，卻又後悔覺得這樣講並不恰當，我不曉得有沒有人在意，「說者無心、聽者有意」。其實我有時也會想，能夠像以前一樣其實也很好，不講什麼話，專心coding，不用刻意注意每個成員的狀態，又能更深入熟悉基本的技能，不會停留在懂得皮毛的狀態。但我現在已經不能真的這樣做了，這樣反而有可能變成搶了成員表現自己的機會，也可能造成一些不信任感。
team leader 該要注意 member 的狀態，處理跟人有關的問題，也有技術上的基本條件，因為不懂技術，無法從根本上驅動團隊成員，也不知道怎麼拿捏評斷每一個人能力的標準，也無法適當地判斷並分配工作項目，否則也只是會造成團隊產出的成品，砸到自己的腳的狀況。
沒有留言:
張貼留言