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