你好,我是箴亚管理顾问公司负责人,同时也是TGO鲲鹏会台北分会学习委员游舒帆,今天想跟大家分享的话题是“高效研发流程的第三步,研发流程管理中最困难的那些事”。
前两篇文章中我与大家分享了组织架构与研发流程的选型,这两者都是高效流程的基础,可以让团队做好事(Do thing right),但却不见得能做对事(Do right thing)。
我曾在台湾敏捷峰会上分享过一句话,在这里也分享给大家:“如果敏捷走不出技术团队,就不可能真正敏捷”,一样的观念“研发流程如果只着眼于研发工作本身,就不可能真正高效”。因为研发团队不是独立存在的,其本身的工作与外部具有一定的相依性,例如需求、营销、运营、服务等,如果我们不能有效的管理这些事,只会事倍功半。
本文我将会着重就研发管理过程中最困难的几件事:需求管理、优先级、迭代与交付方式、跨部门沟通与数据驱动等主题与各位分享我的经验与看法。
所谓的需求管理,并不是单指整理出需求列表,而是需要对这些需求做有效的管理,让团队能满足老板与客户的期待,所以我也常说需求管理本质上其实是期待管理。
在谈期待管理时,我常常用这张图来跟团队沟通:
我总是问团队:“你们清楚老板想解决什么问题吗?”因为很多时候,项目团队往往只看到有件事得做,而时程已经被压上去了,所以匆匆忙忙的开始项目工作,但却很少花时间去理解这个项目背后的为什么。一年下来,做的项目也不少,但却没有几个项目真正解决问题。
如此,老板的需求没有真正被满足,对团队的信任感自然也不会太高,而这样的企业,一般效率也不会太高。
如果公司的组织架构是属于多阶层式的科层组织,那这个问题会放的更大,老板可能只是想解决一个很简单的问题,但经过层层解读与转达后,最后收到的需求是要做一整套系统。导致原先只要一两周时间就能解决的问题,却往往得拖上半年一年之久。
要真正做好期待管理,团队必须在承接每个项目时,都往上层去了解源头的问题,这就是所谓的上游信息。当团队能真正理解老板与客户的真实期待,并逐一解决时,需求管理这件事才可能真正做好。
排优先级,一直都是件难事,我们如果想在相同的时间内创造出更多的价值,那决定先做什么,不做什么就成了关键点,所以优先级的规则至关重要。过去我们曾经采取过几种排定优先级的方式:
第一种,权力决,通俗一点来说,就是由权力大的人来决定,排第一的通常是老板或业务部门最高主管。权力决有另一种变形,那就是让承担该业务的主要负责人来做决定,例如产品经理决定产品优先级,业务主管决定业务需求优先级。权力决的好处是决策者明确,然而缺点是官大不一定学问大,有权力的人,对现场的把握度可能反而是最差的。
第二种,共识决,由大家共同决定项目的优先级,严谨一点的甚至会成立一个委员会来定期处理此事,然而就过去经验,如果没有适当的机制来维持客观性,共识决与认可决的背后其实仍是权力决。
第三种,数据决,由大家共同协议一个项目价值的运算公式,例如能带来多少业绩、改善多少服务满意度、提升多少用户增长或留存率、降低多少人事成本等。每个项目都会被算出一个权重,然后依此权重值进行所有项目的排序。这个做法的好处是客观,所有参数都是经过讨论后得到的共识,缺点则是对项目价值的计算不会一开始就很精准,必须经过一次又一次的修正后才会越来越准。
过去这些年来,一般种况下我是倾向使用数据决,如果过程遭遇争议,便辅以权力决或共识决。
如本文开头所述,如果研发团队能将视线从团队内移往团队外,并面对真正的问题,那我们应该会把重点放在快速迭代,创造价值,而不该单单着眼于开发迭代,这句话的意思是“解决问题,不必总是仰赖技术”。
专业人士因为拥有一身绝活,所以思考问题时总想着运用专业来解决问题,技术人在面对问题时也时常会想用技术来解决,然而有许多事情其实可以靠流程解、人工解、沟通解,不见得总是得仰赖技术。过去在带领团队时,我给了团队绕路解、临时解、根本解几个规则,让他们在规划与思考时能有依归。
问题发生的当下,依循处理问题的三段式方法,一定要先能提供一个绕路解,也就是workaround,但身为研发人员,我们都很清楚workaround不代表问题被解决,如果不根本解决问题就会累积技术债。所以我们还是要从根本来解决此问题,但如果根本解的时间太长,用户无法忍受,你就要提供一个临时解来缓和用户的痛苦,不能根除也要先能止痛。
这样的做法,基本上能同时考虑到技术与运营两方,在内部讨论时很容易取得共识。
而面对需求,我们也强调三段式方法,如果有个需求可以每月创造2亿的营收,但完整做完需要花4个月的时间,我们会将这个需求细拆,找出其中相对有价值的部分先做,可能只花1周的时间,就能达到20%效益;紧接着在4周内再推出第二个版本,这个版本已经能创造60%效益;最后再推出根本解,实现完整的需求。
当我们着眼于更快的创造价值时,迭代的方式与周期便可能有多种方法,而三段式方法是我们过去用过的,效率非常好的一种方法。
“解决问题,不必总是仰赖技术”这个观念我们也在持续推广到研发部门外,让大家了解不是凡事都得靠系统,如果时间真的急迫,但研发部门暂时排不出资源,我们也会从专业角度提出其他建议方案。
过去产品团队曾提出一个很棒的产品点子,在早期规划时产品经理与设计团队对于功能产生诸多歧异,并且技术团队做了初步评估,认为要完成这个功能最少需要四个月的时间,我们就这样僵持在会议室内。
此时有位同仁提出了一个很好的建议。他说可以找客服部门合作,请他们找40位客户,并告诉客户我们将提供一项新服务,邀请他们抢先体验。而初期,便由客服部门同仁通过人工来服务客户。
我当下觉得这个建议可行,便去找客服主管讨论此事,她听完后觉得很不错,虽然会增加一部份工作量,但能协助产品部门更快的把好的产品功能产出,这些投入非常值得。
人工处理的好处是调整效率高,早上客户反映有状况的地方,下午就可以修正,这种效率是技术做不到的。这个人工服务的时间大概维持了一个半月左右,过程中流程调整了多次,服务内容也修正了好几次。我们可以思考,如果是交由系统来迭代,我们需要花多少时间才能迭代出这个结果呢?
不过,虽然人工迭代的效率高,但人工毕竟无法处理大批量的工作,这部分还是要交由系统去处理,然而有效结合人工与系统,将可能创造最高的迭代效率。
在我过去经验中,技术主管最常求助于我的问题有二:第一个是向上管理问题,不知道如何有效的跟老板沟通;第二个则是横向的跨部门沟通问题,彼此之间KPI不同,目标不同,讨论时常谈不到一个点上。
其实上述两个问题的解决方法是一样的,都是要掌握上游信息,解决上游问题,我说服团队成员学习向上管理,运用的是本文前头提到的,不断去追问 “为什么” ,只有掌握了为什么,才能知道自己做的事情到底对不对。
而我用来说服团队做好横向沟通则会辅以一个故事:“如果今天你住在河川下游,河川的上游住了另外一群人,上游这群人每天都会在河里倾倒垃圾,所以位居下游的你,要不没有干净的水好用,要不就要喝脏水,此时你会怎么做?”
“我会搬到他的上游去。”“那他也会继续搬到你上游,互相伤害。” “我到上游去将河道分成两条路线。”“好方法,但工程浩大。” “我会去劝导他们不要这样。”“一开始有用,两天后可能又故态萌发了。”
通常经过一轮讨论后,大多会得出这个答案:“我去帮他们建立垃圾处理机制”。不管我提问的对象是什么背景,这个简单的答案通常都不会在一开始就出现,原因很简单——我们都认为那是对方的责任。所以我们会直觉的绕开对方的责任圈,我们只在圈外打转,顶多作柔性劝导,而不愿直接有效的帮对方解决问题。
我常灌输大家一个观念,如果我们的上游出问题,不论他是没能力、没资源或是不愿意解决,问题就是在那,如果不帮他解决,我自己就得蒙受其害。这种情况下,那件事不再是别人的事,而是我们的事。当所有部门都理解了这个观念,都能协助上游解决问题,并给下游干净的水源,那跨部门沟通便不再是问题了。
当决策、运营与开发都在正确的组织架构、流程上,而上下、横向之间的沟通都没有阻碍时,研发流程才真正实现了高效。