【實習】在大公司實習六個月後的收穫

　　從大三的暑假開始，我就一直在某互聯網公司一直實習到來年的一月份，算起來也六個月了，經歷過這六個月的洗禮，很有感想，假如本身沒有這段經歷的話，或許本身會錯失職場和技術上的收穫。我始終相信，全部的經歷不管對錯與結果如何，都是一段收穫的旅途。這篇文章就撇開技術層面的細節，說說宏觀上的收穫。

 

接觸到流程化管理

　　我所在的部門是屬於技術服務類型，也就是利用平臺流量爲不一樣的廠商導流，從中獲利。這樣一來就要求部門要有高效的合做精神可以快速完成各類需求方提的需求任務，用最新又穩定的技術來節約資源和提升工做效率。管理層要作的是協調需求方和開發人員的矛盾，規範化開發流程，及時爲需求方提供高質量和速度快的服務。而這一切大概是怎麼運做的呢？

　　首先說說需求方和技術開發二者之間的矛盾在哪裏。需求方各類素質不一，有的甚至連開發流程都不清楚，還有的老是改需求，這些都容易形成需求方和技術開發人員之間的矛盾。好比，正常的開發流程是：需求方提需求—產品設計—後臺接口開發—前端開發—測試—上線。而需求方覺得前端開發完就能夠上線了，因而上線後出現問題後就找前端開發，前端開發這時候才發現需求方竟然沒有經過測試環節就上線了？！因而心中怨氣重重，怎麼不按照套路走呢？！還有的需求方在前端開發完成後竟然說改需求，因而前端同窗又是一口老血，不只浪費了開發資源和時間，還形成了彼此的矛盾。然而需求方心中也對開發不滿，有時候開發者可能同時在處理幾個項目，其中一個項目花的時間和精力有限，可能要延遲一兩天才開發完，這時需求方心中會埋怨不是說好幾號上線的嗎，怎麼又延遲了？！因而向老闆告狀。除了需求方和技術開發之間的矛盾，其實技術開發團隊之間的不一樣環節也是須要協調彼此工做的，否則整個開發流程就亂套了。

　　那具體怎麼處理這些矛盾點呢？每週項目經理都會開一次會議，各需求方均可以在此次會議上提出本身的需求和想法，而技術開發的老大們會根據需求方提的需求估算開發時長和難度，項目經理會聽取各方的意見和想法，協調在會議上產生的矛盾，再根據目前的狀況以及需求的優先級和分類，制定出一份總需求表。而各個需求的開發時長鬚要各相關的技術老大預估和提交，項目經理才大概知道這個需求的開發總時長， 而後再和需求方進行後期的溝通，約定完成的時間。

　　有幾個環節比較重要，第一個是與需求方的前期和後期溝通。從有需求方提出技術需求開始，項目經理就須要和需求方進行前期溝通，開需求會議，若是需求方已經有產品的具體實現想法，那就引導他根據以前約定的需求文檔規範寫下來，若是需求方對產品的定義比較模糊，就須要產品經理跟進，設計一款產品，寫下需求文檔。需求文檔也是有講究的，好的產品經理會按照技術開發的思惟來制定詳細的符合邏輯的文檔，還須要當面和開發人員溝通，這樣一來最後的效果纔會皆大歡喜。需求這一關最好是肯定性的，充分和技術開發溝通，才能夠減小由於需求產生的衝突。而與需求方的後期溝通，多是由於技術開發某種緣由致使開發延遲，還有產品開發完了可是需求方不滿意須要和需求方商量一下解決方案。這些溝通的重活都主要落在項目經理的肩膀上，其中各類狀況的複雜性和處理方式只有項目經理經歷過才明白如何預防和處理。

　　再來看看和開發人員緊密相關的整個開發環節吧。因爲以前出現項目開發的延遲次數比較多，所以影響到開發預估時長，因此項目經理就採起新規定了，下面闡述的是新規定的流程。各技術主管根據需求的難度和數量，分配給適合的開發人員，而後列出開發人員對應的需求表格。項目經理約定，下午不一樣時間段前，不一樣的開發崗位對應的人員，必須根據主管分配的任務預估本身的開發時間，並在線上excel上填寫開發時長，必須在開發結束時間前完成需求，延遲的話將影響到我的的指標評比。部門內本身開發了一個需求管理系統，需求方能夠上傳本身的需求，而後項目經理通過前面的流程後，將任務細分給不一樣的技術主管，技術主管再將任務細分給不一樣的開發人員，開發人員能夠在需求系統上看到本身的需求任務，獲取需求文檔、設計稿等材料和信息。而整個開發流程須要不一樣角色進行充分溝通，因此在開發的時候，項目經理會在通信軟件上給每一個項目小組開一個小羣，產品、設計、後臺、前端、運營均可以在上面溝通本身遇到的問題。若是通信軟件上說不明白的事情，就須要當面進行溝通。另外，咱們組在每週開頭都會開一次會議，每一個人都須要在開會前在需求管理系統上寫本身的週報，總結上週完成了什麼任務，遇到什麼問題，怎麼解決，計劃這種完成什麼事情。主管在會議上了解你們需求進度，以及總結一下問題，更好得把控需求任務的分配。

