你的團隊內部是如何進行項目管理和協作的？具體流程如何？使用什麼工具呢？

12-11

做個比較粗淺的關於項目管理的分享，順便給我大Worktile 打個軟廣

首先，我們先來看看幾個在管理項目過程中常常遇到的問題：

任務不明（unclear tasks）
溝通不暢（communication is expensive）
雜亂的文件管理（failed in documents management）
缺乏用戶參與（lack of user participation）

（當然還有其他關於項目管理遇到的問題，歡迎補充討論）

任務不明

解決這個問題我只需回答以下4個問題即可：

做什麼
為什麼做
誰來做
截止日期是哪天

這些是在項目中幾乎每天都會問到的問題，我們之前也會用一些工具來呈現問題的答案，但問題是，呈現的內容真的回答了我們提出的問題了嗎？
（先來看這樣一張圖）

是不是很眼熟？很專業？讓人感覺不明覺厲了吧？但是並沒有完全回答了我們上面的問題
切換到看板的模式來對比下

清楚的回答了做什麼，誰在做，哪天截止的問題，至於為什麼做，可以在任務詳情中查看任務的始末。

然後我們在回過頭看看以上的幾個問題是不是完美解決了？！Cool ！

Worktile Tips:為任務添加恰當的標籤也很重要，方便日後篩選任務

關於溝通

我們經常會抱怨，部門與部門之前，同事與同事之間，上級與下級之前溝通不暢。先讓我們思考以下幾個問題。

溝通的根本目的是啥？
引起需要溝通的原因是啥？
多溝通是給你帶來了效率還是帶來更多的加班時間？
做一個任務，溝通的時間比完成任務的時間還要多，你覺得值么？

想清楚這幾個問題，我們會發現問題發生在任務上。引起溝通的原因往往是因為任務/需求不明，只要做好第一點，你會發現其實基工作中的溝通也不需要那麼多，甚至發現：過多的溝通才是工作效率的最大敵人。
我們只需要做的就是：

為任務添加詳細的描述，包括任務要做到什麼程度，驗收的標準是什麼，可以以列表的形式一一給出說明
將任務分配到相應的人身上，如果是需要多人共同完成的任務，可以通過檢查項分別@每個執行者，明確每個人的職責

靈活的資料管理

雜亂的資料管理會讓你在找文件的時候恨不得把自己弄死。文件找不著了么？用郵件附件來發送文件么？網盤和U盤的文件滿天亂飛么？對於這些問題，你只要一些小技巧就可以跟這種狀態說拜拜了，在Worktile上，資料（文檔，文件）管理有以下幾個建議：

充分利用文檔－－子文檔的層級關係組織項目文檔，你還可以通過歷史版本來追溯你想要的內容
創建有規律的不同文件夾來存放不同的文件，然後在你想找文件的時候可以利用文件的篩選和排序快速定位文件
團隊成員的創意和想法，則可以在話題中討論，日積月累就會形成團隊的靈感池。

獨立的任務列表收集客戶反饋

讓你的客戶也參與進來吧，直接又有規則的提出需求絕對是你與你們客戶和諧相處的一大法寶，利用Worktile可以將一個清晰透明的項目進度呈現給你的客（lao）戶（ban），只需將他（她）設置成訪客的身份即可

最後

讓我們「多走一步」（one more step）看看，其實決定團隊工作效率和質量的，最終歸結還是在於人。因為每個團隊有各自需要遵守的規則，比如標籤的設置與定義，文件和文檔儲存的格式，驗收的標準是什麼，獎懲制度是什麼樣的等等.....所以，工具是輔助，根據團隊的實際情況制定適合團隊的規則才是靈魂。

希望與各位親們討論更多

原文來自《10分鐘成為高逼格PM》

推薦我們自己的產品Worktile ，下面的視頻小故事更有助於您了解我們對於協作的理解和工具的價值定義，謝觀賞。

Worktile，讓工作更簡單！視頻

我所在的團隊只有十幾個人，其中產品設計、開發人員只佔到一半，而且都十分年輕，因此項目管理和團隊協作對於我們來說也是一件正在探索和學習的事情，談不上對錯，寫出來僅供與大家交流。

首先，對於項目管理，我們的是：

結果導向，不拘泥於形式，允許試錯
數據直接在雲端存儲
機器能做好的事情，不要讓人去做

另外，我們認為，要做好項目管理，關鍵是將工作任務拆分到足夠細化，明確好每個事項的責任人、產出結果、驗收時間及獎懲。

由於團隊較小，我們每個人的工作都是直接向 CEO 彙報的，而我們的 CEO 也十分強悍，每天上班前都能初步安排好每個人當天的工作任務（未來團隊擴大後也許不適用）。9 點是我們的晨會時間，一般持續 10 分鐘左右，為站立會議，議題只有一項：CEO 和每個人確定當天的工作任務。我們沒有昨日工作彙報，因為每天只有工作任務完成後才能下班，否則會扣除績效。也許很多團隊崇尚自由，沒有固定的上下班時間，或者對每個人充分信任，不要求將每項工作的時間定得過細過死。但我們的觀點是，如果團隊足夠優秀，是有能力做到被精細管理的（往往高效的方法都不是隨性的；備註：團隊擴大後，就無法保證每個人都足夠優秀了）。

在工具方面，由於團隊的工程師文化偏 geek，所以初期我們購買了不少高端服務（是否高端，見仁見智），比如說 Confluence、LayerVault、Dropbox、OmniPlan、Trello、slack。而 QQ、微信則被明確定位為生活溝通工具，不用於工作討論（雖然很多公司把微信也用在了工作中）。下面，基於項目管理的事項和流程來逐個簡單地介紹一下這些工具吧：

Conflunce

我們公司制度、學習分享及產品策劃的文檔會放在 Confluence 上，分成 3 個 board，理由是文檔類的信息直接在網頁上編輯和存儲，查閱和管理起來都會更加直觀和高效。

LayerVault

Layervault 是一個很高大上的設計管理工具，是以
web 的形式存在的。設計師可以將設計稿的預覽、切圖、標註甚至 Psd 文件發布到上面，邀請團隊其他人員查看和討論。但由於我們的設計經常改動，在 LayerVault 上進行發布和非同步討論似乎跟不上迭代的速度，所以後來還是放棄了，對設計的評審、發布我們目前仍在摸索更合適的方式。

Dropbox

Dropbox 以文件夾的形式進行共享與同步對於管理設計稿來說十分方便，我們現在的交互稿、視覺稿都是用 Dropbox 來管理的。

OmniPlan

OmniPlan 一般比較少用到，只是在規劃新版本的開發進度時使用，有點類似甘特圖，將所有需求進行拆分、排序、排期及指定責任人。

Trello

Trello 相當於網頁上的一塊大白板（沒有寬度限制），團隊成員的每一項工作任務都會以 card 的形式貼上去，並設置好
due
date（驗收時間，只能精確到某一天）和
members（責任人，可以是多個）。當一項任務完成並經過驗收後，把 Trello 上相關的card歸檔即可。

但後來 Trello 在團隊協作中漸漸被我們拋棄了，因為我們的任務已經拆分得足夠細，而且都是每天驗收的，用即時聊天工具來得更方便一些。所以，Trello 現在已成為我個人工作任務的 To Do List了。而對於個人事務管理，團隊其他成員更多的是用 OmniFocus。

Slack

Slack 是一個即時聊天工具，可以在網頁上使用，也可以下載客戶端使用。我們在 Slack 上有劃分不同的頻道，比如說 General、Design、Development 和 Operation 等等。特定的話題只能在特定的頻道討論，這樣每個人可以根據自己的需要加入和退出某個頻道，從而減少信息干擾。另外這樣做還有一個好處是可以很快地查找歷史消息。當然，除了在頻道里群聊，也可以單獨和團隊的某個成員私聊。我們工作中大量的碎片化溝通都是通過 Slack 完成的。

以上的工具看起來有點多，而實際上也確實有點多。但當你用起來之後，其實不用多久就能熟悉，並且會發現能明顯地提升工作效率。其實就使用頻率而言，最常用的只有3個：Confluence、Dropbox 和 Slack，其它的偶爾發揮一下作用即可。

----------------------------- 2015 年 6 月 20 日更新-----------------------------

現在團隊規模已經是之前的兩倍多，產品文檔重新用 Confluence 管理，並且使用了兩個維度來組織，一個維度是基於功能模塊的，可以快速地查看某個功能模塊最新的產品設計是怎樣的；另外一個維度基於版本，可以查找到每個版本更新的功能特性，也可以在上面同步每一輪測試的結果，把發現的問題做成任務列表，這樣可以查看最新的測試及修復進度。

LayerVault 已被完全棄用，因為分工明確後，設計評審的範圍窄了很多，方案確定後一般不用怎麼修改。

Dropbox 依然被用來同步設計稿、切圖、標註等文件。

Trello 用來做需求池及開發看板。

Slack 為產品設計及開發同事的即時溝通工具，全公司範圍的話用 QQ 群就夠了，一般都只是聊些輕鬆的話題。

----------------------------- 2015 年 10 月 20 日更新-----------------------------

Trello 已基本被棄用，主要原因是任務的層級拆分有限，取而代之的是 Asana 。Trello 已成為我個人的需求池以及產品部門的工作計劃板。至於 Asana 的介紹，待日後進一步熟悉後再寫。

----------------------------- 2015 年 11 月 15 日更新-----------------------------

一開始，只有開發團隊使用 Asana，後來為了統一管理產品開發這個大部門，產品團隊也開始使用 Asana。與 Trello 相比，其實大部分用到的 Asana 的功能 Trello 也有，但在任務指派、跟進和溝通的使用上，Asana 要更方便一些。原本想著 Asana 還能起到績效管理的作用，但目前來看並不明顯，因為並不能在 task list 頁面直接查看各個任務是否有 delay（後來針對這點給了解決方案，就是標記完成時如果有 delay 要備註在 task 標題後面），但如果有很用好地使用任務評論功能，倒是能查看一個設計任務修改了幾版方案才完成，並且也省去了工作日報、周報這個煩人的事情。

所以，後來設計了幾條產品設計團隊任務管理的規則：

1. task 可以由主管或自己發起

2. task 只能由主管標記完成，主管標記完成時需要記錄交付是否有延遲，若有延遲，需要在 task 原標題後面標註延遲 x 天，x 的最小顆粒度為 0.5 天，如：app 改版策劃（延遲 0.5 天）

