在一個創業型公司作技術總監應該幹什麼？

2016年10月19日從新修訂

********************************************************************************************************************

離開大公司到創業小公司擔任技術總監的崗位2年多了，時間不長，也沒取得什麼成績，但做爲以軟件項目服務爲主的公司，大大小小也負責交付了八、9個項目。

這個過程當中遇到了很多問題和困難，想談談我的對這個崗位的理解，不算什麼有價值的東西，就當給本身作點總結吧。

對於軟件公司，不一樣於平臺型的互聯網企業；咱們仍是會以項目的形式進行交付管理，所以通用的看能夠分爲售前、售中和售後三個階段。

 

一、項目前期（售前階段）：

這個階段在有必定規模的企業裏一般是不須要研發人員參與的，由專門的市場、售前人員完成，當產品資料還不完善時可能少許技術支持。但在創業型小公司，從老大開始接洽這個項目開始，做爲技術主管你就須要參與了。屬於這個崗位的主要的工做我認爲有以下一些：

　　1.一、需求澄清：在識別出客戶的關鍵需求的前提下，引導並與客戶（或甲方）梳理出一個有利於雙方的需求邊界。這個階段是很是重要的，也對我的在業務上的理解有必定要求，須要能給客戶必定的信賴感，若是以前不瞭解這個行業，提早作作準備。千萬不要去「扯皮」（在大公司滾過幾年的人應該對這個詞都有體會），在大公司裏只要你有本事把皮球踢出去，你就牛X，但在創業型公司，每一天都是錢、是成本，跟客戶扯皮就是找屎。

     忽然想起原來公司一個笑話，只要你有本事把問題單扯皮到不歸你改，這個問題單就算被你close了，因此某牛人能夠一行代碼不寫改掉N個問題單。這個笑話懂不：）

     1.二、初步的產品架構：這裏是一些high level的架構，好比移動端採用原生、混合仍是純H五、要不要上負載均衡、數據庫要不要上主備、是否須要獨立緩存、是否須要引入第三方平臺，如支付、短信、音視頻、推送等等。這裏的工做，並非嚴格意義上的指導研發，而主要是爲了預估工做量和實施成本。

　　1.三、技術選型：結合團隊自身和初步產品架構的判斷’完成語言、數據庫、中間件等選型。技術選型之因此在售前階段須要定下來，主要是兩方面考慮，一方面是不少政企類項目須要提早出項目建議書或投標文件，裏面會對這些有章節表述要求；另一方面是它也影響你內部團隊資源的調配和工期的判斷。這裏仍是要有必定的權衡的，對於某些工期要求不重，需求相對簡單清晰的，能夠適當用下新的技術平臺方案，好比以前大可能是JAVA的項目，能夠考慮試一下node、go。

　　1.四、關鍵技術風險：對於項目中的關鍵風險點進行識別，若是存在特別大的風險，好比複雜引擎、音視頻服務等，不是短時間能儲備充分的，要及時把項目close掉。對於某些可承受的風險，在這個階段也能夠提早安排空餘人員進行儲備。

　　1.五、工做量評估：工做量評估及開發計劃初步制定，支撐商務談判和合同簽定，簡單點講告訴大家老闆，多少人天能搞定：）

二、項目中期（售中階段）

　　2.一、架構設計：在售前階段你可能作了一個初步的產品架構，在這個時候就要細化了。對於不少項目而言，可能最開始的時候就是一個單機系統，但若是客戶是一個互聯網平臺項目，你仍是要對將來有所預留。我我的的理解是在這個階段核心仍是業務子系統的劃分和數據庫的設計，其餘不少東西后面都好說。比如，你一開始用戶管理和訂單管理就是混在一塊兒的代碼，之後就無法拆，給你用什麼RPC都沒用。數據庫設計的時候，權限、角色、角色控制表都沒有規劃，後續想作細粒度的權限控制，也無法作。這些纔是軟件的核心，至於什麼要不要動靜分離、要不要上緩存、要不要上服務治理，我以爲均可以等等業務發展再說。

　　2.二、制定詳細的開發計劃：協調終端、前端、後端（大的項目也多是各個子系統）之間的交付，避免彼此的功能存在依賴而阻塞，同時也要可以照顧到前期識別出的關鍵需求:。這裏必定要先定接口，這件事情最好技術主管親自作。開發能夠採用敏捷的迭代，讓進度可控，問題提早暴露。

　　2.三、核心問題解決；代碼框架、關鍵代碼、阻塞性問題等等；這點我感觸最深的就是一個詞「兜底」。由於在這裏，你沒有別人能夠求助了，反過來你是你下面兄弟求助的對象，關鍵，這些時候你還不能讓你的下屬和客戶看出來。我本身寫到這裏的時候，回想起不少事情，還真是有點心有餘悸的，真是打落牙齒往肚子裏吞啊.....

　　2.四、對外控制客戶的預期：（這個時候項目合同已定，能夠適當的和客戶談談困難，給本身的交付留有餘地）；客戶必定會有不少臨時的需求，好比何時要提早演示給某某投資方或領導啦，或者臨時接了什麼單子要某個功能提早上啦。這個時候儘量擋住，別信他的鬼話，項目沒找大家的時候，一年半載都拖過去了，這會晚個10天半個月，還就錯過什麼關鍵機會窗，鬼扯！實在擋不住，就和他說要加錢的，100%擋住僞需求。

　　2.五、對內控制項目的進度和質量：以我我的這點經驗而言，比較好的實踐有，早例會和周例會（可以施加必定的進度壓力，同時也提高團隊歸屬感），代碼檢視（針對複雜業務代碼頗有效，捎帶也作了團隊技術提高、編程規範啥的）、持續集成（平臺類項目很重要，不然版本發佈進度跟不上）。

     我之因此把這部分工做放到這個階段的最後，並不是它不重要，而是有些從大平臺出來的人（特別是管理類），總喜歡一上來就談這方面的理念和思路，說的頭頭是道。以我我的的經驗是省省，且不說削足適履是否合適，在你沒能解決一些關鍵核心問題以前，真沒人會願意聽你叨叨這些有的沒的。

三、項目後期（售後階段）

　　3.一、妥善處理客戶需求變動，保證不過多增長項目成本，而又不影響後續款項的收取；

　　3.二、版本管理，每次發佈後的版本要能在配置庫可回溯，出了問題可回滾；