當年多少次做夢都在想以後能不能做到那樣的一個程度，可不可以自己不用幹活在旁邊指揮指揮就好，輕輕鬆鬆就拿錢，而且是超高那種。後來發現完全是兩碼事，如果我們不能在短時間內做調整，我敢保證累不死人。多人的開發班子，多條業務線，反正別人做不了的你都得上，關鍵是還有人給你挖坑。**你不做沒人做，你不抗沒人抗。**以下是個人的一些套路，團隊人數不一樣，公司性質不一樣，都可能不一樣。套路是這麼個套路，但能參考
作者 | 紅橙Darren
地址 | http://www.jianshu.com/p/3c51fe0b5860
培訓
有的時候放權，結果卻讓人吐血。如果事事都得自己來那麼會很累，但是若不自己來心裡總覺得不踏實。這個時候我們最好選擇培養一到兩個人,具體視團隊成員而定。給他們洗腦打雞血，把目前所有的經驗和知識分享給他們，最好是要讓他們能夠超過我，能夠取代我甚至可以讓我滾蛋。為什麼不是所有人，就像西遊記裡面師徒四人一樣，很多人都是沙和尚，別跟我講什麼價值觀什麼使命感什麼以後，我就喜歡按時上班按時下班按時拿工資，福利可以分我其他什麼都別跟我扯。對於這種你要花很多的時間，很多是經歷習慣決定的，這就比較尷尬，但是團隊裡面少了他們也不行。所以專案不是很急的時候，面試一年的經驗和三年的經驗對於我來說沒什麼兩樣，需要看你的學習方式和態度，你對知識的追求，因為剛開始我也不需要你幹什麼。 為了提高效率和穩定團隊成員，還需要抽出20%的工作時間來作培訓和交流，作為碼農你給我講制度，講懲罰，講一大堆都代替不了我們一行行去寫程式碼，最直接的方法就是讓他們做的更快更好，若是能比IOS開發週期短，程式更穩定，他們會非常高興，當然這些需要知識和經驗的積累。這些時間我們一般會做三件事情：任務完成情況，技術實現方案討論，學習與講座。
開發
只要是作為團隊成員那麼你就不應該離開程式碼和文件編寫，而只做架構圖或者乾脆讓別人來代替，且不說別人怎麼看你，就單單拿系統來說，後面需要救火的時候別人下班走了，請問你怎麼救。而作為系統的負責人，必須親手領導參與建造，才能有足夠的能力去擔起這個責任。所以剛開始你必須有一半的時間來參與開發工作，所以上班的第一件事應該是把手機放進抽屜做到物理隔絕，然後開啟IDE開始擼碼。當然沒必要什麼都寫：
1.設計搭建架構
這個是最重要的一步，而且很繁瑣，不畫設計圖上來就寫程式碼的技術員，越到後面越慘，而且慘得不行，當然如果你很喜歡縫縫補補，喜歡天天加班倒沒什麼，我就不信那麼多東西你能全記在腦袋裡，奇了怪。對於其他成員來說，架構在分工合作，提高質量，提高開發速度和舒緩開發者心情上面起了決定性的作用。 可以多關注程式碼架構，很多人喜歡關注執行時架構，當然執行時架構是不可少的。程式碼架構是更加穩定的設計方案，一旦發生一些小的需求變化，執行架構肯定會有變化，但是大的方向往往不會變化頻繁，因此我們可以根據大的方向來組織程式碼，劃分模組。所以這個不能亂，一旦亂了不管你怎麼調整還是會問題百出。
2.難點關鍵開發
對於部分難以實現的程式碼我們還是得自己來，在一些中小型企業，如果這些讓別人來做，到頭來還是給自己找麻煩。質量底下的程式碼會造成故障和Bug，後面一旦出現問題也會消耗更多的時間成本，本來人手又緊後面還要到處救火，會導致天天加班而出不來專案。還有部分成員往往沒那個能力，你讓他去實現可能導致功能雖說實現了，但是可控性並不高，一旦需求稍有變動會出現各種問題，出問題沒什麼，關鍵是他根本不知道怎麼解決。在大公司，團隊成員普遍素質比較高，這種現象倒是鮮少出現，但是核心程式碼我們最好還是自己操刀。
3.各種救火
架構部分程式碼往往是最容易出現問題的程式碼，隨著需求的不斷改變有時需要調整，嚴重的還可能會出現Bug，有時還需要防止成員copy你的程式碼另起爐灶，當你改程式碼的時候要改多個地方也比較麻煩。團隊其他成員寫的程式碼也時常出現Bug，往往他自己不能解決這個時候你就得幫忙。當然找問題的過程本身也可以提高技術水平，關鍵是要讓自己和團隊的成員學會使用各種診斷工具，學習思考和分析問題。
管理和學習
1.程式碼稽核
需要讓團隊認識到程式碼審查是為了提高整個團隊的能力，而不是針對個體設定的檢查“關卡”。另外，程式碼審查本身可以提高開發者的能力，讓其從自身犯過的錯誤中學習，從他人的思路中學習。如果開發者對這個流程有牴觸或者反感，這個目的就達不到。 在程式碼審查中如果發現問題，對於被發現者，不主張使用這個方式予以懲罰。軟體開發中bug在所 難免，過度苛求本身有悖常理。更糟的是，如果造成參與者怕承擔責任，影響積極性，程式碼審查就沒有任何的價值和意義。
2.進度稽核和任務分配
任務分配是個大問題，而且又是一個權勢的工作，成員面對一個任務時，往往不能正確、合理地安排時間。如果出不來，會給你若干理由，比如很忙，造成任務延期或者加班，最後造成整個專案的延期。怎麼避免這種情況不能讓班子成員各搞各的，我們自己得有一套任務分解，任務描述和時間分配原則，風險管理和計劃餘地，首先是自己能夠把事情做好，然後可以把他分享給團隊成員。
3.面試和各種會議
準備一份有區分度的筆試題目，不靠譜的人多了去，自稱多少多少年經驗。但你要他寫個倒數計時往往都寫不出來，這麼個題目我們送走了很多人。老闆不是花錢請我來和他們聊天的，所以我通常會問四個方面的內容，原始碼、設計模式、優化、NDK。對於應屆畢業生，我往往倒不是特別關注技術，也不需要他目前能實現各種功能，很多東西我可以自己來可以寫好讓你調。所以我比較關心學習態度、上進心、聽安排、別惹事，這方面HR往往比我們看得準。 部分會議我們可以抵制，能不去就不去。尤其是部門溝通會能躲就躲，那是扯淡者的天堂，測試、產品、設計比程式設計師能扯的多了去。如果還有一個功能等著你去寫，你會很蛋疼。這個時候你可以派一個人去一下就好，回來讓他告訴你發生了什麼。
4.學習
學習一停我們基本就死了，把手機放抽屜也是為了讓我們在閒下來的時間可以去學。而我一般選擇多寫文章，多參加技術沙龍多與別人交流，選擇週末多看看別人的框架原始碼等等，反正我的狀態大家基本瞭解，週六日晚都在給大家做直播分享。只有這樣自己才能得到提升，專案才能做到可控，只有這樣才能去影響團隊成員而不是靠說，當然該說的還是要說。
儘管我們現在還沒有做到那樣的一個程度，但學會像一個技術總監一樣去思考問題，積極樂觀的心態非常重要，學習、思考、努力、利他，day day up!
更多
相信自己，沒有做不到的，只有想不到的
如果你覺得此文對您有所幫助，歡迎入群 QQ交流群 ：644196190 微信公眾號：終端研發部