龙空技术网

「项目管理」从技术转管理,你该如何走好第一步?

架构思考 727

前言:

如今我们对“技术架构图和业务架构图区别”都比较注重,我们都想要分析一些“技术架构图和业务架构图区别”的相关资讯。那么小编也在网络上收集了一些有关“技术架构图和业务架构图区别””的相关知识,希望看官们能喜欢,大家快快来学习一下吧!

本次分享有两个重要的前提:

管理是一门科学,领导才是一门艺术。 管理有一套完整的逻辑和理论支撑,这样让我们能比较容易说清楚如何去达成一个目标,去完成一个任务;本次分享主要受众是一线技术管理者。 在技术人员成为一线管理者,到逐步成为中层管理者或者高层管理者的这一过程中,唯有第一步的转变最为“凶险”,有不少人会在成为一线管理者后“哑火”。一、刚成为一线管理者的时候会遇到哪些问题

1.1 遇到的问题

1)关键任务亲自动手才安心

当需要攻坚任务或者遇到技术难题,总觉得下属能力不足或者干活进度慢,不如自己亲自操刀来的快和放心。

殊不知,如果经常这样做的话,后面慢慢就会演变成,只要遇到问题,只有你一个人在干活,其他人都看着你干活,团队成员无法得到有效成长,团队整体能力也起不来。

2)领导总不满意任务结果

成为一个管理者之后,如果你总是在一线冲锋陷阵去完成具体的事务,不能合理安排团队成员工作和及时检查他们的工作完成情况。

那么在关键里程碑上你会无法有效地跟踪进展、及时回复领导关心的问题,最后导致无法保障按时保质的完成领导给的任务。久而久之,领导对你的能力产生怀疑,不再愿意把任务分配给你。

3)管理类的书也看过不少,似乎没啥用

在我成为一个管理者的那一刻起,我看了很多管理类的书籍,学习到不少从未接触过的管理技巧。可一用到现实中,效果奇差。因为这些管理类书籍所涉及的场景并不适合一线管理者,生搬硬套只会反受其害。

4)感觉下属老跟自己过不去

安排的任务执行起来不是拖拖拉拉就是没有任何反馈,自己辛苦做的各种方案不是无人反馈意见和建议就是总被挑刺。

感觉下属看你就是不顺心,就是要反对你任何的想法和安排。我们抛开个别态度确实不正的人,这些问题的核心在于无效的沟通、不合理的安排。

5)招人难,淘汰人更难

随着团队不断扩张,你首先会面临招人问题,当你真正开始招聘新成员时会发现找到一个合适的人真的好难。筛选简历、邀约面试、层层过关到最后能进团队的不说百里挑一,那也差不多是二三十里挑一。

都说没有淘汰过人的管理者,不是一个好的管理者,当你面临因某些原因需要把朝夕相处的小伙伴淘汰时,当你面临小伙伴面谈过程中表现出来的各种情绪时,你就会知道是有多么难下决定。

解决方法

为什么我们会遇到这些问题和挑战呢? 最大的变化在于,你不再是一个人单打独斗 ,本来你只要按时把任务完成就可以了,而且任务也在你可控的范围里。

但是当你开始带领团队冲锋陷阵的时候,就会遇到不少问题,比如说:

团队成员能力参差不齐,甚至团队存在明显短板;面临的挑战不仅变大,而且任务周期也变长了;如何能从团队利益出发考虑问题。

从这种情况来看,你需要:

改变思维,改变习惯: 你只有思维改变了行为才能随之改变,同时影响团队成员的思维,反映在他们的行为之上,最终反过来再影响你的思维,从而形成一个正向的循环。以前你所有的时间几乎都花在了解决问题上,而现在你更需要为大家考虑团队目标和发展、如何培养人才和形成团队职能梯度,这些都需要你改变你的习惯;重新分配时间: 你的时间不再 100%用在处理事情上,而是更多地留出 30%-40%的时间去考虑整个团队方向性的问题、战术或者是建设层面上的情况;提升管理技能: 要懂得一些基础的管理知识和技能,才能不断地推动团队向前走,而不是大家互相抱怨、停滞不前甚至倒退。

1.2 管理的两面性

面对完全不同的挑战和困难,在时间上一定要划分出时间来,思考团队建设和团队成长。在思维方面有两个比较重要的点:

管理即为管事;是人去完成一个个任务。

在一开始千万不要把“人”过早的介入到“事”里, 因为人这个因素变数太多。

一段时期内心情、体能的变化都会影响到团队成员个人完成任务的进度和质量,进而影响整体目标的达成。

