CEO主要管四方面：人事物財。對於CTO，我認為也是管四個方面：人事物文。

　　·人- 團隊管理

　　·事- 專案管理

　　·物- 技術管理

　　·文- 文化建設

　　團隊管理團隊由追求一個或多個共同目標的一群人組成，經過一些規則約束在一起工作。要讓高效協作，需以人為本，讓成員在各自位置得到最有效發揮，個體與整體相互促進成長。

　　1. 組織架構

　　組織架構是公司骨架，明確各個崗位的職責、管理範圍、責任鏈。以下為負責技術開發部分：

　　

組織架構

　　2. 招聘

　　招人這件事本身就是個技術活。從哪兒招？要發什麼樣的招聘文案吸引人？面試時問什麼？怎麼知道對方是不是有料？什麼樣的人適合留下來？

　　有效過的招聘渠道大概有3種：內部推薦，專業招聘網站，社群論壇。其中內推最靠譜。為了鼓勵更多內推，我們推行了內推獎勵機制：內部推薦成功後，推薦人可獲一定獎勵。

　　不同的技術崗位需要掌握的技術技能自然不同，因此刷選時也需要面試官對面試崗位技能都有所掌握，然而每一門技術的技能樹各不相同。

　　

前端工程師技能樹

　　技術崗位都需要定一些面試題目來提高候選人篩選效率和標準化結果評估。

　　面試很佔用人的時間、精力，對於應聘者，耐心引導，應避免面試緊張導致應聘者沒有發揮好從而給出錯誤結論。

　　讓新人儘快通過磨合，熟悉開發流程，掌握專業技能，儘早能獨立完成開發任務。以下方案：

　　·引入Mentor導師制度

　　·[xx公司新人注意事項]

　　·code review：[Code Review Tips]

　　·pair programming

　　·內部培訓、分享

　　·官方BLOG

　　·外部技術交流會

　　Mentor制度

　　指定一名同類崗位、高一級別的同事任“導師”，帶新人熟悉環境、流程、規範等，儘快通過磨合，熟悉團隊、有歸宿感。

　　開發人員一開始也可能不懂如何指導新人。為解決這種問題，我整理了一份文件，可以是WIKI中的的連結索引。不要分享整個文件給新人，讓他鍛鍊自學能力。

　　

新人注意事項

　　Code Review

　　我們在日常開發中鼓勵並推行程式碼審查。

　　專案開發階段時，我會根據開發組成員的級別設定審查鏈，按照“中級審初級，高階審中級，高階互審”。

　　沒有合適的人時我來審查，開發任務完成後，任務開發者需要發Pull/MergeRequest給指定好的審查者進行審查和合並，確保每次程式碼合併前都有2個人能看到過，一般只有在做演示出現exception，需要緊急合併做部署時才會跳過code review流程。

　　推行程式碼審查需要有兩個人以上的協作，自然是有代價的，那有什麼好處？

　　程式碼審查相當於另一種pair programing，大家的程式設計水平都能提高（無論是提出問題的，還是被指出問題的）

　　讓一個新人融入團隊沒有比在一起討論程式碼更快的方式了，特別是對於新人而言，對程式碼規範不熟悉，通過Code Reivew能有效減少低質量程式碼的Check in，對個人、對團隊、對專案都是很有益的一項安排。

　　我日常對進行Code Reivew發現問題做總結，在團隊內也做過一次專題培訓。

code review examples

　　特別提一下，設定固定的審查鏈的好處是減少審查者的負擔，每個人只需負責1~2個的程式碼審查；階級式的安排，可以讓高階的不用反覆的去提點低階人的一些低階錯誤，反覆指出一些低階問題對高階人員是負擔也是干擾，容易累積高階人員缺乏成就感的情緒（程式設計師的一個特質是喜歡有挑戰性的任務）。

　　結隊程式設計

　　結對程式設計的好處不用多說，應鼓勵結對程式設計。我不會強制安排，不會要求像教科書般要求在某個時間規規矩矩的一個看一個寫，實際上一般的情景是某個同事有問題時，需要找我或作指導的其他同事，拿上電腦大家坐在一起討論、直接敲程式碼：

pair programming

　　內部培訓、分享

　　團隊的強大不能依賴個體，新知識只有一個人掌握時，不等於團隊掌握了，分享出來團隊技術才能成長。

　　在每週五下午，我會不定期的安排一些內部的培訓，技術的、設計的、產品的，不限制領域，既是對個人的一次鍛鍊，又同時是給大家一個休息、坐在一起討論的時間。

