寒冬来了,个人和组织都需要更加的高效

阅读数:2984 2019 年 7 月 29 日 19:06

寒冬来了,个人和组织都需要更加的高效

现在朋友圈里各种“互联网寒冬来临,…”、各种“*公司裁员%…”的文章,在煽动我们焦虑感的同时,确实也让我们看到了一些趋势。尽管我认为“寒冬”还谈不上,只是互联网原来太火,有不少泡沫,现在正是挤掉泡沫,修炼内功的时候。在整个行业回归理性的趋势下,动不动就加人这种简单粗暴的解决问题方式显然应该成为过去时。

那我们如何在人员相对更少的情况下,还把事情做好呢?

我认为答案是两个字:“高效”。下面我主要从产品技术层面,以我们做的数据中台和数据产品为例谈下,如何做到高效?

寒冬来了,个人和组织都需要更加的高效

高效首先对外要做有价值的事情,对内要提升研发效率。产品技术团队的需求主要来自用户 / 客户,通过产品经理来把控的,所以做有价值的事情主要是对产品经理的要求。提升研发效率,对产品技术团队更加可控,是修炼产品技术团队的内功。

一、B 端产品经理如何做有价值的事情?

1. B 端产品经理应该是“跟着业务负责人走”(听起来有点媚上)

寒冬来了,个人和组织都需要更加的高效

绝大部分 B 端产品(通用的工具除外),无论对内还是对外,都有明确的业务方。比如:我们河洛 - 供应链协同决策系统的核心业务方是供应链计划,大麦 - 商品数据化运营系统的核心业务方是商品 BU。产品经理需要问出业务负责人的愿景,好的业务负责人对业务应该是有往后 2-3 步的推断和长远愿景的。产品经理基于业务的愿景结合业务的规划,才能做好产品的规划,进行前瞻的设计,让产品有顶层的逻辑和明确规划,避免产品成为需求任务的堆积,产品经理变成项目经理,产品研发团队沦为外包。B 端产品的最核心任务是根据业务负责人的愿景、规划,联合业务专家帮助业务负责人将业务中的知识提炼出来,落地在系统中。这样业务人员就能在组织的业务知识之上工作。业务里面每个业务人员可能有自己的利益和习惯,我们做 B 端产品的时候,不是为了每个业务人员做的,满足每个业务人员的利益,而是跟着业务负责人让业务组织的知识体系化、系统化、线上化,让组织的利益最大化。

2. B 端产品经理需要“问业务需求价值”

业务负责人毕竟时间有限,主要确定方向和策略,产品大量的需求还是来自具体的业务人员。如果不能直接判断需求符合业务的大方向和策略,特别是评估出来研发成本很高的,就需要追问需求方需求的价值。比如:这个需求能降多少成本?这个需求能创造多少营收?这个需求是不是属于基础设施,后续很多其他需求都依赖它?对于大的功能需求 (涉及系统多、研发成本高),甚至需要业务方给出量化的效益,也让业务方对需求由更多的思考,让最终的优先级更加的有说服力。

3. B 端产品经理需要成为“很懂业务的通才”

B 端产品经理 (包含技术) 需要既有产品化思维、系统思维、数据化思维 (数据产品经理尤为重要),又要深入理解业务,成为通才。产技团队要成为业务的合作伙伴,不是只向业务单向获取知识。业务有的业务知识,我们有的是系统化思维和数据化思维。我们与业务沟通时进行思维的联系和碰撞,一起从业务的信息里面提炼知识,并将知识系统化、体系化。创新来自于联系,只有和业务专家一起,将不同的知识建立联系,将不同领域的知识迁移,才能做出创新的产品。

二、研发团队如何提升研发效率?

大家都知道,提升效率最根本的办法就是分工协作。那么产品技术团队如何做好分工协作呢?

1. 分工

寒冬来了,个人和组织都需要更加的高效

1). 人员上更明确的分工

当然,这个要求是基于在中后台建设不是特别完善的情况下。如果中后台建设非常完善,前台人员完全可以模糊分工,往全栈化发展。

寒冬来了,个人和组织都需要更加的高效

