- 相關(guān)推薦
如何做好創(chuàng)業(yè)公司的技術(shù)負(fù)責(zé)人
技術(shù)負(fù)責(zé)人主要負(fù)責(zé)帶領(lǐng)技術(shù)團(tuán)隊更好的支持業(yè)務(wù)發(fā)展，對項目的構(gòu)建完成至關(guān)重要。那么，如何做好創(chuàng)業(yè)公司的技術(shù)負(fù)責(zé)人呢?
如何做好創(chuàng)業(yè)公司的技術(shù)負(fù)責(zé)人
請善待原有技術(shù)團(tuán)隊
這個產(chǎn)品目前融資了，而原有技術(shù)團(tuán)隊肯定付出了很多，也許他們技術(shù)能力并不突出，也可能聽不懂你的技術(shù)術(shù)語，也沒有做過高負(fù)載的網(wǎng)站。
但是他們肯定足夠辛苦，因為一直在默默付出，對待他們要抱著幫助的心態(tài)，不要一上去就提出批評或者質(zhì)疑，不要提擴(kuò)展性、可維護(hù)性這樣很虛的概念，而要了解目前遇到了什么難題，你能夠坐下來仔細(xì)和他們分析，并實實在在幫助解決問題，技術(shù)人員都很單純，你幫助了他們，就會服你，會尊重你。
假如技術(shù)負(fù)責(zé)人不能幫助他們，那就不要去添亂，比如用行政的命令要求他們遵守代碼規(guī)范，畫架構(gòu)圖，進(jìn)行代碼審查，不要有高高在上的感覺，你過來是解決問題的，而不是來生產(chǎn)制度的。
就算你看到了技術(shù)團(tuán)隊有很多問題，也要逐步的去優(yōu)化，因為在現(xiàn)階段，原有團(tuán)隊是最了解目前的技術(shù)組成，不要全部推翻，也不要用新來的人去替代他們，尊重他們，幫助他們，才是最好的方式。
整鍋挖來一個團(tuán)隊需要慎重
很多公司負(fù)責(zé)人找技術(shù)負(fù)責(zé)人的一個標(biāo)準(zhǔn)，就是看這個人的人脈，能不能找到很多技術(shù)人員，快速搭建技術(shù)團(tuán)隊，這個思路其實是沒問題的，因為公司負(fù)責(zé)人需要放權(quán)，專業(yè)的事情交給專業(yè)的人去做，可是假如技術(shù)負(fù)責(zé)人招的人都是原來的朋友、同事，形成家族式技術(shù)團(tuán)隊，那么就要警惕了。
首先這個用人成本非常高，招來的人并不完全是因為技術(shù)負(fù)責(zé)人的個人魅力而來的，他需要平衡是否值得，所以高工資成為必然，當(dāng)然假如確實是高水平的技術(shù)人才，這也是合理的。
其次以關(guān)系這種方式引進(jìn)的員工，技術(shù)水平肯定良莠不齊，很多人因為和技術(shù)負(fù)責(zé)人良好的關(guān)系而進(jìn)來的，更要命的是技術(shù)負(fù)責(zé)人引進(jìn)人只是為了證明他的人脈那就危險了，所以技術(shù)負(fù)責(zé)人只要覺得一個人聽話，這個人可能就會被引進(jìn)，而不是以技術(shù)能力而衡量了。
另外一般技術(shù)負(fù)責(zé)人的年齡可能不小了，而必然原來的同事年齡也不小了，可能他們原來是技術(shù)人才，可隨著年齡的提升，他們可能是個“技術(shù)管理者”，而失去了編碼能力，對于創(chuàng)業(yè)團(tuán)隊來說這是非常不好的事情，創(chuàng)業(yè)團(tuán)隊其實更需要業(yè)務(wù)開發(fā)人員。
家族式管理的弊端
在特定的時間，家族式管理很有用，因為技術(shù)人員任何的行為都是建立在幫助技術(shù)負(fù)責(zé)人的角度，所以干勁會很足，對于技術(shù)負(fù)責(zé)人來說就更好了，不用動員，不用講管理技巧，只要建立兄弟之間的關(guān)系就行了，任何事情都能搞定。
假如這些兄弟確實技術(shù)能力很強，那么技術(shù)體系可能會很好，假如技術(shù)能力不強，設(shè)計和開發(fā)出的東西沒有任何的審查，技術(shù)負(fù)債就會很多，而技術(shù)負(fù)責(zé)人本來的職責(zé)不就是掌控技術(shù)質(zhì)量嗎?你完全放開，要你何用?
家族式團(tuán)隊很有可能和原有團(tuán)隊產(chǎn)生摩擦，比如原有團(tuán)隊感覺受到了排擠，很有可能處處不配合，而新進(jìn)團(tuán)隊可能為了有更多的話語權(quán)，會搶班奪權(quán)，所以這兩個團(tuán)隊就為了私利，不會專注于技術(shù)，內(nèi)耗會很嚴(yán)重。
這種事情就很多，比如某個公司，新來的技術(shù)負(fù)責(zé)人帶來了自己的團(tuán)隊，并且都是級別很高的職位，而老同事感覺這些人啥都不懂，什么也解決不了，而新來的團(tuán)隊又各種的變革，導(dǎo)致互相利益不平衡，很多老同事走了。
請先進(jìn)行技術(shù)方案的設(shè)計
對于一個剛來的技術(shù)負(fù)責(zé)人來說，有許多工作，比如組建團(tuán)隊、了解產(chǎn)品，但更重要的是設(shè)計靠譜的技術(shù)方案。
首先要了解系統(tǒng)存在的問題，要了解產(chǎn)品未來的走向，要了解技術(shù)團(tuán)隊的現(xiàn)狀，針對這三點，你需要親自操刀，設(shè)計一個針對目前最優(yōu)的技術(shù)方案。
為什么要親自呢，因為你是技術(shù)負(fù)責(zé)人，不了解技術(shù)問題，就無法進(jìn)行技術(shù)管理，親自設(shè)計了，才能有針對性的去解決問題，將來系統(tǒng)遇到瓶頸，就能更好的優(yōu)化或者重新設(shè)計。
不要用各種理由不去做這個事情，在早期這很重要。
不要過度追求專業(yè)化
其實在創(chuàng)業(yè)公司，一般追求小而快的概念，但是很多從大公司出來的技術(shù)負(fù)責(zé)人充滿激情，任何事情都想追求專業(yè)化，這可能會出現(xiàn)很多問題，這里舉幾個例子。
存在很多沒有意義的技術(shù)崗位，比如現(xiàn)在很多產(chǎn)品并沒有多少的用戶，可非要搞數(shù)據(jù)挖掘，很多數(shù)據(jù)通過簡單的 Shell 腳本就能解決，可專業(yè)的數(shù)據(jù)挖掘崗位要求并不低，從成本和效益看，并不建議有。
喜歡造輪子，在創(chuàng)業(yè)團(tuán)隊，其實應(yīng)該多用開源的解決方案，現(xiàn)在發(fā)現(xiàn)很多公司喜歡自己實現(xiàn)或?qū)υ熊浖鰯U(kuò)展，假如沒有特殊原因，應(yīng)該用成熟的解決方案，原因第一就是研發(fā)成本，第二就是這個開發(fā)成本會很長，第三就是穩(wěn)定性有待考量。
過度設(shè)計，就是設(shè)計的方案不結(jié)合目前的實際情況，考慮的太復(fù)雜，所以實現(xiàn)的也特別復(fù)雜，和造輪子一樣，也存在同樣的浪費，其實過度設(shè)計到還好，就怕錯誤設(shè)計，比如我原來單位，非覺得 MySQL 性能不好，要加一層 Memcached 緩存，最后設(shè)計并線上使用發(fā)現(xiàn)后，緩存命中率非常低，白白浪費了大量服務(wù)器，損耗了性能，并增加了系統(tǒng)的復(fù)雜性。
不要有開發(fā)語言歧視，比如前端業(yè)務(wù)層用 PHP，后端數(shù)據(jù)層用 Java，性能沒有想象的那么夸張，這也是細(xì)分崗位的一種缺陷。
專業(yè)化的反面其實就是技術(shù)負(fù)債，上面也只是簡單的說下，有很多的最佳實踐指導(dǎo)，想表明的就是太專業(yè)化是對效率的最大打擊(時間、成本等等)，我原來也遇到很多類似的情況，這個傷害分為兩個階段，第一階段就是短期的一錘子傷害，比如說技術(shù)方案上線了，浪費了一些時間和成本，但是這個浪費是固定的，可衡量的。
第二階段就非常難衡量了，為早期的決策還債，比如說原來的技術(shù)方案上線后，后期開發(fā)特別難擴(kuò)展，維護(hù)也非常困難，累計起來是對生產(chǎn)力的極大打擊，成本非常昂貴。
招人要慎重
關(guān)鍵詞就是數(shù)量和質(zhì)量，沒有合適的情愿不招。
在創(chuàng)業(yè)團(tuán)隊，項目一個接著一個，很容易造成一個假象，開發(fā)人員不夠，所以就大量的去招人，這是非常不成熟的行為，尤其假如這個技術(shù)團(tuán)隊沒有太強的最佳開發(fā)實踐，新來的人員可能會很茫然，各有各的開發(fā)習(xí)慣和模式，會導(dǎo)致 1+1 < 2 的現(xiàn)象產(chǎn)生。
人一多，分工就要細(xì)化，一細(xì)化協(xié)作就會產(chǎn)生一定的問題，所以招人要控制數(shù)量。
第二就是重視質(zhì)量，質(zhì)量這個詞每個人都有自己的標(biāo)準(zhǔn)，我核心的觀點就是情愿使用一個技術(shù)底子扎實的畢業(yè)生，也不愿意使用一個有多年開發(fā)經(jīng)驗但無技術(shù)底蘊的人。
一個沒有技術(shù)體系的開發(fā)人員總有一些瓶頸和不好的習(xí)慣，會有很多累。
不了解公司負(fù)責(zé)人
很多公司負(fù)責(zé)人找技術(shù)負(fù)責(zé)人的時候，都是求才若渴，目標(biāo)就是希望這個人去搞定技術(shù)事宜，可在頭腦中并沒有衡量標(biāo)準(zhǔn)，一切都是變化的。
對于一個技術(shù)負(fù)責(zé)人來說，可以天天和他聊，告訴他架構(gòu)的重要性，人員的重要性，這些確實很重要，但并非必要性，對于公司負(fù)責(zé)人來說他其實就關(guān)注開發(fā)速度、穩(wěn)定性、產(chǎn)出，他并不關(guān)心深層次的技術(shù)內(nèi)部是如何運轉(zhuǎn)的。
舉個我遇到的情況，原來一個同事去一個公司做負(fù)責(zé)人，他天天搭基礎(chǔ)，優(yōu)化系統(tǒng)，后來不知道什么原因走了，而產(chǎn)品負(fù)責(zé)人這么評價他「來這么久一個產(chǎn)品也沒上線」。
這個例子對技術(shù)人員應(yīng)該很具有打擊性。
不要有求必應(yīng)
和技術(shù)合作最多的就是產(chǎn)品人員，個人覺得產(chǎn)品人員思維有點發(fā)散，做任何事情都比較著急，天天思考這個功能，那個功能;一個簡單的數(shù)據(jù)需求就問技術(shù)要不要弄個后臺出來。
反正一刻也不會讓你閑著。
對于一個成熟的技術(shù)負(fù)責(zé)人來說，不能什么都快速答應(yīng)，因為這是對自己的傷害，第一開發(fā)人員就算多一倍也會不夠，需求會源源不斷的來;第二產(chǎn)品人員很多情況會考慮不成熟，假如你完全按照他們說的去設(shè)計，方案會非常復(fù)雜，有的時候邏輯性也會顯得有問題，會讓系統(tǒng)很難有效的持續(xù)運轉(zhuǎn)。
第三有時候人工完成的時間比開發(fā)一個系統(tǒng)完成的時間少得多，所以少開發(fā)一些無意義的腳本或后臺，比如剛開始產(chǎn)品人員覺得這個數(shù)據(jù)很重要，過了幾天就會突然覺得沒用了。
這樣的例子很多很多，我的意思并不是不去配合產(chǎn)品人員，而是從自己專業(yè)角度出發(fā)，給出合理的意見，當(dāng)然需要避免激化矛盾。
不要依賴測試
在創(chuàng)業(yè)團(tuán)隊，由于開發(fā)時間要求特別高，開發(fā)人員在評估時間的時候，特別喜歡加上測試時間，等同于拿測試時間完成其開發(fā)時間，這是一種非常不好的行為。
比如說一個項目開發(fā)時間要 5天，測試時間要 5 天。
看上去好像開發(fā)時間只占一半(開發(fā)人員好像很高效)，但實際上測試時間開發(fā)人員肯定還在開發(fā)，給測試人員的是一個半成品。
另外開發(fā)人員知道有測試人員會測試出問題、會把關(guān)，初期的開發(fā)質(zhì)量肯定不高，這種案列見過很多。
所以不要變現(xiàn)的用測試時間彌補開發(fā)時間，有可能的話，開發(fā)人員自己負(fù)責(zé)測試，當(dāng)然這個實際操作起來有困難。
[如何做好創(chuàng)業(yè)公司的技術(shù)負(fù)責(zé)人]
【如何做好創(chuàng)業(yè)公司的技術(shù)負(fù)責(zé)人】相關(guān)文章：
創(chuàng)業(yè)公司如何創(chuàng)新08-28
四個案例告訴你如何做好創(chuàng)業(yè)公司的運營07-31
創(chuàng)業(yè)公司如何競爭和如何虧損？06-22
創(chuàng)業(yè)公司應(yīng)該如何招人？07-31
創(chuàng)業(yè)公司如何競爭和如何虧損？(2)07-07
怎樣做好創(chuàng)業(yè)10-01