跟产品一起出需求的开发才是好开发

Posted by ZY on September 8, 2019

1、格鲁夫 + 德鲁克 = ?

格鲁夫在他的书中提到一个观点:

经理人的产出 = 他直接管辖部门的产出 + 他间接影响所及部门的产出

——《格鲁夫给经理人的第一课》

那如果你不是一个部门的 leader,你没有直接管辖的部门呢?

德鲁克在他的书中提到另一个观点:

在一个现代的组织里,如果一位知识工作者能够凭借其职位和知识,对该组织负有贡献的责任,因而能实质地影响该组织的经营能力及达成的成果,那么他就是一位管理者。

——《卓有成效的管理者》

在物理层面的组织层级结构上,你可能并没有直接归属你管理的员工,然而,只要你在组织中,你就可以影响到其他人,从而影响到整个组织的绩效,你就是管理者。

把格鲁夫和德鲁克的观点,合起来,不难得出:

一个员工的贡献 = 他对公司的直接贡献 + 他通过影响他人间接给公司带来的贡献

直接贡献,很好说,就是我们日常做的大部分工作,比如给一个需求写技术方案、开发代码,需求上线后,用户在上面用的很 high,背后跑的都是我们写的代码,这就是直接贡献。

间接贡献,比如产品过来找你导数据,你给他导出来了,他根据这些数据,分析一些用户的行为习惯、使用情况,然后去优化和决策后续的产品规划,这是你的间接贡献。

绝大多数人,都专注于直接贡献,因为它直观、可见,实实在在就是我们做的事情;

而间接贡献呢?很多人不会 care,没有人会把帮产品导数据,写到自己的升职报告中。

2、团队意识

自私是天性,每个人都为自己绩效着想,这无可厚非。

但是你的绩效,到底是怎么来的?

你的绩效 = 你对组织的直接贡献 ?

是这样吗?

想想看,你是一个优秀的工程师,你的代码写的无可挑剔,你的技术方案设计的天衣无缝,具有极强的弹性,支持后续产品迭代的灵活发展,产品你爱怎么玩你都支持 ……

然而,产品上线后,被用户吐槽的体无完肤;这一整年,公司不断亏损,客户不断流失 ……

你的代码写的再好,又有何用?

所以:

你的绩效 = 你的直接绩效 + 团队绩效 + 整个组织的绩效 ?

不对,应该是:

你的绩效 = 整个组织的绩效 + 团队绩效 + 你的直接绩效

你没看错,我只是换了个顺序。

先有的组织的绩效,才有的个人绩效,如果站在 leader 的角度换位思考,很容易明白这个道理。

组织垮掉的时候,没有人会去看你写的代码有多漂亮,加了多少天班,熬了多久的夜。

没错,升职报告里,你可能不会提到对组织的间接贡献,但是如果没有高绩效的组织,压根就没你写升职报告的机会。

这就是「团队意识」。

3、员工影响力模型

所以,你的间接贡献,其实是在间接的帮助公司成功的同时,也间接的帮助你的直接贡献,发挥最大的价值。

你间接影响的同事,可能是同一个团队的,比如你给 leader 提了一个管理方式上的反馈、你跟产品一起头脑风暴分析需求,也可能是其他团队的,比如你分享了一个效率提升的工具。

你所做的这些,最终都会通过他人,间接的提升了组织的绩效。

这就是「员工影响力模型」:

每天的任务清单里,有直接贡献类的任务,也有间接贡献类的任务,到底选择哪些任务优先去完成?

格鲁夫提出了「杠杆率」的概念,如果花十五分钟的时间,和产品一起分析好需求,能够让这个需求更有价值,更能满足用户的需要,那就应该控制住写代码的冲动。

能够跟产品一起出需求的开发,才是好开发。