3. 每個 task 的產品及交互設計方案的每個內部評審版本都需要在評審前以附件的方式上傳至 task 評論區域，每個版本的評審意見在評審後需要記錄至 task 評論區域

4. 每月的績效考核包含 task 的完成量、延遲率、內部評審方案版本數以及考勤

我們現在核心使用四個。

背景：我們是一家小型影視公司，平時的工作80%是以文檔的來往為主。之前只是通過郵件溝通（當年一直用gmail，後來被牆後換為了騰訊企業郵），後來我們增加了一些工具的使用。大概用了以下幾個:

第一：worktile （團隊協作與分工）
用來做項目協作的管理。當時在worktile和tower裡面做了選擇，看中了worktile更美觀（沒辦法，公司的人都看顏）。整體來說還是比較滿意，缺點是移動端的功能還遠遠不夠完善，以及某些交互設計的邏輯有點累贅。

第二：釘釘（即時通訊）
本來是請我們信息總監在pubu,紛雲，telegram等還有四五個主流im裡面選擇。信息總監選擇了pubu，但是最後我選擇了釘釘。主要看中了絕命連環無敵ding的功能，以及可以提供一些簡單的企業流程管理比如「審批」「彙報」的功能。工具還是寧少勿多。缺點是小插件和管理後台都不易用。

第三：百度雲（大文件及視頻分享）
曾經在很久以前我們使用dropbox，後來遭遇了太多血淚悲劇。現在主要使用百度雲。有點是下載飛快，分享機制多樣且合理。缺點是mac客戶端太垃圾。以及同事若干次自動備份了自己手機的相冊……

第四：群暉（文件備份與管理）
由於我們是一個偏向於開發策劃的影視公司，所以每天都會產生海量的文檔文件和多如牛毛的版本，後來在辦公室區域網環境搭建了一個群暉的nas，用了陣列。然後核心版本的文件都會放在裡面做備份，並供使用者自由取用。缺點是管理機制略複雜。以及如果不是企業網路的話似乎埠被封導致不能外網訪問。

以下部分來自我的博客，是我最近半年理解到的的項目管理的方法論總結，拋磚引玉吧，工具是一個ppt和一個excel表格，原文見：老王牌項目管理流程
說明：需要老王牌項目管理相關PPT和EXCEL模版的朋友，請加我的微信：wendayuan

一、項目管理的定義

我這裡所指的項目不同於寫一份本人的年度計劃這樣的一個人就能完成的case（雖然這樣的事情放大來看，也可以叫做項目），我這裡提到的項目更側重指需要不同的部門協作，不同的資源調動，集中各種力量起來才能達到目標的事務。

我認為，所謂項目，就是為了達到一個目標而需要完成的事務集合體。

那麼，所謂項目管理，就是組織相關資源完成項目的過程。

二、項目管理常遇到的問題

可是我們卻常常在推進項目向前的時候，遇到各種問題：

對於交付給別人完成的事務不放心，總是擔心出漏子，事實上，也的確常常出漏子。
怕什麼來什麼，經常在deadline到達那天或者前兩天出漏子，告訴你因為若干客觀原因，某個環節又得延期，於是導致整個項目的時間表跟著變動。
如果自己事必躬親，什麼都干，累的跟豬一樣，還是沒法解決問題：首先你一個人干不過來，其次不是所有的都是你會幹的，而且你有搶同事飯碗的嫌疑。
到底一個項目（或者項目中的一個人物）做到什麼算是合格，執行的人不是很清楚，甚至可能出現問到你自己的時候，你自己都不清楚。
你覺得你已經跟別人說得很透徹的事情，別人其實可能根本沒弄明白，你們最後互相埋汰，肝火大動（這個最經常出現在技術人員和業務人員的相互罵sb的場景中）
項目執行者各人理念不同，方式方法不同。做成一個事情的方法很多，說不上對錯，但如果老闆說按照A的辦法做，B自然很不爽，在這種情況下保證B能夠正常給出他應該給的結果？
也許還有更多。

不解決好上面的問題，就不算好的項目管理。

三、項目管理的目的

項目管理的好壞，直接決定了效率的高低。我認為，成功的項目管理就是能夠在預期的時間、使用預期的資源內達到預期的目標。

項目管理的最終目的，說句國企常常在電視上喊的口號，就是：我們一定保質保量按時圓滿完成任務。這話很精鍊，問題是如果沒有明確：「我們」是誰，「質」是什麼，「量」是多少，「時」是多久，何為「圓滿」，這就是一句老王常常罵的「江澤民語言」。

道理很淺顯，邏輯很簡單，在中科希望我最大的感悟，就是「多走一步」，這個「多走一步」看上去不起眼，象一張窗戶紙，但是不捅破，就永遠看不到後面真真切切的結果。

下面，就是我在中科希望六個月學到的老王牌項目管理流程心得。

四、老王項目管理的步驟

還沒入職的時候，我就和我的直接領導在填寫一個「FY2011經營計劃模板」的PPT，工作這麼多年，我做的ppt也不少，每個公司都喜歡玩的年度計劃和年度總結也是家常便飯，從來計劃和總結沒有什麼關係，計劃也從來沒有得到過持續的執行過。一直的印象中，這純粹就是走走過場的玩意兒。沒想到老王的這個東西卻是別有玄機。

這個經營計劃的ppt的第一部分，就是老王牌項目管理的起點：目標

項目管理第一步：確定目標

對於目標設定要求很簡單：

能量化的一定要量化！
不能量化的軟性目標也要量化！
什麼？還有實在不能量化的，那麼就要描述這個目標做到哪裡能夠帶來什麼好處

老王對於數字非常講究，我認為這個的根結在於：他需要管理不同的行業的公司，沒有人可能是多個行業的專家，那麼如何管理不同行業的業務？說的花里胡哨的形容詞，說的雲里霧裡的專業術語，這些都沒用，最無法騙人的就是數字，數字也是最簡單的邏輯和效果。

所以，能夠量化的一定要量化，不能量化的也要量化，壓榨的實在量化不了的，那也要轉換成有意義的可以預期的東西。

項目管理第二步：環境分析

老王PPT的第二部分，是個大家都很熟悉的SWOT工具，這玩意兒基本也是人人都耳熟能詳的東西了，但是，在老王的項目管理流程裡面，這個是處於核心樞紐的部分！而且其操作手法也有獨特的地方。具體要求如下：

在SWOT的每個象限，針對競爭對手寫出3條，最多不超過5條
寫完之後逐項論證是否成立
論證完成之後是一頁SWOT的綜合結論，這一頁寫法很簡單，選擇前面每個象限中的你認為最重要的一條，寫法如下：「加強xxx的優勢」「減弱xxx的劣勢」「抓住xxx的機會」「規避xxx的威脅」注意，一定要引用swot中的原話！

這裡需要補充一下關於威脅和劣勢的區別，我一直沒弄明白這兩個的區別，不過老王解釋了一句我就明白了，他說：什麼叫威脅？就是出現這情況，這個目標就必死的事情！

項目管理第三步：策略設定

我想起那個印象深刻的場景：老王開會，問所有的人：「神馬叫策略？」答案很多，也有非常教科書一樣的長長的一句一句的話，老王最後霸氣側漏的下了個我印象深刻的定義「策略就是mi你的quota要做的事」

是的，直擊要害。策略就是完成你的目標要做的事情。

我們的目標在第一個步驟中已經設定好了，那麼策略從哪裡來呢？策略就從第二步環境分析中來，所以我說第二步是處於核心樞紐的部分，因為下面所有的策略，都來自這個地方，來自「加強xxx的優勢」「減弱xxx的劣勢」「抓住xxx的機會」「規避xxx的威脅」。

我曾經就SWOT成為所有策略的來源請教老王：如果SWOT分析出錯了，豈非後面完事皆錯？他說是的。

當然，我一直以來也沒有發現更好的辦法，昃小姐曾經提供過一種科學的避免誤差的辦法，了解了一半，沒有深入，暫時還是無法替代SWOT。

但是我想說一點的是：就算SWOT分析有誤差，策略設定出錯也沒關係，策略的執行到位並完成才是項目管理的成功之道。

很多時候，即使這是一條正確的路，也因為不得力的關鍵控制點的執行，而最終失去成功。

反之，就算策略出錯了，有良好的項目控制，只要糾正偏差，就能慢慢調整到正確的方向，必然就會成功。

唐僧要去取經，怕的是悟空往東走，八戒往北走，唐僧要往南走，處於內耗，永遠原地踏步，走不到要去的地方。如果有良好的項目管理，所有的人都跟著唐僧往南走，走到一定的階段，發現不對，大家再一起調整方向，終有一天會調整到正確的西方。

下面我來講策略如何能夠保障執行。這就是這份ppt的第三部分，這也是這個項目管理的精華之一：

設定重點策略：根據SWOT的綜合結論，列出mi你的quota要做的事情：），可能一個象限會有1－n個重點策略。

設定關鍵控制點：針對每一條重點策略，要拆解成三個左右的關鍵控制點。完成了這三個控制點，就能意味著這個策略能夠順利完成。這個需要設定關鍵控制點的人和驗收的人共同確定，互相有底。

設定驗收標準：每一個控制點要有可量化的驗收標準，主要是三要素：什麼時間，誰來做，做到什麼。這個驗收標準也是需要設定的人和驗收的人共同確定，互相有底。

不但要學會設定目標，而且要學會設定策略，然後要設定關鍵控制點，然後要設定關鍵控制點的驗收標準。這才是項目管理的真諦啊，不但管理了目標，而且管理了實現目標的過程。

設定關鍵控制點是確保這個策略能夠完成

設定驗收標準是確保這個關鍵控制點能夠完成

關鍵控制點和驗收標準是老王特別講究的東西。甚至驗收標準的寫法，都非常講究，我認為他是想通過公式化的寫法，能夠讓執行者迅速明白要做到什麼，標準是什麼，減少溝通成本。關鍵控制點和驗收標準，如果寫的制定的人和驗收的人都不清楚瞭然，一切的執行無從談起。一定是雙方共同明確的，甚至可能需要多次討論才能確定。

老王說：能在他手下，這份經營計劃的ppt能夠三次以內過堂就完成的，從來沒有一個人。我很榮幸沒有成為打破紀錄的那位，我也是第三次過的。

項目管理第四步：重點工作和執行計劃

