你好,我是白海飞。今天讲职业规划的第二篇:程序员后来都去干啥了。

我刚开始工作的时候,每次上下西二旗地铁站,看着那么多人背着电脑包,眼神炯炯,脚步匆匆,心里就想,每年都要有更年轻的人挤进来,我们这些程序员将来去干啥呢?

如今十多年过去了,稳中求进的西二旗都成了程序员神往的圣地,看看我身边的小伙伴们,有人跳到别的大厂发展成总监,有人去互联网创业做了CEO,有人进了银行,有人改行做了餐饮,有人搞起自媒体成了大V……

但是大多数人,都像我一样,还在程序的世界里摸爬滚打。以我们团队为例,十多年来,从十几个人,发展成200多人的全球跨职能团队。其中,我们的领队成了全球商务系统的总负责人,汽车制造专业的程序员成了资深架构师,测试出身的小姑娘成了业务大拿,还有更多的人,一直坚守在技术岗位上,成了所在领域的专家,推动着客户成功,带领着团队成长。

那么,对于没有选择创业、没有转行的这大多数程序员来说,在软件产品团队内部是怎么发展的呢?这些角色的发展空间如何?你怎样才能判断自己适合做哪个角色呢?

好,在前一篇我介绍了职业规划的愿景和小目标,今天我们就把眼光聚焦在软件产品团队的几类角色上,以便帮助你结合自己的情况,规划个人发展方向。

软件产品团队的角色划分

简单地说,软件开发的工作是编写程序为用户服务。如下图所示,在这个领域,一端是用户,另一端是技术、设备等资源,中间是产品团队负责连接。用户想满足自己的需求,就需要产品团队,把资源加工成可用的软件或者服务,递交给用户,甚至负责运维,满足用户持续的使用。

我们在上图中间画一条分割线,把软件产品团队除了管理人员,一分为二,靠近用户一端的这组角色,包括产品经理、业务分析师、业务运营等职位,作用是确保产品功能体现客户价值,也就是“做正确的事”,这组角色是业务角色;而靠近技术资源一端的这组角色,包括架构师、开发、测试和系统运维人员等,负责高效高质地做出产品,也就是“正确地做事”,这组角色是技术角色。另外,在这两组角色之外,还有一组管理角色,包括项目经理、部门经理等职位,负责业务战略、项目执行、团队管理等。这样一来,我们就把软件产品团队的角色分为三类:业务角色、技术角色、管理角色

虽然这三类角色的目标都是为用户递交高质量、高价值的产品服务,但各自有明显不同的关注点,他们的思维模式也不一样。为了让你更清楚地了解他们的不同,我举个例子。比如我们让这三类人分别解释一下“圆”这个图形:

你看到了么,技术角色关注的是设计实现,业务角色关注的是功能价值,而管理角色关注的是质量、过程控制和风险。下面我们一起详细讲讲这三类角色。

1. 技术角色

首先说技术角色,它包括开发、测试、架构、系统运维等职位。这些职位有什么共同点呢?

技术人员的任务,是把定义好的功能做出来。因为长时间跟计算机打交道,而计算机按照算法逻辑运行程序,所以技术人员讲求逻辑,追求细节,探究问题的根源,有追根寻底的好奇心。优秀的技术人员,除了爱钻研深度,还爱探索广度。当对某个领域的技术深入理解之后,他们能抽象出方法和模型,用于掌握日新月异的技术本源,和变化的思想模式,从而在广度上对技术有更快更好的理解。这就是“T”型人才:纵向有技术深度,横向有技术广度,他们对新技术有敏锐的嗅觉,关注、掌握甚至引领技术发展的动态和趋势。

我理解技术角色有以下的四个发展阶段:

  1. 初级的程序员,拿到小的开发任务,能够运用团队中已经选型的技术和工具,编码实现功能,通过调试代码,理解技术的原理,训练自己的思路以便和计算机的运行逻辑同频,灵活运用编程模式,驽驾程序解决技术问题,也就是形成算法思维,这时他关注的是代码质量和技术问题。

  2. 随着开发任务的多样化,程序员解决的问题越来越深入和复杂,逐渐接触和掌握了完整的框架和技术,通过总结,对该问题域形成模块化、体系化的认知,可以独立设计和开发,也就是形成系统思维。这时他关注的是某一类系统的运行效率。

  3. 解决问题能力越来越强的程序员,把问题域不断拓展到新的领域,利用已经掌握的系统化知识和思考方法,能快速学习新领域的知识,掌握新领域的技术和框架,这是进行“T”型技术中广度的积累。每个技术模块都形成他知识体系中的一个节点,随着这个知识体系越长越大,他可以根据用户的需求,选择合适的技术模块,进行分拆组合,考虑成本和收益的均衡,来提供解决方案,也就是形成架构思维,我们称为架构师。这时架构师的他,关注的是业务和架构的最优匹配。

  4. 再以后,就是对技术前瞻性的把握了,结合市场的需求变化和研究人员的成果,依托整个软件生态的发展,引入或创造新的技术,提高应用效率,满足用户需求。IBM有很多技术大神级的人物,我很希望能有机会跟他们深度协作,这样有了体会,就能补充完善这段了。

