參加工作已經兩年多了，加上實習的時間差不多快三年了，中間做過很多專案，但是成功的不多，pm，也就是所謂的專案經理做過很多次，有業務專案，有技術驅動專案，有大型跨團隊專案，有了一些感悟，大概幾個月前在團隊內部做過乙個分享，最近剛剛忙完雙十一，就把之前的ppt簡單翻譯一下放出來吧。
什麼是專案？
特定資源高質量的完成特定的任務。從這個簡單的描述中，就能看出，專案的四個點，乙個是進度、乙個是資源、乙個是範圍、乙個是質量。專案可能分為業務型專案、技術驅動型專案、預研類專案，這三種型別有幸在公司的這幾年都參與過。
pm（專案經理，在我廠大多數是開發的同學負責，當然有的專案pm是測試或者其他）最重要的素質是啥？
這個時候，你的腦海中可能會有「懂產品」、「懂技術」、「比較強勢」、「溝通能力比較強」這些詞語，其實，我覺得，專案經理作為專案的負責人，我認為最重要的是「積極主動」這個素質。有了這個習慣或者素質，其他的也就沒有問題了。本篇不是心靈雞湯，點到為止。如果技術差，需要在之前就需要補一下技術的東西，產品理解比較弱，那就多看看產品相關的東西，如果溝通能力比較弱，那就需要在平時多多注意這些方面的鍛鍊。但是如果這時候專案來了，咋辦呢？那就積極一點，主動一點，這時候問題可能就不是問題了。
關於專案流程
各個公司，尤其是大公司，會有很多流程，有的整合到工作流系統中，有的通過郵件或者公告的形式大家約定的一些流程，這篇文章不包含這些流程的東西，主要是自己的一些摸索和感悟。流程可能比較簡單，例如「需求評審」-「技術方案和設計」-「編碼測試」-「發布上線」這幾個步驟，也可能比較複雜，流程的分支讓你看半天也理解不了。那流程是什麼呢？我認為流程是遊戲規則，如果不懂規則，怎麼能夠玩好遊戲呢？流程本身不是生產力，但是好的流程和約定，能夠提公升效率。
專案中溝通的原則是啥
就兩個字「坦誠」，專案絕大多數都是技術人員，總體比較簡單，溝通不會有一些亂七八糟的問題，遇到問題可以坦誠的說出自己的想法。沒必要搞的很複雜。在剛剛工作的時候，遇到乙個同事比較難溝通，於是找老闆告狀，然後再比較強勢的溝通，後面發現效果不是很好，然後緊接著一天就坦誠了說出了自己的想法以及為啥溝通不爽啥的。所以，坦誠溝通即可，簡簡單單更好。
團隊內部怎麼溝通比較好
這裡馬總在內網的一次討論總結的很好，這裡就借用一下。好的團隊，在會議室會爭吵的猶如仇人，憑藉嗓門各抒己見，一離開會議室戰鬥中猶如兄弟，互相配合支援和掩護。離開會議室的決定就是團隊的決定。壞的團隊，在會議室討論猶如兄弟，都是同意，讚美或者沉默，不發表意見或者不痛不癢，離開會議室就各自拔刀詆毀，拉幫結派，爭權奪利。好團隊碰到問題會去解決問題，懷團隊首先是指責或者推卸責任或者批評別人的不對。
如何討論需求
1、需求階段的討論，是價效比最高的（和後面的開發階段以及測試階段相比的話）；
2、事無鉅細，挑戰prd（需求文件）中的任何細節；
3、關注合理性、可行性以及價值等抽象層面；
如何避免吵架
在專案中吵架在所難免，但是有個前提，就是吵架不能解決問題，吵架傷身，也傷感情，最好減少。這裡總結了三個點：
1、換位思考（換個角度思考，看看對方的觀點為啥會是那樣的）；
2、聽完對方的講話之後再表達自己的觀點（很多時候，吵架的雙方都彼此不聽對方的講話，各自說各自的）；
3、憤怒時，自己默數幾個數之後再表達自己的觀點；
如何進行跨團隊協作
了解需要協作的團隊的業務和技術，在了解之後，溝通的障礙會少很多。
1、了解對方大體的業務場景；
2、雙方重度合作的，可能需要看一下彼此的**；
3、這也可能四知己知彼，百戰不殆的另外乙個層面；
啥是好的技術方案
1、能夠梳理清楚業務需求（這一點，需要讓專案中各個角色的人都能理解需求是啥）；
2、技術方案要能夠支援團隊的開發同學設計詳細的方案；
3、乙個問題點有多個方案的時候，列舉多個，並比較各自的優勢和劣勢；
在做好技術方案的時候，建議提前和比較資深的同事溝通，請同事幫忙review一下。平時和多看一下同事或者團隊外部的技術方案，學習一下。
uc（use case 用例）的作用是啥
需求用例，這裡的作用，我覺得就是需求達成一致，在uc評審的時候，需要專案中的產品經理、開發同學和測試同學能夠達成一致，因為一些點，大家可能彼此以為理解了，但是時間上理解的是不一致的。uc或者設計的時間，建議pm給開發同學多留一些時間，好的uc或者設計能夠很好的減少後面的返工，也能夠及時的發現一些細節問題點。
什麼樣的uc才是合格的呢？
1、寫完之後，把自己掏空，換角度思考，從測試或者產品的角度來看一下uc；
2、如果自己以一種小白的角色，還能看懂，我覺得就ok了；
3、頁面類和介面類，在uc上面要求是不同的，頁面可能需要互動的細節比較清楚，介面類的可能需要入參和出參啥的很清楚才可以；
4、在我看來是沒有固定的模板或者格式的，能夠講清楚，別人能夠看明白就行；
如何評估工作量
實際在專案中，時間都很近，這裡建議在評估工作量的時候，多考慮以下幾個因素：
1、一些需求可能在寫**的時候還在討論；
2、在寫**除錯的時候，可能環境問題搞死人；
3、擴團隊的協作是很消耗時間的，這裡要多預留一些時間；
4、在你做專案的時候，可能還有一些緊急問題，例如線上問題等著你處理；
作為技術要不要懂產品
我覺得必須懂，如果不懂，僅僅是去實現產品，那就成了工具，最起碼我是這樣認為的。我覺得終極目標就是比業務同學更了解業務。在專案中，主動挑戰產品，以此來判斷產品思考的是否完善。對於產品中的問題，給出自己的建議。專案經理和產品經理是上下游協作的戰友，比較多一些了解方便溝通。
如何分配專案任務
1、提前溝通專案成員的長項和興趣點；
2、了解專案組成員期望在專案中學習的東西是啥；
3、緊急情況下（例如上線時間特別緊急），這時候擅長的人做擅長的事情；
4、劃分模板，模組內部高內聚，模組之前低耦合；
5、專案經理做好專案組成員工作的銜接，鏈結各個零散的模組；
6、**確認，pm都要頂上，這個對於pm的技術要求比較全面；
單元測試需要做多細
在專案過程中，開發同學要把東西做乙個單元測試，之後再提交測試同學做測試，這裡有個問題，就是單元測試要做多細呢？
1、dao層的就不要做了，可以通過工具來生成一些配置或者**；
2、重點關注一些容易出錯和邊界點；
3、主流程的測試切記要能夠覆蓋到；
4、單元測試多花點時間，其實能夠很好的減少後面測試環節的扯皮和返工；
為什麼要做冒煙測試
所謂冒煙測試，就是找乙個時間點，開發和測試同學約定專案的主流程，然後走一遍，成功則冒煙測試成功。
冒煙測試是專案提交測試的里程碑；
在測試用例評審的時候，約定冒煙測試的範圍；
這個標誌著專案進入穩定期，也是專案最緊張的開始；
如何開每日例會
1、挑選乙個大家都在的時間點，也可以專案組中約定乙個大家覺得不錯的時間；
2、確定例會的範圍（昨天做了啥，今天的工作計畫，遇到的問題）；
3、切記，不要在例會上討論細節問題，丟擲問題即可，細節的會後討論；
要學會說「no」
什麼情況下可以說不呢？我列舉幾個情況
1、業務方對於上線時間要求完全不靠譜；
2、產品經理在沒有溝通的情況下就進行重大的需求變更；
3、犧牲專案的質量來強行上線；
如果開發同學事事都說yes，那會很苦逼，並且沒人說你好。
關於發布計畫
為啥要有發布計畫呢？
1、這個是發布順序的描述以及線上變更的計畫；
2、必須有，且必須重視；
什麼樣的發布計畫是合格的呢？
1、合理的發布順序；
2、每個環節有人關注，有人check；
3、有回滾計畫；
4、善於利用工具，多多check；
專案過程中的風險管理
1、有風險一定要提前丟擲來；
2、動員專案組的成員多多思考各自模組的問題點；
3、拉上資深的同事幫忙review一下風險點；
4、pm要花一半的精力在以後的事情上，多多思考後面幾天要幹啥，提前做乙個準備；
專案中的沉澱
1、文件沉澱（供後續的新人或者非專案組成員看）；
2、技術沉澱（用的新框架或者元件啥的）；
3、踩過的坑，記得分享出來；
至此，乙個完整的專案已經上線了，這些是經歷過多次專案之後的乙個總結，可能有些不正確或者不全面。
工作還是要繼續，後面隨著工作的深入，可能對於專案的理解會不同，但是上面這些點，是目前階段的理解。
分析網際網路的起點在電子商務
現在的模式，更多的是網際網路上的花費大頭，瘋狂投放網路廣告，這些廣告先被門戶瓜分，再經過聯盟一層層盤扣後，流入小 的口袋裡。當冤大頭不投錢了，新一輪的網際網路小 的秋天就來了。而電子商務作為網際網路的盈利模式的根源，能夠養育大量的小 並且自底向上的推動網際網路的大樹的成長。沒有成熟的電子商務作為網際...
網際網路 時代電子商務發展建議
建立健全相關法律體系 在 網際網路 時代，網路資訊科技取得了巨大的進步，並且變得越來越成熟，在很大程度上促進了電子商務快速發展。要想確保電子商務始終處於良好的執行環境中，真正實現可持續發展，我國一定要以電子商務發展的具體需求為依據完善相關法律體系，並將其全面落實，使電子商務取得更好的發展。從電子商務...
基於移動網際網路的電子商務個性化推薦的一些思考
在上週晚上冒著大雨參加了it龍門陣主辦的，由口袋購物候迅發表的主題為 智慧型推薦在移動電子商務中的應用 的主題演講。在演講中，候迅提出了一種 發現式無意識購物 的觀點。很多人在很多時候，去商場，或者去壓馬路，可能並不是專門買什麼而去的，或者是為了專門買什麼而去，但是在逛的過程中，發現了一些 資訊 一...