互聯(lián)網(wǎng)項(xiàng)目當(dāng)中，相信每一個(gè)項(xiàng)目經(jīng)理或者制作人，最頭疼的就是技術(shù)部的管理犁享。因?yàn)榧夹g(shù)工作看起來是那么的棘手，一般人難以理解豹休，而且技術(shù)人員大多數(shù)都似乎情商不高炊昆。管理人員既不能輕易了解技術(shù)工作的內(nèi)涵，技術(shù)人員也覺得很難和管理人員溝通威根。特別是技術(shù)工作凤巨，難以在不同人之間交接，很多技術(shù)人員都聲稱無法繼續(xù)別人做過的項(xiàng)目洛搀。這讓管理者覺得技術(shù)人員特別喜歡耍大牌敢茁，而且他們要偷懶也非常容易。但正如軍事中的定理留美，對(duì)付坦克最好的武器就是坦克彰檬，對(duì)付航母最好的武器也是航母，這條理論是通用的谎砾。要管理好技術(shù)人員逢倍，就一定要懂技術(shù)。這是任何一種其他號(hào)稱完美的管理方法都無法替代的棺榔。

開發(fā)是一切——何時(shí)寫文檔

對(duì)于技術(shù)管理來說瓶堕，很多公司會(huì)非常注重文檔。雖然開發(fā)的結(jié)果是代碼症歇，但對(duì)于管理來說郎笆，代碼往往難以閱讀，也很少有人擅長接手別人的系統(tǒng)忘晤。為了讓代碼不至于被丟棄宛蚓，公司管理人員就祭起文檔這個(gè)法寶。我認(rèn)為文檔是很重要的设塔，但也發(fā)現(xiàn)這些文檔中很典型地存在幾個(gè)問題：文檔和代碼不同步凄吏；文檔的可讀性差，需要的文檔沒寫闰蛔，不需要的文檔寫了一大堆痕钢；文檔和代碼脫節(jié)，文檔很多序六，開發(fā)出來的成果很少任连。

我們應(yīng)該何時(shí)寫什么文檔，這是需要有嚴(yán)格定義例诀，并且有檢查過程的随抠，而不是任由大家自然發(fā)展就可以完善的裁着。代碼的編寫需要按不同類型，定義好在各個(gè)階段中所需要完成的部分拱她。

設(shè)計(jì)類文檔——這類文檔往往在項(xiàng)目二驰、模塊啟動(dòng)的時(shí)候，大家都會(huì)想到要去寫秉沼，作為討論和最后決議的成果桶雀，顯然是很自然的。然而在項(xiàng)目進(jìn)入開發(fā)之后氧猬，碰到實(shí)際問題時(shí)背犯，往往就不能完全按照設(shè)計(jì)的初衷去做了，所以通常設(shè)計(jì)文檔就在這個(gè)時(shí)候和代碼脫離了聯(lián)系盅抚。但有一點(diǎn)是絕對(duì)可以做的漠魏，就是在重構(gòu)的時(shí)候，按照現(xiàn)有狀況妄均，重新增加重構(gòu)前的系統(tǒng)狀況說明柱锹，然后再添加上重構(gòu)后的設(shè)計(jì)。這樣就把重構(gòu)的設(shè)計(jì)和文檔的更新結(jié)合到一起了丰包。

API（應(yīng)用編程接口）文檔——現(xiàn)代軟件都希望能提高重用的程度禁熏，因此很多程序員都會(huì)自己構(gòu)造自己的業(yè)務(wù)API旁壮，以便在之后的開發(fā)中使用得湘。而這種業(yè)務(wù)API，也是很多分工合作的基礎(chǔ)秦爆。這種代碼的說明寄症，會(huì)直接影響日常的開發(fā)宙彪，因此非常有必要保證和代碼的高度一致性。

