“任務(wù)”作為大部分運(yùn)營(yíng)活動(dòng)的核心組成要素，使得任務(wù)中心類的項(xiàng)目應(yīng)用廣受歡迎。此類系統(tǒng)在實(shí)際研發(fā)過(guò)程中，涉及環(huán)節(jié)較多。對(duì)于新同學(xué)，順利的帶領(lǐng)一個(gè)此類項(xiàng)目是不小的挑戰(zhàn)。因此整理個(gè)人經(jīng)驗(yàn)成文，作為參考與借鑒。

最近會(huì)有許多新同學(xué)來(lái)咨詢關(guān)于此類系統(tǒng)合作在項(xiàng)目管理方面的經(jīng)驗(yàn)信息，因?yàn)榇祟悜?yīng)用涉及研發(fā)環(huán)節(jié)較多，又確實(shí)有許多可以總結(jié)和分享的細(xì)節(jié)信息、經(jīng)驗(yàn)，因此整理出來(lái)，希望能夠?qū)λ擞兴鶐椭?/p>

國(guó)內(nèi)游戲運(yùn)營(yíng)對(duì)于玩家的習(xí)慣培養(yǎng)已經(jīng)非常成熟了，基本一個(gè)新游戲上線，迎接玩家的會(huì)是一系列活動(dòng)：或是新手培養(yǎng)、或是簽到打卡、或是活躍度成長(zhǎng)。

無(wú)論是以拍臉形式，還是游戲內(nèi)常駐的任務(wù)中心，其中的活動(dòng)除去公告類，以及少數(shù)不強(qiáng)制引導(dǎo)用戶游戲行為的活動(dòng)，都可以看到“任務(wù)”這一元素，任務(wù)即運(yùn)營(yíng)希望玩家完成的目標(biāo)，輔以恰當(dāng)?shù)莫?jiǎng)勵(lì)，往往能很好的達(dá)到運(yùn)營(yíng)效果。

“任務(wù)”作為運(yùn)營(yíng)活動(dòng)的核心組成要素，其普遍性和標(biāo)配性毋庸置疑。

因此對(duì)于游戲運(yùn)營(yíng)，做一個(gè)長(zhǎng)線的任務(wù)系統(tǒng)或是一次性短期的任務(wù)類營(yíng)銷活動(dòng)，是一個(gè)常見(jiàn)且高頻的工作。

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

所以本文會(huì)將一個(gè)標(biāo)準(zhǔn)的任務(wù)系統(tǒng)類項(xiàng)目的開展流程、關(guān)鍵注意事項(xiàng)、以及遇到某些問(wèn)題時(shí)的應(yīng)對(duì)方案一一分享出來(lái)，給新同學(xué)一些參考。

因?yàn)槭菑捻?xiàng)目管理角度來(lái)分享，因此會(huì)以項(xiàng)目流程貫穿全文，其中每個(gè)環(huán)節(jié)會(huì)說(shuō)明需要重點(diǎn)關(guān)注的事項(xiàng)、風(fēng)險(xiǎn)點(diǎn)、以及一些做事的技巧，期間會(huì)進(jìn)行一些個(gè)人心得的探討，項(xiàng)目管理方式千千萬(wàn)，無(wú)關(guān)對(duì)錯(cuò)，歡迎一起交流分享。

Key Point：流程是核心與靈魂，它很重要，清晰的流程會(huì)幫助研發(fā)團(tuán)隊(duì)做的更好

首先我們回到項(xiàng)目管理的本質(zhì)：是在有限的時(shí)間和資源條件下，達(dá)成最終目標(biāo)的過(guò)程。作為項(xiàng)目的第一責(zé)任人，要想項(xiàng)目順利進(jìn)展，理清流程非常關(guān)鍵。有條不紊，而不是手忙腳亂。

抽象的關(guān)鍵項(xiàng)目流程如下圖：

圖1：任務(wù)中心型項(xiàng)目管理流程

