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