垂死项目复活记，本文主要内容关键词为：项目论文，此文献不代表本站观点，内容供学术参考，文章仅供参考阅读下载。
“多少？”王峰盯着李成手上的报告问。
“你猜！嘿嘿！”
“找抽是吧？！”
“159……万！”
“哇哦！另一个？”
“65.6%！”
王峰抿了抿嘴，点了点头，起身向办公区的同志们吼道：“大家听好了！159万！65.6%！继续！加油！”在一阵小骚动后，王峰走向李成，相互击掌拥抱。要知道，三个月前的数据是日活跃用户1.2万，新进玩家周流失率高达92%！两人紧紧相拥，久久不分。对此，大伙已经习以为常，在过去的几个月，他们已被“公认”有“基情”。而这段难忘的“基情”结缘于TQ公司一个雄心勃勃的社交游戏项目——“X城市”。
悲情“城市”
他相信，团队中没有一个人不想把事做好，公司也提供了平台资源，但结局为何如此不堪？
作为国内互联网巨头TQ的技术骨干，王峰在过去的十个月跑了趟事业的“过山车”。先是被紧急调任为“X城市”游戏产品总监，在火急火燎地带领团队开发了六个月后，游戏终于上线，但一个多月来的数据却惨不忍睹（1.2万；92%）。王峰问自己，人生还能更悲催一点吗？
能！随着TQ开放平台战略的推进，美国一款有史以来最火的社交游戏V—City正式入驻TQ平台。当初启动“X城市”就是受到V—City的启发，创意也是在模仿人家。V—City已经运营三年有余，产品的完成度非常高，背后还有一个超过200人的团队在维护。
反观“X城市”只有不到30人的团队，有限的预算，不理想的玩家数据带来的士气低落，以及疲惫不堪的自己。29年来，王峰从来没有像现在这么郁闷和绝望过。他知道，团队中几乎没有人有社交游戏开发经验，有些新人甚至没有软件开发经验。虽是第一次担任产品总监，但他也明白，这些不能成为产品失败的借口。
在过去的半年，团队成员的努力王峰都看在眼里。项目启动会上，一些团队成员激情澎湃的演说场面仍然历历在目，项目推进过程中虽也磕磕绊绊，但他相信，团队中没有一个人不想把事做好，TQ公司也提供了平台资源，但结局为何如此不堪？正在困顿不解时，公司给他派了个助手，他就是李成。
浑水摸“鱼”
团队中居然有近80%的员工50%的时间处于等待状态。为什么自己每次看到大家都在忙碌？没有几个团队成员真正了解每次发布的产品要实现的功能，这实在令人惊诧。
敏捷开发的特点
1.在需求上：化“一蹴而就”为“循序渐进”；化极端严格的文档定义为形式多样和简洁的文档以及频繁的沟通；以有效的开发实践持续容纳需求变更。
2.在设计上：以测试驱动开发为保证的演进式设计策略；以简单设计为目标设计原则；通过持续集成最大程度减少子系统间的架构冲突；通过结对编程进行持续设计评审，减少实现偏离设计的几率。
3.在运维上：以迭代式开发代替瀑布式开发；首次交付实现最少但重要功能的产品，再周期性地不断交付新功能；根据需求设计架构。
在得知李成管理咨询出身的背景后，王峰彻底绝望了。“还以为会帮我找个技术或是产品高手，却来了个练嘴皮子的。”王峰正叨叨着，李成就到了。
“你觉得这个项目还有必要继续吗？”王峰淡淡地问道。
“您觉得呢？”
“可以再看看吧，毕竟花了那么多精力。”
“这不是关键，关键是找出问题的根源。”
“大家都很努力，我也是拼了命，会不会是产品定位有问题？”
“可V—City相当成功。”
“那就是产品本身有问题？”
“您觉得呢？”
“是还不够完善，但也不至于如此惨淡啊？”
“不够完善？您的结论？”
“不，是团队共识！”
“结论要由玩家来做，而不是由开发团队！”
“这……”
“还有，诸如‘大家都很努力’这样的评价没有任何意义，管理者要的是结果，如果没有‘好的结果’，‘努力的团队’就要反思，达成‘好的结果’是您的责任。”
李成的话确实刺激了王峰，但项目窘境当前，他也只有忍了。第二天，在李成的建议下，团队全体成员开了个沟通会。
“今天没什么事，就是一起聊聊天。半年多了，大家还记得自己最初在加入项目组时的目标吗？”李成笑着对大伙说道。
“希望能通过这个项目提升产品开发能力呗。”一个刚入职不久的新人答道。
“嗨，别提了，我原来是准备来挣10-monthes的奖金的！”
“说实话，不是很清楚，抄袭V—City？”
“我是被安排的！”大伙哄堂大笑。
“我是来打酱油的。”居然出自一个核心成员之口。
“我不告诉你！”又是一阵笑声。
一切王峰都看在眼里，他没想到大家所言与自己的目标——开发一款顶级的模拟城市社交游戏——差距这么大。这让他回想起过去半年团队中很多无效的争吵和误解，莫非根源在目标不一致？
“好，我们换个话题。大家一起来抱怨抱怨过去半年的工作！现在，将你的怨气大声说出来！”李成说。
“忙的时候忙死，闲的时候闲死。”一个产品测试人员说道。原来测试小组在另一个楼层办公，当开发人员将产品交付测试时，有的有文档描述，有的则没有，即使有描述的也大多不够清晰，测试人员多是根据自己的想象去做测试，常常出现误差。不同小组相互间的沟通非常少，冲突却很多。同时，测试人员在每周的前几天常常没事干，后几天则要工作到下半夜，满意度很低。
“是啊，反正头儿派了任务就去做，不派任务就不做了呗，还能怎样？”
“其实有一半的时间是在等任务啦！”一个负责策划和设计的员工说道。
“我觉得问题是，给的都是具体任务，但我们根本不知道这些任务完成后要实现什么功能，很难发挥我们的创造性！”
王峰默默地打着腹稿做记录，最触动他的是，团队中居然有近80%的员工50%的时间处于等待状态。为什么自己每次看到大家都在忙碌？假象吗？同时，没有几个团队成员真正了解每次发布的产品要实现的功能，有的甚至只知道20%，这实在令人惊诧。
“好了”，李成打断大伙的发言，“大家辛苦。我们再聊聊过去半年中大家冲突和讨论最多的一件事吧！”
“当然是棺材板元宝啦！”一位员工抢答道。
王峰知道他说的是“X城市”游戏中，玩家完成任务后，点击房子就会哗啦啦地掉金币。后来有成员提出金币不好看，就改成元宝，有人又说元宝像棺材不吉利，就改成了不同颜色的元宝，后来干脆改成金砖，改成宝石，甚至一度改成阿尔卑斯牛奶糖……而这些改变对于用户数据的改观没有起到任何效果。
团队在这些低优先级的活动中耗费了大量精力，整个过程全凭拍脑袋。而过早开发低优先级功能，将大大增加代码的复杂程度和缺陷数量。同时，很多文档尤其是策划设计小组的功能需求文档不规范，缺乏必要的信息和路径，导致大量返工，开发团队非常不满。
王峰没想到，自己的团队信息如此不透明，角色和职责如此不清晰，策划人员、开发人员和测试人员都没有很好地承担职责，都等着他分配任务，对自己高度依赖。想想吧，自己每天来得最早走得最晚，既负责技术又负责产品，而他们却闲得发慌。
会议临近结束，一个团队成员说：“从来没有这么痛快地将自己的真实想法说出来！以前都是通过邮件、电话、QQ和文档联系，确实没感觉。”王峰望了望李成，向他竖起了大拇指。
为什么自己每次看到大家都在忙碌？假象吗？同时，没有几个团队成员真正了解每次发布的产品要实现的功能，有的甚至只知道20%，这实在令人惊诧。
大家一致认为要再搏一把，定一个清晰的产品方向，快速增加新功能或优化现有功能，通过迭代式开发改进产品。
当晚，王峰叫上团队的核心成员，当然少不了李成，一起到附近的茶馆喝茶，顺带头脑风暴，聊聊“X城市”下一步的发展策略。近半年的投入让大多数成员对这款游戏有了很深的感情，但也少不了有一些核心成员认为早放弃早超生。
“李成，你的看法？”王峰问。
“我们是否要放弃由V—City决定，而不是我们自己。对于同一类型的社交游戏产品，玩家只会选一款玩，如果国内玩家确实喜欢V—City，那我们就别做了。”
“V—City的完成度和实力确实比我们强很多，但相关的玩家数据我们还没有拿到。”
“你们不断提到‘完成度’，但它不是社交游戏的核心，核心应该是‘社交’！”李成说。王峰看出李成今晚是有备而来的。“我认真研究过V—City，它的核心玩法是一个‘帮’字，利己不损人，这符合西方人的社交观。但国内之前最火爆的社交游戏却是开心农场的偷菜！占小便宜、不劳而获、损人利己，这是国内大多数玩家在社交游戏中认可的趣味点。同时，V—City仅仅是汉化了，它的建筑仍然是欧美风格，对西方玩家代入感极强，但对国内玩家则极差。”
“对！社交游戏要基于社交观来做，中西社交观完全不同！代入感的问题非常关键，这是我们的机会！”王峰抢过话头，其他团队成员也频频点头。又陆陆续续聊了一些细节问题后，大家终于统一目标，一致认为要再搏一把，定一个清晰的产品方向，快速增加新功能并优化现有功能，通过迭代式开发改进产品。
机会是看到了，但团队问题怎么解决？在大家陆续散去后，王峰叫上李成到附近的酒店开了间房，两人畅谈了一个通宵，“基情”的玩笑也由此在团队中流传开来。
“我们是否要放弃由V—City决定，而不是我们自己，对于同一类型的社交游戏产品，玩家只会选一款玩，如果国内玩家确实喜欢V—City，那我们就别做了。”
天下武功，唯快不破
故事墙仅仅上墙四周，团队效率就提升了近三倍，团队的满意度也随之上升。
问题1：大家都觉得自己很努力，但为何团队就是快不起来？
原因：由于团队信息不透明导致团队成员能力调度与时间调配混乱，项目进展的瓶颈始终潜伏在大家的视野之外。
方案：建立故事墙，推行站立式会议。
如表1所示，故事墙分“Ready（计划）—Play（开发）—Test（测试）—Done（完成）”四栏，不同的纸片代表不同的任务种类，浅灰代表功能需求，深灰代表技术任务，中灰代表Bug（缺陷），纸片内容含任务、执行人、工作量和计划完成时间等信息。任务的优先级程度由纸片自上而下的位置而定，在上的为高优先级。通过引入故事墙，将项目信息完全透明和可视化，团队成员每天经过就可以很清楚地看到整个项目的进度，每个任务要实现的功能，以及项目的瓶颈和问题。
表1是最初的故事墙，从中不难发现，很多任务已经在Play栏里了，但Ready栏内容严重不足，尤其竟然没有一张是代表功能需求的浅灰色纸片，这说明开发人员做得足够快，但策划设计人员没能提供足够的玩家需求，项目瓶颈一目了然。看到这样的场景，策划设计人员就不得不在没有任何人敦促的情况下，抓紧做需求研究，被故事墙赶着走。
产品策划设计部门在自我剖析后发现，由于很多需求是由前后台技术共同完成，而很多需求的后台技术已经完成但前台却没有实现。分析后得知，原来是前台员工严重不足所致！于是王峰迅速从公司其他部门借调相关人员加入团队。到周五时，有成员发现有些功能还没进入测试状态，大家站在故事墙前分析，原来是开发人员太慢了，于是开发人员自发地赶工。就这样，通过团队自发地不断找到项目瓶颈，自动消除瓶颈，项目过程不断优化，故事墙仅仅上墙四个星期，团队效率就提升了近三倍，团队的满意度也随之上升。
在故事墙的基础上，王峰与李成又将团队开会方式改为站立式，每天早晨大家围着故事墙讨论项目进展，相互沟通各自的信息和困惑，会议长度控制在五分钟左右。一个员工告诉李成：“自从有了故事墙和站立式会议，如果墙上没有自己的任务，或自己的任务优先级不够，压力就巨大，而且很丢人，不得不努力加班加点。”通过管理方式的改变，王峰不用再分配任务了，团队成员根据自己的任务情况去Ready栏领取任务，任务完成后将纸片挪到别的栏即可（认领—完成—确认）。从表2可以看出，在四周后的故事墙上，待完成的任务纸片越来越多，且绝大多数为功能需求（浅灰纸片），说明团队对用户的研究越来越深入，从事的改善工作越来越多；同时Bug（中灰纸片）消失了，说明随着产品信息的畅通透明，返工任务越来越少，团队实现了高速有效运转。
从“提神基本靠狗”到“通讯基本靠吼”
团队成员从以往的文档、邮件、QQ、电话等沟通方式，改为如无特殊需要全部到对方工位上面对面沟通，实现“通讯基本靠吼”。
问题2：大家都觉得自己很“牛”，为什么“神功”就是无法发力？
原因：传统的瀑布式开发注定要产生大量无用的功能，同时传统沟通方式极容易产生误解与冲突，相互推脱责任，大量繁琐的需求文档让团队疲于应付，你再有本事又有何用？应付了事是普遍心态。
方案：以快速开发、快速验证、快速修正的迭代式开发代替瀑布式开发，同时以面对面的高效沟通替代传统沟通方式。
经过前期的分析，王峰与核心团队已经基本明确了不再去模仿V—City，而要走自己的路，重社交玩法，轻单机体验，在此基础上制定具体的设计策略。在以往的功能测试中，如果玩家反馈Bug，团队直接就去修复了，这样会打乱之前的迭代开发计划。同时，团队成员也不知道是需求更重要还是Bug更重要，对于谁更优先困惑不解。王峰和李成在与大家沟通后，定下一个新的管理机制：无论是需求任务、技术任务，还是Bug，都放到统一的需求池中，按照统一的优先级标准进行排序（下页图）。优先级的排序以实现商业目标为根本标准。比如，如果某个设计就是为了好玩，而无法实现如提高玩家活跃度等商业目标，就将被排到后面去。这样团队就不用再纠结于谁更优先的问题，也不会打乱团队开发计划。
测试是产品开发非常重要的一个环节，它反馈的信息是否准确直接决定了整个团队对产品的认知，以及后续的成败。为了让测试人员不再凭“第六感”去猜测试需求，王峰与李成让测试人员全程参与产品讨论，使他们不用文档描述也能清晰了解测试需求，需求人员、测试人员与开发人员沟通效率迅速提高。同时，之前常常是一个版本完成了才去做测试，由此带来大量无用功能的开发与人员精力的浪费，这是瀑布式开发的主要弊病。经过调整，王峰要求首先开发人员要做测试，同时产品策划人员也要做测试，最后，测试人员进行需求级别测试以及版本测试，从一个级别测试增加四个测试级别，大大减少Bug数量，同时省去海量文档。
故事墙解决了团队信息透明的问题，但仍然不够。一个有趣的发现是，李成在与团队沟通的过程中，大家都认为面对面沟通最高效，但就是没有人进行面对面沟通。王峰也深有同感，在过去的半年，办公区常常安静到可以闹鬼。在他的推动下，团队成员从以往的文档、邮件、QQ、电话等沟通方式，改为如无特殊需要全部到对方工位上面对面沟通，实现“通讯基本靠吼”。当然，首先要将不在同一楼层的项目成员拉到同一个办公区间。通过这种快速即时反馈，大大消除了团队成员之间的误解，活络程度也大大提升，工作氛围非常好。
就这样，团队目标变得非常清晰，成员对各自的职责与角色也非常明白，同时，王峰与李成还将每个功能的目标都贴到每个人的座位上，不厌其烦地与所有团队成员对产品和功能目标做详细沟通互动。他们深知，只有统一到同一目标下的争论才是有效争论，否则就是无效争论。
通过几周改造，“X城市”项目组从一个疲劳且昏昏欲睡能力不足的团队，转变为一个有战斗力有能力完全授权自组织且有统一目标的团队，工作效率和精神状态都获得极大改善。王峰开玩笑地对李成说：“现在的团队真的从‘提神基本靠狗’转型为‘通讯基本靠吼’！”他知道，只有团队改造成功，才有可能实现产品的持续改进。
人与人的差别远大于人与猪
“X城市”最大的玩家群体居然是三四线城市的宅男宅女和家庭主妇，此前大家一直坚信是一二线城市的高校学生。
问题3：大家都觉得是很好的东东，为什么玩家就是不喜欢？
原因：缺乏科学有效的用户调研，仅从自己的感觉喜好出发设计开发产品，以己度人，但玩家其实和你很不一样，“人与人的差别要远大于人与猪”，你难道不明白？
方案：找到目标玩家，观察他，感受他，理解他，拥抱他，爱上他。
“X城市”很多团队成员打死也想不到，这款游戏最大的玩家群体居然是三四线城市的宅男宅女和家庭主妇，此前大家一直坚信是一二线城市的高校学生。在一次详尽的用户调研结束后，王峰说：“之前的失败是必然的！”随后，他们请了一些有代表性的玩家到公司与开发人员沟通交流，让玩家玩给员工看，并做详细的观察记录，对他们的隐性需求做深入挖掘与分析。领导力大师约翰·科特指出，相对于“分析—思考—改变”的模式，“目睹—感受—改变”更容易让人发生变化。一个典型案例是，在“X城市”的产品设计中，有一个交互设计是通过一个动态的箭头提示玩家点击箭头指示方向的“我的好友”信息框，但大家通过观察发现，大多数玩家都是直接点击箭头。
怎么会这样？
“框框太小，箭头太大了！”
“箭头是动态的，而框框是静态的，我点击箭头有错吗？”
“我常常在这里浪费时间，这绝对是一个脑残的设计！”
“真的没想到！”一个团队成员说。当然团队马上做了改进调整，将箭头做小并相对静态，而框框则亮堂、动态且更加显眼。“这样的案例太多了，我们对游戏中的语言也做了全面的调整，尽最大努力与目标玩家的喜好实现匹配。”王峰说，“原来很多拒绝改变的团队成员很快发现自己在玩家面前是多么愚蠢，不仅迅速调整自己，还成为改变的推动者。”
由于互联网产品要持续采集用户数据才知道如何优化产品，因此必须清晰地告知开发人员要采集哪些玩家数据及其原因。此前导致大量返工的一个重要原因是文档的需求描述不清晰，于是王峰对策划人员要求以更简洁清晰的方式描述需求，按“目标—策略—验证标准—用户故事—界面草图—流程图—采集数据”的模板描述需求，在形式上结合“文字描述+流程描述+界面图描述”。用科学的数据说话，不断改善产品，做出详细的分析报告。科学的数据采集分析带来了更贴近玩家需求的功能改进。比如，设计更接近三四线城市玩家的界面风格，着色更加大胆鲜艳（大红大绿），城市建筑也集合了美甲店、拉面馆等，加上“收税”玩法，以及“炫耀”功能等，持续强化中国元素，增强玩家的代入感，流失率大大降低。
* * *
一个月后，王峰的团队完成了之前觉得不可能完成的任务——新产品上线了！同时，通过帮助员工“发现问题—建立能力—发现目标—自组织—实现目标”，以“示范（做一遍给员工看）—结对（与员工一起做一遍）—建议（只提供修正意见）”的思路进行教练，团队成员的能力获得快速提升，普通的技术人员也会用数据分析的方法找到问题并知道如何优化产品，团队成员互相激励，交流频繁，开心并充满创造力，氛围极好，真正实现自组织。王峰也终于彻底解放，不用再疲于奔命地四处救火了。三个月后，日活跃用户达到159万，新注册玩家周流失率降到65.6%，而之前认为不可战胜的对手V—City的日活跃玩家则只有“X城市”的三分之一。原因在于它只是一个汉化版，同时又是分布式的跨文化管理团队在做支持，对外界变化的反应非常慢，与“X城市”团队的轻敏捷组织相去甚远。王峰真的没想到，一个垂死的项目就这样复活了。
一周后，李成到另一个项目组去了。又过了几天，“X城市”全体团队成员收到了李成的一封E-mail，没有开头也没有收尾，只有干巴巴的两段话，大家明白，这就是他的风格——简单快捷营养有效：
“我们之所以成功，是因为做了几件事：1.确定清晰的产品方向和目标，并毫不动摇地坚持走下去；2.给团队建立起可以快速验证设计的研发能力，实现持续改善；3.团队实现自组织，保持开放心态，不断提供指导，充分信任和授权，每件事想办法做到极致；4.以商业价值为导向，用科学的方法获取用户意见优化产品。
最难改变的还是人的思想，其实我们团队中也有一部分人是抵触的。比如，对于面对面的沟通，有人觉得还是文档可靠；对于自组织，有人觉得还是要控制。大家没有尝试过，会有很多担心，这很正常。好在我们的方法快速起到作用，解决了团队最头疼的几个问题。同时对抵触者更多地做一对一的辅导，也通过他们相对信任的人去影响他们。最后的结果大家也看到了，我们从非常不信任变成完全信任！相信我，现在的你们，无敌了！”
“三板斧”打造轻敏捷战队
王峰面对的是几乎每个市场后进者的新项目团队都无法回避的困境：新人多，缺乏经验，粗放的管理方式，强大的竞争对手……他的胜利让我不得不说，这是一个以弱胜强和自我救赎的精彩案例。那么，王峰的团队究竟做了什么？他们不过是明确了目标并订立了合理的战略实现方式——快速验证、价值驱动与团队自组织，打造出了一个轻敏捷战队，进而实现产品的战略意图。
“快速验证”能力是打造轻敏捷团队的第一步，即快速让产品与用户见面，快速验证产品的设计是否合理，并持续优化。这需要团队建立快速迭代的工作方式，如迭代式开发、看板（故事墙）、站立式会议、数据驱动产品设计等。这些方法和实践同时依赖先进的自动化工具，让一切重复性的工作自动化，同时重视对用户反馈信息的收集，并做定量和定性分析，让“设计-验证-完善设计”形成闭环。
商业价值是很多产品开发团队最难把握的，也是很多产品失败的根本原因。“价值驱动”需要管理者和团队一起设定清晰合理的业务目标，让所有团队成员都知道什么才是最有价值的事情，进而明白不同任务的优先级差异，让整个团队专注于商业目标。
当团队目标明确，并专注于最高优先级的任务时，就要充分授权给他们，让团队自我组织做决策，自主制定计划，自主协作，并完成任务，这样才能最大限度发挥其特长，保证组织的高效运行。当项目信息完全透明时，团队就能随时随地了解项目和每个人的工作计划及进展，大家自然而然地就有了压力，也有了动力。
“团队自组织”可以给公司带来意想不到的惊喜。我在腾讯辅导了一个项目，把强制性分配任务的项目经理领导方式，分解为若干个小组，同时让每个小组自己做决策，让每个人选择自己的工作而不是分配任务，结果团队在两个月之内效率翻了一番。整个过程并没有要求团队加班加点，但这就是自组织的力量所在。
从王峰的案例可以看出，在一个组织转型为“轻敏捷”团队的过程中，不但需要一把手的支持，更需要如李成这样有经验的专家辅导。国内不少公司还没有养成“引入外脑”的习惯。而绝大多数国外的领先企业每次变革转型或并购，都是在有经验的外部专家辅导下完成的。由于与内部各个利益相关方没有利益关系，外部专家可以更客观地从第三方立场帮助企业设计科学的解决方案，并通过方案试运行的过程中不断地沟通交流，平衡利益关系，最终实现转型目标。