高级产品分享:如何实现高效的产品研发与沟通技巧!

最近阿里一系列的组织架构调整,随之而来对阿里拆中台等相关解读的文章又尘嚣直上,再加上中台这几年的发展,大家对中台充满了争议,中台死亡论也成了一股暗流。

有人把它捧到天上,又有人把它甩到茅房;我认为中台概念现在没有可以丈量的标准,一千个人就有一千个中台的模样,有的人运用中台提升了组织的运行效率;有的人建中台却劳民伤财最后失败告终,中台没有错,只是用的人用错了而已。

很多传统企业数字化转型,太过强调中台的平台属性却忽视了更为重要的组织属性,一个不能变革组织的中台建设是注定要失败的;因为所有事情的执行者是人,没有匹配的组织架构,没有合适的岗位人员,相应的事情就很难执行。

一、从大秦帝国看中台

最近大秦赋在热播中,“及至始皇,奋六世之余烈,振长策而御宇内,吞二周而亡诸侯,履至尊而制六合,执敲扑而鞭笞天下,威振四海。”看的我们也是心潮澎湃,激昂壮烈。

回顾那段历史,我一直在思考,为什么是秦国一统天下,结束五百年的诸侯之争,为什么秦朝短短十几年就走上覆灭之路,它对后世中国带来哪些影响呢?它对我们的工作有什么指导启示吗?

和春秋战国时期的周王朝相比,秦制的本质是实行中央集权的郡县制,撤销了诸侯国,有人说秦制就是大中台,书同文、车同轨,其实就是one id;这么说也是有一定道理的,中台的本质就是由过去分散式的前台应用独立建设转变为统一建设,以达到更好的能力积累和复用。

但有人把秦二世亡国类比中台的死亡,这就有点牵强了。

秦朝灭亡从表面上来看是秦二世的昏庸无道,实行暴政,本质上更多是秦朝中央集权的政治改革过于激进,对过去的分封体制是一种颠覆,对于法家思想的过度执念,这样的改革只有像秦始皇这样雄才大略的帝王才能hold住;如果再给秦始皇更多的时间,也许秦朝就不至于二世灭亡。所以汉朝初期采用了郡县制和分封制结合的模式,循序渐进的进行改革,直到汉武帝平定七国叛乱,最终实现中央集权在后世中国的深远影响。

书同文、车同轨其实就是中台要建立统一的标准、规范,这对于组织的协同,对于能力的复用都有帮助;按道理这对于企业管理来说,或者对于研发来说,都是一件好事情,为什么却有那么多人中伤中台呢?

我认为中台的建设中,始终存在着管控与自主,稳定与创新等矛盾,这就需要强大的组织领导力,能打破原有的组织关系,不怕动某些人的利益才能完成。

很多中台失败的案例大多数是只有变革之心,却无变革之力。

拓展阅读:

向左还是向右?中台建设才不止这点纠结事

半年中台实践的思考:落地中台,贵在其神,活用其形

二、合理的研发组织是基础

中台架构一般是一些具备大型复杂生态系统的大公司在自主的前台和统一的后台寻求平衡的结果;对于大部分小公司来说,中台架构离我们还是比较远,所以我一直强调,对于中台架构要重其神而轻其行。

中台架构的成功的基础是中台组织的建立和保障,对于研发来说,一个合理的研发组织也是高效研发的基础。

笔者早几年负责一个互联网产品的技术团队,这是一个创业阶段的小团队,整个技术团队也就十几个人,业务也相对来说比较单一;所以组织架构相对来说就比较简单,分成了后端Java开发团队和APP开发团队,平时以产品迭代为主,偶尔也协调资源做一些和客户有关或者运营活动有关的项目。

此时职能团队是实线管理团队,而项目因为存在可变化性,是临时的虚线团队。

没有匹配的研发组织,如何实现高效的产品研发

随着业务发展,前台出现两个业务团队的时候,两个业务团队为了更好的让技术团队服务业务团队,开始要求拆分技术团队到业务单元,以便更好的和业务绩效挂钩。

如果该项目业务稳定、资源充足,可以独立成更有自主性的项目团队,否则还是按照虚线的项目团队作为过渡。当时我们就过早的拆分了团队,不可避免的部门墙也导致了在一些新项目时资源协同性很差的问题;好在我还是作为公司的技术总监来统筹技术管理,这个影响还不是很大;所以小团队不要过早拆分,否则资源本身不充足的基础上,又更加难以利用!

