人与人的差距远大于人与猪

很多团队成员打死也想不到，这个游戏最大的玩家群体居然是三四线城市的宅男宅女和家庭主妇，此前大家一直坚信是一二线城市的高校学生。

问题3：大家都觉得是很好的东东，为什么玩家就是不喜欢？

原因：缺乏科学有效的用户调研，仅从自己的感觉喜好出发设计开发产品，以己度人，但玩家其实和你很不一样，“人与人的差距要远大于人与猪”，你难道不明白？

方案：找到目标玩家，观察他，感受他，理解他，拥抱他，爱上他。

《摩登城市》很多团队成员打死也想不到，这个游戏最大的玩家群体居然是三四线城市的宅男宅女和家庭主妇，此前大家一直坚信是一二线城市的高校学生。在一次详尽的用户调研结束后，王峰说：“之前的失败是必然的！”随后，他们请了一些有代表性的玩家到公司与开发人员沟通交流，让玩家玩给员工看，并做详细的观察记录，对他们的隐性需求做深入挖掘与分析。领导力大师约翰·科特指出，相对于“分析—思考—改变”的模式，“目睹—感受—改变”更容易让人发生变化。一个典型案例是，在《摩登城市》的产品设计中，有一个交互设计是通过一个动态的箭头提示玩家点击箭头指示方向的“我的好友”信息框，但大家通过观察发现，大量玩家都是直接点击箭头。

批注

相对于“分析—思考—改变”的模式，“目睹—感受—改变”更容易让人发生变化。要让团队发生改变有两种方式：一是领导者率先垂范，强势推动团队变革；二是让用户告诉团队成员什么是真实的用户需求，倒逼他们做出改变。一个是强势推动，一个是无情倒逼，两者结合，效果最佳。

怎么会这样？

“框框太小，箭头太大了！”

“箭头是动态的，而框框的静态的，我点击箭头有错吗？”

“我常常在这里浪费时间，这绝对是一个脑残的设计！”

……

“真的没想到！”一个团队成员说。当然团队马上做了改进调整，将箭头做小并相对静态，而框框则亮堂、动态且更加显眼。“这样的案例太多了，我们对游戏中的语言也做了全面的调整，尽可能地让玩家感受到温情和感动！”王峰说，“原来很多拒绝改变的团队成员很快发现自己在玩家面前是多么愚蠢，不仅迅速调整自己，还成为改变的推动者。”

由于互联网产品要持续采集用户数据才知道如何优化产品，因此必须清晰地告知开发人员要采集哪些玩家数据及其原因。此前导致大量返工的一个重要原因是文档的需求描述不清晰，于是王峰对策划人员要求以更简洁清晰的方式描述需求，按“目标—策略—验证标准—用户故事—界面草图—流程图—采集数据”的模板描述需求，在形式上结合“文字描述+流程描述+界面图描述”。用科学的数据说话，不断改善产品，做出详细的分析报告，在此基础上进行功能改进。比如，设计更接近三四线城市玩家的界面风格，着色更加大胆鲜艳（大红大绿），城市建筑也集合了美甲店、拉面馆等，加上“收税”玩法，以及“炫耀”功能等，持续强化中国元素，增强玩家的代入感，流失率大大降低。

批注

完全从中国社会文化背景出发的产品设计，对中国玩家的代入感极强。

敏捷开发的精髓

在产品开发的过程中是否常常遇到以下苦恼：产品劣质；功能无法测试；可用性和用户体验差；不能按时交互；开发费过高；团队成员不交流，或交流效果差，不喜欢合作；太多新人，严重缺乏经验和技能；写不完、没人看的文档；技术支持差，无法预测投资回报；没有专注商业价值；没有关注用户满意度；需求管理死板；冗余文档；难以维护和技术支持。敏捷开发正是为解决以上问题而生。

敏捷是基于Scrum、极限编程和精益理论的最佳软件工程实践的集合。这些实践包括：迭代开发、测试驱动开发、持续集成、重构、结对编程、用户故事及看板、自动化测试、有效的反馈、站立会议、敏捷回顾和成果展示。传统开发方式以预测性为原则，文档驱动，以流程管理、优化流程为主要策略；敏捷方法以适应性为原则，可工作的软件驱动，面对面的交流为主要策略。

·在需求上：化“一蹴而就”为“循序渐进”；化极端严格的文档定义为形式多样和简洁的文档以及频繁的沟通；以有效的开发实践持续容纳需求变更。

·在设计上：以测试驱动开发为保证的演进式设计策略；以简单设计为目标设计原则；通过持续集成最大程度减少子系统间的架构冲突；通过结对编程进行持续设计评审，减少实现偏离设计的概率。

·在运维上：以迭代式开发代替瀑布式开发；首次交付实现最少但重要功能的产品，再周期性地不断交付新功能；根据需求设计架构。

·在实现上：敏捷的核心实践包括——测试驱动开发；结对编程；持续重构；简单设计；持续集成；知识共享；持续代码复审；新成员能迅速融入。

