互聯網IT項目管理有什麼經驗總結和心得體會？

12-29

做互聯網管理很久了，但是和外界交流比較少。希望大家能夠將自己在管理上的經驗分享在這裡，互相學習。這些經驗或是一整套管理流程，也或者是一些細節創新。

互聯網項目管理要點

　　互聯網項目，會定一個計劃發布日期，然而這個項目有個隱藏的實際合理髮布日期。因為軟體開發並不是一個直接添加資源就可以加快速度的過程，所以這個實際合理髮布日期是在現實資源合理利用前提下一個客觀存在的最可能早的完成時間。項目進展的過程，其實也是發現這個隱藏的合理髮布日期的過程。

　　從管理的角度來講，當然是儘可能的趕上計劃的發布時間，或者儘可能快的完成項目。但是因為多方面因素的影響，項目管理是一個欲速則不達的過程。如果這個計劃發布日期早於這個實際合理髮布日期，那你越往這個不合理的日期趕，工期內積累的問題就越多導致後期收尾的時候爆發，結果反而可能連合理髮布日期都趕不上。借用《讓子彈飛》裡面的一句話，步子邁得太大了，容易扯著蛋。給項目組定一個個合理的看得見的小目標，步步為營，一步一步朝著看得見的並且合理的每一個小目標前行，每一個小目標的積累，才能最終走向項目的成功。

　　所以務實的項目經理應該認識到如下幾點：

　　1. 項目組可以以快節奏的步伐在前行，但是項目經理本身一定要清晰的認識到，我們明面上是在趕那個計劃發布日期，但是項目組實際的目標應該是那個客觀存在的合理髮布時間。

　　2. 隨著項目的進行，那個客觀存在的合理髮布時間會逐漸明朗。它與計劃發布時間的差異也逐漸顯示出來。此時有些項目經理往往會通過加資源的方法來嘗試縮短這個合理髮布時間。但是真實的情況是，除非你前期的資源配置不合理，不然在這種情況下加資源，對項目幫助不大。這個地方無須多說，有疑問的人，去看一下《人月神話》就知道了。

　　3. 項目經理必須有一些堅持。領導或者業務部門經常會有一些壓力下來，要求趕那個計劃發布時間，同時要求你想盡任何辦法去趕上這個計劃發布時間。而現實狀況下，如果你能夠調整一些需求的範圍，你還是有戲。不然，你要嘛此時報喜，後期報憂，要嘛此時報憂，後期不憂。掩蓋問題往往可以讓人開心，但是不代表問題不存在。

　　4. 項目經理能做好的其實就5點：

　　 a. 控制好了需求；

　　 b. 及早的發現問題，報告出來並解決；

　　 c. 不出現資源空閑的狀態；

　　 d. 利用好每個資源去做擅長的事，快速有效的推進各種任務；

　　 e. 不浪費資源去做一些對項目目標總體沒有幫助的工作，或者一些後期會推翻的需求。

　　基於這樣的認識下，本文有如下幾個要點：

　　#項目責任感

　　項目經理應該有這個的責任感，你要為這個項目的任何一件事情負責，因為這個事情會影響到整個項目的工期，而你為整個工期負責。

　　一個例子，我發現現在的項目有一個緊急的問題需要項目組外的人幫忙解決。於是我把郵件發出去，通知Wendy趕緊處理這件事情。

　　幾天過去了，Wendy還沒有處理。我想，我已經把問題說出去了，接下去就是Wendy的事情。

　　那個問題還是沒有解決，我的整個工期受影響了。

　　事後追究起來，我說，我已經發出郵件了，是Wendy沒有及時處理。

　　Wendy說，我事情那麼多，我怎麼知道這件事情這麼急。

　　項目工期受影響了，誰的責任？Wendy嗎？不，是我自己。

　　作為一個對整個項目負責的項目經理，沒有人會比你更在意項目的進展。讓一個不負具體負責的人去幫你推進你的項目，遠遠不如你自己用心推進來得有效。

　　#項目經理是打雜的

　　項目組裡面的每個專業成員，他們都有擅長的領域，做他們擅長的事情是他們的快樂。而不屬於他們擅長的事情，對他們來說就算是雜事一般。

　　項目經理一定要有一個這樣的意識：

　　項目經理就是打雜的，幫助項目組成員把雜事處理掉，讓他們可以專心的做他們擅長的事情，這樣對項目組來說才是高效的。

