參加工作已經(jīng)兩年多了，加上實(shí)習(xí)的時間差不多快三年了，中間做過很多項(xiàng)目，但是成功的不多，PM，也就是所謂的項(xiàng)目經(jīng)理做過很多次，有業(yè)務(wù)項(xiàng)目，有技術(shù)驅(qū)動項(xiàng)目，有大型跨團(tuán)隊(duì)項(xiàng)目，有了一些感悟，大概幾個月前在團(tuán)隊(duì)內(nèi)部做過一個分享，最近剛剛忙完雙十一，就把之前的PPT簡單翻譯一下放出來吧。

        什么是項(xiàng)目？

        特定資源高質(zhì)量的完成特定的任務(wù)。從這個簡單的描述中，就能看出，項(xiàng)目的四個點(diǎn)，一個是進(jìn)度、一個是資源、一個是范圍、一個是質(zhì)量。項(xiàng)目可能分為業(yè)務(wù)型項(xiàng)目、技術(shù)驅(qū)動型項(xiàng)目、預(yù)研類項(xiàng)目，這三種類型有幸在公司的這幾年都參與過。

        PM（項(xiàng)目經(jīng)理，在我廠大多數(shù)是開發(fā)的同學(xué)負(fù)責(zé)，當(dāng)然有的項(xiàng)目PM是測試或者其他）最重要的素質(zhì)是啥？

        這個時候，你的腦海中可能會有“懂產(chǎn)品”、“懂技術(shù)”、“比較強(qiáng)勢”、“溝通能力比較強(qiáng)”這些詞語，其實(shí)，我覺得，項(xiàng)目經(jīng)理作為項(xiàng)目的負(fù)責(zé)人，我認(rèn)為最重要的是“積極主動”這個素質(zhì)。有了這個習(xí)慣或者素質(zhì)，其他的也就沒有問題了。本篇不是心靈雞湯，點(diǎn)到為止。如果技術(shù)差，需要在之前就需要補(bǔ)一下技術(shù)的東西，產(chǎn)品理解比較弱，那就多看看產(chǎn)品相關(guān)的東西，如果溝通能力比較弱，那就需要在平時多多注意這些方面的鍛煉。但是如果這時候項(xiàng)目來了，咋辦呢？那就積極一點(diǎn)，主動一點(diǎn)，這時候問題可能就不是問題了。

        關(guān)于項(xiàng)目流程

        各個公司，尤其是大公司，會有很多流程，有的整合到工作流系統(tǒng)中，有的通過郵件或者公告的形式大家約定的一些流程，這篇文章不包含這些流程的東西，主要是自己的一些摸索和感悟。流程可能比較簡單，例如“需求評審”-“技術(shù)方案和設(shè)計(jì)”-“編碼測試”-“發(fā)布上線”這幾個步驟，也可能比較復(fù)雜，流程的分支讓你看半天也理解不了。那流程是什么呢？我認(rèn)為流程是游戲規(guī)則，如果不懂規(guī)則，怎么能夠玩好游戲呢？流程本身不是生產(chǎn)力，但是好的流程和約定，能夠提升效率。

        項(xiàng)目中溝通的原則是啥

        就兩個字“坦誠”，項(xiàng)目絕大多數(shù)都是技術(shù)人員，總體比較簡單，溝通不會有一些亂七八糟的問題，遇到問題可以坦誠的說出自己的想法。沒必要搞的很復(fù)雜。在剛剛工作的時候，遇到一個同事比較難溝通，于是找老板告狀，然后再比較強(qiáng)勢的溝通，后面發(fā)現(xiàn)效果不是很好，然后緊接著一天就坦誠了說出了自己的想法以及為啥溝通不爽啥的。所以，坦誠溝通即可，簡簡單單更好。

        團(tuán)隊(duì)內(nèi)部怎么溝通比較好

        這里馬總在內(nèi)網(wǎng)的一次討論總結(jié)的很好，這里就借用一下。好的團(tuán)隊(duì)，在會議室會爭吵的猶如仇人，憑借嗓門各抒己見，一離開會議室戰(zhàn)斗中猶如兄弟，互相配合支持和掩護(hù)。離開會議室的決定就是團(tuán)隊(duì)的決定。壞的團(tuán)隊(duì)，在會議室討論猶如兄弟，都是同意，贊美或者沉默，不發(fā)表意見或者不痛不癢，離開會議室就各自拔刀詆毀，拉幫結(jié)派，爭權(quán)奪利。好團(tuán)隊(duì)碰到問題會去解決問題，懷團(tuán)隊(duì)首先是指責(zé)或者推卸責(zé)任或者批評別人的不對。

        如何討論需求