有了重點策略和驗收標準，下面就需要跟你的team和你的支持部門擬定重點工作和執行計划了。這個老王有一個專門的月度重點工作表來跟進。

我們平時部門經理什麼的，做計劃的時候，容易出一個毛病，就是1、自己能看懂就行，2、很少和team一起做，和team也是確認一個數字而已，很少或不知道怎麼去干預執行過程。老王特彆強調：重點工作和執行計劃，不是讓你自己寫自己看的，是要讓執行的人明白並且能夠照著去做的。

所以，這個重點工作和執行計劃其實是由你和你的下屬一起完成的（當然，也有可能有的事項項目牽涉到同級的部門，比如程序開發需要涉及技術等等）。所以，具體步驟如下：

根據重點策略，設定完成重點策略所需的重點工作及驗收標準。
和下屬明確你列出的重點工作和驗收標準，讓下屬明白你需要他要做到的目標是什麼？他需要什麼時候做到？他做到什麼標準算合格，做到什麼標準算優秀。這個環節由你自己主導。
與下屬討論明確他完成這個重點工作的行動計劃（或者叫節奏）是什麼，這個環節由下屬來主導，但是你最終要認可。他必須告訴你，並且你要認可：如果要按照前面的要求完成這個項目，他的行動計劃是什麼，第一步做什麼第二步做什麼第三步做什麼，每一步的時間節點是什麼，每一步的驗收標準是什麼。而你，要認可如果他達到了這些步驟，就是能夠完成這項重點工作的，否則，你們就需要反覆討論。

舉例：你有兩個下屬A和B，你需要他們都做成同樣一個事情。

首先，你要告訴他們驗收標準：你需要他們在什麼時間，給你一個什麼樣子結果。要明確到數字和時間。（我們很多時候到這裡就完了，我們就等著到什麼時間來要結果，這是不夠的！！！我前面說到的感受最深刻的「多走一步」就在這裡體現價值了）

然後，你讓他告訴你，他們準備怎麼做，來保證按時給你這樣的結果。有可能有這樣的情況：A聰明一點，他只需要3步就能完成，B笨一點，他需要8步才能完成。但是，請注意，這就是人和人的節奏不一樣，只要他們都能根據你的要求完成任務，又有什麼關係呢？

有一次業務會議，老王提到一個要點：給銷售不能說策略，給銷售就是講工作，否則就變成形式主義。下屬能理解策略當然更好，但是在更多時候，你不能指望下屬理解整個的策略，那麼，你就讓他好好的完成你既定的重點工作就好了。

老王，就是用了設定行動計劃這個「多走一步」的辦法，讓我們做到了對項目的可控性。

項目管理第五步：跟進

做到部署重點工作和執行計劃這個就可以安枕無憂了么？當然不，為了保證項目能夠按時完成，還需要加上一道保險，這就是下面這個重要環節，同時很類似時間管理GTD裡面的「回顧」：跟進。

對於跟進這個事情，老王常用的詞叫Review，我翻譯成跟進，嘿嘿。

跟進的意思，就是加上保險，讓你確保你的項目所有的行動計劃的進展狀態是否正常，如果正常當然ok，如果出現差池，那就可以及時調整，不至於到了項目截止日期打你個措手不及，欲仙欲死！

跟進的步驟如下，我個人實踐中發現兩種跟進辦法：

1、定期跟進：比如每周的例會，統一對於進行的行動計划進行跟進（其實公司周報的發明，就是應該起這個作用的，但是由於普通的公司的周報都是基本沒有主題的，失去了項目跟進的靈魂的周報就是流水賬）

2、節點跟進：比如某個行動計劃是大概2周完成，你可以還有一周的時候跟進一下，還有3天的時候跟進一下，保證進度正常。

需要提出重點的是：跟進的背後要有具體的想法，你可以提出反對意見，但是你同時要給出解決辦法。老王修鍊到了可以直接在會上即時提出問題同時提出解決辦法，普通的管理者，還是要在開跟進會之前，多做做功課才行。

老王在月度重點工作表裡面甚至強調要求我們在每個行動計划上，都標準上對應哪一條重點策略，以便讓他清晰的把握現在的我們乾的事兒是在和當初計劃一樣向一個方向邁進！

項目管理第六步：重複第二到第五步。

SWOT要經常更新。

這就是取經路上的修正的問題，拿我們前面取經的例子來說，如果隊伍如果跟著唐僧往南邊一條路走到黑，那就跑南極去了也到不了西天。對於大的策略，要定期重新進行SWOT分析。必要的時候進行修正，才可能走到成功的地方。

附錄：

中科希望短暫的六個月，我感覺比我過去6年學到的東西還多，感謝王總的教誨。

文章中提到了經營計劃的ppt和月度重點工作表兩個文檔，ppt裡面的東西是給團隊看和演講的，一表通那個excel是用來管理的時候審核下屬用的。

項目管理有一個鐵律就是：別拿客觀原因說事兒，完成就是完成，沒完成就是沒完成。老王舉的例子很直接：不能說因為日本地震了，所以你沒有mi你的quota。

我做了個項目管理示意圖：

註：萬字乾貨~建議收藏慢慢消化

大體說來，一個項目管理的流程分為這麼幾個階段：

項目啟動——項目計劃——項目執行和監控——項目收尾

如果用一幅圖來表示的話，大概會是這個樣子的：

在整個項目的運轉過程中，從最開始的來自領導的戰略規劃啟動了項目，到前期的項目計劃、需求轉化與中期的項目執行和跟進，以及後期的項目收尾總結會，每一個環節都有產品經理的身影。

尤其是在初創公司，產品經理大多數的時間也擔任項目經理這樣一個角色。所以對於初創公司的產品們來說，了解項目管理的大致流程，合理分配資源就顯得更加重要了。

我們來一一梳理下，產品經理如果來負責一個項目的管理，在每一個階段都要做哪些工作。

項目啟動階段

任何一個項目，能夠被啟動，至少從戰略層面是得到公司認同和支持的，也就意味著這個項目是要背負著實現公司的某一個戰略目標而存在的。產品經理在項目啟動前，有這麼幾個問題需要提前去了解和熟悉：

為什麼要立項？

項目目標是什麼？

項目的相關人員都有哪些？

怎麼立項？

第一個問題，為什麼要立項？

這個時候，作為產品經理的你需要去了解這個項目的來龍去脈，最好的方式是和你的上級或者BOSS溝通，因為他們掌握的信息量遠遠比你大且比你多，所以通過和他們溝通再加上自己理解，就能夠對項目立項的原因有一個清晰的認知。

當然，有時候項目立項，可能就是產品版本的定期迭代，這個時候產品經理對為什麼要立項恐怕是比誰都更清楚了。

第二個問題，項目目標是什麼？

產品經理作為項目的負責人，是一定要明白整個項目的目標是什麼，然後在裡面找出最核心的目標。例如有的項目是時間（越快越好，花多少錢無所謂），有的項目是錢（做慢點沒關係，但是要花最少的錢）。這些都可以通過跟你的領導聊一聊聊出這些信息，知道了項目目標後你需要把這個目標用準確的文字寫下來。

對，一定要寫下來，因為口說無憑，再一個寫下來的東西才能成為所有人具體執行的方向和準則。

第三個問題，項目的相關人員都有哪些？

關於干係人，寶潔的方法論是找出PACE。P是Participant（參與者），A是Approver（審批者），C是Consultant（顧問），E是Executor（執行者）。當然，產品經理（尤其是創業公司的產品）在日常的項目工作中，恐怕不會有這麼繁瑣的流程，所以，也就遵循一切從簡的原則。

項目相關人員，可以從這幾個角度去考慮下，如哪些人或部門會受到項目結果的影響，哪些人可為項目提供資源（人、財、物）等。當然，在互聯網公司，常見的相關人員也就是老闆、產品經理、項目經理、項目團隊（包含設計、開發、測試、運維等）及用戶等。

找到了項目的相關人員後，現在你要做的就是把團隊成員綁到自己的船上。你需要去了解團隊里每個成員的核心KPI，也就是他們於這個項目的需求是什麼，做這個項目可以給他們帶來什麼。如果這個項目沒被囊括在這個成員的工作評價 list 裡面，你需要去找他的老闆溝通。

根據我的經驗，85%出工不出力的情況都是因為你的項目根本不會對這個成員的KPI有什麼正向的幫助。當然，如果找他的老闆溝通無效，還有最後一招：感情投資，請那個成員擼串、吃飯，利用感情讓他幫你做好這個項目。

第四個問題，怎麼立項？

通常來說，這個時候需要開一個項目啟動大會。這個啟動大會的目的是召集項目團隊成員，成員之間初步認識一下，產品經理主持會議，然後清楚地傳達項目要做什麼，目標是什麼，為什麼要做，怎麼做，誰來做等等。

另外，跟所有的啟動大會一樣，項目的啟動大會，也需要給團隊成員來點雞湯、打點雞血。產品經理需要去統一團隊的思想，明確團隊的管理和運作方式，以及團隊的溝通機制等，產品經理需要動員團隊成員積极參与項目，並高質量地完成項目。

這個時候，項目相關的文檔其實應該已經完成了，因為只有當詳細的產品需求文檔有了之後，開發團隊才能估算項目時間及里程碑等。也有另一種情況，那就是項目本身包括了需求分析階段，所以詳細的需求文檔是在立項之後才開始進行調研和撰寫。

不管怎麼說，明確的產品需求和詳細的需求文檔，都是項目得以順利進行的基本前提保障，所以，產品經理的規劃能力、撰寫文檔的能力在這個時候就顯得尤為重要了。

項目計劃階段

完成了項目的啟動，接下來就要開始進行項目計划了，所謂的項目計劃，其主要工作就是工作任務分解，任務優先順序安排，資源、工期、成本估算，以及風險計劃和溝通計劃等。

工作任務分解

工作任務分解，在項目管理中也有專門的術語叫做「工作分解結構」（WBS），指的是以可交付成果為導向對項目要素進行的分組。它其實歸納和定義了項目的整個工作範圍，從項目目標開始分解，逐層下降，每下降一層，代表對項目工作的更詳細的定義。

產品經理在每一個版本的迭代規劃中，都需要從產品需求池中撈一些比較重要的需求出來放到項目需求里來，這正好符合敏捷開發的思想，飯是要一口一口吃的，項目也是一樣，不可能一次性把所有需求都搞定。所以，我們需要通過一個版本一個版本來完成，在做版本的工作任務分解的時候，一定要將任務分解到不能再分為止，任務的粒度一定要細，如果太粗，則很有可能會出現一些任務被忽略，從而影響整個項目的進度和計劃。