　　一個簡單的例子，測試人員Tracy在測試某個功能的時候，突然發現她需要一個賬號，同時開通這個賬號的某些特定的許可權，同時她需要一些伺服器的信息，比如主機名，某些功能文件夾存放的路徑。但是她不清楚這個賬號和許可權要找誰開通，這些伺服器的信息誰有。

　　Tracy是個喜歡做測試的人，但是她不喜歡跟項目組外的人溝通，特別是還要到其他部門去找人問人。這些對她來說就是雜事，而且她對其他部門的人也不熟，一個一個問明顯效率不高。

　　你可以自己去幫她找到需要的信息，也可以找一個對這方面比較熟的人去解決，但是你絕對不能讓她自己去做。

　　「為什麼我的手下不能解決這麼簡單的問題？如果連這種事情都要我來幫忙的話，那我這個項目經理做來幹什麼？她當項目經理得了。「這種想法千萬是不可取的。

　　你當這個項目經理的目的並不是管人，指使這人做什麼那人做什麼。你的目標只是把項目快速推進完成。

　　#控制需求

　　在所有因素當中，需求對項目的影響力，至少佔50%以上。能夠控制好需求，項目就成功了一半。控制需求，有如下幾點：

　　1. 必須有人能夠當好產品經理這個角色

　　一個項目組當中，其實人人都可以影響需求。但是管理需求的，是產品經理這個崗位。如果你的項目組當中已經有一個很好的產品經理，恭喜你，項目經理可以輕鬆很多。但是世間事不會如此幸運，因為現實生活中，並不是所有的產品經理都這麼棒。作為一個對項目完成負責的項目經理，當你們組沒有一個好的產品經理的時候，你必須意識到，你至少要扮演好一半的產品經理，除非你本身對項目的完成也沒什麼責任感。

　　2. 管理需求的人要平衡工期和功能友好程度

　　需求其實有兩個極端，一個是盡善盡美，儘可能的讓功能更友好，用戶體驗更佳；一個是儘早交付，一切改善性的需求都可以犧牲。

　　只滿足前者，項目工期可能會不斷的拖延，因為很多功能的工作量其實是在細節的優化，而不是主要流程的完成。只滿足後者，很可能會出現一個讓用戶很不滿意的產品。

　　一個有經驗或者產品意識很好的產品經理，可以很好的平衡好這兩點。如果產品經理不能平衡好，那隻好依賴項目經理來平衡。這點，如果產品經理或項目經理不是天才的話，只能通過經驗來學習。

　　比如我們在做一個註冊的頁面，裡面有個城市的輸入框。城市的輸入框可以做得很友好。如果要項目儘早完成，那麼這個輸入框我們只要讓用戶自己輸入就行。一個比較好的設計就是兩個下拉環框，一個選擇省份，然後再選擇城市。但是一個更好的設計是讓用戶既可以選擇，也可以自由的在這個輸入框裡面輸入拼音首字母，漢字，然後系統就會自己顯示相匹配的城市讓用戶選擇。後兩者的改進肯定會花時間，但是如果這兩種改進都不做，讓用戶只是自由輸入的話，後期維護的時候就會出現用戶輸入不標準的城市數據，如果我們需要用戶的城市數據做一些其他功能，就會有錯誤數據的風險。

　　3. 懂得對不重要的需求說不

　　如果你不能平衡好工期跟功能改進的話，有一點你一定要意識好，就是你一定要懂得對不重要的需求說不。這很簡單，你對一個需求說不，只要這個需求不是一個會造成其他功能依賴的核心需求，就算這個需求後面發現必須實現，你可以補上，總體工作量並沒有增加。但是如果你花資源去完成了這個需求，後面卻發現這個需求是不重要的或者可以簡化的，那你已經浪費了一些工作量。兩者的代價相比，明顯前者的代價比較小。

　　4. 理好需求優先順序

　　需求的優先順序應該滿足如下幾點：

　　a. 確定不變的需求應該先完成，如果項目組去完成了一些功能，結果後面發現需求要改，那前期的一些工作量已經浪費了。

　　b. 被其他需求依賴的需求應該先完成，只有這樣，才能不擋住依賴它的需求的開發。

　　比如登錄功能，很多登錄後的頁面都需要當前登錄的用戶信息。

　　c. 主流程，或者核心需求應該先完成，改善性的需求應該後完成。