技术是可以一直做下去的,当然,这点取决于公司的技术成长空间和个人能力素质。如果条件具备,并非像某些人说的那样,35岁以后就要转做管理。和年轻的开发者相比,你资深在对技术本质和广度的理解,以及技术和业务的融合上。

怎么衡量你适不适合走技术路线呢?我觉得,能不能做好技术,不在于你是不是计算机科班出身,不在于你是不是现在还处理琐碎的小任务,而在于你对底层细节的好奇心,以及是否愿意尝鲜钻研,扩充自己的知识体系。

比如,你在饭馆第一次看到“煤球炒饭”,有研究它的欲望么?这道菜上来的时候,还蹿着火苗,你能快速搞清其原理么?你是要自己先研究一番呢,还是去“朋友圈”问别人呢?乘坐电梯,你会不会纳闷电梯用的什么调度算法?你有没有折腾出过一些小程序,被别人“把玩”?你的技术博客,曾经被人称赞或引用过么?如果是,那你可以考虑一下技术路线。

2. 业务角色

业务就是用户遇到的问题和要做的需求。业务角色,包括业务分析师、产品经理、客户支持、业务运维等人员。这些人一方面跟用户打交道,另一方面跟技术人员打交道,把用户不明确的需求、痛点、问题,加工转化为技术人员可理解的、高确定性的需求说明和功能定义。进一步讲,业务角色把用户价值翻译成产品功能,保证产品团队做正确的事。

用户是多种多样的,其原始需求和痛点也是多样的、多变的,很多时候,甚至用户自己也不清楚需求是什么,到底痛在哪里。假如用户想要一种更快的交通工具,但是他没见过汽车,就只能指着满街的马车,说想要一匹更快的马了,然后还说最好不要拉臭臭,因为他的痛点之一是现在街上马粪太多太臭。产品经理如果只理解字面意思,最后的产品也许就是穿着纸尿裤的赤兔马了。

所以,优秀的业务角色能够换位思考,就是有同理心,能站在用户角度考虑问题,也能站在技术人员的角度理解问题。但这并不是说,业务人员是在用户和技术人员中间摇摆,他们要有很强的主导意识,否则在用户指明要赤兔马的情况下,就不会有汽车的诞生了。这正是业务人员关注价值的表现,这也是业务难做的地方。

我觉得业务人员的发展有如下几个阶段:

  1. 初级的业务人员,参与需求分析和产品功能设计,通过对用户心理和行为的调研,选用恰当的UI/UX元素和设计原则,并和技术人员沟通可行性,构建产品原型,同时满足技术成本要求,又提升用户满意度。这时,他关注的是交互设计和用户体验,即这样的操作设计能多好地实现既定功能。

  2. 产品经理则主导业务分析和负责整个产品设计,推动产品的实现和运营,参与产品Idea的产生过程,对市场分析和产品生命规划有一定的了解。贡献在于甄别真正有价值的问题,定义产品功能和优先级,确保解决用户问题,创造用户价值,并通过产品价值指标来衡量和验证。这要求产品经理具备价值判断能力和很强的沟通能力。

  3. 发展到产品总监级别,要主导市场分析和产品规划,掌握用户群体的属性,负责产品Idea的产生,进行产品全生命周期管理,要求有丰富的行业知识和深刻的市场洞察。此时已经兼具业务和管理职责了。

  4. 再往上就该是公司老总级别了,主抓公司战略,业务方向和市场布局。负责整个公司的运作。

这么看,业务角色的发展空间很大。即使你现在只是一个测试人员,你也可以朝着业务方向发展。我之前把测试归并到技术中去了,其实用来验证产品功能的测试工作,是在看界面行为是否符合设计,这是业务人员的职责之一。在积累了大量的功能操作经验之后,可以尝试参与功能设计和用户调研之类的初级业务工作了。

如果你对技术细节总是一头雾水,但是对用户体验倒是很有想法,你更关心别人的感受和使用习惯,有同理心,别人说很难交流的用户,你能轻松搞定。对于某款App,你能体会到某点设计的好处,又能找出不当之处,并知道为什么。那么,说明你比较有产品意识,你真可以尝试一下业务方向。

