淺談軟件研發管理

不知不覺間，已經從業十年有餘，而今又是一年的年末，想寫寫總結，最近本身一直在想關於軟件研發管理的一些相關的問題，因此寫此文作一個歸納，許多觀點也許並不是本人原創，但具體出處我就不去一一考證了。

最好的管理方案就是這麼一種東西：你能夠不斷嘗試去接近它，但永遠達不到。這麼多年的工做下來，我感受這真是個赤裸裸的真理。這個「真理」不光對軟件研發行業適合，對別的行業也適合。

一個例子

公司有一倉庫，倉庫裏有若干員工，須要進行理貨、入庫、上架、貼標、撿貨、出庫……等操做，爲了鼓勵員工積極幹活，設計了「計件工資」，給每種操做設置了一個單價，多幹多得，看起來很美；但很快就發現員工很會趨利避害，幹活就專挑那些性價比高的幹，而那些收益不高的活沒人願意幹；因而組織管理人員通過N個月的調查和核對，調整各個操做的單價，直到看起來比較合適，儘管仍是有些問題，但大體正確了；但仍然有別的問題存在，負責工做分配的倉庫主管本身也須要幹活，並且一般會給本身安排一些對本身有利的工做，能夠多拿計件工資，弄得其餘員工很不高興，因而管理團隊又通過N次開會商量決定不讓倉庫主管直接拿計件工資，倉庫主管所幹的活將按下屬員工的工做量的比例分攤給下屬員工，而後倉庫主管拿全部下屬員工的平均計件工資乘一個係數的「係數工資」，這回夠複雜了吧！看起來已經相對公平；但公司發現倉庫員工仍是不斷減小，招來的新人幹不了多久就走人，認爲這樣十分不公平，由於新人的工做效率遠遠不如老員工，他們幹活同樣也很累，只是因爲熟練度不高，效率低，而如今這種計件分攤的機制對他們很不利，他們拿的不多，而主管也無法分配更多的任務給他們，又通過若干次開會討論，決定給新員工在試用期內給一種「新人補貼」；接着隨着某些操做的熟練度的不斷上升或在操做中使用了一些捷徑，某工人的計件工資出現了史無前例的高，公司管理層以爲這樣很不妥，須要對此操做的單價進行調整，工人就不高興了，「大家憑什麼又不兌現本身的承諾？」，因而屢次反覆……我還沒提到考勤管理，加班管理和飯貼等狀況，總而言之，這並不是一件容易的事情，並且，更關鍵的：這麼一個「管理」的自己，通過這麼長時間的調研和會議，也耗費了公司至關大的一筆資源。不過，話說回來，無論理能行麼？

計件可行不？

上面的例子我向你保證100%真實，若是換到軟件研發管理去，狀況會更加複雜，由於和倉庫操做工相比，軟件研發是一種「智力密集型」工做，其工做計件十分困難，工做質量更加難以評估，而「計件」之外的工做也是難以估量，因此企圖以精確「計件」的方式去管理軟件研發團隊的，確定都不能成功。

好比按照產生代碼的行數計件？若是那樣的話程序員就企圖把代碼寫得爛一點，原本一行能夠完成的功能如今分做幾行寫，這樣行不？難道你還要聘一我的專門檢查程序員是否多寫了沒必要要的代碼？更關鍵的是代碼的質量如何判斷？應該用什麼標準？你能想到的大概就是測試了，測試出來的bug越多，質量越低，但bug有大有小，難道都要一視同仁？還不算有些bug須要運營了好久以後才被發現的狀況，好吧，當你根據bug的嚴重程度作好加權以後又發現程序員和測試組會串通：「你發現bug直接告訴我，我偷偷改了就是，免得扣我KPI，回頭請你吃飯。」因而你又規定測試也得KPI，測試出來的bug越多KPI越高，但這樣很不幸把測試跟開發對立了起來，有些問題你們互相推卸，根本得不到很好的解決，不涉及到錢的時候你們均可以表現得很謙虛，但一旦要跟本身有利害關係了，每一個人都會挖空心思去提升本身的收益，程序員智商原本就不低，手段方法恐怕只有你想不到的，沒有他作不到的。這還沒完，因爲推行了這種策略，公司裏已經沒有技術人員願意去研究新的技術，沒人願意改進本身的工做，由於這些東西都沒有被「計件」，因而公司成了一潭死水……接着無論如何改進，機械式的計件方案都不會有什麼改觀，這是由軟件開發工做的特殊性決定的。更慘的是，最後你發現這樣「管理」自己還消耗掉了公司至關大一筆資源，直接把這些錢發給程序員的話激勵效果可能還更好點。

