週六又被老闆招呼去開會，煩!在會上，老闆說要對我們軟體部實施績效考核，並要求我們幾個專案經理在一起商量下，把具體的實施細則給敲定下來。結果我們幾個經理們在公司會議室一直討論到晚上八點多才大體弄出個實驗品來，準備周一就開始在軟體部開展實施。
在這些年工作的時間裡，我在很多公司呆過，自然也感受過很多公司對我們這些程式設計師的考核。說實話，我一直對考核這東西不感冒，更多的是不喜歡，因為這裡面需要參雜的人為因素太多，而且很多時候讓人反感，搞得大夥是怨聲載道，民不聊生的。所謂的一些專業人士，專業考核，在我看來也無非是些江湖道士，到處坑蒙拐騙，有甚者引導過來，也無非就是裝點門面而已。而其很多時候，被考核者在忍受不了那些無盡的摧殘和折磨下，謾罵著無理的規則，鬱悶的考核離開公司的，我在幾年前離開某家公司也是源於此。
在我看來，其實很多時候，不管是公司老闆還是部門領導，無非就是想通過這些考核的執行，最終知道自己下面的每個人，具體每天都在幹些什麼，有無偷懶，是否按照規定做事等。那些上層領導們一天都是忙得「神龍見首不見尾」，**有時間來實時盯著你，看你是否在qq，是否在上網，是否在遊戲等等。終究是歸於這樣的原由，這些所謂的績效考核，崗位考核，專案考核，部門考核等形形色色的東西，也就有如一顆顆定時炸彈般突現在我們日常的程式生活中。
今天，在這裡我不想就考核的好壞做分析，因為這東西本就是乙個爭論不休的無奈，再論下去，也就只能那樣了，正所謂仁者見仁智者見智，終究是誰對誰錯，也只有我們的程式設計師才得以知曉。
在下面的文字裡，我主要還是針對我們當前即將實施的考核囉嗦幾句，這些只是個人觀點而已，說的不好的望各位給以指出。我主要談到的有如下三點：考核的目的、考核的規則、考核的結局。好，我們就開始吧。
一、考核的目的
前面我說到，不管是我們的老闆還是相關部門領導，對他的手下實施考核的最根本目的就在於想知道大夥都在做些什麼。不然他一天在外面奔東忙西，結果到頭來卻是自家後院**，那豈不是得不償失，亡羊補牢悔之晚也。
當然，領導終究是領導。他是這麼想的，可從來不是這麼說的。那天在會議上，我的老闆就很義正嚴詞地告訴我們說，這次對軟體部實行考核的主要目的只有如下五點：
1、規範大家的日常行為，辦事流程，工作方式，方法；
2、約束大家每天幹好自己手頭的任務，各司其職、各負其責，既不能玩忽職守，也不可越俎代庖；
3、對大家的工作能力，積極意識給出較為合理的評價。做得好的給出褒獎，做得差的給出批評、指正；
4、在公司內，部門內，各專案組內形成競爭氛圍，使各團隊之間有pk意識，敢於攀比，勇於超越，使我們的每個員工每天都能以最大的熱情投入到日常工作中，把自己身邊的每件事情做好；
5、公司準備出台相關獎勵措施，對於季度、年度一直表現突出的個人或團隊給以相應的獎勵。當然對於一直甘於老末的，也要給以警示、處罰，不過具體的形式有待協商。
現在看來，也只有第五條，能勾起我對考核的丁點興趣了，因為那裡已經明確指出，只要一直堅持做得好，就有一些獎勵的回報。我在痴想或許每人能分個千兒八百的，那也算是划得來了，也不枉大夥白忙活一場。哈哈。。。
二、考核的規則
對於這考核規則，還真是個沒譜的旋。這玩意兒，比起寫程式，做專案來說難多了。定嚴了，執行起來難，定寬鬆了，對得起下面的兄弟，對不起上面的領導，真是左右為難，糾結無奈。
那天，我們幾個專案經理一直折騰到晚上8點多才基本上弄出個大概來，這裡我主要列幾條給大夥一起觀賞觀賞。
1. **編寫期間，每天下班前按時提交**，並保證系統整合後可正常執行（3分）；
2．嚴格執行軟體開發規範，各個環節給出相應的文件說明（1分）；
3. 嚴格執行**編寫規範，爭取做到每個包，每個類，每個方法有注釋；**命名規範，每個類**行數盡量控制在200行以內，對於複雜或公共部分，盡可能給出類圖和包結構圖等（2分）；
4．遵守公司規定的作息時間，各專案組成員請銷假按照專案組內已規範的流程執行（2分）；
5. 無特殊原因，必須按時完成已分配的開發內容（2分）；
6. 未經同意不能隨意引入其他技術框架，確實認為好的東西，可提出，大家一起討論（2分）；
7. 未經同意不能隨意修改系統框架公共部分，核心架構組除外（2分）；
三、考核的結局
週六那天我們幾個在一起弄玩，老闆就要求馬上執行下去。我們原打算是八月才開始的。可老闆一再堅持說，沒必要，下週就可以宣布，讓大家開始執行，我們也沒再多說什麼。其實我當時想告訴他說再商量下，可轉眼一想還是算了，別去碰壁，我的老闆是那種言出必行的人，他一旦決定的事，沒人可以阻止他。
其實在我經歷過的很多考核中，無非都是相同的結局。一開始激情澎湃，到頭來，要不就是中途夭折死去，要不就是含含糊糊一直和稀泥。因為很多時候我們制定的那些規範太過死板，而且一旦某個兄弟觸犯了，我們這些執法者們，又有點於心不忍地去扣他的那一兩分。
如果狠心扣了，那他會覺得你多少有點不通情理，他這樣兢兢業業地給你賣命幹活，你卻這樣對他冷酷無情。長此以往，他會發現其實你這人很不講究，自然你和他的關係也會逐步變得不和諧起來，甚至最終他可能選擇遠離你而去，另頭他處。如果礙於情面，不扣吧，那好，別人不爽啦。說你有私心，有偏見。明明規矩定在那裡，為什麼不執行。好，你今天不扣他的，那我明天犯了，你也不能扣我的，不然我和你沒完，你敢扣老子告你去。最終下來你不能扣張三，也不能惹李四，睜乙隻眼閉乙隻眼就此作罷，只有祈禱別讓上面領導發現就行，不然自己是吃不了兜著走。看看就是這樣的結局，你該如何是好？
其實我們都是一群在一起為求過點好日子而不辭辛苦勞作的苦力同僚，我們都是些難兄難弟，我們有共同的愛好，有相同的追求，有同樣的企盼，今生有緣才相聚於此。很多時候我們應該在一起有說有笑，和和氣氣地相處好，大夥一起寫**，做專案。可這考核一來，搞得是**人怨，滿城風雨。我不曉得這樣的考核下來，我們的團隊和諧還能存在多久? 我們彼此的合作意識還能否繼續? 我們的專案組還是否一直延續下去?
哥們兒幾個，別怪我，哥是被逼的！！！
艾偉也談專案管理，架構組織管理
架構組織管理的五大原則 構想 節奏 預見 協作和簡化 架構組織的三在概念 準則 模式和反模式 準則 為了把原則運用到實踐中，需要實施細節。準則把廣泛的原則翻譯成是否和如何執行原則的細節。模式 描述了開發或者使用軟體架構時可能遇到的常見問題的解決方案。反模式 反模式描述了組織在實踐中可能遇到的陷阱，描...
艾偉也談專案管理，微型專案實踐感悟
微型專案是指絕大部分工作由乙個人員負責的專案，這個核心成員負責專案的系統分析 構架 及絕大部分的編碼工作。專案的持續時間一般不會超過乙個月。專案的參與人員除了核心的程式設計師外還可能一部分輔助人員，包括第二程式設計師 負責一部分編碼工作 美工 負責介面設計 等。微型專案的規模一般很小，業務邏輯也比較...
艾偉也談專案管理，如何管理「人」
我們常說工作中應該 對事不對人 但事都是人做的，不同的人做相同的事效果可能相去甚遠，再好的業務如果用錯了人也會全盤皆輸。正所謂 事在人為 嘛，識人 用人 聚人是乙個團隊管理者獲得成功的基礎。先說怎麼認識人 人格矩陣法。即所謂的topk技術，topk就是由 tiger owl peacock 與 ko...