在敏捷开发中，第一次发布交付的是一个包含功能中最小可用集合的系统，然后再周期性地增量发布，来不断交付新的功能。特别是在大型的项目中，这种交付的好处非常突出，对软件价值和团队信心都有非常重要的好处，也使得敏捷项目基本没有延期交付的压力。在全部的开发过程中，根据客户对需求优先级的排序，首先实现重要需求。同时每一个迭代，客户还是可以调整需求开发的先后顺序，包括增加或者修改需求或删减需求。

在每一次发布过程中，最初构架也会根据需求而进行设计。由于敏捷方法最初设计的构架都着眼于将来的增量发布，因此都有很好的扩展性。当传统软件开发方法到无法再增加功能而不得不摒弃现有架构的时候，敏捷方法还可以在此基础上不断扩展。

在迭代开发中，客户如果在完成几个迭代后，发现原有的需求不再需要，就可以将这部分时间用于新的需求开发和需求修改，将无用功降到最低。同时和客户风险共担，在开发全过程中，能很好地接受客户的需求增加和变更。所有使得很多系统，在一期的时间段和费用预算内，就完成了传统开发中二期、三期的工作内容，节约开发投入是显而易见的，更重要的是帮助业务部门把握了市场的先机，创造更多的价值。

敏捷需要必要的文档；必须确保每个文档至少有一个读者；敏捷鼓励各种实践；必须确保每个实践至少解决一个问题；放弃任何没有价值的事情；不要做任何过度设计的事情。传统软件开发方法无法预测投资回报，系统上线后20%~30%的功能已经不是用户需要的了，甚至是50%；另有10%~20%的功能在系统上线后也会成为用户不需要的功能，甚至更多。这是巨大的投资浪费。与传统方法相比，平均早6~12个月回收投资回报；95%~100%的功能解决关键业务问题，并且通过在最初的发布和迭代中交付这些功能从而实现价值最大化。投资在每个迭代中不断地回报，这个数字或许更多。敏捷能给公司带来更早的投资回报；持续不断交付最重要的商业价值，产品更早进入市场；增加产品的资产价值；开发出高品质产品并消除浪费；更好的交流效果；提升项目中每个相关方的透明度和可视性等好处。

一个月后，王峰的团队完成了之前觉得不可能完成的任务——新产品上线了！同时，通过帮助员工“发现问题—建立能力—发现目标—自组织—实现目标”，以“示范（做一遍给员工看）—结对（与员工一起做一遍）—建议（只提供修正意见）”的思路进行教练，团队成员的能力获得很大提升，普通的技术人员也会用数据分析的方法找到问题并知道如何优化产品，团队成员互相激励，频繁交流，开心并充满创造力，氛围极好，真正实现自组织。王峰终于彻底解放，不用再疲于奔命地四处救火了。三个月后，日活跃用户达到159万，新注册玩家周流失率降到65.6%。而之前认为不可战胜的对手Virtual City的数据只有《摩登城市》的三分之一，原因在于它只是一个汉化版，同时又是分布式的跨文化管理团队在做支持，对外界变化的反应非常慢，与《摩登城市》团队的轻敏捷组织相去甚远。王峰没想到，一个垂死的项目就这样复活了。

一周后，李成到另一个项目组去了。又过了几天，《摩登城市》全体团队成员收到了李成的一封e-mail，没有开头也没有收尾，只有干巴巴的两段话，大家明白，这就是他的风格——简单快捷营养有效：

我们之所成功，是因为做了几件事：①确定清晰的产品方向和目标，并毫不动摇地坚持走下去；②给团队建立起可以快速验证设计的研发能力，实现持续改善，不走捷径；③团队实现自组织，保持开放心态，不断提供指导，充分信任和授权，每件事想办法做到极致；④以商业价值为导向，用科学的方法，根据用户反馈优化产品。

批注

1.在一个团队陷入困境时，他们最需要的是成功的滋味。要转型就要先让团队收获成功的感觉。李成的方法快速在团队中见效是团队转型能够持续推动下去的根本原因。通过几个“小胜”建立信任，再深入推动团队转型。

2.对于坚决抵触变革的团队成员，有时更多是一种情绪，不是通过和他们讲道理能疏通解决的。对于这种成员，要么直接清除，如果确实有特殊才干希望留下他们，则不宜直接去和他们摆事实讲道理，而通过他们信任的团队成员去影响他们，收效最好，因为人最容易受自己信任的人影响。

最难改变的还是人的思想，其实我们团队中也有一部分人是抵触的。比如，对于面对面的沟通，有人觉得还是文档可靠；对于自组织，有人觉得还是要控制。他们没有尝试过，会有很多担心，这很正常。好在我们的方法快速起到作用，解决了几个团队最头痛的问题，同时对抵触者更多地做一对一的辅导，也通过他们非常信任的人去影响他们。最后的结果大家也看到了，我们从非常不信任变成完全信任！相信我，现在的你们，无敌了！^[1]

[1] 本文根据腾讯《摩登城市》社交游戏项目真实境况改写而成，应被访者要求隐去真实姓名。