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