【项目管理】项目管理之中可能遇到的一些坑爹情况

GShion

写这玩意是为了避免踩坑！！！都是真事教训！！！

立项前预估工作内容问题
- 策划应当提前做好各系统的大略内容说明，也就是玩什么，怎么玩，能玩多少的问题。
- 策划应当提前做好所有UI板子的图量表，用于预估大致的内容，一般认为程序在有详细策划案的情况下可以1天做1个通用业务的板子。
- 程序根据UI板子以及此前经验预估各部分或者全部的工作量。复杂的地方（如英雄、装备之类的）可以多估一点。预估完成后，增加至少20%的时间用作风险余量。
- 注意策划按板子排工作量的话天生就排不准确，因为策划不清楚程序是如何通过板子与具体内容估算工作量的。粗略估算还是得程序自己看UI图量表，精确估算则需要策划出好详细策划案。
- 如果预估错误，可以通过具体工作时长与内容看一下多出了多少工作量。
- 是否做本地化，如何进行机型适配，高中低配如何处理。
预演可用性测试问题
- 游戏上什么途径，引擎支不支持，有没有问题，对应途径有没有常见的坑，先测测试试。
- 搞一个预测的假内容，但是大小什么的都是目前可预期的大小，不然可能包出不来就要换引擎、换版本。
- 查看一下对应论坛引擎可能存在什么打包出包的坑。
- 查一下上对应平台可能存在什么打包出包的坑。
中台内容工作量估算问题
- 中台与通用内容很容易就会在立项的时候漏掉
- 基本的游戏GM功能、前后台功能、网络功能、图集与性能等
- 包括前端中台与后端中台，这个得单独出文档
立项后定每周工作内容/月度里程碑节点的问题
- 每周工作除了工作量合理以外，工作分配应当平均到人，不能出现本周只有一个大活且只能一个人负责，闲的闲死忙的忙死的情况。
- 前期月度节点可以依据情况定，重要的是后几个面向玩家的节点：首日节点（1日内容/3日体验，内部测试用)、三日节点（3日内容/7日体验，面向玩家，技术测试用）、七日节点（7日内容/14日体验，面向玩家，买量测试用）、14日节点（14日内容/30日体验，面向玩家，大推用）。
- 应当保持每月1个小版本（新角色、小活动、小养成线），每季1个大版本（大活动，新功能，大养成线）的开发预估。
各部门工作进度问题
- 策划的策划案应当领先程序工作进度两周及以上。
- 策划的图量表/美术需求案应当领先美术工作进度一周及以上。
- 美术的产出资源应当领先程序工作进度一周及以上。
- 程序应当预估的时候就将修Bug的时间估算进去，并且在本周的节点时给出没有Bug的内容。不能说时间到了还要求额外时间修Bug。
- 程序应当在时间节点给出策划验收通过的内容的原因，是因为正常情况下这部分内容会直接面向玩家，直接对玩家与营收数据负责，不能分派额外时间修Bug这一点是由玩家说了算，策划、程序说的都不算。
- 程序估时往长了估计，多退少不补。不过除非能够证明确实有这个需求，否则额外的估时时长应当在预计开发时长的20%以内（4天开发，0.8天修Bug，正好大概一周）。
- 另外，开发完成=>验收=>给反馈，修Bug存在时差，注意考虑到这一点。
产出内容格式与管理问题
- 无论是策划案、美术资源、UI、特效、字体、音效、模型、图片与图集，都需要内容格式与限定框架。
- 所有游戏资产都应当有固定的资源命名、存放、管理方式与管理负责人。
- 目的是除了保证游戏整体的统一性以外，还会方便资源管理、开发以及性能优化。
- 所有游戏资产管理，策划必须要参与，避免程序问策划资产在哪、策划问美术资产在哪、美术问策划当时这一批需求给过来的时候策划知不知道里面都有什么的情况。
资产帮助（老版美术资源，代码资源，策划案）问题
- 重要的话说三遍：即使有了资产帮助，开发逻辑也仍然是重新开发逻辑！即使有了资产帮助，开发逻辑也仍然是重新开发逻辑！即使有了资产帮助，开发逻辑也仍然是重新开发逻辑！
- 如果有美术资源，那么考虑是否能复用以及复用率，以及是否需要修复图片大小，分辨率等。
- 如果有代码资源，优先转代码而不是看代码。
- 如果有策划案资源，优先通读并对比现在的竞品，优化设计不合理的地方。
- 最后，不要过于依赖帮助，帮助只能在有限的情况下增加开发进度，但源头仍然是策划案。策划也不要被资产帮助限制死了，先出了策划案再决定让程序看代码，如果看代码耗费时间过长，那么直接按策划案上的做，而不是让程序看代码还原一个东西，策划再从这个东西里面挑刺，找不合理的地方。
- 在没有资产帮助的情况下，美术需要图量表、程序需要策划案、策划需要研究竞品。资产帮助只是将这些需求的强度弱化了，但不是消除了需求。
- 无论外部帮助程度如何，策划对一个东西应该是完全清楚的，如果不清楚，就要拍板，先拍了再说，遇到区别再决定听谁的（策划新想的还是外部帮助的）。
- 总而言之，策划案和相应文档不能少，不要产生帮助能让策划少写策划案的幻想，程序在没有策划案的情况下可以直接拒绝做事（但在有代码帮助的情况下，最初的策划案可能没办法太详细，更近于表现策划案，一些关键设计可能还是要程序看代码）。
通用内容问题
- 策划应当就常见通用内容出策划案。常见通用内容包括引导、红点、音效、通用奖励界面、连续弹窗口显示规则、跳转途径、帮助、任务、扫荡结算等。
- 以及各种高中低配的设计，和这些设计分别代表了什么意思（如使用不同精度的美术资源，还是削除了一些美术资源表现之类的）。
- 不要多次开发通用内容，策划在写案子的时候应当考虑涉及到的某一部分是否可以在不同的位置通用（或稍微改一下就可以通用），然后把通用的部分独立成另一个策划案。
- 通用内容也应当策划和程序共同维护，程序看策划案的时候觉得某部分可能是通用功能，那就叫相应策划看一下，如果通用就重新写，单独排期做。
工作流程问题
- 合理的工作流程，应当各方各面都考虑到，而且方便团队开发。
项目跟进问题
- 应当有一个负责统筹所有进度（实际进度与预期表现，要有明确具体可执行的验收标准）的人员。该人员负责统筹项目进度与各方面需求，建立问题列表。
- 使用CheckList单跟进项目。如果跟进项目没有好好跟，那么需要就跟进人员问责。
- 使用跟进与验收标准来倒逼执行，不符合跟进验收标准的就得重做。
- 建立问题列表与负责人，有事必跟，每周周会会的时候都看一下。
项目验收问题
- 验收标准如果不明确，可执行程度不高，那么必然导致拖延，因为内容产出端都不知道自己要做成什么样子。很多时候可以从验收标准文档反推出开发时各个地方要做到什么地步。
- 可以使用CK单验收。对应里程碑的CK单务求全面，验收里程碑时记下所有问题（以及吐槽！）。之后讨论月版本问题所在、修改方案与工期。
- 表现与性能上的真机标准，什么是真机标准，上线标准，什么是上线标准，这些都要明确，或者至少能被大致感知，如约0.5秒，约1秒等。
- 要确定标准机型，高中低配置机型至少确定一个，并且使用真机做测试。