一般的工作任務分解方法有：按照產品的物理結構分解、按照產品的功能模塊進行分解、按照實施過程來進行分解、或者是按照項目的地域分布等。比較常用的是按功能模塊來進行分解，再結合產品的實施過程來進行分解。

以微信公眾號的開發為例：

微信公眾號的開發就涉及微信端開發和PC管理後台的開發，這個時候如果進行任務分解，最基本的方向就要分為微信端任務開發、PC管理端任務開發。

而微信端任務開發，又可細分為需求梳理、產品設計、前端頁面實現、後台介面支持、測試任務等；PC管理端的任務開發也是如此，也細分為需求梳理、產品設計、前端頁面實現、後台介面支持、測試任務等，如果再細分功能模塊，則可分為「群發消息」、「自動回復」、「用戶管理」、「消息管理」等功能模塊的需求梳理、產品設計、前端頁面實現、後台介面支持、測試任務等；

這裡需要注意的是：分解任務的過程中，需要將任務給描述清楚；否則團隊成員會不太明確，自己究竟要做成什麼樣子，或達到什麼樣的目標才算任務完成。

項目的工作任務分解，其實也可以運用我們之前提到過的MECE原則去進行檢查：工作任務必須全面、清晰、細分，任務責任需要到人，每一個子任務都能夠估算工作量和工期。

任務優先順序安排

任務分配好了，但總有輕重緩急之分。項目里的優先順序排序，就是需要產品經理去識別項目任務清單里的各種任務的相互關聯和依賴關係，並根據自己對需求優先順序的判斷，來對項目里各項任務的先後順序進行安排和確定。

通俗地來說，產品經理要定義的就是先做哪些任務，後做哪些任務。其實這個時候往往又會用到我們在需求管理中使用到的工具KANO模型，通過明確任務的重要度和緊急度來梳理任務的優先順序，優先處理的是重要又緊急的任務。

在處理任務的優先順序安排時，有另一個非常重要的點需要明白，那就是有些任務與任務之間，存在著前置後置關係，只有在完成了一項任務的時候，我們才能開始下一個任務。所以在規劃優先順序的時候，需要把這種情況給考慮進去。

計劃呈現——甘特圖或其它

很多項目管理的書籍都推薦使用甘特圖來進行項目進度計劃的製作和呈現，一般都是通過微軟的Project等專業軟體進行繪製，還可以通過這些專業軟體直接查看項目的關鍵路徑。也有一些產品經理或項目經理直接使用Excel來製作項目進度計劃表，畢竟他們對於表格的操作熟練程度已經足夠駕馭一個項目的進度計劃製作。

我是個比較注重用戶體驗的人，所以，上面兩種工具其實我都不怎麼使用；一般來說，我更喜歡通過團隊協作軟體中的項目管理功能，來實現項目計劃的呈現。

比如下面這樣的：

tower的項目管理界面

風險控制

通俗地來說：風險就是發生不幸事件的概率。任何一個項目都有風險，這就好比任何一次手術都有風險一樣，風險其實是無處不在的，是一種不以人的意志為轉移，獨立於人的意識之外而存在的事物。

我們先來看看常見的一些風險來源有哪些：

a、客戶沒有參與項目

如果你們公司的一個項目恰好是給客戶做的一個定製產品，但是在項目啟動、計劃和執行的階段，都沒有客戶的參與，客戶只是在最開始的時候給了一份文檔，然後在項目收尾的時候來進行驗收，中間沒有絲毫地參與到項目中來。那麼客戶一旦發現最後的成果和自己當初設想的需求相去甚遠，結果就會變得非常糟糕。客戶有可能因此就不同意驗收項目，要求項目團隊重新返工開發，這個時候造成的工作量及時間的損失、及對相關事件的影響則是不可估量的。

b、需求不明確或不完整

產品經理的需求說明文檔出現不明確或不完整的情況，項目出現風險的概率也會比較大，因為項目的開發成員都是圍繞著需求設計文檔來進行開發、測試的，如果產品經理能夠隨叫隨到，和開發及時討論清楚需求，則還能挽回一定的損失；而如果是異地開發，則整個項目便會比較悲催。

c、項目計劃的不合理

項目沒有如期完成，很有可能本身項目計劃就是有問題的。比如說，團隊成員的分工不合理、工期安排的也不合理（一般3個月才能完成的任務，非得要求1個月之內要上線）、資源沒有配置到位、工作任務的分解沒有細化沒有責任到人（這樣就會導致項目組的團隊成員對自己的任務不太清晰，即使分解了，沒有指定到人，也會發現影響項目進展）、還有一個就是任務的優先順序安排的不合理，導致後面任務的完成受到影響等。

d、團隊成員的精神狀態

一個項目能不能如期按時按質地完成，其中最主要因素還是人的因素，因此團隊成員的精神狀態也是影響項目成敗的風險之一。如果項目成員都如Scrum敏捷開發中提到的團隊成員一樣，都是自發組織和管理，參與項目的積極性比較高，項目風險就會大大降低。如果項目成員工作態度有問題，互相之間經常推諉任務責任，經常互相埋怨，那麼項目的成果則很令人擔憂。

e、領導變更

這裡的領導變更，主要是指項目開發到中途，領導突然說這個需求不對，應該朝另一個需求方向開發，那麼我們就稱之為領導變更。這裡的變更，大致分為兩種情況：

一種是不太傷筋動骨的，也就是只是小的需求修改，不涉及底層架構的重建；另一種呢，則是產品的規劃和定位不夠清晰，導致修改起來比較傷筋動骨。一個需求方向的改變，就可能讓開發重新搭建後台架構，前端很多頁面也得跟著修改。

當然，有時候產品經理也常常會犯這樣的錯誤，就是中途變更需求，這就要求產品經理在項目策劃的時候就把需求都想清楚，盡量減少項目開發到一半需求突然變更的情況。

f、技術風險

這裡說到的技術風險，指的是項目的開發組成員，他們在用代碼實施項目的過程中，會發生一系列意想不到的情況。比如開發去做一個從來沒有做過的功能，這個時候可能需要先進行技術調研，可能最後的結果是光光是調研事件就話費了一兩個禮拜，留著開發的時間幾乎僅剩無幾。比如說網站掛了，一處理就一天時間進去了，原先手上的項目就只好拖延一天。

這裡列舉了一些常見的技術風險，產品經理們在做項目管理的過程中，還是稍微了解下比較好：

那說了這麼多的風險來源，有沒有什麼比較好的方法來規避這些風險呢？

答案是有，但是依然比較難規避掉所有的風險。

大家有沒有同感：出現項目偏離日程安排的情況，很少是因為工作耗費了比預期更長的時間。更常見的原因是：根本不在計劃中的工作使項目泥足深陷？如果身兼項目經理的你，深有同感；那麼，我們就可以體會到：項目中的風險是可以互通的，昨天的問題就是今天的風險，你的問題很可能就是我的風險。

因此，我們能做的比較好的一個方法就是：在項目初期，對上述風險來源進行逐一參考和排查，看看是否存在什麼問題。當然，更加隱秘的風險，恐怕也不是靠這種逐一排查的方法來發現的；更關鍵的點還是在於對日常項目狀態的洞察，這樣才能把所有的核心風險都呈現出來。

風險管理是一件非常耗費心力的事情，產品經理如果兼職做了項目管理的工作，就必須要做好相關的心理準備，畢竟內心強大也是產品經理必須具備的一個人格特質啊。

在完成了項目計劃階段，進行了項目計劃的任務分解、優先順序排序、計劃呈現和風險控制之後，就到了項目的執行和監控階段了。這個階段主要是針對項目執行的情況進行溝通，對整個項目的執行進度進行監控，使其在時間、質量、成本之間取得一定的平衡。

項目執行和監控

主要來說，這個階段會包含下面這麼幾件事情：

過程跟蹤：主要是對項目執行過程中的跟蹤和監控，防止團隊成員對計劃理解產生偏差，導致執行階段出現一些問題，跟蹤的事物包含團隊成員、任務、開支情況等；

例行項目會議：所謂的例行會議，其實就是要給一個項目制定一個固定的溝通渠道，這樣才能讓團隊成員溝通效率變高；

階段性交付物的審核：對於一個長期的項目計劃，一定是會拆解為好幾個實施階段的，那麼對於階段性的交付物就有必要進行審核了，這也是非常重要的一個監控手段；

里程碑報告：項目達到了一個里程碑，那麼就可以來一次里程碑的報告；

變更管理：為了適應項目運行過程中與項目相關的各種因素的變化，保證項目目標的實現而對項目計划進行的一些調整，我們稱之為變更管理

第一件事情，過程跟蹤

產品經理為了掌握項目的進展，掌握各項工作的狀況，就不得不進行項目過程的一個監控和跟蹤。只有這樣，出現了問題，我們才能進行適當的資源調整和進度計劃調整，重新規劃某一個任務的開始時間和結束時間，並記錄實際的進度情況。

那麼，產品經理在實際的工作過程中，到底如何進行項目跟蹤呢，主要可以從以下三個方面進行考慮：

1、管事——監控項目的任務

有很多產品經理都有一個習慣，那就是在每天來到公司的第一件事情，就是跑到項目開發組那邊去溜達一圈，把大家召集到一個地方進行項目站立會的召開，例會花不了多長時間，但是在監控項目任務進展方面起的作用卻很大。一方面可以避免有些同事在項目過程中沉浸在自己的世界裡，方向走偏了自己沒有發現。另外一方面是能幫助大家克服人性上的懶惰因素，在每天彙報工作進度中給大家形成適度的壓力。

每日站立會在同樣的時間和同樣的地點召開，會議準時開始，最好不要超過15分鐘，每一個開發團隊的成員都必須發言，會議中不進行討論，發言內容需提供以下信息：

昨天完成了什麼

今天即將做什麼

遇到了什麼困難

很多團隊在召開每日站會的時候，還會結合看板來進行任務梳理，如下圖這樣的：

每日站會看板

通過這樣一種簡單的會議形式，就可以讓項目組的所有成員知曉各任務的最新進展。這樣才能監控哪些任務的進度落後於計劃，並採取相應的措施給予糾正（通常就是加班啦），盡量不使項目的進度受到影響。

