ZKIZ Archives


初來乍到,如何做好創業公司的技術 Leader?

來源: http://www.iheima.com/zixun/2017/0327/162157.shtml

初來乍到,如何做好創業公司的技術 Leader?
MacTalkMacTalk

初來乍到,如何做好創業公司的技術 Leader?

人從一種狀態到另一種狀態的時候,先思考的不應該是如何快速去做,而是如何避免犯一些錯誤。

本文由MacTalk(微信ID:sagacity-mac)授權i黑馬發布,作者虞衛東&MacTalk

2017年3月,一段新的旅程開始了,我加入了一家新公司 —— 極客邦科技。每次到新公司,都會涉及到建立團隊的事情。二爺在杭州抱著吉他嘲笑我,辛苦兩年建團隊,一朝回到解放前。又得重來一次了吧?我說,那你吉他能彈個單弦的曲子嗎?二爺消失在了微信的時間線上。

其實每次建團隊都是一個有趣、有挑戰的新過程,就像春天里種樹,雖然時令和樹苗是一樣的,但每顆小樹的成長方式都千姿百態,因為土壤不同,空氣不同,養分不同,最後結出的果實也不同。這次就更不同一些,因為產品、技術和設計都需要理順或重建,還要能快速推出新產品,更有挑戰,也更有樂趣。

小夥伴們也沒閑著,今天極客邦旗下公眾號「聊聊架構」的主編扔給我一篇文章,是作者的投稿,說,池哥,這篇可能對你和你的讀者有幫助,你發吧。我讀完之後,感覺確實不錯,文章立意和思路都非常清晰有效,於是首發在 MacTalk,也希望你能喜歡。

作者介紹

虞衛東,新浪網高級技術經理,前趕集網移動事業部技術總監,主要供職於新浪網,經歷所有新浪博客技術演變,有十余年的互動類產品開發經驗,熟悉 LAMP 平臺 和 Python 的開發,提倡益軟件開發理論。

以下是正文。

自己閑的時候總是思考一個問題,將來有一天我成為一家創業公司的技術負責人,哪些錯誤應該是避免犯的呢?人從一種狀態到另一種狀態的時候,先思考的不應該是如何快速去做,而是如何避免犯一些錯誤,這就是本文的出發點。

首先為了避免太跑題,先設置一個限定,一個創業團隊近期融了一筆錢,需要快速的搶占市場,需要有一個技術負責人(全局負責)來帶領技術團隊更好的支持業務發展,這個創業團隊原來的技術團隊人員沒有超過 5 人。

請善待原有技術團隊

這個產品目前融資了,而原有技術團隊肯定付出了很多,也許他們技術能力並不突出,也可能聽不懂你的技術術語,也沒有做過高負載的網站。但是他們肯定足夠辛苦,因為一直在默默付出,對待他們要抱著幫助的心態,不要一上去就提出批評或者質疑,不要提擴展性、可維護性這樣很虛的概念,而要了解目前遇到了什麽難題,你能夠坐下來仔細和他們分析,並實實在在幫助解決問題,技術人員都很單純,你幫助了他們,就會服你,會尊重你。

假如技術負責人不能幫助他們,那就不要去添亂,比如用行政的命令要求他們遵守代碼規範,畫架構圖,進行代碼審查,不要有高高在上的感覺,你過來是解決問題的,而不是來生產制度的。

就算你看到了技術團隊有很多問題,也要逐步的去優化,因為在現階段,原有團隊是最了解目前的技術組成,不要全部推翻,也不要用新來的人去替代他們,尊重他們,幫助他們,才是最好的方式。

整鍋挖來一個團隊需要慎重

很多公司負責人找技術負責人的一個標準,就是看這個人的人脈,能不能找到很多技術人員,快速搭建技術團隊,這個思路其實是沒問題的,因為公司負責人需要放權,專業的事情交給專業的人去做,可是假如技術負責人招的人都是原來的朋友、同事,形成家族式技術團隊,那麽就要警惕了。

首先這個用人成本非常高,招來的人並不完全是因為技術負責人的個人魅力而來的,他需要平衡是否值得,所以高工資成為必然,當然假如確實是高水平的技術人才,這也是合理的。

