技术、产品闹分家,究竟合不合适?

2019 年 5 月 29 日

技术、产品闹分家,究竟合不合适?

轻芒联合创始人兼 CTO 范怀宇此前在 GTLC 全球技术领导力北京分站上给现场参会者带来了精彩的主题演讲,本文根据现场演讲内容整理而成。6 月 14-15 日,由 TGO 鲲鹏会举办的 GTLC 全球技术领导力峰会将在上海举行。 范怀宇,轻芒联合创始人 &CTO。此前多年在豌豆荚负责从 Windows 到 Android 等各种不同产品的研发工作,经历了整个移动 app 的时代,著有《Android 开发精要》一书。


我 2009 年毕业,2011 年去了豌豆荚,2016 年从豌豆荚出来创业。我从正式入行的第一天起,就开始做移动互联网开发,主要业务是 ToC,虽然今天轻芒有一部分业务是 ToB,比如给内容创作者做小程序的服务等,但大部分时间还是在做 ToC 的产品。


我学习过不少方法论,也在团队中做了不少实践,今天希望能结合实战经验给大家带来不一样的视角。



今天我将从软件流程和技术视角出发,分享轻芒如何更多地参与上下游、产品、运营中。可能以往的分享常常会提到技术经理、技术负责人、CTO 等名词,但我今天分享的内容更偏技术线一些,不会教大家如何将一个人培养得更好,或是如何组建团队做绩效,更多的是如何保证产品落地,如何按时交付产品,让产品产生更大的价值。


对于大部分技术人来说,日常工作是混合型的,可能一部分是管理角色,另一部分是技术经理角色,甚至有一部分是高级工程师或是其他类别的角色,我们很难区分自己在每一个情境里该做什么样的事情。


项目流程


对于大部分人来说,参与到一件事情中,需要有一个合适的引导流程。现在我们在聊传统软件开发流程时,更多的是保证质量或是效率,可是我希望能更进一步地激发每个人的主观能动性,让每个人把自身的特长或能力不仅带到研发和执行环节中,在流程上发挥自己更大的价值。


那么怎样的流程更适合发挥主观能动性呢?


传统流程




上图是传统流程图,这些流程制定最大出发点是为了保证项目的执行。过去的软件研发从 1.0 到 2.0 版本需要 1-2 年的时间,在这个时间内,如何将各个环节拆解得更好,让流程执行得更有序是传统流程上做的事情。


敏捷流程



后来逐步进入互联网或是移动互联网时代,在这个时代里,即使团队将传统流程的环节做得非常好,但过了一年后,产品可能没人使用,这是为什么呢?因为互联网变化太快,传统流程跟不上步伐。


我认为传统流程和敏捷流程在环节上相差无几,只是将 1.0-2.0 变成 0.1-0.2,整个迭代周期会压缩,效率会增强沟通。敏捷流程除了保证执行质量和按时出研发效果外,更重要的是将时间压缩,能在更快地时间内释放效果、试错,然后才能知道哪些事情需要调整。


在敏捷流程里,我会更注重沟通,因为频繁地沟通会让大家的关系变得更加紧密。


一体化流程



上图是一体化流程图,从图中我们可以看出一体化流程对上下游的要求非常高,每个环节都需要按部就班来做。如果我们做的东西更复杂,那么需要团队更紧密,以便于团队彼此支撑。目前我们的执行思路是,在需求、设计、产品上线的过程中将一些流程并行;运营的角色越来越重要。


曾经有个朋友和我提到,做出好产品的人都拥有技术背景,如马化腾、李彦宏,为什么他们都能找到这些点?是否因为他们都曾经参与到产品当中?这个问题可能还有待解答,但对于我来说是一个很有启发的想法。现在我常常要求技术团队更多地参与到产品环节当中,因为很多时候技术人的视角十分独特,产生的想法和产品、运营不一样,导致大家的思维方式产生了偏差。如果我们能让技术人员去理解他们的想法,是不是可以达到不一样的效果?举个例子,有一天产品提出一个 idea, 产品告诉技术这个 idea 有多好,能帮助用户解决很多问题;如果技术懂产品,他就能告诉产品经理,这个需求是不对的,就算把这个 idea 做出来也解决不了任何问题。


对于一些创业公司、早期公司来说,很多时候一些新兴出发点能让你看到更多的机会,这些机会可能来自很晦涩的技术变更,也可能隐藏在某个平台的某次更新里或者是隐藏在技术趋势文章分析里,它代表着暴露的技术上已经变得成熟或者是有新的机会。如果能参与其中,那就更有利于我们发现类似的机会或在其中推进事件的发生。


技术经理的角色



一个优秀的技术经理应该为技术团队提供更早的反馈机会以及为产品、技术提供更多的支持,除此之外,还应该注重哪些方面呢?


新流程



因为只有拥有流程才知道从哪里出发,所以我们一定要有流程。流程主要包含 3 个部分——输入、输出和活动。上图黄色板块指的是输入和输出的部分,每个环节的输入都是下一个环节的输出,蓝色板块指的是所有技术人都会参与的部分。


