1樓：網易數帆
在網際網路時代背景下，產品的研發也早已不是設計好乙個產品，然後花個1年時間研發完成後發布這樣的形式。無論是《精益產品》還是《設計衝刺》都有乙個最小可用產品的概念去做市場驗證，然後增量發布，不斷再驗證再調整，每次發布可能只有1-2周，甚至早期以天來計。所以相比以前的產品研發，不僅僅要快，還要有市場驗證的環節來完成產品的完整閉環。
這也是我們曾經對於專案管理專注研發的乙個很糾結的點，要不要包含市場運營？怎麼做？做到什麼程度？
現在的答案是肯定的，但是是在專案經理的定位下，圍繞我們的核心目標去做市場運營的工作。如下圖所示：
上圖描述了我們的網際網路專案管理的核心框架，包含了產品探索、產品研發、產品運營這三個環節形成乙個閉環，圍繞著效能的核心目標。每個環節都有其相應的核心過程，核心指標，以及相應的最佳實踐。
我們在產品探索、產品研發已經定義好了適合網易杭研特定情況的主要過程，而在真實的產品中，專案經理們都是基於這樣的主要過程而演化出各自產品的具體流程。換個角度說， 我們也是在基於專案經理們在各自產品中的具體實踐而抽象出了共同的主要過程，而成為我們網際網路專案管理體系的核心過程。該過程一定程度上是在網易杭研特定環境下抽象出來的，還不一定能夠適合到更廣泛的標準中去。
至於產品運營的核心過程，我們在一定程度上還有爭議，還需要更多的經驗總結，在此時就按下不表，希望在不久的將來，在我們新的文章、分享中能夠具體介紹。
l產品探索
如上圖所示，乙個完整閉環的產品功能會經過策劃、互動、視覺、研發和驗收的過程，而產品策劃要對整個過程負責直至功能按照預期上線驗收。這裡對於產品策劃的職責基本上涵蓋了產品研發的所有內容，對於簡單團隊來說，產品策劃跟進到細節還是可以做到的。基本上來說，他已經是乙個具有專案管理能力的產品經理了。
但是對於複雜團隊來說，讓產品策劃跟進每乙個協作的細節，著實是一件比較吃力的事情，但是做到跟蹤和支援， 卻是必要的，但無論怎樣對最終上線的功能負責這一點是毫無疑問的。
l產品研發
如上圖所示，乙個產品版本（多個功能點）會經過分析、設計、評估、開發、測試和上線的過程，而產品開發要對整個產品版本的過程負責直至上線驗收。這整個過程看似是乙個瀑布的過程，但並不妨礙我們採用敏捷的研發方式，只不過裡面的每個部分是簡單略過，還是著重強化，是手工處理還是自動化工具。因為我們可以根據不同團隊的現狀，採用不同的方式， 甚至逐漸變化演進，根本的目的還是為了達到更好的效能。
這個過程在一定程度上是被產品探索的過程所包含的，同時產品策劃和產品研發的職責也是有一定的重疊的，但這也沒有關係，不是嗎？因為他們的目標應該就是要統一的。
l產品運營
l效率
投入產出比=完成規模/完成週期的總人力投入
我們通過定義不同「完成」的規模和各個環節所需的人力投入來進行計算，從而得出不同環節的投入產出比，應用在各個環節。
例如：在產品研發環節，「完成規模」可以定義成已經上線並通過產品策劃驗收的所有功能大小，而「完成週期的總人力投入」可以是進入產品研發階段的所有人力投入。而在產品探索環節，「完成規模」可以定義成上線並且達到功能設計預期的所有功能的大小，而「完成週期的總人力投入」除了研發人力還需包括產品策劃、互動、視覺等。
這個投入產出影響的因素很多，比如：人力成本，時間成本等等，在一定程度上和我們的閉環週期也有關係，能夠幫我們發現很多可能存在的問題。
l質量
線上Bug數=一定週期內線上環境發現的Bug數總和
這是乙個比較簡單指標，同樣的，我們對於Bug引入的環節的不同，來定義不同環節的質量
例如：在產品設計過程中就引入的bug，還是研發過程中引入的bug。
l週期
產品交付週期=產品功能從開始策劃到驗收上線的時間
研發週期=產品版本從計畫開始到實際發布的時間
這兩個指標，分別從產品探索環節和產品研發環節，來衡量產品的響應能力或者說是自我調整的能力。我們經常說現在的產品研發要「快」，更多的其實是指交付週期，這也是乙個非常重要的指標。
使用資料統計的專案經理們往往會進入兩個誤區。
誤區一：資料作為評價產品和團隊好壞的標準
資料作為對乙個複雜系統的評價，是不客觀也不完備的，至少我們所統計的或者看到的資料量是遠遠不夠的。如果抱著評價乙個系統的方式去看待資料， 那麼很容易就會使用資料來對人員和團隊進行績效考核並反推他們「改進資料」本身，而非實質意義上的改進。而另一種態度是承認資料無法完整評價人員或者團隊，從而對於統計資料就產生了懷疑，甚至於不願意去統計資料。
這兩種態度都是對資料本身的作用誤解，我們是要拿資料去監控和發現問題，並對他們進一步分析，從而採取有針對性的措施，進行改進，而非評價。
誤區二：忽視忽略資料所展示出來的問題
我們剛開始統計資料，資料的結果往往不是我們想象的那樣漂亮，而是偏離標準非常遠。有一種情況就是我們會認為這是一種可接受的現狀，並對資料所展現出來的問題進行選擇性的接受。而資料展現出來的問題是不是乙個需要正視的問題，是應該由我們對這個問題做進一步的分析，有必要的時候需要再把這個資料分解（分階段、分角度、分場景等等）來找到產生這個差異的真正原因，從而採取一些必要的措施，逐步改進。
當然也許這個資料展現出來的問題，並不是乙個真正的問題，那麼我們就該思考是否還有必要保留這個資料指標，並用真正合理的演算法和指標來取代他。
網易雲 - 知乎
2樓：泛微移動辦公
有效的IT專案管理可以為企業控制交付風險與財務風險，更好的為企業降低成本，提公升經濟效益與優化管理模式...
泛微為眾多網際網路客戶提供過IT專案服務，積累豐富表專案管理經驗，用OA系統打造全過程專案管理平台！幫助企業專案計畫任務明確化，專案合同管理規範化，費控與成本歸集智慧型化...
1、專案立項泛微OA系統通過專案立項申請將立項工作流程化、標準化；實現專案過程目標任務清晰，權責得到有效落實，追溯完整，強化了專案督查。
2、合同管理合同全生命週期管理通過合同資訊完整記錄，讓審批更加便捷、高效；全面靈活報表，協助專案順利推進。
3、專案執行在專案執行的各環節進行精細化管理，有效管控專案風險。
4、專案費控從指導、監督、調節和限制多角度進行費用管控，最終提高企業費用支出的時效性和準確性。
5、成本歸集泛微OA系統針對專案全過程發生的人力成本、資產成本、費用開支進行自動歸集分析，並生成費用統計報表。為專案預算提供實際決策依據，同時成為專案參與人員績效考核標準。
更多網際網路IT專案管理案例內容請登入泛微官網！
3樓：anytao
從定義可以看出，IT專案管理其本質上還是對專案的管理。在我看來，無論是專案管理還是IT專案管理，這個過程都繁瑣且複雜，因此，一款簡單實用的專案管理軟體必不可少。
綜合這麼多年IT專案管理的經驗，給大家良心推薦專案管理軟體Worktile。
Worktile 作為一款以專案協作為核心的軟體，其在專案管理上的應用主要有以下幾點：
1）看板式專案管理
跟蹤任務在整個價值流中流經的不同階段，具體特徵如下：
流程視覺化：將工作拆分成小塊，一張卡片寫一項任務，再把卡片放到牆上，每一列都起乙個名字，顯示每件任務在流程中處於什麼位置。
限制WIP（work in progress)：明確限制流程中每個狀態上最多同時進行的任務數。
度量生產週期：對流程進行調優，盡可能縮短生產週期，讓所有人都參與進來，了解工作進度，負責人等資訊。既有利於專案經理對整體的把控，也有助於每個參與者明確自己的職責。
2）任務管理
所有成員均可在工作台規劃安排自己負責的任務，待辦事項清晰可見，井井有條。
在任務詳情中，可以設定負責人、專案開始/結束時間等基本資訊，還可進行子任務建立、任務分享等操作，日常事務管理簡潔方便。
3）專案統計
實時資料展現，支援專案內統計和任務全域性統計，通過多維度統計圖表清晰展示任務情況，企業、專案及成員進度一目了然。
專案內任務統計：統計專案任務完成情況/工時/進度資訊，快速掌握該專案完成進度及延誤率、成員任務量及完成度。
全域性統計：系統內建多個統計圖表，分別從企業、專案、成員等多維度進行統計資料展示；此外，還可自定義任務統計圖，按企業、專案、成員不同級別，對任務情況進行更加細節的展現。
除了以上這些還有任務管理很多功能，有興趣的朋友可以去【Worktile官網】看看，了解一下。
4樓：網易杭研專案管理
其實做專案管理，還是要多跟外界交流，透過會議能聽到一些業界大牛的實戰分享
我認為專案經理其實要考慮業務與團隊。
對於業務，網際網路變化很快，產品專案是否有找準方向、設計好戰略與商業模式、建立獨一無二的競爭力？不然方向沒想好、需求就一定有問題，需求有問題，就會導致後面一連串的浪費。
關於團隊，其實網際網路現在很多人用scrum，這裡就不贅述。具體可以上網或買書，我們自己也出過一本書《網易一千零一夜》裡面也涵蓋理論與實際。但具體每個團隊特性不一樣，找到符合自己的最重要。
當然還有很多跨界的方法，設計衝刺、商業畫布，其實都是可以幫助團隊與業務做創新改善。
5樓：東子Geek
#控制需求
在所有因素當中，需求對專案的影響力，至少佔50%以上。能夠控制好需求，專案就成功了一半。控制需求，有如下幾點：
1. 必須有人能夠當好產品經理這個角色
乙個專案組當中，其實人人都可以影響需求。但是管理需求的，是產品經理這個崗位。如果你的專案組當中已經有乙個很好的產品經理，恭喜你，專案經理可以輕鬆很多。
但是世間事不會如此幸運，因為現實生活中，並不是所有的產品經理都這麼棒。作為乙個對專案完成負責的專案經理，當你們組沒有乙個好的產品經理的時候，你必須意識到，你至少要扮演好一半的產品經理，除非你本身對專案的完成也沒什麼責任感。
2. 管理需求的人要平衡工期和功能友好程度
需求其實有兩個極端，乙個是盡善盡美，盡可能的讓功能更友好，使用者體驗更佳；乙個是盡早交付，一切改善性的需求都可以犧牲。
只滿足前者，專案工期可能會不斷的拖延，因為很多功能的工作量其實是在細節的優化，而不是主要流程的完成。只滿足後者，很可能會出現乙個讓使用者很不滿意的產品。
乙個有經驗或者產品意識很好的產品經理，可以很好的平衡好這兩點。如果產品經理不能平衡好，那只好依賴專案經理來平衡。這點，如果產品經理或專案經理不是天才的話，只能通過經驗來學習。
比如我們在做乙個註冊的頁面，裡面有個城市的輸入框。城市的輸入框可以做得很友好。如果要專案盡早完成，那麼這個輸入框我們只要讓使用者自己輸入就行。
乙個比較好的設計就是兩個下拉環框，乙個選擇省份，然後再選擇城市。但是乙個更好的設計是讓使用者既可以選擇，也可以自由的在這個輸入框裡面輸入拼音首字母，漢字，然後系統就會自己顯示相匹配的城市讓使用者選擇。後兩者的改進肯定會花時間，但是如果這兩種改進都不做，讓使用者只是自由輸入的話，後期維護的時候就會出現使用者輸入不標準的城市資料，如果我們需要使用者的城市資料做一些其他功能，就會有錯誤資料的風險。
3. 懂得對不重要的需求說不
如果你不能平衡好工期跟功能改進的話，有一點你一定要意識好，就是你一定要懂得對不重要的需求說不。這很簡單，你對乙個需求說不，只要這個需求不是乙個會造成其他功能依賴的核心需求，就算這個需求後面發現必須實現，你可以補上，總體工作量並沒有增加。但是如果你花資源去完成了這個需求，後面卻發現這個需求是不重要的或者可以簡化的，那你已經浪費了一些工作量。
兩者的代價相比，明顯前者的代價比較小。
4. 理好需求優先順序
需求的優先順序應該滿足如下幾點：
a. 確定不變的需求應該先完成，如果專案組去完成了一些功能，結果後面發現需求要改，那前期的一些工作量已經浪費了。
b. 被其他需求依賴的需求應該先完成，只有這樣，才能不擋住依賴它的需求的開發。
比如登入功能，很多登入後的頁面都需要當前登入的使用者資訊。
c. 主流程，或者核心需求應該先完成，改善性的需求應該後完成。
比如資訊列表頁面，很多功能需要使用者在資訊列表裡面選擇要操作的記錄。因此資訊列表是核心需求。而在資訊列表頁裡面乙個列顯示格式的美化，這屬於改善性需求。
網際網路是否需要專案管理
象天飛的專案思維 從專案本身角度而言，任何專案都需要專案管理，如何滿足需求，如何明確專案的範圍，如何分解任務和分工，如何控制進度 成本 質量 風險等，所有專案都要面對和解決這些問題，都需要有人來思考 策劃和管理.從人的角度而言，到底是否需要有人單獨負責專案管理工作呢？要看專案大小 專案管理的複雜程度...
非網際網路人士如何轉行網際網路？
產品一哥 你要掌握知識點有 網際網路思維，運營方法，運營是什麼，它是幹什麼的，它的工作目標是什麼。這些都是要掌握的，否則就算你轉行成功了也將無從下手。產品一哥 萬字乾貨！0基礎如何拿到產品經理offer 0基礎如何拿到產品經理offer 資料分享 資料提取碼 z8nr 0基礎如何拿到產品經理offe...
什麼是裝修？什麼是網際網路 ？什麼是網際網路裝修？哪個平台算得上網際網路裝修？哪個平台的模式與方向有潛力？
什麼是裝修？答 從毛坯房到精品房的過程！什麼是網際網路 答 借助網際網路渠道，重塑傳統經營方式，就叫網際網路 什麼是網際網路裝修？答 現階段還沒有一家網際網路裝修，頂多叫裝修網際網路化，真正的網際網路裝修類似於網上下單，線下確認，線上支配，線下施工，整體交付。哪個平台是網際網路裝修？答 有很多自稱為...