比如:你发现团队中一个原本任务完成质量很高的小伙,近段时间工作中经常出错,做事心不在焉,任务进度拖拖拉拉,你甚至怀疑他是不是正在找下家,其实他只是近期家里琐事缠身。

所以对于管理者来说,要先把事和人分开。 运用合适的做事方法论,确定好目标、里程碑、责任人等关键项后,通过不断对团队成员激励、辅导、反馈,最终促成目标的达成,这就是管理的两面性。

1.2.1 从事的角度

1)一切以团队目标为优先

对一个刚刚晋升的管理者来说,如果他一下子切换到团队目标优先的情况会面临两个问题:

成就感下降: 因为他可能再也无法体会到某个技术难题被攻克时,自己目标达成的那种快感,而且现在以完成团队目标为先,所以他完成任务的成就感就会下降。也因为对于团队的成功来说,自己在时间、空间上的努力和劳力付出都减少了,成就感自然也就下降了;失重感上升: 自己无法实时地掌控任务的进展,原本自己完成有 100%信心能够完成目标。但是推动团队去做的话是通过每个人的努力来达成结果,而每个人每天的状态都不一样,自己每隔一段时间才能收到进度信息,这其中很多因素都会导致任务失败。

但是不管怎样,你都需要从你的团队小伙伴中“汲取”成就感。他们的成功就是你的成功,同时你也要适应这样的反馈节奏,才能不断去纠偏。

2)学会合理的任务分配

从项目管理的角度去看,分配好任务才能更好地达成目标,而这样就必定会经历以下三个步骤,也可以说是去 PMP 的方法论:

分析任务: 当你成为一个一线管理者的时候,你拿到的任务很可能不再明确,甚至看着很“虚”。但是你需要去和老板、需求方沟通这个任务,并且详细分析这个任务需要达到怎样的目标或者里程碑,同样也要分析任务的难点、重点和风险点;拆解和整合任务: 比如完成目标需要 3-5 个人,每个人在任务中承担的角色和介入的时间点都不一样,所以需要先拆解任务。而需要再整合任务是任务拆解之后会处于比较松散的状态,这时候就需要你对任务进行整合,有了一个整体的概念再把任务分配到每个人的头上;优先级整理: 比如完成这个任务需要五步,你就需要知道哪一步最重要、完成哪一步之后会有实时的成果、完成哪一步之后能有一个具体的里程碑、完成哪一步能够推进下一步等等,你整理好后要和团队成员明确目标和优先级步骤,这样才能更好地完成目标并使团队获得成就。

1.2.2 从人的角度

从人的角度出发,有两点比较重要:

1)注意新老搭配

由于人员流失或者团队扩张,不可避免的会有新人进入团队当中,这时候你就要思考如何让团队新成员快速融入和成长。要决定是老人带新人还是让新人从简单开始一步步成长,同时也要关注新人的成长情况以便进行下一阶段任务的安排。

促进人员梯队的形成能够很好地应对团队内的突发情况,需要培养或者设置好人员梯队,而不是把重要的工作只集中在某几个人身上,有条件的话还可以培养好 AB 甚至 C 岗。

2)授权与监督

你一定要学会放权,信任实际操作的小伙伴,让他们具有确定权。

但是信任并不等于放任。小伙伴的反馈同样重要,你需要在中间节点及时检查和纠偏,而不是事无巨细盯着每一个细节。这样做能让团队形成正向循环,具备自我驱动前行的能力。

1.3 从不同视角看技术管理人员

即便我们已经成为一个管理者,但从外部看,我们仍然是一名技术人员,我们需要通过技术的手段帮助他们解决业务问题,他们会觉得你的技术能力很厉害而很少关注你的管理能力。

而从技术内部角度来说,你是一名管理者,你如何拆解和分配任务、如何激励团队成员、如何解决内部冲突问题都被大家看在眼里,所以团队成员会关注你的管理能力和技术前瞻性。你需要带领团队成员完成一个个任务,并做好人员培养、促进团队成长。

所以作为一线管理者的我们需要时刻记住,我们的双重身份,不宜再纯粹地用技术的思维去解决问题。

二、在管理技能提升上两个好用的方法论

2.1 目标、计划 / 考核、激励 / 辅导、反馈

这一个方法论推荐大家先背下来再在实际中慢慢应用和体会。

当我们面对人或者事的时候,一定要先设定一个够得着的目标,确定目标后完成分析、拆解、整合、优先级排序的动作,再之后就能制定出一个计划,而这个计划会按照“PDCA 环”去循环。

