|
|
文/顾煜
通过创意的收集和筛选的项目，进入正常的项目研发流程。
这篇聊聊在帮助产品落地的过程中，我们又做了什么。
节点
对于验证了想法的项目，我们愿意投入更多资源，它们可以进入一个称之为预立项的节点。在这个节点上，团队可以得到补充，项目可以得到研发预算，进行外包工作。
预立项，代表着管理团队的承诺，我们愿意投入真金白银，帮助把这个好的创意，做成上线项目。
预立项，也意味着项目组的承诺，他们责任更大了，许下的愿，吹过的牛，埋过的坑，要开始一一兑现。
进入预立项的项目，我们会大致保持每月Review一次的节奏。项目组依然需要时时刻刻理清思路，面临评委的挑战，此为外患；项目组也需要对齐目标，面对内部成员的质疑，此为内忧。内忧外患，从来就是逼人奋进的理由。
虽然管理团队承诺了要和这个项目白头偕老，但承诺从来都是不靠谱的。项目组也不能高枕无忧，长时间不能进展的项目，依然会被无情抛弃，回退到创意孵化阶段。这是一个温情和绝情并存的组织，我们对人宽容（暂时的），对事严格（一贯的）。
历史上，有过3-4个项目被从预立项阶段退回孵化状态，有些团队从败者组杀回，站上人生巅峰，有些就此沉沦，令人唏嘘。
在预立项后，目标有了变化。预立项的团队，需要尽力做出一个垂直切片版本（vertical slice），这个垂直切片版本，规模可以很小，但在品质上要代表最终项目，在流程上已经走通难点，在思路上已经确立了设计Pillar。完成了这一切，他们就可以申请立项了。
照例又是另一次评审，类似的流程，类似的决策，通过的项目，就能得到正式的立项。我们对正式产品，会给予三位数的编号。比如NEXT 001《死神来了》，NEXT 002《彩虹坠入》。
从孵化阶段到预立项阶段，到最终的立项阶段，资源投入依次递增，在内部分配资源的优先级也越来越高，但这些项目也有代价需要付出，他们的灵活度越来越低，承诺越来越多，压力越来越大。
资源
在孵化产品阶段，由于大家都是自下而上进行孵化，人力得不到保障。而进入新的阶段，我们就需要做更多的调配，给予尽可能多的资源，确保项目能按时完成。
说是尽可能多的资源，实际还是比较有限的，每个项目一般也就10多个人上下，最多的时候也就是20左右。不比其他商业化项目的博爆款，我们本就是细水长流，需要在一个更长的周期，维持产能和输出。
调动资源是很困难的工作，因为每个人，手头必然有事情在做。我们要做的，就是根据工作的优先级，去拆东墙，补西墙。拆迁的过程中，不免要和被拆的项目PK，要打破各种利益从属关系。
早期还好，即使无法调配人员，至少还有一些招聘编制，搞不定，招聘一个，可以通过引入人员增量来解决问题。
而随着招聘名额用完，竞争就开始白热化了，大家忽然都意识到，不会再有外来资源了，人员利用上，进入了零和博弈时代。
只是这工作再艰难，也要做。
无论什么样的组织，资源总是有限的，不可能满足每个项目。作为被薅羊毛的弱势项目侧，自然满心怨恨，谁敢动我奶酪，我就杀谁全家；而对于求资源不得的强势项目侧，也是满怀牢骚，你不给我资源，我不确保进度。
信息不够透明，进一步又引起了更多的内部矛盾。风声鹤唳，是谁在传谣言？疑神疑鬼，是谁在坏规矩？猜疑链将我们紧紧捆绑在一起，相爱相杀。
我们制定了多种多样的制度，来确保资源调配。我们成立了相对中立的行会制度，对同类工种的人，进行横向管理，方便调动。也定义了各种项目优先级，让弱势项目提前有心理准备，好接受不公平的命运。对于实在难以调配的资源，则通过合理的外包、顾问等形式，予以缓解。
然丘壑总难填，人心是永不能满足的深渊。总是有不能被满足的项目，他们的所有困难都成立，所有方向都靠谱，于情于理，就是应该给予支持，只是，地主家也没余粮了…
所有现实层面无法解决的问题，就需要上升到哲学层面。对于那些得不到资源而痛不欲生的项目，黎叔给出了终极解决方案：现在没资源，你们耐心点，小团队慢慢做，可以做更久。这个策略方针，和天美常说的变通的执行力，异曲同工。如果想要什么资源，就能得到什么资源，我们为什么还需要你的聪明才智呢？
Master review
上述的产品开发的流程，已经经历了很多的微调整，我们也会经常发现新的问题，需要实时调整。
NEXT的产品，强调长板，也逐渐遇到了问题，很多产品，都是有不错的卖点，但短板也很明显，整个研发流程中，如何进行品质的把控，成为一个问题。
管理团队希望给开发团队足够的自由度，完成自我表达。我们不想深度干预项目日常开发。然而，宽容不等于纵容，对于明显有问题的项目，还是要有些方式，来提出意见，提升项目品质。
日常的Review提供了一个不错的反馈渠道，但是这远远不够。
我们发现有些产品在难度设置上不合理，有些产品整合后品质不够，有些产品有口碑风险，这些问题，都有一个共性，就是只在产品开发的后期才会出现，早期的版本，因为完成度的问题，并不会暴露问题。
现代游戏开发，过于流水线化，每个工序都切分细致，美术专心画画，程序专心写功能和整合，策划专心设计玩法和系统，测试寻找功能Bug。可是这个开发流程里面，并没有玩家。很多时候，用普通玩家的视角，进行游戏测试，会发现大量问题，而这些问题，在基本的开发过程中，没有人留意。
于是我们引入了各个节点的专家评测，更早、更全面反馈游戏中的问题。我们也引入了Master review，在游戏上线前，集中召集相关人，用玩家的视角，来体验游戏，看游戏的节奏，看游戏的问题，给予开发者深度的反馈。此时版本完成度较高，也更容易发现体验的问题。
轻量
随着研发进行，也逐渐有了需要运营维护的产品。产品的生命周期，有了更复杂多变的表现。我们要加入更多的环节。
只是工作时间总是有限的，更重的流程，也许为管理打开了一个新的视角，但也消耗了更多的资源。我们也在尝试调整流程，加上一些新的环节，减掉一些冗余的过程。没有完美的流程，其中的平衡，需要小心翼翼的试探。
行文至此，我点到为止提了一下研发流程。这个流程看似极其不靠谱，大家不免有很多疑问，这样也行？这样也能做成事情？
的确，你们不是唯一怀疑的人。
哪有什么一帆风顺，我们只是在逆境中忍住不哭。挫折，在黑暗中伺机而动。
待续
专栏地址：https://zhuanlan.zhihu.com/gu-yu
|
|
发表于 2018-12-20 14:51:38