　　技術部落格

　　知識的累積和鞏固途徑由淺到深可分為“聽讀寫說”，但聽別人說不如自己讀書，讀書不如動手寫，寫不如說出來給別人聽。能親口說出來的知識掌握得最牢固，不是人人都有勇氣在別人面前開口，因此開設技術blog，把掌握到知識“寫”出來。

　　只是內部交流是不足夠的，還要看看別人是怎麼做的，做法很簡單要麼走出去要麼請人來。我們會不定期安排一些優秀的員工，參加的一些技術沙龍活動開拓眼界和學習。

　　5. 效率管理

　　程式設計師最煩什麼？最煩的不是任務有多難多重，而是在寫程式碼時被幹擾打斷。為此我需要從溝通方式、工作流程、協作方式各種方面來解決干擾的問題，我大概歸納為“四化”：

　　·溝通明朗化

　　·工作流程化

　　·開發自動化

　　·協作清晰化

　　提高溝通效率

　　微信或QQ混合了非工作訊息的通知，開發人員不能很好的區分開這是有工作訊息、還是普通社交聊天訊息，很容易錯過重要的工作資訊。注意，這裡說的是“企業內部的溝通工具的選擇”，對外該用什麼的還用什麼，兩者並不衝突。

　　工作流程化

　　在團隊中，特別是進行軟體開發專案時，需要有一定的流程指引。大家在一起進行工作時可以分工、分步協作，清楚知道自己、別人下一步會做什麼，自己會不會被幹擾，從而提高協作效率。

　　·開發流程規範- 規範了從需求確定、專案評估、專案確立、開發、驗收交付到專案結束總結各個階段的各角色的工作內容範圍和輸入輸出的文件

　　·開發流程圖- 建立feature分支-> 提交PR/MR -> code review -> 部署staging-> QA -> 部署production

　　·提倡git flow - 使用Github/Gitlab flow，程式碼提交使用Pull/MergeRequest來進行code review。

　　定好工作流程，大家從中找到自己的位置和角色，知道在什麼階段要做什麼、下一步做什麼、要跟誰協作，不能有“一頭霧水”的感覺。

　　開發自動化

　　提倡善用工具最大程度做到自動化，這種思維是貫穿整個開發流程各個環節的。比如最普通的Terminal（終端shell），推薦使用帶互動的shell（如zsh/Fishshell）來輔助cli的操作，鼓勵善用alias來簡化重複的使用命令；

　　程式碼開發時鼓勵使用支援自動完成的IDE、編輯器（如SublimeText），鼓勵善用程式碼snippet來減少重複編碼的操作；

　　程式碼測試使用自動化測試（可配合guard或者livereload達到儲存時自動跑相關測試）；

　　程式碼提交使用自動化命令（gitlab-send-merge-requestof git-cmd-helpers），一步完成程式碼提交併發Merge request；

　　專案部署使用自動化部署工具（如Chef、Capistrano），做到一鍵部署；

　　使用CI（GitlabCI）進行自動化測試、自動構建、構建結果通知、自動部署、自動打包上傳app package，達到DevOps的自動化；

　　服務使用健康監控（如Monit，God），自動監測服務健康並自動重啟服務；

　　一句話就是儘量把重複的工作丟給機器去做，人力應該專注在機器解決不了的地方。

　　協作清晰化- 讓你知道什麼時候要去找誰做什麼

　　為了解決協作清晰問題，我們使用3種管理方法：

　　·團隊共享日程表

　　·團隊協作（非特定專案）任務管理

　　·具體的專案管理佈告板

　　一個專案開發時必定會定下一些關鍵的時間節點，如何時開會、開發完成、會議演示、正式上線；公司內人員活動變化，如公共節假日安排、團建、面試安排、團隊成員生病請個假什麼的等等。

　　在團隊中清晰透明、避免衝突。具體做法使用GoogleCalendar進行日曆共享，客戶端使用MacCalendar檢視，約定好事件的標題格式“[公司名-專案名] 事件類別: 事件標題”。

　　在推行新制度時，使用流行的服務和系統自帶的工具，可降低推行阻力。

　　日曆只能也只應該記錄事件標題和日期時間，更具體的內容，我們在Trello上建了一個board來進行管理，如我們的團隊分享安排、團建安排、假期的安排等。

　　至於更具體的專案開發任務，可使用獨立專案管理工具

　　6. 情緒管理