计划开始执行之后,每隔一段时间都需要进行考核,检查目标执行情况和遇到的问题。如果目标执行情况不理想,遇到知识盲区或者团队推进困难的情况,这时候你就需要激励你所放权的小伙伴,同时引导他去发现整个过程中做得不太好或者做得好的地方。

接下来就是要辅导和帮助他,因为不是每个人生来都能胜任好管理者的工作。以我为例子,我从基础运维到系统运维再发展到应用运维,但如果有 DBA 问我有关数据库的问题,虽然我无法帮他解决这个问题但是我也会给出指导性的意见。

在给予小伙伴激励过后,每隔一段时间还要观察你的激励和辅导有没有起到作用,又或者任务目标是否需要调整,有了这样的反馈也能增加你做管理的经验。

2.2 复盘

复盘是我做管理 7、8 年间认为最最有用的方法论,大体可以分为四步:

回顾目标: 这是我在上文为什么说有一个明确的目标很重要,因为要先有目标才能在后期回顾目标,来判断是否达成了你想要的结果;评估结果: 要针对事而不是针对人,客观看看待事情的完成度和效果;分析原因: 分析阻碍任务完成是客观原因还是主观原因,是人为原因还是不可控的原因;总结经验: 最简单的办法是,总结经验之后再去思考,如果这个任务再来一遍你能不能完成得更好。

对于小的任务或者项目,要及时复盘;而对于大任务或者项目,要阶段性复盘;对于重要任务或者大任务完成后要全面复盘;甚至对于自身的事情也可以复盘。

这样你能够不断累积各方面的经验,并把经验应用到更多的事情上。多用这个方法,能使我们避免重复犯错,能使好的固化下来,成为能力。

2.3 推荐书籍

推荐两本书,是我在转型期中,对我影响最大的两本书:《卓有成效的管理者》《影响力》。希望能帮助到即将转型或刚转型没多久的你,顺利度过转型的阵痛期。

Q & A

Q1:从技术转管理,技术水平的提升应该把重点放在哪里?

A: 技术水平的提升的重点放在技术方向和技术整合。

Q2:有遇到过部分项目难点亲自操刀的情况吗?

A: 如果遇到团队成员无法解决的问题,不得不亲自操刀时,需要把握一个度:一旦解决关键部分或者团队中有人能接手了,就要及时抽身,交给团队成员继续推进。如果是攻坚型的项目,需要你全程投入的,那也一定要留出时间处理团队事务。

Q3:要怎样才能减少管理的隐形成本呢?

A: 有效的沟通,充分的信息流动,明确的目标,及时的复盘。

Q4:技术团队要做团队转型,组织架构应该怎样修改更好?

A: 技术团队的转型过程中组织架构的修改先要弄清楚一个问题:是不是现有组织架构阻碍了技术转型。所以组织架构的修改没有标准答案,需要根据转型的目标而定:按技术栈,按敏捷小组等等。

Q5:团队有技术厉害的人,但安排出方案的任务给他,他觉得你除了会安排事其他都不会怎么办?

A: 从他的角度看你的日常的工作确实如此:安排工作,安排任务。但是如何合理的安排工作和跟踪进度,调动团队工作积极性,把任务串联起来以达成目标这已经跳出了技术范畴,他看不到看不懂也是正常的。如果你的团队是一个手串,那么你团队成员就是手串上一颗颗珠子,而你就是串起珠子的那根线。

Q6:OKR 的自我推动力不足,怎么办?

A: 推荐使用复盘这个工具,来剖析一下为什么自我推动力不足:是目标定高了?还是目标不是自己定的,只是被强加的?亦或是遇到无法逾越的障碍。

Q7:如何培养技术出身的管理者的战略思维?

A:站的高一些,比如站在你领导的角度看问题;跳出当前的职位和团队,比如站在业务的角度看问题;时间放的长一些。

推荐一个概念可以去了解并实践:点、线、面、体。

Q8:上传下达有什么技巧吗?

A: 千万不要透传,分析、过滤、转译。想想好的 ETL 是怎么做的你就会明白上传下达的技巧。

Q9:当要落地一些技术战略,会影响多个技术部门,需要各个部门相互协调合作,共同推进。有比较好的管理模式和最佳实践吗?

A: 你有调动其他部门的权限吗?你跟其他部门负责人关系如何?用项目的方式,让有权限的人授权或亲自参与。

Q10:上级让你出方案然后推动项目,但是没给你授权怎么办?

A: 对于这种情况,一靠“人情”,二让你的上级参与此项目。

文章来源:岑崟_

标签: #技术架构图和业务架构图区别