大體流程就是這樣子了，但實際執行的過程當中不免會遇到一些特殊狀況，這些就須要管理層權衡利弊，制定出更好的解決方案了。

規範化的團隊管理和更好的技術氛圍

　　我所在的組是前端組，有十多人，根據不一樣人的能力負責不一樣的需求任務。主管重視咱們組內建設，根據基礎業務，組織核心人員開發sdk，爲業務層提供統一的服務，而且開發自助系統，便利業務層的開發，爭取在簡單的業務層上減小重複的人力。在一些業務上，也有對應的比較詳細的文檔，對於新人來講，會相對友好一些，但因爲有時候文檔更不上業務的變動，新人有時仍是須要問問其餘人。

　　爲了便於管理，咱們組內規範了開發工具，但具體的開發框架比較自由，能夠根據本身的業務場景進行選擇，這樣一來，整個團隊的技術選擇會比較自由，我在實習的時候也嘗試了不一樣的框架和庫，把理論上學到的用上，並能夠對比一下哪一種會比較好，實習會有更自由的實戰機會。一開始主管不放心實習生本身弄一個項目，會找一我的帶着。恰好那時候組內有一位資質比較高的前端是在作一個第三方遊戲運營的移動端項目，主管讓我去幫忙「打打雜」，我起初是作一些比較簡單的樣式佈局，到後來爭取到作一些邏輯處理，還研究了整個項目的框架結構，如此一來從打雜中收穫了很多。在後來的小項目中，有了前面的積累，能夠稍微應用自如。

　　爲了營造更好的技術氛圍，主管要求正式員工每兩週就輪一我的進行技術分享。說實話，做爲一個實習生，一開始接觸的東西不是不少，因此一開始就聽大牛們的分享會感受吃力，聽不怎麼明白。除了組內的技術分享，項目經理也會組織所有門的技術分享，這種跨組的分享的確能夠學到東西，但說實在的，學習這種事情更多的仍是靠本身。

 

接觸到更多優秀的人和提升本身的認知

　　我接觸到的身邊的人，都是優秀的。他們有的是熱愛技術、喜歡專研技術、有本身理想抱負的年輕人，有的是資質高、有接近十年的經驗、帶過團隊的高級工程師。做爲一枚實習生，一開始可能懵懵懂懂，跟着別人作項目的時候，別人會發現你技術上的不足，而後會幫忙推薦一些書籍和公衆號。在實戰中，遇到不懂的，還有人能夠指點你，起碼知道彌補本身不足的方式，而後靜下心來認真把技術補上，如此纔有了技術上的收穫。一開始接觸陌生的業務時，會有點困難，須要多問別人，纔會比較明白整個業務流程，纔不會影響到需求進度，多問很重要。

　　有時候本身在工做的時候，是意識不到本身的不足的，這時候可能須要找前輩來指出不足纔有進步的空間。我找過主管和當時面試個人面試官，和他們聊了一下後，纔有以下的感悟。

　　雖然是實習生，可是要拿出正式工的態度和責任來對待任務，要對任務負責，而且思考本身和正式工的距離 在哪裏，爭取向正式工靠齊甚至超越，這樣才能夠體如今一個組裏的價值所在。而且要懂得反思，思考本身一天的時間花在哪裏了，需求的效率怎麼樣，如何去更好更快得完成某一項任務。其實前端開發會更加註重溝通，若是僅僅是利用通信工具的話，可能效果會有所欠缺，該當面聊的話就當面去找，刷刷臉也好，積極主動地去找別人聊。

　　在需求進度緊張而任務一直完成不了的時候就須要反思了。不少工程師包括我可能會有視覺上的潔癖，必定要嚴格按照像素大小來調整界面，然而，假如該項目不是公司主要營收來源，也就是邊緣項目的話，那注重太多的細枝末葉只能是浪費時間和精力。假如需求繁重，而恰好手頭上這個 項目是邊緣項目的話，不妨削減沒必要要的細節問題，節省寶貴的時間和精力。這也就是要把時間精力花在刀刃上。

 

前輩爲我的成長鋪路

　　在實習中，有時候會遇到各類各樣的問題，這時候有個資深前輩帶一下，問題很快就能夠解決了。並且在作比較複雜的項目時候，有前輩帶着你一塊兒作，幫忙搭好了代碼結構，這些代碼結構能夠抽取出來，在之後本身獨立作項目的時候可使用到，也算是一種積累，但最好仍是要理解好代碼結構原理。

　　團隊裏的人須要用新技術，有時候我和其餘小夥伴會圍在在熟悉的前輩電腦前，看前輩在github或博客上逛別人寫的插件效果，一塊兒討論這個插件好很差看，怎麼實現的呀~就像是女生們圍觀購物同樣，樂趣無窮。

 

　　總而言之，這就是我在大公司那段實習經歷的收穫，以爲一開始能夠在大公司實習真的很不錯，有成熟正規的規章制度，還認識了一羣熱愛技術的小夥伴們，這些想法和收穫分享出來，但願能夠幫忙到選擇實習或工做的大家。