====== 目的 ====== 一个产品是由**团队**打造，在我们眼前的通常是一个团队打造一个产品的花费了一段时间的结果，我们如何确保这个30%左右的产品，在未来能达到期望中80%以上的效果？那就是**评估团队**。 在商业合作中，我们避免不了与其他团队合作，所以学会合作之前**评估其他团队**，就能降低一些风险。简单来说，合作方给了我们O，而我们要通过合作方表现出的内容，评估出它是否最终基于我们F，而不是F-。 同样的，这样的模型有理论，也有经验，每一个团队的特质都不一样，所以拉出来的维度也必然不同，这与之前的快速评测很像，只能理会，无法照搬。 同时，读者也一定要理会到，接下来分享给大家的，是不靠谱的，甚至有大错误观念的，仅仅是分享而已，一定要自己结合实际情况思考我所说的内容。 ====== 观点 ====== ===== 观点1：能力与态度 ===== 与其他团队合作，最大的宏观方面，我们会分为2层：1层是**能力**，另1层是**态度**。 - **能力**：对版本更新的速度是最重要的。 - **态度**：对我们理论的接受和认可，达成一致性是最重要的。 因为我们有自己的理论（也就是本书的内容），当我们通过自己的观点与别人沟通时，就需要考虑到别人是否接受我们的言语。是觉得我们“假大空”，还是真的觉得我们“有道理”。 比如一个视觉系优先的制作人，就很有可能觉得游戏做机制期的内容是不重要的。 当我们多次沟通后还是不上心，那我们就觉得他沉浸在自己的思考维度中难以自拔。 事实上，通过对认知模型的学习，我们可以理解到，任何一个人，包括你我，都是固执的，基于**“人是有限理性人”**的假设，我们一生都在追求最优解，能成为创业者的，都有自己非常坚定的理念，自然的，也就难以说服。 与其说，我们在说服别人，不如说我们在寻找契合的人。 从经验讲，**理工科**出生的制作人，就比较容易接受我们的这一套思维方式。 同时，在实际的工作中，也会有这样的情况发生。一个**制作人**有一款产品，产品表现得并不是非常抢手，所以制作人继续把产品代理出去，拿到钱，以维持团队，此时制作人面对发行时，就有可能变得**“什么都答应”**。 当发生这种情况，我们也会归类为：**“态度有问题”**，需要研究下对方答应的，承诺的，是否是自发的，内心所想的，还是只是缓兵之计。这里我所说的，是人之常情，并没有特指谁，也没有把这个问题归类为品德问题，读者要分辨清楚，在商业合作中，大家都有自己的难处，许多情况都会发生，我们只能假设好各种坏事情都会发生的可能，然后再通过检查点去排除，才能在诸多的合作中，尽量的确保自己活下去，不被坑。 ===== 观点2：论持久战 ===== 对于大发行公司来说，可能千金一掷，直接包养一个研发团队研发三年不是问题，就当投资，但对于作者所在的发行部来说，还达不到这样的级别，就需要考虑合作方自己能生存多久。 多杰也相信，各行各业，但凡涉及到两个团队合作，都要考虑这个问题。 要是合作到一半，对方突然跟你说倒闭了，没法继续了，你就会陷入非常尴尬的境界当中。 一个团队，能活下去，取决于**成本、收入与存粮**。 通常我们会询问对方的月支出，收入来源，以及账户上的资金，当然，有的愿意说，有的不愿意说，作为善于算账的中国人，去饭点吃饭都要算算人家收入的，我们肯定也会自己算一算，看看办公室多少人，程序员多少人，策划多少人，美术多少人，财务等其他岗位多少人，所处于什么城市，基本也能算个大概。 同样的，算开支，还能算出一个制作人是否是精打细算之人。不会花钱的制作人会把钱浪费到更多对产品无益的地方，如果在一个收益文件的团队这没有问题，但对于一个创业团队来说，这就是致命的问题。 ===== 观点3：多少条生产线 ===== 一个客户端程序、一个服务端程序，基于我的经验我会看作一个生产线，因为组合起来能在一段时间内负责一个完整的系统。而策划与美术则是共用岗位。 小一点的团队，往往2、3个客户端程序与1个服务端程序，这在我心中就代表着1.5的战斗力，大概能全力开发1个系统，并改善现有的体验，同时修复bug。 因为经常与独立游戏团队接触，所以往往会面临的问题，就是团队过于精简，无法支撑上线后的并发工作状态，导致版本更新过慢，1个月左右玩家大量流失。 就像上面所说，在项目上线后，我们需要： - 有人开发新版本 - 有人调整老功能 - 有人改BUG 其中，2、3可以同一组来兼顾，所以团队中至少得有2组开发，也就是**2条生产线**，我认为才能在应对上线时的情况。 那么，评估团队是否有足够的**开发能力**面对上线时的情况，就非常重要。当然，**单机游戏**就没有那么多问题。 ===== 观点4：核心乐趣能力 ===== 这一条其实体现在快速评测中，复选评测时会再次观察，最终结果会写到团队评测里做个总结，道理也说过，如果一个团队没有能力让游戏具备核心乐趣，那么我们也很难与他们一起完成这个艰难的任务。 所以理论上也是评估团队的一个点，这里就不过多描述。 ===== 观点5：体验细节 ===== 如果一个团队注重一些交互体验，我们认为是加分项。 通常检查的项目为： - 是否玩家每一次输入都有视觉、听觉反馈 - 玩家经常需要用的页面是否三步以内抵达 一些交互细节虽然不是必要的，但通常可以给玩家带来更好的体验，就算检查时没有，在开发过程中也会逐步完善。 ===== 观点6：磨合时间 ===== 一个团队，在一起磨合的时间非常重要。一批人在一起时间越久，战斗力就越强。如果一个团队像俄底修斯之船一样短期内总在换人，那战斗力就很难发挥出来。所以我们会打探一个团队的人员稳定情况，了解目前核心成员在一起磨合的时间，如果是那种原本就是同事一起出来创业的，那就再好不过了。 ====== 综上 ====== 当然，这只是运营层面的评估，在法务部门，商务部门都有各自的评估模型，这里多杰也不太了解，所以只能给出我们给予合作能力方面的评估。 不要小看这种评估，在曾经，多杰听老板说过公司真实案例，就包含了合同签约第二天，拿了代理费就失踪的团队，所以每多做一次评估，都是为公司消灭潜在的风险，是不得不做的。 ---- > //下一章：[[.:小结]]//