网站开发建设账务处理程序,网站建设服务费入,仿《砍柴》网站程序,网站开发与维护都有些什么要先把当前级别要求的能力提升到精通#xff0c;然后尝试做下一级别的事情。
但可能不确定高一级的能力要求究竟怎样#xff0c;不同Title#xff0c;如“工程师”“高级工程师”和“资深工程师”等。但这样 Title 对我们理解不同级别的能力要求#xff0c;完全无用。“高…要先把当前级别要求的能力提升到精通然后尝试做下一级别的事情。
但可能不确定高一级的能力要求究竟怎样不同Title如“工程师”“高级工程师”和“资深工程师”等。但这样 Title 对我们理解不同级别的能力要求完全无用。“高级工程师”到底“高级”在哪
1 公司统一的能力描述抽象
为指导员工晋升公司会对各级能力要求给出描述。但因细分的领域太多公司只能进行抽象描述。如
P7要求“具备系统思考能力能全面掌握某技术领域”P8要求“具备前瞻判断的能力能够规划技术领域的发展方向”
从实际效果看这样的描述无效还是不懂在说啥。我们经常困惑
什么是系统思考能力P7才要求系统思考可我P6时参与项目开发就要考虑需求合理性、索引设计高性能、接口兼容性和易用性、上线的灰度方案这么多事情这些难道不是系统思考什么是前瞻判断能力P6要预测需求变化P7要规划团队技术发展这些也是前瞻判断呀为何P8强调前瞻判断
晋升疑惑千千万能力要求占一半。
2 领域定制的能力解读比较具体
因为公司的抽象描述很难指导实际工作有些领域会独立定制自己的职级能力解读一般由P8或P9级以工作组的方式讨论得出。
如“Java业务开发”领域P6、P7能力解读参考 跟公司的描述相比具体很多。按此思路完整把各级要求能力列出不但可作为晋升标准也可作为学习参考。
这种做法对员工有利标准越明确越容易“照本宣科”去做。但公司角度这成本太高有几十上百个专业领域要制定详细标准每年都要更新、限制创新大家就只管对照公司标准来做事其它一概不管等问题所以没有公司这么做。
3 COMD能力模型
为彻底解决要求不明确更好理解不同职级能力差异整理一套兼容性强、易理解的能力模型面向复杂度的多维度能力模型Complexity-Oriented Multi-Dimension Capability ModelCOMD能力模型。
核心指导思想是通过事情的复杂度来判断能力的高低级别越高所做的事复杂度越高。
只是单纯用复杂度判断能力高低那它本质和其他方法没啥不同看不懂的地方还是看不懂不同的人理解还是不同。所以为清晰描述不同能力层级的差异COMD能力模型还进一步明确复杂度包括规模复杂度、时间复杂度、环境复杂度和创新复杂度。
3.1 规模复杂度
规模越大节点越多节点间的关系越复杂而且节点间的关系复杂度是指数增长的。
就可对一些常见工作维度的规模复杂度进行比较 以上对比前提是除了规模其他条件差不多。200行代码和2000行代码对比前提是代码复杂度差不多。因为200行核心代码的复杂度显然比2000行拷贝粘贴的代码高。
3.2 时间复杂度
时间跨度越长复杂度越高。原因在于万事万物都处于不断发展变化当中时间跨度越长变化的因素和可能方向越多越难判断准确。
三大维度的时间复杂度的对比 3.3 环境复杂度
和环境不确定性有关的复杂度。
我们很多的判断、决策和行为都依赖于对环境的认知和反应。总的来说环境不确定性越高复杂度越高。
环境的不确定性具体分为环境的稳定性、环境的透明性和环境的可预见性3个方面
环境的稳定性指环境变化的速度快慢。环境的透明性指是否能够明确地获取环境相关的信息。环境的可预见性指是否会发生完全无法预料的黑天鹅事件。
环境的稳定性、透明性和可预见性越低它的不确定性就越高复杂度也越高。
宏观分析技术、管理和业务三个维度所面临的环境不确定性 对互联网行业业务环境稳定性、透明性和可预见性都较低所以环境复杂度最高。这也是在互联网大厂大部分P9/P10都需要把很多时间和精力投入到业务上的主要原因。
3.4 创新复杂度
常见创新包括理论创新、思想或方法创新和技巧创新。
理论创新复杂度思想创新复杂度技巧创新复杂度。
高可用技术领域
FLP原理、CAP定理是理论创新。它们奠定分布式高可用设计的基础和边界无论是缓存系统、存储系统、批处理系统、流式处理系统还是采用微服务架构的业务系统等都不能跳出这两个理论的约束和限制批处理和流处理属于思想创新。对于大数据技术来说一开始Google提出的批处理思路开启了大数据时代而后来Storm开启了流处理这个新的技术领域实现Exactly Once特性属于技巧创新。开源框架Flink使用Chandy-Lamport 算法实现了流处理Exactly Once的特性能够实现消息精确投递避免重复消息导致业务出错
创新复杂度越高影响的范围往往也越大。理论创新会奠定整个行业的基础而思想创新可能开辟一个新技术领域。
创新并不意味着一定要全球首创只要相比团队当前现状来说有改进就行了创新也不局限于技术领域管理和业务一样可以创新。所以下面这些事情都可以算是创新
开发Memcache有Memcache后开发Redis引入设计模式优化代码使用微服务拆分系统优化项目流程提出新业务模式
各领域的部分典型创新案例 除了刚才说的这4种通用的复杂度之外在每个领域内部也会有一些工作的复杂度本身就要比另一些工作高。
比方说在软件开发领域我们一般认为各项工作的复杂度排序是这样的
从0到1创造系统架构重构项目方案设计编码实现从0到1创造系统 架构重构 项目方案设计 编码实现从0到1创造系统架构重构项目方案设计编码实现
不过这些认知是领域经验总结形成的共识并不能通用。所以在使用COMD模型的时候你还是需要结合领域经验综合判断。
4 COMD与抽象描述的对比
公司写的那些抽象描述跟COMD能力模型的具体拆解比起来只是脱离实际的文字游戏。
4.1 系统思考
某大厂“系统思考”的确写在P7级能力描述但它不是P7才有的能力特征。P6以上都要求“系统思考”只是思考范围不同即规模复杂度不同。
以B2C电商业务开发为例在某些大厂不同级别“系统思考”范围 P6系统思考范围是某个需求考虑需求合理性、设计可扩展性和上线后的稳定性P7范围是单个系统考虑单个系统的架构设计、架构重构和技术选型P8范围是某领域考虑领域的发展趋势、架构演进、团队组织结构P9系统思考的范围是多个关联的业务域组成的业务线考虑业务发展趋势、架构演进、团队组织结构
4.2 前瞻判断
某些大厂“前瞻判断”虽写在P8描述但P6以上都有前瞻性要求只是前瞻范围、时间跨度和面临的环境不同分别对应规模复杂度、时间复杂度和环境复杂度。
B2C电商为例某些大厂P6P9前瞻性要求 若你还苦逼钻研“为何P7才提出系统思考”、“P8要求的前瞻判断有啥深意”就会掉入文字陷阱白费脑细胞。从坑里走出要灵活应用COMD能力模型。
5 应用COMD
当你想要了解某个级别的能力要求不要再对那些抽象和模糊的词语不着边际猜测和想象。
静下心坐下来填“能力矩阵”表格把每项要求完整且具体列出。如下摘录P6部分要求可参考 若表格有些内容填不出来说明你对这级别理解不到位。
在这基础上可请教你的主管、HR和同事等人完善、细化表格。详细填完表格就对级别很清楚了后续针对性提升能力。
6 总结
公司会对各个级别的能力要求给出一个抽象的描述比如“系统思考”和“前瞻判断”等但实际指导意义不大。有些领域可能会独立定制相关技术方向的能力解读。虽然这种解读比公司的抽象描述稍微具体一些但因为投入成本太大和限制创新等原因很难大范围推广。我总结的COMD能力模型把能力分成技术、管理和业务三个维度并通过规模、时间、环境和创新四个复杂度来判断能力的高低。如果你想了解某个级别的能力要求为晋升做准备可以把这个级别的能力模型表格列出来然后针对表格内容做针对性的提升。
FAQ
“为什么说P6是独当一面难道P7、P8和P9没有独当一面的要求吗”
独当一面的“面积”不一样P6的面积是15寸笔记本屏幕大小P7的面积是32寸液晶显示器大小P8的面积是65寸高清显示器大小P9的面积是公司门口的大号液晶显示屏。
单维度内把基本的事情做对把难的事情做对 多维度内把基本的事情做对把难的事情做对 多维度间把基本的事情做顺把难的事情做顺 新维度时把基本的事情理清把难的事情理清
为清晰地描述不同能力层级的差异COMD 能力模型还进一步地明确了复杂度具体包括规模复杂度、时间复杂度、环境复杂度和创新复杂度 4 种类型。怎么想到按这几个维度来拆分的。很多时候对一件事情的理解无法深入就是不知道该怎么继续往下拆分老师的能力模型一下子把模糊的评级能力要求拆解的特别清晰。特别想提升这方面的能力可通过哪些方式锻炼
如何衡量和考察技术人员的能力对于一个复杂模糊问题一下子看不到答案可尝试拆分按逻辑维度、流程维度、分类维度COMD模型的3个维度其实就是分类拆分的4个复杂度就是按逻辑来拆分。
如何提升这种能力可能跟我看书多有关例如人文社科心理学经济学管理学等看多会潜移默化无意学习一些方法。
中途转的JAVA目前作为一个小组长技术不行管理上也在摸索这种情况下是偏向技术还是偏向管理比较好P9以前都是专业为核心管理是附加分。
直面自己和直属领导的差距除了直面更要学习别人的长处和厉害的地方。
