閱讀Tips: 本文是我根據(jù)這么多年來(lái)的實(shí)際開(kāi)發(fā)杆查、技術(shù)管理經(jīng)驗(yàn)的一些總結(jié)窍蓝，完整閱讀需要30分鐘缴挖，已經(jīng)整理成簡(jiǎn)書(shū)專題《當(dāng)我在做技術(shù)管理時(shí)我在做什么》，可分章節(jié)挑選感興趣的部分閱讀涮坐。
序言
個(gè)人介紹：
聯(lián)合創(chuàng)始人 & CTO凄贩，目前管理20多人的技術(shù)團(tuán)隊(duì)，從事Web開(kāi)發(fā)12年袱讹，使用過(guò)Perl疲扎、ASP、PHP捷雕，從2007年開(kāi)始使用Ruby開(kāi)發(fā)椒丧，主持開(kāi)發(fā)過(guò)音樂(lè)上傳下載網(wǎng)站、網(wǎng)頁(yè)游戲API救巷、癥狀疾病檢索網(wǎng)站壶熏、CRM系統(tǒng)、數(shù)據(jù)可視化浦译、在線GTD項(xiàng)目棒假、任務(wù)管理系統(tǒng)、在線教育精盅、在線呼叫中心淆衷、在線商城、商品采集和點(diǎn)評(píng)渤弛、地方門(mén)戶類網(wǎng)站祝拯、定制微信公眾平臺(tái)、iOS多媒體終端她肯、國(guó)外多種社交網(wǎng)站API數(shù)據(jù)分析等佳头，目前專注敏捷團(tuán)隊(duì)管理。
企業(yè)背景
公司創(chuàng)立于2013至今晴氨，主要從事Web康嘉、移動(dòng)應(yīng)用、微信公眾號(hào)的定制籽前、外包開(kāi)發(fā)亭珍，主要使用ruby/rails/git/linux等編程技術(shù)敷钾，推行敏捷風(fēng)格的開(kāi)發(fā)管理，使用自動(dòng)化部署肄梨、各種共有云服務(wù)阻荒，使用Redmine、Trello众羡、Slack等流行的項(xiàng)目管理侨赡、溝通工具，客戶分布中國(guó)粱侣、美國(guó)羊壹、德國(guó)、澳洲等地齐婴，涉及領(lǐng)域廣泛（見(jiàn)「圖2-2」）
?「圖2-2」2016年項(xiàng)目領(lǐng)域統(tǒng)計(jì)
工作范疇：
“大內(nèi)總管” - 公司的內(nèi)部管理者油猫，負(fù)責(zé)技術(shù)管理、團(tuán)隊(duì)管理柠偶、項(xiàng)目管理
管理的目標(biāo)：
我所做的一切都是為了提高開(kāi)發(fā)效率情妖，讓項(xiàng)目成功交付
目標(biāo)意義：
- 提高開(kāi)發(fā)效率 -> 我們開(kāi)心！
- 項(xiàng)目成功交付 -> 客戶開(kāi)心 -> 爽快結(jié)款 -> 大家開(kāi)心嚣州！
管理什么：
眾所周知鲫售，一個(gè)企業(yè)中CEO主要管四方面：人事物財(cái)
那么對(duì)于CTO呢，我認(rèn)為也是管四個(gè)方面：人事物文
分別對(duì)應(yīng)為：
- 人 - 團(tuán)隊(duì)管理
- 事 - 項(xiàng)目管理
- 物 - 技術(shù)管理
- 文 - 文化建設(shè)
下面分別講一下四個(gè)方面的管理该肴。
人 - 團(tuán)隊(duì)管理
核心思想: 以人為本
團(tuán)隊(duì)是由一群追求一個(gè)或多個(gè)共同目標(biāo)的人組成情竹，通過(guò)一些規(guī)則約束在一起工作。人多不一定是力量大匀哄，也可能是人多手腳亂秦效。要讓一個(gè)團(tuán)隊(duì)高效協(xié)作，核心原則必然是以人為本涎嚼，讓每個(gè)成員在自己的位置得到最有效發(fā)揮阱州，讓個(gè)體與整體相互觸進(jìn)成長(zhǎng)。
我把團(tuán)隊(duì)管理分為6個(gè)方面：
- 定組織架構(gòu) - 要招什么人
- 招聘 - 怎么招人
- 培養(yǎng) - 招到的人怎么培養(yǎng)
- 考核 - 要不要繼續(xù)培養(yǎng)
- 效率管理 - 要培養(yǎng)成高效人材
- 情緒管理 - 是人就有情緒
1. 定組織架構(gòu)
所謂“成大事須合乎天時(shí)地利人和”法梯，其中天時(shí)不如地利苔货，地利不如人和。所有事情歸根都是由人來(lái)推動(dòng)執(zhí)行立哑，因此一個(gè)團(tuán)隊(duì)首先要有適合的人夜惭。
那是不是馬上要講講怎么招人嗎？不急铛绰，首先看公司的業(yè)務(wù)方向诈茧，根據(jù)公司發(fā)展的需要來(lái)選則所需要的人材組建團(tuán)隊(duì)。
所以成熟團(tuán)隊(duì)的管理方案中第一件事應(yīng)該先定好組織架構(gòu)捂掰，定下企業(yè)需要的崗位敢会、職責(zé)曾沈、需要的人數(shù)。
這點(diǎn)其實(shí)跟做產(chǎn)品開(kāi)發(fā)流程很像鸥昏，得先有原型塞俱、設(shè)計(jì)圖，然后才做實(shí)際的開(kāi)發(fā)實(shí)現(xiàn)互广，實(shí)施成本才可控敛腌。
組織架構(gòu)的科普：
企業(yè)組織結(jié)構(gòu)是進(jìn)行企業(yè)流程運(yùn)轉(zhuǎn)卧土、部門(mén)設(shè)置及職能規(guī)劃等最基本的結(jié)構(gòu)依據(jù)惫皱，常見(jiàn)組織結(jié)構(gòu)形式包括中央集權(quán)、分權(quán)尤莺、直線以及矩陣式等旅敷。
企業(yè)的組織架構(gòu)就是一種決策權(quán)的劃分體系以及各部門(mén)的分工協(xié)作體系。組織架構(gòu)需要根據(jù)企業(yè)總目標(biāo)颤霎，把企業(yè)管理要素配置在一定的方位上媳谁，確定其活動(dòng)條件，規(guī)定其活動(dòng)范圍友酱，形成相對(duì)穩(wěn)定的科學(xué)的管理體系晴音。
組織架構(gòu)的作用簡(jiǎn)單來(lái)說(shuō)就是公司的骨架，自上而下明確各個(gè)崗位的職責(zé)缔杉、管理范圍锤躁、責(zé)任鏈，因此不宜經(jīng)常大動(dòng)大改或详。
公司成立了3年多系羞，目前做了2次調(diào)整，「圖3-1」是公司 2016年底定下的組織架構(gòu)中CTO負(fù)責(zé)管理的開(kāi)發(fā)部分
?「圖3-1」組織架構(gòu)
2. 招聘 - 招人其實(shí)也是個(gè)技術(shù)活
有了組織架構(gòu)（設(shè)計(jì)圖紙）后可以招人了霸琴，然而招人這件事本身就是個(gè)技術(shù)活椒振！
從哪里招？同行那么多要發(fā)什么樣的招聘文案才吸引人梧乘？面試時(shí)要問(wèn)什么澎迎？怎么知道對(duì)方是不是有料？什么樣的人適合留下來(lái)选调？要給多少錢(qián)夹供？
一大波的問(wèn)題迎面而來(lái)！
有效過(guò)的招聘渠道大概有3種：內(nèi)部推薦学歧，專業(yè)招聘網(wǎng)站罩引，社區(qū)論壇。
從實(shí)踐結(jié)果來(lái)看枝笨，其中內(nèi)推的結(jié)果最為靠譜袁铐。為了鼓勵(lì)更多的內(nèi)推揭蜒，我在公司內(nèi)提出推行了內(nèi)推獎(jiǎng)勵(lì)機(jī)制：通過(guò)內(nèi)部推薦應(yīng)聘成功的，在試用期轉(zhuǎn)正后剔桨，推薦人可獲取一定現(xiàn)金獎(jiǎng)勵(lì)宏粤，獎(jiǎng)勵(lì)力度跟被推薦人被評(píng)定的職位等級(jí)掛鉤，也就意味著引薦越有實(shí)力的人窄瘟，引薦人則有高的回報(bào)具垫，企業(yè)也能收獲更有實(shí)力的人材，對(duì)企業(yè)而言是小投入高回報(bào)的策略树绩。
另外為了讓招聘文案“新鮮刺激有內(nèi)涵”萨脑，在眾多的招聘帖子中能吸引到小伙伴的眼球，我曾煞費(fèi)苦心收集了大堆團(tuán)隊(duì)的日常照片饺饭，從中挑選一些有代表性渤早，給每一張配上適合的解說(shuō)詞，合并成了一張457x8419 像素的巨長(zhǎng)圖（「圖3-2」）瘫俊，得到一波好評(píng)的同時(shí)也給公司了一次PR鹊杖。
「圖3-2」 公司的日常（@2015.4）
不同的技術(shù)崗位需要掌握的技術(shù)技能自然不同，因此刷選時(shí)也需要面試官對(duì)面試崗位技能都有所掌握扛芽，然而每一門(mén)技術(shù)的技能樹(shù)各不相同骂蓖，如「圖3-3」。
?「圖3-3」前端工程師技能樹(shù)
技術(shù)崗位都需要定一些面試題目來(lái)提高候選人篩選效率和標(biāo)準(zhǔn)化結(jié)果評(píng)估川尖，因此我根據(jù)需要的引進(jìn)的崗位制定一些面試題文檔：
- [公司前端面試題v2015-08-27]
- ruby開(kāi)發(fā)面試@2016-10-09.md
- react-native開(kāi)發(fā) 面試.md
- 開(kāi)發(fā)運(yùn)維面試.md
內(nèi)容涉及對(duì)應(yīng)崗位的編程知識(shí)登下、項(xiàng)目開(kāi)發(fā)的流程及協(xié)作方式、解決問(wèn)題的方法等空厌，考察候選人當(dāng)前的編程水平庐船、項(xiàng)目經(jīng)驗(yàn)、學(xué)習(xí)能力和工作態(tài)度嘲更，用以判斷加入公司后的培養(yǎng)成本和周期筐钟。當(dāng)然大家都知道，只是通過(guò)交談是無(wú)法百分比準(zhǔn)確的判定一個(gè)候選人是否完全符合預(yù)期赋朦，只有真正在一起工作時(shí)才能了解彼此篓冲。
目前所有進(jìn)入公司的技術(shù)人員都是由我親自面試過(guò)，因此引進(jìn)的人員在技能方面是比較有把握的宠哄。
面試的過(guò)程其實(shí)很占用人的時(shí)間壹将、精力的，對(duì)于每位上門(mén)的應(yīng)聘者毛嫉，我都會(huì)耐心的引導(dǎo)诽俯，避免由于面試的緊張導(dǎo)致應(yīng)聘者沒(méi)有發(fā)揮好從而給出錯(cuò)誤的結(jié)論。因此即使沒(méi)有面試通過(guò)的承粤，也得到比較正向的反饋暴区，見(jiàn)「圖3-4」
? [圖3-4] 面試反饋
最后面試的人多起來(lái)了闯团，我們需要安排一面、二面流程提高面試效率仙粱，這時(shí)也需要制定一些流程規(guī)范來(lái)標(biāo)準(zhǔn)化從而提高招聘效率房交，因此我也將這個(gè)流程指定成規(guī)范文檔，見(jiàn)「圖3-5」：
? 「圖3-5」公司招聘流程
除了專業(yè)技能伐割，我認(rèn)為優(yōu)秀員工的重要的品質(zhì)有2點(diǎn)：
- 責(zé)任心
- 主動(dòng)性
但這些是從短短一個(gè)小時(shí)的面試過(guò)程中是看不出來(lái)的候味，因此還要涉及到對(duì)新入職員工的考察，后面一節(jié)會(huì)講到我是怎么做隔心。
面試通過(guò)后白群、談妥了offer后，就是入職安排济炎。
入職過(guò)程不是到公司報(bào)個(gè)道就完事了川抡，有相應(yīng)的入職的流程辐真、需要不同的人協(xié)作须尚，如要安排Mentor、分配帳號(hào)侍咱、滿試用期后考核等等耐床，因此我提出并制定了一個(gè)[公司新員工入職流程]，如「圖3-6」
? 「圖3-6」[公司新員工入職流程]
企業(yè)都想找到適合的員工楔脯，所謂適合撩轰，其實(shí)就是有能力、企業(yè)能給得起錢(qián)昧廷。企業(yè)主不應(yīng)總是對(duì)應(yīng)聘者挑剔堪嫂，懂得要馬跑就要喂馬吃飽的道理，這點(diǎn)是每個(gè)企業(yè)主自身要做好的準(zhǔn)備木柬，雙方各取所需皆串、共同成長(zhǎng)，企業(yè)賺錢(qián)眉枕、員工漲薪才是最大的共贏恶复。
3. 培養(yǎng)
經(jīng)過(guò)了面試雙方談妥，人員入職到崗了速挑，不能丟在一邊“放養(yǎng)”谤牡。要想讓新人盡快通過(guò)磨合，熟悉開(kāi)發(fā)流程姥宝，掌握專業(yè)技能翅萤，盡早能獨(dú)立完成開(kāi)發(fā)任務(wù)，我采用以下幾種方案：
- 引入Mentor制度
- [公司 新人提點(diǎn)注意事項(xiàng)]
- code review：[Code Review Tips]
- pair programming
- 內(nèi)部培訓(xùn)腊满、分享
- 官方blog
- 外部技術(shù)交流會(huì)
引入Mentor制度
Mentor制套么，是指定了一名同類崗位流纹、高一級(jí)別的同事作為“導(dǎo)師”，來(lái)帶領(lǐng)入職的同事熟悉開(kāi)發(fā)環(huán)境违诗、開(kāi)發(fā)流程漱凝、代碼規(guī)范等，讓新人盡快通過(guò)磨合诸迟，熟悉團(tuán)隊(duì)茸炒、有歸宿感。我不認(rèn)可那種一來(lái)就直接指派個(gè)任務(wù)卡片阵苇，丟下一句“自己看代碼學(xué)習(xí)壁公，這周內(nèi)搞掂”的放養(yǎng)式管理風(fēng)格。將心比心绅项，人到一個(gè)陌生的環(huán)境紊册，都是期待能得到一些簡(jiǎn)單的指引，有時(shí)只有簡(jiǎn)單幾句話快耿，也會(huì)有種安全感囊陡。
[公司 新人提點(diǎn)注意事項(xiàng)]
這是我整理給Mentor的指導(dǎo)文檔，一般的開(kāi)發(fā)人員平時(shí)都只是做日常開(kāi)發(fā)掀亥，一開(kāi)始也不懂得如何指導(dǎo)新人撞反，為了解決這種窘?jīng)r，我整理了這么一份文檔（「圖3-7」）搪花，內(nèi)容實(shí)際就是公司知識(shí)庫(kù)WIKI中的一些內(nèi)容的鏈接索引遏片，另外特別強(qiáng)調(diào)了注意不要分享整個(gè)文檔給新人，要鍛煉他們自己的學(xué)習(xí)能力撮竿。
? 「圖3-7」公司 新人提點(diǎn)注意事項(xiàng)
code review：[Code Review Tips]
我們?cè)谌粘ｉ_(kāi)發(fā)中鼓勵(lì)并推行code review（代碼審查）吮便。
在每個(gè)項(xiàng)目立項(xiàng)進(jìn)入開(kāi)發(fā)階段時(shí)，我會(huì)根據(jù)開(kāi)發(fā)組成員的級(jí)別設(shè)定審查鏈幢踏，按照 “中級(jí)審初級(jí)髓需，高級(jí)審中級(jí)，高級(jí)互審”惑折，沒(méi)有合適的人時(shí)我來(lái)審查授账，開(kāi)發(fā)任務(wù)完成后，任務(wù)開(kāi)發(fā)者需要發(fā)Pull/Merge Request給指定好的審查者進(jìn)行審查和合并惨驶，確保每次代碼合并前都有2個(gè)人能看到過(guò)白热，一般只有在做演示出現(xiàn)exception，需要緊急合并做部署時(shí)才會(huì)跳過(guò)code reivew流程粗卜。
推行code reivew需要有2個(gè)人以上的協(xié)作屋确，自然是有代價(jià)的，那有什么好處？
見(jiàn)「圖3-8」中我在公司W(wǎng)IKI [code review tips]中給的回答：
? 「圖3-8」code review tips
相當(dāng)于另一種pair programing攻臀，大家的編程水平都能提高（無(wú)論是提出問(wèn)題的焕数，還是被指出問(wèn)題的）
讓一個(gè)新人融入團(tuán)隊(duì)沒(méi)有比在一起討論代碼更快的方式了，特別是對(duì)于新人而言刨啸，對(duì)代碼規(guī)范不熟悉堡赔，通過(guò)code reivew能有效減少低質(zhì)量代碼的check in，對(duì)個(gè)人设联、對(duì)團(tuán)隊(duì)善已、對(duì)項(xiàng)目都是很有益的一項(xiàng)安排。
至于要怎么做好code reivew這件事离例，需要另開(kāi)新篇來(lái)闡述换团，「圖3-8」中有review代碼的要點(diǎn)摘要，在這里就不展開(kāi)了宫蛆。
「圖3-9」是我日常進(jìn)行code reivew 發(fā)現(xiàn)問(wèn)題的一些總結(jié)艘包，在團(tuán)隊(duì)內(nèi)也做過(guò)一次專題的培訓(xùn)
? 「圖3-9」 code review examples
?「圖3-10」code reuse - DRY your codes
特別提一下，設(shè)定固定的審查鏈的好處是減少審查者的負(fù)擔(dān)耀盗，每個(gè)人只需負(fù)責(zé)1~2個(gè)的代碼審查想虎；階級(jí)式的安排，可以讓高級(jí)的不用反復(fù)的去提點(diǎn)低級(jí)人的一些低級(jí)錯(cuò)誤袍冷，反復(fù)指出一些低級(jí)問(wèn)題對(duì)高級(jí)人員是負(fù)擔(dān)也是干擾磷醋，容易累積高級(jí)人員缺乏成就感的情緒（程序員的一個(gè)特質(zhì)是喜歡有挑戰(zhàn)性的任務(wù)）。
pair programming
結(jié)對(duì)編程的好處不用多說(shuō)胡诗，我鼓勵(lì)結(jié)對(duì)編程，但不會(huì)強(qiáng)制安排淌友，不會(huì)要求像教科書(shū)般要求在某個(gè)時(shí)間規(guī)規(guī)矩矩的一個(gè)看一個(gè)寫(xiě)煌恢，實(shí)際上一般的情景是某個(gè)同事有問(wèn)題時(shí)，需要找我或作指導(dǎo)的其他同事震庭，拿上電腦大家坐在一起討論瑰抵、直接敲代碼（「圖3-11」）：
內(nèi)部培訓(xùn)、分享
團(tuán)隊(duì)的強(qiáng)大不能依賴個(gè)體器联，新知識(shí)只有一個(gè)人掌握時(shí)二汛，不等于團(tuán)隊(duì)掌握了，分享出來(lái)團(tuán)隊(duì)技術(shù)才能成長(zhǎng)拨拓。
在每周五下午肴颊，我會(huì)不定期的安排一些內(nèi)部的培訓(xùn)，技術(shù)的渣磷、設(shè)計(jì)的婿着、產(chǎn)品的，不限制領(lǐng)域，既是對(duì)個(gè)人的一次鍛煉竟宋，又同時(shí)是給大家一個(gè)休息提完、坐在一起討論的時(shí)間（「圖3-12」）
? 「圖3-12」內(nèi)部培訓(xùn)
官方blog
知識(shí)的累積和鞏固途徑由淺到深可分為“聽(tīng)讀寫(xiě)說(shuō)”，但聽(tīng)別人說(shuō)不如自己讀書(shū)丘侠，讀書(shū)不如動(dòng)手練習(xí)寫(xiě)寫(xiě)徒欣，寫(xiě)不如說(shuō)出來(lái)給別人聽(tīng)。能親口說(shuō)出來(lái)的知識(shí)掌握得最牢固蜗字，不過(guò)不是人人都有勇氣在別人面前開(kāi)口帚称，因此我們?cè)O(shè)立了團(tuán)隊(duì)Blog，把掌握到知識(shí)“寫(xiě)”出來(lái)秽澳。
我會(huì)不定期給技術(shù)人員安排“功課”闯睹，給定一個(gè)主題和大綱，將一些開(kāi)發(fā)的心得總結(jié)整理成博客文章担神，經(jīng)我審查修訂后發(fā)布到公司的博客上楼吃，這樣即可以讓當(dāng)事人的知識(shí)更加鞏固，又可以給其他同事作參考指引，另外還可以對(duì)外展示公司的技術(shù)能力和形象扰柠，可謂一舉多得榜轿。
外部技術(shù)交流會(huì)
只是內(nèi)部交流是不足夠的，還要看看別人是怎么做的躬窜，做法很簡(jiǎn)單要么走出去要么請(qǐng)人來(lái)。
我們會(huì)不定期安排一些優(yōu)秀的員工炕置，參加的一些技術(shù)沙龍活動(dòng)開(kāi)拓眼界和學(xué)習(xí)荣挨。
我們會(huì)邀請(qǐng)其他企業(yè)的、行業(yè)的技術(shù)專家過(guò)來(lái)朴摊，給團(tuán)隊(duì)分享技術(shù)上的默垄、產(chǎn)品上的、團(tuán)隊(duì)管理上的經(jīng)驗(yàn)甚纲。
交流應(yīng)該是雙向的口锭，我個(gè)人也會(huì)被邀請(qǐng)到其他技術(shù)團(tuán)隊(duì)、交流活動(dòng)分享我的技術(shù)經(jīng)驗(yàn)介杆、心得鹃操，讓外界了解公司技術(shù)實(shí)力。
我自己曾作為2015年的Rubyconf China活動(dòng)講師春哨，跟現(xiàn)場(chǎng)300多ruby開(kāi)發(fā)者們交流（「圖3-13」）
? 「圖3-13」Rubyconf China 2015
4. 考核
前面提到荆隘，除了專業(yè)技能，我認(rèn)為優(yōu)秀員工的重要的品質(zhì)有2點(diǎn)：
- 責(zé)任心
- 主動(dòng)性
但這些是從短短一個(gè)小時(shí)的面試過(guò)程中是看不出來(lái)的悲靴，因此還要涉及到對(duì)新入職員工的考察和審核臭胜，試用期就是很好的一個(gè)讓雙方了解磨合的階段莫其。
在前面提到的[公司新員工入職流程]中，我要求Mentor在試用期結(jié)束后耸三，需要對(duì)新人進(jìn)行評(píng)價(jià)審查乱陡，而評(píng)價(jià)審查的大綱很簡(jiǎn)單：
- 基礎(chǔ)
- 學(xué)習(xí)能力
- 態(tài)度
- 交流
1是考察當(dāng)前能力水平，這點(diǎn)在面試時(shí)已經(jīng)大概了解仪壮，相當(dāng)于驗(yàn)證一下是否有水分憨颠，短短的試用期內(nèi)也不大可能突飛猛進(jìn)；
2考察個(gè)人潛質(zhì)积锅，對(duì)個(gè)人發(fā)展很重要爽彤；
3是看責(zé)任心和態(tài)度，遇到問(wèn)題會(huì)不會(huì)主動(dòng)找人反饋或協(xié)助缚陷？交代的任務(wù)超出預(yù)期時(shí)間不能完成有沒(méi)有主動(dòng)反饋給項(xiàng)目組長(zhǎng)适篙？
4是考察團(tuán)隊(duì)協(xié)作，對(duì)團(tuán)隊(duì)重要箫爷，有些程序員動(dòng)手能力強(qiáng)但比較內(nèi)向嚷节，溝通能力略有欠缺的，那就可以安排不需要很多溝通需要的任務(wù)虎锚。
一般初級(jí)安排1到2個(gè)月的實(shí)習(xí)硫痰，但基本上1、2周都能看出一些問(wèn)題了窜护，這時(shí)我是愿意給機(jī)會(huì)調(diào)整效斑，看重后續(xù)的成長(zhǎng)，但如果到了實(shí)習(xí)結(jié)束期都還是不行的柱徙，那就只能勸退了缓屠。
審查內(nèi)容只有4點(diǎn)，因?yàn)閷?xiě)評(píng)價(jià)報(bào)告這件事對(duì)Mentor是開(kāi)發(fā)工作之外的一種負(fù)擔(dān)坐搔，我盡量簡(jiǎn)化文檔/報(bào)告的復(fù)雜度藏研，減少干擾，接下來(lái)效率管理就會(huì)提到具體怎么做概行。
5. 效率管理
核心思想：減少干擾
程序員最煩什么？最煩的不是任務(wù)有多難多重弧岳，而是在寫(xiě)代碼時(shí)被干擾打斷凳忙。為此我需要從溝通方式、工作流程禽炬、協(xié)作方式各種方面來(lái)解決干擾的問(wèn)題涧卵，我大概歸納為“四化”：
- 溝通明朗化
- 工作流程化
- 開(kāi)發(fā)自動(dòng)化
- 協(xié)作清晰化
溝通明朗化 - 限定溝通工具、使用好工具
為了減少對(duì)開(kāi)發(fā)人員的打斷腹尖，可以把需要溝通討論的內(nèi)容根據(jù)“輕重緩急”柳恐，粗略分為“緊急且重要”，“緊急不重要”，“重要不緊急”乐设。
- 緊急且重要的讼庇，就當(dāng)面溝通。面對(duì)面溝通是效率最高的近尚，然而這種情況也是最干擾的蠕啄，因此應(yīng)該判斷好溝通內(nèi)容是否確實(shí)那么緊急且重要；
- 緊急不重要的戈锻，但期待對(duì)方盡快有反饋的歼跟，我們鼓勵(lì)在企業(yè)IM上進(jìn)行對(duì)話，這樣對(duì)話內(nèi)容以后還有歷史記錄格遭。至于企業(yè)IM哈街，我們團(tuán)隊(duì)目前是使用Slack，支持@提醒拒迅、公私分組骚秦、代碼片段高亮、各種服務(wù)跟chatbot集成坪它，強(qiáng)烈推薦技術(shù)團(tuán)隊(duì)使用（見(jiàn)「圖3-14」）骤竹；
- 重要不緊急、需要存檔或者不期待對(duì)方馬上給反饋的往毡，就建議使用Email蒙揣，常見(jiàn)如一些重要公告、會(huì)議記錄通知开瞭。
- 其他的如任務(wù)反饋懒震、code review的留言等，不需要馬上有答復(fù)的嗤详，只需要在任務(wù)管理工具上留言个扰，這樣有源可塑。
? 「圖3-14」Slack example
另外還有一點(diǎn)要提的是葱色，作為管理者應(yīng)該有意識(shí)的界定IM工具的使用場(chǎng)景递宅，我們工作時(shí)間使用Slack，這樣只要是通過(guò)Slack發(fā)過(guò)來(lái)的消息苍狰，我們能第一時(shí)間意識(shí)到是有工作相關(guān)的問(wèn)題需要討論了办龄，以便能及時(shí)作出反饋。Slack中按項(xiàng)目建立分組淋昭，所以往往只是看到消息是來(lái)自哪個(gè)分組俐填，不用看消息內(nèi)容，就以及知道大概是要討論什么內(nèi)容翔忽，自然在腦中切換上下文英融，提高溝通效率盏檐。
不建議使用微信/QQ作為企業(yè)內(nèi)部的溝通工具，由于微信/QQ混合了非工作消息的通知驶悟，開(kāi)發(fā)人員不能很好的區(qū)分開(kāi)這是有工作消息胡野、還是普通社交聊天消息，很容易錯(cuò)過(guò)重要的工作信息撩银。但有人會(huì)說(shuō)跟外部的人溝通時(shí)是避免不了使用微信/QQ给涕，注意，這里說(shuō)的是“企業(yè)內(nèi)部的溝通工具的選擇”额获，對(duì)外該使用什么的還是用什么够庙，兩者并不沖突。
工作流程化 - 不要每次都讓我告訴你什么時(shí)候該做什么
在團(tuán)隊(duì)中抄邀，特別是進(jìn)行軟件開(kāi)發(fā)項(xiàng)目時(shí)耘眨，需要有一定的流程指引，那么大家在一起進(jìn)行工作時(shí)可以分工境肾、分步協(xié)作剔难，清楚知道自己、別人下一步會(huì)做什么奥喻，自己會(huì)不會(huì)被干擾偶宫，從而提高協(xié)作的效率。
為此我根據(jù)我們公司實(shí)際的需要环鲤，制定了一些規(guī)范文檔纯趋，從接到項(xiàng)目需求，到項(xiàng)目評(píng)估冷离、立項(xiàng)吵冒、開(kāi)發(fā)、具體到代碼提交西剥、部署痹栖、驗(yàn)收都做了流程規(guī)范，例如：
- [公司開(kāi)發(fā)流程規(guī)范] - 規(guī)范了從需求確定瞭空、項(xiàng)目評(píng)估揪阿、項(xiàng)目確立、開(kāi)發(fā)咆畏、驗(yàn)收交付到項(xiàng)目結(jié)束總結(jié)各個(gè)階段的各角色的工作內(nèi)容范圍和輸入輸出的文檔图甜，見(jiàn)「圖3-15」
- [公司招聘流程] - 前面提到過(guò)了，見(jiàn)「圖3-5」
- 開(kāi)發(fā)流程圖 - 創(chuàng)建feature分支 -> 提交PR/MR -> code review -> 部署staging -> QA -> 部署production
- 提倡git flow - 使用Github/Gitlab flow鳖眼，代碼提交使用Pull/Merge Request來(lái)進(jìn)行code review
? 「圖3-15」公司開(kāi)發(fā)流程規(guī)范
定好工作流程，大家都能從中找到自己的位置和角色嚼摩，知道在什么階段要做什么钦讳、下一步做什么矿瘦、要跟誰(shuí)協(xié)作，不能有“一頭霧水”的感覺(jué)愿卒。
開(kāi)發(fā)自動(dòng)化 - 把重復(fù)丟給機(jī)器
我提倡善用工具最大程度做到自動(dòng)化缚去，這種思維是貫穿整個(gè)開(kāi)發(fā)流程各個(gè)環(huán)節(jié)的。
如最普通的Terminal（終端shell）琼开，推薦使用帶交互的shell（如zsh/Fishshell）來(lái)輔助cli的操作易结，鼓勵(lì)善用alias來(lái)簡(jiǎn)化重復(fù)的使用命令；
代碼開(kāi)發(fā)時(shí)鼓勵(lì)使用支持自動(dòng)完成的IDE柜候、編輯器（如Sublime Text）搞动，鼓勵(lì)善用代碼snippet來(lái)減少重復(fù)編碼的操作；
代碼測(cè)試使用自動(dòng)化測(cè)試（可配合guard或者livereload達(dá)到保存時(shí)自動(dòng)跑相關(guān)測(cè)試）渣刷；
代碼提交使用自動(dòng)化命令（gitlab-send-merge-request of git-cmd-helpers）鹦肿，一步完成代碼提交并發(fā)Merge request；
項(xiàng)目部署使用自動(dòng)化部署工具（如Chef辅柴、Capistrano）箩溃，做到一鍵部署；
使用CI（GitlabCI）進(jìn)行自動(dòng)化測(cè)試碌嘀、自動(dòng)構(gòu)建涣旨、構(gòu)建結(jié)果通知、自動(dòng)部署股冗、自動(dòng)打包上傳app package霹陡，達(dá)到DevOps的自動(dòng)化；
服務(wù)使用健康監(jiān)控（如Monit魁瞪，God）穆律，自動(dòng)監(jiān)測(cè)服務(wù)健康并自動(dòng)重啟服務(wù)；
一句話就是盡量把重復(fù)的工作丟給機(jī)器去做导俘，人力應(yīng)該專注在機(jī)器解決不了的地方峦耘。
協(xié)作清晰化 - 讓你知道什么時(shí)候要去找誰(shuí)做什么
為了解決協(xié)作清晰問(wèn)題，我們使用3種管理方法：
- [公司 Agenda] - 團(tuán)隊(duì)共享日程表
- [公司 collaboration] - 團(tuán)隊(duì)協(xié)作（非特定項(xiàng)目）任務(wù)管理
- project board - 具體的項(xiàng)目管理布告板旅薄，在后面的項(xiàng)目管理章節(jié)中會(huì)具體提及
一個(gè)項(xiàng)目開(kāi)發(fā)時(shí)必定會(huì)定下一些關(guān)鍵的時(shí)間節(jié)點(diǎn)辅髓，如什么時(shí)候開(kāi)會(huì)討論、什么時(shí)候開(kāi)發(fā)結(jié)束少梁、什么時(shí)候做演示洛口、什么時(shí)候正式上線；公司內(nèi)必會(huì)有人員活動(dòng)的變化凯沪，如公共節(jié)假日怎么安排第焰、團(tuán)建、什么時(shí)候有面試安排妨马、團(tuán)隊(duì)成員中必然會(huì)有事生病請(qǐng)個(gè)假什么的等等。
為了讓這些跟時(shí)間節(jié)點(diǎn)、會(huì)影響到人員在線情況的事件在團(tuán)隊(duì)中清晰透明浪耘、避免沖突饶深，我在公司里發(fā)起推行了“團(tuán)隊(duì)日歷共享計(jì)劃 - [公司 Agenda]”（見(jiàn)「圖3-16」），這樣大家都能有個(gè)清晰的預(yù)期，知道最近有什么短期目標(biāo)、有什么事需要準(zhǔn)備、什么時(shí)候有會(huì)議要開(kāi)砌左、哪個(gè)小伙伴會(huì)沒(méi)有空。具體做法很簡(jiǎn)單铺敌，使用Google Calendar服務(wù)進(jìn)行日歷共享汇歹，客戶端使用Mac Calendar查看，約定好事件的標(biāo)題格式“[公司名-項(xiàng)目名] 事件類別: 事件標(biāo)題”适刀。
另外注意一點(diǎn)秤朗，在推行新制度時(shí)，使用流行的服務(wù)和系統(tǒng)自帶的工具笔喉，可以降低推行阻力取视。
? 「圖3-16」公司 agenda
但日歷只能也只應(yīng)該記錄事件標(biāo)題和日期時(shí)間，更具體的內(nèi)容常挚，我們?cè)赥rello上建了一個(gè)board來(lái)進(jìn)行管理作谭，如我們的團(tuán)隊(duì)分享安排、團(tuán)建安排奄毡、假期的安排等折欠。
至于更具體的項(xiàng)目開(kāi)發(fā)任務(wù)，我們是使用獨(dú)立的項(xiàng)目管理工具吼过，在后面的項(xiàng)目管理章節(jié)中會(huì)提及锐秦。
6. 情緒管理
是人就會(huì)有情緒，了解員工的情緒問(wèn)題也是管理工作的日常之一盗忱。在公司還沒(méi)有強(qiáng)大到有專職的“程序員鼓勵(lì)師”時(shí)酱床，也只有親身上陣，我推行了3種方式：
- 員工一對(duì)一談話 - 聊天是舒緩情緒很簡(jiǎn)單有效的一種方式趟佃，無(wú)論工作問(wèn)題扇谣、生活問(wèn)題，都可以坐下來(lái)面對(duì)面聊一聊闲昭，討論下解決方法
- 員工年度調(diào)查 - 有些話不適合罐寨、不方便當(dāng)面說(shuō)的，那么可以寫(xiě)下來(lái)序矩，為此我發(fā)布過(guò)[2015年 公司員工年度調(diào)查]鸯绿，收集對(duì)工作流程、工作環(huán)境、薪資待遇楞慈、公司發(fā)展建議等
- 戶外團(tuán)建活動(dòng) - 離開(kāi)工作環(huán)境人的情緒會(huì)得到放松幔烛，為此我擬訂過(guò)[公司2016團(tuán)隊(duì)建設(shè)活動(dòng)計(jì)劃]
我自認(rèn)為在這方面做得還不夠好，InfoQ上有篇文章《技術(shù)團(tuán)隊(duì)的情緒與效率》 值得參考借鑒囊蓝。
事 - 項(xiàng)目管理
前面團(tuán)隊(duì)管理中說(shuō)“團(tuán)隊(duì)是由一群追求一個(gè)或多個(gè)共同目標(biāo)的人組成，通過(guò)一些規(guī)則約束在一起工作”令蛉，而項(xiàng)目管理則是為了讓團(tuán)隊(duì)能在資源聚霜、人員限定的情況下，能按預(yù)期達(dá)成目標(biāo)的手段和方法珠叔。
核心思想：有的放矢
項(xiàng)目管理的注意3點(diǎn)：
- 目標(biāo)清晰 - 要做什么蝎宇、什么時(shí)候完成
- 控制節(jié)奏 - 有了目標(biāo)，就要管理好節(jié)奏祷安，是一步到位還是小步快跑
- 制定規(guī)范 - 無(wú)規(guī)矩不成方圓姥芥，現(xiàn)代化團(tuán)隊(duì)作戰(zhàn)講究統(tǒng)一、標(biāo)準(zhǔn)汇鞭、量化
1. 目標(biāo)清晰
在項(xiàng)目開(kāi)發(fā)中凉唐，有3點(diǎn)需要清晰：
- 需求清晰 - 要做什么，做給誰(shuí)用霍骄，做成什么樣
- 任務(wù)清晰 - 安排什么人台囱，在什么時(shí)候，具體做什么
- 節(jié)點(diǎn)清晰 - 要在什么時(shí)候做完
針對(duì)以上這3點(diǎn)我制定了以下文檔读整、規(guī)范：
- 明確需求 - [公司 PRD文檔規(guī)范]
- 明確任務(wù) - [公司 Trello使用規(guī)范]
- 明確節(jié)點(diǎn) - [公司 Agenda]
下面分別說(shuō)下具體的做法簿训。
[公司 PRD文檔規(guī)范]
PRD（產(chǎn)品需求文檔），相當(dāng)于是產(chǎn)品的工程設(shè)計(jì)圖紙米间，是給開(kāi)發(fā)人員使用的强品，它的主要目的是陳述產(chǎn)品是什么，有什么功能屈糊，給什么人用的榛，是什么樣子。因此我認(rèn)為一份PRD中應(yīng)包含以下7部分：產(chǎn)品說(shuō)明文檔另玖、產(chǎn)品信息結(jié)構(gòu)圖困曙、產(chǎn)品功能結(jié)構(gòu)圖、邏輯流程圖谦去、原型圖慷丽、功能點(diǎn)列表、設(shè)計(jì)文檔鳄哭，如「圖4-1」要糊，主要是說(shuō)明每份文檔是什么、有什么用妆丘、大概長(zhǎng)什么樣锄俄。
? 「圖4-1」公司 PRD 文檔規(guī)范
開(kāi)發(fā)人員常說(shuō)我不怕需求復(fù)雜也不怕需求太多局劲，最怕的是我費(fèi)心費(fèi)力使用了優(yōu)雅的設(shè)計(jì)模式、重構(gòu)了代碼奶赠、加了單元測(cè)試后PM對(duì)我說(shuō)句“xx需求不要了”鱼填。所以如果作為產(chǎn)品PM，當(dāng)整理過(guò)一份完整的PRD后毅戈，其實(shí)已經(jīng)對(duì)產(chǎn)品的邏輯性苹丸、合理性做了一次梳理，再傳達(dá)到開(kāi)發(fā)團(tuán)隊(duì)手里時(shí)苇经，能有效減少返工赘理、無(wú)效需求的“折騰”。在這里要認(rèn)清的一個(gè)事實(shí)就是：沒(méi)有不變的需求扇单！所以我們要做的只是盡量減少無(wú)效需求傳導(dǎo)到開(kāi)發(fā)手中商模，讓開(kāi)發(fā)的輸出更有價(jià)值。
[公司 Trello使用規(guī)范]
Trello是個(gè)看板風(fēng)格的協(xié)作工具蜘澜，上手十分簡(jiǎn)單施流，但由于Trello本身十分松散靈活，100個(gè)團(tuán)隊(duì)有100種用法兼都，因此為了方便統(tǒng)籌管理嫂沉，我制定了一些使用流程并整理成規(guī)范文檔[公司 Trello使用規(guī)范]（見(jiàn)「圖4-2」），包含對(duì)list扮碧、label使用以及card生命周期的流轉(zhuǎn)趟章，讓每個(gè)任務(wù)從需求轉(zhuǎn)化為任務(wù)，到分配慎王、評(píng)估蚓土、開(kāi)發(fā)、部署赖淤、測(cè)試蜀漆、上線，意圖讓每一步都清晰可預(yù)期咱旱，參與員之間協(xié)作配合清晰可見(jiàn)确丢。
我們的項(xiàng)目管理布告版也會(huì)對(duì)客戶開(kāi)放，我們希望讓客戶從一開(kāi)始就可以參與到日常開(kāi)發(fā)流程中吐限，可以了解項(xiàng)目的開(kāi)發(fā)具體進(jìn)度鲜侥，也方便收集對(duì)需求任務(wù)的討論、BUG反饋诸典，以及給客戶分配一些他們所要配合的工作（如一些基礎(chǔ)服務(wù)帳號(hào)注冊(cè)）描函，讓協(xié)作由內(nèi)而外都可以貫通。為此我特意把這個(gè)文檔寫(xiě)了英文版，以發(fā)放給國(guó)外合作的客戶參閱以便了解我們是怎么使用Trello的舀寓。幫助客戶培養(yǎng)成合理的協(xié)作習(xí)慣胆数，這其實(shí)對(duì)我們進(jìn)行高效項(xiàng)目管理也會(huì)更有利。
? 「圖4-2」公司 Trello使用規(guī)范
[公司 Agenda]
一個(gè)項(xiàng)目開(kāi)發(fā)互墓，需要定一些時(shí)間節(jié)點(diǎn)必尼，如什么時(shí)候正式立項(xiàng)，以便項(xiàng)目經(jīng)理可以召集開(kāi)發(fā)團(tuán)隊(duì)轰豆、召開(kāi)立項(xiàng)會(huì)議胰伍；什么時(shí)候做交付演示，以便讓QA工程師可以準(zhǔn)備用戶故事酸休；什么時(shí)候正式上線，以便項(xiàng)目組技術(shù)組長(zhǎng)可以準(zhǔn)備交付文檔祷杈；時(shí)候做營(yíng)銷推廣以便運(yùn)維人員可以做好服務(wù)器壓力測(cè)試調(diào)整服務(wù)器配置……
前面在說(shuō)如何解決團(tuán)隊(duì)協(xié)作清晰化中斑司，提到了使用“團(tuán)隊(duì)日歷共享計(jì)劃 - [公司 Agenda]”（見(jiàn)「圖3-16」），因此我要求項(xiàng)目經(jīng)理給每個(gè)項(xiàng)目添加2種事件類型但汞，一個(gè)是CHECKPOINT（檢查點(diǎn)）宿刮，一個(gè)是DEADLINE（最后期限）。CHECKPOINT是階段性的時(shí)間節(jié)點(diǎn)私蕾，DEADLINE是當(dāng)前版本最終的交付限期僵缺；一個(gè)開(kāi)發(fā)版本內(nèi)可以有多個(gè)CHECKPOINT，但只有一個(gè)DEADLINE踩叭。
做事應(yīng)有始有終磕潮，我要求每個(gè)項(xiàng)目的每個(gè)大版本開(kāi)發(fā)，都要定一個(gè)DEADLINE（最后期限）容贝，期限是構(gòu)成目標(biāo)的要素自脯，沒(méi)有期限則沒(méi)有目標(biāo)，沒(méi)有目標(biāo)何從談管理斤富。
CHECKPOINT則是一些階段性的目標(biāo)膏潮，到達(dá)一個(gè)DEADLINE之前，可以有多個(gè)CHECKPOINT满力；一個(gè)CHECKPOINT可以是任何關(guān)鍵事件焕参，如階段演示、交付演示油额，可安排階段小結(jié)會(huì)議來(lái)討論技術(shù)問(wèn)題調(diào)整開(kāi)發(fā)計(jì)劃叠纷。
個(gè)人todo管理tips
在日常工作中，往往又有一些個(gè)人的代辦事項(xiàng)悔耘，如某項(xiàng)技術(shù)調(diào)研讲岁、培訓(xùn)文檔準(zhǔn)備等不適合放入?yún)f(xié)作的任務(wù)列表的，也要管理起來(lái)，我現(xiàn)在的做法如下：
- 不需要協(xié)作的缓艳，放入 Wunderlist（可跨多終端）;
- 需要team范圍知曉的校摩、有明確日程安排的，放Agenda;
- 跟具體項(xiàng)目相關(guān)的阶淘，放在對(duì)應(yīng)的項(xiàng)目trello board
2. 控制節(jié)奏
項(xiàng)目開(kāi)發(fā)有如組織團(tuán)隊(duì)賽跑衙吩，需要控制好節(jié)奏，什么時(shí)候要留力調(diào)整速度溪窒，什么時(shí)候要加速?zèng)_刺坤塞，都應(yīng)該有規(guī)劃。
我根據(jù)這些年來(lái)的項(xiàng)目開(kāi)發(fā)經(jīng)驗(yàn)澈蚌，整理了一份開(kāi)發(fā)流程規(guī)范 [公司開(kāi)發(fā)流程規(guī)范]（見(jiàn)「圖 17」）摹芙，劃分出幾個(gè)階段，每個(gè)階段有主要參與的角色及其主要任務(wù)宛瞄、有輸入輸出的結(jié)果浮禾，以便項(xiàng)目參與者明確自己角色的任務(wù)。
項(xiàng)目開(kāi)發(fā)流程大綱：
- 選定項(xiàng)目管理框架/風(fēng)格：Kanban + Scrum
- 選定項(xiàng)目管理工具：
- 默認(rèn)：Trello + Scrum Extension
- 其他：Redmine份汗，Teambition盈电，Worktile，Tower
- 角色安排：項(xiàng)目經(jīng)理杯活，產(chǎn)品經(jīng)理匆帚，項(xiàng)目組長(zhǎng)，開(kāi)發(fā)旁钧，測(cè)試吸重，運(yùn)維
- 流程安排：
1. 需求確定 - 確立需求可行性
2. 項(xiàng)目評(píng)估 - 根據(jù)PRD評(píng)估開(kāi)發(fā)量，確定項(xiàng)目周期
3. 項(xiàng)目確立 - 項(xiàng)目組角色安排均践，項(xiàng)目周期晤锹、確定技術(shù)棧
4. 開(kāi)發(fā) - 日常開(kāi)發(fā)迭代
5. 驗(yàn)收交付 - 交付項(xiàng)目，收集客戶反饋
6. 項(xiàng)目結(jié)束 - 進(jìn)行項(xiàng)目匯總彤委，總結(jié)開(kāi)發(fā)收獲鞭铆、工作流程改進(jìn)意見(jiàn)
- 會(huì)議安排：
* 項(xiàng)目啟動(dòng)會(huì)議 - 成立開(kāi)發(fā)組、通告項(xiàng)目背景焦影、周期车遂、技術(shù)棧
* 項(xiàng)目階段會(huì)議 - 階段性小結(jié)，了解當(dāng)前實(shí)現(xiàn)進(jìn)度及出現(xiàn)的問(wèn)題斯辰，調(diào)整下階段的目標(biāo)和做法
* 項(xiàng)目總結(jié)會(huì)議 - 進(jìn)行項(xiàng)目匯總
?「圖3-15」公司開(kāi)發(fā)流程規(guī)范
3. 制訂規(guī)范
所謂無(wú)規(guī)矩不成方圓理郑，在一個(gè)完整的開(kāi)發(fā)流程中吩坝，每個(gè)環(huán)境牽扯到不少細(xì)節(jié)歌憨，團(tuán)隊(duì)會(huì)不時(shí)增補(bǔ)新人員解阅，要形成統(tǒng)一的團(tuán)隊(duì)風(fēng)格柄瑰，少不了要制定一些規(guī)范文檔，讓團(tuán)隊(duì)每個(gè)成員可以達(dá)到一致的行事風(fēng)格和輸出剪况，其他對(duì)接同事協(xié)作時(shí)則有規(guī)可循教沾。特別的，一些輸出文檔我都給出了樣例译断，這樣負(fù)責(zé)輸出文檔的同事只需做“填空題”授翻，關(guān)注輸出內(nèi)容本身即可。
以下是我制定的跟項(xiàng)目開(kāi)發(fā)流程相關(guān)的系列文檔例子：
- [公司開(kāi)發(fā)流程規(guī)范]（見(jiàn)「圖 3-15」）
- [公司 PRD文檔規(guī)范]（見(jiàn)「圖 4-1」）
- [公司 Trello使用規(guī)范]（見(jiàn)「圖 4-2」）
- [公司 Trello board template]
- [公司項(xiàng)目周報(bào)規(guī)范文檔]
- [公司階段小結(jié)會(huì)議規(guī)范]
- [公司項(xiàng)目總結(jié)會(huì)議規(guī)范]（見(jiàn)「圖 4-3」）
- [公司項(xiàng)目總結(jié)報(bào)告規(guī)范]
- [公司會(huì)議記錄書(shū)寫(xiě)規(guī)范]
? 「圖4-3」公司項(xiàng)目總結(jié)會(huì)議規(guī)范
小結(jié)
如果有一些成熟完整的項(xiàng)目管理工具孙咪，可以輔助解決一些流程的規(guī)范堪唐、自動(dòng)化，自然會(huì)省事不少翎蹈，但工具很重要也只是輔助淮菠，我接觸了解過(guò)一些開(kāi)發(fā)團(tuán)隊(duì)，使用了一些復(fù)雜荤堪、強(qiáng)大的項(xiàng)目管理工具兜材，然而管理層不去推行、監(jiān)督逞力，執(zhí)行層不落實(shí)執(zhí)行，工具再多再?gòu)?qiáng)大也是沒(méi)有意義糠爬。因此在工具的使用上寇荧，適合自己團(tuán)隊(duì)的才是最好的，不用過(guò)于糾結(jié)在工具選擇上执隧。例如揩抡，我們使用Scrum管理框架，但也不是完全照搬Scrum全家桶镀琉，我們有每日站會(huì)峦嗤、有Sprint 評(píng)審/回顧會(huì)議（我合并為“階段小結(jié)會(huì)議”）、使用Backlog列表屋摔、任務(wù)評(píng)估使用Story Point烁设、使用User Story做驗(yàn)收交付文檔，沒(méi)有Scrum Master（但有項(xiàng)目組長(zhǎng)）钓试，根據(jù)團(tuán)隊(duì)的實(shí)際情況做了簡(jiǎn)化調(diào)整装黑，可以落實(shí)執(zhí)行的方案才是好方案。
總的來(lái)說(shuō)弓熏，即使團(tuán)隊(duì)只有一個(gè)人時(shí)恋谭，做事也應(yīng)該有章法，才能做到事多不亂挽鞠，團(tuán)隊(duì)壯大了再由己及人疚颊，保持團(tuán)隊(duì)一致的調(diào)性狈孔。只有做到以上這些，我們才能從復(fù)雜多變的環(huán)境中做到“有的放矢”材义，從容應(yīng)對(duì)變化均抽。
關(guān)于項(xiàng)目管理有幾本書(shū)推薦閱讀：
- 《最后期限》 —— 被稱為“中國(guó)第一本項(xiàng)目管理小說(shuō)”，以一個(gè)虛構(gòu)小說(shuō)告知項(xiàng)目最重要的4個(gè)要素：找對(duì)人母截，分配正確的任務(wù)到忽，激勵(lì)，團(tuán)隊(duì)建設(shè)清寇。
- 《人月神話》 —— 本書(shū)自第一版以來(lái)喘漏，暢銷20余年不衰，是軟件領(lǐng)域絕無(wú)僅有的必讀經(jīng)典
- 《Scrum權(quán)威指南》 —— 不到20頁(yè)的文檔里簡(jiǎn)明闡述了Scrum是什么华烟、怎么進(jìn)行Scrum翩迈，特別是在2016年版引入了“Scrum價(jià)值觀”的概念，鼓勵(lì)團(tuán)隊(duì)成員相互敬重盔夜，彼此成為更有能力和獨(dú)立的人负饲。
- 《技術(shù)管理之巔 : 如何從零打造高質(zhì)效互聯(lián)網(wǎng)技術(shù)團(tuán)隊(duì)？》 —— 1號(hào)店技術(shù)總監(jiān)出品喂链，推行扁平話返十、OKR目標(biāo)管理、Scrum和Kanban的實(shí)踐椭微、自動(dòng)化測(cè)試等洞坑，從技術(shù)團(tuán)隊(duì)組織架構(gòu)、產(chǎn)品開(kāi)發(fā)流程蝇率、制度規(guī)范建立迟杂、企業(yè)文化、大數(shù)據(jù)與技術(shù)管理創(chuàng)新本慕、移動(dòng)技術(shù)開(kāi)發(fā)排拷、實(shí)用應(yīng)用架構(gòu)設(shè)計(jì)等方面。
物 - 技術(shù)管理
核心思想: 喜新厭舊
- 喜新（Upgrade）：升級(jí)技術(shù)棧
- 厭舊（Migrate）：償還技術(shù)債務(wù)
喜新（Upgrade）：升級(jí)技術(shù)棧
從事信息技術(shù)的都知道摩爾定律锅尘，然而這個(gè)定律不止作用在芯片更新?lián)Q代上监氢，在編程領(lǐng)域也是可適用的，幾乎每年都有一些新編程語(yǔ)言鉴象、技術(shù)框架忙菠、系統(tǒng)架構(gòu)的出現(xiàn)，其中一些有重大突破性的還能引起熱潮纺弊。對(duì)于技術(shù)團(tuán)隊(duì)牛欢，其能掌握的技術(shù)棧就是其戰(zhàn)斗力，而今年掌握的很有可能第二年就變?yōu)檫^(guò)時(shí)淆游，因此一個(gè)有活力的技術(shù)團(tuán)隊(duì)是需要不斷吸收外界新鮮有活力的技術(shù)點(diǎn)傍睹，吸納融合入團(tuán)隊(duì)技術(shù)棧隔盛，轉(zhuǎn)化為團(tuán)隊(duì)的戰(zhàn)斗力。
然而新技術(shù)會(huì)不斷提出拾稳、舊技術(shù)會(huì)迅速過(guò)時(shí)吮炕，我們既不能被新技術(shù)牽著鼻子走又不能過(guò)于落伍。因此在選定技術(shù)棧時(shí)需要具備有前瞻性访得，不能被新熱的技術(shù)吸引分散精力龙亲，也又不能把團(tuán)隊(duì)綁定到一些沒(méi)有生命力的技術(shù)上，這不是簡(jiǎn)單的選擇題悍抑，需要經(jīng)過(guò)探索鳄炉、調(diào)研、實(shí)踐到最后掌握化為生產(chǎn)力搜骡。
厭舊（Migrate）：償還技術(shù)債務(wù)
在項(xiàng)目開(kāi)發(fā)過(guò)程中拂盯，有時(shí)會(huì)根據(jù)當(dāng)時(shí)的人、財(cái)记靡、物及知識(shí)經(jīng)驗(yàn)限制等谈竿，對(duì)技術(shù)框架、架構(gòu)選型做一些當(dāng)時(shí)認(rèn)為“最適合”的設(shè)計(jì)或選擇摸吠，但隨著時(shí)間推移空凸，需求變更、經(jīng)驗(yàn)提升寸痢、新技術(shù)提出等劫恒，回過(guò)頭來(lái)會(huì)發(fā)現(xiàn)當(dāng)時(shí)的“最佳實(shí)踐”已經(jīng)不適合了，有的嚴(yán)重更會(huì)成為推進(jìn)項(xiàng)目的負(fù)擔(dān)轿腺，這種情況我們稱之為“技術(shù)債務(wù)（technical debt）”。
欠債要還丛楚，沒(méi)有反思不會(huì)進(jìn)步族壳，因此要給團(tuán)隊(duì)“還債”的時(shí)間，團(tuán)隊(duì)才有進(jìn)步趣些。但這點(diǎn)在外包開(kāi)發(fā)團(tuán)隊(duì)中其實(shí)是很難徹底實(shí)踐仿荆，因?yàn)樾枰蛻艚忉屖裁词恰爸貥?gòu)”，為什么要花時(shí)間去做一些沒(méi)有明顯輸出的工作坏平；又得在盡量不影響工期的情況下拢操，定下更“正確”的架構(gòu)，這也很考驗(yàn)架構(gòu)能力舶替。
所幸我們團(tuán)隊(duì)是以Ruby/Rails框架為核心技術(shù)棧令境，Rails框架本身就是fullstack且推崇最佳實(shí)踐的框架，每年都有大版本升級(jí)顾瞪，每次升級(jí)都會(huì)引入對(duì)提升開(kāi)發(fā)效率舔庶、安全抛蚁、代碼質(zhì)量的理念和實(shí)踐。因此我們選擇了Rails惕橙，就相當(dāng)于在底層框架中有一支專業(yè)的團(tuán)隊(duì)不斷的在維護(hù)升級(jí)瞧甩，這也是為什么國(guó)內(nèi)外很多創(chuàng)業(yè)團(tuán)隊(duì)喜歡選擇Rails作為開(kāi)發(fā)框架的原因，可以讓產(chǎn)品開(kāi)發(fā)者更多去關(guān)注業(yè)務(wù)實(shí)現(xiàn)弥鹦，而不用太過(guò)操心底層框架的維護(hù)肚逸。
更重要的是，Ruby/Rails不止提供給我們快樂(lè)編程的體驗(yàn)彬坏，還指導(dǎo)了我們做事情的方式方法朦促、看問(wèn)題的角度：The Rails Doctrine - Rails 信條
另外遇到一些本身就是做技術(shù)開(kāi)發(fā)的客戶時(shí)，就會(huì)比較好溝通能得到認(rèn)可苍鲜，但這種優(yōu)質(zhì)客戶是隨機(jī)的思灰、可遇不可求，更多情況是我們開(kāi)發(fā)團(tuán)隊(duì)自己要提高自己的迭代能力混滔，在每次階段會(huì)議洒疚、項(xiàng)目總結(jié)時(shí)進(jìn)行技術(shù)積累，把經(jīng)驗(yàn)知識(shí)應(yīng)用到新的項(xiàng)目上坯屿。
上面說(shuō)了那么多理論油湖，下面說(shuō)下怎么做。
具體做法
作為公司技術(shù)負(fù)責(zé)人领跛，我進(jìn)行技術(shù)管理主要看以下6個(gè)方面：
- 技術(shù)調(diào)研 - 探索新技術(shù)乏德、調(diào)研工作上需要用的服務(wù)等，以保持技術(shù)團(tuán)隊(duì)的先進(jìn)性
- 技術(shù)實(shí)踐 - 有實(shí)踐過(guò)的技術(shù)才敢引入團(tuán)隊(duì)中吠昭，不要做拍腦袋決策
- 技術(shù)培訓(xùn) - 得到認(rèn)可的技術(shù)要推廣和普及給其他成員喊括，提升團(tuán)隊(duì)整體戰(zhàn)斗力
- 技術(shù)復(fù)用 - 提取出可復(fù)用的技術(shù)點(diǎn)，進(jìn)一步提高團(tuán)隊(duì)生產(chǎn)力
- 規(guī)范化 - 技術(shù)團(tuán)隊(duì)?wèi)?yīng)保持一致行事風(fēng)格矢棚，以降低溝通郑什、代碼維護(hù)、工具使用的成本
- 自動(dòng)化 - 解放生產(chǎn)力蒲肋，讓機(jī)器去做重復(fù)工作蘑拯，人力去做突破性工作
具體實(shí)踐總結(jié)
以下是具體實(shí)踐過(guò)的一些調(diào)研報(bào)告（report）、培訓(xùn)講稿（ppt）兜粘、規(guī)范文檔（doc）申窘、知識(shí)庫(kù)（wiki）、內(nèi)部開(kāi)源項(xiàng)目（project）以及公開(kāi)博客文章（blog post）孔轴，涉及的內(nèi)容其實(shí)很多我這里只列出一些比較有代表性的剃法、在團(tuán)隊(duì)內(nèi)實(shí)踐分享過(guò)的內(nèi)容：
- 技術(shù)調(diào)研
- report:[angularjs vs reactjs]
- report:[2016 Rails popular app servers]
- report:[chrome extension開(kāi)發(fā)調(diào)研]
- report:[Crash Reporting Service]
- report:[React-Native Hot Update Services Research Report]
- report:[流行云主機(jī)調(diào)研報(bào)告]
- report:[國(guó)內(nèi)外流行字體CDN調(diào)研]
- report:[QingCloud 調(diào)研]
- doc:[公司 技術(shù)調(diào)研報(bào)告規(guī)范]
- 技術(shù)實(shí)踐
- project:[jpush-ionic-demo]
- project:[pushwoosh-example]
- project:[公司team/react-components]
- 技術(shù)培訓(xùn)
- ppt:[how to do model design]
- ppt:[toolbox-for-optimizing-rails-project]
- ppt:[rails項(xiàng)目中性能調(diào)優(yōu)要注意什么]
- ppt:[rails-debug-tips 2016]
- ppt:[如何寫(xiě)一份壓力測(cè)試報(bào)告] （如 「圖5-1」）
- ppt:[如何用rails開(kāi)發(fā)一個(gè)任務(wù)管理的網(wǎng)站和移動(dòng)app]
- 技術(shù)復(fù)用
- project:[quickstart]
- project:[rails-composer]
- project:[react-boilerplate]
- 規(guī)范化
- doc:[公司 styleguide(公司代碼規(guī)范指南)]（如「圖5-2」）
- wiki:[公司 coding standard]
- wiki:[Code Review Tips] （如「圖3-8」，「圖3-9」）
- wiki:[Rules for committing]
- wiki:[trello + git開(kāi)發(fā)流程規(guī)范]
- wiki:[how to write a rake task]
- doc:[Tech Stack Example]
- doc:[API design example]
- 自動(dòng)化
- 自動(dòng)化測(cè)試
- blog post:[RSpec 使用一周小結(jié)（上篇）]
- blog post:[RSpec 使用一周小結(jié)（下篇）——使用 FactoryGirl 準(zhǔn)備測(cè)試數(shù)據(jù)]
- blog post:[rails集成測(cè)試學(xué)習(xí)總結(jié)]
- blog post:[rspec集成測(cè)試的總結(jié)]
- blog post:[簡(jiǎn)介如何測(cè)試Rails應(yīng)用]
- blog post:[壓力測(cè)試總結(jié)]
- 自動(dòng)化部署
- wiki:[Deploy Project to Staging Using Capistrano on Ubuntu]
- DevOps - 持續(xù)集成
- wiki:[Setup GitLab CI]
- wiki:[Setup GitLab CI Runner]
- ChatOps - Slack+Lita
- 自動(dòng)化測(cè)試
? 「圖5-1」如何寫(xiě)一份壓力測(cè)試報(bào)告
? 「圖5-2」公司代碼規(guī)范指南
重點(diǎn)說(shuō)說(shuō)自動(dòng)化
自動(dòng)化技術(shù)在技術(shù)團(tuán)中對(duì)效率提升很重要路鹰，在前面的“團(tuán)隊(duì)管理 - 開(kāi)發(fā)自動(dòng)化” 這節(jié)已經(jīng)提到了：
我提倡善用工具最大程度做到自動(dòng)化玄窝，這種思維是貫穿整個(gè)開(kāi)發(fā)流程各個(gè)環(huán)節(jié)的牵寺。
如最普通的Terminal（終端shell），推薦使用帶交互的shell（如zsh/Fishshell）來(lái)輔助cli的操作恩脂，鼓勵(lì)善用alias來(lái)簡(jiǎn)化重復(fù)的使用命令帽氓；
代碼開(kāi)發(fā)時(shí)鼓勵(lì)使用支持自動(dòng)完成的IDE、編輯器（如Sublime Text）俩块，鼓勵(lì)善用代碼snippet來(lái)減少重復(fù)編碼的操作黎休；
代碼測(cè)試使用自動(dòng)化測(cè)試（可配合guard或者livereload達(dá)到保存時(shí)自動(dòng)跑相關(guān)測(cè)試）；
代碼提交使用自動(dòng)化命令（gitlab-send-merge-request of git-cmd-helpers）玉凯，一步完成代碼提交并發(fā)Merge request势腮；
項(xiàng)目部署使用自動(dòng)化部署工具（如Chef、Capistrano）漫仆，做到一鍵部署捎拯；
使用CI（GitlabCI）進(jìn)行自動(dòng)化測(cè)試、自動(dòng)構(gòu)建盲厌、構(gòu)建結(jié)果通知署照、自動(dòng)部署、自動(dòng)打包上傳app package吗浩，達(dá)到DevOps的自動(dòng)化建芙；
服務(wù)使用健康監(jiān)控（如Monit，God）懂扼，自動(dòng)監(jiān)測(cè)服務(wù)健康并自動(dòng)重啟服務(wù)禁荸；
一句話就是盡量把重復(fù)的工作丟給機(jī)器去做，人力應(yīng)該專注在機(jī)器解決不了的地方阀湿。
如「圖5-3」就是我們團(tuán)隊(duì)日常開(kāi)發(fā)中赶熟，從本地終端使用一行代碼發(fā)起MR（MergeRequest），code rewivew通過(guò)合并MR陷嘴，觸發(fā)CI自動(dòng)進(jìn)行構(gòu)建钧大、測(cè)試、部署到通知Slack的過(guò)程
? 「圖5-3」auto CI/CD
另外我們開(kāi)發(fā)的Chrome Extension項(xiàng)目罩旋，也做到了的DevOps貫通、自動(dòng)化發(fā)布眶诈，流程如下：
- 開(kāi)發(fā)在本地執(zhí)行執(zhí)行構(gòu)建命令：
gulp release --bumpversion涨醋，自動(dòng)更新 manifest.json中的版本號(hào)、自動(dòng)做git commit逝撬、同時(shí)自動(dòng)以版本號(hào)創(chuàng)建git tag - 往Gitlab發(fā)起MR浴骂，合并到develop分支后，CI會(huì)自動(dòng)加上
--env staging為參數(shù)宪潮，應(yīng)用上針對(duì)staging的配置，進(jìn)行構(gòu)建生成zip文件 - 把develop往master合并后，CI會(huì)自動(dòng)加上
--env production為參數(shù)扳碍，應(yīng)用上針對(duì)production的配置遏暴，進(jìn)行構(gòu)建生成zip文件 - 在CI上構(gòu)建生成zip文件時(shí)，會(huì)自動(dòng)加上一些stamp（包括extension version凉馆，git revision， env，datestamp）彬伦，如“Trellohub-0.2.2[staging]@2016-12-06^0b89f89”
- zip文件生成完畢后，CI自動(dòng)把zip文件上傳到Trello board對(duì)應(yīng)環(huán)境的card中伊诵；發(fā)布為staging的单绑，放入packages-for-staging card以便可以給QE進(jìn)行QA；發(fā)布為production的曹宴，放入packages-for-production card以便給PM上架發(fā)布到Chrome Web Store
整個(gè)流程中只有第1搂橙、2步是需要人工參與（將來(lái)可優(yōu)化成一步），其他步驟已全部通過(guò)CI實(shí)現(xiàn)自動(dòng)化笛坦。
對(duì)于ios/android app構(gòu)建發(fā)布区转，我也準(zhǔn)備使用Appium做集成測(cè)試，使用Fastlane做自動(dòng)化構(gòu)建弯屈，配合Gitlab CI打通DevOps自動(dòng)化蜗帜。
自動(dòng)化有助減少人工參與，提高效率的同時(shí)減少誤操作可能资厉，技術(shù)團(tuán)隊(duì)?wèi)?yīng)大力推行厅缺。
小結(jié)
今年最大的變化莫過(guò)于前端圈的火熱和容器架構(gòu)的盛行，層出不窮的概念宴偿、輔助的工具湘捎，新技術(shù)還沒(méi)來(lái)得及掌握轉(zhuǎn)眼已經(jīng)變?yōu)樘蕴@也意味著對(duì)技術(shù)的細(xì)分越來(lái)越專業(yè)窄刘，同時(shí)也意味IT項(xiàng)目的工程化越來(lái)越專業(yè)窥妇。這是挑戰(zhàn)也是機(jī)遇，項(xiàng)目越復(fù)雜娩践、質(zhì)量要求越高活翩，對(duì)個(gè)人的要求也就越高，也意味著團(tuán)隊(duì)作戰(zhàn)的作用越重要翻伺，這也正是PaaS/SaaS這類以打包服務(wù)為賣點(diǎn)的平臺(tái)也更有機(jī)會(huì)材泄。
文 - 文化建設(shè)
核心思想: “八面”玲瓏
團(tuán)隊(duì)文化是指團(tuán)隊(duì)成員在相互合作的過(guò)程中，為實(shí)現(xiàn)各自的人生價(jià)值吨岭，并為完成團(tuán)隊(duì)共同目標(biāo)而形成的一些行事態(tài)度拉宗、思考方式和行為準(zhǔn)則。在技術(shù)管理方面，我主要是負(fù)責(zé)塑造技術(shù)文化氛圍旦事，并通過(guò)這些思想魁巩、準(zhǔn)則來(lái)影響及推行“團(tuán)隊(duì)管理”、“項(xiàng)目管理”及“技術(shù)管理”等方面姐浮。
我眼中的工程師文化
所謂“八面”玲瓏谷遂，不是指要把人培養(yǎng)成圓滑的人，而是我認(rèn)為在一個(gè)以工程師為伍的技術(shù)團(tuán)隊(duì)中单料，應(yīng)該建立以下八個(gè)方面的文化：
- 學(xué)習(xí)文化
- 創(chuàng)新文化
- 工程文化
- 工具文化
- 自動(dòng)文化
- 腳本文化
- 開(kāi)源文化
- 流程文化
學(xué)習(xí)文化
- 技術(shù)調(diào)研
- 技術(shù)總結(jié)
前面“技術(shù)管理”中說(shuō)過(guò)要“喜新厭舊”埋凯，不斷擴(kuò)寬知識(shí)邊界、填平知識(shí)短板扫尖，團(tuán)隊(duì)技術(shù)水平才能不斷提高白对。對(duì)新出現(xiàn)、不熟悉的技術(shù)點(diǎn)要進(jìn)行調(diào)研换怖，出調(diào)研報(bào)告甩恼；對(duì)已經(jīng)熟悉用過(guò)的，要做技術(shù)總結(jié)沉颂，使得經(jīng)驗(yàn)可以復(fù)用条摸。如何鼓勵(lì)內(nèi)部分享，外部交流铸屉、互通有無(wú)钉蒲，在前面“團(tuán)隊(duì)管理”如何“培養(yǎng)”已經(jīng)具體說(shuō)過(guò)就不再展開(kāi)。
創(chuàng)新文化
公司無(wú)創(chuàng)新則無(wú)獨(dú)特的競(jìng)爭(zhēng)力彻坛，這點(diǎn)大家都懂不多用解釋顷啼。但我認(rèn)為“創(chuàng)新”不止是說(shuō)創(chuàng)造新的工具、組件昌屉，勇于使用新技術(shù)钙蒙、引進(jìn)新框架、打破陳規(guī)做法也是一種創(chuàng)新间驮，能引起“有益的變化”就是創(chuàng)新躬厌，應(yīng)該鼓勵(lì)。
例如我看到我們有一個(gè)項(xiàng)目后端是ruby竞帽，前端是coffee語(yǔ)言編寫(xiě)扛施，都有大量的類定義，新加入的開(kāi)發(fā)人員上手會(huì)比較困難屹篓，為此我編寫(xiě)了一個(gè)文檔構(gòu)建腳本疙渣，能自動(dòng)對(duì)2種語(yǔ)言的代碼分別生成統(tǒng)一的YARD風(fēng)格的文檔，再合并在一份文檔中抱虐，以方便開(kāi)發(fā)人員查看熟悉程序結(jié)構(gòu)，如「圖6-1」
? 「圖6-1」build app doc
這種有利于提高工作效率的改進(jìn)在我看來(lái)就算是一種微創(chuàng)新饥脑。
工程文化
軟件工程開(kāi)發(fā)恳邀，從來(lái)不是寫(xiě)個(gè)“Hello World”這么簡(jiǎn)單的事情懦冰。一個(gè)完整的軟件工程，需要考慮程序語(yǔ)言谣沸、數(shù)據(jù)庫(kù)刷钢、開(kāi)發(fā)工具、系統(tǒng)平臺(tái)乳附、依賴包管理内地、代碼目錄結(jié)構(gòu)、設(shè)計(jì)模式赋除、日志記錄等方面阱缓，開(kāi)發(fā)項(xiàng)目交付時(shí)，除了代碼举农，還要功能說(shuō)明文檔荆针、代碼說(shuō)明文檔、單元測(cè)試颁糟、壓測(cè)報(bào)告航背、部署說(shuō)明文檔。所以在我看來(lái)棱貌，一個(gè)開(kāi)發(fā)框架的工程化成熟度玖媚，就是看以上這些方面的覆蓋程度。
前面“技術(shù)管理”中說(shuō)過(guò)了我們的Web 開(kāi)發(fā)框架是用Rails婚脱，而Rails是fullstack的今魔、從一開(kāi)始就走工程化的風(fēng)格，從初始化一個(gè)rails項(xiàng)目的第一步的命令： rails new MyProject --database=postgresql --javascript=jquery 看出它會(huì)期待你預(yù)先考慮好后端使用什么數(shù)據(jù)庫(kù)起惕，前端使用什么js庫(kù)涡贱，當(dāng)然這些參數(shù)都是可選，不選擇則使用默認(rèn)配置惹想，Rails遵從CoC（約定優(yōu)于配置） 原則问词。
再看一下rails 5自動(dòng)生成的項(xiàng)目目錄結(jié)構(gòu)：
├── Gemfile # gem依賴管理(Gem是Ruby領(lǐng)域的apt)
├── README.md # 說(shuō)明文檔
├── Rakefile # 構(gòu)建任務(wù)管理入口（Rake是Ruby領(lǐng)域的Make）
├── app/ # 應(yīng)用代碼
│ ├── assets/ # 靜態(tài)資源文件（js,css,img,font）
│ ├── channels/ # 基于WebSocket 的Pub/Sub實(shí)現(xiàn)
│ ├── controllers/ # 控制器，負(fù)責(zé)處理請(qǐng)求嘀粱，調(diào)取Model激挪，選擇View渲染
│ ├── helpers/ # view 的輔助模塊
│ ├── jobs/ # 隊(duì)列任務(wù)
│ ├── mailers/ # 郵件內(nèi)容
│ ├── models/ # 業(yè)務(wù)模型
│ └── views/ # 視圖（HTML模板）
├── bin/ # 一些項(xiàng)目CLI命令、自定義腳本
│ ├── bundle*
│ ├── rails* # 主要CLI锋叨，提供啟動(dòng)app server垄分、控制臺(tái)、生成器娃磺、運(yùn)行測(cè)試
│ ├── rake*
│ ├── setup* # 項(xiàng)目初始化腳本薄湿，一步完成安裝依賴、數(shù)據(jù)庫(kù)初始化、啟動(dòng)rails server
│ ├── spring*
│ └── update* # 開(kāi)發(fā)過(guò)程更新腳本豺瘤，一步完成安裝依賴吆倦、數(shù)據(jù)庫(kù)遷移、清理臨時(shí)文件坐求、重啟rails server
├── config/ # 各種配置蚕泽，如啟動(dòng)方式、數(shù)據(jù)庫(kù)配置桥嗤、路由配置须妻、環(huán)境配置、密鑰配置泛领、i18n配置
├── config.ru # Rack架構(gòu)服務(wù)調(diào)用接口
├── db/ # 數(shù)據(jù)庫(kù)遷移改動(dòng)荒吏、種子數(shù)據(jù)
├── lib/ # 獨(dú)立的類、模塊师逸、app相關(guān)的rake任務(wù)
├── log/ # 各種日志文件
├── public/ # 不用預(yù)處理司倚、可公開(kāi)訪問(wèn)資源目錄，如404.html,robots.txt
│ ├── 404.html
│ ├── 422.html
│ ├── 500.html
│ ├── favicon.ico
│ └── robots.txt
├── test/ # 單元測(cè)試篓像、集成測(cè)試
│ ├── controllers/
│ ├── fixtures/
│ ├── helpers/
│ ├── integration/
│ ├── mailers/
│ ├── models/
│ └── test_helper.rb
├── tmp/ # 緩存动知、臨時(shí)文件
│ └── cache/
└── vendor/ # 第三庫(kù)、資源
└── doc/ # 文檔存放目錄员辩，從rails 4不再默認(rèn)生成盒粮，但可以通過(guò)`rake doc:app` 來(lái)檢查并生成app代碼文檔
從所生成目錄就能看出在 rails 項(xiàng)目里會(huì)涉及到依賴包管理、構(gòu)建任務(wù)奠滑、靜態(tài)資源處理丹皱、消息訂閱處理、消息隊(duì)列處理宋税、MVC架構(gòu)摊崭、郵件處理、提供CLI杰赛、i18n處理呢簸、多環(huán)境適配、Rack架構(gòu)乏屯、數(shù)據(jù)庫(kù)連接根时、數(shù)據(jù)庫(kù)查詢（ORM）、數(shù)據(jù)結(jié)構(gòu)遷移管理辰晕、初始化數(shù)據(jù)管理蛤迎、日志處理、單元測(cè)試含友、集成測(cè)試這些概念替裆，幾乎涵蓋了一個(gè)Web項(xiàng)目需要用到的方方面面校辩，可以大方說(shuō)句使用rails的開(kāi)發(fā)者相對(duì)是比較“幸福”的辆童，因?yàn)橛泻芏嗉?xì)枝末節(jié)的地方都已經(jīng)有被考慮到召川，而且還在不斷的補(bǔ)充引入新的feature。
我們使用的技術(shù)框架不止rails胸遇，在前后端分離的架構(gòu)中，前端使用過(guò)Backbone/Angularjs/React & Redux汉形，在移動(dòng)開(kāi)發(fā)中使用Ionic/React Native纸镊，但這些技術(shù)框架中有些沒(méi)有很統(tǒng)一、符合要求的工程化規(guī)范概疆，因此我安排整理了一些目錄規(guī)范逗威，例如：
- angularjs 項(xiàng)目目錄結(jié)構(gòu)規(guī)范文檔
- react-redux 項(xiàng)目目錄結(jié)構(gòu)規(guī)范文檔
- React Native項(xiàng)目結(jié)構(gòu)規(guī)范
以便開(kāi)發(fā)項(xiàng)目時(shí)更工程化、結(jié)構(gòu)化岔冀，可以在新項(xiàng)目中可以復(fù)用架構(gòu)凯旭、組件可以通用
工具文化
“工欲善其事，必先利其器”這句話我非常贊同使套。如果說(shuō)任務(wù)開(kāi)發(fā)是戰(zhàn)場(chǎng)罐呼，那么開(kāi)發(fā)者使用的工具就是他們的武器，把“武器”打磨得是否順手就會(huì)成為戰(zhàn)場(chǎng)生存的關(guān)鍵之一侦高。我經(jīng)常在團(tuán)隊(duì)中推薦并鼓勵(lì)每個(gè)人都分享嫉柴、推薦自己使用過(guò)、認(rèn)為高效的工具奉呛，例如：
- Shell： zsh/fish - 交互式shell计螺，提高CLI操作效率
- 代碼提交： GitX - 我鼓勵(lì)在代碼提交時(shí)使用git的GUI工具如GitX而不是命令行，因?yàn)镚UI工具可以進(jìn)行代碼整理瞧壮，有利合理的代碼提交記錄
- 終端操作： TotalTerminal/iTerm - 隨時(shí)隨地可以進(jìn)行敲命令
- 文檔編輯：MacDown - 所寫(xiě)己所得登馒、兼容github GFM格式
- API查看：Dash - 快速離線查看各種技術(shù)API文檔，開(kāi)發(fā)者必備
- 窗口操作：Spectacle - 多屏幕操作利器
- 應(yīng)用訪問(wèn)：Alfred - 把Mac變成Google Instant Search 般的體驗(yàn)
- 圖片編輯：Skitch - 一圖勝千言咆槽，快速給截圖加上注釋
- 數(shù)據(jù)庫(kù)操作：Navicat Lite - 支持鏈接mysql/postgres/oracle/sqlite/sql server陈轿，開(kāi)發(fā)者必備
- 代碼編輯器：Sublime Text/Vim/Emacs/Atom - 編輯器的選擇對(duì)程序員而言是場(chǎng)“圣戰(zhàn)”，為了找出“哪個(gè)才是最好的代碼編輯器”罗晕，我特意在團(tuán)隊(duì)內(nèi)發(fā)起過(guò)專題分享活動(dòng)：“編輯器到底哪家好”——技術(shù)分享 @ 2015-01-10
自動(dòng)文化
優(yōu)秀程序員三大特質(zhì)之一是“懶”济欢，能用程序、腳本解決的小渊，就不用手工法褥，更有“以自動(dòng)化為榮，手工為恥”的說(shuō)法酬屉，常會(huì)出現(xiàn)花費(fèi)幾個(gè)小時(shí)的腳本去解決一次只要十幾分鐘簡(jiǎn)單但會(huì)重復(fù)的問(wèn)題半等，作為管理者遇到這種情況不應(yīng)該一昧的打壓揍愁，因?yàn)檫@種思想就是以自動(dòng)化思維去解決重復(fù)，前面“技術(shù)管理”章節(jié)中就提到過(guò)了自動(dòng)化的重要性杀饵，從本地開(kāi)發(fā)莽囤、到代碼提交、測(cè)試切距、集成朽缎、部署、發(fā)布谜悟、監(jiān)控等各個(gè)環(huán)節(jié)中都有加入自動(dòng)化的操作话肖，能執(zhí)行自動(dòng)化的都盡量推行自動(dòng)化，提高效率之余減少人為誤操作葡幸。
以現(xiàn)在的觀點(diǎn)來(lái)看最筒，一個(gè)技術(shù)團(tuán)隊(duì)中有沒(méi)推行自動(dòng)化技術(shù)，可以認(rèn)為這個(gè)團(tuán)隊(duì)是否達(dá)到“高效”的檢驗(yàn)特征之一了蔚叨。
腳本文化
無(wú)論是作為Java床蜘，C++，.Net 這類靜態(tài)語(yǔ)言的程序員蔑水，還是使用Ruby邢锯，PHP，Python搀别，JavaScript 這類腳本語(yǔ)言的程序員弹囚，在開(kāi)發(fā)過(guò)程中都會(huì)接觸到Shell腳本（Shell Script），因此掌握一些基本的Shell腳本操作领曼，可以有效提高工作效率鸥鹉。
除了可以使用上面提到的“工具文化”中推薦的一些交互式shell來(lái)提高CLI操作效率外，還應(yīng)掌握一些簡(jiǎn)單的Shell語(yǔ)法，用以編寫(xiě)輔助開(kāi)發(fā)的腳本。
最簡(jiǎn)單的做法是可以增加一些alias作為一些常用命令的組合絮宁，使用有語(yǔ)義的命名，配合可交互Shell的提示灸异，很簡(jiǎn)單、很低廉的操作成本羔飞，就可以在很大程度上減少重復(fù)敲打鍵盤(pán)肺樟、錯(cuò)誤輸入。例如我給不熟git的新人建了個(gè) git-cmd-helpers逻淌，就是增加一些常用git 操作的封裝么伯，用以提高git的使用效率。
開(kāi)源文化
作為技術(shù)開(kāi)發(fā)者卡儒，我們是技術(shù)開(kāi)源社區(qū)的收益者（可見(jiàn)我發(fā)表的 blog post:公司用到的開(kāi)源產(chǎn)品）田柔，因此也鼓勵(lì)開(kāi)源精神俐巴。我會(huì)經(jīng)常在團(tuán)隊(duì)中鼓勵(lì)在開(kāi)發(fā)中使用一些開(kāi)源組件遇到問(wèn)題修復(fù)時(shí)，給源作者發(fā)PR硬爆，我們?cè)趃ithub上也有發(fā)布一些開(kāi)源作品欣舵。
流程文化
制訂流程，是團(tuán)隊(duì)多人協(xié)作的基礎(chǔ)缀磕，是“規(guī)范化”的細(xì)節(jié)缘圈，是“自動(dòng)化”的前提。
在前面的“團(tuán)隊(duì)管理”提到工作要流程化袜蚕，我制定了涵蓋從招聘到入職准验、升退評(píng)價(jià)、招聘和入職流程廷没；“項(xiàng)目管理”中我制定了[公司開(kāi)發(fā)流程規(guī)范]、[公司 Trello使用規(guī)范]垂寥，涵蓋從需求對(duì)接到項(xiàng)目結(jié)束交付颠黎；“技術(shù)管理”中提到[trello + git開(kāi)發(fā)流程規(guī)范]，涵蓋了代碼提交流程滞项、代碼審查流程狭归、部署流程步驟細(xì)節(jié)。
制訂制度文判、規(guī)范的流程
同樣的过椎，在企業(yè)中制定一種新的制度、規(guī)范時(shí)戏仓，也應(yīng)該遵從類似以下流程：
- 調(diào)研 - 先看人家怎么做
- 制訂 - 自己要怎么做
- 發(fā)布 - 跟團(tuán)隊(duì)說(shuō)明是什么疚宇、怎么做
- 執(zhí)行 - 怎么說(shuō)就要怎么做，最忌光說(shuō)不練
- 監(jiān)督 - 了解執(zhí)行效果赏殃，收集反饋
- 修正 - 根據(jù)反饋意見(jiàn)調(diào)整細(xì)節(jié)敷待，收集到足夠多的改動(dòng)后發(fā)布新版
- 發(fā)布新版 -> 執(zhí)行 -> 監(jiān)督 -> 修正 ->（重復(fù)）
思路：跟寫(xiě)單元測(cè)試一樣
- 編寫(xiě)測(cè)試代碼
- 運(yùn)行測(cè)試
- 觀察結(jié)果
- 修正實(shí)現(xiàn)代碼 -> 運(yùn)行測(cè)試 -> 觀察結(jié)果 -> (重復(fù))
推衍：企業(yè)內(nèi)所有的重大決策都應(yīng)該如此推行
所以一個(gè)成熟的技術(shù)團(tuán)隊(duì)中，為了明確職責(zé)仁热、分工清晰榜揖、減少?zèng)_突，是很有必要制定一些常用流程抗蠢，并將之作為的規(guī)范文檔沉淀下來(lái)反復(fù)推行實(shí)踐举哟，以下我制定過(guò)且形成規(guī)范文檔的流程：
- [公司招聘流程] （見(jiàn)「圖3-5」）
- [公司新員工入職流程] （「圖3-6」）
- [公司開(kāi)發(fā)流程規(guī)范]（見(jiàn)「圖3-15」）
- wiki:[公司任務(wù)開(kāi)發(fā)流程]
- wiki:[Trello + git開(kāi)發(fā)流程規(guī)范]
小結(jié)
以上這八種便是我認(rèn)為是對(duì)技術(shù)團(tuán)隊(duì)有益的文化總結(jié)。
企業(yè)文化建設(shè)能否建設(shè)好同樣是門(mén)不簡(jiǎn)單的技術(shù)活迅矛，但更大程度上是受企業(yè)創(chuàng)始人妨猩、管理層影響，因此不同技術(shù)團(tuán)隊(duì)中即便是使用相同的技術(shù)棧秽褒，但由于創(chuàng)始人不同册赛，所施行的管理理念钠导、思考方式不同，執(zhí)行結(jié)果也就不一樣森瘪。因此我不認(rèn)為有“最好”的團(tuán)隊(duì)文化牡属，只有“最適合”的團(tuán)隊(duì)文化，因地制宜扼睬、量身打造的才是適合自己的逮栅。
總結(jié)
在最后做一下總結(jié)，我認(rèn)為想要打造 高效 高質(zhì)量 的技術(shù)團(tuán)隊(duì)窗宇，需要解決以下問(wèn)題：
- 高效人員：
- 持續(xù)深入
- 專人專職
- 技術(shù)復(fù)用：
- 經(jīng)驗(yàn)復(fù)用
- 代碼復(fù)用
- 文檔復(fù)用
- 團(tuán)隊(duì)復(fù)用
- 產(chǎn)品復(fù)用
- 自動(dòng)化：
- 開(kāi)發(fā)自動(dòng)化
- 測(cè)試自動(dòng)化
- 部署自動(dòng)化
- 運(yùn)維自動(dòng)化
- 規(guī)范化：
- 流程規(guī)范化：開(kāi)發(fā)流程措伐，會(huì)議流程，交付流程
- 代碼規(guī)范化：代碼編寫(xiě)军俊，代碼提交侥加，代碼審查
- 文檔規(guī)劃化：需求文檔，調(diào)研文檔粪躬，會(huì)議文檔
- 目標(biāo)清晰：
- 需求清晰担败，協(xié)作清晰，日程清晰镰官，任務(wù)清晰提前，流程清晰 = 為了什么，跟什么人泳唠，在什么時(shí)候狈网，做什么事，要怎么做