當然，我們不光要知道任務的進度落後，還需要去了解落後的原因是什麼，這樣才能根據具體情況採取不同的措施來使得項目恢復到正常軌道上來。

比如，某一個任務的進度落後於計劃，發現原來是任務分解的時候漏掉了這個任務或者這個任務沒有責任到人，那麼在發現了這一情況之後，可以採取的措施有：讓開發加班搞定、增加人力投入、延長時間、或者更換效率較高的成員來完成任務。

這些都是補救措施，我們再補救完了之後，其實還可以進一步的思考，是不是我們的項目管理流程上面哪裡有什麼欠缺，是否可以改進工作流程、方法和工具，這樣就減少上述情況的發生概率。

2、管人——監控項目的團隊成員

大家不要誤解為是讓產品經理去做間諜之類的角色，混跡於項目組成員中偷取情報什麼的。其實，這裡所謂的監控項目的團隊成員，更多的是去記錄下項目組每個成員的表現，對表現突出的給予讚賞和肯定，對表現不好的則應提出相應的批評（當然，很多時候產品經理其實並不是開發部門的領導，措辭什麼的還是注意一下為好）。

另外一點，產品經理要去多和項目組的成員進行溝通，這種溝通不僅僅是工作上的溝通，還可以聊聊生活方面的東西，這樣不僅可以促進你和項目成員之間的關係，還能及時知曉他們的生活狀態，也是有利於項目管理的。

3、管錢——監控項目的開支

一般的軟體項目開發並不會涉及到項目開支的問題，因為基本所有的開支都是人力成本。但也有特殊情況，尤其是運營活動相關的項目管理，就經常會涉及到項目開支的問題，這裡的監控其實主要是記錄下所有的開支流水，看下與項目計劃初始階段的預算相比是否有超出的情況。

這個時候可以好好和運營的相關同事進行溝通，找出具體的費用超出項，分析原因找到相應的解決方案。

第二件事情，例行項目會議

管理學大師彼得德魯克有一句名言，叫做「管理就是溝通，溝通，再溝通」。事實上，我們細想一下，在項目管理的實踐過程中，我們是不是經常會碰到下面這些情況：

比如說項目老闆隔三差五就跑來詢問項目的進展情況，其實是因為沒有人給他彙報項目的進展，但老闆又比較擔心；

再比如說，你把需求的第一部分通過郵件發出去後，沒有人回郵件提出自己的意見和疑問，你也以為這個需求會很順利的走下去，但是那天無意間和團隊成員聊起需求，那個成員馬上提出來自己的異議，巴拉巴拉說了一通。有的時候你不去問，別人是不會主動來告訴你他的想法的，這個時候可能自己才意識到，其實是需要給團隊一個溝通的機會來聊這些東西；

還有，在項目實踐中，問題早就已經出現了，但是過了一段時間才通知項目團隊的所有成員，這樣就導致了大家對於項目進展的信息不對稱，很容易導致工期滯後的情況發生；

所以，在項目管理的過程中，溝通是不能忽視的一個重要環節。再說的直白一點，項目負責人最重要的工作之一就是溝通，所要花費的時間可能要佔到工作的75%～90%。因為只有良好的溝通，才能獲取足夠多的信息，才能發現潛在的問題，這樣才能更好的控制項目的各個方面。

前面我們提到了項目有相關干係成員，但由於每個成員的崗位和職責不同，所以每個人關注的項目信息不一樣，他們關注信息的頻率其實也不一樣，有的比較頻繁，有的則可能整個項目過程就問那麼兩三次。由於每個人的習慣不同，所以他們獲取信息的手段也不太一樣，有些人喜歡微信、QQ，有些人喜歡郵件，還有些人喜歡以會議的形式獲取信息。

這樣的話，就很有必要建立起一套屬於本項目的一個溝通機制，統一一下溝通的方法和渠道。比如說最緊急的事情可以通過電話溝通，比較緊緊的事情則通過微信或者QQ溝通，而不是那麼重要的事情，則放在每日站會或者是項目周會的會議上進行解決。同時，還應該在團隊里提倡主動溝通的精神，這樣不僅能建立團隊之間的親密關係，更能表明成員參與者對項目的一個重視程度。

第三件事情，階段性交付物的審核

在項目進展的過程中，會產生不少的交付產物，產品經理在管理項目的過程中，可以對以下幾項階段性的交付物進行審核，以確保整體項目的計劃和執行不會出現大的偏差：

1、需求清單

產品需求清單是一個排序的功能需求列表，是一個持續完善的清單，包含所有產品需要的東西，也是產品需求變動的唯一來源。產品需求清單包含所有的模塊、功能、特性、需求描述、商業價值、優先順序描述等。

需求清單的內容、可用性、優先順序等僅由產品經理負責管理。

2、任務清單

任務清單是一份足夠具體的計劃，包含對需求清單的任務分解。開發團隊在整個迭代過程中都會修改這份清單，比如開發團隊對需求有了更多的了解，需要增加一些新的開發任務到清單中去。

任務清單的修改只能由項目經理（產品經理）負責，該列表是用來明確項目團隊成員的任務的。

3、項目周報

項目周報是對項目組本周工作內容的總結、以及下周的工作計劃安排的彙報，同時項目周報需要及時反饋本周工作中存在的問題以及需要領導協調的資源。

項目周報中切忌報喜不報憂，要反映項目的真實情況。

第四件事情，里程碑報告

當項目進展到一個關鍵節點，這個時候出現了一個里程碑式的事件，里程碑代表項目生命周期中的重大事件，是衡量項目總體進展的一種高層次的方法，能用於向項目利害關係者和項目組報告高層次的進展情況。

另一個方面來說，在項目進展過程中，通過讓項目組成員了解他們為實現里程碑付出的努力，而里程碑的實現對鼓團隊成員也是非常有用的。

比如說，在每個迭代結束後，項目組成員聚在一起召開總結會議，回顧一下在本次迭代過程中，哪些是做的好的，哪些是做的不好的，找出潛在的可以改進的事項，作為將來的改進計劃。迭代總結會議記錄就是這樣一份將會議過程記錄下來的清單已經後續跟進的依據。

通常的里程碑事件有這麼一些：需求分析、詳細設計、系統開發、系統測試、正式發布等，產品經理在管理自己的項目時，可以根據自身項目的一些關鍵節點來做一下里程碑式的總結，達到項目彙報的目的。

猶如《西遊記》中的唐僧取經團隊，好不容易經歷了九九八十一難，才來到了佛教聖地靈山取得真經。這就好比一個歷經千辛萬苦的項目管理過程，這種體會其實作為產品經理的你，也是有機會體驗的。

項目收尾階段

在項目的整個發展過程當中，我們已經經歷了項目的啟動，項目的計劃，項目的執行和監控，最後終於到了項目的收尾階段，有那麼一瞬間，你會覺得一切都是值得的，因為勝利就在眼前，希望的曙光彷彿在明日即將瞥見。

項目收尾階段主要是對項目的各項指標進行評估驗收，對項目進行經驗教訓總結。但，作為整個項目的負責人，即使到了最後一刻，我們依然不能掉以輕心，有很多例子就足以證明仔細、認真的重要性。

比如說，一個簡單的伺服器修改功能，由於過於輕視，沒有走測試流程，直接發布到外網，導致外發版幾萬用戶的手機崩潰。雖然後期排查查明是因為程序員的疏忽導致的參數錯誤，但其實這裡就已經暴露了項目流程上還存在很多問題，尤其是在項目收尾的過程中，產品測試是非常重要的一個環節，沒有經過測試的產品，是萬萬不能對外進行發布的，這都是血的經驗教訓。

嗯，重要的事情還真是的說上三遍吧：

無論進度多趕的項目，發布前，請一定內測。

那麼，具體到項目收尾這個事情上，就涉及到方方面面的驗收及檢查了，項目團隊的所有成員都理應投入到自我檢查和項目檢查的隊伍中來，這樣才能確保項目正常、穩定的上線。

功能bug測試

測試是產品上線環節中重要的一部分，伴隨著整個產品的生命周期，因此產品測試是很重要的一個環節，需要特殊的人員從事相關測試工作，這部分人就是測試工程師。目前所有的互聯網公司都有測試工程師。

當然，根據項目的大小不同，測試團隊的規模相差也很大。有些項目需要和開發團隊人數相當的測試工程師，而有些團隊的開發人員、產品經理則兼任了測試的職責。

在項目的發展過程中，應盡量對一些基礎功能製作自動化測試工具，並不斷完善測試用例。這樣測試團隊可以把更多精力投入到新功能的測試中，而不是每次版本發布都在對已有功能是否被破壞而感到擔心。測試工程師是產品上線的最後一環，對用戶負責，是「上帝」的品菜師，他們的定位是產品把關者。

通常，測試工程師在項目中的主要職責分以下幾部分：

編寫測試計劃、規劃詳細的測試方案、編寫測試用例；

根據測試計劃搭建和維護測試環境；

執行測試工作，提交測試報告，包括編寫用於測試的自動測試腳本，完整地記錄測試結果，編寫完整的測試報告等相關的技術文檔；

對測試中發現的問題進行詳細分析和準確定位，與開發人員討論缺陷解決方案；

提出對產品的進一步改進的建議，對測試結果進行總結與統計分析，對測試進行跟蹤，並提出反饋意見；

測試工程師完成了以上的相關任務後，才算是完成了項目的功能bug測試部分的收尾工作。

開發人員的走查

儘管大部分的功能性bug都被測試人員發現，並反饋到開發人員這邊進行處理和修改，但是開發人員仍然需要對一些自己的工作進行走查，這樣才能提高整個產品的安全係數。

開發人員的走查，主要包含如下一些內容：

是否進行高危函數掃描？

是否進行安全漏洞掃描？

是否有內存泄漏的檢測和結果（如果是C/C++代碼）？

不必要log是否刪除了，以及log信息是否清晰完整詳細？

是否影響其他相關模塊功能表現？

自身系統壓力是否已評估？

後端支撐系統負載變化是否已評估？

當然，這裡只是列舉了一些比較常見的開發走查，具體的開發走查安排還是要靠開發部門的領導來具體計劃和推動安排。

產品走查

產品經理作為整個項目的負責人或主導者，對於自己份內的工作也要做到仔細走查一遍，確定沒有任何產品策划上的問題，才是對自己工作崗位職責的盡責，也是對項目的負責。

通常，產品經理在項目收尾階段，需要檢查如下事項：

