整合营销服务商

电脑端+手机端+微信端=数据同步管理

免费咨询热线:

技术团队成长和突破的一些体会

技术人员成长路径

技术同学深耕技术,沉浸在某些特定专业领域,在成长过程中,既有专业性的成长,也需要软能力的突破不能在标准模块中使用的是,典型的成长问题包括:

1、「学习成长困惑」:一直做业务代码,使用的技术深度不够,导致一直搭积木,技术得不到成长。而自己想突破技术能力,但是找不到好的突破方向,内心苦恼。

2、「独立解决问题能力」技术上达到了能够被安排编写核心模块代码这个阶段,基础技术能力还行,但是真正独立从0开始写一个核心模块或子系统时,又会碰到各种障碍,需要上级各种支持,显得很无力。

3、「团队协作问题」能独立编写核心模块或子系统,自己个人交付没有问题。随着业务的发展,团队人员逐步变多,反而效率变低,产出变少,个人成为瓶颈,个人成就感也变低。

4、「多团队管理」在管理一个小团队的时候,自己熟悉各种细节不能在标准模块中使用的是,有一切仅在掌控中的感觉。但是业务变复杂后,团队拆分或者增加了其他子团队,对团队的细节不了解,导致项目风险频出,团队Lead也变得很疲惫,甚至陷入了在管理或技术哪个方向发展的犹豫。

5、「技术领导者的经营思维」技术团队管理井井有条、按部就班,解决了一个又一个业务问题,搭建了支持业务体系的完整的技术解决方案,形成了规范化的技术体系后,此时技术领导人的问题变成了技术团队成长空间问题,如何挖掘更大的发展空间、如何让团队实现更大的业务价值等,技术管理问题变成了一个业务问题,变成了一个经营问题。

vb标准模块中怎么写过程_窗体模块和标准模块_不能在标准模块中使用的是

6、「软能力提升」在专业领域已经够用,能够做事,也可能能够安排具体的事情,但是在自己不擅长的非专业领域,在软能力方面,比如沟通能力、情绪控制、领导力等,一直存在或大或小的缺陷,让人不省心,可能需要上级不时干预或者敲打,迟迟不能断奶。

以上其实也是一个技术人员的成长路径,从在指导下做简单代码,在知道下做稍微复杂的模块,再到独立负责相对负责的模块,再到团队协作共同交付复杂的系统,再到多团队管理实现系统集管理,最后到具备经营思维的技术领导者,整个过程需要不断进行硬能力和软能力的突破。

本文站在非技术人员的角度,尝试提出一些技术同学升级突破方式,期望能够对技术同学有所启发。

技术人员成长关键点成长的目标和土壤

很多技术人员在成长过程中,总喜欢盯着外部出现的新技术、别的团队使用的技术栈等,对自己团队用的东西却很是排斥,觉得学不到啥。说起别的语言或者某个技术框架,似乎头头是道,但是讲到自己做的技术,也仅仅是会使用基础技术码出勉强可读的代码而已,典型的眼高手低、好高骛远。

其实能够踏实一点,能够好奇一些,能够眼界放开点,采用成熟的技术构建的业务系统未必不能给新人带来成长,比如对业务需求的理解、对整体技术方案的理解、代码的可读性、异常的处理、上线的维护成本、日志监控和预警等运行管理上的考虑等,就算是一个简单的业务系统,也包含了软件工程的完整要素,整个过程要是能很好理解和交付,个人综合能力也会获得成长。所谓的技术成长,不应该只是盯着某个技术点的成长,而是全面的成长。

所以技术成长的首要点是知道自己缺什么(个人认知),这个阶段要提升什么(个人目标),当前的环境能给我带来什么成长机会(成长土壤),然后基于实际项目、基于自己的技术拓展,去应用和改善自己的技术。当简单的业务系统已经无法难住你时,自然会有更多的机会,若当前环境无法提供足够的机会,甚至个人也会去寻找其他机会。

不能在标准模块中使用的是_窗体模块和标准模块_vb标准模块中怎么写过程

抓住独立负责核心模块的机会

当技术人员成长到一定阶段时,就会面临更有挑战的任务,比如独立去编写核心模块。若仍然停留在原来接收分配到的任务的思维,技术人员可能会把思维限制在“编写代码实现这个核心模块”。可代码编写出来后,可能会有很多直接代码之外的事情,比如这是个伪需求,功能做了也没有用;产品设计反人类,需要返工;代码没有考虑一些业务边界,比如并发访问,比如数据量,需要在底层上重构;开发上没有考虑到对周边模块的影响,导致交付质量差;前后端自测不到位,导致提测后很多阻塞性BUG;异常场景考虑不够缜密,提测甚至上线后,发现各种使用上的异常……

很多问题可能并不仅仅是研发人员的问题,但是作为独立模块的负责人,整个模块的交付质量其实都是有责任的。

作为模块的负责人,去理解要做的事情(业务背景、业务价值、业务规模)、站在使用者和实现者的角度去质疑功能设计、认真构思技术方案(性价比、维护性、拓展性等)、实现中考虑各种异常处理、做好自测、自行调优、关注上线后的模块使用情况(线上问题、监控的友好性等),通过这一系列措施,成为一个靠谱的模块贡献者。