　　比如信息列表頁面，很多功能需要用戶在信息列表裡面選擇要操作的記錄。因此信息列表是核心需求。而在信息列表頁裡面一個列顯示格式的美化，這屬於改善性需求。

　　#風險管控

　　風險管控是項目經理一個非常重要的技能。一個好的項目經理應該盡量在早期把所有的風險都列出來，一個一個解決。一個流暢的項目，從前期到後期風險點應該是倒三角形的，就是前期風險很多，後期風險越來越少。而項目管理不暢的，則是一個正三角形，上面風險少，到後期風險就多了。

　　項目經理應該儘可能的找出所有的風險點。假設有一個點，你不確定他是不是有風險的，那即使我們把早期把它當做一個風險點重視起來，帶來的代價也遠遠小於在後期等它爆發出來的時候再處理。

　　我們現實中就有一個很適合的例子。我們有一個功能是SSO，讓合作方去調用我們的介面實現免登錄直接從他們的站點跳轉到我們的站點繼續使用。因為關係到第三方，所以我們前期就有些擔心到時候這一塊會不會出現什麼東西不可控。

　　不過大家也就是想想而已，沒有太在意。

　　在項目後期的時候，需要跟第三方站點聯調，通過他們的站點來測試我們的SSO介面和接下去的流程是不是可用的。結果這時候發現，因為第三方安全管控很嚴格，外部人員無法訪問他們的站點。於是我們的測試工作就停滯在那邊。後面弄得雞飛狗跳，兩個公司的IT以及架構組的人討論來討論去看這個問題怎麼解決。

　　發布時間最終還是因為這一點拖延了。

　　#外部依賴最不可控

　　風險管控還有個要點要記住，項目組能處理的問題，算是小問題。需要項目組外的人員處理的，才是大問題。因為項目組外的人員不受你調配，他應承你的時間不一定是你滿意的時間；即使是你滿意的時間，也不一定真的就能確保在那個時間完成；就算真的完成了，也不一定就達到你想要的效果。

　　#必要的時候，任務要步步緊跟

　　項目經理並不是把任務簡單分出去就可以不管的。如果你的開發人員不是很有經驗，或者技術實力很強，思維很縝密，那你應該緊緊的跟進你分發出去的任務。

　　1. 你應該經常去看一下他們的任務開發到了什麼程度，可以的話，讓他運行給你看一下。

　　2. 問一下有沒有什麼問題，有什麼可以幫助他的。因為很有可能他就有個問題在糾結，而其實你因為經驗或者了解更多的背景，很簡單就為他指出簡單的解決方案。

　　3. 你在檢查的過程當中，也會有可能發現一些他可能還沒發現的問題，或者跟這個任務相關聯的問題。

　　任務的完成進度和完成質量，是影響項目進展的一個重要因素。項目經理的一個主要職能，就是幫助每個任務的快速推進。

　　#做當前，看後續

　　當我們把當前的做的迭代的需求，流程，依賴以及其他的疑問理清楚，讓項目組可以順利推進的時候，項目經理不應該再專註在當前的迭代，而是要開始想整理下一個迭代的事情，讓大家在完成當前迭代的時候，不需要暫停在那邊，去等待梳理下一個迭代的問題。

　　舉一個例子，當前的迭代我們在做用戶登錄的功能，做完這個迭代，接下去我們就要做登錄完的首頁展示。開發組在做登錄的時候，項目經理也跟著在那邊搗騰登錄的細節。等下一個迭代開始的時候，項目組才發現首頁展示只有原型圖，UI 跟HTML都還沒做出來，而其他功能更沒有準備。於是項目組就只好花兩三天的在那邊等UI和HTML。

　　#固定的項目組成員

　　這是一個很簡單的要求，但是並不是所有的人都會重視。

　　正如隨便加一個開發人員進來並不能夠立刻讓整個項目進展加快，換一個人的話，整個進展肯定也會受影響。

　　#組員潛力

　　每一個程序員，測試人員，美工，產品經理，都比你想像的要聰明。如果你沒有對你組員的能力有個清晰的認識，那你可以嘗試給他的任務增加一些難度，超過你原來的預期一點點。他能完成，你以後可以再增加一些難度。直到他直接跟你說他搞不定。如果你覺得你已經有個清晰的認識了，那你也應該記得，只是你覺得。