没有匹配的研发组织,如何实现高效的产品研发

一项新的业务,要尽量用现有的功能团队先进行项目初期的开发或者孵化,等项目上线或者成熟后,转由专门支持该项目的效率团队完成后续的迭代升级;所以最终形成如下图的研发组织,有侧重业务线,有侧重功能线。

为了便于更好的协同和技术体系的统一,CTO或者技术委员会将在技术管理中起到重要的作用。

没有匹配的研发组织,如何实现高效的产品研发

在一个自我演化的团队,只要保证CTO或者技术委员会的统筹和统一的技术管理的作用,技术团队的拆分、裂变都是有序的,技术体系的统一,技术规范的统一,开发流程的一致都能得到有效的维护。

2019年初,我开始负责一个TO B业务的科技公司的整体研发,很不幸的是,之前的技术管理做得很不好,表现在存在5个事业部,研发分散在事业部,且技术路线不统一,光主流的后端开发语言就涵盖Java,net和PHP三种;所以后续业务整合、研发统一的过程中,系统和技术的整合也是一件非常头疼的事情;当时尝试了中台化的解决方案,以期通过中台架构实现柔性化的统一。

既然说到中台的柔性,我想对于当前阿里拆中台的猜测表达一下自己的想法,也许阿里是年底正常的架构调整,也许是有人说的中台强管控对于前台应用的制约;如果真是这个原因,我想这和我对中台的理解不同,中台不能做强管控的中台,而是要做柔性的中台,改革是一个循序渐进的过程。

另外,有人把阿里前台创新的不足归结于中台的制约,我认为也是比较牵强的;中台不是创新的方向标,它只是创新的加速器,创新是靠的企业文化和管理机制;如果建了中台就能让企业具备创新的能力,这无异于是对中台的不切实际的过高期望。

另外,对于自运营的互联网应用研发的企业和对外实现客户交付的偏软件应用研发的企业,对于研发组织的建设依然会有很大的不同。

互联网企业重运营,所以产品的迭代,对日常运营的支持就会更加的频繁,适合在前台建立全职能的研发团队,以提供更紧密的支持;而交付型的软件企业重销售,前台更侧重产品销售和项目交付,所以更倾向研发统一管理,让专业的人做专业的事,同时更能有效的利用进行技术积累和复用,提升产品研发的效率。

今年我们在部分领域实行了项目带产品的策略,但是由于研发既负责项目交付,又承担产品迭代,在资源紧缺的情况下,两边可能都会耽误,项目交付不能保证,产品研发也不顺畅。

这算是一次小小的教训,如何改变呢?如果团队规模较大,要把项目交付团队和研发团队做一个分离,各司其责,相互协同又不要相互影响。

没有匹配的研发组织,如何实现高效的产品研发

对于TO B的企业,我们需要从能力线、产品线以及项目线上来建设技术团队,通过CTO或技术委员会保持在跨组织的技术管理,以保证技术战略、技术规范、开发流程的有效统一。

三、不可忽视的康威定律

很多老板看到中台架构很好也请来供应商帮着搞,但是就是搞不好,就感觉阿里宣传的中台是不是吹牛逼。

其实阿里的中台也不是一帆风顺的,没有组织的变革,没有自上而下的强力推动,也是寸步难行。

在钟华的《企业IT架构转型之道》一书中,他形象的给我们展现了,承接中台架构的业务组织–共享业务事业部的发展史,又一次告诉我们IT架构和组织架构密不可分的关系,这就是有名的“康威定律”

没有匹配的研发组织,如何实现高效的产品研发

康威定律是马尔文·康威1967提出的:“设计系统的架构受制于产生这些设计的组织的沟通结构。”

通俗的来讲:产品必然是其(人员)组织沟通结构的缩影。

更直白的说,你想要什么样的系统,就搭建什么样的团队。

如果你的团队分成前端团队,Java后台开发团队,DBA团队,运维团队,你的系统就会长成下面的样子:

没有匹配的研发组织,如何实现高效的产品研发