需求清單是否有調整或更新？例如每個功能特性是否有確定的輸入、處理、輸出；

需求文檔是否補充完整或及時更新？例如交互圖、設計稿是否已經更新；

產品更新說明文檔是否已經提交並進行客服培訓；

產品頁面文案是否已檢查（包括但不限於頁面文字、廣告語）；

已有功能、標識的改動，在其他模塊的呈現，是否覆蓋完整？

數據統計需求是否明確提出？數據是否正常上報？

這些都是非常細節和瑣碎的工作，產品經理在處理這些事情的時候，往往需要多一份耐心和細心，這樣才能考慮周到和全面，確保在自己的工作範圍內，沒有給項目造成什麼損失。

交互和設計走查

這部分，主要是交互設計師和UI設計師要做的工作，因為即使是再精緻的設計稿也只是設計師們電腦中的圖片，只有經過了項目里的前端工程師、開發實現了的產品，才能被廣大用戶看到。

所以，在前端和後台開發完成後，設計師與開發人員一起確認的環節是必不可少的。不經過確認就上線的產品，往往在產品細節上會存在疏漏，比如說某幾個頁面樣式的細節和原先的設計稿不符，這樣就造成了產品用戶體驗的下降。

在這個環節，交互設計師通常要做的工作包含如下內容：

頁面的交互動作，操作及其反饋；

交互控制項的各種狀態，初始狀態、常態、邊界狀態、錯誤狀態等的情況確認；

其他交互細節，如默認值是否正確、第一屏的高度、產品文案等；

而UI設計師要做的事情主要是對產品的視覺樣式進行走查，如是否有色差、尺寸間距、圖片質量、是否符合柵格等；

產品運營人員的走查

如果項目做好之後，就要投入到市場，那麼產品運營人員肯定也要在產品上線之前做好相關的運營準備，這樣才不至於淪落到產品推出之後無人問津的尷尬境地。

那麼，通常來說，產品運營在這個環節需要做哪些工作呢？

產品的冷啟動是否已經準備完畢，種子用戶的招募工作是否已經開啟？

內容運營是否已經規劃？內容的更新機制是否已經確認，並進行部署，是自動更新，還是人工更新？

活動運營是否已經規劃？是否有專人負責？周期性的活動，是否已經配套有運營模板？

用戶運營是否已經規劃？拉新、留存、促活的關鍵步驟都有哪些？

新媒體運營的賬號是否已經建立，是否有專人負責？

渠道拓展是否已經規劃？是否發展代理？是否要引入合作夥伴，合作夥伴的資質又應該是怎樣的？

總結

在看著產品成功發布上線後，項目團隊總算是鬆了一口氣，這個時候就是項目進行了成功地交付了。這個時候，產品經理可以總結一下整個項目的收穫和成功經驗，比如運用了任務優先順序排序，才確保產品項目的主流程能夠順利按時上線。

在整個項目管理的過程當中，肯定也暴露了團隊成員的不少問題，比如研發階段，前松後緊，總是臨近提測時，才匆匆收尾；這常常導致提測質量不佳，或者提測時間延後，風險積攢到測試階段才集中爆發，最終導致項目延期發布，或者帶著顯性的Bug上線。

面臨這方方面面的問題和陷阱，產品經理需要帶領項目團隊做好準備來迎接各種挑戰。最關鍵的是能夠構建一個學習型團隊和高效溝通的團隊，及時總結項目經驗和教訓，從而不重複犯同樣的錯誤，團隊在項目的發展中不斷學習提高。

最後要做的，就是一些文檔的歸檔和項目慶功，這些想必大家在日常的項目管理過程中都遇到過了，就不再複述多言。

原作|壹百度

原文：萬字乾貨｜在高級產品經理眼中，好的項目管理流程是怎樣的-姑婆那些事兒官網

姑婆那些事兒(www.gupowang.com)是互聯網推廣運營知識分享平台,關注移動推廣(android,ios)運營,網站推廣運營、校園推廣及互聯網領域最新動態。歡迎關注我們的微信(gupo520),新浪微博(姑婆那些事兒)。

http://weixin.qq.com/r/e0lNVQvEi1b0rU829xxp (二維碼自動識別)

我就上個圖，最新版本的明道任務。

巧了，公司上周剛讓項目經理給全司做了分享「如何高效完成一個項目」。我就搬過來啦。針對其他同事提的一些問題，項目經理再結合自己的實際操作給大家分享的。沉迷於學習的我筆記做得相當認真的）：

分享主要解決了以下幾個問題
1、一個項目能按時保質完成最關鍵的因素有哪些？
2、如何驅使項目團隊每個人價值最大化？
3、團隊成員如何善用項目工具，流程如何？
4、高效做項目管理的tips有哪些？

一個項目能按時保質完成最關鍵的因素有哪些？
1、良好的硬體設備（現在都是清一色的mac了，哈哈）；
2、穩定的團隊，不斷優化的協作流程，項目管理者的主動管理和溝通；
3、合理的工作分配；
4、對目標有強烈的責任感；（現身說法啊，項目組連續3個季度最佳team，老大帶頭買的躺椅放公司時刻準備通宵加班，使命必達的那種）

如何驅使項目團隊每個人價值最大化
1、熟悉每個人的特點，根據他們的特長分配工作；
2、在成員力所能及的情況下給予一定的挑戰性工作，平時適當協助成員對工作內容的優先順序劃分；

團隊成員如何善用項目工具，流程如何？
人心所向，再善用工具，項目都完成得妥妥的，老闆一開心就。。。。哈哈哈哈。
現在市場上的項目管理工具好像蠻多的，我司用的明道。然後使用情況如下

1、使用「項目」進行任務追蹤，分配任務，落實到人；任務負責人使用任務更新進度和彙報；
2、通過「項目」，從需求的立項、評審、開發、測試、發布整個過程的詳細定義，平時會議的關鍵信息在項目中的任務做好總結和知會；
3、團隊成員使用「動態」進行早晚彙報和總結；
4、通過「知識」，達到文檔資料的流暢共享；
5、用「消息」做即時溝通

高效做項目管理tips
1、主動解決影響團隊效率的臟活、累活；
2、多關注團隊成員的心情變化；
3、以身作則，勇於承擔責任，主動出擊，避免溝通障礙；
4、對項目進度要有心理預期；

項目能否做好，公司管理層動向、公司重視度都有影響。在沒有用明道之前，印象筆記備忘，QQ群、微信群交流，大多時候可能是靈機一動，發現什麼事情要去做，計劃性比較弱，沒有固定的模式。雖不能說明道（或其他工具）就是萬能解藥，畢竟還是靠人用好工具做好事的，協作意識和工具的實用性擺在這兒了。

附幾張圖（忽略那些扭曲的馬賽克嘻嘻）

任務看版。項目一立項就分解階段、分解任務。

任務詳解如圖。deadline、清單列表進度、任務負責人、執行人一目了然

知識管理
文檔多了桌面各種盤不好找，費時間費力還容易抓狂，都無需跨平台，分門別類，並支持全局搜素。（任務、文檔、動態、都支持搜索）

還有打卡、審批、日程、聊天、群組、動態等就不截圖了，嘻嘻。
感謝公司領導大人的分享！

接觸過許多知識管理和效率商務相關的App/平台，在項目協作和管理上，我們內部的主要協作工具之一就是堅果雲，自2012年使用至今，值得信賴與推薦。

對於堅果雲的主要用途就是文件的自動同步和工作文檔的及時共享。堅果雲支持全平台使用，即使在Windows Phone和Linux系統上也可以下載安裝其客戶端。

我對項目管理和協作工具比較看重的因素有：
- 能夠查看同事的相關工作進度
- 能夠及時獲取最新版本的工作資料
- 能夠共同對某一文件進行編輯（或者說批註、添加修改意見）
- 支持的平台終端種類齊全，在手機和平板上都能使用
- 操作簡單，團隊新成員學習成本低

選擇堅果雲最初是因為它的操作非常簡單，很容易上手，為俱樂部的成員之間協同辦公帶來了不少便利，而且確實幫助你提高了效率，具體表現在：

- 可以將電腦本地的任意文件夾進行同步，同步到個人空間或邀請同事同步，其他終端設備上可以即時查看同步文件夾
- 可以用鏈接、微信、郵件等方式共享資料給同事
- 可以查看到同事更新過的文件
- 共享文件夾中的文件可以多人同時編輯
- 可以找迴文件歷史版本，並且對Word歷史版本進行對比

評判一個工具好不好用，要看它能不能幫助你解決實際的問題。
堅果雲的定位是個同步盤，所以沒有多餘的評論或者IM社交功能，解決的主要是團隊的文件管理和文件共享協作的功能。但也因為如此，相比其他項目管理協作軟體，上手成本很低，易用性最好。

以我在項目中的經歷為例，我們通常會在日常交付項目中使用敏捷實踐來幫助團隊實現價值最大化。下面我將詳細介紹：

用戶故事

用戶故事(User Story)是敏捷開發的基礎，它從用戶的角度來對需求進行描述。軟體開發是為了實現產品的商業價值，滿足用戶需求。只要需求足夠明確，所有人都了解其具體內容，團隊就能簡單有效地把需求轉化成可實現、可測試、能夠發布的代碼。為了實現這個目標，需要找到一種方法來描述需求，讓所有人都能對任務的範圍有一個共同的認知。這樣團隊對任務完成會有一個共同的定義，不會出現「你做的不是我所要求的」、「我忘了告訴你這個需求」等類似的問題。

用戶故事體現了用戶需求以及產品的商業價值，同時定義了一系列Acceptance Criteria(AC)。只有團隊完成的工作符合這一系列的AC時，才算真正完成了這個用戶故事。一個用戶故事通常包括三個要素：

角色：誰要使用這個功能。
活動：需要完成什麼樣的功能。
商業價值：為什麼需要這個功能，這個功能帶來什麼價值。

用戶故事可以有不同的展現形式，以下是其中一種：作為一個&<某種類型的用戶角色&>，我要&<達成某些目的&>，只有這樣我才能夠獲取&<商業價值&>。

所以用戶故事一旦被確定，那麼它所要實現的功能、需求範圍、所需工作量也就隨之確認了。之後開發人員所要做的就是根據這個用戶故事的內容進行開發，只有當所有AC被覆蓋到，測試人員完成測試，發現所有功能是可測試的、可運行的，這個用戶故事才算完成了。