前瞻性与什么是前瞻性
- 定义：避免踩坑，按时推进，赚更多钱
- 从0开始的前瞻，注意要看到坑。骨架是核心，但这些东西容易“习以为常”忽略，只关注业务，其实是第一优先级。这些内容全部要提前趟一下或者提前做，避免不上不下的时候发现问题
  - 容易踩的坑
    - 游戏上什么途径，引擎支不支持，有没有问题，先测测试试
    - 搞一个预测的假内容，但是大小什么的都是目前可预期的大小，比如小程序出包问题，差点搞得要换引擎版本
    - 查看一下对应论坛引擎可能存在什么打包出包的坑
  - 为了避免踩坑的规章制度
    - 类似于不准改数据库数据之类的
  - 除了通用业务之外的所有骨架内容
    - 前台
      - SDK接入
      - 资源管理，资源压缩，资源规格标准
      - 版本管理，SVN/Git，主干分支
      - 热更，强更
      - 打包、本地包、线上包
    - 后台
      - 服务器列表，服务器列表显示规则，服务器状态，自动修改服务器状态等
      - 服务器稳定性，连接稳定性，连接容量
      - 弱网环境、断线重连
      - 数据验证
      - 账号相关操作（换号、顶号、封号）
      - 报错日志，线上报错日志
    - 数据运营
      - 管理后台
      - 埋点、各类统计数据（需要细化）
      - 各类玩家统计数据（和上面差不多）
      - 邮件、补偿、cdk、公告
      - 查找可疑行为（广告哥）
      - 修改各类属性（后台GM改号行为）
      - 其他的操作功能（需要细化）
    - 业务量
      - 全部的UI图量表
      - 全部的特效图量表
      - 全部的通用音效要求
      - 全部的系统内容详情
      - 通用内容尝试单独拿出
        
        红点
        
        奖励
        
        帮助
        
        音效音乐
        
        缺资源跳转途径
      - 按板子进行不精确的时间预估，然后乘以1.2
      - 如果以上内容不能全部，至少75%以上
  - 核心业务
    - 核心业务能不能做，怎么做，是否有参考的踩坑记录
    - 核心业务做多大，就是战斗中几个角色，多少buff之类的，性能消耗范围
    - 核心业务的框架设计文档，即使有参考，也要重设计并且出设计文档
    - 优先保证核心业务而非通用业务
