项目执行中的首胜体验

在日常工作中，团队协作必不可少，最常见的情况应该就是任务延期交付了吧？如果说不如意事常八九，这不如意想必换成了「延期」也是毫无违和感的。Deadline 一般都不是 Deadline，经验丰富的 PM 应该心有戚戚焉。

项目常常延误的原因是什么？是团队不给力？是估算不准确？还是任务本身有问题？撤换团队？去掉估算或者变更估算算法？很多解决方案无法触及任务的本质。我认为常见的原因是：任务边界模糊，以及任务和执行者的匹配度不高。

任务边界模糊，也就是任务在界定的时候缺少了足够的界定环节，或者缺少合适的方法。在传统的项目管理过程中，通过「需求收集和整理」活动，在开发之前准备了大量的需求分析文档，设计图和原型图等，投入了大量的时间精力搞清楚任务的边界。在执行前做大量的准备和设计并无不妥，问题是可能在瞬息万变的市场中，失去了快速响应的机会。

在敏捷的环境下，通过「作为...，我需要...，以便...」的用户故事方法，再加上 3C（Card, Conversation, Confirmation），DEEP 方法和实例化需求等方法，基本上都可以把需求详细的讨论清楚。在讨论过程中团队建立起相互的信任关系，和关于任务的沟通原则（这个是重要的组织知识，在项目管理的语境里，叫做「组织过程资产」）。这是兼顾传统项目管理的边界设定，和敏捷项目管理的轻量级方法的「混合方法」，在实际执行中可以灵活使用。

任务和执行者匹配度不高，主要表现在：给执行人安排的任务，要不就是比较难，技术业务各种坑；要不就是任务颗粒度太大，老虎吞天无从下口；要不就是资源配合不足，孤胆英雄勇闯虎穴。这样分配的任务，再加上团队协作的变量，到最后能完成都是奢望了（更别提什么质量了）。

那么该如何解决匹配度不高的问题呢？我的建议是参考游戏设计中的「首胜体验」。

「首胜体验」的游戏的一个常见术语，一般我们进入到游戏的时候（尤其是中国网游或手游），都会有简单的引导，通过一段简单的操作可以熟悉游戏的操作过程，轻易的完成第一组动作并获得奖励。简单的引导消除了玩家首次进入游戏时的不适感，而第一次的胜利让玩家更有动力接着玩下去。

工作中的「首胜体验」指的是，在执行的前面几个任务比较简单，很容易就完成了，然后紧接着稍微提高一点难度，让执行者在略有挑战，但不超出能力范围的过程中，进入到深度工作的「心流」状态，从而达到高水平的绩效状态。这种方式循序渐进，但是更加强调的是第一步的任务达成。

我们在工作中的主要目标，都是要使之完成，而不是通过任务摧残团队的自信心和挑战团队的执行力。既然如此，我们不妨在项目的初期，把任务拆解到可执行单元，尽快把依赖项和技术风险消灭于无形，并让团队自主的完成任务。完成一个小任务，然后接着完成一个稍微复杂些的任务，再扩展到一个有挑战，需要比较长的集中周期的任务上，这流程就顺理成章了。唯有如此，我们才能积小胜为大胜，积跬步以致千里。

小目标，同样也是团队自组织的开始。在任务拆分到合适大小的情况下，从心理上也减少了团队的负担，让一个任务变得「可接受」并「可实现」，是团队自愿认领工作的起点。团队参与任务的分配和认领，而不是被动的接受任务指派，是所有自组织团队的基础步骤，这一方法同时适用于传统项目管理和敏捷项目管理环境。

小目标的另外一个好处，就是可以谨慎的试错。在飞速变动的市场环境下，经过繁琐验证后获得超长的待办列表和复杂的功能设计，本身就有失「精益」和「敏捷」的精髓。通过大目标拆分成的几个小任务，快速切人市场以尽快获得「经验证的认知」，是当下的研发团队必不可少的心法。毋庸置疑，小目标就是这个心法的具体呈现。

作者：翁云锋（Ivan），项目管理师，敏捷教练，厦门敏捷社区主要组织者。《SAFe 4.0 参考指南——精益软件与系统工程的规模化敏捷框架》中文版译者之一。超过 7 年的项目管理实战经验，曾担任戴尔亚太区测试机项目经理、中国区测试机运营经理，美图高级项目经理、敏捷教练等职位。

---

点击这里，了解更多关于 Teambition 的故事