估算和迭代計劃

估算(Estimation)：團隊在動手開發一個用戶故事功能之前，應當對實現這個用戶故事所需要的工作量有清晰的認識。如Martin Fowler所說，"Estimation is valuable when helps you make a significant decision"。只有當團隊對達成一個目標的工作量以及完成它之後的「收益」有明確的認知，才能做出明智的決定。

當團隊在為工作排定優先順序、制定迭代計劃時，業務分析師需要知道每個用戶故事的成本，團隊成員需要知道每個用戶故事的價值。有很多種估算用戶故事工作量的方法，其中一種就是把完成這個用戶故事所需要的點數（根據用戶故事的複雜度估算）寫到對應的故事卡上。估算可以幫助團隊以不同的方式，對實現即將開始的用戶故事、未來的架構方向和代碼庫的設計，有更好的理解。一個迭代能完成多少個點數是能估算出來的。也可以使用一些工具統計出過去每個迭代所完成的點數，比如燃盡圖。

只要整個團隊共同協作，估算本身也可以變成一種很有意義的活動。它有助於團隊增進理解，並保證團隊每個人都對要交付的需求範圍和價值達成共識。讓評估變得更有趣的是，通常不採用簡單連續的數列，比如1，2，3，4，5等——而是採用一種近似菲波拉契數列的形式，像1，2，3，5，8，13等（正如《達芬奇密碼》裡面看到的），這樣當數字越大、相鄰數之間的間隔就越大，使得團隊更容易區分哪個故事更小、哪個更大。

在做迭代計劃(Iteration Planning)時，團隊需要從客戶價值維度和技術風險的角度來排定優先順序。下圖中是常用的工具之一——需求優先順序矩陣。

迭代會議和功能演示

敏捷宣言裡面有一條：客戶協作優於合同談判。在敏捷團隊中有一個角色叫做業務分析師(BA)，其核心職責是確保業務需求的清晰和透明，保證開發團隊對業務有足夠的理解，並將這些待完成的用戶故事按照優先順序排列出來，以任務卡的形式來驅動團隊的開發。

迭代會議(IPM)通常發生在每個迭代的第一天，團隊成員一起制定迭代計劃。這個會議由BA主持，大家一起同步幾個方面的內容：

下一個迭代的用戶故事
對下一個迭代的期望和計劃
風險的評估和總結

不同的人對需求有著不同的理解，所有團隊成員都要對用戶故事所有相關內容、所要實現的功能、滿足哪些條件用戶故事才算完成達成一致。迭代會議的主要產出是下一個迭代中需要完成的用戶故事，這些用戶故事即為下一個迭代所要完成的主要目標。

功能演示(Showcase)是敏捷開發流程中的又一個實踐，通常發生在每個迭代的最後一天，目的是演示可工作的軟體。團隊把一個迭代中開發好的功能給相關人員演示，並收集反饋，以便在下一個迭代中可以對變化作出快速響應。

站會和用戶故事開卡

簡單地說，站會(Standup)是團隊在一起快速地開一個會(通常在物理牆前)，成員逐個更新自己的狀態。更新包含以下幾個方面：

昨天完成的工作；
今天計劃做的工作；
面臨什麼阻礙，需要什麼幫助；
自己手頭用戶故事的進展，是否存在技術風險。

既然是快速的會議，站會的時間就不宜過長，10分鐘左右為佳。建議團隊成員站著開會，因為研究表明，當人們坐著開會的時候，會議的時間會被無形中拉長。

這裡有一些實踐原則：

團隊成員都要參加站會，輪流主持，誰遲到了都不等——儀式感很重要。
站會的時候，每位團隊成員圍繞故事卡進行更新。介紹一種有意思的實踐——使用Token(也就是使用一個實物作為」令牌」，準備發言的人首先取得」令牌」，發言完成後將「令牌」傳給下一個人。令牌要醒目，可以是毛絨玩具，也可以是一頂帽子)。

用戶故事開卡(Story kick-off)：在每個用戶故事開發之前，要確保BA、DEV和QA對用戶故事理解一致。這個溝通活動通常表現為由DEV講解這個用戶故事要完成的功能及AC，一旦發現任何疏漏，BA及時補充。DEV有任何疑惑也需及時提出來，當場確認，使這些功能得以正確實現。在後續開發中如果碰到任何疑惑，也應及時找BA了解清楚。QA會嚴格按照AC來驗收用戶故事。

代碼審查和回顧

*代碼審查

開發團隊在完成每天代碼之後，會聚在一起評審當天的代碼，這樣做有幾個好處：

團隊經過一天高強度的思考與編碼，適當地停下來，看看其他人寫的代碼，同時將自己的代碼講解出來，往往能獲得一些意外的靈感，或許能解決自己面臨的阻礙；
互相了解設計思路，獲得更好的建議和進行思路重構，提高代碼質量；
及早發現潛在缺陷，降低事故成本：如果這個時候發現代碼的壞味道和一些需要改進的地方，代碼審查結束後可以花少量時間作出更改；
促進團隊內部的知識共享。

回顧(Retrospective)：回顧會議的目的是通過新的溝通形式喚起大家對團隊的集體意識，指出團隊或個人在一段時間內的不足並列出對應行動。持續而有效的回顧和反饋，可以保證團隊關心生產力和效率，了解自身的不足，這將成為團隊持續改進的起點。

回顧的關注點也多種多樣，除了「項目開發」之外，還可以關注「敏捷成熟度」、「團隊角色和職責」、「人員技能提升」等。在堅持回顧的同時，需要做的還有保證回顧的有效性。應根據團隊建設目標的發展變化，不斷調整回顧的關注點和形式，確保回顧能夠有針對性地發現團隊的缺陷並轉化為實踐。長期有效的回顧和正確的回顧產出，還能夠不斷提升團隊內部的安全感和信任度。

回顧的形式和方法非常多，最常見的是「Well Less Well」。

最大程度的可視化

看板源於精益生產實踐，敏捷將其背後的可視化管理理念借鑒過來，形成了具有自己獨特風格的可視化管理工具。

在敏捷項目里，掛在牆上的「人人可見的大圖表」是一種普遍的實踐，它被用來共享項目的狀態並將之可視化。比如表示項目狀態的物理牆，這樣的物理牆通常包括三個元素：時間、任務和團隊。

除了表示項目狀態，項目團隊還會可視化其他的元素，比如團隊應堅持的規則、項目上的經驗分享以及項目的里程碑。

一般來說，通過有關聯的團隊和個人之間相互協商，可以識別出未來一段時間裡各自的活動，以及相應的、對成功的衡量方式，然後將其可視化出來，每段時間再回顧和調整一次。有了這樣的可視化，團隊會更加容易對齊目標，並不斷培養和加深責任感。

可視化帶來的好處是：

日常工作透明，將迭代過程中所有的故事卡可視化出來，團隊成員可以隨時知道當前需要完成的工作以及將要完成的工作。由於人對視覺反應更靈敏，可視化的故事牆能立刻聚焦團隊的注意力。
將迭代過程中遇到的問題暴露出來，可以促進團隊成員在工作中一起積極討論解決方案。
團隊也可以根據現在的進度以及遇到的問題，了解需要哪些幫助，更好的分配資源，減少開發進度被滯後的風險。

溝通計劃

敏捷裡面的自組織團隊其實是敏捷的結果，而不是先決條件。實施敏捷的過程也是打造自組織團隊的過程。每個團隊成員在面對「做什麼、怎麼做」的問題時，也會以自組織的方式去解決。每一天，團隊中的每一個人都要其他成員保持協調。為了保持同步，我們會創造基於敏捷實踐的溝通機會，這個也是實施敏捷的過程之一。

在ThoughtWorks有一個非常有名的活動叫Inception。Inception是啟動軟體設計和交付項目的方法，通過集中式、互動式的設計工作坊，幫助客戶在最短時間內對項目範圍達成一致，快速進入項目交付。而Inception的一個產出就是溝通計劃(Communication Plan)。比如在這個溝通計劃中會討論：以什麼頻率、什麼形式作項目的更新，比如說每周五以周報的形式作一些主要信息的更新；站會和迭代會議什麼時候召開，需要邀請哪些人，比如說業務負責人，技術負責人等等。

以下內容都會在溝通計劃中定義清楚:

寫在最後

回到文章開頭的部分，我認為可以將敏捷實踐和解決方案做如下對應：

團隊目標不一致

用電子牆和物理牆展示用戶故事、需求全景圖、項目進度燃盡圖；
通過迭代會議和功能演示會議對齊迭代計劃，項目進度、識別項目風險。

團隊成員不熟悉

基於敏捷實踐，創造更多的溝通機會，比如回顧會議、代碼審查和站立會議。通過不斷地創造這樣的溝通機會讓團隊成員更加默契。

信息發布不順暢

共享信息，制定溝通計劃；
最大程度的可視化。

文中提到了很多類型的敏捷實踐，這些實踐需要貫穿到團隊的日常活動中去，持續的實施和改進。行為心理學研究認為：21天以上的重複就會形成習慣。任何一個動作，重複21天就會變成習慣性的動作；任何一種想法，重複21天、或者重複驗證21次，就會變成習慣性的思維方式；任何一種信念或者有益的實踐，經過團隊持續驗證，它一定會成為團隊的信念和實踐。

劍道中有這樣一個心訣：守、破、離。

守：最初階段須遵從老師教誨，認真練習基礎，達到熟練的境界
破：基礎熟練後，試著突破原有規範讓自己得到更高層次的進化
離：在更高層次得到新的認識並總結，自創新招數、另闢新境界

項目管理者中的大多數人都處於「守」的階段：他們學習、吸收了前人的項目管理經驗，帶領自己的團隊有序地開展項目交付工作；但是他們經常困惑於某些在管理中反覆出現的問題，苦於找不到有效的解決方法，不得不在新的項目中重複之前的困惑；

有的項目管理者已經達到了「破」的層次：他們能夠以全局優化的角度去總結自身項目管理的經驗，並通過學習、分享及各種交流平台去開闊眼界、拓寬思路，借鑒或改良項目管理的方式方法，使之更適用於團隊；

而所有項目管理者的最高目標則是「離」：隨著項目經驗的不斷積累、對管理的思考日漸加深，對項目管理有了新的、更高層次的、屬於自己的獨特認知，並將其應用在實踐中，獨闢蹊徑，使整個項目管理思路煥然一新。

