GTLC全球技术领导力峰会·上海站,首批讲师正式上线! 了解详情
写点什么

为什么技术同学需要有更多的业务思考?

2020 年 8 月 31 日

为什么技术同学需要有更多的业务思考?

技术同学的三个阶段

首先,根据技术同学对业务的理解程度,可以划分为 3 个阶段。


第一阶段 PRD 翻译机

这一阶段的技术同学,PRD 说什么做什么,只要验收通过,那么他们就觉得任务就算圆满完成了。不关心需求背景,不关心需求价值,不关心背后业务逻辑。对于初入职场的同学,能把任务圆满完成,已着实不错。


不过处于这一阶段的技术同学也最容易被替代。


第二阶段 理解业务,选择合适的技术方案

这个阶段的技术同学开始去理解业务了,会去关注业务架构,在理解业务的基础之上去选择合适的技术架构。通过深入理解 PRD,和产品经理沟通,能够在完整了解业务价值及解决思路的基础上,准确判断出实现的可行性和技术方案,在开发时间紧张的前提下和 PD 及时沟通砍掉非必要的功能,抓紧时间保障完成最小化可行产品(MVP)。


大部分技术同学应该都在这个阶段了,而且是非常重要的角色。


第三阶段 主动的业务思考,为业务献计献策

首先每个人不管角色是什么,都可以有主动的业务思考。


而技术同学有这个优势,本身我们了解业务,再者了解数据,那么在这个基础去做业务思考,是有很好的基础的。所以,驱动业务对于技术同学来讲,看起来是个突破,其实是很自然的事情。


主动的业务思考指的是主动产出新的业务点子,有大致的产品方案,包括背景、价值、可行性分析、长期规划等。然后通过积极与产品经理充分沟通,相互碰撞想法,最终由产品经理或者技术同学产出完整的产品方案。最终,再由技术同学推动落地。


这个阶段其实不算是独立的阶段,和第二阶段是并存的。作为核心开发,特别是技术团队的管理者,尤其需要拥有第三阶段的能力。


驱动业务的探索

在 2020 H1 阶段,我们团队也进行了一些探索,去贴近业务,去换位思考,去探索技术同学有业务思考后能做什么?如何拥有更多的业务思考?


一、探索需求

首先需要明白,用户的需求不是凭空想象的。用户的需求来源于不断地探索。那么,作为技术同学如何去探索需求?


比如有赞是是一个商家服务公司,我们帮助每一位重视产品和服务的商家私有化顾客资产、拓展互联网客群、提高经营效率,全面助力商家成功。那么我们首先就要去贴近商家,同时还要去了解消费者。


1.我们去接触直面商家的一些角色,比如销售、运营、服务、客满等。

在有赞,有定期的客满体验日活动,不管是哪个岗位的同学都可以报名去作为客满体验一天。这对于技术同学是非常有帮助,真真切切地感受到了商家的感受、问题、需求。


另外,我们可以主动去找产品运营、商家运营、商家服务去沟通他们了解到的商家需求、以及日常工作的问题,发现痛点,挖掘需求。


这个过程,如果你之前并不了解业务的全流程,可能需要找很多个角色才能把一件事从头到尾串起来。相比起安安心心写代码不同的是,会跟更多的人有主动交流,对于大部分技术同学,可能是比较难跨出的一步。


2.我们通过数据分析来挖掘一些需求。

比如,有赞微商城有 PC 版本和 App 版本。我们通过数据分析商家在 PC 和 App 的注册转化率,去分析所有营销应用给商家带来的 GMV,去分析 PC 和 App 的用户占比,去分析每款营销应用如果在 App 端实现需要多少成本,商家操作是否方便。


通过这些分析,去判断是否需要在移动端支持营销应用,以及支持哪些营销应用。


3.我们去采访一些愿意被采访的商家,进行直接交谈。

只有更了解商家,才能更好地服务商家。


和商家直接交谈,会有更真切的了解和感受。对于技术同学,像是打开了一扇通向新世界的大门。如果不方便直接与商家访谈,可以和产品经理一起访谈。产品经理采访商家是非常频繁的事情,在确定需求方案前,在产品上线后,都会定期进行。技术同学可以先从旁听开始,提前准备了解访谈内容和商家背景,逐渐地,还可以准备一些问题。