使用文檔——一般來說有巧，一個(gè)軟件的使用文檔必須包含以下幾個(gè)：《產(chǎn)品版本說明》释漆、《產(chǎn)品安裝和部署文檔》、《產(chǎn)品使用教程以及例程》篮迎、《產(chǎn)品FAQ文檔》男图。這里面的《產(chǎn)品版本說明》應(yīng)該在每次發(fā)版的時(shí)候，作為發(fā)布流程的一個(gè)固有環(huán)節(jié)來設(shè)計(jì)甜橱⊙钒剩《產(chǎn)品使用教程以及例程》是我認(rèn)為所有文檔中，最值得花大力氣去寫好的岂傲∧疡桑《產(chǎn)品安裝和部署文檔》內(nèi)容越少越好，應(yīng)該讓安裝部署盡量智能化譬胎、自動(dòng)化差牛。

了解什么是軟件架構(gòu)

了解軟件架構(gòu)的范疇，才能有針對(duì)性地去把握軟件開發(fā)中的風(fēng)險(xiǎn)堰乔，從而管理好軟件開發(fā)的過程偏化。簡(jiǎn)單來說，軟件架構(gòu)就是應(yīng)對(duì)需求所產(chǎn)生的“一系列決定”镐侯。軟件會(huì)根據(jù)這些決定來開發(fā)侦讨。根據(jù)軟件需要應(yīng)對(duì)的需求，軟件架構(gòu)一般包含以下幾個(gè)部分苟翻。

邏輯架構(gòu) 主要是為了明確“功能性需求”而做的設(shè)計(jì)韵卤，針對(duì)需求以及需求變化作為架構(gòu)目標(biāo)所做出的關(guān)于代碼之間的劃分、耦合崇猫、關(guān)聯(lián)的決定沈条。采用合理的邏輯架構(gòu)，將會(huì)大大降低需求變更對(duì)開發(fā)的延遲作用诅炉。邏輯架構(gòu)最直接指導(dǎo)代碼中互相耦合的情況蜡歹，仔細(xì)設(shè)計(jì)好耦合的規(guī)則，會(huì)讓后續(xù)開發(fā)事半功倍涕烧。

運(yùn)行時(shí)架構(gòu) 運(yùn)行時(shí)架構(gòu)是為了滿足運(yùn)行期的質(zhì)量需求月而，所做出的關(guān)于對(duì)象行文、進(jìn)程結(jié)構(gòu)议纯、通信協(xié)議父款、數(shù)據(jù)結(jié)構(gòu)等方面的決定。運(yùn)行架構(gòu)一旦確定瞻凤，等于大部分的“實(shí)現(xiàn)”代碼都確定了憨攒，設(shè)計(jì)有足夠擴(kuò)展性和可用性的運(yùn)行架構(gòu)，可以為后續(xù)工作節(jié)省時(shí)間鲫构，也降低了系統(tǒng)在運(yùn)行期對(duì)開發(fā)工作的干擾浓恶。

開發(fā)架構(gòu) 為了滿足開發(fā)時(shí)的需求所做的決定，主要是軟件根據(jù)分工開發(fā)结笨、測(cè)試驗(yàn)證流程等需求劃分的軟件層次和區(qū)域以及各種接口設(shè)計(jì)包晰，也包含使用的軟件包、組件庫炕吸、開發(fā)工具伐憾，以及編譯構(gòu)建的方法。一個(gè)好的開發(fā)架構(gòu)赫模，可以讓溝通成本降低树肃，開發(fā)速度提高。

部署架構(gòu) 現(xiàn)代軟件系統(tǒng)瀑罗，基本上都包括了客戶端和服務(wù)端程序胸嘴，如何快速雏掠、高效、穩(wěn)定地部署和發(fā)布這些程序劣像，如網(wǎng)絡(luò)機(jī)房的分布乡话、服務(wù)器硬件的搭配、監(jiān)控和維護(hù)工具軟件的安裝耳奕、開發(fā)測(cè)試網(wǎng)絡(luò)和運(yùn)營網(wǎng)絡(luò)的設(shè)置绑青。可以獲得安全性的配置屋群，良好的部署能力闸婴，能推動(dòng)軟件進(jìn)行更頻繁、更全面的測(cè)試芍躏，從而提高軟件質(zhì)量和開發(fā)效率邪乍。