通过这个流程可以让大家很明确每一个需求的来源,可能是通过某个领导拍脑袋的想法、用户反馈或数据运营的效果。这样可以通过了解不同的渠道,分析出我们将服务什么样的人,他们具备有什么样的特点。


使用好流程



流程固然重要,但它只是一个工具,我们应该更注重输入和输出的部分,因为它让产品上下游信息更透明化,这也是为什么我们让每个人都参与到流程中的原因。每个人都有机会参与到活动中,即便不参与活动,也可以非常轻松地拿到所有上下游信息以及所有的输入和输出信息。只要技术 Leader 保证信息是透明的,那么当你遇到疑问时,都可以通过工具或 Paper 实时提问,相应负责人或产品会出来回应你。


在输入、输出过程中,我们一直强调,不需要文采有多华丽,而是需要有一个详细的结构,能清晰的把重要部分描述出来。比如当我们已经做出产品时,我们需要明确目标用户是谁;做了很长时间的产品,能够快速知道我们以往的设计方案是什么等等。每一个环节都要直接体现需求,这需要所有人共同努力才能做到。


在工作中,我们应该尽可能扮演好自己的角色,只要进入了下一个环节就应该尊重需求文档,相信它是完整、可靠的。这个点看上去非常小但却非常重要,它从本质上体现了你相不相信团队。这不是说每个人参与到其中就可以,而是需要你与团队一起运作。


决策职责分配


  • 发行者

  • 执行者

  • 支持者

  • 决策者


在流程里,往往会有人没有理解自己在流程里的定位,那么你知道每个职责的定位是什么吗?


举个例子,在参加评审时,我们需要了解自己是以什么样的角色进入的。老板的角色是决策者吗?不,决策应该是由项目决策人来做,TL 这个角色背后代表整个团队,他一定是项目中技术背景最深的人,可以代表技术团队的观点,能给需求提供技术上的建议、约束和机会。


除此之外,TL 还应该扮演好一个发起者,由发起者做技术评审,技术评审的重点应该是我理解的需求。可能在评审的过程中,我理解的需求可能出现了遗留系统保持问题,那么应该由执行者负责。最后产品上线,再回头看数据,我们就可以发现流程的价值,它对产品能起到事半功倍的作用。



除了找准定位之外,我们还需要学会表达。我们经常说程序员用代码说话,但如果你对团队、对自己有更高要求,那你一定要学会其他的表达方式。比如原来注释写了很多的东西,要求大家把注释写成文档的形式并附上链接。有的人可能会说文档很难表示,是否可以在聊需求时提前写脚本,那么在聊的过程中就可以不用说话,直接把脚本展示给大家。


总的来说,我们应该注意 3 点:


  • 合适的流程是重要的,这样才有透明的信息和参与的机会;

  • 流程中有清楚的输入输出是重要的,过程和形式是次要的;

  • 技术经理应当参与全部环节,但不是决策全部。


技术评审


回到更具体的实践环节,刚才我提到环节里的具体操作以及它的价值,我们再看看对于技术来说最重要的环节——技术评审。一些从豌豆荚出来的人管理公司时,都统一用豌豆荚总结下来的方法论。我们在尝试很长时间后,得出了不断精简的技术设计模板。


一般在项目在开始前,我一定会让所有的设计人回答 3 个问题:


第一个问题是你的需求是什么。通过这个问题,可以看出他的需求有没有经过讨论、需求来源是否可靠。


第二个问题是技术上如何定义需求,也就是写技术文档。这个问题一定需要写清楚,之前我们在做技术评审时,通常是计划要讨论非常复杂的技术问题,但最后可能 2 分钟评审就结束了。这是因为可能他的前两个问题没有回答好,致使我认为他根本没有理解需求。


第三个问题是有哪些可行的方案。在能回答前两个问题的基础上,剩下的就要考虑约束技术本身以及可行的方案了。



上图是大概的讨论框架,可能一个需求文档需要讲述 3 个用户故事,接着我根据用户故事提出设计要点,通过设计要点决定技术方案。



上图是我提到的一些示例,左边是技术方案,输入、输出里是我们重视的需求翻译或对应的需求翻译,接着是技术和技术之间的沟通,用什么样的语言或方式都可以,只要是通用的、熟悉的东西就好。右边是我们的备注,注释了很多技术指标,我会在备注里增加大量的技术视角来确定需求。


运营分析


技术数据报表


一般数据分为两个部分,一是产品上线后,所有运营人员需要看的线上数据评估,通过观察数据,评估需要改进的方向;二是没有进入运营系统、埋没在业务里的数据,可能是业务日志等,但这些数据具有极大的价值,它能够发现真正的产品问题或产品隐含的需求。比如回访很好,但你在观察后会发现这些回访都是来自同一个 IP 或有很大部分具有虚假的成分,那么我们可能需要挤掉”水分“后才能看见真实的情况。


