從大三的暑假開始，我就一直在某互聯網公司一直實習到來年的一月份，算起來也六個月了，經歷過這六個月的洗禮，頗有感想，假如自己沒有這段經歷的話，或許自己會錯失職場和技術上的收獲。我始終相信，所有的經歷無論對錯與結果如何，都是一段收獲的旅途。這篇文章就撇開技術層面的細節，說說宏觀上的收獲。
接觸到流程化管理
我所在的部門是屬於技術服務類型，也就是利用平台流量為不同的廠商導流，從中獲利。這樣一來就要求部門要有高效的合作精神能夠快速完成各種需求方提的需求任務，用最新又穩定的技術來節約資源和提高工作效率。管理層要做的是協調需求方和開發人員的矛盾，規范化開發流程，及時為需求方提供高質量和速度快的服務。而這一切大概是怎么運作的呢？
首先說說需求方和技術開發兩者之間的矛盾在哪里。需求方各種素質不一，有的甚至連開發流程都不清楚，還有的總是改需求，這些都容易造成需求方和技術開發人員之間的矛盾。比如，正常的開發流程是：需求方提需求—產品設計—后台接口開發—前端開發—測試—上線。而需求方以為前端開發完就可以上線了，於是上線后出現問題后就找前端開發，前端開發這時候才發現需求方居然沒有通過測試環節就上線了？！於是心中怨氣重重，怎么不按照套路走呢？！還有的需求方在前端開發完成后居然說改需求，於是前端同學又是一口老血，不僅浪費了開發資源和時間，還造成了彼此的矛盾。然而需求方心中也對開發不滿，有時候開發者可能同時在處理幾個項目，其中一個項目花的時間和精力有限，可能要延遲一兩天才開發完，這時需求方心中會埋怨不是說好幾號上線的嗎，怎么又延遲了？！於是向老板告狀。除了需求方和技術開發之間的矛盾，其實技術開發團隊之間的不同環節也是需要協調彼此工作的，不然整個開發流程就亂套了。
那具體怎么處理這些矛盾點呢？每周項目經理都會開一次會議，各需求方都可以在這次會議上提出自己的需求和想法，而技術開發的老大們會根據需求方提的需求估算開發時長和難度，項目經理會聽取各方的意見和想法，協調在會議上產生的矛盾，再根據目前的情況以及需求的優先級和分類，制定出一份總需求表。而各個需求的開發時長需要各相關的技術老大預估和提交，項目經理才大概知道這個需求的開發總時長， 然后再和需求方進行后期的溝通，約定完成的時間。
有幾個環節比較重要，第一個是與需求方的前期和后期溝通。從有需求方提出技術需求開始，項目經理就需要和需求方進行前期溝通，開需求會議，如果需求方已經有產品的具體實現想法，那就引導他根據之前約定的需求文檔規范寫下來，如果需求方對產品的定義比較模糊，就需要產品經理跟進，設計一款產品，寫下需求文檔。需求文檔也是有講究的，好的產品經理會按照技術開發的思維來制定詳細的符合邏輯的文檔，還需要當面和開發人員溝通，這樣一來最后的效果才會皆大歡喜。需求這一關最好是確定性的，充分和技術開發溝通，才可以減少因為需求產生的沖突。而與需求方的后期溝通，可能是因為技術開發某種原因導致開發延遲，還有產品開發完了但是需求方不滿意需要和需求方商量一下解決方案。這些溝通的重活都主要落在項目經理的肩膀上，其中各種情況的復雜性和處理方式只有項目經理經歷過才明白如何預防和處理。
再來看看和開發人員緊密相關的整個開發環節吧。由於之前出現項目開發的延遲次數比較多，因此影響到開發預估時長，所以項目經理就采取新規定了，下面闡述的是新規定的流程。各技術主管根據需求的難度和數量，分配給適合的開發人員，然后列出開發人員對應的需求表格。項目經理約定，下午不同時間段前，不同的開發崗位對應的人員，必須根據主管分配的任務預估自己的開發時間，並在線上excel上填寫開發時長，必須在開發結束時間前完成需求，延遲的話將影響到個人的指標評比。部門內自己開發了一個需求管理系統，需求方可以上傳自己的需求，然后項目經理經過前面的流程后，將任務細分給不同的技術主管，技術主管再將任務細分給不同的開發人員，開發人員可以在需求系統上看到自己的需求任務，獲取需求文檔、設計稿等材料和信息。而整個開發流程需要不同角色進行充分溝通，所以在開發的時候，項目經理會在通訊軟件上給每個項目小組開一個小群，產品、設計、后台、前端、運營都可以在上面溝通自己遇到的問題。如果通訊軟件上說不明白的事情，就需要當面進行溝通。另外，我們組在每周開頭都會開一次會議，每個人都需要在開會前在需求管理系統上寫自己的周報，總結上周完成了什么任務，遇到什么問題，怎么解決，計划這種完成什么事情。主管在會議上了解大家需求進度，以及總結一下問題，更好得把控需求任務的分配。
大致流程就是這樣子了，但實際執行的過程中難免會遇到一些特殊情況，這些就需要管理層權衡利弊，制定出更好的解決方案了。
規范化的團隊管理和更好的技術氛圍
我所在的組是前端組，有十多人，根據不同人的能力負責不同的需求任務。主管重視我們組內建設，根據基礎業務，組織核心人員開發sdk，為業務層提供統一的服務，並且開發自助系統，便利業務層的開發，爭取在簡單的業務層上減少重復的人力。在一些業務上，也有對應的比較詳細的文檔，對於新人來說，會相對友好一些，但由於有時候文檔更不上業務的變更，新人有時還是需要問問其他人。
為了便於管理，我們組內規范了開發工具，但具體的開發框架比較自由，可以根據自己的業務場景進行選擇，這樣一來，整個團隊的技術選擇會比較自由，我在實習的時候也嘗試了不同的框架和庫，把理論上學到的用上，並可以對比一下哪種會比較好，實習會有更自由的實戰機會。一開始主管不放心實習生自己弄一個項目，會找一個人帶着。剛好那時候組內有一位資質比較高的前端是在做一個第三方游戲運營的移動端項目，主管讓我去幫忙“打打雜”，我起初是做一些比較簡單的樣式布局，到后來爭取到做一些邏輯處理，還研究了整個項目的框架結構，如此一來從打雜中收獲了不少。在后來的小項目中，有了前面的積累，可以稍微應用自如。
為了營造更好的技術氛圍，主管要求正式員工每兩周就輪一個人進行技術分享。說實話，作為一個實習生，一開始接觸的東西不是很多，所以一開始就聽大牛們的分享會感覺吃力，聽不怎么明白。除了組內的技術分享，項目經理也會組織全部門的技術分享，這種跨組的分享的確可以學到東西，但說實在的，學習這種事情更多的還是靠自己。
接觸到更多優秀的人和提高自己的認知
我接觸到的身邊的人，都是優秀的。他們有的是熱愛技術、喜歡專研技術、有自己理想抱負的年輕人，有的是資質高、有接近十年的經驗、帶過團隊的高級工程師。作為一枚實習生，一開始可能懵懵懂懂，跟着別人做項目的時候，別人會發現你技術上的不足，然后會幫忙推薦一些書籍和公眾號。在實戰中，遇到不懂的，還有人可以指點你，起碼知道彌補自己不足的方式，然后靜下心來認真把技術補上，如此才有了技術上的收獲。一開始接觸陌生的業務時，會有點困難，需要多問別人，才會比較明白整個業務流程，才不會影響到需求進度，多問很重要。
有時候自己在工作的時候，是意識不到自己的不足的，這時候可能需要找前輩來指出不足才有進步的空間。我找過主管和當時面試我的面試官，和他們聊了一下后，才有如下的感悟。
雖然是實習生，但是要拿出正式工的態度和責任來對待任務，要對任務負責，並且思考自己和正式工的距離 在哪里，爭取向正式工靠齊甚至超越，這樣才可以體現在一個組里的價值所在。並且要懂得反思，思考自己一天的時間花在哪里了，需求的效率怎么樣，如何去更好更快得完成某一項任務。其實前端開發會更加注重溝通，如果僅僅是利用通訊工具的話，可能效果會有所欠缺，該當面聊的話就當面去找，刷刷臉也好，積極主動地去找別人聊。
在需求進度緊張而任務一直完成不了的時候就需要反思了。很多工程師包括我可能會有視覺上的潔癖，一定要嚴格按照像素大小來調整界面，然而，假如該項目不是公司主要營收來源，也就是邊緣項目的話，那注重太多的細枝末葉只能是浪費時間和精力。假如需求繁重，而剛好手頭上這個 項目是邊緣項目的話，不妨削減不必要的細節問題，節省寶貴的時間和精力。這也就是要把時間精力花在刀刃上。
前輩為個人成長鋪路
在實習中，有時候會遇到各種各樣的問題，這時候有個資深前輩帶一下，問題很快就可以解決了。而且在做比較復雜的項目時候，有前輩帶着你一起做，幫忙搭好了代碼結構，這些代碼結構可以抽取出來，在以后自己獨立做項目的時候可以使用到，也算是一種積累，但最好還是要理解好代碼結構原理。
團隊里的人需要用新技術，有時候我和其他小伙伴會圍在在熟悉的前輩電腦前，看前輩在github或博客上逛別人寫的插件效果，一起討論這個插件好不好看，怎么實現的呀~就像是女生們圍觀購物一樣，樂趣無窮。
總而言之，這就是我在大公司那段實習經歷的收獲，覺得一開始可以在大公司實習真的很不錯，有成熟正規的規章制度，還認識了一群熱愛技術的小伙伴們，這些想法和收獲分享出來，希望可以幫忙到選擇實習或工作的你們。