數(shù)據(jù)架構(gòu) 數(shù)據(jù)是軟件項(xiàng)目的核心財(cái)富，關(guān)于數(shù)據(jù)的結(jié)構(gòu)对竣，數(shù)據(jù)的存放溺欧、備份、傳輸會(huì)直接影響到運(yùn)行性能柏肪、業(yè)務(wù)功能姐刁、部署、安全等需求烦味。在面向?qū)ο蟮拈_發(fā)模式下聂使，數(shù)據(jù)到對(duì)象的ORM架構(gòu)也是很重要的設(shè)計(jì)。一個(gè)完整的數(shù)據(jù)架構(gòu)包括了數(shù)據(jù)流圖谬俄、數(shù)據(jù)字典柏靶、ORM結(jié)構(gòu)（如果需要的話）、數(shù)據(jù)索引和備份機(jī)制等幾個(gè)方面溃论。

何時(shí)以及如何評(píng)審

相信大部分公司都有評(píng)審這個(gè)環(huán)節(jié)屎蜓，評(píng)審可以包括方案評(píng)審、代碼評(píng)審钥勋、項(xiàng)目專項(xiàng)議題的評(píng)審炬转，比如對(duì)存留Bug的處理評(píng)審等。而這些評(píng)審算灸，常常會(huì)變成一個(gè)挑毛病的會(huì)議扼劈。要解決評(píng)審給產(chǎn)品帶來的負(fù)面影響，同時(shí)發(fā)揮這個(gè)活動(dòng)的優(yōu)點(diǎn)菲驴，我們需要關(guān)注以下幾個(gè)方面荐吵。

評(píng)審由誰發(fā)起 相對(duì)比較好的是，由負(fù)責(zé)此項(xiàng)目的“領(lǐng)導(dǎo)”來召集人員評(píng)審，并且一定要有負(fù)責(zé)開發(fā)的人員參加評(píng)審先煎。參與評(píng)審的受邀請(qǐng)人員可能會(huì)與方案提交者就一些問題有分歧贼涩，但提交者有最終決定權(quán)。要把權(quán)力給有能力承擔(dān)它的人薯蝎。這樣做可以讓“防止風(fēng)險(xiǎn)”的一部分人和“注重效率”的開發(fā)人員形成平等的意見交換磁携。

什么時(shí)候做評(píng)審 應(yīng)該在每個(gè)迭代、每個(gè)較大的版本開工前良风，或者僅僅是某個(gè)認(rèn)為比較重要的決定做出前，都來一次簡(jiǎn)短的評(píng)審闷供。如果開始時(shí)只是做一個(gè)DEMO烟央，那么需要評(píng)審的東西也比較少，而隨著不斷的開發(fā)歪脏，評(píng)審也能遍歷所有的開發(fā)疑俭。

做評(píng)審的方法 真正對(duì)項(xiàng)目有幫助的，是了解項(xiàng)目的需求婿失，分析面臨的難點(diǎn)钞艇，思考方案為何這樣做，提出自己的解決方案豪硅，給項(xiàng)目開發(fā)者以建議和啟發(fā)哩照。多說“我建議這樣解決這個(gè)問題”，而不要僅僅去說“這樣做可能有問題懒浮，應(yīng)該添補(bǔ)這樣的功能”飘弧。以建設(shè)性的心態(tài)和思路去做評(píng)審，而不是以找問題的思路去做砚著，這就是兩種做法的最大區(qū)別。

分層開發(fā)稽穆，盡快運(yùn)行

