中文字幕无码av不卡一区,亚洲综合AV永久无码精品一区二区,黑人巨大白妞出浆,黄色高清无码免费看,久久久久免费精品国产,久久无码人妻丰满熟妇区毛片,欧美日韩国产综合草草,久久福利网站,亚洲一区二区三区中文字幕在线,av国内精品久久久久影院

“任務”作為大部分運營活動的核心組成要素，使得任務中心類的項目應用廣受歡迎。此類系統在實際研發過程中，涉及環節較多。對于新同學，順利的帶領一個此類項目是不小的挑戰。因此整理個人經驗成文，作為參考與借鑒。

最近會有許多新同學來咨詢關于此類系統合作在項目管理方面的經驗信息，因為此類應用涉及研發環節較多，又確實有許多可以總結和分享的細節信息、經驗，因此整理出來，希望能夠對他人有所幫助。

國內游戲運營對于玩家的習慣培養已經非常成熟了，基本一個新游戲上線，迎接玩家的會是一系列活動：或是新手培養、或是簽到打卡、或是活躍度成長。

無論是以拍臉形式，還是游戲內常駐的任務中心，其中的活動除去公告類，以及少數不強制引導用戶游戲行為的活動，都可以看到“任務”這一元素，任務即運營希望玩家完成的目標，輔以恰當的獎勵，往往能很好的達到運營效果。

“任務”作為運營活動的核心組成要素，其普遍性和標配性毋庸置疑。

因此對于游戲運營，做一個長線的任務系統或是一次性短期的任務類營銷活動，是一個常見且高頻的工作。

那么基于這樣的需求背景，能夠一體化的解決此類系統開發的技術方案必定大受歡迎。

所以本文會將一個標準的任務系統類項目的開展流程、關鍵注意事項、以及遇到某些問題時的應對方案一一分享出來，給新同學一些參考。

因為是從項目管理角度來分享，因此會以項目流程貫穿全文，其中每個環節會說明需要重點關注的事項、風險點、以及一些做事的技巧，期間會進行一些個人心得的探討，項目管理方式千千萬，無關對錯，歡迎一起交流分享。

Key Point：流程是核心與靈魂，它很重要，清晰的流程會幫助研發團隊做的更好

首先我們回到項目管理的本質：是在有限的時間和資源條件下，達成最終目標的過程。作為項目的第一責任人，要想項目順利進展，理清流程非常關鍵。有條不紊，而不是手忙腳亂。

抽象的關鍵項目流程如下圖：

圖1：任務中心型項目管理流程

可能看到這里，大家會想要說這不就是常規的項目流程嗎？對，沒錯。借用寧向東在描述管理學的一句話來解釋：“管理是介于人文與科學的一門學科”，實際上項目管理本身也是一門說起來似乎很簡單，但實際做起來卻需要內功、技巧和經驗的學問。

請接著往下看吧~

確認合作：干系人清晰

一個項目能夠啟動立項的前提條件是，各方參與人員對此項目能夠達成一致，尤其是對于跨團隊甚至跨部門合作的項目。

策劃/運營團隊負責整體需求設計和運營策略方向的把控，技術研發團隊負責具體的實現，數據分析同學負責效果的分析與迭代方向建議。

作為其中的負責人，僅僅了解內部研發系統的模塊分工是遠遠不夠，在項目與各方達成初步的合作意向時，就需要清晰的明確，此次前端、后端分別是哪個團隊來負責研發，大家的分工邊界大概在哪里。設計、重構、測試資源分別是哪個團隊負責，甚至是禮包單誰來配置這種細節問題，這時也可以進行溝通明確。

換一句話來講，在聊合作的這一步，基本可以清楚的知道，這個項目會涉及多少團隊，大家的職責范圍是什么。

需求梳理：知道要做什么

對于團隊，負責項目管理并不是劃分好開發人員、測試人員就萬事大吉。

PM作為負責人，還需要進行需求的技術化梳理。這種需求梳理不是簡單的把產品方的需求文檔進行轉達，因為業務運營或策劃，他們的需求文檔是從活動角度去陳述，不完全了解數據型項目開發細節，當然也無法準確給出團隊開發所需要的形式的文檔。

那我們需要從這份偏活動說明的文檔中，抽象轉化出團隊需要的開發文檔，讓開發可以非常簡單直接的理解他需要做什么，避免理解偏差和溝通成本。即PM要成為最了解這個系統活動的邏輯和內容細節的人，以確保在整個開發過程中，大家對于需求的理解是一致的，否則后面所有的研發工作都可能是浪費時間與人力。