其次以關系這種方式引進的員工,技術水平肯定良莠不齊,很多人因為和技術負責人良好的關系而進來的,更要命的是技術負責人引進人只是為了證明他的人脈那就危險了,所以技術負責人只要覺得一個人聽話,這個人可能就會被引進,而不是以技術能力而衡量了。

另外一般技術負責人的年齡可能不小了,而必然原來的同事年齡也不小了,可能他們原來是技術人才,可隨著年齡的提升,他們可能是個“技術管理者”,而失去了編碼能力,對於創業團隊來說這是非常不好的事情,創業團隊其實更需要業務開發人員。

家族式管理的弊端

在特定的時間,家族式管理很有用,因為技術人員任何的行為都是建立在幫助技術負責人的角度,所以幹勁會很足,對於技術負責人來說就更好了,不用動員,不用講管理技巧,只要建立兄弟之間的關系就行了,任何事情都能搞定。

假如這些兄弟確實技術能力很強,那麽技術體系可能會很好,假如技術能力不強,設計和開發出的東西沒有任何的審查,技術負債就會很多,而技術負責人本來的職責不就是掌控技術質量嗎?你完全放開,要你何用?

家族式團隊很有可能和原有團隊產生摩擦,比如原有團隊感覺受到了排擠,很有可能處處不配合,而新進團隊可能為了有更多的話語權,會搶班奪權,所以這兩個團隊就為了私利,不會專註於技術,內耗會很嚴重。

這種事情就很多,比如某個公司,新來的技術負責人帶來了自己的團隊,並且都是級別很高的職位,而老同事感覺這些人啥都不懂,什麽也解決不了,而新來的團隊又各種的變革,導致互相利益不平衡,很多老同事走了。

請先進行技術方案的設計

對於一個剛來的技術負責人來說,有許多工作,比如組建團隊、了解產品,但更重要的是設計靠譜的技術方案。

首先要了解系統存在的問題,要了解產品未來的走向,要了解技術團隊的現狀,針對這三點,你需要親自操刀,設計一個針對目前最優的技術方案。

為什麽要親自呢,因為你是技術負責人,不了解技術問題,就無法進行技術管理,親自設計了,才能有針對性的去解決問題,將來系統遇到瓶頸,就能更好的優化或者重新設計。不要用各種理由不去做這個事情,在早期這很重要。

不要過度追求專業化

其實在創業公司,一般追求小而快的概念,但是很多從大公司出來的技術負責人充滿激情,任何事情都想追求專業化,這可能會出現很多問題,這里舉幾個例子。

存在很多沒有意義的技術崗位,比如現在很多產品並沒有多少的用戶,可非要搞數據挖掘,很多數據通過簡單的 Shell 腳本就能解決,可專業的數據挖掘崗位要求並不低,從成本和效益看,並不建議有。

喜歡造輪子,在創業團隊,其實應該多用開源的解決方案,現在發現很多公司喜歡自己實現或對原有軟件做擴展,假如沒有特殊原因,應該用成熟的解決方案,原因第一就是研發成本,第二就是這個開發成本會很長,第三就是穩定性有待考量。

過度設計,就是設計的方案不結合目前的實際情況,考慮的太複雜,所以實現的也特別複雜,和造輪子一樣,也存在同樣的浪費,其實過度設計到還好,就怕錯誤設計,比如我原來單位,非覺得 MySQL 性能不好,要加一層 Memcached 緩存,最後設計並線上使用發現後,緩存命中率非常低,白白浪費了大量服務器,損耗了性能,並增加了系統的複雜性。

不要有開發語言歧視,比如前端業務層用 PHP,後端數據層用 Java,性能沒有想象的那麽誇張,這也是細分崗位的一種缺陷。

專業化的反面其實就是技術負債,上面也只是簡單的說下,有很多的最佳實踐指導,想表明的就是太專業化是對效率的最大打擊(時間、成本等等),我原來也遇到很多類似的情況,這個傷害分為兩個階段,第一階段就是短期的一錘子傷害,比如說技術方案上線了,浪費了一些時間和成本,但是這個浪費是固定的,可衡量的。第二階段就非常難衡量了,為早期的決策還債,比如說原來的技術方案上線後,後期開發特別難擴展,維護也非常困難,累計起來是對生產力的極大打擊,成本非常昂貴。