為了降低軟件耦合給開發(fā)帶來的負(fù)面影響冠王，正確的做法是要高度重視軟件開發(fā)方法柱彻，從代碼風(fēng)格餐胀、軟件架構(gòu)绒疗、設(shè)計(jì)模式、開發(fā)模式方面來提高水平骂澄。其中一個(gè)最簡(jiǎn)單有效的做法吓蘑，就是分層。在經(jīng)典的架構(gòu)模式中，分層模式幾乎是所有模式的基本模式：把代碼按照你所需的范圍劃分層次磨镶，然后規(guī)定層次之間的耦合接口溃蔫，層次之間只可單向依賴，而且盡量減少跨層耦合琳猫。劃分層次的范圍伟叛，由你的開發(fā)團(tuán)隊(duì)水平和項(xiàng)目的復(fù)雜程度決定。

非功能需求決定成敗

世界上類似的項(xiàng)目非常多脐嫂，但成功的占少數(shù)统刮，失敗的占多數(shù)，這種現(xiàn)象的背后有一個(gè)重要的原因账千，就是非功能需求侥蒙。非功能需求具體包括：軟件開發(fā)效率的相關(guān)需求，比如代碼結(jié)構(gòu)匀奏、代碼風(fēng)格鞭衩、內(nèi)容開發(fā)工具、自動(dòng)構(gòu)建部署工具娃善；軟件的質(zhì)量穩(wěn)定性的需求论衍，如測(cè)試方面的需求，產(chǎn)品結(jié)構(gòu)對(duì)于缺陷的防范聚磺，代碼質(zhì)量坯台；軟件的運(yùn)行承載力需求，包括可用性瘫寝、容災(zāi)性捂人、可維護(hù)性、承載力矢沿、運(yùn)行性能和成本需求滥搭；軟件的信息搜集方面的需求，如故障上報(bào)捣鲸、數(shù)據(jù)統(tǒng)計(jì)和挖掘瑟匆。

如何才能做好這些非功能需求呢？

首先是在項(xiàng)目成本規(guī)劃時(shí)栽惶，分配足夠多的資源愁溜，比如人力和時(shí)間，去做好這個(gè)事情外厂；其次是要盡量合理地規(guī)劃和設(shè)計(jì)這些非功能需求冕象，既不能貪多求全，也不能無所作為汁蝶。

追求代碼質(zhì)量

代碼質(zhì)量不高帶來的危害包括人員流動(dòng)后沒法接手渐扮、Bug頻繁出現(xiàn)论悴、效率問題難以定位、開發(fā)速度慢等墓律。

什么樣的代碼才叫高質(zhì)量的代碼膀估？代碼質(zhì)量存在一個(gè)唯一標(biāo)準(zhǔn)，就是可閱讀性耻讽〔齑浚可讀性好的代碼，結(jié)構(gòu)通常更簡(jiǎn)單清晰针肥，Bug也少饼记；更多人愿意去閱讀的代碼，也會(huì)有更多的機(jī)會(huì)去改正Bug以及其他的缺陷慰枕【咴颍可讀性好，也意味著你能更簡(jiǎn)單地去找到改進(jìn)性能的方法捺僻，減少修改代碼帶來的風(fēng)險(xiǎn)。

提高代碼質(zhì)量的手段崇裁，最簡(jiǎn)單的兩條匕坯，一是執(zhí)行代碼規(guī)范，二是進(jìn)行代碼評(píng)審拔稳。除了規(guī)范制定和評(píng)審?fù)飧鹁M織學(xué)習(xí)代碼質(zhì)量的知識(shí)，提倡并獎(jiǎng)勵(lì)高質(zhì)量代碼的人員巴比，也是提高代碼質(zhì)量的有效手段术奖。

搭好測(cè)試這個(gè)安全網(wǎng)