1、需求階段的討論，是性價比最高的（和后面的開發(fā)階段以及測試階段相比的話）；

2、事無巨細(xì)，挑戰(zhàn)PRD（需求文檔）中的任何細(xì)節(jié)；

3、關(guān)注合理性、可行性以及價值等抽象層面；

        如何避免吵架

        在項(xiàng)目中吵架在所難免，但是有個前提，就是吵架不能解決問題，吵架傷身，也傷感情，最好減少。這里總結(jié)了三個點(diǎn)：

1、換位思考（換個角度思考，看看對方的觀點(diǎn)為啥會是那樣的）；

2、聽完對方的講話之后再表達(dá)自己的觀點(diǎn)（很多時候，吵架的雙方都彼此不聽對方的講話，各自說各自的）；

3、憤怒時，自己默數(shù)幾個數(shù)之后再表達(dá)自己的觀點(diǎn)；

        如何進(jìn)行跨團(tuán)隊(duì)協(xié)作

        了解需要協(xié)作的團(tuán)隊(duì)的業(yè)務(wù)和技術(shù)，在了解之后，溝通的障礙會少很多。

1、了解對方大體的業(yè)務(wù)場景；

2、雙方重度合作的，可能需要看一下彼此的代碼；

3、這也可能四知己知彼，百戰(zhàn)不殆的另外一個層面；

        啥是好的技術(shù)方案

1、能夠梳理清楚業(yè)務(wù)需求（這一點(diǎn)，需要讓項(xiàng)目中各個角色的人都能理解需求是啥）；

2、技術(shù)方案要能夠支持團(tuán)隊(duì)的開發(fā)同學(xué)設(shè)計(jì)詳細(xì)的方案；

3、一個問題點(diǎn)有多個方案的時候，列舉多個，并比較各自的優(yōu)勢和劣勢；

在做好技術(shù)方案的時候，建議提前和比較資深的同事溝通，請同事幫忙review一下。平時和多看一下同事或者團(tuán)隊(duì)外部的技術(shù)方案，學(xué)習(xí)一下。

        UC（use case 用例）的作用是啥

        需求用例，這里的作用，我覺得就是需求達(dá)成一致，在UC評審的時候，需要項(xiàng)目中的產(chǎn)品經(jīng)理、開發(fā)同學(xué)和測試同學(xué)能夠達(dá)成一致，因?yàn)橐恍c(diǎn)，大家可能彼此以為理解了，但是時間上理解的是不一致的。UC或者設(shè)計(jì)的時間，建議PM給開發(fā)同學(xué)多留一些時間，好的UC或者設(shè)計(jì)能夠很好的減少后面的返工，也能夠及時的發(fā)現(xiàn)一些細(xì)節(jié)問題點(diǎn)。

        什么樣的UC才是合格的呢？

1、寫完之后，把自己掏空，換角度思考，從測試或者產(chǎn)品的角度來看一下UC；

2、如果自己以一種小白的角色，還能看懂，我覺得就OK了；

3、頁面類和接口類，在UC上面要求是不同的，頁面可能需要交互的細(xì)節(jié)比較清楚，接口類的可能需要入?yún)⒑统鰠⑸兜暮芮宄趴梢裕?/span>

4、在我看來是沒有固定的模板或者格式的，能夠講清楚，別人能夠看明白就行；

        如何評估工作量

        實(shí)際在項(xiàng)目中，時間都很近，這里建議在評估工作量的時候，多考慮以下幾個因素：

1、一些需求可能在寫代碼的時候還在討論；

2、在寫代碼調(diào)試的時候，可能環(huán)境問題搞死人；

3、擴(kuò)團(tuán)隊(duì)的協(xié)作是很消耗時間的，這里要多預(yù)留一些時間；

4、在你做項(xiàng)目的時候，可能還有一些緊急問題，例如線上問題等著你處理；

        作為技術(shù)要不要懂產(chǎn)品

        我覺得必須懂，如果不懂，僅僅是去實(shí)現(xiàn)產(chǎn)品，那就成了工具，最起碼我是這樣認(rèn)為的。我覺得終極目標(biāo)就是比業(yè)務(wù)同學(xué)更了解業(yè)務(wù)。在項(xiàng)目中，主動挑戰(zhàn)產(chǎn)品，以此來判斷產(chǎn)品思考的是否完善。對于產(chǎn)品中的問題，給出自己的建議。項(xiàng)目經(jīng)理和產(chǎn)品經(jīng)理是上下游協(xié)作的戰(zhàn)友，比較多一些了解方便溝通。

        如何分配項(xiàng)目任務(wù)