相反,如果你的系统是按照业务边界划分的,大家按照一个业务目标去把自己的模块做出小系统,小产品的话,你的大系统就会长成下面的样子,即微服务的架构。

没有匹配的研发组织,如何实现高效的产品研发

架构不仅仅需要技术,在大公司尤其需要政治,所谓的架构的政治;所以康威定律一定是要熟悉并合理使用的第一定律,想想那些大公司的产品形态和他们的组织关系,就会发现这么有趣的联系。

没有匹配的研发组织,如何实现高效的产品研发

所以一些传统企业想要数字化转型,如果还是依托传统的信息部这样的后台组织去搞,十有八九很难成功,需要一个全新的数字化部门大胆的改革。

同样作为产品研发,我们如果既要降本增效,又想保持创新,没有合理的匹配的研发组织,那也只是一场梦而已。

场景一:在产品设计的过程中,有的地方对于可实现性或难度拿不准需要向研发请教

在此种场景下,有没有遇到研发答非所问,甚至在你描述多遍的时候对方依然不能理解你在问什么,或者在双方讨论问题的过程中,发现双方讨论的问题根本不是一个点。

此时你可能开始怀疑对方的能力了“这么简单的问题你怎么理解不了呢?”,而对方呢可能想的是“卧槽,你到底想说啥呢?”

场景二:研发在开发的过程中对需求产生疑问或者质疑向你请教

工作中我经常见到的情况是,产品/交互同事正在忙着手头工作,研发忽然过来:

研发:你这里逻辑怎么能这样出呢/你这里交互做的不好

产品/交互:(看了一下)哪里有问题啦?是你自己没理解吧

研发:你自己没想清楚吧~balabala

……

研发:好!就按照你这个做,后续遇到问题不要找我改!

产品/交互:那就按照这个做

最后就是争吵一番,浪费了时间、增加了矛盾、问题没有解决。

以上的问题个人曾经也遇到过,但是在长期的工作与反省中,自己总结了一套我自己使用起来比较行之有效的方法——控制情绪,三步聚焦问题,分享出来,希望对经常遇到此问题的新人产品经理有所帮助。

控制情绪

绝大多数情况下,产品经理面对的研发都是比较耿直型的,说话不太会顾及别人感受,但是其实人都是比较好的,如果不是因为工作,你会发现和研发处朋友特容易。

但是在日常的工作中身边遇到这样的场面,多数会变为情绪上的对抗,竭力证明自己是对的,从而争吵、矛盾上升,此时控制好情绪是第一步要做的。

好了,不逼逼了,咱也不摆道理,如果你被研发怼过,或者研发说了你觉得过分的话让你感觉感情受到了伤害想要直接怼回去时候,跟我默念控制情绪口诀(可视个人情况修改)。

  • 比较正经的:掌控情绪,才能掌控局面
  • 比较不正经的:身为一名产品爸爸,我要以包容天下人为己任

三步聚焦问题

三步即交代清楚(问清)背景、共享知识、聚焦(解决)问题。

场景一:向研发请教问题(以输出优惠券需求为例)

第一步:交代清楚背景

探讨问题前,一定要尽量同步问题背景,让双方的话题都有一个边界框架,如果遇到场景二情况其实比较方便,因为需求是自己出的,直接问一下是哪个项目、哪个需求、什么功能出了问题等。

如果是场景一的情况,因为研发事先不知道需求背景,需要尽量说清背景:

XX大大,我现在在做一个优惠券需求,这个优惠券呢是提供给运营使用的,主要目的是用来做一些活动,其中用户领取途径有以下几种:

1.在活动页面,用户点击按钮领取

2.运营直接向指定用户发放

3.运营给一个领取码,用户通过我们提供的页面输入兑换码兑换

4.其他balabala

而且领取的限制规则有所不同,比如在活动页,可能只能抢到某一种优惠券、也可能抢到n种优惠券里的一种。

第二步:共享知识

共享知识其实就是在提问之前将自己已经有的思考说出来,或者说是将对方之前的思考问出来。

如遇到场景一情况可以大致这样说:

我现在比较纠结是该将优惠券的领取方式放在优惠券属性里还是将领取方式放在调用规则引擎里,我直观的感觉吧应该是放在调用规则引擎里,因为这样配置就会更灵活一些。

