第三期我們講的是最後乙個須要溝通的主要團隊—研發團隊。
研發團隊溝通後。就代表我們的最後乙個溝通任務結束了。那麼我們如今開始正式進入了乙個專案的生產階段了，假設說前面準備工作，非常多童鞋沒有接觸過，那麼從今天開始我們講的內容，我相信大家都不會陌生。那麼就讓我們來複習一下專案的生命週期。
啟動→需求→設計→開發→測試→上線→推廣。
我之前講的都是環繞啟動這個階段的，那麼啟動階段在這裡要做乙個收尾，啟動階段最後乙個任務就是啟動會。啟動會的形式能夠多種多樣，有些事大家在一起開個會認識一下，有些是大家來個宣誓會，有些是大家在一起聚個餐唱個歌。
情況多種多樣，這個要依據所在公司的的風氣、習慣來。
啟動階段結束後，我們就要馬上投入到需求階段，在這個階段的參與者主要為業務方領導、業務方、產品經理、研發經理、架構師以及專案經理，但並非說整個需求階段必須要全部的人參與進來。那麼這些人我們怎麼來分別呢。他們主要分三個團隊和乙個主導。
1、業務團隊：業務方領導、業務方。
2、產品團隊/翻譯團隊：產品經理。
3、研發團隊：研發經理、架構師。
這裡我把產品經理叫做「翻譯團隊」大家會不會認為有點奇怪？事實上這個產品經理的角色在不同的公司有著截然不同的作用。即便他們做的事兒可能是一樣的。
大概網際網路公司會分下面幾種型別：
1、技術驅動業務團隊：產品經理規劃公司業務。通過產品經理來驅動業務方和研發團隊。
2、業務驅動技術團隊：業務方提出需求，產品經理翻譯成研發團隊easy理解的語言，並交由研發團隊實現。
自己的公司屬於哪種，就看看你們的產品經理是處於哪種模式下吧。
有點扯遠了。話說回來，這三個團隊是pm主要須要聯絡接觸的團隊，這三方都有著微妙的關係和利益。怎樣平衡好。我之前已經提到過一些，這裡就不再繼續講了。我想說的是。怎樣看待這三個團隊。
1、確保老闆的利益
說白了，乙個專案的成功失敗，最直接的影響人並非業務方或者產品經理，而就是老闆。一定要搞清楚老闆想要什麼，老闆要達成什麼目的。一味的唯命是從。被產品經理和業務方牽著鼻子走，僅僅能讓事情朝著不可控的方向發展。所以，搞清了老闆的目的，哪怕是出現一些小的錯誤，老闆一定不會在意的。
2、誰地位高。我們以誰為核心去推動
即便是相同的組織架構的兩家公司，也會由於成員的組成而造成工作流程的天壤之別。好比a公司的研發團隊的領導是公司的元老，在公司極有話語權。那麼在這個公司想產出乙個產品你肯定要過他這關，即便你全部的工作做得完美。搞不定這個元老，也僅僅會功虧一簣。這裡，會不會有童鞋質疑我。「之前你不是說過要走的那些流程，跟你如今說的不一樣嗎？」是的，確實不一樣，前面我是講乙個萬金油，應對各種各樣的場合，那麼做起碼不會錯。但你看看我的標題？假設都講那些流程式的東西就沒意思了。
3、確保產品經理與業務方交好
業務方和產品經理的關係。在非常多公司都是個問題。假設二者關係鬧僵，不管你有再優秀的研發團隊。也是無力回天。這個一定是重中之重，怎樣處理好二者關係，我們以後再說。
4、與研發團隊一起加班
說來說去，最核心的工作事實上就在研發這，而最辛苦的團隊當然就是研發團隊了，他們常常會沒日沒夜的加班趕工。這是pm親近研發團隊的最好時機，一定要常常陪研發團隊在一起加班，與他們討論需求、功能。這樣你才是乙個身體力行的專案經理，而不會被扣上乙個「耍嘴皮子的銷售」的帽子。
以上就是在pm在需求階段須要具備的一些意識，下次我會繼續講需求階段的詳細行動。
scala細節 你不知道的
在scala一般都是作為佔位符，比如下面過濾掉非整數的例子 somenumbers.filter x x 0 其等價於 somenumbers.filter 0 如下是做為引數的佔位符,需宣告型別 val f int int f 5,10 15多個下劃線指代多個引數，而不是單個引數的重複使用。第乙個...
你不知道的那些console
前一陣在查詢問題的時候，偶然間發現了console的乙個用法，彷彿開啟了我新世界的大門，原來console還有這麼多的用法，這讓一直以來只用console.log 的我情何以堪啊，所以在這裡記錄一下我認為有意思和比較實用的幾種用法。console.log 文字資訊 console.info 提示資訊...
那些你不知道的meta標籤
作為一名切圖仔，對meta一直都是用於seo優化 設定視口標籤，但是最近一段時間檢視 京東 蘇寧等 的前端 卻發現meta標籤的使用多種多樣，這才知道自己一直小覷了meta標籤。在陸續看了其他幾家大型 的前端 和翻閱了相關資料寫下了這篇文章，如果文章中有什麼錯誤，麻煩指出，立即更正。http equ...