技术人员怎样提升对业务的理解
技术服务于业务。
一个技术人员想要走得更远,不能仅局限于技术,需要对自己所从事的业务领域有不断深入和全面的理解。
所谓业务领域,就是大家平常自我介绍,不会仅简单说我是搞C++的,我是搞JAVA的,而是游戏后台C++,广告引擎C++,电商后台JAVA,大数据JAVA,这里面的游戏/广告/电商/大数据,就是大的业务领域,平时我们接触到的,应该是业务领域里面更小更具体的业务。比如说广告,有展示广告,搜索广告,feeds流广告,而且这些业务(领域知识)还在不断变化和演进。
产品经理(产品专家,高级产品专家,资深产品专家,产品总监)不断地思考业务的发展,然后把这些思考转换成一个个需求,然后一般以项目的形式提给技术人员,期望对产品的思考能快速落地实现,并尽快在用户那里得到使用和反馈(以及分析数据)。
对于技术人员而言,可能很多时候都处在接产品需求,分析需求,考虑/撰写技术实现方案,排期,埋头吭哧吭哧干活,赶在deadline前上线,收工,周而复始的这样一个流程中。
久而久之,我们处于这样的循环中而不自知,变成了一个需求实现机。虽然对于技术人员来讲,最重要的还是技术,主要关注点在系统架构、系统稳定性、系统可用性、系统运维、快速迭代能力、流量峰值等方面,但就像我们前面说的,要想走得更远,就需要对业务有更多的理解(和把控)。
最近对于技术人员怎样提升业务sense(加深对业务的理解)有了一些输入和思考,在这里分享给大家。
一、关注需求背后要解决的业务问题,而不是产品经理的需求
很多时候产品经理提过来的是解决方案(已经把待解的业务问题做了自己的理解,转换成了自己认为最合适的解决方案),而不是原始的待解决的业务问题。
技术人员需要自己找到原始的待解决的业务问题,自己去理解和分析问题,从技术的角度考虑,评估产品经理给出的解决方案是否是最合理/最适合的,如果不合理/不合适,那么就给出自己认为最合适的解决方案。
拿到一个需求的时候,一定要自己先做一个基础的判断,接收到的是一个待解的业务问题,还是一个解决方案。
从事技术开发的人要杜绝的,是接收到一个需求(解决方案),就立即开始评估工作量、排期,然后吭哧吭哧把活干完,上线。然后,下一个(需求)。
举个例子。
产品经理提了个需求给技术人员,要求建造一部梯子。需求很明确了,梯子需要使用什么材料建造,长度要求多少,宽度要求多少,需要能承受多少重量。
技术人员拿到这个需求,就开始评估大概需要多少材料,需要多少建造工期和测试工期,然后就开工了。
其实我们应该停一下。“建造一部梯子”是一个解决方案,而不是一个待解的业务问题。
不妨问问产品经理梯子是用来干什么。用来更换屋里中央吊灯的灯泡的。为什么要换灯泡?因为灯泡不够亮,白天屋里太暗了。所以要解决的业务问题是屋里的照明问题。
那不用费劲造梯子了,说不定我们把厚厚的遮光窗帘掀开,屋里就亮堂了。喏,不用浪费时间和财力造梯子了,你happy我happy大家happy。
二、技术人员要有业务好奇心
最近听到一个有关技术人员的观点,觉得很有意思,因为我一下子就被说中了:给技术人员一个deadline,他所有的精力/注意力/付出全部都集中在deadline上,整个思维都集中在怎么在deadline前把项目完成上线。
我自己脑补了下:一条狗,不论它之前在做什么,你只要让它注意到你手里的肉骨头,它的眼神和精力就会集中在这个肉骨头上,不论你是把肉骨头高举,还是把它扔出去。deadline就是技术人员关注的肉骨头。
全力关注肉骨头好像是一种本能,但是人需要克服本能才能获得更多的进步和成长。
参与到项目后,不能只是评估工作量、排期、kickoff,然后就盯着deadline赶工和快速收工。要对技术方案之外的业务有好奇心,在保证项目按期保质完成的基础上,花时间去了解需求背后的业务问题和业务变化,扩展自己对业务认知的版图,加深自己对业务的理解。很多项目,一般涉及到多个团队/部分,平时难得见到,正是沟通和了解自己所负责工作之外的好时机。
人与人之间最大的差别是思维方式。只有思维方式持续不断升级,我们才有可能站得更高走得更远,与诸君共勉。