　　我們有一個項目，裡面有個很棒的程序員Joy，平常是個很低調的人。項目經理分任務的時候，就給他幾個特定的模塊讓他完成。他也堅守崗位，做好他份內的事。項目因為種種原因，不斷的拖延。但是Joy還是很誠實的做好他的本分。

　　後來有人跟Joy講，你以後要把自己當dev lead看，所有開發的事情你統籌。

　　Joy還是一個很低調的人，他繼續做他本分的事情，只不過這次的本分就是統籌負責所有的開發問題。

　　接下去就是項目的問題一個接一個的被快速解決掉，其他程序員也得到強有力的幫助，快速處理到自己手頭中的bug。

　　項目進展很快趕上了原來的計劃。

　　你真的很好的發揮了你組員的潛力了嗎？

　　#人人看到全盤

　　項目經理能夠很好的分配好任務，讓各個組員可以較獨立的工作，這是不錯，但也不見得就是好事。因為軟體開發是一個團體的工作，各個人做的事情之間都有交叉。我做的功能，接下去就要調用你的介面。你做的頁面，接下去就要跳轉到我的。

　　Bruce做一個功能，是要顯示公司人員信息的列表。裡面有個操作，選擇一個人員計算出勤率。這個操作不是Bruce完成了，他只要直接調用Lisa的頁面，Lisa的頁面會直接計算出勤率並顯示出來。Bruce認識，他只要簡單傳一個人員的ID過去就可以了。

　　Lisa做這個出勤率的頁面，因為這個人員是屬於業務人員，經常要在分公司跑，所以只能計算他在某一個分公司的出勤情況。她以為大家都知道。

　　等大家都完成了，QA在測試的時候，發現在人員信息列表裡面點進去，顯示不了出勤頁面。整個流程都走不通了。

　　後來才發現有2個問題沒解決好，一個人員信息跳轉到出勤頁面前要傳遞當前的分公司信息，一個是出勤頁面還要增加選擇分公司的功能。

　　這2個問題一個是QA測出Bug，一個是需求還有不足。而這本來是應該在開發周期內就可以發現並解決的問題。

　　根源就在於，Bruce跟Lisa在做手頭任務的時候，都沒有去考慮跟其他人的關聯。而他們2個人都沒有去考慮的話，其他人更不會去考慮了。

　　如果Bruce或者Lida在做任務的時候，去想想他們彼此怎麼串聯起來，這問題本身就很簡單了。

　　項目組的每個人，可以重點在自己手頭的任務，但是思路必須是在全盤，大家腦子裡面都要經常去想想，整個系統是什麼樣子的，我的功能前後的依賴是什麼樣的。項目經理平常要引導大家這樣想。

　　#一定要分成每一個小迭代

　　步伐邁得太大了，你就不知道你邁得對不對，邁得夠不夠快。項目是不可能一步到位的。把一個大目標分解成每一個小目標，整個項目工期分成若干個短迭代，一個一個的完成。每一個完成的小目標都能幫助你理清整個項目的進度，方向，幫助你審核一下目前的思路是對的還是錯的，出錯了，也能夠及時的調整。

　　#不做一半的功能

　　如果我們做了2個功能，但是我們每個功能都做了一半沒全部完成，那目前為止我們總計完成了多少個功能？1個？

　　不是的，完成了0個。一個功能除非真正完成並且通過產品經理的檢查，不然你永遠不能確定這個功能是不是還有一些遺漏的地方。

　　100個完成度為90%的功能合起來，完成的功能還是0個。你很興奮你的程序裡面有很多功能，但是你試了一個又一個，結果發現每個功能都是半成品，沒有一個功能可以正確解決你的問題。

　　對於半成品的功能：

　　1. 你其實並不知道你還剩多少工作量，因為已經「完成「的工作不能驗證說是真正完成的。

　　2. 你沒法給業務部門或者客戶做演示，因為這些功能沒做完。

　　3. 如果業務部門讓你暫停一下，就先按照目前已有的功能去讓客戶測試一下，你會啞巴吃黃蓮，有苦說不出。

　　所以我們做功能的時候，要確保我們在做的功能已經是真正完成了，我們再去接著做下一個功能。

　　#不讓細節影響你的目標

　　項目組的人很容易沉浸在功能的細節當中，為一些友好美觀的顯示，炫麗的功能或者很酷的設計浪費大把的時間，忘記了這個項目的最終目標是什麼。其他人可以投入，但是項目經理一定要能夠抽身事外，專註在項目的全局。沉浸在細節當中很容易讓人忘記工期，忘記項目的最終目標。