盡管各類活動或系統在規則設計時有所差異，但還是有一些公共的清單內容，可以幫助新同學進行需求梳理：

1. 參加活動的玩家資格，比如只有回流玩家能參與活動或者是不限制玩家類型。
2. 活動周期，即活動準確的開始和結束時間。
3. 玩家賬號維度，不同游戲本身賬號就存在區別，比如賬號+系統的形式、賬號+系統+角色的形式，活動需要明確玩家參與維度，關系到所有實時任務數據計算、道具信息等。
4. 是否有精細化模塊，比如根據玩家畫像標簽推薦不同的任務、或者根據玩家偏好進行不同獎勵配置。
5. 任務下發場景，是玩家進入頁面才能看到任務內容，還是需要根據玩家游戲行為來觸發任務的分配。比如玩家回流到游戲那一刻系統需要自動給玩家下發任務就屬于后者。這塊會涉及到不同的技術。方案組合，比較復雜需要重點關注一下。在前面的場景下，每個玩家的活動時間窗口實際是不一樣的，需要格外注意。
6. 任務完成周期，玩家需要在多長時間內完成此任務，一天內做完、一周又或者是一個月，還有一種可能是從任務分配時間點到某個固定的時間。另外對于有些時候為了避免玩家高在線時刻刷新影響玩家體驗，會進行任務周期刷新時間偏移的設計，比如某每日任務采用凌晨6點刷新的邏輯等。
7. 任務激活時間，在某些系統設計中，存在所有任務統一分配，但不同任務激活（即玩家可做任務可領獎）的時間點會有區別，比如第一天解鎖、第二天解鎖、第三天解鎖等。
8. 任務邏輯關聯，在另外一些設計中，可能任務之間存在關聯邏輯，必須第一個任務完成后才能解鎖第二個任務，依次往后。
9. 任務完成條件，明確需要完成的任務，是否有特殊要求等，比如需要正常完成、排除組隊形式等，不同類型的游戲會有所區別。
10. 禮包道具信息，每個任務對應的禮包組應該如何配置。
11. 其它活動邏輯，比如支持玩家刷新任務、支持道具回收。
12. 其它系統要求，比如是否需要支持頁面banner圖片、活動ICON、道具ICON配置化等。

基于這個清單，轉化出一份開發能夠簡單、清晰、準確理解需求的文檔，是這一步的目標。項目負責人要成為最清楚項目需求的人。

技術評審：控制整體方向

技術評審的目的，一是澄清需求，二是確認技術邊界。

如果是和其它團隊合作完成研發，建議小范圍先進行第一次評審，敲定最佳的技術方案。然后再約其它團隊進行整體的評估，確認好邊界需求的處理。有一些功能邏輯，實際上放在前端或者后臺都可以，那么就盡量與大家一起協商到對于整個系統來講最簡潔的方案架構，畢竟技術實現越復雜，鏈條越長，出問題的概率也就會相應加大。

作為PM，有責任也有義務去從風險的角度規避過于復雜的技術實現方案。

對于任務中心后端的評審，主要涉及如下模塊：

圖2：任務中心評估模塊

涉及外部合作的部分，比如前端，這時候，需要對其它團隊的內容有一定的了解。清楚哪些內容是可做的、哪些存在技術障礙。在這些基礎之上的技術評審才能更加高效與準確。

時間規劃：關鍵節點

作為負責人，在項目過程中需要關注的更多是全局整體是否順利開展。需要了解項目涉及的技術模塊，但不要陷入技術細節。對于核心關鍵的模塊，交給對應模塊的開發全權負責。

PM的重點是把控好關鍵的時間點，評估這個時間點對于項目deadline是否來得及，對于該模塊開發周期是否足夠，是否會存在delay風險。如果在時間規劃的時候就存在肉眼可見的延期風險，那基本這個時間規劃就是不合格的。

另外注意預留足夠的測試時間以及buffer，畢竟測試全面才能保證質量，而要堅定的記住過程中一定會出現這樣或那樣的突發問題，占滿你項目的buffer時間。

這里建議采用VISIO畫好項目里程碑，并且周知所有干系人，大家按照約定來執行。

圖3：示例-里程碑（非真實項目計劃）

當然并不是表示定好時間到點驗收是唯一需要做的工作。過程監控和協助，也是關鍵工作。作為負責人，要有能力能夠識別和判斷當前項目是否存在風險，當前模塊是否存在風險。還是那句話，可以不關注研發細節不關心每一行代碼如何寫，但必須關心時間是否來得及。

開發期間：跟進不僅是問進度