可能看到這里，大家會(huì)想要說(shuō)這不就是常規(guī)的項(xiàng)目流程嗎？對(duì)，沒(méi)錯(cuò)。借用寧向東在描述管理學(xué)的一句話來(lái)解釋：“管理是介于人文與科學(xué)的一門學(xué)科”，實(shí)際上項(xiàng)目管理本身也是一門說(shuō)起來(lái)似乎很簡(jiǎn)單，但實(shí)際做起來(lái)卻需要內(nèi)功、技巧和經(jīng)驗(yàn)的學(xué)問(wèn)。

請(qǐng)接著往下看吧~

確認(rèn)合作：干系人清晰

一個(gè)項(xiàng)目能夠啟動(dòng)立項(xiàng)的前提條件是，各方參與人員對(duì)此項(xiàng)目能夠達(dá)成一致，尤其是對(duì)于跨團(tuán)隊(duì)甚至跨部門合作的項(xiàng)目。

策劃/運(yùn)營(yíng)團(tuán)隊(duì)負(fù)責(zé)整體需求設(shè)計(jì)和運(yùn)營(yíng)策略方向的把控，技術(shù)研發(fā)團(tuán)隊(duì)負(fù)責(zé)具體的實(shí)現(xiàn)，數(shù)據(jù)分析同學(xué)負(fù)責(zé)效果的分析與迭代方向建議。

作為其中的負(fù)責(zé)人，僅僅了解內(nèi)部研發(fā)系統(tǒng)的模塊分工是遠(yuǎn)遠(yuǎn)不夠，在項(xiàng)目與各方達(dá)成初步的合作意向時(shí)，就需要清晰的明確，此次前端、后端分別是哪個(gè)團(tuán)隊(duì)來(lái)負(fù)責(zé)研發(fā)，大家的分工邊界大概在哪里。設(shè)計(jì)、重構(gòu)、測(cè)試資源分別是哪個(gè)團(tuán)隊(duì)負(fù)責(zé)，甚至是禮包單誰(shuí)來(lái)配置這種細(xì)節(jié)問(wèn)題，這時(shí)也可以進(jìn)行溝通明確。

換一句話來(lái)講，在聊合作的這一步，基本可以清楚的知道，這個(gè)項(xiàng)目會(huì)涉及多少團(tuán)隊(duì)，大家的職責(zé)范圍是什么。

需求梳理：知道要做什么

對(duì)于團(tuán)隊(duì)，負(fù)責(zé)項(xiàng)目管理并不是劃分好開發(fā)人員、測(cè)試人員就萬(wàn)事大吉。

PM作為負(fù)責(zé)人，還需要進(jìn)行需求的技術(shù)化梳理。這種需求梳理不是簡(jiǎn)單的把產(chǎn)品方的需求文檔進(jìn)行轉(zhuǎn)達(dá)，因?yàn)闃I(yè)務(wù)運(yùn)營(yíng)或策劃，他們的需求文檔是從活動(dòng)角度去陳述，不完全了解數(shù)據(jù)型項(xiàng)目開發(fā)細(xì)節(jié)，當(dāng)然也無(wú)法準(zhǔn)確給出團(tuán)隊(duì)開發(fā)所需要的形式的文檔。

那我們需要從這份偏活動(dòng)說(shuō)明的文檔中，抽象轉(zhuǎn)化出團(tuán)隊(duì)需要的開發(fā)文檔，讓開發(fā)可以非常簡(jiǎn)單直接的理解他需要做什么，避免理解偏差和溝通成本。即PM要成為最了解這個(gè)系統(tǒng)活動(dòng)的邏輯和內(nèi)容細(xì)節(jié)的人，以確保在整個(gè)開發(fā)過(guò)程中，大家對(duì)于需求的理解是一致的，否則后面所有的研發(fā)工作都可能是浪費(fèi)時(shí)間與人力。

盡管各類活動(dòng)或系統(tǒng)在規(guī)則設(shè)計(jì)時(shí)有所差異，但還是有一些公共的清單內(nèi)容，可以幫助新同學(xué)進(jìn)行需求梳理：

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