二、推动立项

跨部门合作的“难”,应该大部分人都体会过。每个公司都存在“部门墙”。


碰壁是常态,但是方法总比困难多。在与各业务方沟通的时候,保持低姿态,以结果为导向,只要你要推的事情足够有价值,就能争取到资源,如果你要推的事情没有那么有价值,那么也便不值得去做了。


首先遇到的问题就是,不同的部门,不同的团队,规划和优先级不一致,外部依赖的资源不确定。


1.巧妙利用 OKR(KPI)

有赞在使用 OKR 进行绩效管理,整个公司、每一条业务线,到每个人,OKR 都是公开可见的。公司、各业务线、个人,三者的关系是相辅相成的,互相在成就彼此。


所以,第一步,需要清楚知道公司目标是什么,避免在错误的方向上浪费过多的时间。第二步,如果你想做的需求是跨部门、跨业务线的,就要去关注对方的 OKR,是否有契合点。如果你想推动是事情足够有价值,不一定要有契合点。但是有契合点,会让你的推动过程更加顺利。


2.做足前期准备。

秉着不浪费别人的时间,也不浪费自己的时间的原则,一定要做好前期准备。


比如我们想推动在移动端落地营销插件。PC 端已经有几十款营销插件,但是在移动端支持得很少。那么我们首先是怎么做的呢?


我们没有直接去找营销业务的产品,因为还有很多问题需要准备。


问题一:为什么要在移动端落地营销插件?

问题二:要落地什么营销插件?哪几款?

问题三:为什么是这几款?

问题四:项目目标如何量化?


我们首先要对所有的营销插件有个了解,各个营销插件是做什么的,能为商家带来什么。我们去梳理现在 PC 端的所有营销插件,一一分析数据、实现成本、需要的资源等,出了几十份可行性分析报告。


然后我们结合了实现成本、产品价值以及移动端现状,第一轮筛选出 22 个插件,第二轮将 22 个插件根据综合优先级分成了 3 期。最终选出了最优先开始落地的一期。


然后再拿着这些结论,去找产品沟通推进。如果不提前做这些事情,那么你跟产品沟通的时候很可能不在一个频道上,更不用说达成一致。


跨部门合作,总会有很多困难。部门墙在每个有一定规模的公司都是存在的。但是方法总比困难多。虽然听起来是鸡汤,但是当真正做到去保持好良好心态,去寻求解决方案,去寻求合作的时候,就会明白确实如此。


三、项目管理

确定产品方案、启动项目之后,剩下的就是项目的管理。在有赞,技术同学可以做为项目经理去带领项目前进。这对于技术同学,是一个很好的机会。


具体如何做项目管理,这里不展开讲了。过程中,可能会遇到不少问题,比如开发过半,发现一开始需求评估不到位?期间有其他高优级项目插入,要如何做?


处理这些问题的过程中,就能慢慢体会到一个完整的项目是怎样运转的以及项目与项目之间是如何相互影响的。


通过做项目经理,可以全局地了解整个项目涉及到的各个角色、各个环节,而不再局限于自己负责的那一块。做过一次项目经理之后,再做其他项目的时候,就会明白,如果每个角色都能向前迈出一小步,这个项目就能很好地跑起来,否则就会各自很努力的样子,到最后还是延期的延期、质量不好还是质量不好。


这里分享一个小故事,看完估计就都明白了。


一个人去俄罗斯旅游,他在逛街的时候发现两个很奇怪的人:一个人在前面挖坑,一个人在后面用铲子把挖出来的泥土填进去。这个人觉得很奇怪,就去问他们在干什么。他们回答说,他们在种树。这个人觉得更奇怪了。这两个人解释说,负责放树苗的那个人生病了,没有来。


四、数据分析与迭代

每个项目都有一个项目价值目标,根据目标可以拆解出数据指标。在项目开始之初,就需要确定需要通过哪些业务数据或者埋点数据来评估项目的价值。然后,在技术方案中需要考虑如何获取这些数据,在上线后建立数据看板,及时关注。这里推荐一下《精益数据分析》。