另外一種「計件」的方法是根據項目來，看一個項目能帶來多少收益，進而給員工發放項目獎。——實在有點很差意思說，我工做超過十年了，儘管大多數公司都說起了「項目獎」，但至今我是一分都沒拿到過啊！程序員也不是傻子，你們都清楚，沒有明確承諾的「獎」其實就是空頭支票，這個你們都一清二楚了。即使你做爲管理者，決心去執行項目獎，怕對程序員的激勵也頗有限，由於不少項目每每都週期很長，收益不那麼容易看到，許多人沒信心等到那天，即使等到了，項目也不是他一我的作的，別人不用那麼積極也照樣能搭順風車拿到項目獎，那本身幹嗎那麼努力呢？因此着急的恐怕到最後也就項目經理一我的。（參考「智豬博弈」）

一種可能比較靠譜的績效評定方法是「經理直接打分」，由於對員工的工做最瞭解的人就是經理，誰的貢獻大，誰的貢獻小，一目瞭然，可是，不用說，這種方法也高度依賴於一個大公無私的經理人。也許你想說，那員工的「自我評定」呢？——沒用的，只要涉及到錢，無論本身表現有多差，每一個人都會厚着臉皮給本身飆滿分。

CMMI等

CMMI（軟件能力成熟度集成模型）其實就是一套方法論，是爲了可以保障軟件質量和交付日期而提出來的軟件公司的模型。CMMI分爲五個級別，第一級最低，只要是家軟件公司就能夠「驕傲」地說「經過了CMMI Level 1」，若是能達到最高的CMMI Level 5，那就至關的牛逼了，理論上如此。

我接觸CMMI是在2004年，那時候我在一家作對日外包項目的公司當程序員，個人上司對個人評價並不高，他一直認爲我代碼質量差，工做不行，其實主要的緣由是有一次我登陸到服務器上不當心從新保存了一個文件，內容雖然沒有任何改變，但文件的時間戳變了，日本方面就抓住了這條「小辮子」，個人上司估計所以受到了比較嚴肅的批評，因此個人日子也開始很差過了……那時候公司正好在推CMMI，因而他把我分配到了CMMI組，我有些不樂意，我本身最喜歡的事情就是技術，直接接觸代碼，但這麼一來，卻有些同事對我羨慕嫉妒恨啊，心想這小子功績平平，咋被分配去作管理了呢？

事實上，這種「管理」一點都很差玩，培訓、開會、整文檔就成了工做的主要內容，一大羣人蔘加的會議，能有什麼效率呢？一份功能簡單的代碼，就得對應上好幾份繁冗的文檔，如此般繁瑣的流程，哪有什麼創造性可言呢？只見你們對此怨聲載道。不久後我離開了那裏，那之後我一直都不認爲CMMI是什麼幫助企業改進的良丹妙藥，它過於「學院派」，雖然說「源於實踐」，可又有些「不切實際」，最關鍵的是：這種方法論每每走着走着就把手段自己當成了目的，這樣的管理，開銷實在太大了。

後來，我一直想着如何不按照CMMI的方法去作，可否將它簡化簡化再簡化，卻又能保證軟件質量，同時讓軟件開發的工做變得有趣，而不是把手段當成了目的。固然了，想這個的人大把了，並且他們已經提出了完備的理論體系，即「敏捷開發」，敏捷開發強調人做爲核心，強調人和人之間的溝通和配合，我還專門弄了本書看，但遺憾的是，這一切依然過於「理論化」，上面的東西頭頭是道，不容駁斥，但到具體怎麼作的時候，那真是一種「拔劍四顧心茫然」的感受啊，我漸漸以爲，不涉及到如何具體操做的方法論都「不實際」，不具有「可操做性」。

有效的工具

作上技術管理的職位以後，我嘗試推過一系列的工具，以此來提升咱們的開發質量和效率。如今總結回來，除了源碼管理工具（SVN）推得算比較成功以外，別的基本上都失敗了，下面我一一道來。

