任務”作為大部分運營活動的核心組成要素，使得任務中心類的項目應用廣受歡迎。此類系統在實際研發過程中，涉及環節較多。對於新同學，順利的帶領一個此類項目是不小的挑戰。因此整理個人經驗成文，作為參考與借鑑。
國內遊戲運營對於玩家的習慣培養已經非常成熟了，基本一個新遊戲上線，迎接玩家的會是一系列活動：或是新手培養、或是簽到打卡、或是活躍度成長。
無論是以拍臉形式，還是遊戲內常駐的任務中心，其中的活動除去公告類，以及少數不強制引導用戶遊戲行為的活動，都可以看到“任務”這一元素，任務即運營希望玩家完成的目標，輔以恰當的獎勵，往往能很好的達到運營效果。
“任務”作為運營活動的核心組成要素，其普遍性和標配性毋庸置疑。
因此對於遊戲運營，做一個長線的任務系統或是一次性短期的任務類營銷活動，是一個常見且高頻的工作。
那麼基於這樣的需求背景，能夠一體化的解決此類系統開發的技術方案必定大受歡迎。
實際上，DataMore任務系統能力，就是為了一體化解決所有遊戲在類似系統上的研發服務訴求。
它可以涵蓋整體後端的開發，基於海量的遊戲數據，實現玩家實時遊戲行為數據的計算、玩家任務完成狀態的判定、活動系統邏輯的處理、玩家領獎判定與獎勵道具發放等等。另外在精細化大行其道的當下，玩家分群精細化任務也成為了活動系統的標配，所有這些，DataMore任務系統都可以支持。（打個小廣告）。
由於涉及研發模塊較多，對於負責此類項目的新同學，一開始在將此類系統高質量上線方面的確會存在一些困惑與問題，因為會涉及非常多數據技術細節以及內外部的協調與配合。
所以本文會將一個標準的任務系統類項目的開展流程、關鍵注意事項、以及遇到某些問題時的應對方案一一分享出來，給新同學一些參考。
因為是從項目管理角度來分享，因此會以項目流程貫穿全文，其中每個環節會說明需要重點關注的事項、風險點、以及一些做事的技巧，期間會進行一些個人心得的探討，項目管理方式千千萬，無關對錯，歡迎一起交流分享。
Key Point：流程是核心與靈魂，它很重要，清晰的流程會幫助研發團隊做的更好
首先我們回到項目管理的本質：是在有限的時間和資源條件下，達成最終目標的過程。作為項目的第一責任人，要想項目順利進展，理清流程非常關鍵。有條不紊，而不是手忙腳亂。
抽象的關鍵項目流程如下圖：
任務”作為大部分運營活動的核心組成要素，使得任務中心類的項目應用廣受歡迎。此類系統在實際研發過程中，涉及環節較多。對於新同學，順利的帶領一個此類項目是不小的挑戰。因此整理個人經驗成文，作為參考與借鑑。
國內遊戲運營對於玩家的習慣培養已經非常成熟了，基本一個新遊戲上線，迎接玩家的會是一系列活動：或是新手培養、或是簽到打卡、或是活躍度成長。
無論是以拍臉形式，還是遊戲內常駐的任務中心，其中的活動除去公告類，以及少數不強制引導用戶遊戲行為的活動，都可以看到“任務”這一元素，任務即運營希望玩家完成的目標，輔以恰當的獎勵，往往能很好的達到運營效果。
“任務”作為運營活動的核心組成要素，其普遍性和標配性毋庸置疑。
因此對於遊戲運營，做一個長線的任務系統或是一次性短期的任務類營銷活動，是一個常見且高頻的工作。
那麼基於這樣的需求背景，能夠一體化的解決此類系統開發的技術方案必定大受歡迎。
實際上，DataMore任務系統能力，就是為了一體化解決所有遊戲在類似系統上的研發服務訴求。
它可以涵蓋整體後端的開發，基於海量的遊戲數據，實現玩家實時遊戲行為數據的計算、玩家任務完成狀態的判定、活動系統邏輯的處理、玩家領獎判定與獎勵道具發放等等。另外在精細化大行其道的當下，玩家分群精細化任務也成為了活動系統的標配，所有這些，DataMore任務系統都可以支持。（打個小廣告）。
由於涉及研發模塊較多，對於負責此類項目的新同學，一開始在將此類系統高質量上線方面的確會存在一些困惑與問題，因為會涉及非常多數據技術細節以及內外部的協調與配合。
所以本文會將一個標準的任務系統類項目的開展流程、關鍵注意事項、以及遇到某些問題時的應對方案一一分享出來，給新同學一些參考。
因為是從項目管理角度來分享，因此會以項目流程貫穿全文，其中每個環節會說明需要重點關注的事項、風險點、以及一些做事的技巧，期間會進行一些個人心得的探討，項目管理方式千千萬，無關對錯，歡迎一起交流分享。
Key Point：流程是核心與靈魂，它很重要，清晰的流程會幫助研發團隊做的更好
首先我們回到項目管理的本質：是在有限的時間和資源條件下，達成最終目標的過程。作為項目的第一責任人，要想項目順利進展，理清流程非常關鍵。有條不紊，而不是手忙腳亂。
抽象的關鍵項目流程如下圖：
圖1：任務中心型項目管理流程
可能看到這裡，大家會想要說這不就是常規的項目流程嗎？對，沒錯。借用寧向東在描述管理學的一句話來解釋：“管理是介於人文與科學的一門學科”，實際上項目管理本身也是一門說起來似乎很簡單，但實際做起來卻需要內功、技巧和經驗的學問。
請接著往下看吧~
² 確認合作：干係人清晰
一個項目能夠啟動立項的前提條件是，各方參與人員對此項目能夠達成一致，尤其是對於跨團隊甚至跨部門合作的項目。
策劃/運營團隊負責整體需求設計和運營策略方向的把控，技術研發團隊負責具體的實現，數據分析同學負責效果的分析與迭代方向建議。
作為其中的負責人，僅僅瞭解內部研發系統的模塊分工是遠遠不夠，在項目與各方達成初步的合作意向時，就需要清晰的明確，此次前端、後端分別是哪個團隊來負責研發，大家的分工邊界大概在哪裡。設計、重構、測試資源分別是哪個團隊負責，甚至是禮包單誰來配置這種細節問題，這時也可以進行溝通明確。
換一句話來講，在聊合作的這一步，基本可以清楚的知道，這個項目會涉及多少團隊，大家的職責範圍是什麼。
² 需求梳理：知道要做什麼
對於團隊，負責項目管理並不是劃分好開發人員、測試人員就萬事大吉。
PM作為負責人，還需要進行需求的技術化梳理。這種需求梳理不是簡單的把產品方的需求文檔進行轉達，因為業務運營或策劃，他們的需求文檔是從活動角度去陳述，不完全瞭解數據型項目開發細節，當然也無法準確給出團隊開發所需要的形式的文檔。
那我們需要從這份偏活動說明的文檔中，抽象轉化出團隊需要的開發文檔，讓開發可以非常簡單直接的理解他需要做什麼，避免理解偏差和溝通成本，即PM要成為最瞭解這個系統活動的邏輯和內容細節的人，以確保在整個開發過程中，大家對於需求的理解是一致的。否則後面所有的研發工作都可能是浪費時間與人力。
儘管各類活動或系統在規則設計時有所差異，但還是有一些公共的清單內容，可以幫助新同學進行需求梳理：
ü 參加活動的玩家資格，比如只有迴流玩家能參與活動或者是不限制玩家類型
ü 活動週期，即活動準確的開始和結束時間
ü 玩家賬號維度，不同遊戲本身賬號就存在區別，比如賬號+系統的形式、賬號+系統+角色的形式，活動需要明確玩家參與維度，關係到所有實時任務數據計算、道具信息等
ü 是否有精細化模塊，比如根據玩家畫像標籤推薦不同的任務、或者根據玩家偏好進行不同獎勵配置
ü 任務下發場景，是玩家進入頁面才能看到任務內容，還是需要根據玩家遊戲行為來觸發任務的分配。比如玩家迴流到遊戲那一刻系統需要自動給玩家下發任務就屬於後者。這塊會涉及到不同的技術方案組合，比較複雜需要重點關注一下。在前面的場景下，每個玩家的活動時間窗口實際是不一樣的，需要格外注意。
ü 任務完成周期，玩家需要在多長時間內完成此任務，一天內做完、一週又或者是一個月，還有一種可能是從任務分配時間點到某個固定的時間。另外對於有些時候為了避免玩家高在線時刻刷新影響玩家體驗，會進行任務週期刷新時間偏移的設計，比如某每日任務採用凌晨6點刷新的邏輯等
ü 任務激活時間，在某些系統設計中，存在所有任務統一分配，但不同任務激活（即玩家可做任務可領獎）的時間點會有區別，比如第一天解鎖、第二天解鎖、第三天解鎖等
ü 任務邏輯關聯，在另外一些設計中，可能任務之間存在關聯邏輯，必須第一個任務完成後才能解鎖第二個任務，依次往後
ü 任務完成條件，明確需要完成的任務，是否有特殊要求等，比如需要正常完成、排除組隊形式等，不同類型的遊戲會有所區別
ü 禮包道具信息，每個任務對應的禮包組應該如何配置
ü 其它活動邏輯，比如支持玩家刷新任務、支持道具回收
ü 其它系統要求，比如是否需要支持頁面banner圖片、活動ICON、道具ICON配置化等
基於這個清單，轉化出一份開發能夠簡單、清晰、準確理解需求的文檔，是這一步的目標。項目負責人要成為最清楚項目需求的人。
² 技術評審：控制整體方向
技術評審的目的，一是澄清需求，二是確認技術邊界。
如果是和其它團隊合作完成研發，建議小範圍先進行第一次評審，敲定最佳的技術方案。然後再約其它團隊進行整體的評估，確認好邊界需求的處理。有一些功能邏輯，實際上放在前端或者後臺都可以，那麼就儘量與大家一起協商到對於整個系統來講最簡潔的方案架構，畢竟技術實現越複雜，鏈條越長，出問題的概率也就會相應加大。
作為PM，有責任也有義務去從風險的角度規避過於複雜的技術實現方案。
對於任務中心後端的評審，主要涉及如下模塊：
任務”作為大部分運營活動的核心組成要素，使得任務中心類的項目應用廣受歡迎。此類系統在實際研發過程中，涉及環節較多。對於新同學，順利的帶領一個此類項目是不小的挑戰。因此整理個人經驗成文，作為參考與借鑑。
國內遊戲運營對於玩家的習慣培養已經非常成熟了，基本一個新遊戲上線，迎接玩家的會是一系列活動：或是新手培養、或是簽到打卡、或是活躍度成長。
無論是以拍臉形式，還是遊戲內常駐的任務中心，其中的活動除去公告類，以及少數不強制引導用戶遊戲行為的活動，都可以看到“任務”這一元素，任務即運營希望玩家完成的目標，輔以恰當的獎勵，往往能很好的達到運營效果。
“任務”作為運營活動的核心組成要素，其普遍性和標配性毋庸置疑。
因此對於遊戲運營，做一個長線的任務系統或是一次性短期的任務類營銷活動，是一個常見且高頻的工作。
那麼基於這樣的需求背景，能夠一體化的解決此類系統開發的技術方案必定大受歡迎。
實際上，DataMore任務系統能力，就是為了一體化解決所有遊戲在類似系統上的研發服務訴求。
它可以涵蓋整體後端的開發，基於海量的遊戲數據，實現玩家實時遊戲行為數據的計算、玩家任務完成狀態的判定、活動系統邏輯的處理、玩家領獎判定與獎勵道具發放等等。另外在精細化大行其道的當下，玩家分群精細化任務也成為了活動系統的標配，所有這些，DataMore任務系統都可以支持。（打個小廣告）。
由於涉及研發模塊較多，對於負責此類項目的新同學，一開始在將此類系統高質量上線方面的確會存在一些困惑與問題，因為會涉及非常多數據技術細節以及內外部的協調與配合。
所以本文會將一個標準的任務系統類項目的開展流程、關鍵注意事項、以及遇到某些問題時的應對方案一一分享出來，給新同學一些參考。
因為是從項目管理角度來分享，因此會以項目流程貫穿全文，其中每個環節會說明需要重點關注的事項、風險點、以及一些做事的技巧，期間會進行一些個人心得的探討，項目管理方式千千萬，無關對錯，歡迎一起交流分享。
Key Point：流程是核心與靈魂，它很重要，清晰的流程會幫助研發團隊做的更好
首先我們回到項目管理的本質：是在有限的時間和資源條件下，達成最終目標的過程。作為項目的第一責任人，要想項目順利進展，理清流程非常關鍵。有條不紊，而不是手忙腳亂。
抽象的關鍵項目流程如下圖：
圖1：任務中心型項目管理流程
可能看到這裡，大家會想要說這不就是常規的項目流程嗎？對，沒錯。借用寧向東在描述管理學的一句話來解釋：“管理是介於人文與科學的一門學科”，實際上項目管理本身也是一門說起來似乎很簡單，但實際做起來卻需要內功、技巧和經驗的學問。
請接著往下看吧~
² 確認合作：干係人清晰
一個項目能夠啟動立項的前提條件是，各方參與人員對此項目能夠達成一致，尤其是對於跨團隊甚至跨部門合作的項目。
策劃/運營團隊負責整體需求設計和運營策略方向的把控，技術研發團隊負責具體的實現，數據分析同學負責效果的分析與迭代方向建議。
作為其中的負責人，僅僅瞭解內部研發系統的模塊分工是遠遠不夠，在項目與各方達成初步的合作意向時，就需要清晰的明確，此次前端、後端分別是哪個團隊來負責研發，大家的分工邊界大概在哪裡。設計、重構、測試資源分別是哪個團隊負責，甚至是禮包單誰來配置這種細節問題，這時也可以進行溝通明確。
換一句話來講，在聊合作的這一步，基本可以清楚的知道，這個項目會涉及多少團隊，大家的職責範圍是什麼。
² 需求梳理：知道要做什麼
對於團隊，負責項目管理並不是劃分好開發人員、測試人員就萬事大吉。
PM作為負責人，還需要進行需求的技術化梳理。這種需求梳理不是簡單的把產品方的需求文檔進行轉達，因為業務運營或策劃，他們的需求文檔是從活動角度去陳述，不完全瞭解數據型項目開發細節，當然也無法準確給出團隊開發所需要的形式的文檔。
那我們需要從這份偏活動說明的文檔中，抽象轉化出團隊需要的開發文檔，讓開發可以非常簡單直接的理解他需要做什麼，避免理解偏差和溝通成本，即PM要成為最瞭解這個系統活動的邏輯和內容細節的人，以確保在整個開發過程中，大家對於需求的理解是一致的。否則後面所有的研發工作都可能是浪費時間與人力。
儘管各類活動或系統在規則設計時有所差異，但還是有一些公共的清單內容，可以幫助新同學進行需求梳理：
ü 參加活動的玩家資格，比如只有迴流玩家能參與活動或者是不限制玩家類型
ü 活動週期，即活動準確的開始和結束時間
ü 玩家賬號維度，不同遊戲本身賬號就存在區別，比如賬號+系統的形式、賬號+系統+角色的形式，活動需要明確玩家參與維度，關係到所有實時任務數據計算、道具信息等
ü 是否有精細化模塊，比如根據玩家畫像標籤推薦不同的任務、或者根據玩家偏好進行不同獎勵配置
ü 任務下發場景，是玩家進入頁面才能看到任務內容，還是需要根據玩家遊戲行為來觸發任務的分配。比如玩家迴流到遊戲那一刻系統需要自動給玩家下發任務就屬於後者。這塊會涉及到不同的技術方案組合，比較複雜需要重點關注一下。在前面的場景下，每個玩家的活動時間窗口實際是不一樣的，需要格外注意。
ü 任務完成周期，玩家需要在多長時間內完成此任務，一天內做完、一週又或者是一個月，還有一種可能是從任務分配時間點到某個固定的時間。另外對於有些時候為了避免玩家高在線時刻刷新影響玩家體驗，會進行任務週期刷新時間偏移的設計，比如某每日任務採用凌晨6點刷新的邏輯等
ü 任務激活時間，在某些系統設計中，存在所有任務統一分配，但不同任務激活（即玩家可做任務可領獎）的時間點會有區別，比如第一天解鎖、第二天解鎖、第三天解鎖等
ü 任務邏輯關聯，在另外一些設計中，可能任務之間存在關聯邏輯，必須第一個任務完成後才能解鎖第二個任務，依次往後
ü 任務完成條件，明確需要完成的任務，是否有特殊要求等，比如需要正常完成、排除組隊形式等，不同類型的遊戲會有所區別
ü 禮包道具信息，每個任務對應的禮包組應該如何配置
ü 其它活動邏輯，比如支持玩家刷新任務、支持道具回收
ü 其它系統要求，比如是否需要支持頁面banner圖片、活動ICON、道具ICON配置化等
基於這個清單，轉化出一份開發能夠簡單、清晰、準確理解需求的文檔，是這一步的目標。項目負責人要成為最清楚項目需求的人。
² 技術評審：控制整體方向
技術評審的目的，一是澄清需求，二是確認技術邊界。
如果是和其它團隊合作完成研發，建議小範圍先進行第一次評審，敲定最佳的技術方案。然後再約其它團隊進行整體的評估，確認好邊界需求的處理。有一些功能邏輯，實際上放在前端或者後臺都可以，那麼就儘量與大家一起協商到對於整個系統來講最簡潔的方案架構，畢竟技術實現越複雜，鏈條越長，出問題的概率也就會相應加大。
作為PM，有責任也有義務去從風險的角度規避過於複雜的技術實現方案。
對於任務中心後端的評審，主要涉及如下模塊：
圖2：任務中心評估模塊
涉及外部合作的部分，比如前端，這時候，需要對其它團隊的內容有一定的瞭解。清楚哪些內容是可做的、哪些存在技術障礙。在這些基礎之上的技術評審才能更加高效與準確。
² 時間規劃：關鍵節點
作為負責人，在項目過程中需要關注的更多是全局整體是否順利開展。需要了解項目涉及的技術模塊，但不要陷入技術細節。對於核心關鍵的模塊，交給對應模塊的開發全權負責。
PM的重點是把控好關鍵的時間點，評估這個時間點對於項目deadline是否來得及，對於該模塊開發週期是否足夠，是否會存在delay風險。如果在時間規劃的時候就存在肉眼可見的延期風險，那基本這個時間規劃就是不合格的。
另外注意預留足夠的測試時間以及buffer，畢竟測試全面才能保證質量，而要堅定的記住過程中一定會出現這樣或那樣的突發問題，佔滿你項目的buffer時間。
這裡建議採用VISIO畫好項目里程碑，並且周知所有干係人，大家按照約定來執行。
任務”作為大部分運營活動的核心組成要素，使得任務中心類的項目應用廣受歡迎。此類系統在實際研發過程中，涉及環節較多。對於新同學，順利的帶領一個此類項目是不小的挑戰。因此整理個人經驗成文，作為參考與借鑑。
國內遊戲運營對於玩家的習慣培養已經非常成熟了，基本一個新遊戲上線，迎接玩家的會是一系列活動：或是新手培養、或是簽到打卡、或是活躍度成長。
無論是以拍臉形式，還是遊戲內常駐的任務中心，其中的活動除去公告類，以及少數不強制引導用戶遊戲行為的活動，都可以看到“任務”這一元素，任務即運營希望玩家完成的目標，輔以恰當的獎勵，往往能很好的達到運營效果。
“任務”作為運營活動的核心組成要素，其普遍性和標配性毋庸置疑。
因此對於遊戲運營，做一個長線的任務系統或是一次性短期的任務類營銷活動，是一個常見且高頻的工作。
那麼基於這樣的需求背景，能夠一體化的解決此類系統開發的技術方案必定大受歡迎。
實際上，DataMore任務系統能力，就是為了一體化解決所有遊戲在類似系統上的研發服務訴求。
它可以涵蓋整體後端的開發，基於海量的遊戲數據，實現玩家實時遊戲行為數據的計算、玩家任務完成狀態的判定、活動系統邏輯的處理、玩家領獎判定與獎勵道具發放等等。另外在精細化大行其道的當下，玩家分群精細化任務也成為了活動系統的標配，所有這些，DataMore任務系統都可以支持。（打個小廣告）。
由於涉及研發模塊較多，對於負責此類項目的新同學，一開始在將此類系統高質量上線方面的確會存在一些困惑與問題，因為會涉及非常多數據技術細節以及內外部的協調與配合。
所以本文會將一個標準的任務系統類項目的開展流程、關鍵注意事項、以及遇到某些問題時的應對方案一一分享出來，給新同學一些參考。
因為是從項目管理角度來分享，因此會以項目流程貫穿全文，其中每個環節會說明需要重點關注的事項、風險點、以及一些做事的技巧，期間會進行一些個人心得的探討，項目管理方式千千萬，無關對錯，歡迎一起交流分享。
Key Point：流程是核心與靈魂，它很重要，清晰的流程會幫助研發團隊做的更好
首先我們回到項目管理的本質：是在有限的時間和資源條件下，達成最終目標的過程。作為項目的第一責任人，要想項目順利進展，理清流程非常關鍵。有條不紊，而不是手忙腳亂。
抽象的關鍵項目流程如下圖：
圖1：任務中心型項目管理流程
可能看到這裡，大家會想要說這不就是常規的項目流程嗎？對，沒錯。借用寧向東在描述管理學的一句話來解釋：“管理是介於人文與科學的一門學科”，實際上項目管理本身也是一門說起來似乎很簡單，但實際做起來卻需要內功、技巧和經驗的學問。
請接著往下看吧~
² 確認合作：干係人清晰
一個項目能夠啟動立項的前提條件是，各方參與人員對此項目能夠達成一致，尤其是對於跨團隊甚至跨部門合作的項目。
策劃/運營團隊負責整體需求設計和運營策略方向的把控，技術研發團隊負責具體的實現，數據分析同學負責效果的分析與迭代方向建議。
作為其中的負責人，僅僅瞭解內部研發系統的模塊分工是遠遠不夠，在項目與各方達成初步的合作意向時，就需要清晰的明確，此次前端、後端分別是哪個團隊來負責研發，大家的分工邊界大概在哪裡。設計、重構、測試資源分別是哪個團隊負責，甚至是禮包單誰來配置這種細節問題，這時也可以進行溝通明確。
換一句話來講，在聊合作的這一步，基本可以清楚的知道，這個項目會涉及多少團隊，大家的職責範圍是什麼。
² 需求梳理：知道要做什麼
對於團隊，負責項目管理並不是劃分好開發人員、測試人員就萬事大吉。
PM作為負責人，還需要進行需求的技術化梳理。這種需求梳理不是簡單的把產品方的需求文檔進行轉達，因為業務運營或策劃，他們的需求文檔是從活動角度去陳述，不完全瞭解數據型項目開發細節，當然也無法準確給出團隊開發所需要的形式的文檔。
那我們需要從這份偏活動說明的文檔中，抽象轉化出團隊需要的開發文檔，讓開發可以非常簡單直接的理解他需要做什麼，避免理解偏差和溝通成本，即PM要成為最瞭解這個系統活動的邏輯和內容細節的人，以確保在整個開發過程中，大家對於需求的理解是一致的。否則後面所有的研發工作都可能是浪費時間與人力。
儘管各類活動或系統在規則設計時有所差異，但還是有一些公共的清單內容，可以幫助新同學進行需求梳理：
ü 參加活動的玩家資格，比如只有迴流玩家能參與活動或者是不限制玩家類型
ü 活動週期，即活動準確的開始和結束時間
ü 玩家賬號維度，不同遊戲本身賬號就存在區別，比如賬號+系統的形式、賬號+系統+角色的形式，活動需要明確玩家參與維度，關係到所有實時任務數據計算、道具信息等
ü 是否有精細化模塊，比如根據玩家畫像標籤推薦不同的任務、或者根據玩家偏好進行不同獎勵配置
ü 任務下發場景，是玩家進入頁面才能看到任務內容，還是需要根據玩家遊戲行為來觸發任務的分配。比如玩家迴流到遊戲那一刻系統需要自動給玩家下發任務就屬於後者。這塊會涉及到不同的技術方案組合，比較複雜需要重點關注一下。在前面的場景下，每個玩家的活動時間窗口實際是不一樣的，需要格外注意。
ü 任務完成周期，玩家需要在多長時間內完成此任務，一天內做完、一週又或者是一個月，還有一種可能是從任務分配時間點到某個固定的時間。另外對於有些時候為了避免玩家高在線時刻刷新影響玩家體驗，會進行任務週期刷新時間偏移的設計，比如某每日任務採用凌晨6點刷新的邏輯等
ü 任務激活時間，在某些系統設計中，存在所有任務統一分配，但不同任務激活（即玩家可做任務可領獎）的時間點會有區別，比如第一天解鎖、第二天解鎖、第三天解鎖等
ü 任務邏輯關聯，在另外一些設計中，可能任務之間存在關聯邏輯，必須第一個任務完成後才能解鎖第二個任務，依次往後
ü 任務完成條件，明確需要完成的任務，是否有特殊要求等，比如需要正常完成、排除組隊形式等，不同類型的遊戲會有所區別
ü 禮包道具信息，每個任務對應的禮包組應該如何配置
ü 其它活動邏輯，比如支持玩家刷新任務、支持道具回收
ü 其它系統要求，比如是否需要支持頁面banner圖片、活動ICON、道具ICON配置化等
基於這個清單，轉化出一份開發能夠簡單、清晰、準確理解需求的文檔，是這一步的目標。項目負責人要成為最清楚項目需求的人。
² 技術評審：控制整體方向
技術評審的目的，一是澄清需求，二是確認技術邊界。
如果是和其它團隊合作完成研發，建議小範圍先進行第一次評審，敲定最佳的技術方案。然後再約其它團隊進行整體的評估，確認好邊界需求的處理。有一些功能邏輯，實際上放在前端或者後臺都可以，那麼就儘量與大家一起協商到對於整個系統來講最簡潔的方案架構，畢竟技術實現越複雜，鏈條越長，出問題的概率也就會相應加大。
作為PM，有責任也有義務去從風險的角度規避過於複雜的技術實現方案。
對於任務中心後端的評審，主要涉及如下模塊：
圖2：任務中心評估模塊
涉及外部合作的部分，比如前端，這時候，需要對其它團隊的內容有一定的瞭解。清楚哪些內容是可做的、哪些存在技術障礙。在這些基礎之上的技術評審才能更加高效與準確。
² 時間規劃：關鍵節點
作為負責人，在項目過程中需要關注的更多是全局整體是否順利開展。需要了解項目涉及的技術模塊，但不要陷入技術細節。對於核心關鍵的模塊，交給對應模塊的開發全權負責。
PM的重點是把控好關鍵的時間點，評估這個時間點對於項目deadline是否來得及，對於該模塊開發週期是否足夠，是否會存在delay風險。如果在時間規劃的時候就存在肉眼可見的延期風險，那基本這個時間規劃就是不合格的。
另外注意預留足夠的測試時間以及buffer，畢竟測試全面才能保證質量，而要堅定的記住過程中一定會出現這樣或那樣的突發問題，佔滿你項目的buffer時間。
這裡建議採用VISIO畫好項目里程碑，並且周知所有干係人，大家按照約定來執行。
圖3：示例-里程碑（非真實項目計劃）
當然並不是表示定好時間到點驗收是唯一需要做的工作。過程監控和協助，也是關鍵工作。作為負責人，要有能力能夠識別和判斷當前項目是否存在風險，當前模塊是否存在風險。還是那句話，可以不關注研發細節不關心每一行代碼如何寫，但必須關心時間是否來得及。
² 開發期間：跟進不僅是問進度
進入開發期後，提前準備好這些前置的資源（比如美術、道具信息等），可以儘量避免因為等待配置或者UI設計等耽擱的開發時間。
雖然每個模塊開發一定是可以也必須為自己工作負責的，但作為一個負責任的項目管理者，多思考此時是否會出現容易被誤解的信息，是否有某些特殊的邏輯容易被忽視，是否有措施可以保證整體質量和進度的正常也非常必要。雙重保證，項目效果會更好。
另外一點，在這個環節，要能夠嚴格控制需求的變更。除非是原始的邏輯設計存在嚴重的問題和紕漏，會影響整個系統上線後的運營效果的話，就另當別論。不合理的不必要的需求變更通通控制住，避免因為來回變更、信息偏差導致的項目災難。畢竟換位思考一下，在開發期間改需求，是很讓研發人員煩惱的一件事情。
數據指標開發完成後，先進行開發自測，規避大多數問題，避免在轉測後耗費太多時間進行任務數據測試和溝通。
最後，聯調時候，主動推進問題解決與團隊間的配合。
² 轉測試：環境與用例
測試環境，針對不同的業務場景會有不一樣的點。有些業務需要跟研發版本、有些業務是新業務接入暫時還沒有完善的環境可測、有些業務是代理產品需要外部研發配合等等。你需要懂得基於不同的情境進行判斷，和開發同學一起確認好最佳的測試方案。
任務部分會提供2套環境：測試環境與正式環境。從項目成本和效率考慮，除非測試流程強制要求搭建2套物理隔離的測試環境與正式環境，底層數據建議都採用正式環境進行測試。因為涉及任務多，數據開發需要接入數據、計算、發佈部署等等，成本的確比較高，在某些情況下也不是非常有必要。那麼採用任務接口無論是測試還是正式，都對接正式的數據指標的方案性價比會比較高。這樣說會有點抽象，畫個圖示例一下：
任務”作為大部分運營活動的核心組成要素，使得任務中心類的項目應用廣受歡迎。此類系統在實際研發過程中，涉及環節較多。對於新同學，順利的帶領一個此類項目是不小的挑戰。因此整理個人經驗成文，作為參考與借鑑。
國內遊戲運營對於玩家的習慣培養已經非常成熟了，基本一個新遊戲上線，迎接玩家的會是一系列活動：或是新手培養、或是簽到打卡、或是活躍度成長。
無論是以拍臉形式，還是遊戲內常駐的任務中心，其中的活動除去公告類，以及少數不強制引導用戶遊戲行為的活動，都可以看到“任務”這一元素，任務即運營希望玩家完成的目標，輔以恰當的獎勵，往往能很好的達到運營效果。
“任務”作為運營活動的核心組成要素，其普遍性和標配性毋庸置疑。
因此對於遊戲運營，做一個長線的任務系統或是一次性短期的任務類營銷活動，是一個常見且高頻的工作。
那麼基於這樣的需求背景，能夠一體化的解決此類系統開發的技術方案必定大受歡迎。
實際上，DataMore任務系統能力，就是為了一體化解決所有遊戲在類似系統上的研發服務訴求。
它可以涵蓋整體後端的開發，基於海量的遊戲數據，實現玩家實時遊戲行為數據的計算、玩家任務完成狀態的判定、活動系統邏輯的處理、玩家領獎判定與獎勵道具發放等等。另外在精細化大行其道的當下，玩家分群精細化任務也成為了活動系統的標配，所有這些，DataMore任務系統都可以支持。（打個小廣告）。
由於涉及研發模塊較多，對於負責此類項目的新同學，一開始在將此類系統高質量上線方面的確會存在一些困惑與問題，因為會涉及非常多數據技術細節以及內外部的協調與配合。
所以本文會將一個標準的任務系統類項目的開展流程、關鍵注意事項、以及遇到某些問題時的應對方案一一分享出來，給新同學一些參考。
因為是從項目管理角度來分享，因此會以項目流程貫穿全文，其中每個環節會說明需要重點關注的事項、風險點、以及一些做事的技巧，期間會進行一些個人心得的探討，項目管理方式千千萬，無關對錯，歡迎一起交流分享。
Key Point：流程是核心與靈魂，它很重要，清晰的流程會幫助研發團隊做的更好
首先我們回到項目管理的本質：是在有限的時間和資源條件下，達成最終目標的過程。作為項目的第一責任人，要想項目順利進展，理清流程非常關鍵。有條不紊，而不是手忙腳亂。
抽象的關鍵項目流程如下圖：
圖1：任務中心型項目管理流程
可能看到這裡，大家會想要說這不就是常規的項目流程嗎？對，沒錯。借用寧向東在描述管理學的一句話來解釋：“管理是介於人文與科學的一門學科”，實際上項目管理本身也是一門說起來似乎很簡單，但實際做起來卻需要內功、技巧和經驗的學問。
請接著往下看吧~
² 確認合作：干係人清晰
一個項目能夠啟動立項的前提條件是，各方參與人員對此項目能夠達成一致，尤其是對於跨團隊甚至跨部門合作的項目。
策劃/運營團隊負責整體需求設計和運營策略方向的把控，技術研發團隊負責具體的實現，數據分析同學負責效果的分析與迭代方向建議。
作為其中的負責人，僅僅瞭解內部研發系統的模塊分工是遠遠不夠，在項目與各方達成初步的合作意向時，就需要清晰的明確，此次前端、後端分別是哪個團隊來負責研發，大家的分工邊界大概在哪裡。設計、重構、測試資源分別是哪個團隊負責，甚至是禮包單誰來配置這種細節問題，這時也可以進行溝通明確。
換一句話來講，在聊合作的這一步，基本可以清楚的知道，這個項目會涉及多少團隊，大家的職責範圍是什麼。
² 需求梳理：知道要做什麼
對於團隊，負責項目管理並不是劃分好開發人員、測試人員就萬事大吉。
PM作為負責人，還需要進行需求的技術化梳理。這種需求梳理不是簡單的把產品方的需求文檔進行轉達，因為業務運營或策劃，他們的需求文檔是從活動角度去陳述，不完全瞭解數據型項目開發細節，當然也無法準確給出團隊開發所需要的形式的文檔。
那我們需要從這份偏活動說明的文檔中，抽象轉化出團隊需要的開發文檔，讓開發可以非常簡單直接的理解他需要做什麼，避免理解偏差和溝通成本，即PM要成為最瞭解這個系統活動的邏輯和內容細節的人，以確保在整個開發過程中，大家對於需求的理解是一致的。否則後面所有的研發工作都可能是浪費時間與人力。
儘管各類活動或系統在規則設計時有所差異，但還是有一些公共的清單內容，可以幫助新同學進行需求梳理：
ü 參加活動的玩家資格，比如只有迴流玩家能參與活動或者是不限制玩家類型
ü 活動週期，即活動準確的開始和結束時間
ü 玩家賬號維度，不同遊戲本身賬號就存在區別，比如賬號+系統的形式、賬號+系統+角色的形式，活動需要明確玩家參與維度，關係到所有實時任務數據計算、道具信息等
ü 是否有精細化模塊，比如根據玩家畫像標籤推薦不同的任務、或者根據玩家偏好進行不同獎勵配置
ü 任務下發場景，是玩家進入頁面才能看到任務內容，還是需要根據玩家遊戲行為來觸發任務的分配。比如玩家迴流到遊戲那一刻系統需要自動給玩家下發任務就屬於後者。這塊會涉及到不同的技術方案組合，比較複雜需要重點關注一下。在前面的場景下，每個玩家的活動時間窗口實際是不一樣的，需要格外注意。
ü 任務完成周期，玩家需要在多長時間內完成此任務，一天內做完、一週又或者是一個月，還有一種可能是從任務分配時間點到某個固定的時間。另外對於有些時候為了避免玩家高在線時刻刷新影響玩家體驗，會進行任務週期刷新時間偏移的設計，比如某每日任務採用凌晨6點刷新的邏輯等
ü 任務激活時間，在某些系統設計中，存在所有任務統一分配，但不同任務激活（即玩家可做任務可領獎）的時間點會有區別，比如第一天解鎖、第二天解鎖、第三天解鎖等
ü 任務邏輯關聯，在另外一些設計中，可能任務之間存在關聯邏輯，必須第一個任務完成後才能解鎖第二個任務，依次往後
ü 任務完成條件，明確需要完成的任務，是否有特殊要求等，比如需要正常完成、排除組隊形式等，不同類型的遊戲會有所區別
ü 禮包道具信息，每個任務對應的禮包組應該如何配置
ü 其它活動邏輯，比如支持玩家刷新任務、支持道具回收
ü 其它系統要求，比如是否需要支持頁面banner圖片、活動ICON、道具ICON配置化等
基於這個清單，轉化出一份開發能夠簡單、清晰、準確理解需求的文檔，是這一步的目標。項目負責人要成為最清楚項目需求的人。
² 技術評審：控制整體方向
技術評審的目的，一是澄清需求，二是確認技術邊界。
如果是和其它團隊合作完成研發，建議小範圍先進行第一次評審，敲定最佳的技術方案。然後再約其它團隊進行整體的評估，確認好邊界需求的處理。有一些功能邏輯，實際上放在前端或者後臺都可以，那麼就儘量與大家一起協商到對於整個系統來講最簡潔的方案架構，畢竟技術實現越複雜，鏈條越長，出問題的概率也就會相應加大。
作為PM，有責任也有義務去從風險的角度規避過於複雜的技術實現方案。
對於任務中心後端的評審，主要涉及如下模塊：
圖2：任務中心評估模塊
涉及外部合作的部分，比如前端，這時候，需要對其它團隊的內容有一定的瞭解。清楚哪些內容是可做的、哪些存在技術障礙。在這些基礎之上的技術評審才能更加高效與準確。
² 時間規劃：關鍵節點
作為負責人，在項目過程中需要關注的更多是全局整體是否順利開展。需要了解項目涉及的技術模塊，但不要陷入技術細節。對於核心關鍵的模塊，交給對應模塊的開發全權負責。
PM的重點是把控好關鍵的時間點，評估這個時間點對於項目deadline是否來得及，對於該模塊開發週期是否足夠，是否會存在delay風險。如果在時間規劃的時候就存在肉眼可見的延期風險，那基本這個時間規劃就是不合格的。
另外注意預留足夠的測試時間以及buffer，畢竟測試全面才能保證質量，而要堅定的記住過程中一定會出現這樣或那樣的突發問題，佔滿你項目的buffer時間。
這裡建議採用VISIO畫好項目里程碑，並且周知所有干係人，大家按照約定來執行。
圖3：示例-里程碑（非真實項目計劃）
當然並不是表示定好時間到點驗收是唯一需要做的工作。過程監控和協助，也是關鍵工作。作為負責人，要有能力能夠識別和判斷當前項目是否存在風險，當前模塊是否存在風險。還是那句話，可以不關注研發細節不關心每一行代碼如何寫，但必須關心時間是否來得及。
² 開發期間：跟進不僅是問進度
進入開發期後，提前準備好這些前置的資源（比如美術、道具信息等），可以儘量避免因為等待配置或者UI設計等耽擱的開發時間。
雖然每個模塊開發一定是可以也必須為自己工作負責的，但作為一個負責任的項目管理者，多思考此時是否會出現容易被誤解的信息，是否有某些特殊的邏輯容易被忽視，是否有措施可以保證整體質量和進度的正常也非常必要。雙重保證，項目效果會更好。
另外一點，在這個環節，要能夠嚴格控制需求的變更。除非是原始的邏輯設計存在嚴重的問題和紕漏，會影響整個系統上線後的運營效果的話，就另當別論。不合理的不必要的需求變更通通控制住，避免因為來回變更、信息偏差導致的項目災難。畢竟換位思考一下，在開發期間改需求，是很讓研發人員煩惱的一件事情。
數據指標開發完成後，先進行開發自測，規避大多數問題，避免在轉測後耗費太多時間進行任務數據測試和溝通。
最後，聯調時候，主動推進問題解決與團隊間的配合。
² 轉測試：環境與用例
測試環境，針對不同的業務場景會有不一樣的點。有些業務需要跟研發版本、有些業務是新業務接入暫時還沒有完善的環境可測、有些業務是代理產品需要外部研發配合等等。你需要懂得基於不同的情境進行判斷，和開發同學一起確認好最佳的測試方案。
任務部分會提供2套環境：測試環境與正式環境。從項目成本和效率考慮，除非測試流程強制要求搭建2套物理隔離的測試環境與正式環境，底層數據建議都採用正式環境進行測試。因為涉及任務多，數據開發需要接入數據、計算、發佈部署等等，成本的確比較高，在某些情況下也不是非常有必要。那麼採用任務接口無論是測試還是正式，都對接正式的數據指標的方案性價比會比較高。這樣說會有點抽象，畫個圖示例一下：
圖4：測試方案1-完全獨立環境
任務”作為大部分運營活動的核心組成要素，使得任務中心類的項目應用廣受歡迎。此類系統在實際研發過程中，涉及環節較多。對於新同學，順利的帶領一個此類項目是不小的挑戰。因此整理個人經驗成文，作為參考與借鑑。
國內遊戲運營對於玩家的習慣培養已經非常成熟了，基本一個新遊戲上線，迎接玩家的會是一系列活動：或是新手培養、或是簽到打卡、或是活躍度成長。
無論是以拍臉形式，還是遊戲內常駐的任務中心，其中的活動除去公告類，以及少數不強制引導用戶遊戲行為的活動，都可以看到“任務”這一元素，任務即運營希望玩家完成的目標，輔以恰當的獎勵，往往能很好的達到運營效果。
“任務”作為運營活動的核心組成要素，其普遍性和標配性毋庸置疑。
因此對於遊戲運營，做一個長線的任務系統或是一次性短期的任務類營銷活動，是一個常見且高頻的工作。
那麼基於這樣的需求背景，能夠一體化的解決此類系統開發的技術方案必定大受歡迎。
實際上，DataMore任務系統能力，就是為了一體化解決所有遊戲在類似系統上的研發服務訴求。
它可以涵蓋整體後端的開發，基於海量的遊戲數據，實現玩家實時遊戲行為數據的計算、玩家任務完成狀態的判定、活動系統邏輯的處理、玩家領獎判定與獎勵道具發放等等。另外在精細化大行其道的當下，玩家分群精細化任務也成為了活動系統的標配，所有這些，DataMore任務系統都可以支持。（打個小廣告）。
由於涉及研發模塊較多，對於負責此類項目的新同學，一開始在將此類系統高質量上線方面的確會存在一些困惑與問題，因為會涉及非常多數據技術細節以及內外部的協調與配合。
所以本文會將一個標準的任務系統類項目的開展流程、關鍵注意事項、以及遇到某些問題時的應對方案一一分享出來，給新同學一些參考。
因為是從項目管理角度來分享，因此會以項目流程貫穿全文，其中每個環節會說明需要重點關注的事項、風險點、以及一些做事的技巧，期間會進行一些個人心得的探討，項目管理方式千千萬，無關對錯，歡迎一起交流分享。
Key Point：流程是核心與靈魂，它很重要，清晰的流程會幫助研發團隊做的更好
首先我們回到項目管理的本質：是在有限的時間和資源條件下，達成最終目標的過程。作為項目的第一責任人，要想項目順利進展，理清流程非常關鍵。有條不紊，而不是手忙腳亂。
抽象的關鍵項目流程如下圖：
圖1：任務中心型項目管理流程
可能看到這裡，大家會想要說這不就是常規的項目流程嗎？對，沒錯。借用寧向東在描述管理學的一句話來解釋：“管理是介於人文與科學的一門學科”，實際上項目管理本身也是一門說起來似乎很簡單，但實際做起來卻需要內功、技巧和經驗的學問。
請接著往下看吧~
² 確認合作：干係人清晰
一個項目能夠啟動立項的前提條件是，各方參與人員對此項目能夠達成一致，尤其是對於跨團隊甚至跨部門合作的項目。
策劃/運營團隊負責整體需求設計和運營策略方向的把控，技術研發團隊負責具體的實現，數據分析同學負責效果的分析與迭代方向建議。
作為其中的負責人，僅僅瞭解內部研發系統的模塊分工是遠遠不夠，在項目與各方達成初步的合作意向時，就需要清晰的明確，此次前端、後端分別是哪個團隊來負責研發，大家的分工邊界大概在哪裡。設計、重構、測試資源分別是哪個團隊負責，甚至是禮包單誰來配置這種細節問題，這時也可以進行溝通明確。
換一句話來講，在聊合作的這一步，基本可以清楚的知道，這個項目會涉及多少團隊，大家的職責範圍是什麼。
² 需求梳理：知道要做什麼
對於團隊，負責項目管理並不是劃分好開發人員、測試人員就萬事大吉。
PM作為負責人，還需要進行需求的技術化梳理。這種需求梳理不是簡單的把產品方的需求文檔進行轉達，因為業務運營或策劃，他們的需求文檔是從活動角度去陳述，不完全瞭解數據型項目開發細節，當然也無法準確給出團隊開發所需要的形式的文檔。
那我們需要從這份偏活動說明的文檔中，抽象轉化出團隊需要的開發文檔，讓開發可以非常簡單直接的理解他需要做什麼，避免理解偏差和溝通成本，即PM要成為最瞭解這個系統活動的邏輯和內容細節的人，以確保在整個開發過程中，大家對於需求的理解是一致的。否則後面所有的研發工作都可能是浪費時間與人力。
儘管各類活動或系統在規則設計時有所差異，但還是有一些公共的清單內容，可以幫助新同學進行需求梳理：
ü 參加活動的玩家資格，比如只有迴流玩家能參與活動或者是不限制玩家類型
ü 活動週期，即活動準確的開始和結束時間
ü 玩家賬號維度，不同遊戲本身賬號就存在區別，比如賬號+系統的形式、賬號+系統+角色的形式，活動需要明確玩家參與維度，關係到所有實時任務數據計算、道具信息等
ü 是否有精細化模塊，比如根據玩家畫像標籤推薦不同的任務、或者根據玩家偏好進行不同獎勵配置
ü 任務下發場景，是玩家進入頁面才能看到任務內容，還是需要根據玩家遊戲行為來觸發任務的分配。比如玩家迴流到遊戲那一刻系統需要自動給玩家下發任務就屬於後者。這塊會涉及到不同的技術方案組合，比較複雜需要重點關注一下。在前面的場景下，每個玩家的活動時間窗口實際是不一樣的，需要格外注意。
ü 任務完成周期，玩家需要在多長時間內完成此任務，一天內做完、一週又或者是一個月，還有一種可能是從任務分配時間點到某個固定的時間。另外對於有些時候為了避免玩家高在線時刻刷新影響玩家體驗，會進行任務週期刷新時間偏移的設計，比如某每日任務採用凌晨6點刷新的邏輯等
ü 任務激活時間，在某些系統設計中，存在所有任務統一分配，但不同任務激活（即玩家可做任務可領獎）的時間點會有區別，比如第一天解鎖、第二天解鎖、第三天解鎖等
ü 任務邏輯關聯，在另外一些設計中，可能任務之間存在關聯邏輯，必須第一個任務完成後才能解鎖第二個任務，依次往後
ü 任務完成條件，明確需要完成的任務，是否有特殊要求等，比如需要正常完成、排除組隊形式等，不同類型的遊戲會有所區別
ü 禮包道具信息，每個任務對應的禮包組應該如何配置
ü 其它活動邏輯，比如支持玩家刷新任務、支持道具回收
ü 其它系統要求，比如是否需要支持頁面banner圖片、活動ICON、道具ICON配置化等
基於這個清單，轉化出一份開發能夠簡單、清晰、準確理解需求的文檔，是這一步的目標。項目負責人要成為最清楚項目需求的人。
² 技術評審：控制整體方向
技術評審的目的，一是澄清需求，二是確認技術邊界。
如果是和其它團隊合作完成研發，建議小範圍先進行第一次評審，敲定最佳的技術方案。然後再約其它團隊進行整體的評估，確認好邊界需求的處理。有一些功能邏輯，實際上放在前端或者後臺都可以，那麼就儘量與大家一起協商到對於整個系統來講最簡潔的方案架構，畢竟技術實現越複雜，鏈條越長，出問題的概率也就會相應加大。
作為PM，有責任也有義務去從風險的角度規避過於複雜的技術實現方案。
對於任務中心後端的評審，主要涉及如下模塊：
圖2：任務中心評估模塊
涉及外部合作的部分，比如前端，這時候，需要對其它團隊的內容有一定的瞭解。清楚哪些內容是可做的、哪些存在技術障礙。在這些基礎之上的技術評審才能更加高效與準確。
² 時間規劃：關鍵節點
作為負責人，在項目過程中需要關注的更多是全局整體是否順利開展。需要了解項目涉及的技術模塊，但不要陷入技術細節。對於核心關鍵的模塊，交給對應模塊的開發全權負責。
PM的重點是把控好關鍵的時間點，評估這個時間點對於項目deadline是否來得及，對於該模塊開發週期是否足夠，是否會存在delay風險。如果在時間規劃的時候就存在肉眼可見的延期風險，那基本這個時間規劃就是不合格的。
另外注意預留足夠的測試時間以及buffer，畢竟測試全面才能保證質量，而要堅定的記住過程中一定會出現這樣或那樣的突發問題，佔滿你項目的buffer時間。
這裡建議採用VISIO畫好項目里程碑，並且周知所有干係人，大家按照約定來執行。
圖3：示例-里程碑（非真實項目計劃）
當然並不是表示定好時間到點驗收是唯一需要做的工作。過程監控和協助，也是關鍵工作。作為負責人，要有能力能夠識別和判斷當前項目是否存在風險，當前模塊是否存在風險。還是那句話，可以不關注研發細節不關心每一行代碼如何寫，但必須關心時間是否來得及。
² 開發期間：跟進不僅是問進度
進入開發期後，提前準備好這些前置的資源（比如美術、道具信息等），可以儘量避免因為等待配置或者UI設計等耽擱的開發時間。
雖然每個模塊開發一定是可以也必須為自己工作負責的，但作為一個負責任的項目管理者，多思考此時是否會出現容易被誤解的信息，是否有某些特殊的邏輯容易被忽視，是否有措施可以保證整體質量和進度的正常也非常必要。雙重保證，項目效果會更好。
另外一點，在這個環節，要能夠嚴格控制需求的變更。除非是原始的邏輯設計存在嚴重的問題和紕漏，會影響整個系統上線後的運營效果的話，就另當別論。不合理的不必要的需求變更通通控制住，避免因為來回變更、信息偏差導致的項目災難。畢竟換位思考一下，在開發期間改需求，是很讓研發人員煩惱的一件事情。
數據指標開發完成後，先進行開發自測，規避大多數問題，避免在轉測後耗費太多時間進行任務數據測試和溝通。
最後，聯調時候，主動推進問題解決與團隊間的配合。
² 轉測試：環境與用例
測試環境，針對不同的業務場景會有不一樣的點。有些業務需要跟研發版本、有些業務是新業務接入暫時還沒有完善的環境可測、有些業務是代理產品需要外部研發配合等等。你需要懂得基於不同的情境進行判斷，和開發同學一起確認好最佳的測試方案。
任務部分會提供2套環境：測試環境與正式環境。從項目成本和效率考慮，除非測試流程強制要求搭建2套物理隔離的測試環境與正式環境，底層數據建議都採用正式環境進行測試。因為涉及任務多，數據開發需要接入數據、計算、發佈部署等等，成本的確比較高，在某些情況下也不是非常有必要。那麼採用任務接口無論是測試還是正式，都對接正式的數據指標的方案性價比會比較高。這樣說會有點抽象，畫個圖示例一下：
圖4：測試方案1-完全獨立環境
圖5：測試方案2 – 底層數據複用
在某些場景下，前後端的開發進度不一致，可以先採用任務接口進行任務部分的測試，等前端開發完成後再進行頁面UI還原、圖片文案展示、點擊交互響應、兼容性等方面的測試。核心策略就是，儘量並行開發，減少等待和耦合，獨立測試，提升項目效率。
² 檢查上線：再多囉嗦一句
之前在寫項目管理風險的文章時，解釋過為什麼數據型項目比常規的項目要複雜。因為大數據本身存在的多樣性和複雜的情況。要絕對保證外網上線項目的質量，不僅僅是團隊研發口碑的問題，還有一個因素是一旦出現問題解決修正非常困難，對於玩家口碑體驗也有影響。
因此在上線之前，務必用標準的上線Checklist檢查所有的模塊、配置、時間等信息。多確認幾遍多囉嗦幾遍很有必要。
² 數據效果與迭代優化
項目上線不代表結束，我們所有的項目一定有肩負著它的數據運營目標。PM雖然不直接參與數據效果分析工作，但是對於項目的數據效果一定要非常關注，這關係到項目最終的價值呈現。
因此對於一個活動或系統，細緻深入的數據分析十分有必要，只有清楚地知道活動漏斗數據，才能知道哪個環節的設計是有問題的，哪個環節的用戶轉化沒有做好。在項目後面的迭代中才能進行鍼對性的改進優化。無論是前端資源設計、UI、交互，還是整體活動系統的邏輯規則設計，都可以通過細緻的數據分析效果來發現問題和解決優化。
因此在項目過程中，務必提前做好前後端數據埋點採集，這是在項目開始時就值得做且必須做的一件事，否則到後面會發現，數據分析這件事有心但舉步維艱。
整個項目過程中，一定要十分注意關鍵信息的同步與對齊。如果有多種方式與團隊成員溝通，比如工作群、項目記錄單、郵件等，都儘量覆蓋到，該當面確認的關鍵事項當面同步溝通。
在實際做項目過程中，還會有一些具體操作細節、會接觸到一些研發和管理系統，比如項目建單規範、數據開發系統建項目管理單、資源申請單等。當然在心中有譜的情況下，這些只是具體的執行細節了，問題不大。