招人要慎重

關鍵詞就是數量和質量,沒有合適的情願不招。在創業團隊,項目一個接著一個,很容易造成一個假象,開發人員不夠,所以就大量的去招人,這是非常不成熟的行為,尤其假如這個技術團隊沒有太強的最佳開發實踐,新來的人員可能會很茫然,各有各的開發習慣和模式,會導致 1+1 < 2 的現象產生。人一多,分工就要細化,一細化協作就會產生一定的問題,所以招人要控制數量。

第二就是重視質量,質量這個詞每個人都有自己的標準,我核心的觀點就是情願使用一個技術底子紮實的畢業生,也不願意使用一個有多年開發經驗但無技術底蘊的人。一個沒有技術體系的開發人員總有一些瓶頸和不好的習慣,會有很多累。

不了解公司負責人

很多公司負責人找技術負責人的時候,都是求才若渴,目標就是希望這個人去搞定技術事宜,可在頭腦中並沒有衡量標準,一切都是變化的。

對於一個技術負責人來說,可以天天和他聊,告訴他架構的重要性,人員的重要性,這些確實很重要,但並非必要性,對於公司負責人來說他其實就關註開發速度、穩定性、產出,他並不關心深層次的技術內部是如何運轉的。

舉個我遇到的情況,原來一個同事去一個公司做負責人,他天天搭基礎,優化系統,後來不知道什麽原因走了,而產品負責人這麽評價他「來這麽久一個產品也沒上線」。這個例子對技術人員應該很具有打擊性。

不要有求必應

和技術合作最多的就是產品人員,個人覺得產品人員思維有點發散,做任何事情都比較著急,天天思考這個功能,那個功能;一個簡單的數據需求就問技術要不要弄個後臺出來。反正一刻也不會讓你閑著。

對於一個成熟的技術負責人來說,不能什麽都快速答應,因為這是對自己的傷害,第一開發人員就算多一倍也會不夠,需求會源源不斷的來;第二產品人員很多情況會考慮不成熟,假如你完全按照他們說的去設計,方案會非常複雜,有的時候邏輯性也會顯得有問題,會讓系統很難有效的持續運轉。第三有時候人工完成的時間比開發一個系統完成的時間少得多,所以少開發一些無意義的腳本或後臺,比如剛開始產品人員覺得這個數據很重要,過了幾天就會突然覺得沒用了。

這樣的例子很多很多,我的意思並不是不去配合產品人員,而是從自己專業角度出發,給出合理的意見,當然需要避免激化矛盾。

不要依賴測試

在創業團隊,由於開發時間要求特別高,開發人員在評估時間的時候,特別喜歡加上測試時間,等同於拿測試時間完成其開發時間,這是一種非常不好的行為。比如說一個項目開發時間要 5天,測試時間要 5 天。看上去好像開發時間只占一半(開發人員好像很高效),但實際上測試時間開發人員肯定還在開發,給測試人員的是一個半成品。另外開發人員知道有測試人員會測試出問題、會把關,初期的開發質量肯定不高,這種案列見過很多。

所以不要變現的用測試時間彌補開發時間,有可能的話,開發人員自己負責測試,當然這個實際操作起來有困難。

這篇文章有點偏理論,每個公司有其特殊的情況,中心想表達的思想就是先考慮不犯錯,然後再考慮更好的改進;在創業早期,追求輕量而不是重量;技術成本非常昂貴,需要效率。

在這個高速發展的互聯網時代,人們總是喜歡快中求快,希望站在別人的肩膀上做自己的架構。很多開發者和架構師花了大量時間研究知名公司的企業架構,把這些資料當個寶,但拿回家後發現並不是那麽回事。究其原因,只能說是參考的架構實踐太多,但了解和領悟的架構知識太少。

道是事物發展的本質規律,術是事物發展的具體途徑。《架構漫談》系列文章其實就是想和大家聊聊架構之道,希望大家能領悟架構的本質,不拘泥於現有的實踐和理論框框,而是以最直接的方式解決問題,無招勝有招。

創業公司
贊(...)
文章評論
匿名用戶
發布
PermaLink: https://articles.zkiz.com/?id=243220

Next Page

ZKIZ Archives @ 2019