[轉]由自助餐想到軟件團隊的管理

 [轉載]

剛纔和同事一塊兒去吃了一頓自助餐，席間談起一個關於自助餐廳的話題。說自助餐老闆爲了賺錢，每每會試圖減小供應的食物量，好比對昂貴的食物用小號的盤子，又或者取肉的時候限制一次只能拿2盤，其實這樣的自助餐廳反而並不賺錢。由於道理很簡單，在空空如也的餐檯前排隊取食的顧客天然造成了競爭關係，不得不花更多的心思去「爭奪」食物；另外一方面，顧客們顯然會對自助餐廳的作法表示不滿，而發泄不滿的最好辦法就是「把花掉的錢吃回來」——不惜把本身吃撐也要和餐廳老闆賭氣！

聰明的自助餐廳會堆積大量的食物，甚至是最昂貴的食物也同樣在餐檯上堆積如山，還不等顧客吃完就繼續上菜。這樣的效果看起來很奢侈，可是食客們即沒有競爭的搶食心態，又不會心懷怨恨地去和本身的腸胃賭氣，所消耗的食物其實會更少。

多是由於最近剛好作了一段時間代理Scrum master的緣故，對「管理」上的事情開始變得敏感起來了，因而情不自禁的就把自助餐廳的管理手法套用到軟件開發團隊裏來對比一番。

我在此以前的幾份開發工做在團隊管理上基本上都是你們熟知的國情化路線：管理就是制定規章制度而後以此去考覈獎懲。我曾經就有一次一入職就讓抱着厚厚的《崗位做業指導書》去啃，而後考試上崗。其實各類制度總結概括起來無外乎就是兩個字——扣錢！這應該是不少國內同仁們很是熟悉的套路了！某些時候咱們甚至還能聽到中層領導們一臉無奈的反問道：「（這事/這人）不扣錢還怎麼管?」

當年我遇到領導這種反問句的時候，感受是無力的。由於我象那些領導們同樣沒有答案！

不過，如今，我感受我彷佛能夠開始尋找而且慢慢接近這個答案了！

正如前面提到的自助餐廳，當你面臨競爭壓力的時候，你所能作的確定是爲本身爭取更多的利益——好比去搶奪食物。而你在和公司（罰款）制度賭氣的時候，可能考慮的會是找到制度的漏洞併爲己所用。

你會發現，你並不愛你的工做，那只是一個賺錢的手段。

你會認爲工做是在爲老闆「賣命」，而不是本身的「事業」。（或許這也是國人熱衷於創業的緣由吧，純屬猜想，基本靠譜！☺）

而形成你這些想法的公司制度，其實不是正好和自助餐廳那些吝嗇、苛刻的營銷手法同樣拔苗助長嗎？若是~~若是沒有這些規章制度，給員工們自由的空間——正如給食客們充裕的食物資源，狀況就會徹底不一樣了：

就像廚子都但願別人誇本身的菜燒得好、裁縫都喜歡別人誇本身的新款衣服作的漂亮。其實每一個人都是有本身的追求的！

當外界對你的限制（好比規章制度）變小甚至沒有的時候，（合格的）員工們會考慮的是什麼呢？

顯然是如何把本身的工做作好！

一個程序員固然會像廚子、裁縫同樣，但願本身的代碼優雅而高效，被用戶所欣賞！

 

看到這裏，估計有人要笑了，不要規章制度來管理，那員工們還怎麼作事呢？那不是要亂套了嗎！

對別的崗位，我不敢妄下斷語，不過對軟件開發團隊而言，這套說法卻是真的可行！

咱們的CTO（先後換過一次，兩位都是瑞典人）歷來就不在崗位職責以及如何作事上對咱們指手畫腳，也幾乎沒有給咱們下發過任何成文的規章制度，可是咱們公司三個開發團隊運做的基本沒有什麼大毛病，所謂的「亂套」還真沒發生過！（這裏說「幾乎」是由於確實有一個成文的值班制度，但僅此一個）

有時候管理就是一個這麼神奇的玩意！

好了，也沒什麼必要賣關子了，其實神奇的地方就是前面所提到的：給開發團隊以自由的空間，他們會本身好好用心作事的——中國話說就是「倉廩足而知禮節，衣食足而知榮辱」——當食客們無需搶食的時候，他們要作的是如何保持風度、體驗美食；當程序員們沒有行政壓力的時候，寫出更好的代碼恐怕是最有可能的追求目標吧！

 

當你讀到這裏，我不得不認可，我其實悄悄偷換了一個概念：咱們的團隊在作事的時候，實際上是有不少不少「制度」的。不過好在這個概念偷換得不算太大，由於這些規範咱們開發過程的「制度」，沒有一個是咱們的領導制定出來的！這些制度的制定者、執行者和被約束者，其實正是咱們團隊中的每個人。