一开始可能并不一定能达到面面俱到,但是每次负责独立模块的开发,都是一个检验和完善自己能力的机会,是一个逐步变得更靠谱的过程。

若都无法树立自己是一个模块负责人的意识,自然就很难让自己发现这些问题,也很难有所改进。

关注团队的总产出

当事情变得有些复杂时,某个模块可能会有更多的人加入。之前的模块负责人就会面临怎么跟更多人协作的问题。

技术团队作为一个专业化团队,通常会弱化层级,而更多考虑的是专业输出以及人员的灵活调度,因此进入到这个团队的人可能有更高或更低的专业层级,但是若对系统或者业务理解还不够,这些人无序的去承接新的工作时,可能会让工作变得混乱,而原来的核心模块负责人也会陷入到做功能、救火、救队友等各种繁琐的事情上,成为瓶颈。

这种情况下,核心模块负责人要承担起部分团队管理和协同的工作,让事情往有序的方向发展,包括功能的依赖和拆解、工作分派、整体方案把控、代码、进度跟进和新的工作指派、团队内知识和信息的共享等,让各个角色能够快速进入状态,能够真正分担工作,自己也不至于成为瓶颈。

阻碍这个模块负责人去承担这个职责的常见的主观问题可能包括:

其实作为模块负责人,不管任何授权,都需要以该模块的交付为最重要的任务,所有进来的人都是资源,都是帮助其实现这个模块,因此这些主观的想法都是应该被摒弃掉的想法。

当然也有客观原因,比如本身技术能力不够、基础的项目管理能力不足等,这个时候就需要上级多进行支持和指导,甚至必要时指定新的模块负责人。

培养团队的梯度

vb标准模块中怎么写过程_不能在标准模块中使用的是_窗体模块和标准模块

当管理多个相对复杂的系统,且系统之间相互独立时,技术负责人通常很难去了解所有项目的细节,若仍然期望自己去实现所有系统的研发项目管理时,可能会碰到一系列障碍:

技术团队负责人期望自己不放弃技术能力,又要能管控好不同研发项目,此时的做法只能通过培养靠谱的团队核心人员:

比较忌讳的就是没有给到各个系统主程充分的授权和指导,而自己陷入管理细节却管不好,团队得不到好的产出,也得不到成长锻炼。

摒弃技术不需要对业务负责的想法

当技术能力和技术管理进一步成长,技术团队本身已经成熟到适用公司发展阶段、公司的基础信息化建设也到了一定成熟度后,技术团队进一步成长就变成了一个业务问题,即有什么新的业务模式能够支撑起技术团队下一步的成长空间。甚至有新的业务模式后,新的业务团队会考虑采用独立的技术团队去支持自己的业务,而让所谓的“专业化”技术团队继续思考自己的生存。

从管理层角度,当技术团队成长到一定阶段,业务侧已经无法提供更有效的信息输入时,管理层也寄希望技术团队能够有业务意识,去主动学习业务知识,去挖掘业务机会,为业务侧实现更多的增值能力,甚至找到技术团队自己的业务机会点。

毕竟公司、团队、个人都是要成长的,成长的尽头殊途同归,都是创造更大的价值。当创造更大的价值之路停止了,迎来的自然就是衰退或者改道。

克服性格中的弱点

人骨子里都会有些性格上的弱点,这些弱点在不同的人生发展阶段对个人的发展有不同的影响。

职场初期,更多还是专业能力的提升,拥有做事的能力,然后随着事情的复杂度提升、人际沟通变多、个人的影响力变大等,人性上的弱点也越来越影响职业的发展。技术团队通常管理和沟通模式相对简单,所以面对复杂度增加的场景会面临一些常见的性格上的挑战:

是不是也可以只发展纯粹的专业能力

答案是可能可以,但是需要有特定背景,比如在大型研发机构的专业人士、技术专业能力足以弥补其他能力的不足、做出巨大的专业贡献等。

但通常在大部分公司,所做的事情并没有专业到那么高的程度,个人专业能力发展到一定程度后,做更复杂的事情就会涉及到很多协作,就需要其他能力并行发展,这样才能把事情做好,在做好事情的情况下,进一步提高专业能力和其他软能力。很多发展型的公司的核心事情都是业务主导,导致对专业人员的综合要求会更高,尤其是高层级的专业人士需要跟业务端口去建立平等的对话、要根据业务情况灵活调整研发策略,这样对非专业素质的要求会更高。

成长的通用性

技术人员成长本质上跟其他人员成长差不多,从早期完成交代的事情,到独立完成简单的事情,独立完成复杂的事情,跟别人协作完成事情,再到领导团队形成更大的影响力,最后就是超越专业本身回到个人和企业经营的问题,无非就是在技术这个专业背景下发挥技术的作用而已。所幸的是,由于技术线条专业性比较强,只要能专注下去,其早期的成长路径会更加清晰,也更可控。