“任务”作为大部分运营活动的核心组成要素，使得任务中心类的项目应用广受欢迎。此类系统在实际研发过程中，涉及环节较多。对于新同学，顺利的带领一个此类项目是不小的挑战。因此整理个人经验成文，作为参考与借鉴。

最近会有许多新同学来咨询关于此类系统合作在项目管理方面的经验信息，因为此类应用涉及研发环节较多，又确实有许多可以总结和分享的细节信息、经验，因此整理出来，希望能够对他人有所帮助。

国内游戏运营对于玩家的习惯培养已经非常成熟了，基本一个新游戏上线，迎接玩家的会是一系列活动：或是新手培养、或是签到打卡、或是活跃度成长。

无论是以拍脸形式，还是游戏内常驻的任务中心，其中的活动除去公告类，以及少数不强制引导用户游戏行为的活动，都可以看到“任务”这一元素，任务即运营希望玩家完成的目标，辅以恰当的奖励，往往能很好的达到运营效果。

“任务”作为运营活动的核心组成要素，其普遍性和标配性毋庸置疑。

因此对于游戏运营，做一个长线的任务系统或是一次性短期的任务类营销活动，是一个常见且高频的工作。

那么基于这样的需求背景，能够一体化的解决此类系统开发的技术方案必定大受欢迎。

所以本文会将一个标准的任务系统类项目的开展流程、关键注意事项、以及遇到某些问题时的应对方案一一分享出来，给新同学一些参考。

因为是从项目管理角度来分享，因此会以项目流程贯穿全文，其中每个环节会说明需要重点关注的事项、风险点、以及一些做事的技巧，期间会进行一些个人心得的探讨，项目管理方式千千万，无关对错，欢迎一起交流分享。

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协议