具體咱們是怎麼作的呢？

這個問題不難回答，不過就是套用了Scrum敏捷開發價值觀「團隊按期地反思如何能提升成效，並依此調整自身的舉止表現」

咱們的團隊在每個開發週期結束以後（一週或者兩週）須要進行反思會（retrospective ），我比較喜歡把它稱之爲懺悔日。在會上全部團隊成員都須要進行反思，這時候除了極具自我批判精神的團隊成員以外，你們通常都會把矛頭指向其餘人。若是你在這段時間作過一些讓同伴不快的事情，那就要當心了哦！（壞笑中）

反思的結論會被總結起來，成爲這個團隊的「制度」貼在牆上。目前咱們Team的制度掛在牆上大概已經有三張A4打印紙了，規則不可謂很少也。可是在執行這些規則的時候卻不會有人有什麼怨言——由於任何人都參與過這些規則的制定過程，任何人都知道爲何會有這條規則。好比下面這些是我今天剛剛主持的一場懺悔後製定的規則：

l  Allocate time about old bugs list.　　對未處理的舊bug維護一個評估表。 l  Set some UI rules for all teams.（Game Team do it first）　　全部團隊應該使用一致的UI界面設計 l  Allocate 20% time off for on-call developer now, and change the value as average in future.值班人員的正常工做量減小20%。一段時間以後將此比例更改成平均值。 l  Whose bugs who fix should be faster, if you know whose it is.誰的bug誰修復（若是知道是誰寫的）。 l  Small defect need to be task/story if that need more than 0.5 hour to fix. Because QA would know there is something need to be test with task note.任何超過半小時的缺陷都須要寫成task或者story，由於這樣qa才知道有東西須要測試。 l  Full Integration tests before make a task as 「finish」.完成一個任務前，須要全面的測試之。 l  Keep API method clear and simple.API方法須要保持簡潔。 l  All stories in backlog need to be estimated. All team members do that on every Thursday.每週四評估backlog裏面的故事，全部故事都要被評估。 l  No-planed refactor should be a task and one test task for it.計劃外的重構須要被做爲一個task來完成，而且爲之加一個測試task。 l  Pair work with new comer.和新團隊成員結對工做。 l  Bugs list on A4 paper is better than note paper.在scrum板上的bug用A4紙張比便籤紙好。 l  Discuss test cases when design meeting; discuss bugs after scrum meeting.設計會議的時候須要討論測試用例。Bug在scrum會後討論。 l  Ever bug need Integration test, one at least. 每一個bug都須要加至少一個集成測試。

在上面的示例裏，你們不難看出，如此瑣碎的細節，應該只能稱之爲「規則」而不能算做是「規章制度」。並且，每一個團隊會由於不一樣的工做內容、工做性質和工做方式而獲得本身不一樣的「規則」。因此相信你們應該能夠原諒我在上面偷換概念的行爲了吧！

實際上，團隊成員自主創造規則，並遵循之，這樣的工做效率以及工做成果遠遠好於拿着公司成文的《XXX崗位做業指導書》來指導工做的成績，尤爲是對軟件開發這樣的創造性工做而言！有了寬鬆的工做環境，加上適當的職業道德，一個團隊就能夠「自維護」而且逐步完善——這是我從外國同事那裏領悟的，用來回答「（不扣錢）還怎麼管事/管人」問題的答案！

不過有了這個答案以後，我又不得不面對另外一個尷尬的事實：不少中國人還真的是~~很沒有職業道德！

曾經有一次在一個Q羣裏見到一羣人在討論「外企和國內私企哪一個好？」這樣永恆的話題。其中有人就說，外企好哇，上下班都不用打卡，多自由啊！而後是一堆附合之聲，以及狂罵國內私企沒良心云云。其間，我插嘴了一句，大意是說，外企也都不是一個規格的，有打卡要求很嚴的，也有不打卡的。別忘了打卡機仍是外國人發明的呢！結果卻反被一羣人狂罵，還被不認識的人諷刺曰「你是大牛，怎麼不把我弄去HP上班呢？」

在這些人眼裏，作程序，真的只是一份工做，一個謀生賺錢的手段，不是本身的事業！

在這羣人眼裏，考慮的僅僅只是待遇的高低，工做是否是輕鬆，而不是把本身的能力提高，眼界放遠！

當一個廚子都不期待顧客誇本身的菜好的時候，他仍是廚子嗎？

當面對這麼一羣沒有節操，甚至沒有正常邏輯的「程序員」構成的從業大軍的時候，或許~~~~~~那個使人費解的問題依舊沒有答案：「（這事/這人）不扣錢還怎麼管?」