從大公司跑到小公司去(團隊建設)
--專案管理學習總結(9)—史上最全網際網路八大技術崗位詳解- https://blog.csdn.net/u012562943/article/details/78312211
網際網路技術崗位詳解,涉及到前段開發、後端開發、移動端開發、大資料、專案管理、測試、運維、技術管理等八大領域。
大部分的HR不會問你崗位專業問題,有一句話是說技術面試看你做事,人事面試看你做人。無非是看你的溝通能力、性格、企業忠貞度、對崗位的熱情等。
建議最好是說自身原因且能讓HR信服的,比如說覺得目前個人發展已經沒有什麼空間,想要在技術上再多歷練提升下自己。回答是積極正面的就好。
-- 1.技術專家路線,成為架構師,優化系統中的瓶頸;
2.專案經理,逐步學會協調各類資源;
3.技術管理方向:技術經理/總監;
4.產品方向:產品經理、產品總監。
5.往運營和市場方向轉型。
站在技術牛人的肩膀上,你會看的更高看的更遠,從而避免很多彎路,彎路過多那是對時間的浪費。
站在技術牛人的肩膀上,將幫你更清晰的規劃自己的職業發展方向。
不斷從你身邊的牛人身上汲取過往的經驗和教訓,找到一個你可以參考的榜樣,去開啟你未來的職業生涯。
> 從一個上市公司的某平臺技術總監,來到新型的O2O公司來做CTO. 感受最深的說下四點。
有長期激勵目標。
經驗能力到了一定程度,就會關注於做的事情有沒有挑戰,有沒有意義。對於我來說,找不到做事的意義和挑戰,便無法激勵自己和團隊,有混日子的感覺,浪費自己的時間。而跳到創業公司,前提就是看好公司發展的方向,加入公司一起努力,這便是長期激勵自己的事業。這便是我們的星辰大海!
之前看到新聞,前幾年還是紅火的世界級企業,突然賣掉裁員。而公司的員工,為了多獲得幾個月補嘗,而樓下拉橫幅抗爭。 雖然我支援這樣的抗爭,但並不希望出現在自己身上。
無平臺光環,需要真正實力
很多人員在原有公司做不錯,但很可能是平臺有光環,有資源。 在你做了正確的事,就取得業績不錯。但在創業公司卻不同,你需要為公司提供資源,推動發展。
以招人來舉例。
在大公司,但只要你和HR 努力,你可以建立一支還不錯的技術團隊(在大公司都不能建立起團隊,創業就不要當技術負責人)。 而創業公司,所有面試中你看得上的,手裡都有很多個Offer, 這時你感受到是,面試者在面試你和公司。你需要說明公司的發展前景,展示團隊的願景,更要展現個人的實力與感召力。
在大公司踏實認真做過的事情,最終都會成為你的經驗和能力,讓你有信心來面對創業的挑戰。
能力越強,空間越大
大公司,有不少做法落後時代,雖然大家都知道不好,但是沒有辦法改變。 比如GitHub發展如火如荼,但有公司還用著SVN. 你去推動Git 的使用,大家會推脫 "SVN不也能用麼,我們還有更重要的事情要做,換GIT的收益有多少?"
做為公司的CTO, 你可以建立符合時代發展的技術價值觀和技術文化。 比如,我在團隊中提倡:
極致: 不論是產品還是程式碼質量,還是使用的工具。 要永遠保持有更高的要求。
透明 : 為工作建立透明的環境,讓所有的人知道你做的事情和貢獻。
透明環境能降低潛規則的出現,保護人才、用好人才。
追求成功
如果創業不能成功,那成就、榮譽、收益都是空談。不成功,將辜負那些追隨自己的兄弟和一起打拼的團隊。追求成功,將以更高的視角來看到工作和問題,能放下一時之得失與創始團隊一起建立更高的夢想。
創業能不能成功,主要看兩點:
第一、方向是否正確
在風口,豬都可以飛上天。 比如,在O2O的風口下,BAT等這樣的大廠都來主動找我們合作,在宣傳推廣方面,我們的成本就少很多了。
第二、 領導者
現在創業者如過江之鯽,有純忽悠、有賺快錢的、有騙投資人錢。這些基本都是坑。創業是比艱難還難的事情。怎可能僥倖成功。領導者是企業的靈魂, 領導者需要,志存高遠, 腳踏實地,鍥而不捨,快速成長!
還好,我選擇公司這兩點都不錯。
選對人,做對事!
什麼不知道怎麼判斷人和事? 那就跟隨你接觸過中最優秀那個人,這樣成功的概率高多了。
》去小公司做CTO,那麼小公司能說清CTO的職責定義嗎?
CTO是技術高階管理,是包括組建團隊,制定技術方向,規範,人才梯隊,甚至關注這個行業技術趨勢,大部分時間主要是管理和溝通,並非編碼,如果對方的職責定義裡面仍然包含了編碼,說明這個崗位也不是純CTO,而是cto兼程式設計師,兼...
說實話,關鍵看你怎麼看待這件事,是在意title,還是薪資,還是未來成長空間,還是能學到東西,還是什麼?
看重任何一項,小公司有大公司缺的,你都可以去。但title一定很虛
》分享一位Google離職工程師的職場轉型體驗,有比較多的細節,希望給題主一些啟發。
1、離開程式設計的舒適區
創業初期籌集資金的時候,我第一次遇到程式設計以外的挑戰。和投資者周旋對一位軟體工程師來說真是一件苦差事,如果你也習慣了坐在自己的工位,僅通過GChat彼此交流。突然之間,我得穿上沒有洞的襯衫參加各種大型會議,並試圖說服在場的人我們能實現不可能的事。
對於工程師來說,承諾一週以後的deadline已經很難了。投資人卻會challenge你承諾今後1~2年的事情,並會在每一個節點問你問題。「真的嗎?」他們中的有人說,「你要做一個AAA遊戲?你怎麼把2G的內容放進瀏覽器?你怎麼讓它有趣?」
幸運的是,多年的軟體工程師生涯賦予了我一項珍貴的技能:直覺。我豪不懷疑我們在做的事情是可行的。一旦我自己深信不疑,讓其他人相信也就輕鬆多了。
就像說服投資人,團結新的隊伍也是一項挑戰。幾個月之前,我們決定做遊戲,雖然不知道它會成為什麼樣子,但是開始做是第一步。一位合作的藝術家給我發來了一張遊戲的圖片:一片鬱鬱蔥蔥的草地。我把它做成了36’’x 24’’的大海報,掛在牆上。
從此,無論誰問我他們接下來要幹嘛,我都會指著這張圖說:「只要能讓我們離這裡更進一步。」這是自我驅動型工程師需要聽到的話。我們有一個清晰的目標,正踏踏實實地掛在牆上,我們要做的就是努力實現它。
CTO的職位意味著更多的責任,卻不代表冗長的會議和官僚主義。除了技術,CTO還要承擔更多的管理職能:僱傭合適的員工,解僱不合適的員工,持續地創造和輸出idea,帶著目標團結隊伍。
2、溝通的陷阱
起初,我想當然地以為在這樣一支幾個人的小隊伍,相對於在Google,溝通應該不是問題,但是我錯了。在加入Artillery的頭幾個月,其他的合夥人和我都已經數次激怒了對方。
三位Co-founders的溝通很混亂,一個人說給另一個人,第二個人又傳話給第三個人。作為一名軟體工程師,如果你在一支全是工程師的隊伍,溝通是相對容易的。當這支隊伍混入了其他職位的人,且多於10個,溝通會變得有點棘手。相信我,溝通會比你想象的難,但是必須好好地掌握。
所以我們準備花更多的時間一起籌劃,比如花一個小時坐在房間,清楚地寫出來當下在進行的事情和麵臨的問題。第一次這樣溝通,還不到60分鐘,我們就解決了能想出來的大部分問題——大部分都是由於溝通失誤造成的誤解(!)。從此每週,我們都會開一次這樣的founder’s meeting,並把決議都記在一個長長的Google文件,方便隨時查閱。從此我們再也沒有出現過嚴重的分歧。
但是,僅僅增加溝通的量是不夠的,更重要的是掌握溝通的技巧,提高溝通的效率。剛開始例會的時候,過了30分鐘後,我們才意識到剛才是在用各自不同的話語表達同一個觀點,這種無休止的爭論純粹是浪費時間,
另外,真誠的批評是原則:把自我關在門外,開誠佈公地討論,給彼此最坦誠的反饋。我們的會議中常會聽到這句話:「哦,我不認為它會這樣。」建設性的批判能幫助彼此更好地完善自我。
其次,email也是一個坑。通過email很難傳遞情緒,很容易成為誤解的發源地,會影響情緒,甚至影響表現。同樣的話語,如果是面對面的對話就會有完全不一樣的效果。
分享一個簡單的小技巧:當我懷疑我發出的某條資訊可能會有歧義,我會加一個表情,比如 [mood: agreeable],從而確保傳達出我樂意的態度。如果你也這樣做,你會發現它非常有效,可以讓所有人保持冷靜,避免不必要的爭端。
3、選擇正確的技術
Web開發是一個有創造力的快速發展的世界。各種各樣的新idea和工具層出不窮,似乎換一個新框架或程式碼就能解決你所有的問題。但是作為CTO你要記住,挑選怎樣的技術相當於你花了一筆真金白銀,一旦你做了決定,很可能你就沒有時間和資源再走回頭路了。
在Artillery,我們清楚我們會寫很多的JavaScript,即使大家都懂的,JavaScript有各種讓你不爽的地方 。我們之前有使用過CoffeeScript,它運作的不錯,我們也喜歡它的作者做的大部分決定,所以我們最終選擇了它。然而最關鍵的原因是,我們並不會被困死在CoffeeScript上。如果哪天我們想丟棄它,我們可以將輕量級的CoffeeScript全部編譯成JavaScript,並從那裡繼續前進。這麼做合情合理的,而且成本也很低。
伺服器端的決定就沒有那麼容易。Node.js顯然是我們的首選,它可以輕鬆分享客戶端和伺服器端的程式碼。然而,那個時候Node.js還很年輕,而且它的生態圈也不成熟。當時很難評估Node.js的第三方庫的質量和安全性,有很多相似功能、但又在開發的不同階段的庫。
這讓我們停下來思考了一下。但是經過更多的研究,一件事情提醒了我們:Node.js的更新速度很快。Node.js基於的V8,已經被證明在Google Chrome上跑的又快又幹淨。如果只有一家公司擁有最多值得信任的聰明人在致力於語言,那就是Google。依靠這個框架似乎是一個安全的選擇。Node.js的程式碼新版本是一致的,而且強大的Github社群又提供了頻繁程式碼更新的便利。在仔細的審議後,我們決定用Node.js,現在很慶幸我們做了這個決定。
4、放棄side project
我很喜歡side project,我總是要做點什麼——一個遊戲、一個WebApp,或其他的什麼工具。這是我保持學習,玩兒新東西的方法。但是當Artillery成為現實,我的興趣突然成為我的全職,我該怎麼度過我的空閒時間呢?
我曾經花了一個週末,和一個朋友做一個電商網站的原型。「花不了多長時間的」我記得我還這樣說過,「我只需要用Django、PayPal和一個購物車。」它的確只花了兩天,卻耗盡了我一個禮拜的精力。
從此,我才意識到精神充電是必須的。在其他專案上分腦力讓我在工作中降低了效率。作為CTO,跟上新技術是我的責任,為什麼我還要做那些無益於我提高的事情呢?做外部的專案會給我的正職帶來壓力,對我的合夥人也不公平。
我停掉了side project,創造力和精力又回來了。雖然我有時還是會陷入卡殼,想修復一個bug卻怎麼也辦不到,但是瞭解了生產力低估週期後,我放輕鬆了。如果此時狀態不佳,不如接受它,和周圍的夥伴交流一下,做一些簡單的活兒。這樣總比恐慌、錯過deadline要好。
5、團隊管理太難
開始組建團隊的時候,我們會說很多在Artillery工作的美好願景,包括各種各樣的福利待遇。我們希望用有趣又有意義的工作來吸引最優秀的人才。
於是我們在網站上掛了很多福利:免費午餐、完善的醫療保險、交通報銷、無限的假期、WorkStation預算、從東京買來的遊戲原型手辦……列出這些福利簡單,然而並沒有什麼用。
比如,開始我以為無期限的假期是一個好主意。沒想到似乎給員工帶來了更多的壓力:優秀的員工害怕他們休假太多而不敢提出請求。最後,我們決定還是採取固定期限的帶薪休假模式——既能緩解員工焦慮,又能足量地滿足員工的度假需求。
再比如,自主選擇程式設計裝備帶來了各種奇葩需求:20美元的Razer Goliathus滑鼠墊值不值?我想用自己的筆記本工作,把我的預算花在昂貴的外設上吧!甚至還有員工想要高昂維護費用的組裝系統——至此,我終於確定每個人都應該用Mac OS X——因為它足夠乾淨、簡單。
要解決問題首先要理解福利的實質是什麼。比如裝備福利,它的目的不是無限制地滿足員工的每一個細微的需求,而是為他們提供良好的工作環境,確保沒有人還在使用老舊、遲緩的電腦。
那些員工看似在浪費你的好意,其實並沒有惡意。你得幫助他們理解政策、福利背後的邏輯,他們會做出更好、更謹慎的選擇。
Lan離開Google的原因很簡單:在這裡很難保持衝勁和創造力。在大公司離職工程師中,這樣的理由太常見了,軟體工程師很容易被隔離在業務線外,唯一的任務就是不斷輸出優質的程式碼。
創業不是解決大公司病的靈丹妙藥,選擇加入一家小公司當CTO,意味著生活一半是巨大的自由,另一半是巨大的責任。CTO的工作如此辛苦,會花掉全部的腦力和精力——但為什麼還要選擇呢?
》》 搭環境,搭框架,寫ui,管產品,跑調研...
糾結svn還是git,糾結eclipse還是intellij,糾結github還是gitlab,糾結maven還是gradle...
人與人的信任是一點一點建起來的,即使老闆對你再客氣、再重視、再放權,你也要在初期把溝通和信任建立做為第一優先順序考慮。
雖然是很大的title,但是千萬別太把自己當回事,你對於公司是可有可無的,不管你創造了多少價值。。
》我才明白什麼是真正的軟體工程師。更重要的是,明白了軟體工程中的業務是什麼。這不需要知道更多的程式語言、庫、演算法和設計模式。這是一種思維模式。勤奮、嚴謹、可靠的人際關係和最終犯傻,不僅僅是軟體工程師的必要素質,也是從事研究生院之外的任何職業的必要素質。
花時間來學習新的工具。不僅為了擴充你的抽象知識,而且真正瞭解工具可以幫助你把事情做好。你將很快的從中獲得回報。
學習如何說話。看TED演講,並注意許多經驗豐富的演講中是如何能吸引觀眾十五分鐘,同時講述一個引人入勝的故事的。
當我們談論一個公司的最佳利益時,我們實際上指的是利益相關者的最佳利益。現在真正的問題是:你的CEO或主管認為這些利益相關者有哪些人,以及他們的利益有多重要?
以下是我如何看待世界的觀點:
如果一種狀態太熟悉,你學不到太多。然而如果你感到恐慌,你可能什麼也學不到。
這裡是你的舒適區。你知道池塘中的每條魚。你的歸屬。你知道如何處理問題。太陽底下沒有什麼新鮮事。如果你想要學習新東西並且成長,你必須離開你的舒適區。這是學習的開始。這是有趣的事情開始的地方。這是你不會立即對一切事情做出反應的地方。
》瞭解自己的特性以及希望邁入怎樣的管理崗位絕對是最值得大家認真反思的首要議題。
領導與引導是這份素質清單中的核心專案--甚至足以決定一切。
發現幫助最大的還是來自同事、管理者以及整個團隊的反饋意見,我也通過 審視角色模型並瞭解其為何能夠確切起效而得到了切實助益。
一位專家指出,管理崗位會給從業者帶來大量同樣的挑戰與不確定因素。他隨後補充稱,我們絕對不能採取直白的表達方式--否則必然招致被整個團隊所疏遠的風險。有鑑於此,類比與提醒才是最理想的溝通手段,而這正是作為職業轉變的基礎性藍圖。
只有最糟糕的管理者才會過分施加控制,”Long指出。但這些事必躬親的領導總以為自己是在做正確的事。您能將自己的全部精力用於指導、支援、點撥以及鼓勵他人嗎?這種心態是最基本的前提。總之,請確保自己做好了登上這輛過山車的全部心理準備。”
我們還認為,成功實現晉升後的工程技術人員不妨偶爾回顧過往,審視將程式碼構建與部署作為核心工作--而非管理產品、預算與團隊--的那段時光。
作為一位管理者,大家的職責將較少專注於工作,而更多集中在幫助他人獲得成功上。”
相關文章
- 從Rails聊聊小公司的研發團隊建設AI
- 團隊建設
- 從打籃球到IT團隊建設薦
- 找工作,去小公司好,還是大公司好?
- 程式設計師畢業去大公司好還是小公司好?程式設計師
- 關於程式設計師去大公司還是留在小公司的思考程式設計師
- 前端小團隊建設前端
- 軟體測試人員找工作,去大公司還是去小公司?
- 團隊解散,我們該何去何從?
- Pipefy如何使用團隊拓撲方法建設敏捷團隊?敏捷
- 如何管理好團隊,團隊需要同心圓建設
- 團隊技術資訊流建設
- 運維去大公司好還是小公司好?你怎麼看?運維
- 從恰如其分的架構到研發團隊建設架構
- CIO如何建設數字化團隊
- 團隊文化建設:擁抱黑客文化黑客
- 專案團隊建設“四戒”(轉)
- 巴西隊:一支死於大公司病的創業團隊創業團隊
- 大公司和小公司的程式設計師差別在哪?程式設計師能去小公司嗎?程式設計師
- 幼兒園遲到現象和團隊建設
- 關於團隊建設和個人成長
- 專案團隊建設有“四戒”(轉)
- 中小團隊的技術負責人如何做好技術團隊建設
- 應屆生選擇大公司還是小團隊
- 對新人而言,做軟體測試是去大公司好還是小公司好?
- 技術管理之路三、團隊建設:怎麼帶隊伍?
- LeSS 的誕生(一):大規模團隊該何去何從
- 【團隊建設】如何做好團隊開發中的 CodeReview(程式碼評審)?View
- 【原創】如何開展專案團隊建設
- 專案團隊建設有“四戒”(一)(轉)
- 專案團隊建設有“四戒”(二)(轉)
- 專案管理團隊建設的有效工具(轉)專案管理
- 從 Etsy 團隊看敏捷架構的設計敏捷架構
- 讀大道至簡之我見3——團隊建設
- ERP實施中的團隊建設(1)(轉)
- ERP實施中的團隊建設(2)(轉)
- 淺議物流專案管理的團隊建設 (轉)專案管理
- 專案團隊建設的12條經驗(轉)