人員與結構
在團隊中使用層級結構，是否阻礙了個體與外界的溝通？
極少有底層程序員或新手能和產品經理做深入的溝通的，所以中間放上師傅這一層，讓其代為問問題，徒弟旁聽，不但不會阻礙，反而會促進。
這樣徒弟可以更快地學會問答技巧或熟悉業務，真正學成了，師傅才懶得在中間“阻礙”呢，呵呵。
師傅又要懂業務，又要懂技術，又要帶徒弟，是否要求太高了？
的確不低，但是如果不要求這三個師傅如此，就要要求全組如此，更難；當然可以要求讓程序員們可以不懂業務，但這樣的程序員怎么放心讓他干活呢。
但實際上，這點要求算不上什么，和“多才多藝”二字沾不上邊。所以這種人其實很多，只是他們沒被賦予這種職能而已。
師與徒
高手不愿意帶徒弟怎么辦？
所謂求什么得什么，如果企業給個人能力高的人發高薪，而不給能帶團隊的人發高薪，屋子里邊坐著的一定是一堆不愿意帶徒弟的高手；反之則反。
另外一個角度，139團隊不只是一個學習團隊，而首先是一個生產團隊。師傅帶徒弟，一定程度上有上級帶下級的感覺。還沒有一個上級不希望自己有更多手下的，也沒有上級希望自己手下都是飯桶的。
所以制度合適，人自然改變。
招聘了徒弟，沒有師傅愿意帶怎么辦？
以往人是招聘來塞給某人“你負責他的成長的”，現在應該是有師傅說“忙不過來了，給我招聘個徒弟吧”。師傅要參與徒弟的招聘和試用。
徒弟不聽師傅的怎么辦？
試用期就走人。
時間與效率
師傅一個頂仨，照顧別人是否降低效率？
要做好時間管理，就是師傅找徒弟隨時，徒弟找師傅預約（“我有問題……”“好，等15分鐘……（繼續干活至一段落為止）”）。
一個人看那么多人的代碼，會不會很花時間？
高手看新手的代碼，10分鐘就能看到一大堆錯誤。
師傅看徒弟的代碼，5分鐘就行；每天早上做了設計，中間還有前后關鍵點，沒什么可看的。
今天看到的問題，明天不可再見，早晚一天無問題可見。師傅是培養徒弟干活的，不是給徒弟擦屁股的（在試用期就要考核這個，不怕起點低，但一個人連培養價值都沒有，還能干啥）。
專家與雜家
大家需要了解的東西太多，生產率是否降低？
我見過的最高的幾個高手，都是以更廣泛地了解業務和技術為特點的。
我見過一個13個人的團隊，9年來人換了好幾批了，從來都是每人只負責的功能，都是“專家”。產品最后有25萬行，被一個高手花一年半改為1.3萬行。問為什么原來的代碼那么多，答：“原來的專家走了，沒人能看懂其代碼，所以只能大面積拷貝粘貼。”這樣的專家，要他何用。
有些人希望只專注于自己的工作，怎么辦？
目光這么窄的人，能做好自己的工作才怪；所知這么窄的人，能委之重任才怪；一直自己干活的人，能管理部門才怪。很多人苦苦鉆研技術，希望能力提高然后被提拔，實在是緣木求魚。道理一講就通。
如果還講不通，遲早會發現不想當將軍的士兵，連廚子都做不好的，呵呵。
績效與成長
師傅學不到東西怎么辦？
師傅之上還有師傅；師傅人數少，可以送去培訓……師徒制度里邊沒有關于師傅怎么學習的內容，但如果理解“有問題處無答案”，這類問題很好解決。
教會徒弟，會不會餓死師傅？
如果我是老板，我會喜歡下金蛋的鵝，勝過金蛋，因此給鵝更多錢。
如果我是師傅，我會喜歡賣金鵝蛋，勝過賣烤鵝腿，因此能值更多錢。
如果我是徒弟，我會羨慕下金蛋，勝過我就是個蛋（好慘啊）。
徒弟的能力超過師傅怎么辦？
我的編程能力超過我師傅的時候，他做部門經理去了，因為我們部門的所有師傅，都是他的徒弟，不選他選誰。
能力的不總是等于編程能力，而是一種在不同年齡不同層次有不同定義的東西，只有這種東西才能叫做能力。
上面這句話套用金剛經語法，就是“如來所說能力，則非能力，是名能力”，剛開始很難理解，但理解了就發現是一種很通用很有效的思維方式。
比如把“創新”帶進去，就會得到喬布斯的創新觀：我們蘋果所說的創新（價值觀創新），是不能被模仿的創新，所以才叫做創新（換言之能被那么容易模仿的，還談不上什么創新）；你們模仿iPod，我就做iPhone，你們模仿iPhone，我就做iPad；你們模仿iPad，我就得胰腺癌……
因為何為“能力”，怎樣根據“能力”確定師傅和徒弟，根據什么“能力”來考核師徒，是139團隊和松結對編程的核心，所以多說兩句。
?
點擊下載免費的敏捷開發教材：《火星人敏捷開發手冊》
?
)