單元測(cè)試是最原始的工程概念之一。單元測(cè)試對(duì)于互聯(lián)網(wǎng)應(yīng)用來說轻绞，一般會(huì)有一個(gè)困難采记，就是需要大量的“腳手架”，比如為了測(cè)試數(shù)據(jù)庫操作政勃，必須要有一段代碼“重置”數(shù)據(jù)庫的狀態(tài)唧龄；為了測(cè)試網(wǎng)絡(luò)打包解包，則需要用一個(gè)程序向某個(gè)網(wǎng)絡(luò)端口發(fā)數(shù)據(jù)奸远。而準(zhǔn)備這些測(cè)試工具代碼的時(shí)間往往會(huì)比較長既棺，需要有足夠的耐心去做，但一旦做好了懒叛，往往能讓開發(fā)風(fēng)險(xiǎn)大大降低丸冕。

對(duì)于單元測(cè)試，我認(rèn)為最少應(yīng)該覆蓋所有正確的路徑薛窥，以及重點(diǎn)防御的錯(cuò)誤路徑胖烛。覆蓋了這些重點(diǎn)關(guān)注的地方之后，放手重構(gòu)代碼就很方便了。

單元測(cè)試應(yīng)該是屬于代碼的一部分洪己，和源代碼一起存放妥凳。自動(dòng)構(gòu)建時(shí)也應(yīng)該進(jìn)行檢查輸出結(jié)果。提交代碼時(shí)都會(huì)自動(dòng)運(yùn)行單元測(cè)試答捕，當(dāng)“版本樹”需要合并“分支”時(shí)逝钥，單元測(cè)試尤為重要，而最重要的是在分支上建立的單元測(cè)試拱镐。這些測(cè)試會(huì)大大加強(qiáng)系統(tǒng)的穩(wěn)定性艘款，因?yàn)闄z驗(yàn)了“合并”功能產(chǎn)生的代碼—這些代碼是最容易出錯(cuò)的。

自己掌控開發(fā)方向

開發(fā)工作往往被需求變化“牽著鼻子走”沃琅，需求往往會(huì)有很多來源：產(chǎn)品策劃的想法哗咆、老板的意見、用戶的反饋益眉、數(shù)據(jù)統(tǒng)計(jì)的結(jié)論等晌柬。提出的各種需求，往往會(huì)對(duì)開發(fā)團(tuán)隊(duì)造成很大壓力郭脂。這些問題都需要我們對(duì)需求做出有效的管理年碘。然而我們應(yīng)該如何去搜集、記錄展鸡、過濾屿衅、實(shí)現(xiàn)這些需求呢？

我們需要很好地搜集記錄需求莹弊。有的團(tuán)隊(duì)會(huì)設(shè)立兩面故事墻涤久，任何方面的需求，都可以減縮成一個(gè)故事忍弛，寫到一張便簽紙上响迂，貼到故事墻上，專人處理细疚，而不會(huì)石沉大海栓拜。

有的公司會(huì)試圖把這個(gè)事情用電子化流程來做，但電子化流程有個(gè)顯著的缺點(diǎn)惠昔，就是為了更多地自動(dòng)化處理幕与，會(huì)加入大量的字段，對(duì)于故事這種還未謹(jǐn)慎定義過的東西镇防，要認(rèn)真填寫太多的資料啦鸣，無疑會(huì)給使用者造成額外的負(fù)擔(dān)。

告別救火隊(duì)員

在產(chǎn)品進(jìn)入運(yùn)營期間来氧，最牛的程序員似乎總是在充當(dāng)救火員诫给，各種各樣的突發(fā)事件香拉、棘手問題中，我們的“高手”往往疲于奔命中狂，永遠(yuǎn)都在做一些補(bǔ)救的措施凫碌。有經(jīng)驗(yàn)的人員一直沒空做開發(fā)，因此大量的代碼由那些水平較差的人來完成胃榕，反過來埋下了更多的問題盛险。然而，如果不是忙著亡羊補(bǔ)牢勋又，我們的資深程序員就可以把更多的精力放在開發(fā)上苦掘，這些有經(jīng)驗(yàn)的程序員所生產(chǎn)的代碼，又會(huì)進(jìn)一步降低出故障的概率楔壤，這才是走向良性循環(huán)的方法鹤啡。

