上篇文章《乙個人被提拔，不僅僅是能力，而是信任》 中分享了兩個點：
什麼樣的工程師，容易被提拔？
當被提拔到一線管理者後，你的初衷是什麼？
這篇文章分享 一線技術管理者 究竟在管什麼事？
咱們從一次完整專案的發布說起，一次完整專案的發布，大概需要經過這幾個大的節點：
專案立項 -> 需求評審 -> 視覺稿評審 -> 技術評審 -> 專案啟動 -> 開發 -> 聯調 -> 測試 -> 發布
有句話是這麼說的，通過控制過程質量，來保證結果質量。
那麼，一線管理者要做的就是保證每個節點的質量，來保證整個專案的質量。
怎麼保證？往下看。
技術評審規範
在技術評審前要熟悉產品同學提供的產品文件、業務流程圖、互動原型圖，反覆與產品同學確認，在雙方達成一致的情況下，再設計技術方案。
設計技術方案要從 總體 到 區域性 ，做到面面俱到。
總體：區域性：
當技術方案確定了，我們就確定了：
當技術方案確定了，需要輸出文件：
**風格規範
雖然**風格並不影響程式的執行，也不會給程式帶來潛在的危險，但是一段好的**風格，閱讀起來能讓人賞心悅目，特別是閱讀別人的**，就像自己寫的一樣。
**風格規範達成一致後，一定要落實到文件上！！！方便其他同事進行 codereview 時使用。
**開發規範
**管理規範
常用的**管理工具：git、svn。
工具的使用，大家都知道，就不多說了，約定一些基礎的規範。
(scope)：，比如：fix(首頁模組)：修復彈窗 js bug。
type表示 動作型別，可分為：
fix：修復 *** bug
feat：新增 *** 功能
test：除錯 *** 功能
style：變更 *** **格式或注釋
docs：變更 *** 文件
refactor：重構 *** 功能或方法
scope表示 影響範圍，可分為：模組、類庫、方法等。
subject表示 簡短描述，最好不要超過 60 個字，如果有相關 bug 的 jira 號，建議在描述中加上。
codereview 規範
說實話，由於種種原因，自己實施的並不好。
codereview 檢查哪些問題？
健壯性檢查
重用性檢查
安全性檢查
效能檢查
codereview 如何執行？
實施期
事後跟蹤
如上就是一線技術管理者要做的事，這些只是 管事 當中的一小部分。
我猜想，有些讀者可能會有這個問題：哪來的時間呀？業務**天天加班都搞不完，哪些時間搞這些？
這個問題... 首先要承認在大部分的公司中，業務**是剛需，因為是靠這些業務掙錢的，需要快速上線占領市場的。
當隨著公司的發展，技術人員的擴充，規範肯定要慢慢建立起來的，否則就會出現這樣那樣的問題。
如果公司就幾名技術人員，可以先不用搞這些，優先快速發展業務吧。
當各位發現有哪些地方不對 或 不完善的地方，歡迎批評指正。
如何做一名技術管理者
曾在 遊戲規則與溝通 一文中我提到，要規範化，有效溝通，提高團隊的效率和質量。時隔一年多，再來談談有了規範，各項工作正規後如何做技術管理。以下所提到的一切的前提是 1 中小企業或創業型公司等，至今我依然認為中小企業不適合搞重型管理方法 2 技術上不要太業餘。擺正自己的位置 技術管理的核心就是為開發人...
如何做一名技術管理者
曾在 遊戲規則與溝通 一文中我提到，要規範化，有效溝通，提高團隊的效率和質量。時隔一年多，再來談談有了規範，各項工作正規後如何做技術管理。以下所提到的一切的前提是 1 中小企業或創業型公司等，至今我依然認為中小企業不適合搞重型管理方法 2 技術上不要太業餘。擺正自己的位置 技術管理的核心就是為開發人...
技術敏感度 基層技術管理者必備
文章 一說到管理者的能力特質，我們馬上會聯想到溝通 授權 決策等能力。然而，對於軟體開發活動中的基層技術管理者 team lead line manager等 我想指出被極為忽視的另一種重要能力 技術敏感度。對於基層技術管理者來說，何為技術敏感度？技術敏感度表現為 1 工程師解釋技術問題時，能快速理...