基于這個(gè)清單，轉(zhuǎn)化出一份開發(fā)能夠簡(jiǎn)單、清晰、準(zhǔn)確理解需求的文檔，是這一步的目標(biāo)。項(xiàng)目負(fù)責(zé)人要成為最清楚項(xiàng)目需求的人。

技術(shù)評(píng)審：控制整體方向

技術(shù)評(píng)審的目的，一是澄清需求，二是確認(rèn)技術(shù)邊界。

如果是和其它團(tuán)隊(duì)合作完成研發(fā)，建議小范圍先進(jìn)行第一次評(píng)審，敲定最佳的技術(shù)方案。然后再約其它團(tuán)隊(duì)進(jìn)行整體的評(píng)估，確認(rèn)好邊界需求的處理。有一些功能邏輯，實(shí)際上放在前端或者后臺(tái)都可以，那么就盡量與大家一起協(xié)商到對(duì)于整個(gè)系統(tǒng)來(lái)講最簡(jiǎn)潔的方案架構(gòu)，畢竟技術(shù)實(shí)現(xiàn)越復(fù)雜，鏈條越長(zhǎng)，出問(wèn)題的概率也就會(huì)相應(yīng)加大。

作為PM，有責(zé)任也有義務(wù)去從風(fēng)險(xiǎn)的角度規(guī)避過(guò)于復(fù)雜的技術(shù)實(shí)現(xiàn)方案。

對(duì)于任務(wù)中心后端的評(píng)審，主要涉及如下模塊：

圖2：任務(wù)中心評(píng)估模塊

涉及外部合作的部分，比如前端，這時(shí)候，需要對(duì)其它團(tuán)隊(duì)的內(nèi)容有一定的了解。清楚哪些內(nèi)容是可做的、哪些存在技術(shù)障礙。在這些基礎(chǔ)之上的技術(shù)評(píng)審才能更加高效與準(zhǔn)確。

時(shí)間規(guī)劃：關(guān)鍵節(jié)點(diǎn)

作為負(fù)責(zé)人，在項(xiàng)目過(guò)程中需要關(guān)注的更多是全局整體是否順利開展。需要了解項(xiàng)目涉及的技術(shù)模塊，但不要陷入技術(shù)細(xì)節(jié)。對(duì)于核心關(guān)鍵的模塊，交給對(duì)應(yīng)模塊的開發(fā)全權(quán)負(fù)責(zé)。

PM的重點(diǎn)是把控好關(guān)鍵的時(shí)間點(diǎn)，評(píng)估這個(gè)時(shí)間點(diǎn)對(duì)于項(xiàng)目deadline是否來(lái)得及，對(duì)于該模塊開發(fā)周期是否足夠，是否會(huì)存在delay風(fēng)險(xiǎn)。如果在時(shí)間規(guī)劃的時(shí)候就存在肉眼可見(jiàn)的延期風(fēng)險(xiǎn)，那基本這個(gè)時(shí)間規(guī)劃就是不合格的。

另外注意預(yù)留足夠的測(cè)試時(shí)間以及buffer，畢竟測(cè)試全面才能保證質(zhì)量，而要堅(jiān)定的記住過(guò)程中一定會(huì)出現(xiàn)這樣或那樣的突發(fā)問(wèn)題，占滿你項(xiàng)目的buffer時(shí)間。

這里建議采用VISIO畫好項(xiàng)目里程碑，并且周知所有干系人，大家按照約定來(lái)執(zhí)行。

圖3：示例-里程碑（非真實(shí)項(xiàng)目計(jì)劃）

當(dāng)然并不是表示定好時(shí)間到點(diǎn)驗(yàn)收是唯一需要做的工作。過(guò)程監(jiān)控和協(xié)助，也是關(guān)鍵工作。作為負(fù)責(zé)人，要有能力能夠識(shí)別和判斷當(dāng)前項(xiàng)目是否存在風(fēng)險(xiǎn)，當(dāng)前模塊是否存在風(fēng)險(xiǎn)。還是那句話，可以不關(guān)注研發(fā)細(xì)節(jié)不關(guān)心每一行代碼如何寫，但必須關(guān)心時(shí)間是否來(lái)得及。