項目管理工具

用於跟蹤項目進度，但得人工填寫，把一個項目拆分紅若干塊，而後每塊拆分紅若干個任務，分配給不一樣的人，並定下一個deadline，工具甚至能根據各個任務的完成狀況繪製甘特圖，對，我曾嘗試過微軟的project，用這種工具的好處是感受項目就在本身的「掌控中」，但這僅僅是感受而已。工具自己是爲了通用性設計的，因此好些地方並不符合咱們的特殊要求，得咱們本身去改，而咱們沒有那麼多的時間和精力，我除了安排任務以外，還要編寫至關一部分的代碼，主要是系統框架和一些比較棘手的部分，因此任務細分這個工做每每很滯後，我好不容易佈置好任務以後狀況卻發生了變化，任務有變，或直接cancel掉，全部這些都須要我上去手工編輯，而後等其餘人確認，你們都以爲這樣很麻煩，畫蛇添足，貌似沒有這樣的「項目管理工具」咱們日子也都過得好好的，惟一最想要的可能就是老闆，他一直很想知道咱們具體的進度，儘管他不關心咱們到底實在寫代碼仍是在畫畫，而你們對此卻並不怎麼配合，漸漸地我也以爲這工具對咱們用處不大，這玩意兒就是得手工去操做，去記流水帳，爲的只是一個「一切盡在掌握中」的錯覺。

bug記錄與跟蹤工具

測試者向開發者最快地反映問題的方法固然是直接喊話，但這樣最大的問題是沒有記錄，因而後來用文本文件記錄，再後來用excel，但這些單機工具不利於共享，接着天然而言就想到一些issue track工具，這種工具大多數是基於web的，開源的不少，配置也並不困難，咱們使用了一段時間，以爲有必定好處，但也不見得有預想中的做用那麼大，我分析緣由下來主要是團隊較小，加上咱們的項目變化過快，工具用起來顯得有些不便，大多數程序的問題老是能在第一時間修正而無須記錄，你們都這麼想。我我的卻是以爲bug技術與跟蹤的工具仍是有必要推一推的，但要養成這麼一個使用習慣，還須要諸多方面的努力。

UML建模工具

我用得最多的是數據庫模型關係圖、類關係圖和時序圖，我得說UML是很好的東西，我嘗試過很多UML建模的工具，但這些工具大多都僅限於我我的使用，極少用於團隊交流，緣由是要學習這些工具的使用是得花上一些時間的，像類關係圖這種東西，甚至看起來沒有直接的代碼那麼直觀，另外一個很重要的緣由仍是跟前面所說的同樣，變化過快，你好不容易畫好了圖，他們立刻說要加上一個字段，代碼直接就改好了，你圖到底改仍是不改？最快捷的方法固然是直接修改代碼，而後上線一個新版本，用最快的時間把東西改出來，老闆和用戶是最高興的了。因此UML這種東西咱們利用率並不高，只用了數據庫建模這一塊，由於數據庫的結構不像源代碼那樣直接有版本管理工具，咱們爲了對其進行控制，還須要這麼折騰一下。

UI設計工具

我曾經說過，UI是最難作的東西，由於誰都能直接看獲得，誇張點說，無論是老闆仍是掃地阿姨，誰都能對UI提出一套本身的看法並可能插上一手。我嘗試過用不一樣的工具來畫界面，好比photoshop，能夠畫出至關漂亮的界面，但花費時間過長，Visio也是不錯的，但無論用什麼，老是得面臨這麼一個問題：改動，頻繁的改動！他們要變了，你的設計圖改不改？改嘛須要花費不少時間，不改嘛，設計就至關於白費了。我後來發覺用word竟然也能把界面描述清楚，並且word改起來比photoshop或visio簡單得多，還自帶了不一樣版本的比較功能，知道每次變了些什麼內容，太棒了，若是word能行爲何不用word？實在word描述不清楚的界面，再用visio或者photoshop來畫好了。

問題反饋系統