上线之后,需要及时关注数据情况。数据分析包括描述型分析(发生了什么)、诊断型分析(为什么会发生)、预测型发生(接下来会发生什么)、指令型分析(下一步怎么做)。那么数据指标要怎么确定呢?优秀的数据指标的特征包括:


  1. 可比较:不同时间段、不同用户群体,比如本周转化率比上周高 2%,本周转化率为 5%

  2. 可理解:简单易懂、避免误导、业务解释性,比如日活的用户指的打开页面还是需要登录?

  3. 是比率:可操作性强、可以比较、反映关联性。


做完数据分析之后,要及时和业务方反馈数据结论,沟通后续优化方向,以取得更大的业务价值。


真正去 owner 一个业务,跟去完成一个项目需求,最大的不同在于 owner 的时候不仅仅是考虑当前项目的需求,还要考虑这一块业务的长远发展。有始有终,不断迭代。


收获


这半年,我们本职工作是移动开发,在较好地完成本职工作的前提下,我们尝试去主动推动业务落地。在推进业务的过程中,我们扮演了各种各样的角色,包括产品经理、项目经理、测试、客满等,接触了日常不会接触的各种角色的同事,尝试了非常多的之前没有做过的事情。


除了新鲜感以外,更重要的是多了很多之前没有的思考。真切地了解了一个业务是如何运转的,除了产研之外,销售、运营、服务都在扮演着非常重要的作用。


在日常工作上,我们不再仅仅停留在实现当前的项目,还会去思考需求的合理性、扩展性、可维护性等。做项目,也不再止于上线,还要持续关注上线后的价值体现,不管这个项目是我们发起的,还是产品经理发起的。上线只是价值体现的第一步。


很多时候,技术同学会迷茫,会无所适从,那可能只是因为不够了解业务。当足够了解业务后,就会跳出技术去思考全局,才能看清楚自己可以做哪些更有价值的事情。


本文转载自公众号有赞 coder(ID:youzan_coder)。


原文链接


为什么技术同学需要有更多的业务思考?


2020 年 8 月 31 日 14:061741

评论 1 条评论

发布
用户头像
这个很高,搞技术的要涉猎一些业务,搞业务要学习一些技术,打通不同的壁垒,往往这样的通才能走更远。
2020 年 09 月 01 日 14:17
回复
没有更多了
发现更多内容

架构师训练营第一期-第一周学习总结

卖猪肉的大叔

作业一:食堂就餐卡系统设计

静海

UML

微服务架构

架构师1期week01总结

FG佳

架构师训练营第一周命题作业

一马行千里

极客大学架构师训练营

架构师训练营第一期-第一周课后作业

卖猪肉的大叔

第五周总结

【第一周】课后作业

云龙

极客大学架构师训练营

食堂就餐卡设计

Bear

极客大学架构师训练营

架构方法

Eddy.何

极客大学架构师训练营 命题作业

合并两个单向链表

食堂就餐卡系统设计

L

第一周架构之UML

若水先生

极客大学架构师训练营

作业二:第一周学习情况总结

静海

Python+Appium运行简单的demo,你需要理解Appium运行原理!

清菡

第八周总结

潮汕之旅第一站

熊斌

摄影 游记

架构师训练营1期作业-学习总结

道长

极客大学架构师训练营

食堂就餐系统

focus

第一周学习总结

月殇

极客大学架构师训练营

架构师训练营Week1 - 学习总结

极客大学架构师训练营

食堂就餐卡系统设计

jizhi7

极客大学架构师训练营

【架构师训练营】第一周作业:画图

MindController

架构师

【架构师训练营第 1 期】第一周作业

知鱼君

极客大学架构师训练营

第10周总结

第一周作业

kevin

极客大学架构师训练营

第一周 架构方法学习总结

L

第一周命题作业

月殇

极客大学架构师训练营

性能测试总结

架构师训练营第一周作业 食堂就餐卡系统设计

帅到没朋友

极客大学架构师训练营

架构师训练营第一章作业一:就餐管理系统UML图

zenfery

极客大学架构师训练营

DNSPod与开源应用专场

DNSPod与开源应用专场

为什么技术同学需要有更多的业务思考?-InfoQ