為了減少運(yùn)營期間的壓力，在系統(tǒng)設(shè)計(jì)時(shí)蹲嚣，就要特別注意關(guān)于可維護(hù)性的非功能需求递瑰。運(yùn)營事故當(dāng)中，因?yàn)椴渴疱e(cuò)誤所導(dǎo)致的占很大一部分隙畜，因此降低部署錯(cuò)誤需要做到：全代碼包發(fā)布抖部，每個(gè)發(fā)布版本要包含所有的可執(zhí)行文件；所有的服務(wù)器上部署的配置文件和數(shù)據(jù)文件都必須做到完全一致禾蚕，降低更新文件的復(fù)雜度您朽。本機(jī)IP地址應(yīng)該用代碼從網(wǎng)卡上直接讀取狂丝，但應(yīng)該提供可以配置的選擇换淆，預(yù)備多個(gè)IP的服務(wù)器使用；只使用命令行方式來啟動(dòng)不同功能几颜，如選擇配置文件路徑倍试、輸入不同功能進(jìn)程或服務(wù)器的配置；程序支持關(guān)閉蛋哭、重載配置這兩個(gè)信號(hào)县习。在處理這兩個(gè)信號(hào)時(shí)，都不應(yīng)該讓使用者感覺突然“掉線”谆趾；開發(fā)用于安全關(guān)閉程序躁愿、重載配置的腳本或功能；開發(fā)用戶自動(dòng)重啟所部署進(jìn)程的腳本沪蓬，以及配置開機(jī)自動(dòng)啟動(dòng)所部署的進(jìn)程彤钟；每個(gè)進(jìn)程都不應(yīng)該強(qiáng)行鎖定某資源，必須要能做到一份安裝復(fù)制多進(jìn)程并行運(yùn)行等跷叉。

每天發(fā)版

如果你想知道項(xiàng)目每一天的開發(fā)進(jìn)度逸雹，你就必須要做到每天發(fā)版营搅，測(cè)試每天的工作進(jìn)度，如果要順利地每天發(fā)版梆砸，就必須建立一個(gè)持續(xù)集成的系統(tǒng)转质。一般來說持續(xù)集成系統(tǒng)會(huì)有以下的先后步驟：?jiǎn)卧獪y(cè)試—自動(dòng)構(gòu)建—自動(dòng)部署—集成測(cè)試—自動(dòng)發(fā)布。

單元測(cè)試關(guān)鍵是要能堅(jiān)持覆蓋所有新加入的代碼帖世；自動(dòng)構(gòu)建是由構(gòu)建腳本休蟹、構(gòu)建服務(wù)器、持續(xù)集成系統(tǒng)幾部分組成狮暑。

對(duì)于美術(shù)鸡挠、產(chǎn)品或者別的非技術(shù)人員，添加的數(shù)據(jù)往往也需要有自動(dòng)部署的工具搬男，而且因?yàn)橥ǔＫ麄儺a(chǎn)生的文件比較大拣展，每次的全體打包然后覆蓋，可能會(huì)非常沒效率缔逛。雖然事情要做得完美不是很容易备埃，但絕對(duì)是物有所值。

版本列車

我們時(shí)常只是對(duì)技術(shù)工作有版本管理的過程褐奴，而對(duì)于其他環(huán)節(jié)按脚，常常停留在最原始的狀態(tài)。我們需要在整個(gè)項(xiàng)目開發(fā)的每個(gè)環(huán)節(jié)敦冬，都進(jìn)行合理的項(xiàng)目管理辅搬。在多個(gè)項(xiàng)目的經(jīng)驗(yàn)積累之后，提出了全過程的項(xiàng)目管理的概念：版本列車脖旱。

