易奇官网-活动

敏捷开发,到底「敏捷」在哪里

日期:06-21

  ▼

       易奇科技导读:“敏捷”一词看起来简单,实际操作起来却不容易。易奇小编将敏捷与团队工作结合在一起,分享了一些自己做产品团队合作的经验。

  


  从初次接触“敏捷”到现在已经差不多1年了,在初期还做了一个PPT在团队内部分享,不过当时的理解比较粗浅。

  经过1年的工作实践与认知升级,对于它的理解也从当初的概念性理解,到了现在可以将其与团队工作结合在一起。

  一、对敏捷的解读

  敏捷的定义是:敏捷是一种创造产品或服务的能力,可定期获取价值,并在不确定中动荡的环境中迎接变化。

  注意其中一些关键词,如能力、定期、价值、不确定等,现在来进行逐一解读。

  首先,敏捷是一种能力,它不是一种方法论或者工作方式,是一种可掌握的能力。

  除项目之外,敏捷会渗透到产品或服务的中,它是伴随生命周期而存在的,并不是在某一段时间存在。

  敏捷是定期的,不是一次性的,我们都会经历产品或服务的迭代优化,因为市场在变化、用户需求在变化。

  所以对于团队来说,与其努力创造完美的产品或服务,不如通过版本的迭代来不断改进。

  关于价值,敏捷专注于客户(也就是最终的利益相关者)的满意度,这一点也与敏捷的价值观之一(客户合作高于合同谈判)相对应。

  最后一点,关于不确定、动荡与变化,敏捷提倡在灵活应变中稳定计划,但同时对于外来插入的紧急任务,也可以适应变化。

  虽然后者具体任务内容不可预知,但是对团队敏捷来说,需要提前为此类情况预留可应对的空间。

  


  二、敏捷的价值观

  第一部分有初步提到敏捷的价值观,第二部分来详细介绍下敏捷的4个价值观,也可以理解为指导团队敏捷的4个标准。

  1. 个体和互动高于流程和工具

  强调的是再好的协同办公工具都不如团队成员之间的即时沟通,无论现在是在用飞书、企业微信、钉钉这类面向协同办公场景的产品,还是直接使用微信、QQ这类集合日常生活交流的产品,亦或者使用OA这类流程产品。

  工具和流程可以在一定程度上提高工作效率,但这些流程和工具是一个“保底”的效用,在遇到一些重大事情或者比较紧急的事情,亦或者面对面沟通成本低于使用工具进行沟通时,多进行个体互动且形成这种习惯,是更佳的选择。

  2. 工作的软件高于详尽的文档

  在日常工作中,大家都会看到产品经理的需求文档、设计同事的设计文档、开发同事的技术方案文档……

  这些文档的一种重要作用就是进行信息的传达,尽可能减少低效的沟通成本。

  那产出这些文档,大家都有着对应的工作软件,如产品经理常用的Axure。

  对于文档来说,使用何种工作软件的意义更大于详尽的文档。

  早期需求文档其实都是word文档形式的,但是现在随着行业的发展,一些工作软件逐步进入了人们的视野。

  这些工具类似于工业时代的蒸汽技术,本质上解决的是同一类问题,但是可以大幅提高工作效率。

  从成本、效益角度来说,最终得出的投入产出比更高,因而更得用户认可和信赖。

  3. 客户合作高于合同谈判

  赚钱,或者说取得经济效益回报,是每个企业都要追求的目标,甚至可以说是大部分企业的首要目标。

  但是从企业的可持续发展来看,想要持续性的取得经济效益回报,就不能只关注合同的谈判,即不能只关注于某次合作带来的经济回报,而要将重点放在与企业合作的客户身上,要关注如何才能与客户取得长期合作。

  例如SaaS产品,其重点是客户的续费,而不是首次购买。

  如果只关注单次合作,而不注重长期合作,不提供优质的产品服务、售后服务。

  不仅不能获得客户的持续合作,而且企业口碑也会因此受损,在整个行业中都会受到不可估量的负面影响。

  4. 响应变化高于遵循计划

  最后一点,其实大家会感受比较深刻。

  每次在迭代开始前,产品经理都会跟技术、测试负责人制定产品迭代计划。

  但是在项目迭代过程中往往会有一些“突发情况”,例如老板又插需求了、市场商务同时又提紧急的“可以赚钱”的需求了。

  这种现象的发生仿佛成为了一个客观事实。

  但是既然发生了,那产品经理就要想办法解决。如何解决?

  其实在敏捷开发的思维里,每个迭代都会留一个“buffer期”,即创建了sprint之后,并不是按照时间要求,将所有的人力都进行排满,一般会预留20%的人力去响应一些变化的需求。

  最后还要提醒的一点是,响应变化高于遵循计划,并不是说不做初始的产品计划。初始的产品计划还是非常重要的,而且需要遵循执行。这样能保证项目的有序进行。

  


  三、当心“假敏捷”

  前面介绍了敏捷定义的解读,以及敏捷的价值观。

  但想要在团队中将敏捷真正推行起来,或者要将团队“转型”到敏捷的方式,可并不简单。

  对于敏捷,也不是仅仅了解了上述介绍,就可以获取敏捷的“能力”。

  造成“假敏捷”的原因有很多,在不同的团队中原因也不一样,这里简单罗列几种可能的情况。

  1. 对参与感的忽视

  敏捷是针对整个团队的,而不是其中一个或某几个角色的,因此团队中每个成员都要变得敏捷,这样才能确保团队对于敏捷的认知,处于同一认知水平。

  如有的同事作为产品支持角色,觉得敏捷只对产品经理、开发,跟自己毫无关系,因此工作中只管维护好自己的用户指南,而不注重敏捷的参与,最终会导致团队敏捷能力的缺失。

  2. 不想改变

  对于团队敏捷来说,sprint每日站会是很重要的一个环节,团队成员即使同步项目进展与遇到的困难。对于已经有旧的工作习惯的团队来说,也许并不容易很快接受这种方式。

  3. 害怕

  工资绩效都是职场人非常关注的点,但有的管理者习惯靠施加压迫和恐惧的方式来管理团队绩效。

  这种方式会降低团队的信任感,而互相信任是敏捷来说是非常重要的。此类管理者会害怕敏捷带来的挑战,挑战他的权威。

  4. 流于形式

  任何的理论只有投入实践,且带来效益才是有实践价值的。对于一些已经有成熟工作模式的团队而言,如果只是在原先的工作流程中“插入”敏捷,让团队工作看起来具有了敏捷的流程,而不是让敏捷发挥其应有的价值,则对于团队价值来说,收效甚微。

  5. 不注重客户的反馈

  做产品或服务的不断迭代很重要的一点就是不停接收用户的反馈,当然不是全盘的无脑接收。而是基于自己的判断和用户的反馈做分析取舍,这样才能不断通过用户的反馈来优化产品或服务。

  过于傲慢的团队往往容易闭门造车,最终产品做出来了,可是却没有用户买单。

  以上介绍的是几种会导致团队“假敏捷”的可能,还有其他的原因也会导致“假敏捷”,这个就要针对具体团队情况具体分析了。