人员分工上以我们部门为例,对每个部门员工来说就是按照角色做自己。我们原来中台系统的产品经理是技术兼着,现在都分配了相应的产品经理;我们原来有的技术数据开发和应用开发都做,现在也都逐渐专注在自己的角色。对部门里面的每个组来说,明确各小组的职责。因为电商是有很长业务过程的,我们一些角色是按照业务过程设置,我们明确了对接个业务过程的负责人,比如:负责营销的数据产品经理,负责供应链主题域建设的数据开发。

2). 技术上更明确的分层

寒冬来了,个人和组织都需要更加的高效

解决复杂性的核心原则是关注点分离,现在我们产品技术面对的系统 (从整个业务系统集合看) 基本都是复杂问题。分层让不同的层关注不同的问题,让下层不依赖上层,让不同团队负责不同的层按照不同的时间节奏来进行演化(往往越往上的层变化越频繁)。分层后,不同团队负责不同层,让更专业的人做更专业的事情,进而提升质量和效率。分层后,越下面的层(中后台),在越大范围内共享,避免了重复建设,进一步提升了质量和效率。

做好分层,要“明确不同的层的职责”。比如 DW 层是保障核心指标在细粒度上的计算口径;基础技术层提供通用技术层,比如持久化、通信等;领域层表达业务概念,决定了系统的能力范围。

做好分层,还要明确“需求拆到不同层的原则”。比如一个数据需求,哪一部分应该在 DW 层算,哪一个部分应该在 DM 层算,哪一部分应该在统一查询处理,哪一部分应该在 app 层处理。

3). 产品上更明确的范围

寒冬来了,个人和组织都需要更加的高效

中台系统是为了更好的支持研发,整体的需求规划和落地都是产品技术团队掌控,要划清各系统之间的边界,严格控制重复建设。前台产品,因为业务场景的需求,是不能也不应该避免功能的重叠。特别是数据产品,业务系统往往根据业务过程是内聚的,但一个数据指标往往来自多个业务过程,且需要被多个业务方使用的。前台产品无法控制功能的重叠,但是要控制重复的层次,将重复控制在上层(参见上一节的分层)。

2. 协作

寒冬来了,个人和组织都需要更加的高效

分工本身只能带来局部效率的提升,如果不能很好地协作,整体的效率甚至会下降。产品技术团队要协作好,要做到以下几点:

1). 提升项目管理能力

大部分项目还是中心化管理的,项目管理者是项目团队协作的中央控制器,项目管理者的能力对项目成败的影响很大,所以项目管理者需要加强项目管理的能力。大部分单产品或单业务过程的项目,没有专职的 (也不需要) 项目经理,需要相关的项目管理者加强项目管理能力。在我们团队主要是产品经理、技术负责人、数据架构师承担项目管理者角色。

寒冬来了,个人和组织都需要更加的高效

2). 开好需求确认会

需求确认会是产品技术团队最重要的协作场合。需求确认会上,产品、应用开发、数据开发 (数据系统特色) 要真正做好交互评估、技术评估和数据评估,避免后续的返工,进度的失控。具体讲,前端开发人员要能够针对交互评估用户体验的问题,甚至给出更好的交互建议;应用开发要评估产品的功能是否符合逻辑,进而评估可行性和实现成本;数据开发要评估指标计算口径的合理性和实现成本,并确认指标的计算分别落在哪一层。

寒冬来了,个人和组织都需要更加的高效

3. 基于 (仓颉) 指标协同。

指标是数据团队各角色协作的基础。这个是数据团队特有的,不再展开。

总结一下,在互联网行业回归理性的情况下,需要更高效的工作。产品技术团队要做到高效,对外产品经理要做更有价值的事情,对内研发团队通过更明确的分工、更顺畅地协作提升研发效率。根据各自团队的特征,可以进行更加细分的方法来让组织更加的高效。

作者简介
魏文庆,现任网易严选数据技术及产品部总监。
2007 年浙江大学计算机硕士毕业后入职网易杭州研究院,从事前端开发,后历任技术主管、技术经理、技术总监。曾负责网易摄影、网易企业邮箱、易信公众号等产品开发,以及网易前端微专业。2015 年开始内部创业,孵化敏捷 BI 平台 - 网易有数,任网易有数总经理,负责产品研发和商业化。2017 年开始负责网易严选数据技术及产品部,从 0 到 1 搭建网易严选数据中台和数据产品体系。

评论

发布