當用戶遇到問題的時候，就給咱們打電話或發Email，他們就像一羣不長記性的人，過去遇到的問題就彷彿沒遇到過同樣，凡是問題，也無論三七二十一，就直接找咱們，因此這麼一套問題反饋系統就應運而生了，讓用戶在遇到問題的時候，到上面去搜索答案，而後再提問，咱們根據具體狀況將問題標記爲處理中，已處理，或關閉等，這是一個不錯的主意，必定程度上幫助了咱們減小對用戶問題的重複處理，但也遠非完美，我發現大多時候用戶依然會無腦地提出如「系統沒法使用，急急急」等不知所云的問題，這樣的問題反饋系統最多隻能算成功了一半。

WIKI知識庫

咱們在不斷的作開發，不斷地積累知識與技術，可這些東西時間一長就變得凌亂不堪，沒有很好地組織起來的知識是沒有價值的，因而我想到了WIKI，用它來整理公司的文檔，這套使用Web技術的知識庫能讓咱們隨時隨地查看和編輯公司的技術文檔，並且還能看到歷史版本，看起來很美……可實踐證實了，這彷佛不太可行，一來WIKI的使用門檻稍微有點高，你們都用不太好，二來你們都沒有這個動力去使用它，養不成這樣的習慣，外加一個緣由就是面對變更頻繁的東西，WIKI用起來仍是有些不方便。因此後來WIKI上的東西基本上都是我寫的，有技術文檔，編程規範和一些公司內部的文件。因爲更新內容很少，難造成一個連貫的知識庫，因此後來用得愈來愈少，基本上是荒廢了。

員工交流平臺

這個東西其實不是我推的，但也把它列一列吧。公司HR部門有人提出弄這麼一個論壇做爲員工交流平臺，因而讓咱們搭建，這個並非太難的事情，都有現成的，咱們直接Discuz。頭先幾個月你們都上去註冊了本身的ID，還有很多人上去發帖，發佈一些活動啥的，但很快人氣劇降，直到荒廢無人再用。這種交流平臺在不少大的公司都有，如阿里的「內網」，人氣還很旺，你們熱衷於利用這麼一個交流平臺，對企業文化氛圍起到了一個至關積極的推動做用，而這種方式對咱們卻不可行，這很大程度上取決於老闆，在咱們老闆眼中，業績纔是最重要的，別的都靠邊站，他根本不可能到這麼一個論壇來跟你們交流，疲於應付業績的員工也無意談論別的事，推不成功，那是理所固然的了。

代碼版本控制工具

現在主流的也就兩種，一是svn，另外一是git，別的都是異類，svn是我在公司推得最成功的工具，以前用的是sourcesafe，一個連微軟本身都不用的東西，開發者們成天叫嚷最多的就是：「那個誰，把代碼簽入一下。」儘管svn的使用很簡單，但我仍是破費周折才讓大夥們走上正軌，若是前面提到的那些工具都並不是是必須的，那麼代碼版本控制工具就是必須的，svn屬集中式管理，適合在公司內部用，git則是分佈式管理，適合開源項目或移動辦公，學習曲線相對稍陡。

最後我不得不聲明一下，我推這些工具的失敗並不意味着這些工具沒用，每種工具都有適合它使用的場所，而每家公司都有其特定的環境，脫離環境談工具是沒什麼意義的，這只是個人經驗。用一句話歸納——什麼工具行之有效，就使用什麼工具。

撰寫說明書

我想說的是：這些東西用戶根本就不會看。

當今社會信息氾濫，人們生活愈來愈快餐化，能靜下來看書的人愈來愈少了，你們看新聞也是隻看一下標題，內容嘛掃幾眼就不看了，看不了那麼多，除非真是本身很感興趣的，認真寫博客的人也愈來愈少，進而換成了「微博」，上面充斥了各類吸引你眼球的段子……還有，你試想如今還有那個手機App會帶上一份「說明文檔」？換句話說，須要看說明書才能用的App，誰會去用？

曾經我也認爲，沒有說明書的產品就稱不上是完整的產品，可咱們如今還須要寫一本用戶根本不會看的說明書嗎？

另外，說明書的壞處還在於軟件產品功能頻繁變更時候，它每每沒有跟上，這樣的說明書做用就更加小了，有時還會誤導人（若是有人還去認真讀它的話）。