　　我這個提示信息的顏色會不會太淡了？要不要再調深一些？

　　我這個按鈕是不是可以往左邊移10像素，這樣更好看？

　　這個地方要不要來一個自動提示，這樣會更友好一點？

　　我這個面板的顯示要不要使用漸變的？1秒內漸變完成會不會太快？用戶會不會還沒看夠？

　　你先把功能完成再說好嗎？以後有的是大把的時間美化這些。

　　#正確的里程碑要點

　　我們碰過一個項目，項目經理的報告說，目前的狀態是開發完成。結果一看，這樣說的依據是分配到所有開發人員的任務，開發人員都認定為完成了。於是大家就認為目前是開發完成，進入QA測試的階段。

　　結果QA報怨測試不下去，流程都走不通。產品經理進去看了一下，也說很多地方功能缺失。根本不能認定為開發完成。

　　1. 一個項目，或者一個短迭代，應該先列出一個所有人都認同的里程碑列表。

　　比如，分為框架設計完成；分解出來的需求已經可用於開發；子任務劃分完成；子任務已經分配並預估完成；各子任務完成；開發人員整合測試完成；產品經理檢查通過；QA測試通過。

　　2. 每個裡程碑的完成要有大家都認同的驗證方式

　　比如如何判斷開發人員整合測試完成，是不是開發人員坐在一起或者開發組長把所有流程都走過一遍，然後發現沒有什麼大的問題？

　　#自我管理

　　前面講了這麼多，弄得好像項目經理很重要，缺了這個項目經理整個項目就不轉了。如果項目經理的手下是固定的，只不過做的項目不一樣，那我建議項目經理在完成項目的基礎上，一定要考慮這樣一個目標：

　　建立一套流程，一套大家都熟悉並且會遵守的流程。這個流程可以保證整個項目組在項目經理不在的情形下，也可以運轉得很好。

　　目前項目處在什麼階段，這個階段大家要做什麼，下一個階段是什麼；這個階段有什麼任務要做；每個階段碰到問題要怎麼處理；每種任務或者問題由誰來處理。這些並不是很難學會的東西。項目的成員經歷過幾次，很容易就可以理解要怎麼做。項目經理除了推進項目以外，還要在項目的過程中把流程的思路，解決各種問題的思路教給大家，同時明確每個人的職責，達到項目組可以自我管理的程度。

　　一個可以自我管理的項目組，才是一個穩定高效的項目組。項目經理才可以抽身出來，同時去做一些其他的對部門，對公司同時也對自己有利的事情。

通用的：

任何的項目管理，都要自上而下支持，自下而上不是不能做，你會發現異常艱苦
在國內，無論你是用PMP那一套還是敏捷還是土辦法，任何做項目管理第一條都是「人際關係」，搞好了人際關係，你會發現任何的項目你都能做的順風順水，否則被玩死是必然的
項目管理是綜合性能力，除了專業技能之外，還有一個就是「平衡」。平衡進度與成本、平衡開發人員之間的關係、平衡所有可以平衡的事情
風險管理很重要，絕大多數項目失敗，都是風險管控沒有做好導致的問題

瀑布：

做好計劃很重要，但是一開始不要過分細化，有一種概念叫「漸進明細」
變更控制要作為重中之重來處理，任何的變更都要仔細分析並記錄，否則項目做完，你會發現和一開始的項目章程完全兩樣
時間、進度、成本你只能控制其中兩個，三個一起控制你是做不到的，或者說不能長期做到（加班這種事情，不能是常態

敏捷：

敏捷的實施比瀑布難，難很多
敏捷最重要的是理念的堅持
儀式（站立會、回顧）能給你帶來的好處值得你堅持

自己這幾年創業主要是和研發項目管理打交道了。自己公司主要的研發管理框架是scrum + xp。不過我們也做了適當的變通。比如xp裡面我們並沒有做單元測試，持續集成等實踐，而是代之以開發人員的自測，互測，集中代碼評審，集中功能評審等方式來保障代碼的質量。這幾年下來效果還是很不錯的。人力投入比較少，發布速度比較快，取得了比較好的效果。

整體的公司管理上我們在互相信任基礎上拋棄了所有可能的管理制度，比較適合小團隊管理。這樣大家的溝通成本可以降到最低，可以形成合力，減少內耗。