比如遇到活动场景会在N个券模板中随机给用户发一张,老户激活需要一次给多张,这样可以通过调用规则引擎层引入多个优惠券模板。

但是如果中间加入调用引擎层,就会涉及一个问题,引擎定制规则,如果有的活动有特殊的规则,那也比较麻烦。但是如果每个活动都去单独写使用规则又会造成重复开发,我在网上也看了相关资料balabala(就不阐述了,总之是将自己已有的知识尽量共享出来)

当背景与知识已经说清楚,总体上对方已经和你同步在一个频道上了,当然在与对方对话的过程中可以通过观察对方的表情、动作等来判断对方是否已经听明白,可以通过问答形式问一点细节几乎不太会有多少问题。

第三步:聚焦问题

当背景与知识已经说清楚后,聚焦问题已经是一件很容易的事情。

基于以上,我想和你讨论一下,我简单列一些常见的运营场景,我们看看能不能将领取规则抽取出来,做成动态配置,以方便后续高效使用。

场景二:研发向你询问产品相关问题(以优惠券方案输出后研发提问为例)

例子还是举上面那个例子,假设当时和你讨论的研发与实现的研发不是同一个人,当前实现的研发对你做的中间调用规则引擎层提出质疑,觉得这样太麻烦。

第一步:问清背景

在这种情况下相对来说简单,因为需求或者交互是自己出的,只需要询问是哪个项目下、哪个需求、哪个功能点即可,但是还是要强调下一定要控制情绪、控制情绪、控制情绪。

不好意思,我正在思考其他问题,思维还没转过弯来,没有太明白你所说的问题是什么地方,你可以再具体说一下吗?

这里有个小技巧就是将没听清的问题归结为自己,而不是归结为对方没说清楚,不太好的示范可能是:

你能不能把话说清楚点,忽然来这么一下,我怎么知道说的是哪里?

第二步:共享知识

此时与场景一不同的地方是,需要先引导对方共享知识,然后根据对方思考背景及提出的问题点做具体回答。

此时对方有可能说的是对的,是我们之前没有思考到的点(如规则引擎有些场景或者问题我们没考虑到),也有可能是对方没有考虑到的(如觉得调用规则引擎没用)。

一般比较好的沟通做法:

产品:嗯,你觉得它没用肯定是有自己的思考角度可能是我没考虑到的,你可以说说你具体是怎么想的吗?(引导研发共享知识)

研发:如果一个新的调用规则引擎被创建,限制每个用户只能领取一张券,但是如果这个引擎被A活动引用了,甲参加了A活动,后来又被B活动引用了,甲又参加了B活动,那不是就领不了券了

产品:对,你说的不错,的确会遇到这样问题。这个问题之前我也考虑到过,后来和XX讨论了这里的细节,解决方案是balabala(共享自己的知识),在文档2.3.4里有具体说明,可能是我过需求的时候没有强调这个地方,你在帮忙考虑一下这样是否可行

不太好的做法可能是,当研发很直白的否定方案,产品会觉得心理不舒服,常见的不太好的谈话可能如下

产品:哪里没用啦?你有没有想过这个做出来能节约后续的开发人力,balabala

这样通常会说了一大堆,然而对问题并没有帮助,可能所有的对话都是围绕怎么反驳研发的那句“没用”,但是具体的研发问题点在哪里都还没有搞清楚,最后很可能争吵很久问题没有解决。

由于上面所举得例子是已经有解决方案了,而且是事先考虑到的问题,所以不再会有继续讨论解决问题。

最后的话

其实在写这篇文章时候是比较纠结的,纠结到底要不要写,因为从我个人感觉来说,这个应该是比较基本容易解决的事情,对产品本身来说营养价值也不高。

但是因为在我的日常工作中,时长会出现产品与研发因为一点小问题而剑拔弩张,所以觉得可能会有产品会遇到此类问题,希望这篇文章能够帮助到一些产品新人。

如果有说的不对的地方,可以留言讨论,轻喷……

推荐阅读《关键对话》,百度搜索鞠远华老师视频“高效沟通十三招”。

文章由PM28网编辑,作者:海阁,如若转载,请注明出处:http://www.pm28.com/4345.html欢迎投稿

联系我们

在线咨询:点击这里给我发消息

邮件:403567334@qq.com

工作时间:周一至周五,9:30-18:30,节假日休息