因此如何開發一個不須要說明書的產品，就成了個人目標。對於消費類的App來講，彷佛不是太難，開發者能夠在界面中加入一些即時提示來幫助用戶使用，還能夠配備簡短的使用教程，讓用戶在第一次運行App的時候快速入門。但企業應用就沒那麼幸運了，由於其最大的障礙實際上是複雜的業務邏輯，這些東西沒法用簡單的一點提示就能說清楚，其中涉及的概念術語又多，說明書又沒人願意看，因此實施和培訓幾乎是必須的。這看起來對企業應用來講也理所固然。

說明書其實也並不是全沒用，有說明書，說明你的產品夠「完整」，至少看起來如此。若是你足夠強勢，你就能夠對客戶吼道：「這問題說明書上有，本身看！」另外就是在培訓完了以後灑脫地把說明書往桌子上一扔：「我今天講的東西說明書上都有。」儘管後面仍是沒人會去看，有啥問題照樣會找上你，他們甚至連程序提示什麼都不會去看。

開發文檔

我開門見山直接地說了吧，開發文檔的最大問題和前面所提到的那一大堆工具所面臨的一個問題同樣：就是很難及時跟上變化。

若是要讓開發文檔跟得上代碼的變化，那就得花費至關大的人力去維護它。爲何不是代碼跟着開發文檔變？由於每次要改動的時候都很急，若是你們稍微有點懶的話，文檔也就沒去改，還有的時候變化太大，至關於要重寫許多文檔內容，工做量太大了，來不及。而開發文檔這個東西是用來指導開發的，開發一完成就基本沒人再去看它，長此以往，文檔和代碼越走越遠。

我回想起許多年前我負責的一個項目，一開始在寫代碼以前你們整理了很多文檔，可弄到最後我發現最有用的文檔只有我畫的一張業務邏輯圖，任什麼時候候對業務有疑問就能夠看看那張圖，問題大多能迎刃而解，而密密麻麻的文字沒人願意再去看。因此以後我一直奉行着「實用爲主」的這麼一種策略，沒用的東西就不去作。開發文檔我認爲也應該如此，要明白哪些東西有用，對開發起到指導做用，哪些東西寫完以後就過期沒人再會去看，還有哪些東西要求投入過大而不太現實，總之要以「實用爲主」有所取捨。

固然了，有些項目是開發中間件的，開發出來的東西是給別的程序員用的，那配套的開發文檔就很重要，這個必須做爲產品不可或缺的一部分，認認真真整理。

管理的核心是人

不涉及到人的管理就不是真正的管理，最多隻能叫作「文案工做」。

上面這句話若是我沒記錯的話，來自於過去我看的一本書——《最後期限》，須要說《最後期限》這本書是至關好的一本書，能夠把它看成《人月神話》這本書的附加讀本，它以一個虛構的故事來闡述軟件管理是怎麼一回事，十分生動。

後來我漸漸以爲，軟件研發的管理，其實就是如何充分發揮每一個人的才智的方法。人才是主角，因此那些文案工做根本就是次要的，最終一切的一切不都是靠人嗎？

如何發揮一我的的最大的能力呢？固然就是讓他去作本身喜歡作的事。

我曾感慨，要求一我的去作一點事是多麼的困難！好比有次想讓公司的美工把圖改小一點，他認爲他原先作的正好合適，若是以爲大了，那確定是個人問題而不是他的，他還能搬出一大堆理由，技術上來講圖不能輕易改變尺寸，由於調整尺寸會讓圖片內容走樣，總之是不行的，我有些惱火，因而本身打開photoshop把圖改了，固然，也許結果你也猜到了，我這樣作引發了他更大的反感，「圖是我設計的，憑啥你說改就改呢？那之後圖我也不作了。」是否是這種道理？想辦法如何讓同事配合本身的工做，須要大量的人與人之間溝通的技巧，讓這個任務被同事認爲是他本身喜歡作的任務，而不是強加給他的任務。學會如何與人溝通，纔是管理的精髓所在，而我一貫作得不夠好。

說到人的管理，這是一個很大的話題，我感受本身能力不足以將這個話題講得有多全面和深刻，這方面有不少書。我如今只能談談我的對於軟件研發這個工做的人員管理的一些粗淺看法。

瞭解每一個人的特色