版本列車的含義是按照項(xiàng)目的工作流程堪遂，為每個(gè)有產(chǎn)出的環(huán)節(jié)都定義一個(gè)版本“車廂”，然后按照工作流程的先后依賴順序萌庆，形成一個(gè)完整的“版本列車”溶褪。第一個(gè)工作環(huán)節(jié)負(fù)責(zé)版本號(hào)，然后在這個(gè)版本號(hào)之下填充版本內(nèi)容践险。當(dāng)工作完成猿妈，此版本的工作內(nèi)容則帶著版本號(hào)進(jìn)入下一個(gè)“車廂”，依此類推巍虫。

這樣做的好處是彭则，每個(gè)環(huán)節(jié)的每份產(chǎn)出都可以明確地知道其進(jìn)度位置，安排在什么時(shí)候做占遥。對(duì)于需要提前準(zhǔn)備市場(chǎng)推廣或者別的工作部門俯抖，有一個(gè)非常明確的長期計(jì)劃。對(duì)于進(jìn)度管理來說筷频，各個(gè)部門也能知道整個(gè)項(xiàng)目的當(dāng)前狀態(tài)蚌成。

論功行賞（績(jī)效評(píng)估）

不管是對(duì)被評(píng)的人前痘，還是對(duì)評(píng)價(jià)別人的來說，績(jī)效評(píng)估都非常難做担忧。因?yàn)楹芏喙ぷ鞑⒎悄芎軠?zhǔn)確地列舉出一二三來芹缔，工作任務(wù)也可能有大量臨時(shí)變更。太過主觀會(huì)讓人覺得草率瓶盛；非要去依據(jù)可量化的數(shù)據(jù)最欠，又過于死板和片面。但沒有一個(gè)公司敢不做考核惩猫，所以說績(jī)效評(píng)估是“明知山有虎芝硬，偏向虎山行”。

績(jī)效考核應(yīng)該重點(diǎn)關(guān)注的是做了什么事轧房，而不是做得怎么樣拌阴。這個(gè)讓很多按“結(jié)果”管理的老板很不接受∧滔猓績(jī)效考核應(yīng)該是推動(dòng)別人去做某件事的工具迟赃。對(duì)于已經(jīng)明確的方法或者子目標(biāo)，通過這種細(xì)化的方式去指導(dǎo)下屬工作厂镇。因?yàn)槭切枰潞笏阗~的纤壁，而且是量化的，所以下屬會(huì)對(duì)這個(gè)事情很認(rèn)真捺信，同時(shí)那些不好量化的事情酌媒，管理者也很難執(zhí)行績(jī)效考核。所以“去做某些事”迄靠，是績(jī)效考核最好的目標(biāo)秒咨。

通過考核結(jié)果提供正式的工作方法意見±嫠績(jī)效考核本身有個(gè)反饋的過程拭荤，這個(gè)反饋的過程應(yīng)該提供給下屬針對(duì)每個(gè)具體事情的建議茵臭。這種具體地疫诽，單獨(dú)地，一對(duì)一地指導(dǎo)旦委，會(huì)提高團(tuán)隊(duì)的穩(wěn)定性奇徒，而且也讓團(tuán)隊(duì)成員獲得“受關(guān)注”的感覺，這種感覺是形成高效團(tuán)隊(duì)的重要工具缨硝。

考核不能代替目標(biāo)摩钙，不能阻礙目標(biāo)，而應(yīng)該是一個(gè)溝通工具查辩。目標(biāo)達(dá)成情況是考核的客觀指標(biāo)胖笛，但不應(yīng)該作為主要績(jī)效考核指標(biāo)网持。最簡(jiǎn)單的績(jī)效考核指標(biāo)就是收入或者利潤率。但這種簡(jiǎn)單指標(biāo)除了在動(dòng)機(jī)上提高下屬的工作熱情外长踊，并沒有從方法和經(jīng)驗(yàn)上幫助團(tuán)隊(duì)成員功舀。有效的考核應(yīng)該是引導(dǎo)下屬按照更有經(jīng)驗(yàn)的方法去實(shí)現(xiàn)目標(biāo)。