太極研發部的年度評比

愈來愈相信，人一生中受用的生活知識中，有超過一半是來自於你所接觸到的人（ex, Complete Maya Programming 這本書的作者 David Gould）、所遇上的事（ex, 台灣 921 大地震）、所看到的世界（ex, 美國佛羅里達州上的 Disney World），乃至於所聽到的音樂（ex, John Lennon 的 Imagine）。即便是工作上，非常無趣且不討喜的RD 部門年度評比也是如此…

上圖是一張我意外在 flickr 上頭找到，照片所有人為 jazzmasterson，他汲汲努力於使用 Index Card 來協助決策判斷與思緒的整理。我印象中有一本鴨嘴獸當封面，講述物件導向（OO）觀念的書籍（Introduction to Object-Oriented Programming by Timothy Budd），也是從使用一種叫 CRC Card 的方式…這是一本非常有意思的 OO 觀念書，至今仍在我的書櫃上好好保存著。我引用他放出來的照片，用來說明年度評比這一件事的複雜情況，那種要面面俱到，但其實又不容易做到的囧況。

去年（2007）年的年初（農曆過年之後），我的主管把我叫去，要我擔任 RD Lead，協助 RD/TD 團隊，讓他可以無後顧之憂，好專心想「怎麼賺錢」這麼一回事。老實說，我在做重大決定時，常常是猶豫不決，一點都不像平時一些「技術上的決策」來得那麼乾脆漂亮的，這件事也一樣。我好像也沒什麼不接的理由，但又擔心會不會因為要帶整個研發團隊而導致一些不適症…總之，最後就是這通「囫圇」地接下了。

一年過去了，研發部門的年度評比（RD annual review）日子到了。我自告奮勇地向我的主管提出，是時候做年度評比了。

於私，我非常地希望從這次的評比中，得知主管們對我這一年表現的看法，包括我和整個研發團隊的成效看法。同時，我也想藉此自我檢視一下：繼續在太極影音待下去，可以有怎麼樣的進步與發展，是否我可以從這裏培養出屬於自己的職業人格；於公，我想給整個研發團隊爭取一些獎勵，試著落實一下所謂的「賞罰分明」。一年下來，有的人表現出非常的積極，勇於冒險嘗試新的作法，懂得配合別的部門來完成目標…等，對於這樣的同事，身為 RD 頭的我，有責任與義務盡我可能，讓大家做得更愉快。

評比進行方式

1. self review
2. cross review (or peer review)
3. manager review
4. 1-to-1 discussion

執行細節

self review，自我評比。

這個階段是讓每個人針對過去的一年，做自我評量，一種自省的過程。review 的型式比較自由，目的在於讓當事人，能確切做到回想與檢驗自我。為了做到這一點，直接捨棄發張表格，然後請大家填表格的作法。因為制式表格只會大大破壞「自省」的功能，讓人覺得「應付了事」就好，完全無法感受 self review 的一絲一毫美意。同時，為了讓 self review 有更正面的意義與用途，我下了個決定：

讓 self review 的成果是對當事人（研發工程師?）有用的。

一般的 review，有某種層面上來看，只是為了讓平日忙錄到沒空關心你，不曉得你的工作內容與成果，而只想透過一些簡單的表格或是某些問答評分等來考核你的主管用的。我並不想做這樣的 review，因為我討厭做一些「看不出來有什麼明確效益的事」，我想借此次的 self review 來讓大家想想「自己的履歷」這件事。

履歷（Resume）或作品集（Portfolio）…這些東西，似乎只有正要找工作、準備換工作或是剛剛畢業的學生才會去注意的事，實際上呢，他們是非常重要，重要到你應該要有能力隨時拿出一份在不同情況下都適任的履歷出來才是（話說回來，目前我好像也沒辦法做到的樣子 :p）。「數位密碼」（Digital Fortress）裏的蜜姬‧密爾肯說過「工作即人生」。隨時在腦子裏（或某份電子檔也行）有一份自己的「最新狀況」，是對自己的一種負責，同時也可以時時提醒自己 What's Next? 因此， self review 要求大家寫一到兩頁，型式就像簡易版的 resume，只提重點，而且要能句句切中要點。

cross review（or peer review）是指同儕之間的檢討與評比。