人跟人之間的差距真是太大了，個性，愛好，能力偏向……都有可能徹底不一樣，有些人喜歡接受一項內容詳細明確的工做，有些人着喜歡有更多的我的發揮空間的工做；有些人工做快速粗糙，有些人則慢工出細活；有些人善於交流和表述，有些人則言不達意，經常不知所云……充分了解每一個人的狀況以後才能作出相應的安排。如我上文中提到的個人經理安排我到CMMI組就是個錯誤，他不瞭解我對技術的熱愛和對那些充滿僚氣的會議的厭惡。

不要對每件事都親力親爲

諸葛亮就是個很好的反面例子，細緻入微，事必躬親，最後把本身給累死了，團隊還不見得管理得有多好。更值得去作的事情實際上是培訓團隊成員，這樣才能把本身解放出來，有時間去想些別的事情，或專一於項目的某一塊，千萬別把本身想得有多萬能，人的能力再強，時間和精力也是有限的。

不要讓團隊作設計

參考：《再談軟件開發中的合做》。

儘可能發揮每個人的潛力

充分信任和激勵每一個團隊中的成員，讓他們以爲是爲本身作事，而不僅是應付工做。這又是一個很大的話題，如何激勵一我的？我建議去看看《軟件隨想錄》中的第一部分——人員管理。這本書貌似沒有中文電子版，我這裏無法摘錄太多內容，英文夠好的話能夠直接去做者的blog去找找，或者像我這樣直接買一本紙張書，你確定不會後悔。

別輕易招人

根據Brooks（《人月神話》的做者）法則，往一個已經延誤的項目中添加人手，只能帶來更多的延誤。軟件研發這事情毫不是1+1=2那麼簡單，軟件研發的工做沒辦法劃分爲絕不相關的小任務，而後讓不一樣的人無須溝通和交流就能準確執行，因此大多數時候，想經過招人來解決項目延誤的問題都是不太可行的。只有在業務擴大，真正出現人手不足的時候才能招人。

寬鬆化管理

相不相信，其實一個開發人員，可以高效地工做的時間一天不會超過三小時，其他的時間都是低效的，若是從上班開始，除了午飯時間，從頭至尾都在聚精會神地寫代碼，恐怕到下班的時候臉都會發青，這是受人的精力所限，無關工做態度，因此我認爲高效地將工做完成比拖沓地加班加點更有意義。除了完成工做，一個技術人員的最重要的事情恐怕就是能看到本身的長進，工做自己固然會帶來長進，但也不是所有，還得有時間去探索一些本身半熟悉的領域，這樣才能真正提升本身，若是團隊上下都培養出了這種主動地提升本身的水平，又反過來不斷改進本身的工做的「技術氛圍」，那這一定是個高效而有活力的團隊。

也許我說的這些都沒太大意義，由於人的管理每每不受咱們技術人員所控，老闆看到誰加班就認爲誰積極，是好員工，老闆也不會去了解代碼的質量多高多低。但，仍是那句話，不涉及到人的管理最多隻能稱得上是「文案工做」，無論你研究了多少種工具和方法，能起到的做用恐怕也很是有限。

別作沒意義的事情

最後，別作沒意義的事情，若是能夠的話……這是什麼意思？由於有不少沒意義的事情是上頭強加的，你不得不作，但若是你能作決定的話，那就別浪費這個時間了。我之前有家公司，有一次開會的時候一個高級經理提了這麼一個建議，就是要寫「工做時間」，所謂「工做時間」就是你在這一週裏在一個項目中花了多少小時，這個建議被採納並一直執行下去，不久後那高級經理離職了，而我還繼續一直忍受着這該死的錯誤的決定。很長一段時間裏，其實咱們的項目一直處於半停滯中，咱們並無把全部的時間都放在項目裏，有時候去協助別的員工解決一些問題，有時候維護和整理歷史代碼，甚至有時候在修理機器……這些工做算在哪一個項目裏？真真正正我負責的立了項的項目只有一個，叫「PRS2」，因此我每一個「工做時間」都只好寫着「PRS2 40小時」——這樣其實毫無心義。

To 2014

本文應該是我2013年最後一篇博文，再過幾天新年就要到來，其實一年並無想像中的長，有時候時間就是那麼彈指一瞬間即過，但願本身的所做所爲更加有意義，Hello，2014。