1、提前溝通項(xiàng)目成員的長項(xiàng)和興趣點(diǎn)；

2、了解項(xiàng)目組成員期望在項(xiàng)目中學(xué)習(xí)的東西是啥；

3、緊急情況下（例如上線時間特別緊急），這時候擅長的人做擅長的事情；

4、劃分模板，模塊內(nèi)部高內(nèi)聚，模塊之前低耦合；

5、項(xiàng)目經(jīng)理做好項(xiàng)目組成員工作的銜接，鏈接各個零散的模塊；

6、哪里確認(rèn)，PM都要頂上，這個對于PM的技術(shù)要求比較全面；

        單元測試需要做多細(xì)

        在項(xiàng)目過程中，開發(fā)同學(xué)要把東西做一個單元測試，之后再提交測試同學(xué)做測試，這里有個問題，就是單元測試要做多細(xì)呢？

1、DAO層的就不要做了，可以通過工具來生成一些配置或者代碼；

2、重點(diǎn)關(guān)注一些容易出錯和邊界點(diǎn)；

3、主流程的測試切記要能夠覆蓋到；

4、單元測試多花點(diǎn)時間，其實(shí)能夠很好的減少后面測試環(huán)節(jié)的扯皮和返工；

        為什么要做冒煙測試

        所謂冒煙測試，就是找一個時間點(diǎn)，開發(fā)和測試同學(xué)約定項(xiàng)目的主流程，然后走一遍，成功則冒煙測試成功。

冒煙測試是項(xiàng)目提交測試的里程碑；

在測試用例評審的時候，約定冒煙測試的范圍；

這個標(biāo)志著項(xiàng)目進(jìn)入穩(wěn)定期，也是項(xiàng)目最緊張的開始；

        如何開每日例會

1、挑選一個大家都在的時間點(diǎn)，也可以項(xiàng)目組中約定一個大家覺得不錯的時間；

2、確定例會的范圍（昨天做了啥，今天的工作計(jì)劃，遇到的問題）；

3、切記，不要在例會上討論細(xì)節(jié)問題，拋出問題即可，細(xì)節(jié)的會后討論；

        要學(xué)會說“NO”

        什么情況下可以說不呢？我列舉幾個情況

1、業(yè)務(wù)方對于上線時間要求完全不靠譜；

2、產(chǎn)品經(jīng)理在沒有溝通的情況下就進(jìn)行重大的需求變更；

3、犧牲項(xiàng)目的質(zhì)量來強(qiáng)行上線；

如果開發(fā)同學(xué)事事都說yes，那會很苦逼，并且沒人說你好。

        關(guān)于發(fā)布計(jì)劃

        為啥要有發(fā)布計(jì)劃呢？

1、這個是發(fā)布順序的描述以及線上變更的計(jì)劃；

2、必須有，且必須重視；

        什么樣的發(fā)布計(jì)劃是合格的呢？

1、合理的發(fā)布順序；

2、每個環(huán)節(jié)有人關(guān)注，有人check；

3、有回滾計(jì)劃；

4、善于利用工具，多多check；

        項(xiàng)目過程中的風(fēng)險管理

1、有風(fēng)險一定要提前拋出來；

2、動員項(xiàng)目組的成員多多思考各自模塊的問題點(diǎn)；

3、拉上資深的同事幫忙review一下風(fēng)險點(diǎn)；

4、PM要花一半的精力在以后的事情上，多多思考后面幾天要干啥，提前做一個準(zhǔn)備；

        項(xiàng)目中的沉淀

1、文檔沉淀（供后續(xù)的新人或者非項(xiàng)目組成員看）；

2、技術(shù)沉淀（用的新框架或者組件啥的）；

3、踩過的坑，記得分享出來；

        至此，一個完整的項(xiàng)目已經(jīng)上線了，這些是經(jīng)歷過多次項(xiàng)目之后的一個總結(jié)，可能有些不正確或者不全面。工作還是要繼續(xù)，后面隨著工作的深入，可能對于項(xiàng)目的理解會不同，但是上面這些點(diǎn)，是目前階段的理解。