提供可运营能力的介绍


除此之外,我们还可以通过数据,确定产品上线后用户要看什么内容。举个例子,我们可以用第三方的数据系统得出的结果来制定目标,尝试着跑数据,这时跑出来的数据结果可能对某些方面有借鉴意义,但不会提供决策。


技术团队如何更好地参与产品


那如何带领技术团队更好地参与到产品中呢?我认为,首先与传统流程相比,我们需要让各个环节更紧密、细致。大家要坚信,技术团队可以为产品创造更大的价值,很多时候有价值的点都是从技术视角看到的,提炼出来后才变成一个产品功能。


其次,我们需要把所有信息透明化,信息不透明会导致产品效果大打折扣;


然后,我们可以拟定相应的流程。流程中最重要的是把所有人带到设计和运营中,释放大家的主动性。


再次,我们需要在合适的场合做合适的事情并相信团队,另外也要积极地提供自我认知和想法。


最后,对于个人来说最重要的是尽可能地参与其中、提升非代码的表达能力、多与他人交流。


以上就是今天分享的全部内容,谢谢。




技术管理的干货还没看过瘾?没关系,2019 年 6 月 14-15 日, 由极客邦科技旗下 TGO 鲲鹏会主办的 GTLC 全球技术领导力峰会将正式在上海举行,我们精心策划了技术、思维、战略、管理、视野及领导力等六大专场,并邀请行业内最有话语权的大咖加入讲师天团阵营,他们将通过体系化、有洞见的分享来帮助技术您成为一名全能型技术人。


TGO鲲鹏会,是极客邦科技旗下高端技术人聚集和交流的组织,旨在组建全球最具影响力的科技领导者社交网络,线上线下相结合,为会员提供专享服务。目前,TGO 鲲鹏会已在北京、上海、杭州、广州、深圳、成都、硅谷、台湾、南京、厦门、武汉、苏州十二个城市设立分会。现在全球拥有在册会员 800+ 名,60% 为 CTO、技术 VP、技术合伙人。


会员覆盖了 BATJ 等互联网巨头公司技术领导者,同时,阿里巴巴王坚博士、同程艺龙技术委员会主任张海龙、苏宁易购 IT 总部执行副总裁乔新亮已经受邀,成为 TGO 鲲鹏会荣誉导师。


2019 年 5 月 29 日 07:004511
用户头像
刘家宇 InfoQ 编辑

发布了 176 篇内容, 共 42.4 次阅读, 收获喜欢 247 次。

关注

评论

发布
暂无评论
发现更多内容

计算机网络基础(九)---网络层-内部网关路由协议

书旅

计算机网络 网络协议 操作系统 计算机基础

工作总结

Arthur

架构师第七周学习总结

小蚂蚁

SpringBoot分布式验证码登录方案

Bruce Duan

验证码 Kaptcha

作业1

东哥

极客大学架构师训练营

总结

ruettiger

报销流程太慢太复杂?区块链技术引入票据系统效率翻一倍

CECBC区块链专委会

数据共享 电子票据 优化业务 可信体系

【week07】作业

chengjing

秒懂云通信:如何用阿里云平台发短信?

巨侠说

性能测试

考尔菲德

MySQL常用函数

Bruce Duan

mysql常用函数

《深度工作》学习笔记(1)

石云升

读书笔记 专注 深度工作

第7章总结

武鹏

【研报下载】InfoQ《2020中国技术发展白皮书》重磅发布

InfoQ写作平台

写作平台 InfoQ 白皮书 研究报告 活动专区

阿里官方 Redis 开发规范

Bruce Duan

redis Redis开发规范

Kubernetes 1.0 发布刚六周年,IBM 却想招 12 年经验的

神经星星

程序员 Kubernetes 云原生 招聘 ibm

【DevCloud·敏捷智库】如何利用故事点做估算

华为云开发者社区

敏捷 敏捷开发 需求 故事 华为云

架构师培训第七周练习

小蚂蚁

架构师训练第七周

邵帅

通过双 key 来解决缓存并发问题

Bruce Duan

缓存穿透 缓存并发 双key解决缓存并发

一周信创舆情观察(7.13~7.19)

统小信uos

数据库 舆情 芯片

全国第一枚企业区块链电子印章诞生

CECBC区块链专委会

萝卜章 区块链印章 全流程上链 e签宝

架构师训练第七周总结

邵帅

【week07】总结

chengjing

JAVA已过气?中俄大佬对话告诉你俄罗斯最受欢迎的编程语言是什么!

华为云开发者社区

Java 开源 程序员 Lambda 编程语言

你只加了两行代码,为什么要花两天时间?

Yukun

程序员 debug bug

第7周作业一

ruettiger

架构师训练营第七周作业

Bruce Xiong

架构师训练营作业-web性能压测示例代码

superman

极客大学架构师训练营

埋点全解析,你最关心的可视化埋点在这里!

易观大数据

性能压测工具

武鹏

技术、产品闹分家,究竟合不合适?-InfoQ