此外,加一个前缀,主要针对非技术领导者所面临的技术管理困境,在很多从传统企业转型或个人站转型的互联网企业里,这个问题较为突出。 问题3:理想主义情绪 开发人员往往有理想主义情节,希望所设计的架构可以支撑更广泛更持续的应用诉求;有时候产品人员也会有这样的想法,过于追求远大的宏伟目标;理想主义往往导致投入太多的无用功到无谓的兼容性设计上 问题4:80%的无用功 这事可以说是问题3的升级版;也可以说是问题1的升级版;程序员往往因为对业务诉求不清晰;或者为了追求完美,将80%的精力投入到并不存在的业务诉求上,这我也遇到过,而且 问题6:没有足够的思考和设计时间,以及学习研究的时间 好吧,前面说了,不要追求完美,不要设计复杂的架构,但是即便是轻架构,即便是简单的代码,也需要足够设计和思考的时间; 小公司、非技术管理者
[tp3jnruqdq.jpeg] 一、技术架构的哲学本质 在上一篇《架构设计思维模型学习总结》中提到,玄姐认为,架构师需要具备几个思维模型,为什么要将思维模型化? 二、技术管理的哲学本质 管理的本质是激发善意 “于一微尘中,悉见诸世界”:万事万物在“道”即本质的层面相同,在“术”即业务场景的领域不同,道同而术相异。微尘虽小,亦可窥探世界的全貌。 构建终身成长生态 作为技术团队的管理者,终身成长应该是技术管理者对整个团队的要求,因为只有终身成长,才能保证你的团队能够持续产出高质量的内容。 (3)落地 这里的落地是指,原创力和执行力,让业务需求能够顺利完成。 玄姐认为,只有具备了以上几种思维方向,才能领高层管理者和团队人员实现双赢或多赢。 三、技术管理案例剖析 案例1:合作 [w5mjbf2bax.png] 从德鲁克的经典论述中,我们知道了:管理的本质是激发善意,而成长又是最大的善意。
最近一年左右兼职技术管理的经验试总结,核心理念就是以人为本。 小作坊 小项目的构成往往是一个相对有经验的人作为 leader,带几个毕业生构成一个三五个人的小作坊。 原文链接:小团队的技术管理 ----
3、高效会议,会前发出议题,与会人提前做准备,会议要有结论,执行结果有跟踪。尽量心平气和地讨论,你每次忍不住骂别人的时候,要考虑对方的感受,尽量不要用方言,因为对方会听不懂。
我们很多技术开发人员,在这个的岗位做的很优秀,就可能得到提拔,而走向技术管理的岗位。 从技术开发到技术管理,是一个很大的转变,也需要走向技术管理的人员转变,这个转变会根据能力不同,有不同的调整期,一般半年左右,转变过来就能更好的适应这个技术管理的岗位。 今天我们就聊聊从技术开发到技术管理后,会有哪些转变,也是我们想走这条路的人必须做出的改变。 所以很多技术开发人员,刚被提拔为技术管理者后,就会很乱,很忙,没有头绪,主要也是因为事情太多,太杂,没有掌握技术管理的诀窍,所以一时很难适应,这个就是适应期,调整期。 现在成了技术管理者了,你要把任务分解好,谁做什么,什么时候完成,怎么做讨论方案。什么?卡住了,再赶紧拉通。
在中生代和飞马网的技术嘉年华上,我斗胆披上吹牛的嫌疑,分享了面向全栈的技术管理,现赘述如下。 ? 作为一名技术管理者,既需要培养团队的ABC,又需要管理你的老板,保持团队的新陈代谢,因为一切都是人的竞争。我曾在GitChat上做过一次分享,具体可以参考《老曹眼中的研发管理二三事》一文。 ? 面向全栈的技术管理试图从采用系统思维的方式来探讨研发管理尤其是技术管理的可行性和方法。从系统的角度看,包括时间,空间 和人三个维度。 面向全栈的技术管理主要是通过系统性的思维方式解决技术研发管理的问题。这是典型的九宫格矩阵,从时间和空间的维度提出了系统思考的维度。可以缩放系统的概念范围,例如到模块的层面,会发现很多有意思的结论。 商业需求是个大话题,超出了很多技术人的领域,这里主要看研发中技术管理的全栈思维方式。用一句高大上的词,就是技术前瞻性。 如何考量技术的前瞻性,可以借鉴TRIZ的方法。 ?
一个技术管理者的成功并不在于自己代码多好、能力多强,他的成功一定建立在团队成功的基础之上。只有团队成员不断成长,这个团队才可以做成更大的事情,而你才可以在团队的基础上,站得更高、看得更远。 ———— 本文引用自极客时间精品专栏“朱赟的技术管理课”。 在专栏中作者以女工程师和技术领导的视角,聚焦于技术管理、技术实践、硅谷文化和个人成长领域,分享自己在技术和管理上的领悟及忠告,以及在硅谷工作的体会与见识。
最近学习了极客时间许健老师的《技术管理案例课》,现在就把我的学习总结分享与你,本文为下半部分,主要关注二线主管和技术决策者的实践要点。 (3)应对组织危机 真正考验经理领导力,往往是在出现组织危机的时候。应对组织危机,核心要点就是:承认差距,但是绝对不要失去信心。 ,需要做技术决策,这也是技术管理和一般管理的主要区别。 (3)多方面、发展眼光看待技术决策:一方面新技术可以推动变革,但引入有风险;另一方面决策要以当前阶段的主要冲突和矛盾为基础。 技术管理案例课脑图(下).png 推荐学习 许健,《技术管理案例课》
我们先依旧遵循理性分析的风格,来拆解归纳一下,作为技术管理者做向上汇报的目的到底是什么? 很遗憾,作为技术管理者本意是希望大家更重视技术,为团队争取更多的资源,但是沟通汇报的结果反而导致了失去信任,失去支持。 问题的症结在于:很多技术管理者还是只关注了前面两个字“技术”,而丢失了后面的“管理者”。 作为技术管理者,你应该关注的是“技术团队需要什么资源,然后可以为公司做到什么!” 仅仅就这么一条而已! 在制定目标结果时,应该尽量基于团队能力、业务价值、实施节奏3个维度来考虑,使用简单明了的数字是一个好的方法。
该ppt记录自己的技术管理上走过的坑和一些成长心得(2008~2022年),2023~至今仍在积累沉淀中,期待有更大的突破,未来再做分享。
这个需要从3个方面解决 设定技术目标时要贴合业务,这要求管理者必须深入到业务,知道哪块业务有长期价值,是公司重点投入对象,那么你的专业目标也是围绕着这块优先落地。 你的KR就是完成5个核心应用,启动时长<3分钟,提效50人日。 明确可衡量 所以KR必须要非常明确,不能笼统。
即便是冠上了架构师的头衔,也需要做很多管理的工作,通常会面临下面的一些问题: 初次接触管理岗,需要和人打交道了,难以适应 仍然把自己当成是一个高级的开发者 需要多任务并行处理事情,分不清主次 团队成员从3、 一旦走上技术管理岗位,会感觉事情突然翻了很多倍: 制定产品的任务计划 需要考虑团队成员的成长 合理地安排任务 各部门之间的协作 重难点技术的攻关 核心代码的编写 解决团队成员遇到的各种问题 … 如果没有一个合理的安排和归类 善用工具 不同的时期,有不同的做事习惯和风格,最早我团队只有3个人的时候,平时的沟通和任务的分配基本都是口头转述,因为这样效率最高,但仅限于团队成员足够少,并且每个人都能够配合默契,这样口头转述的内容才能不失真
有个刚创业的读者问,作为一个技术管理者,都有些什么推荐的工具和系统来组织公司内部的各种系统?这个问题我之前的文章提过一些,但不系统。 建议备份往S3上备,无他,安全,便宜(阿里云有无类似服务我不知道)。 CI jenkins是第一选择,其次是travis,这两个都没得说。 至于怎么上google(访问外国网站),我想,这不仅是技术管理者需要掌握的,每个技术从业人员都需要知道,你说呢?
本文主要内容有: 技术管理之角色认知 技术管理之管理规划 技术管理之团队建设 技术管理之任务管理 技术管理之管理沟通 一、技术管理之角色认知 下面通过脑图梳里了角色认知的七个点:工作职责、负责对象、关注焦点 例如:衡量要能量化,系统吞吐提升3倍、架构优化支持系统高可用、交付哪些功能等。 3、管理规划之团队 从不同的视角观察团队规划,目标视角、资源视角、人才视角。 目标视角:团队分工、规模、梯队。 资源视角:每个人在公司意味着成本,这些成本考量需要跟公司发展匹配。 3、团队分工与协作 团队分工 复杂的事情需要依靠团队完成,谁干啥就需要有个分工。 组织里通过划分部门、业务域,来从整体上分工。 以及部门内部的二级、三级部门等的划分。 3、拉通形成共识 项目整体架构方案、具体到组件的实现方案需要拉干系人聚焦和对齐、达成共识。 拉通和对齐的过程也是发现问题、方案合理性、确保整体方向的正确性。
引言 继前文梳理「团队建设」与「管理规划」后,本文梳理下技术管理的另外一块「任务管理」。
我理解技术总监的权责范畴应该包括: 技术性工作 管理性工作,分为人员管理(即团队管理)和项目管理 在技术型工作中,我认为更多考验的是一个技术管理者的技术深度和广度,而管理性工作中,更多考验的是一个技术管理者对于复杂人和事的协调能力 不要求技术管理者写代码,但是在某些风险性大的技术场景里,技术管理者必须能亲自上阵,以免团队成员解决不了“甩锅”的时候可以接得起来。 而且了解团队的代码情况,融入团队的代码编写,也方便对系统架构的掌控。 3、工程管理能力 很多人对“工程管理能力”感到陌生,如果我把这块分开说为“性能”、“运维”和“效率”大家就好理解了。我们更多的认为工程管理能力关系到稳定性和效率上。 3、组织结构设计和人员招募 我认为组织结构设计更好的关乎团队的效率和能力发挥,包括岗位的增删减,扁平化结构还是梯度化结构,什么样的人安插在什么样的岗位上,这也是管理者应该懂得一门大课程。 但是,我想说技术管理者难度更胜一层,技术管理者要先有专业性,再来领导力,需要像医者一样的仁心仁术,而不是简单粗暴的工厂管理。
综合上面的比喻示例,可抽象概括下技术管理者需完成的工作如下,下面将展开说明。 (以下内容部分来自果见-刘建国系列文章)。 1. 管理规划:“敢问路在何方?” 管理规划对于技术管理者来说,非常之重要。 3. 任务管理:“不以规矩,不成方圆” 我们研究任务管理,就是为了把事情做出来,产出实实在在的业绩和成果。作为结果导向的管理者,这才是管理工作的落脚点。 作为技术管理者,和普通管理者最大的区别,就是"技术"二字,这也是技术管理者最鲜明的标签和最大的竞争力。 01 角色转换 技术管理者,对待技术与技术人员会有所区别,是有个角色的转换。 这项评估工作很考验技术管理者的技术经验和风险意识,而且需要借助全团队的技术力量来做出准确判断。 ?
(3)应对组织危机 真正考验经理领导力,往往是在出现组织危机的时候。应对组织危机,核心要点就是:承认差距,但是绝对不要失去信心。 ? 一线经理自己提准则并选择遵守哪几个准则 不一定按比例分配:一碗水不端平才是公平 投票选举:但要保留一把手对投票结果变更的权利 异常处理:解决方案还是在平时的准备 三、技术决策者 作为技术管理者 ,需要做技术决策,这也是技术管理和一般管理的主要区别。 (3)多方面、发展眼光看待技术决策:一方面新技术可以推动变革,但引入有风险;另一方面决策要以当前阶段的主要冲突和矛盾为基础。 推荐学习 许健,《技术管理案例课》 作者:周旭龙 出处:https://edisonchou.cnblogs.com 本文版权归作者和博客园共有,欢迎转载,但未经作者同意必须保留此段声明,且在文章页面明显位置给出原文链接
例如:衡量要能量化,系统吞吐提升3倍、架构优化支持系统高可用、交付哪些功能等。
最近学习了极客时间许健老师的《技术管理案例课》,现在就把我的学习总结分享与你,本文为上半部分,主要关注领导力及作为一线主管实践的要点。 [381412-20201217143022651-1166619449.png] 一、为何学习技术管理? 对于技术管理者而言,课程中总结了一个技术管理者技能全景图,完整地描述了经理者的成长路线,是一个十分值得我们参考的图: [381412-20201217143112227-832608019.jpg] 下面我就来一一总结一下各个模块的学习收获 就是在转型Leader的过程中容易犯的5类问题需要我们注意: (1)管得太细:需要我们从只关注交付结果转变为同时也要满足人的需求; (2)大包大揽:需要我们提升自己的感情强度,不能剥夺员工的成长锻炼机会; (3) + 定期谈心 安排专门的师傅带新人* 提高软实力 => 思维、逻辑 和 表达能力 给员工提供专注的机会 => 有机会成为某一个领域的专家 把握“挫折”的度 => 重视心理建设,不让员工失去自信 (3)