既然是說體會，我自然是拉來了我們豈安科技項目助理文龍。文龍同學，2年Unity開發，AR及人臉識別相關領域經驗，曾供職贊想科技，負責FaceChat臉說產品設計及項目開發實施。現任豈安科技Warden和Red.Q風控產品項目助理。以下，GO~

不知不覺加入豈安這個大家庭已經3個月了，在這之前我是負責設計及管理移動端某款短視頻人臉識別App的項目，幾乎未曾接觸過互聯網安全風控系列產品，在這三個月的時間經歷了豈安兩個產品的三次迭代開發過程收穫很大，所以很高興能來分享下這段時間參與項目管理過程中的一些感悟。

1需求確認會的必要性

為了提高效率減少未來的溝通成本，所以在需求確認會上必須分清此次迭代的需求優先順序，確保技術部門充分理解需求方便之後的拆分任務排期。作為 PJM 要保證在有限資源下，期限內最大限度的完成產品需求的既定目標。

一、Scrum每日早會

相關 TeamLeader 參與即可（視項目情況而定，有些需產品負責人參與），每日站會時間不需過長，對應既定的排期 Milestone（里程碑）跟進進度，只需關注三大點：

我完成了什麼？
我計劃做什麼？
目前有什麼困難阻礙了我的進度？

此階段是對項目的實施過程進行監督、檢查、協調，將資源利用最大化和盡量將風險時時刻刻的降到最低。

二、關於風險的把控

即便是排下了認為最理想的開發迭代時間表也有突如其來的風險時刻，比如 xxx 今天生病臨時請假，或者重要客戶的臨時部署，亦或各種未知的嚴重 bug…..

對於目前的風險管理我的做法是在與技術部門評估開發任務時間及拆分任務安排時，儘可能地考慮到風險點，預先留有應急的空間盡量減少對項目產生的致命影響。

往往經驗豐富的項目經理對於風險的識別及及時調整有著獨到的處理方法，我也在朝著這個方向努力的前進著。

一點建議

說句題外話：之前在做短視頻人臉識別 app 的時候，因為人臉識別關鍵點需依託第三方 SDK 實現。涉及 AR（增強現實）這種功能時常常要考慮到配合移動端的性能做優化，比如強弱光時候的識別靈敏度，搖晃臉部時識別角度界限的穩定性及引擎在移動端顯示的渲染效果等等。

我想表達的是對於需要第三方技術力量配合或主導時，必須協調好既定目標，只有雙方同時明確一個目標時方可進行下步安排，比如人臉識別後關於效果的設定：磨皮程度，瘦臉程度，2d/3d 素材的最終效果……..

一點分享

給大家大致分享下我平時所使用的工具：

?前期準備工具：Mindjet，百度腦圖，Evernote（作為文本記錄非常方便）；
?項目制定工具：Excel（燃盡），Project（排期）；
?項目跟蹤工具：Tower 或 Worktile 均可；
?Bug反饋：蒲公英，禪道（強烈推薦）；

一點總結

總之一個項目，

有明確的開始和結束時間
有明確的質量監控和要求
有明確的投入和產出

這些是項目管理的核心。項目經理的工作就是規劃和協調各種內部外部資源，保證項目進度和質量。不同公司項目經理的工作具體會有不同，但是大致的套路和職責基本一致，例如：計劃，組織，領導，控制。

最後介紹一下我們的團隊，大概就是安全風控屆里王者打的最好的，王者圈裡風控業務做的最強的。最後，更多的行業觀點和乾貨內容可以關注我們的微信公眾號：bigsec。嗯就是這樣~

其實做項目管理，還是要多跟外界交流，透過會議能聽到一些業界大牛的實戰分享

我認為項目經理其實要考慮業務與團隊。

對於業務，互聯網變化很快，產品項目是否有找准方向、設計好戰略與商業模式、建立獨一無二的競爭力？不然方向沒想好、需求就一定有問題，需求有問題，就會導致後面一連串的浪費。

關於團隊，其實互聯網現在很多人用scrum，這裡就不贅述。具體可以上網或買書，我們自己也出過一本書《網易一千零一夜》裡面也涵蓋理論與實際。但具體每個團隊特性不一樣，找到符合自己的最重要。

當然還有很多跨界的方法，設計衝刺、商業畫布，其實都是可以幫助團隊與業務做創新改善。

今天剛看完網易出的項目管理實踐經驗，網夜一千零一夜。裡面很多項目管理知識與經驗總結，也推薦給大家