希望越來越多的項目管理者能夠達到更高的階段。這是我們在項目管理中不變的追求。

最近換了兩次項目管理軟體，一次使用公司自己做的項目管理軟體，現在是用IBM的Rational team concert. 之前還用過微軟的Team Foundation server, 還研究過一些其他的開源項目管理軟體，如TinyPM等等。

個人體會：如果沒有必要，不要引入項目管理軟體。引入一個項目管理軟體，會給大家帶來負擔，分散大家的注意力，越大的項目管理軟體帶來的負擔越重；而且項目的真實狀態很難在項目管理軟體里表現出來，真實的狀態來自於你每天和大家的交流，來自於你每天去使用自己的產品，而不是項目管理軟體大家每天更新的小時數或者是story points。所以我有時候就像這項目管理軟體除了給上面人看外，到底對項目是起到了推進作用還是副作用？

如果是小的項目，用Excel管理就好了。如果使用Scrum之類的流程，加上一塊白板，就很好了。然後在弄一個bug track的軟體。

個人使用worktile，還不錯，還有的功能都有了，主要是基於團隊和任務管理，可以任務分組可以管理附件可以@人，網頁登陸方便，還有手機端，郵件提醒，第三方集成豐富，通知全面，產品迭代快。不過東西多了有點亂，不能隨便打標籤和沒有IM，要是可以基於標籤搞個信息流時間軸就完美了。

Teambition 新入職員工。

從加入 Teambition 第一天起，就告別了「郵件時代」，開啟了工作的新模式。工作界面從此變成了下面的樣子，看見這些美美的封面，就覺得開心。大概一周左右的時間，就能夠完全上手，在上面嫻熟的處理工作。如果有一天沒用 Teambition，我覺得我們公司的人都不知道要怎麼工作了哈哈哈。

工作中的每一個事兒，其實都可以看作是一個項目，項目經過拆解，就變成了一個個任務甚至是子任務。完成任務是完成項目的唯一路徑。

我們在 Teambition 上面搭建了各種不同的項目，包括 IT 研發、財務管理、合同管理、企業諮詢分享、人才招聘、市場活動管理等等，每個員工可以根據自己的需求，在相應的項目中建任務，指派給相關的同事去解決。例如，我今天有一個合同需要處理，那我就進入「合同審批」項目，建立合同審批任務，指派給公司財務。通過設置自動化規則，合同流程能夠很迅速的走完，並且作為合同的申請人，能夠隨時查看合同目前所處的階段。

Teambition所打造的「協作」平台，能夠使所有人在「同一平面」進行工作，所有的項目和任務都輕鬆實現「可視化」，員工也能夠看見和了解項目全貌，在執行的過程中更能做到心中有數。

那麼，作為一個市場小夥伴，我們怎麼用 Teambition 來策劃一場活動呢？

Step 1: 在 Teambition 上建立一個「項目」，並將項目的相關成員加入項目中。

Step 2: 拆解項目，在項目中建立「任務分組」和「任務」

一個市場活動項目會設計多個部分或是多個階段，例如項目立項、活動預熱、人員安排、宣傳物料設計、物資準備、現場布置、活動執行、後期事務處理和活動總結等，我們根據每個項目的具體情況，建立項目的任務。無論什麼樣的市場活動，都一定要保證目標明確，嚴格控制時間、預算和執行，這樣才能夠確保活動的成功。

Step 3: 正式開始項目執行

在市場活動的項目執行中，溝通非常重要。作為活動的執行人員，常常需要跟公司內部和外部的合作夥伴去溝通，商討並確定活動中的具體執行和細節。這時候，我們需要建立具體的任務，將相關人等加入到具體任務中，並指派具體執行者，有必要的話，還可以再對任務進行拆解。在單個任務中，我們可以設置執行的時間、添加任務描述、關聯任務相關文件，並和相關人等進行溝通，所有的溝通記錄都會自動留存在Teambition 上。

Step4: 項目總結和回顧

在項目順利進行之後，我們有必要對項目進行完整的回顧，回顧時既能發現項目本身可以更加完善的地方，習得經驗；管理層也能夠發現項目參與者在項目過程中的配合度和完成情況，做好員工管理。

以上的步驟都是在 Teambition 的「任務」板塊中進行。除了「任務」之外，針對每一個項目，Teambition 都配備了「分享」、「文件」和「日程」等基礎功能，這些功能的用途看名字就很清楚了，再次就不過多闡述。不過必須要說的是，所有的功能之間，都能夠相互關聯，把項目中的每一個元素串起來。

對於最基礎的項目管理，Teambition 完全可以實現。

輕流作為一款數據管理和團隊協作的小工具，我們習慣於用輕流進行各類協作。在團隊內部，團隊協作是時時刻刻都存在著的，具體流程會根據不同的使用場景發生變化。

我們就挑幾個具體的場景來分享一下：

IT部門debug流程：

生產部門的倉儲流程：

銷售部門的門店業績提交：

人力資源部門的員工招聘：

財務行政部門的工資發放：

如果你對輕流的操作或者團隊的項目管理流程存在疑問的話，可以查看輕流的模板中心，這裡為你精心準備了各行各業的具體使用場景，一鍵定製你的項目信息收集反饋表格以及協作流程。

如果你有定製需求，也可以和我們聯繫，針對新客戶，我們會提供一次免費定製方案的機會。

輕流支持PC端和移動端，讓你隨時隨地處理數據，進行團隊協作。

歡迎來輕流的公眾號：輕流，進一步了解一個越來越好用的輕流。

項目協作用Tower（你的網上辦公室），在線文檔、任務分配，吊吊的。移動端有客戶端或用企業號，足矣滿足
代碼協作用Slack （Slack: Be less busy），綁定多種服務，各種推送及時通知，分組分主題討論也是叼叼的。

關於項目管理和協助概念性問題，有很多答主回答得很仔細了，這裡就就不多說了，下面直接簡單分享下，我們團隊是使用哪些工具有來進行項目管理和協助的？

1、企業微信（溝通和協助）

對於企業來說，溝通及時，節約時間，提高效率才是第一位。而企業微信像微信一如以往的簡約，在企業內部溝通和協作的專業性上具有無可比擬的優勢。重要的是與微信一致的溝通體驗，簡單易用，集成多種溝通方式。

更有著豐富的辦公應用，如預設打卡、審批、日報、公告等OA應用，如果你對這些應用不滿足，還可以通過API接入和第三方應用滿足更多個性需求，而我們作為企業微信第三方核心服務商，肯定是用自己的產品的企微雲來協助辦公（哈哈哈哈哈哈）！

像有工作流、CRM、企業學習、雲盤、任務、日誌、人資管理等三十個應用，幫助企業實現智能化、移動化的高效工作方式，節省管理成本，為協助企業移動辦公提升更大效率。

同時未來企業微信還將鏈接小程序、服務號等微信B端的能力，更好的融合微信生態為企業打造更豐富和個性化的業務協同工具，相信選擇企業微信作為溝通和協助辦公是個不錯的選擇！

2、TAPD（團隊任務/項目協助）

TAPD包括三個應用：看板、文件和 Wiki。看板包括工作中的工作記錄以及工作進度的透明展現，通過文件管理研發過程中的數據，通過Wiki 進行研發過程中知識的沉澱包括創意的滾動。直接通過看板+雲文檔+企業微信集成，基本滿足團隊的協作需要。

同時在添加的項目信息，後期有動態的變化，直接微信消息通知，效果及時性還是很好的。

3、Google 文檔（多人協助文檔）

我們之前是用石墨文檔的，但有時不穩定，不安全，後來改為用Google文檔了，對於Google文檔來說，提供了智能化的編輯和樣式工具，完全多人同時編輯，聊天和評論，做到無鎖實時協助，除了基本滿足各種office需求之外，搜索功能也非常智能和強大，最重要還是安全性非常好，目前國內應該沒有一款產品比Google文檔好用吧？應該沒意見吧？

--------------------------------

歡迎關註：

知乎： @企微科技

微信：企微雲平台DO1（do1info）

官網：企微雲，OA、CRM、HR 一站式企業微信工作平台

企微科技致力於分享前沿管理觀念，讓企業工作更有效率

從律師事務所的角度談談吧，手上每接到一個新案件/項目，我們的流程是這樣的：

一、確定基本情況
所謂「確定基本情況」，就是「搞清楚這到底是怎麼一回事兒」。具體而言，我們要搞清楚：（1）客戶現在面臨的實際情況是什麼；（2）客戶想達到一個什麼樣的目的；（3）我們能不能幫客戶達到這個目的，如果不能，那麼能不能達到次一等的目的。
為了完成上述任務，我們要進行兩部分的工作。一是事實調查，包括從客戶那裡複印資料，也包括去相關單位、部門調取一些相關檔案，有時還需要進行走訪。二是法律研究，即搞清楚這個案件/項目涉及到哪些相關法律法規，這些文件分別又都作出了什麼樣的規定。根據事實調查、法律研究的成果，製作一份中等篇幅的分析報告，這份分析報告將會在例會的時候拿出來，團隊內部一起討論。

二、確立長期、中期、短期任務，逐個分解，落實到人
根據分析報告及團隊的討論結果，主辦人將把完成這個案件/項目所需要的工作清單列到白板上，並分為長期、中期、短期三類。其中，短期任務和部分中期任務是有明確deadline的。每個任務落實到人，該人必須在團隊確定的deadline到來之前完成這個任務，若不能完成，需提前向團隊彙報並說明原因。

三、若有問題/困難，隨時溝通
如果團隊成員在工作中遇到了自己無法解決的問題，要第一時間與團隊主辦人聯繫。主辦人會全力幫助該成員解決問題。如果因溝通不暢而導致問題，則該團隊成員會在團隊內部受到批評。

四、工具
1.電話
2.QQ
3.微信
4.word
5.電子郵件

P,S,

1、真正的功力在於如何將一個非常龐大的目標拆解為若干個非常細微的小目標，這需要經驗和能力，不是一個帖子能說完的，需要自己踏踏實實去積累。

2、我個人最煩外行管理內行，所以那些「用某某工具/方法實現對不同行業/公司的管理」這種說辭在我看來很坑爹，對真正的專業人員來說也是一種不尊重——真正的職業選手，不需要別人來管理，只需要給他足夠的空間，他會做好給你看。

3、決定團隊工作效率和質量的，不在於工具，而在於人。私以為，想買個軟體就提升團隊工作能力/效率的，呵呵了就。