基於諸多顯而易見的理由，一個人的工作表現，最適合給與評論的人，就是與他（她）合作過的人，合作同事給的看法，有時是比主管來得實際。可能是同部門（rigging?）的同事；可能是上下游部門的同事；可能是一起寫程式的工程師；也可能是他所開發的工具的 beta tester…，主要就是和當事人有密切合作的。不過也不是每個人的工作都屬於「協同合作」，有些人的工作性質就是「獨立製作完工」型的，這時就傷腦筋了。我的作法是請「座位離他（她）比較近的同事給與評論」，一種「空間上的親近」，而非「合作上的親近」，這作法的確很怪，不過我想不出更好的點子了 :p

因為 cross review 涉及的人事很多，每個人要被數個人 review，而他（她）同時也可能需要 reivew 另外的數個人，整個過程，如果站在 Taipei 101 樓頂的高度來看的話（可能不需要那麼高），會覺得活像一個網絡（Network? Internet?）。為了避免無謂的人事浪費，需要把握的重點之一就是：讓參與的人盡量在不用花太多力氣的情況下，處理好這件事。為此，我們設計了一個表格，裏頭除了受評人的個人資料以外，評分項目分成三大項，依序是：

1. 專業技能（Technical Skills）
2. 工作成效（減少成本）（Cost Down）
3. 團隊精神（Teamworks）

拿到表格的人，只要根據上頭的項目，一一給與不同程度肯定的「打勾」就行了，然後每一項門後頭有個說明，當給與的評比是最底（ex, 差勁）或最高（ex, 優秀）時，可以有個簡短的文字解釋，讓收到這份表格的主管可以更了解評比的理由與原因。

又 cross review 是採用 pseudo-blind review。舉個例子，工程師 A 在 2007 年參與過三個案子，分別和 B, C 與 D 等人有合作關係，於是 B, C 二人被安排了去填寫工程師 A 的 cross review form。A 並不知道有誰在 reivew 他，而且也不確定會有多少人。而 B, C 也被給與保證，不會讓 A 知道是他們 review 的，讓他們可以盡量公平不偏頗的方式進行。這樣做的目的，是在保護 cross reivew 整個過程中的結果的正確性，已經參與的所有人員之間的感情不會因為這次的 cross review 而有所影響。

pseudo-blind，亦指「當事人不知道誰在評論他」這件事，但不表示「無記名」，因為單位主管與 review 承辦人需要知道 cross review 之間的關係與相對應的內容，好從中決定出更適任的職務安排。

manager reivew 由幾位主管進行，從管理者的角度來評論員工。

有別於 cross review 的表格，manager review 會使用不同的表格，不過有時也會直接使用一樣的表格，依情況而定。這階段，主管會調閱出去年（或上一次 reivew）之後，所訂定出來的計畫、專案之類的，然後一一審視是否達到目的等。舉個例子，我在去年的 RD Projects 中提出，要整合四套 production tools 成一套，而且完全採用 Python 這一套語言來撰寫，同時提出幾個新的功能，所以在今年，主管在評論我的表現時，就會針對去年提的條目，一一了解完成度如何，這些計畫又對整個團隊有什麼影響，是不是關門造車…之類的。

manager review 通常進行得很快，因為審閱的不止是單一對象，有時候是一次審閱四五位工程師，從中看出比較全面的狀況。透過這樣的方式，有時會有意外的發現。舉個例子，現在有個團隊，成員有四位，負責公司內部的 ooxx system，其中一位是 ooxx system lead，另位二位是 engineer，一位是 beta tester。程式都是由 lead 帶頭撰寫，所以他的成效很高是很自然的，但是我們卻意外發現，這位從 self review 或 cross review 都沒看到什麼成效的 beta tester，因為他個人特質的關係，讓整個團隊的向心力非常的好，也因為他而很有活力，同時他還協助整個 system 與別部門之間的溝通，把別部門的觀點與考量引進 system 裏頭，修正了不少當初 spec 的盲點，因此從 manager 的觀點來看，他是僅次於 project lead 的第二大功臣!!!!

1-to-1 discussion，主管一一找員工面談，讓他知道整個 review 的結論與結果。

這是最最重要的一環了，因為如果這樣麻煩了所有人玩這麼一套 review 後，卻沒有讓人覺得有什麼實質上的目的與意義的話，那整個 review 的過程就是失敗的。