　　是人就會有情緒，瞭解員工的情緒問題也是管理的日常之一。在公司還沒有強大到有專職的“程式設計師鼓勵師”時，也只有親身上陣，我推行了3種方式：

　　·員工一對一談話- 聊天是舒緩情緒很簡單有效的一種方式，無論工作問題、生活問題，都可以坐下來面對面聊一聊，討論下解決方法

　　·員工年度調查- 有些話不適合、不方便當面說的，那麼可以寫下來，，收集對工作流程、工作環境、薪資待遇、公司發展建議等

　　·戶外團建活動- 離開工作環境人的情緒會得到放鬆，為此我擬訂過團隊建設活動計劃

　　專案管理要注意三點：

　　·需求清晰- 要做什麼，做給誰用，做成什麼樣

　　·任務清晰- 安排什麼人，在什麼時候，具體做什麼

　　·節點清晰- 要在什麼時候做完

　　針對以上這3點我制定了以下文件、規範：

　　·明確需求- [PRD文件規範]

　　·明確任務- [Trello使用規範]

　　·明確節點- [Agenda]

　　文件規範

　　PRD（產品需求文件），相當於是產品的工程設計圖紙。一份PRD應該包括：產品說明文件、資訊架構圖、功能結構圖、邏輯流程等。

　　當整理過一份完整的PRD後，其實已經對產品的邏輯性、合理性做了一次梳理，再傳達到開發團隊手裡時，能有效減少返工、無效需求的“折騰”。

　　Trello規範

　　是個看板風格的協作工具，上手簡單。由於Trello本身十分鬆散靈活，100個團隊有100種用法，因此為了方便統籌管理，我制定了一些使用流程並整理成規範文件，包含對list、label使用以及card生命週期的流轉，讓每個任務從需求轉化為任務，分配、評估、開發、部署、測試、上線，意圖讓每一步都清晰可預期，參與者之間協作配合清晰可見。

　　專案管理佈告版也會對客戶（外部客戶或其它部門）開放，希望從一開始大家就可以參與到日常開發流程中，掌握專案開發進度，也方便收集對需求討論、BUG反饋，以及分配一些他們要配合的工作，讓協作內外貫通。

　　Agenda

　　一個專案開發，需要定一些時間節點，如什麼時候正式立項，以便專案經理可以召集開發團隊、召開立項會議；什麼時候做交付演示，以便讓QA工程師可以準備使用者故事；什麼時候正式上線，以便專案組技術組長可以準備交付文件；時候做上線推廣以便運維人員可以做好伺服器壓力測試調整伺服器配置。

　　前面在說如何解決團隊協作清晰化中，提到了使用“團隊日曆共享計劃”。因此要求專案經理給每個專案新增2種事件型別，一個是CHECKPOINT（檢查點），一個是DEADLINE（最後期限）。

　　CHECKPOINT是階段性的時間節點，DEADLINE是當前版本最終的交付限期；一個開發版本內可以有多個CHECKPOINT，但只有一個DEADLINE。

　　做事應有始有終，我要求每個專案的每個大版本開發，都要定一個DEADLINE（最後期限），期限是構成目標的要素，沒有期限則沒有目標，沒有目標何從談管理？

　　CHECKPOINT則是一些階段性的目標，到達一個DEADLINE之前，可以有多個CHECKPOINT；一個CHECKPOINT可以是任何關鍵事件，如階段演示、交付演示，可安排階段小結會議來討論技術問題調整開發計劃。

　　個人管理

　　在日常工作中，往往又有一些個人的自我管理&代辦事項。如某項技術調研、培訓文件準備等不適合放入協作的任務列表的，也要管理起來，做法如下：

　　·不需要協作的，放入Wunderlist（可跨多終端）;

　　·需要team範圍知曉的、有明確日程安排的，放Agenda;

　　·跟具體專案相關的，放在對應的專案trello board

　　控制節奏

　　專案開發有如組織團隊賽跑，需要控制好節奏，什麼時候要留力調整速度，什麼時候要加速衝刺，都應該有規劃。

　　根據這些年來的專案開發經驗，我整理了一個開發流程規範，劃分出幾個階段，每個階段有主要參與的角色及其主要任務、有輸入輸出的結果，以便專案參與者明確自己角色的任務。

　　- 選定專案管理框架/風格：Kanban + Scrum

　　- 選定專案管理工具：- 預設：Trello + Scrum Extension

　　- 其他：Redmine，Teambition，Worktile，Tower

　　- 角色安排：專案經理，產品經理，專案組長，開發，測試，運維- 流程安排：

　　1. 需求確定

相關推薦