開發(fā)期間：跟進(jìn)不僅是問(wèn)進(jìn)度

進(jìn)入開發(fā)期后，提前準(zhǔn)備好這些前置的資源（比如美術(shù)、道具信息等），可以盡量避免因?yàn)榈却渲没蛘遀I設(shè)計(jì)等耽擱的開發(fā)時(shí)間。

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

另外一點(diǎn)，在這個(gè)環(huán)節(jié)，要能夠嚴(yán)格控制需求的變更。除非是原始的邏輯設(shè)計(jì)存在嚴(yán)重的問(wèn)題和紕漏，會(huì)影響整個(gè)系統(tǒng)上線后的運(yùn)營(yíng)效果的話，就另當(dāng)別論。不合理的不必要的需求變更通通控制住，避免因?yàn)閬?lái)回變更、信息偏差導(dǎo)致的項(xiàng)目災(zāi)難。畢竟換位思考一下，在開發(fā)期間改需求，是很讓研發(fā)人員煩惱的一件事情。

數(shù)據(jù)指標(biāo)開發(fā)完成后，先進(jìn)行開發(fā)自測(cè)，規(guī)避大多數(shù)問(wèn)題，避免在轉(zhuǎn)測(cè)后耗費(fèi)太多時(shí)間進(jìn)行任務(wù)數(shù)據(jù)測(cè)試和溝通。

最后，聯(lián)調(diào)時(shí)候，主動(dòng)推進(jìn)問(wèn)題解決與團(tuán)隊(duì)間的配合。

轉(zhuǎn)測(cè)試：環(huán)境與用例

測(cè)試環(huán)境，針對(duì)不同的業(yè)務(wù)場(chǎng)景會(huì)有不一樣的點(diǎn)。有些業(yè)務(wù)需要跟研發(fā)版本、有些業(yè)務(wù)是新業(yè)務(wù)接入暫時(shí)還沒(méi)有完善的環(huán)境可測(cè)、有些業(yè)務(wù)是代理產(chǎn)品需要外部研發(fā)配合等等。你需要懂得基于不同的情境進(jìn)行判斷，和開發(fā)同學(xué)一起確認(rèn)好最佳的測(cè)試方案。

任務(wù)部分會(huì)提供2套環(huán)境：測(cè)試環(huán)境與正式環(huán)境。

從項(xiàng)目成本和效率考慮，除非測(cè)試流程強(qiáng)制要求搭建2套物理隔離的測(cè)試環(huán)境與正式環(huán)境，底層數(shù)據(jù)建議都采用正式環(huán)境進(jìn)行測(cè)試。因?yàn)樯婕叭蝿?wù)多，數(shù)據(jù)開發(fā)需要接入數(shù)據(jù)、計(jì)算、發(fā)布部署等等，成本的確比較高，在某些情況下也不是非常有必要。那么采用任務(wù)接口無(wú)論是測(cè)試還是正式，都對(duì)接正式的數(shù)據(jù)指標(biāo)的方案性價(jià)比會(huì)比較高。

這樣說(shuō)會(huì)有點(diǎn)抽象，畫個(gè)圖示例一下：

圖4：測(cè)試方案1-完全獨(dú)立環(huán)境

圖5：測(cè)試方案2 – 底層數(shù)據(jù)復(fù)用

在某些場(chǎng)景下，前后端的開發(fā)進(jìn)度不一致，可以先采用任務(wù)接口進(jìn)行任務(wù)部分的測(cè)試，等前端開發(fā)完成后再進(jìn)行頁(yè)面UI還原、圖片文案展示、點(diǎn)擊交互響應(yīng)、兼容性等方面的測(cè)試。核心策略就是，盡量并行開發(fā)，減少等待和耦合，獨(dú)立測(cè)試，提升項(xiàng)目效率。

檢查上線：再多啰嗦一句

