閱讀Tips: 本文是我根據(jù)這么多年來的實際開發(fā)、技術管理經驗的一些總結，完整閱讀需要30分鐘，已經整理成簡書專題《當我在做技術管理時我在做什么》，可分章節(jié)挑選感興趣的部分閱讀。
序言
個人介紹：
聯(lián)合創(chuàng)始人 & CTO，目前管理20多人的技術團隊，從事Web開發(fā)12年，使用過Perl、ASP、PHP，從2007年開始使用Ruby開發(fā)，主持開發(fā)過音樂上傳下載網站、網頁游戲API、癥狀疾病檢索網站、CRM系統(tǒng)、數(shù)據(jù)可視化、在線GTD項目、任務管理系統(tǒng)、在線教育、在線呼叫中心、在線商城、商品采集和點評、地方門戶類網站、定制微信公眾平臺、iOS多媒體終端、國外多種社交網站API數(shù)據(jù)分析等，目前專注敏捷團隊管理。
企業(yè)背景
公司創(chuàng)立于2013至今，主要從事Web、移動應用、微信公眾號的定制、外包開發(fā)，主要使用ruby/rails/git/linux等編程技術，推行敏捷風格的開發(fā)管理，使用自動化部署、各種共有云服務，使用Redmine、Trello、Slack等流行的項目管理、溝通工具，客戶分布中國、美國、德國、澳洲等地，涉及領域廣泛（見「圖2-2」）
?「圖2-2」2016年項目領域統(tǒng)計
工作范疇：
“大內總管” - 公司的內部管理者，負責技術管理、團隊管理、項目管理
管理的目標：
我所做的一切都是為了提高開發(fā)效率，讓項目成功交付
目標意義：
- 提高開發(fā)效率 -> 我們開心！
- 項目成功交付 -> 客戶開心 -> 爽快結款 -> 大家開心！
管理什么：
眾所周知，一個企業(yè)中CEO主要管四方面：人事物財
那么對于CTO呢，我認為也是管四個方面：人事物文
分別對應為：
- 人 - 團隊管理
- 事 - 項目管理
- 物 - 技術管理
- 文 - 文化建設
下面分別講一下四個方面的管理。
人 - 團隊管理
核心思想: 以人為本
團隊是由一群追求一個或多個共同目標的人組成，通過一些規(guī)則約束在一起工作。人多不一定是力量大，也可能是人多手腳亂。要讓一個團隊高效協(xié)作，核心原則必然是以人為本，讓每個成員在自己的位置得到最有效發(fā)揮，讓個體與整體相互觸進成長。
我把團隊管理分為6個方面：
- 定組織架構 - 要招什么人
- 招聘 - 怎么招人
- 培養(yǎng) - 招到的人怎么培養(yǎng)
- 考核 - 要不要繼續(xù)培養(yǎng)
- 效率管理 - 要培養(yǎng)成高效人材
- 情緒管理 - 是人就有情緒
1. 定組織架構
所謂“成大事須合乎天時地利人和”，其中天時不如地利，地利不如人和。所有事情歸根都是由人來推動執(zhí)行，因此一個團隊首先要有適合的人。
那是不是馬上要講講怎么招人嗎？不急，首先看公司的業(yè)務方向，根據(jù)公司發(fā)展的需要來選則所需要的人材組建團隊。
所以成熟團隊的管理方案中第一件事應該先定好組織架構，定下企業(yè)需要的崗位、職責、需要的人數(shù)。
這點其實跟做產品開發(fā)流程很像，得先有原型、設計圖，然后才做實際的開發(fā)實現(xiàn)，實施成本才可控。
組織架構的科普：
企業(yè)組織結構是進行企業(yè)流程運轉、部門設置及職能規(guī)劃等最基本的結構依據(jù)，常見組織結構形式包括中央集權、分權、直線以及矩陣式等。
企業(yè)的組織架構就是一種決策權的劃分體系以及各部門的分工協(xié)作體系。組織架構需要根據(jù)企業(yè)總目標，把企業(yè)管理要素配置在一定的方位上，確定其活動條件，規(guī)定其活動范圍，形成相對穩(wěn)定的科學的管理體系。
組織架構的作用簡單來說就是公司的骨架，自上而下明確各個崗位的職責、管理范圍、責任鏈，因此不宜經常大動大改。
公司成立了3年多，目前做了2次調整，「圖3-1」是公司 2016年底定下的組織架構中CTO負責管理的開發(fā)部分
?「圖3-1」組織架構
2. 招聘 - 招人其實也是個技術活
有了組織架構（設計圖紙）后可以招人了，然而招人這件事本身就是個技術活！
從哪里招？同行那么多要發(fā)什么樣的招聘文案才吸引人？面試時要問什么？怎么知道對方是不是有料？什么樣的人適合留下來？要給多少錢？
一大波的問題迎面而來！
有效過的招聘渠道大概有3種：內部推薦，專業(yè)招聘網站，社區(qū)論壇。
從實踐結果來看，其中內推的結果最為靠譜。為了鼓勵更多的內推，我在公司內提出推行了內推獎勵機制：通過內部推薦應聘成功的，在試用期轉正后，推薦人可獲取一定現(xiàn)金獎勵，獎勵力度跟被推薦人被評定的職位等級掛鉤，也就意味著引薦越有實力的人，引薦人則有高的回報，企業(yè)也能收獲更有實力的人材，對企業(yè)而言是小投入高回報的策略。
另外為了讓招聘文案“新鮮刺激有內涵”，在眾多的招聘帖子中能吸引到小伙伴的眼球，我曾煞費苦心收集了大堆團隊的日常照片，從中挑選一些有代表性，給每一張配上適合的解說詞，合并成了一張457x8419 像素的巨長圖（「圖3-2」），得到一波好評的同時也給公司了一次PR。
「圖3-2」 公司的日常（@2015.4）
不同的技術崗位需要掌握的技術技能自然不同，因此刷選時也需要面試官對面試崗位技能都有所掌握，然而每一門技術的技能樹各不相同，如「圖3-3」。
?「圖3-3」前端工程師技能樹
技術崗位都需要定一些面試題目來提高候選人篩選效率和標準化結果評估，因此我根據(jù)需要的引進的崗位制定一些面試題文檔：
- [公司前端面試題v2015-08-27]
- ruby開發(fā)面試@2016-10-09.md
- react-native開發(fā) 面試.md
- 開發(fā)運維面試.md
內容涉及對應崗位的編程知識、項目開發(fā)的流程及協(xié)作方式、解決問題的方法等，考察候選人當前的編程水平、項目經驗、學習能力和工作態(tài)度，用以判斷加入公司后的培養(yǎng)成本和周期。當然大家都知道，只是通過交談是無法百分比準確的判定一個候選人是否完全符合預期，只有真正在一起工作時才能了解彼此。
目前所有進入公司的技術人員都是由我親自面試過，因此引進的人員在技能方面是比較有把握的。
面試的過程其實很占用人的時間、精力的，對于每位上門的應聘者，我都會耐心的引導，避免由于面試的緊張導致應聘者沒有發(fā)揮好從而給出錯誤的結論。因此即使沒有面試通過的，也得到比較正向的反饋，見「圖3-4」
? [圖3-4] 面試反饋
最后面試的人多起來了，我們需要安排一面、二面流程提高面試效率，這時也需要制定一些流程規(guī)范來標準化從而提高招聘效率，因此我也將這個流程指定成規(guī)范文檔，見「圖3-5」：
? 「圖3-5」公司招聘流程
除了專業(yè)技能，我認為優(yōu)秀員工的重要的品質有2點：
- 責任心
- 主動性
但這些是從短短一個小時的面試過程中是看不出來的，因此還要涉及到對新入職員工的考察，后面一節(jié)會講到我是怎么做。
面試通過后、談妥了offer后，就是入職安排。
入職過程不是到公司報個道就完事了，有相應的入職的流程、需要不同的人協(xié)作，如要安排Mentor、分配帳號、滿試用期后考核等等，因此我提出并制定了一個[公司新員工入職流程]，如「圖3-6」
? 「圖3-6」[公司新員工入職流程]
企業(yè)都想找到適合的員工，所謂適合，其實就是有能力、企業(yè)能給得起錢。企業(yè)主不應總是對應聘者挑剔，懂得要馬跑就要喂馬吃飽的道理，這點是每個企業(yè)主自身要做好的準備，雙方各取所需、共同成長，企業(yè)賺錢、員工漲薪才是最大的共贏。
3. 培養(yǎng)
經過了面試雙方談妥，人員入職到崗了，不能丟在一邊“放養(yǎng)”。要想讓新人盡快通過磨合，熟悉開發(fā)流程，掌握專業(yè)技能，盡早能獨立完成開發(fā)任務，我采用以下幾種方案：
- 引入Mentor制度
- [公司 新人提點注意事項]
- code review：[Code Review Tips]
- pair programming
- 內部培訓、分享
- 官方blog
- 外部技術交流會
引入Mentor制度
Mentor制，是指定了一名同類崗位、高一級別的同事作為“導師”，來帶領入職的同事熟悉開發(fā)環(huán)境、開發(fā)流程、代碼規(guī)范等，讓新人盡快通過磨合，熟悉團隊、有歸宿感。我不認可那種一來就直接指派個任務卡片，丟下一句“自己看代碼學習，這周內搞掂”的放養(yǎng)式管理風格。將心比心，人到一個陌生的環(huán)境，都是期待能得到一些簡單的指引，有時只有簡單幾句話，也會有種安全感。
[公司 新人提點注意事項]
這是我整理給Mentor的指導文檔，一般的開發(fā)人員平時都只是做日常開發(fā)，一開始也不懂得如何指導新人，為了解決這種窘況，我整理了這么一份文檔（「圖3-7」），內容實際就是公司知識庫WIKI中的一些內容的鏈接索引，另外特別強調了注意不要分享整個文檔給新人，要鍛煉他們自己的學習能力。
? 「圖3-7」公司 新人提點注意事項
code review：[Code Review Tips]
我們在日常開發(fā)中鼓勵并推行code review（代碼審查）。
在每個項目立項進入開發(fā)階段時，我會根據(jù)開發(fā)組成員的級別設定審查鏈，按照 “中級審初級，高級審中級，高級互審”，沒有合適的人時我來審查，開發(fā)任務完成后，任務開發(fā)者需要發(fā)Pull/Merge Request給指定好的審查者進行審查和合并，確保每次代碼合并前都有2個人能看到過，一般只有在做演示出現(xiàn)exception，需要緊急合并做部署時才會跳過code reivew流程。
推行code reivew需要有2個人以上的協(xié)作，自然是有代價的，那有什么好處？
見「圖3-8」中我在公司WIKI [code review tips]中給的回答：
? 「圖3-8」code review tips
相當于另一種pair programing，大家的編程水平都能提高（無論是提出問題的，還是被指出問題的）
讓一個新人融入團隊沒有比在一起討論代碼更快的方式了，特別是對于新人而言，對代碼規(guī)范不熟悉，通過code reivew能有效減少低質量代碼的check in，對個人、對團隊、對項目都是很有益的一項安排。
至于要怎么做好code reivew這件事，需要另開新篇來闡述，「圖3-8」中有review代碼的要點摘要，在這里就不展開了。
「圖3-9」是我日常進行code reivew 發(fā)現(xiàn)問題的一些總結，在團隊內也做過一次專題的培訓
? 「圖3-9」 code review examples
?「圖3-10」code reuse - DRY your codes
特別提一下，設定固定的審查鏈的好處是減少審查者的負擔，每個人只需負責1~2個的代碼審查；階級式的安排，可以讓高級的不用反復的去提點低級人的一些低級錯誤，反復指出一些低級問題對高級人員是負擔也是干擾，容易累積高級人員缺乏成就感的情緒（程序員的一個特質是喜歡有挑戰(zhàn)性的任務）。
pair programming
結對編程的好處不用多說，我鼓勵結對編程，但不會強制安排，不會要求像教科書般要求在某個時間規(guī)規(guī)矩矩的一個看一個寫，實際上一般的情景是某個同事有問題時，需要找我或作指導的其他同事，拿上電腦大家坐在一起討論、直接敲代碼（「圖3-11」）：
內部培訓、分享
團隊的強大不能依賴個體，新知識只有一個人掌握時，不等于團隊掌握了，分享出來團隊技術才能成長。
在每周五下午，我會不定期的安排一些內部的培訓，技術的、設計的、產品的，不限制領域，既是對個人的一次鍛煉，又同時是給大家一個休息、坐在一起討論的時間（「圖3-12」）
? 「圖3-12」內部培訓
官方blog
知識的累積和鞏固途徑由淺到深可分為“聽讀寫說”，但聽別人說不如自己讀書，讀書不如動手練習寫寫，寫不如說出來給別人聽。能親口說出來的知識掌握得最牢固，不過不是人人都有勇氣在別人面前開口，因此我們設立了團隊Blog，把掌握到知識“寫”出來。
我會不定期給技術人員安排“功課”，給定一個主題和大綱，將一些開發(fā)的心得總結整理成博客文章，經我審查修訂后發(fā)布到公司的博客上，這樣即可以讓當事人的知識更加鞏固，又可以給其他同事作參考指引，另外還可以對外展示公司的技術能力和形象，可謂一舉多得。
外部技術交流會
只是內部交流是不足夠的，還要看看別人是怎么做的，做法很簡單要么走出去要么請人來。
我們會不定期安排一些優(yōu)秀的員工，參加的一些技術沙龍活動開拓眼界和學習。
我們會邀請其他企業(yè)的、行業(yè)的技術專家過來，給團隊分享技術上的、產品上的、團隊管理上的經驗。
交流應該是雙向的，我個人也會被邀請到其他技術團隊、交流活動分享我的技術經驗、心得，讓外界了解公司技術實力。
我自己曾作為2015年的Rubyconf China活動講師，跟現(xiàn)場300多ruby開發(fā)者們交流（「圖3-13」）
? 「圖3-13」Rubyconf China 2015
4. 考核
前面提到，除了專業(yè)技能，我認為優(yōu)秀員工的重要的品質有2點：
- 責任心
- 主動性
但這些是從短短一個小時的面試過程中是看不出來的，因此還要涉及到對新入職員工的考察和審核，試用期就是很好的一個讓雙方了解磨合的階段。
在前面提到的[公司新員工入職流程]中，我要求Mentor在試用期結束后，需要對新人進行評價審查，而評價審查的大綱很簡單：
- 基礎
- 學習能力
- 態(tài)度
- 交流
1是考察當前能力水平，這點在面試時已經大概了解，相當于驗證一下是否有水分，短短的試用期內也不大可能突飛猛進；
2考察個人潛質，對個人發(fā)展很重要；
3是看責任心和態(tài)度，遇到問題會不會主動找人反饋或協(xié)助？交代的任務超出預期時間不能完成有沒有主動反饋給項目組長？
4是考察團隊協(xié)作，對團隊重要，有些程序員動手能力強但比較內向，溝通能力略有欠缺的，那就可以安排不需要很多溝通需要的任務。
一般初級安排1到2個月的實習，但基本上1、2周都能看出一些問題了，這時我是愿意給機會調整，看重后續(xù)的成長，但如果到了實習結束期都還是不行的，那就只能勸退了。
審查內容只有4點，因為寫評價報告這件事對Mentor是開發(fā)工作之外的一種負擔，我盡量簡化文檔/報告的復雜度，減少干擾，接下來效率管理就會提到具體怎么做。
5. 效率管理
核心思想：減少干擾
程序員最煩什么？最煩的不是任務有多難多重，而是在寫代碼時被干擾打斷。為此我需要從溝通方式、工作流程、協(xié)作方式各種方面來解決干擾的問題，我大概歸納為“四化”：
- 溝通明朗化
- 工作流程化
- 開發(fā)自動化
- 協(xié)作清晰化
溝通明朗化 - 限定溝通工具、使用好工具
為了減少對開發(fā)人員的打斷，可以把需要溝通討論的內容根據(jù)“輕重緩急”，粗略分為“緊急且重要”，“緊急不重要”，“重要不緊急”。
- 緊急且重要的，就當面溝通。面對面溝通是效率最高的，然而這種情況也是最干擾的，因此應該判斷好溝通內容是否確實那么緊急且重要；
- 緊急不重要的，但期待對方盡快有反饋的，我們鼓勵在企業(yè)IM上進行對話，這樣對話內容以后還有歷史記錄。至于企業(yè)IM，我們團隊目前是使用Slack，支持@提醒、公私分組、代碼片段高亮、各種服務跟chatbot集成，強烈推薦技術團隊使用（見「圖3-14」）；
- 重要不緊急、需要存檔或者不期待對方馬上給反饋的，就建議使用Email，常見如一些重要公告、會議記錄通知。
- 其他的如任務反饋、code review的留言等，不需要馬上有答復的，只需要在任務管理工具上留言，這樣有源可塑。
? 「圖3-14」Slack example
另外還有一點要提的是，作為管理者應該有意識的界定IM工具的使用場景，我們工作時間使用Slack，這樣只要是通過Slack發(fā)過來的消息，我們能第一時間意識到是有工作相關的問題需要討論了，以便能及時作出反饋。Slack中按項目建立分組，所以往往只是看到消息是來自哪個分組，不用看消息內容，就以及知道大概是要討論什么內容，自然在腦中切換上下文，提高溝通效率。
不建議使用微信/QQ作為企業(yè)內部的溝通工具，由于微信/QQ混合了非工作消息的通知，開發(fā)人員不能很好的區(qū)分開這是有工作消息、還是普通社交聊天消息，很容易錯過重要的工作信息。但有人會說跟外部的人溝通時是避免不了使用微信/QQ，注意，這里說的是“企業(yè)內部的溝通工具的選擇”，對外該使用什么的還是用什么，兩者并不沖突。
工作流程化 - 不要每次都讓我告訴你什么時候該做什么
在團隊中，特別是進行軟件開發(fā)項目時，需要有一定的流程指引，那么大家在一起進行工作時可以分工、分步協(xié)作，清楚知道自己、別人下一步會做什么，自己會不會被干擾，從而提高協(xié)作的效率。
為此我根據(jù)我們公司實際的需要，制定了一些規(guī)范文檔，從接到項目需求，到項目評估、立項、開發(fā)、具體到代碼提交、部署、驗收都做了流程規(guī)范，例如：
- [公司開發(fā)流程規(guī)范] - 規(guī)范了從需求確定、項目評估、項目確立、開發(fā)、驗收交付到項目結束總結各個階段的各角色的工作內容范圍和輸入輸出的文檔，見「圖3-15」
- [公司招聘流程] - 前面提到過了，見「圖3-5」
- 開發(fā)流程圖 - 創(chuàng)建feature分支 -> 提交PR/MR -> code review -> 部署staging -> QA -> 部署production
- 提倡git flow - 使用Github/Gitlab flow，代碼提交使用Pull/Merge Request來進行code review
? 「圖3-15」公司開發(fā)流程規(guī)范
定好工作流程，大家都能從中找到自己的位置和角色，知道在什么階段要做什么、下一步做什么、要跟誰協(xié)作，不能有“一頭霧水”的感覺。
開發(fā)自動化 - 把重復丟給機器
我提倡善用工具最大程度做到自動化，這種思維是貫穿整個開發(fā)流程各個環(huán)節(jié)的。
如最普通的Terminal（終端shell），推薦使用帶交互的shell（如zsh/Fishshell）來輔助cli的操作，鼓勵善用alias來簡化重復的使用命令；
代碼開發(fā)時鼓勵使用支持自動完成的IDE、編輯器（如Sublime Text），鼓勵善用代碼snippet來減少重復編碼的操作；
代碼測試使用自動化測試（可配合guard或者livereload達到保存時自動跑相關測試）；
代碼提交使用自動化命令（gitlab-send-merge-request of git-cmd-helpers），一步完成代碼提交并發(fā)Merge request；
項目部署使用自動化部署工具（如Chef、Capistrano），做到一鍵部署；
使用CI（GitlabCI）進行自動化測試、自動構建、構建結果通知、自動部署、自動打包上傳app package，達到DevOps的自動化；
服務使用健康監(jiān)控（如Monit，God），自動監(jiān)測服務健康并自動重啟服務；
一句話就是盡量把重復的工作丟給機器去做，人力應該專注在機器解決不了的地方。
協(xié)作清晰化 - 讓你知道什么時候要去找誰做什么
為了解決協(xié)作清晰問題，我們使用3種管理方法：
- [公司 Agenda] - 團隊共享日程表
- [公司 collaboration] - 團隊協(xié)作（非特定項目）任務管理
- project board - 具體的項目管理布告板，在后面的項目管理章節(jié)中會具體提及
一個項目開發(fā)時必定會定下一些關鍵的時間節(jié)點，如什么時候開會討論、什么時候開發(fā)結束、什么時候做演示、什么時候正式上線；公司內必會有人員活動的變化，如公共節(jié)假日怎么安排、團建、什么時候有面試安排、團隊成員中必然會有事生病請個假什么的等等。
為了讓這些跟時間節(jié)點、會影響到人員在線情況的事件在團隊中清晰透明、避免沖突，我在公司里發(fā)起推行了“團隊日歷共享計劃 - [公司 Agenda]”（見「圖3-16」），這樣大家都能有個清晰的預期，知道最近有什么短期目標、有什么事需要準備、什么時候有會議要開、哪個小伙伴會沒有空。具體做法很簡單，使用Google Calendar服務進行日歷共享，客戶端使用Mac Calendar查看，約定好事件的標題格式“[公司名-項目名] 事件類別: 事件標題”。
另外注意一點，在推行新制度時，使用流行的服務和系統(tǒng)自帶的工具，可以降低推行阻力。
? 「圖3-16」公司 agenda
但日歷只能也只應該記錄事件標題和日期時間，更具體的內容，我們在Trello上建了一個board來進行管理，如我們的團隊分享安排、團建安排、假期的安排等。
至于更具體的項目開發(fā)任務，我們是使用獨立的項目管理工具，在后面的項目管理章節(jié)中會提及。
6. 情緒管理
是人就會有情緒，了解員工的情緒問題也是管理工作的日常之一。在公司還沒有強大到有專職的“程序員鼓勵師”時，也只有親身上陣，我推行了3種方式：
- 員工一對一談話 - 聊天是舒緩情緒很簡單有效的一種方式，無論工作問題、生活問題，都可以坐下來面對面聊一聊，討論下解決方法
- 員工年度調查 - 有些話不適合、不方便當面說的，那么可以寫下來，為此我發(fā)布過[2015年 公司員工年度調查]，收集對工作流程、工作環(huán)境、薪資待遇、公司發(fā)展建議等
- 戶外團建活動 - 離開工作環(huán)境人的情緒會得到放松，為此我擬訂過[公司2016團隊建設活動計劃]
我自認為在這方面做得還不夠好，InfoQ上有篇文章《技術團隊的情緒與效率》 值得參考借鑒。
事 - 項目管理
前面團隊管理中說“團隊是由一群追求一個或多個共同目標的人組成，通過一些規(guī)則約束在一起工作”，而項目管理則是為了讓團隊能在資源、人員限定的情況下，能按預期達成目標的手段和方法。
核心思想：有的放矢
項目管理的注意3點：
- 目標清晰 - 要做什么、什么時候完成
- 控制節(jié)奏 - 有了目標，就要管理好節(jié)奏，是一步到位還是小步快跑
- 制定規(guī)范 - 無規(guī)矩不成方圓，現(xiàn)代化團隊作戰(zhàn)講究統(tǒng)一、標準、量化
1. 目標清晰
在項目開發(fā)中，有3點需要清晰：
- 需求清晰 - 要做什么，做給誰用，做成什么樣
- 任務清晰 - 安排什么人，在什么時候，具體做什么
- 節(jié)點清晰 - 要在什么時候做完
針對以上這3點我制定了以下文檔、規(guī)范：
- 明確需求 - [公司 PRD文檔規(guī)范]
- 明確任務 - [公司 Trello使用規(guī)范]
- 明確節(jié)點 - [公司 Agenda]
下面分別說下具體的做法。
[公司 PRD文檔規(guī)范]
PRD（產品需求文檔），相當于是產品的工程設計圖紙，是給開發(fā)人員使用的，它的主要目的是陳述產品是什么，有什么功能，給什么人用，是什么樣子。因此我認為一份PRD中應包含以下7部分：產品說明文檔、產品信息結構圖、產品功能結構圖、邏輯流程圖、原型圖、功能點列表、設計文檔，如「圖4-1」，主要是說明每份文檔是什么、有什么用、大概長什么樣。
? 「圖4-1」公司 PRD 文檔規(guī)范
開發(fā)人員常說我不怕需求復雜也不怕需求太多，最怕的是我費心費力使用了優(yōu)雅的設計模式、重構了代碼、加了單元測試后PM對我說句“xx需求不要了”。所以如果作為產品PM，當整理過一份完整的PRD后，其實已經對產品的邏輯性、合理性做了一次梳理，再傳達到開發(fā)團隊手里時，能有效減少返工、無效需求的“折騰”。在這里要認清的一個事實就是：沒有不變的需求！所以我們要做的只是盡量減少無效需求傳導到開發(fā)手中，讓開發(fā)的輸出更有價值。
[公司 Trello使用規(guī)范]
Trello是個看板風格的協(xié)作工具，上手十分簡單，但由于Trello本身十分松散靈活，100個團隊有100種用法，因此為了方便統(tǒng)籌管理，我制定了一些使用流程并整理成規(guī)范文檔[公司 Trello使用規(guī)范]（見「圖4-2」），包含對list、label使用以及card生命周期的流轉，讓每個任務從需求轉化為任務，到分配、評估、開發(fā)、部署、測試、上線，意圖讓每一步都清晰可預期，參與員之間協(xié)作配合清晰可見。
我們的項目管理布告版也會對客戶開放，我們希望讓客戶從一開始就可以參與到日常開發(fā)流程中，可以了解項目的開發(fā)具體進度，也方便收集對需求任務的討論、BUG反饋，以及給客戶分配一些他們所要配合的工作（如一些基礎服務帳號注冊），讓協(xié)作由內而外都可以貫通。為此我特意把這個文檔寫了英文版，以發(fā)放給國外合作的客戶參閱以便了解我們是怎么使用Trello的。幫助客戶培養(yǎng)成合理的協(xié)作習慣，這其實對我們進行高效項目管理也會更有利。
? 「圖4-2」公司 Trello使用規(guī)范
[公司 Agenda]
一個項目開發(fā)，需要定一些時間節(jié)點，如什么時候正式立項，以便項目經理可以召集開發(fā)團隊、召開立項會議；什么時候做交付演示，以便讓QA工程師可以準備用戶故事；什么時候正式上線，以便項目組技術組長可以準備交付文檔；時候做營銷推廣以便運維人員可以做好服務器壓力測試調整服務器配置……
前面在說如何解決團隊協(xié)作清晰化中，提到了使用“團隊日歷共享計劃 - [公司 Agenda]”（見「圖3-16」），因此我要求項目經理給每個項目添加2種事件類型，一個是CHECKPOINT（檢查點），一個是DEADLINE（最后期限）。CHECKPOINT是階段性的時間節(jié)點，DEADLINE是當前版本最終的交付限期；一個開發(fā)版本內可以有多個CHECKPOINT，但只有一個DEADLINE。
做事應有始有終，我要求每個項目的每個大版本開發(fā)，都要定一個DEADLINE（最后期限），期限是構成目標的要素，沒有期限則沒有目標，沒有目標何從談管理。
CHECKPOINT則是一些階段性的目標，到達一個DEADLINE之前，可以有多個CHECKPOINT；一個CHECKPOINT可以是任何關鍵事件，如階段演示、交付演示，可安排階段小結會議來討論技術問題調整開發(fā)計劃。
個人todo管理tips
在日常工作中，往往又有一些個人的代辦事項，如某項技術調研、培訓文檔準備等不適合放入?yún)f(xié)作的任務列表的，也要管理起來，我現(xiàn)在的做法如下：
- 不需要協(xié)作的，放入 Wunderlist（可跨多終端）;
- 需要team范圍知曉的、有明確日程安排的，放Agenda;
- 跟具體項目相關的，放在對應的項目trello board
2. 控制節(jié)奏
項目開發(fā)有如組織團隊賽跑，需要控制好節(jié)奏，什么時候要留力調整速度，什么時候要加速沖刺，都應該有規(guī)劃。
我根據(jù)這些年來的項目開發(fā)經驗，整理了一份開發(fā)流程規(guī)范 [公司開發(fā)流程規(guī)范]（見「圖 17」），劃分出幾個階段，每個階段有主要參與的角色及其主要任務、有輸入輸出的結果，以便項目參與者明確自己角色的任務。
項目開發(fā)流程大綱：
- 選定項目管理框架/風格：Kanban + Scrum
- 選定項目管理工具：
- 默認：Trello + Scrum Extension
- 其他：Redmine，Teambition，Worktile，Tower
- 角色安排：項目經理，產品經理，項目組長，開發(fā)，測試，運維
- 流程安排：
1. 需求確定 - 確立需求可行性
2. 項目評估 - 根據(jù)PRD評估開發(fā)量，確定項目周期
3. 項目確立 - 項目組角色安排，項目周期、確定技術棧
4. 開發(fā) - 日常開發(fā)迭代
5. 驗收交付 - 交付項目，收集客戶反饋
6. 項目結束 - 進行項目匯總，總結開發(fā)收獲、工作流程改進意見
- 會議安排：
* 項目啟動會議 - 成立開發(fā)組、通告項目背景、周期、技術棧
* 項目階段會議 - 階段性小結，了解當前實現(xiàn)進度及出現(xiàn)的問題，調整下階段的目標和做法
* 項目總結會議 - 進行項目匯總
?「圖3-15」公司開發(fā)流程規(guī)范
3. 制訂規(guī)范
所謂無規(guī)矩不成方圓，在一個完整的開發(fā)流程中，每個環(huán)境牽扯到不少細節(jié)，團隊會不時增補新人員，要形成統(tǒng)一的團隊風格，少不了要制定一些規(guī)范文檔，讓團隊每個成員可以達到一致的行事風格和輸出，其他對接同事協(xié)作時則有規(guī)可循。特別的，一些輸出文檔我都給出了樣例，這樣負責輸出文檔的同事只需做“填空題”，關注輸出內容本身即可。
以下是我制定的跟項目開發(fā)流程相關的系列文檔例子：
- [公司開發(fā)流程規(guī)范]（見「圖 3-15」）
- [公司 PRD文檔規(guī)范]（見「圖 4-1」）
- [公司 Trello使用規(guī)范]（見「圖 4-2」）
- [公司 Trello board template]
- [公司項目周報規(guī)范文檔]
- [公司階段小結會議規(guī)范]
- [公司項目總結會議規(guī)范]（見「圖 4-3」）
- [公司項目總結報告規(guī)范]
- [公司會議記錄書寫規(guī)范]
? 「圖4-3」公司項目總結會議規(guī)范
小結
如果有一些成熟完整的項目管理工具，可以輔助解決一些流程的規(guī)范、自動化，自然會省事不少，但工具很重要也只是輔助，我接觸了解過一些開發(fā)團隊，使用了一些復雜、強大的項目管理工具，然而管理層不去推行、監(jiān)督，執(zhí)行層不落實執(zhí)行，工具再多再強大也是沒有意義。因此在工具的使用上，適合自己團隊的才是最好的，不用過于糾結在工具選擇上。例如，我們使用Scrum管理框架，但也不是完全照搬Scrum全家桶，我們有每日站會、有Sprint 評審/回顧會議（我合并為“階段小結會議”）、使用Backlog列表、任務評估使用Story Point、使用User Story做驗收交付文檔，沒有Scrum Master（但有項目組長），根據(jù)團隊的實際情況做了簡化調整，可以落實執(zhí)行的方案才是好方案。
總的來說，即使團隊只有一個人時，做事也應該有章法，才能做到事多不亂，團隊壯大了再由己及人，保持團隊一致的調性。只有做到以上這些，我們才能從復雜多變的環(huán)境中做到“有的放矢”，從容應對變化。
關于項目管理有幾本書推薦閱讀：
- 《最后期限》 —— 被稱為“中國第一本項目管理小說”，以一個虛構小說告知項目最重要的4個要素：找對人，分配正確的任務，激勵，團隊建設。
- 《人月神話》 —— 本書自第一版以來，暢銷20余年不衰，是軟件領域絕無僅有的必讀經典
- 《Scrum權威指南》 —— 不到20頁的文檔里簡明闡述了Scrum是什么、怎么進行Scrum，特別是在2016年版引入了“Scrum價值觀”的概念，鼓勵團隊成員相互敬重，彼此成為更有能力和獨立的人。
- 《技術管理之巔 : 如何從零打造高質效互聯(lián)網技術團隊？》 —— 1號店技術總監(jiān)出品，推行扁平話、OKR目標管理、Scrum和Kanban的實踐、自動化測試等，從技術團隊組織架構、產品開發(fā)流程、制度規(guī)范建立、企業(yè)文化、大數(shù)據(jù)與技術管理創(chuàng)新、移動技術開發(fā)、實用應用架構設計等方面。
物 - 技術管理
核心思想: 喜新厭舊
- 喜新（Upgrade）：升級技術棧
- 厭舊（Migrate）：償還技術債務
喜新（Upgrade）：升級技術棧
從事信息技術的都知道摩爾定律，然而這個定律不止作用在芯片更新?lián)Q代上，在編程領域也是可適用的，幾乎每年都有一些新編程語言、技術框架、系統(tǒng)架構的出現(xiàn)，其中一些有重大突破性的還能引起熱潮。對于技術團隊，其能掌握的技術棧就是其戰(zhàn)斗力，而今年掌握的很有可能第二年就變?yōu)檫^時，因此一個有活力的技術團隊是需要不斷吸收外界新鮮有活力的技術點，吸納融合入團隊技術棧，轉化為團隊的戰(zhàn)斗力。
然而新技術會不斷提出、舊技術會迅速過時，我們既不能被新技術牽著鼻子走又不能過于落伍。因此在選定技術棧時需要具備有前瞻性，不能被新熱的技術吸引分散精力，也又不能把團隊綁定到一些沒有生命力的技術上，這不是簡單的選擇題，需要經過探索、調研、實踐到最后掌握化為生產力。
厭舊（Migrate）：償還技術債務
在項目開發(fā)過程中，有時會根據(jù)當時的人、財、物及知識經驗限制等，對技術框架、架構選型做一些當時認為“最適合”的設計或選擇，但隨著時間推移，需求變更、經驗提升、新技術提出等，回過頭來會發(fā)現(xiàn)當時的“最佳實踐”已經不適合了，有的嚴重更會成為推進項目的負擔，這種情況我們稱之為“技術債務（technical debt）”。
欠債要還，沒有反思不會進步，因此要給團隊“還債”的時間，團隊才有進步。但這點在外包開發(fā)團隊中其實是很難徹底實踐，因為需要跟客戶解釋什么是“重構”，為什么要花時間去做一些沒有明顯輸出的工作；又得在盡量不影響工期的情況下，定下更“正確”的架構，這也很考驗架構能力。
所幸我們團隊是以Ruby/Rails框架為核心技術棧，Rails框架本身就是fullstack且推崇最佳實踐的框架，每年都有大版本升級，每次升級都會引入對提升開發(fā)效率、安全、代碼質量的理念和實踐。因此我們選擇了Rails，就相當于在底層框架中有一支專業(yè)的團隊不斷的在維護升級，這也是為什么國內外很多創(chuàng)業(yè)團隊喜歡選擇Rails作為開發(fā)框架的原因，可以讓產品開發(fā)者更多去關注業(yè)務實現(xiàn)，而不用太過操心底層框架的維護。
更重要的是，Ruby/Rails不止提供給我們快樂編程的體驗，還指導了我們做事情的方式方法、看問題的角度：The Rails Doctrine - Rails 信條
另外遇到一些本身就是做技術開發(fā)的客戶時，就會比較好溝通能得到認可，但這種優(yōu)質客戶是隨機的、可遇不可求，更多情況是我們開發(fā)團隊自己要提高自己的迭代能力，在每次階段會議、項目總結時進行技術積累，把經驗知識應用到新的項目上。
上面說了那么多理論，下面說下怎么做。
具體做法
作為公司技術負責人，我進行技術管理主要看以下6個方面：
- 技術調研 - 探索新技術、調研工作上需要用的服務等，以保持技術團隊的先進性
- 技術實踐 - 有實踐過的技術才敢引入團隊中，不要做拍腦袋決策
- 技術培訓 - 得到認可的技術要推廣和普及給其他成員，提升團隊整體戰(zhàn)斗力
- 技術復用 - 提取出可復用的技術點，進一步提高團隊生產力
- 規(guī)范化 - 技術團隊應保持一致行事風格，以降低溝通、代碼維護、工具使用的成本
- 自動化 - 解放生產力，讓機器去做重復工作，人力去做突破性工作
具體實踐總結
以下是具體實踐過的一些調研報告（report）、培訓講稿（ppt）、規(guī)范文檔（doc）、知識庫（wiki）、內部開源項目（project）以及公開博客文章（blog post），涉及的內容其實很多我這里只列出一些比較有代表性的、在團隊內實踐分享過的內容：
- 技術調研
- report:[angularjs vs reactjs]
- report:[2016 Rails popular app servers]
- report:[chrome extension開發(fā)調研]
- report:[Crash Reporting Service]
- report:[React-Native Hot Update Services Research Report]
- report:[流行云主機調研報告]
- report:[國內外流行字體CDN調研]
- report:[QingCloud 調研]
- doc:[公司 技術調研報告規(guī)范]
- 技術實踐
- project:[jpush-ionic-demo]
- project:[pushwoosh-example]
- project:[公司team/react-components]
- 技術培訓
- ppt:[how to do model design]
- ppt:[toolbox-for-optimizing-rails-project]
- ppt:[rails項目中性能調優(yōu)要注意什么]
- ppt:[rails-debug-tips 2016]
- ppt:[如何寫一份壓力測試報告] （如 「圖5-1」）
- ppt:[如何用rails開發(fā)一個任務管理的網站和移動app]
- 技術復用
- 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開發(fā)流程規(guī)范]
- wiki:[how to write a rake task]
- doc:[Tech Stack Example]
- doc:[API design example]
- 自動化
- 自動化測試
- blog post:[RSpec 使用一周小結（上篇）]
- blog post:[RSpec 使用一周小結（下篇）——使用 FactoryGirl 準備測試數(shù)據(jù)]
- blog post:[rails集成測試學習總結]
- blog post:[rspec集成測試的總結]
- blog post:[簡介如何測試Rails應用]
- blog post:[壓力測試總結]
- 自動化部署
- wiki:[Deploy Project to Staging Using Capistrano on Ubuntu]
- DevOps - 持續(xù)集成
- wiki:[Setup GitLab CI]
- wiki:[Setup GitLab CI Runner]
- ChatOps - Slack+Lita
- 自動化測試
? 「圖5-1」如何寫一份壓力測試報告
? 「圖5-2」公司代碼規(guī)范指南
重點說說自動化
自動化技術在技術團中對效率提升很重要，在前面的“團隊管理 - 開發(fā)自動化” 這節(jié)已經提到了：
我提倡善用工具最大程度做到自動化，這種思維是貫穿整個開發(fā)流程各個環(huán)節(jié)的。
如最普通的Terminal（終端shell），推薦使用帶交互的shell（如zsh/Fishshell）來輔助cli的操作，鼓勵善用alias來簡化重復的使用命令；
代碼開發(fā)時鼓勵使用支持自動完成的IDE、編輯器（如Sublime Text），鼓勵善用代碼snippet來減少重復編碼的操作；
代碼測試使用自動化測試（可配合guard或者livereload達到保存時自動跑相關測試）；
代碼提交使用自動化命令（gitlab-send-merge-request of git-cmd-helpers），一步完成代碼提交并發(fā)Merge request；
項目部署使用自動化部署工具（如Chef、Capistrano），做到一鍵部署；
使用CI（GitlabCI）進行自動化測試、自動構建、構建結果通知、自動部署、自動打包上傳app package，達到DevOps的自動化；
服務使用健康監(jiān)控（如Monit，God），自動監(jiān)測服務健康并自動重啟服務；
一句話就是盡量把重復的工作丟給機器去做，人力應該專注在機器解決不了的地方。
如「圖5-3」就是我們團隊日常開發(fā)中，從本地終端使用一行代碼發(fā)起MR（MergeRequest），code rewivew通過合并MR，觸發(fā)CI自動進行構建、測試、部署到通知Slack的過程
? 「圖5-3」auto CI/CD
另外我們開發(fā)的Chrome Extension項目，也做到了的DevOps貫通、自動化發(fā)布，流程如下：
- 開發(fā)在本地執(zhí)行執(zhí)行構建命令：
gulp release --bumpversion，自動更新 manifest.json中的版本號、自動做git commit、同時自動以版本號創(chuàng)建git tag - 往Gitlab發(fā)起MR，合并到develop分支后，CI會自動加上
--env staging為參數(shù)，應用上針對staging的配置，進行構建生成zip文件 - 把develop往master合并后，CI會自動加上
--env production為參數(shù)，應用上針對production的配置，進行構建生成zip文件 - 在CI上構建生成zip文件時，會自動加上一些stamp（包括extension version，git revision， env，datestamp），如“Trellohub-0.2.2[staging]@2016-12-06^0b89f89”
- zip文件生成完畢后，CI自動把zip文件上傳到Trello board對應環(huán)境的card中；發(fā)布為staging的，放入packages-for-staging card以便可以給QE進行QA；發(fā)布為production的，放入packages-for-production card以便給PM上架發(fā)布到Chrome Web Store
整個流程中只有第1、2步是需要人工參與（將來可優(yōu)化成一步），其他步驟已全部通過CI實現(xiàn)自動化。
對于ios/android app構建發(fā)布，我也準備使用Appium做集成測試，使用Fastlane做自動化構建，配合Gitlab CI打通DevOps自動化。
自動化有助減少人工參與，提高效率的同時減少誤操作可能，技術團隊應大力推行。
小結
今年最大的變化莫過于前端圈的火熱和容器架構的盛行，層出不窮的概念、輔助的工具，新技術還沒來得及掌握轉眼已經變?yōu)樘蕴@也意味著對技術的細分越來越專業(yè)，同時也意味IT項目的工程化越來越專業(yè)。這是挑戰(zhàn)也是機遇，項目越復雜、質量要求越高，對個人的要求也就越高，也意味著團隊作戰(zhàn)的作用越重要，這也正是PaaS/SaaS這類以打包服務為賣點的平臺也更有機會。
文 - 文化建設
核心思想: “八面”玲瓏
團隊文化是指團隊成員在相互合作的過程中，為實現(xiàn)各自的人生價值，并為完成團隊共同目標而形成的一些行事態(tài)度、思考方式和行為準則。在技術管理方面，我主要是負責塑造技術文化氛圍，并通過這些思想、準則來影響及推行“團隊管理”、“項目管理”及“技術管理”等方面。
我眼中的工程師文化
所謂“八面”玲瓏，不是指要把人培養(yǎng)成圓滑的人，而是我認為在一個以工程師為伍的技術團隊中，應該建立以下八個方面的文化：
- 學習文化
- 創(chuàng)新文化
- 工程文化
- 工具文化
- 自動文化
- 腳本文化
- 開源文化
- 流程文化
學習文化
- 技術調研
- 技術總結
前面“技術管理”中說過要“喜新厭舊”，不斷擴寬知識邊界、填平知識短板，團隊技術水平才能不斷提高。對新出現(xiàn)、不熟悉的技術點要進行調研，出調研報告；對已經熟悉用過的，要做技術總結，使得經驗可以復用。如何鼓勵內部分享，外部交流、互通有無，在前面“團隊管理”如何“培養(yǎng)”已經具體說過就不再展開。
創(chuàng)新文化
公司無創(chuàng)新則無獨特的競爭力，這點大家都懂不多用解釋。但我認為“創(chuàng)新”不止是說創(chuàng)造新的工具、組件，勇于使用新技術、引進新框架、打破陳規(guī)做法也是一種創(chuàng)新，能引起“有益的變化”就是創(chuàng)新，應該鼓勵。
例如我看到我們有一個項目后端是ruby，前端是coffee語言編寫，都有大量的類定義，新加入的開發(fā)人員上手會比較困難，為此我編寫了一個文檔構建腳本，能自動對2種語言的代碼分別生成統(tǒng)一的YARD風格的文檔，再合并在一份文檔中，以方便開發(fā)人員查看熟悉程序結構，如「圖6-1」
? 「圖6-1」build app doc
這種有利于提高工作效率的改進在我看來就算是一種微創(chuàng)新。
工程文化
軟件工程開發(fā)，從來不是寫個“Hello World”這么簡單的事情。一個完整的軟件工程，需要考慮程序語言、數(shù)據(jù)庫、開發(fā)工具、系統(tǒng)平臺、依賴包管理、代碼目錄結構、設計模式、日志記錄等方面，開發(fā)項目交付時，除了代碼，還要功能說明文檔、代碼說明文檔、單元測試、壓測報告、部署說明文檔。所以在我看來，一個開發(fā)框架的工程化成熟度，就是看以上這些方面的覆蓋程度。
前面“技術管理”中說過了我們的Web 開發(fā)框架是用Rails，而Rails是fullstack的、從一開始就走工程化的風格，從初始化一個rails項目的第一步的命令： rails new MyProject --database=postgresql --javascript=jquery 看出它會期待你預先考慮好后端使用什么數(shù)據(jù)庫，前端使用什么js庫，當然這些參數(shù)都是可選，不選擇則使用默認配置，Rails遵從CoC（約定優(yōu)于配置） 原則。
再看一下rails 5自動生成的項目目錄結構：
├── Gemfile # gem依賴管理(Gem是Ruby領域的apt)
├── README.md # 說明文檔
├── Rakefile # 構建任務管理入口（Rake是Ruby領域的Make）
├── app/ # 應用代碼
│ ├── assets/ # 靜態(tài)資源文件（js,css,img,font）
│ ├── channels/ # 基于WebSocket 的Pub/Sub實現(xiàn)
│ ├── controllers/ # 控制器，負責處理請求，調取Model，選擇View渲染
│ ├── helpers/ # view 的輔助模塊
│ ├── jobs/ # 隊列任務
│ ├── mailers/ # 郵件內容
│ ├── models/ # 業(yè)務模型
│ └── views/ # 視圖（HTML模板）
├── bin/ # 一些項目CLI命令、自定義腳本
│ ├── bundle*
│ ├── rails* # 主要CLI，提供啟動app server、控制臺、生成器、運行測試
│ ├── rake*
│ ├── setup* # 項目初始化腳本，一步完成安裝依賴、數(shù)據(jù)庫初始化、啟動rails server
│ ├── spring*
│ └── update* # 開發(fā)過程更新腳本，一步完成安裝依賴、數(shù)據(jù)庫遷移、清理臨時文件、重啟rails server
├── config/ # 各種配置，如啟動方式、數(shù)據(jù)庫配置、路由配置、環(huán)境配置、密鑰配置、i18n配置
├── config.ru # Rack架構服務調用接口
├── db/ # 數(shù)據(jù)庫遷移改動、種子數(shù)據(jù)
├── lib/ # 獨立的類、模塊、app相關的rake任務
├── log/ # 各種日志文件
├── public/ # 不用預處理、可公開訪問資源目錄，如404.html,robots.txt
│ ├── 404.html
│ ├── 422.html
│ ├── 500.html
│ ├── favicon.ico
│ └── robots.txt
├── test/ # 單元測試、集成測試
│ ├── controllers/
│ ├── fixtures/
│ ├── helpers/
│ ├── integration/
│ ├── mailers/
│ ├── models/
│ └── test_helper.rb
├── tmp/ # 緩存、臨時文件
│ └── cache/
└── vendor/ # 第三庫、資源
└── doc/ # 文檔存放目錄，從rails 4不再默認生成，但可以通過`rake doc:app` 來檢查并生成app代碼文檔
從所生成目錄就能看出在 rails 項目里會涉及到依賴包管理、構建任務、靜態(tài)資源處理、消息訂閱處理、消息隊列處理、MVC架構、郵件處理、提供CLI、i18n處理、多環(huán)境適配、Rack架構、數(shù)據(jù)庫連接、數(shù)據(jù)庫查詢（ORM）、數(shù)據(jù)結構遷移管理、初始化數(shù)據(jù)管理、日志處理、單元測試、集成測試這些概念，幾乎涵蓋了一個Web項目需要用到的方方面面，可以大方說句使用rails的開發(fā)者相對是比較“幸福”的，因為有很多細枝末節(jié)的地方都已經有被考慮到，而且還在不斷的補充引入新的feature。
我們使用的技術框架不止rails，在前后端分離的架構中，前端使用過Backbone/Angularjs/React & Redux，在移動開發(fā)中使用Ionic/React Native，但這些技術框架中有些沒有很統(tǒng)一、符合要求的工程化規(guī)范，因此我安排整理了一些目錄規(guī)范，例如：
- angularjs 項目目錄結構規(guī)范文檔
- react-redux 項目目錄結構規(guī)范文檔
- React Native項目結構規(guī)范
以便開發(fā)項目時更工程化、結構化，可以在新項目中可以復用架構、組件可以通用
工具文化
“工欲善其事，必先利其器”這句話我非常贊同。如果說任務開發(fā)是戰(zhàn)場，那么開發(fā)者使用的工具就是他們的武器，把“武器”打磨得是否順手就會成為戰(zhàn)場生存的關鍵之一。我經常在團隊中推薦并鼓勵每個人都分享、推薦自己使用過、認為高效的工具，例如：
- Shell： zsh/fish - 交互式shell，提高CLI操作效率
- 代碼提交： GitX - 我鼓勵在代碼提交時使用git的GUI工具如GitX而不是命令行，因為GUI工具可以進行代碼整理，有利合理的代碼提交記錄
- 終端操作： TotalTerminal/iTerm - 隨時隨地可以進行敲命令
- 文檔編輯：MacDown - 所寫己所得、兼容github GFM格式
- API查看：Dash - 快速離線查看各種技術API文檔，開發(fā)者必備
- 窗口操作：Spectacle - 多屏幕操作利器
- 應用訪問：Alfred - 把Mac變成Google Instant Search 般的體驗
- 圖片編輯：Skitch - 一圖勝千言，快速給截圖加上注釋
- 數(shù)據(jù)庫操作：Navicat Lite - 支持鏈接mysql/postgres/oracle/sqlite/sql server，開發(fā)者必備
- 代碼編輯器：Sublime Text/Vim/Emacs/Atom - 編輯器的選擇對程序員而言是場“圣戰(zhàn)”，為了找出“哪個才是最好的代碼編輯器”，我特意在團隊內發(fā)起過專題分享活動：“編輯器到底哪家好”——技術分享 @ 2015-01-10
自動文化
優(yōu)秀程序員三大特質之一是“懶”，能用程序、腳本解決的，就不用手工，更有“以自動化為榮，手工為恥”的說法，常會出現(xiàn)花費幾個小時的腳本去解決一次只要十幾分鐘簡單但會重復的問題，作為管理者遇到這種情況不應該一昧的打壓，因為這種思想就是以自動化思維去解決重復，前面“技術管理”章節(jié)中就提到過了自動化的重要性，從本地開發(fā)、到代碼提交、測試、集成、部署、發(fā)布、監(jiān)控等各個環(huán)節(jié)中都有加入自動化的操作，能執(zhí)行自動化的都盡量推行自動化，提高效率之余減少人為誤操作。
以現(xiàn)在的觀點來看，一個技術團隊中有沒推行自動化技術，可以認為這個團隊是否達到“高效”的檢驗特征之一了。
腳本文化
無論是作為Java，C++，.Net 這類靜態(tài)語言的程序員，還是使用Ruby，PHP，Python，JavaScript 這類腳本語言的程序員，在開發(fā)過程中都會接觸到Shell腳本（Shell Script），因此掌握一些基本的Shell腳本操作，可以有效提高工作效率。
除了可以使用上面提到的“工具文化”中推薦的一些交互式shell來提高CLI操作效率外，還應掌握一些簡單的Shell語法，用以編寫輔助開發(fā)的腳本。
最簡單的做法是可以增加一些alias作為一些常用命令的組合，使用有語義的命名，配合可交互Shell的提示，很簡單、很低廉的操作成本，就可以在很大程度上減少重復敲打鍵盤、錯誤輸入。例如我給不熟git的新人建了個 git-cmd-helpers，就是增加一些常用git 操作的封裝，用以提高git的使用效率。
開源文化
作為技術開發(fā)者，我們是技術開源社區(qū)的收益者（可見我發(fā)表的 blog post:公司用到的開源產品），因此也鼓勵開源精神。我會經常在團隊中鼓勵在開發(fā)中使用一些開源組件遇到問題修復時，給源作者發(fā)PR，我們在github上也有發(fā)布一些開源作品。
流程文化
制訂流程，是團隊多人協(xié)作的基礎，是“規(guī)范化”的細節(jié)，是“自動化”的前提。
在前面的“團隊管理”提到工作要流程化，我制定了涵蓋從招聘到入職、升退評價、招聘和入職流程；“項目管理”中我制定了[公司開發(fā)流程規(guī)范]、[公司 Trello使用規(guī)范]，涵蓋從需求對接到項目結束交付；“技術管理”中提到[trello + git開發(fā)流程規(guī)范]，涵蓋了代碼提交流程、代碼審查流程、部署流程步驟細節(jié)。
制訂制度、規(guī)范的流程
同樣的，在企業(yè)中制定一種新的制度、規(guī)范時，也應該遵從類似以下流程：
- 調研 - 先看人家怎么做
- 制訂 - 自己要怎么做
- 發(fā)布 - 跟團隊說明是什么、怎么做
- 執(zhí)行 - 怎么說就要怎么做，最忌光說不練
- 監(jiān)督 - 了解執(zhí)行效果，收集反饋
- 修正 - 根據(jù)反饋意見調整細節(jié)，收集到足夠多的改動后發(fā)布新版
- 發(fā)布新版 -> 執(zhí)行 -> 監(jiān)督 -> 修正 ->（重復）
思路：跟寫單元測試一樣
- 編寫測試代碼
- 運行測試
- 觀察結果
- 修正實現(xiàn)代碼 -> 運行測試 -> 觀察結果 -> (重復)
推衍：企業(yè)內所有的重大決策都應該如此推行
所以一個成熟的技術團隊中，為了明確職責、分工清晰、減少沖突，是很有必要制定一些常用流程，并將之作為的規(guī)范文檔沉淀下來反復推行實踐，以下我制定過且形成規(guī)范文檔的流程：
- [公司招聘流程] （見「圖3-5」）
- [公司新員工入職流程] （「圖3-6」）
- [公司開發(fā)流程規(guī)范]（見「圖3-15」）
- wiki:[公司任務開發(fā)流程]
- wiki:[Trello + git開發(fā)流程規(guī)范]
小結
以上這八種便是我認為是對技術團隊有益的文化總結。
企業(yè)文化建設能否建設好同樣是門不簡單的技術活，但更大程度上是受企業(yè)創(chuàng)始人、管理層影響，因此不同技術團隊中即便是使用相同的技術棧，但由于創(chuàng)始人不同，所施行的管理理念、思考方式不同，執(zhí)行結果也就不一樣。因此我不認為有“最好”的團隊文化，只有“最適合”的團隊文化，因地制宜、量身打造的才是適合自己的。
總結
在最后做一下總結，我認為想要打造 高效 高質量 的技術團隊，需要解決以下問題：
- 高效人員：
- 持續(xù)深入
- 專人專職
- 技術復用：
- 經驗復用
- 代碼復用
- 文檔復用
- 團隊復用
- 產品復用
- 自動化：
- 開發(fā)自動化
- 測試自動化
- 部署自動化
- 運維自動化
- 規(guī)范化：
- 流程規(guī)范化：開發(fā)流程，會議流程，交付流程
- 代碼規(guī)范化：代碼編寫，代碼提交，代碼審查
- 文檔規(guī)劃化：需求文檔，調研文檔，會議文檔
- 目標清晰：
- 需求清晰，協(xié)作清晰，日程清晰，任務清晰，流程清晰 = 為了什么，跟什么人，在什么時候，做什么事，要怎么做