- 从0.5开始的前瞻，核心是项目管理进度推进，套话来说就是“有法可依，有法必依，执法必严，违法必究”。说得比较重但是核心就是这个。既然推进进度，那0进度和100进度都是什么得要有，里程碑是什么，需要什么前提条件得要有，给出的内容以及验收的标准都要有。最重要的是“可执行性”，不能说出现“这个东西重要，xx时间要，但是没有具体执行文档”的情况
  - 各个里程碑，以及大概的概念定义（几句话简述做到什么程度）
  - 对应的验收ck单，可以和测试一起确定，务求详细（拿着这个去验收，对应程序也要看看）
  - 重复工作量尽量减少：通用内容的开发，通用工作流（比如策划模板这种东西）
  - 项目整体的把控：什么有，什么没有，什么缺，什么要补，大概多久完成
  - 项目中出现的问题记录，解决，跟进。由策划牵头，各主管都要负责
  - 项目与竞品的体验差异记录
- 从1开始的前瞻
  - 真机要求（需要细化）
  - 市场，商业化
  - 现在的体验情况，竞品的体验情况
  - 头部产品的商业化策略
另外，现在发现关注最底层逻辑走过来可以让基础打得很坚实，实际上外部帮助都不能帮助基础，有点像空中楼阁，看起来很好，但只用这些是做不了的
只有在基础坚实的情况下才能用好帮助
1. 经验：说白了就是坑踩过去的总结经验多不多
2. 开发能力：人员做不做得出来
3. 商业构成：怎么赚钱，可行性如何
4. 开发流程：从0到1怎么开发
5. 资源管理：资源生产流水线，包括全部部门，会不会卡住或者流动不畅
6. 前后台通用功能：一些“只要是游戏”就必须有的东西，非策划向的内容，而是类似于顶号，后台，埋点之类的，容易忽略但是是骨架的东西
7. 可用性：什么叫做可用，在什么平台上的什么要求，玩家会有什么要求