之前在寫項(xiàng)目管理風(fēng)險(xiǎn)的文章時(shí)，解釋過(guò)為什么數(shù)據(jù)型項(xiàng)目比常規(guī)的項(xiàng)目要復(fù)雜，因?yàn)榇髷?shù)據(jù)本身存在的多樣性和復(fù)雜的情況。要絕對(duì)保證外網(wǎng)上線項(xiàng)目的質(zhì)量，不僅僅是團(tuán)隊(duì)研發(fā)口碑的問(wèn)題，還有一個(gè)因素是一旦出現(xiàn)問(wèn)題解決修正非常困難，對(duì)于玩家口碑體驗(yàn)也有影響。

因此在上線之前，務(wù)必用標(biāo)準(zhǔn)的上線Checklist檢查所有的模塊、配置、時(shí)間等信息。多確認(rèn)幾遍多啰嗦幾遍很有必要。

數(shù)據(jù)效果與迭代優(yōu)化

項(xiàng)目上線不代表結(jié)束，我們所有的項(xiàng)目一定有肩負(fù)著它的數(shù)據(jù)運(yùn)營(yíng)目標(biāo)。PM雖然不直接參與數(shù)據(jù)效果分析工作，但是對(duì)于項(xiàng)目的數(shù)據(jù)效果一定要非常關(guān)注，這關(guān)系到項(xiàng)目最終的價(jià)值呈現(xiàn)。

因此對(duì)于一個(gè)活動(dòng)或系統(tǒng)，細(xì)致深入的數(shù)據(jù)分析十分有必要，只有清楚地知道活動(dòng)漏斗數(shù)據(jù)，才能知道哪個(gè)環(huán)節(jié)的設(shè)計(jì)是有問(wèn)題的，哪個(gè)環(huán)節(jié)的用戶轉(zhuǎn)化沒(méi)有做好。在項(xiàng)目后面的迭代中才能進(jìn)行針對(duì)性的改進(jìn)優(yōu)化。無(wú)論是前端資源設(shè)計(jì)、UI、交互，還是整體活動(dòng)系統(tǒng)的邏輯規(guī)則設(shè)計(jì)，都可以通過(guò)細(xì)致的數(shù)據(jù)分析效果來(lái)發(fā)現(xiàn)問(wèn)題和解決優(yōu)化。

因此在項(xiàng)目過(guò)程中，務(wù)必提前做好前后端數(shù)據(jù)埋點(diǎn)采集，這是在項(xiàng)目開始時(shí)就值得做且必須做的一件事，否則到后面會(huì)發(fā)現(xiàn)，數(shù)據(jù)分析這件事有心但舉步維艱。

整個(gè)項(xiàng)目過(guò)程中，一定要十分注意關(guān)鍵信息的同步與對(duì)齊。如果有多種方式與團(tuán)隊(duì)成員溝通，比如工作群、項(xiàng)目記錄單、郵件等，都盡量覆蓋到，該當(dāng)面確認(rèn)的關(guān)鍵事項(xiàng)當(dāng)面同步溝通。

在實(shí)際做項(xiàng)目過(guò)程中，還會(huì)有一些具體操作細(xì)節(jié)、會(huì)接觸到一些研發(fā)和管理系統(tǒng)，比如項(xiàng)目建單規(guī)范、數(shù)據(jù)開發(fā)系統(tǒng)建項(xiàng)目管理單、資源申請(qǐng)單等。當(dāng)然在心中有譜的情況下，這些只是具體的執(zhí)行細(xì)節(jié)了，問(wèn)題不大。

作者：蔡芳，騰訊KM-IEG增值服務(wù)部-技術(shù)藏經(jīng)閣，公眾號(hào)：騰訊大講堂（ID：TX_DJT）

來(lái)源：https://mp.weixin.qq.com/s/XnTs7QuBq4tCgrWMurak5A

本文由 @騰訊大講堂 授權(quán)發(fā)布于人人都是產(chǎn)品經(jīng)理，未經(jīng)作者許可，禁止轉(zhuǎn)載

題圖來(lái)自Unsplash，基于CC0協(xié)議