進入開發期后，提前準備好這些前置的資源（比如美術、道具信息等），可以盡量避免因為等待配置或者UI設計等耽擱的開發時間。

雖然每個模塊開發一定是可以也必須為自己工作負責的，但作為一個負責任的項目管理者，多思考此時是否會出現容易被誤解的信息，是否有某些特殊的邏輯容易被忽視，是否有措施可以保證整體質量和進度的正常也非常必要。雙重保證，項目效果會更好。

另外一點，在這個環節，要能夠嚴格控制需求的變更。除非是原始的邏輯設計存在嚴重的問題和紕漏，會影響整個系統上線后的運營效果的話，就另當別論。不合理的不必要的需求變更通通控制住，避免因為來回變更、信息偏差導致的項目災難。畢竟換位思考一下，在開發期間改需求，是很讓研發人員煩惱的一件事情。

數據指標開發完成后，先進行開發自測，規避大多數問題，避免在轉測后耗費太多時間進行任務數據測試和溝通。

最后，聯調時候，主動推進問題解決與團隊間的配合。

轉測試：環境與用例

測試環境，針對不同的業務場景會有不一樣的點。有些業務需要跟研發版本、有些業務是新業務接入暫時還沒有完善的環境可測、有些業務是代理產品需要外部研發配合等等。你需要懂得基于不同的情境進行判斷，和開發同學一起確認好最佳的測試方案。

任務部分會提供2套環境：測試環境與正式環境。

從項目成本和效率考慮，除非測試流程強制要求搭建2套物理隔離的測試環境與正式環境，底層數據建議都采用正式環境進行測試。因為涉及任務多，數據開發需要接入數據、計算、發布部署等等，成本的確比較高，在某些情況下也不是非常有必要。那么采用任務接口無論是測試還是正式，都對接正式的數據指標的方案性價比會比較高。

這樣說會有點抽象，畫個圖示例一下：

圖4：測試方案1-完全獨立環境

圖5：測試方案2 – 底層數據復用

在某些場景下，前后端的開發進度不一致，可以先采用任務接口進行任務部分的測試，等前端開發完成后再進行頁面UI還原、圖片文案展示、點擊交互響應、兼容性等方面的測試。核心策略就是，盡量并行開發，減少等待和耦合，獨立測試，提升項目效率。

檢查上線：再多啰嗦一句

之前在寫項目管理風險的文章時，解釋過為什么數據型項目比常規的項目要復雜，因為大數據本身存在的多樣性和復雜的情況。要絕對保證外網上線項目的質量，不僅僅是團隊研發口碑的問題，還有一個因素是一旦出現問題解決修正非常困難，對于玩家口碑體驗也有影響。

因此在上線之前，務必用標準的上線Checklist檢查所有的模塊、配置、時間等信息。多確認幾遍多啰嗦幾遍很有必要。

數據效果與迭代優化

項目上線不代表結束，我們所有的項目一定有肩負著它的數據運營目標。PM雖然不直接參與數據效果分析工作，但是對于項目的數據效果一定要非常關注，這關系到項目最終的價值呈現。

因此對于一個活動或系統，細致深入的數據分析十分有必要，只有清楚地知道活動漏斗數據，才能知道哪個環節的設計是有問題的，哪個環節的用戶轉化沒有做好。在項目后面的迭代中才能進行針對性的改進優化。無論是前端資源設計、UI、交互，還是整體活動系統的邏輯規則設計，都可以通過細致的數據分析效果來發現問題和解決優化。

因此在項目過程中，務必提前做好前后端數據埋點采集，這是在項目開始時就值得做且必須做的一件事，否則到后面會發現，數據分析這件事有心但舉步維艱。

整個項目過程中，一定要十分注意關鍵信息的同步與對齊。如果有多種方式與團隊成員溝通，比如工作群、項目記錄單、郵件等，都盡量覆蓋到，該當面確認的關鍵事項當面同步溝通。

在實際做項目過程中，還會有一些具體操作細節、會接觸到一些研發和管理系統，比如項目建單規范、數據開發系統建項目管理單、資源申請單等。當然在心中有譜的情況下，這些只是具體的執行細節了，問題不大。

作者：蔡芳，騰訊KM-IEG增值服務部-技術藏經閣，公眾號：騰訊大講堂（ID：TX_DJT）

來源：https://mp.weixin.qq.com/s/XnTs7QuBq4tCgrWMurak5A

本文由 @騰訊大講堂 授權發布于人人都是產品經理，未經作者許可，禁止轉載

題圖來自Unsplash，基于CC0協議