项目执行中的首胜体验

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

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

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

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

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

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

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

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

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

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

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

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