这里提一下技术人员看待业务代码的问题。有些涉及业务开发的工作,比如前端UI实现、业务数据操作、业务逻辑处理等,某些开发人员,不愿意写这些业务代码,认为这部分更靠近用户,多变、琐碎、只是逻辑控制,没有技术含量,而更愿意编写底层的框架、事务处理机制等模块,这些模块有通用性且可复用,显得很有成就感。殊不知,这些底层技术,正是为了适应业务代码的需求而编写的。如果不了解业务代码的需求,你所理解的底层技术只是代码而已,而不会明白为什么用这种技术,不会明白它和其他模块是出于什么业务目的划分边界,进而不会明白各个产品团队为什么如此组织和协作。

3. 管理角色

最后我们看看管理角色,它包括项目经理、业务主管、技术经理、部门经理等等(不同的公司可能用不同的名称,而且可能一人担任多职)。这些管理角色的侧重点有所不同:项目经理,负责项目的成败;业务主管,负责业务开拓和发展;技术经理负责技术开拓、技术培训;部门经理负责人员绩效、部门发展……但他们的共同目标都是优化人、财、物等资源的配置,用最小的投入,获得最大的价值产出。

这里有必要区分一下管理和领导的概念。以上说的是管理(Management),是有具体头衔的职位,管理具体事务或者人;而领导(Leading),是从管理中分离出来的影响他人的行为,不一定有具体头衔。也就是说,即使你是一个技术人员,不是部门经理,也可以在团队中具有领导力(Leadership),你的技术权威,可以影响他人的决定和行动。关于领导力的话题,我在后面的文章中会详谈。

说回到管理。管理的角色很多,我这里单说项目管理。传统项目管理者的关注点是过程和质量控制,从而达到预期的成本、范围和进度要求。在敏捷管理中,项目管理的关注点放到了人上:更注重团队成员的自我管理,项目经理转变为协调者和服务者的角色,产品经理负责价值递交,因而产品交付不再是项目经理一个人的责任,有的团队把产品经理和项目经理合并为一个角色,让同一个人承担;透明化、可视化的沟通手段,也使项目经理的沟通工作变得简单直接;团队的开放性和自主性,使创新意识和主人翁意识得到很好的发挥,项目经理不再做监工;项目经理需要开放思想,承认项目范围是可以按迭代调整的,容忍快速试错,拥抱变化,提醒和促进团队正确地做事。

尽管管理者们的管理风格多种多样,但是有一个基本的特质是:有条理(Organized),也就是善于安排事情的优先级和组织过程,目的是保持秩序,使过程可控。一个Organized团队中,角色分工明确,工作先后有序,大家配合默契,资源随用随取,流程清晰简洁,成功率很高,能够最大限度地降低不确定性。

所以想想自己,即使还没有管理的头衔,就日常的事情来说,你是否趋向“有条理”呢?比如,你习惯把常用的东西放到固定的位置么?你会按照使用场景优化它们的位置么?你正忙的时候接到一个新任务,是否先衡量一下轻重缓急,再决定要不要切换任务呢?如果是,说明你比较有条理,可以发展下管理意识。

角色融合

当我们刚开始工作的时候,会着力在一种角色上发展。但是发展到越高的阶段,越会发现只有一种角色的眼光和技能是不够的。拿架构师来说,如果眼里没有业务和用户,即使采用的技术再好再新,不能解决用户问题,也不是好的架构师。另外,如果架构师没有管理思维,无法在团队中发挥技术影响力,就不能把设计的精华落实到产品中去,也不能带出精兵强将来。

下面这个图,包含技术、业务、管理三个维度,我们每个人都在每个维度上有一定的能力,承担一定的职责。这样,在三个轴上围出一个三角形,这个三角形就代表了你的角色融合程度和角色跨度。尽量按照你的能力和愿景去拓宽这个三角形吧,它展示了你的能力多大、责任多大,以及对公司、对社会的价值多大。

总结

谈到这里,相信你已经了解了软件产品团队的三种角色,以及它们的关注点和特质。

技术、业务和管理的角色,本身没有好坏之分,只是关注点不同,你需要根据自身特点,选择适合的发展方向。

如果你觉得自己是普通人,不相信自己能发展成大牛或者大神,不要紧,先别下结论。让我们先做个有“饥饿感”的普通人吧。保持这种“饥饿感”,一步一个脚印地走下去。

走着走着,你会发现身边多了很多优秀的人;

走着走着,你发现你也可以给别人营养了;

走着走着,你发现别人开始仰视你,跟随你了;

走着走着,你发现头发掉光啦(好无奈呀)……

思考时间

根据上文介绍的技术、业务、管理三种角色的特质和发展阶段,请你想一下自己具有什么特质,适合发展哪类角色,当前处于哪个发展阶段呢?

欢迎在留言区分享你的想法,和大家交流互动,共同进步。

最后,感谢你学习今天的内容,如果你的朋友也在困惑职业发展的事情,欢迎把这篇文章分享给他。

评论