5.偏头痛杨写给年轻人的一些经验干货系列之管理篇

版权声明:偏头痛杨:本文为博主原创文章,未经作者允许不得转载,版权必究! https://blog.csdn.net/piantoutongyang/article/details/89639128

文章目录


前戏

首先要感谢我职业生涯中所有遇到过的领导、项目、团队、问题、同事等等,
因为这些才是让我成长的关键因素。

抽空总结了一些日常工作和管理方面的入坑出坑的经验,
希望能给年轻人提供一些帮助。

程序猿的职业发展规划,我个人认为可以有这样一条路。

  1. 应届毕业生&实习生
  2. 程序员
  3. 组长&主管&高级&资深开发
  4. 技术经理&项目经理&架构师
  5. 技术总监&技术专家
  6. CTO&技术VP&技术合伙人

各行各业发展到一定程度都会有瓶颈期,你可能会觉得这个阶段提升的速度较慢,会痛,
但痛就意味着成长。

其实title不重要,脱离了公司,title就啥也不是了。
那么重要的是什么?是能力,是成长,是价值。

无论我们到后面选择的是p岗(技术岗)还是m岗(管理岗),
都需要去学习一些管理上的知识,让自己更优秀,更具有竞争力。

不断的进坑与出坑,不断的总结与复盘,希望可以让大家少走一些弯路。
很多程序员不知道什么是管理,自己当上leader之后,也不知道该怎么管,
认为管与不管都一个样子,都靠大家自觉、素质、职业操守,但其实是一样的吗???
当leader有什么小技巧吗???
在日常的工作中,有什么小技巧吗???

相比较而言,管团队、管人是比较复杂的,因为很多程序员个性是比较桀骜不驯的,
对机器输入指令,机器会按照你的意愿做事情,但人却有很多种可能。


管理

什么是管理

试想一下,在古代金字塔和长城这种大项目,是怎么管理的?需要怎样的调度和控制?
怎样安排大家每天的工作?由于修建工作的危险和辛苦,肯定有很多人打算逃走,
是谁来监督这些劳工?又是谁来保证工地上有足够的沙石,
让每个人都有活可干?肯定有人承担(或兼任)着管理的角色,从事计划、控制和实施的工作。

管理是通过计划、组织、领导、控制的方法带领团队完成某个目标的过程。
按时按量的把领导交代的目标圆满的完成了,你作为leader来说,价值就体现出来了。
有的人单兵作战能力很强,但是带团队的能力很弱,这里需要一些技巧。

计划(plan)

大军未动,粮草先行。哦,是计划先行。
leader需要在大部队进入实施阶段前就确定目标,制定策略,安排计划等等。

本周团队的目标是什么?团队的目标是什么?下个月的目标是什么?
制定了目标后,需要让团队成员达成共识,
然后如何去使这个目标落地?

不要制定特别长的计划

我们要拥抱变化,你订了下一个月的计划,也许到下个月的时候,
临时插进来许多优先级很高的工作,计划又变了,浪费了工程师这边估的时间,
并且计划总是在变也不利于军心稳定,因此计划不要定的太长,考虑灵活多变。

需求调研

无论是创业、外包、互联网,需求都是重中之重,需求或方向定错或有歧义,
那么保质保量的完成目标也就变得没有意义。

需求调研,整个项目的重中之重,需求做不好,后续都是坑,一定会失控!
需要学会整理边界,什么该做,什么不该做。

一个好的需求调研也为后面的工作排期打下了良好的基础。

项目的领导者必须要全身参与进来,否则你无法控制整个项目,项目失控才是最可怕的。
千万不要等项目进行中,或者项目中后期还有一些最原始的需求搞不清(坑王之王)。

在做之前,先想想怎么完成,先在脑子里&纸上路演一遍,
宁可在前期多花一些时间,也总比在后期花大把的时间与精力去改代码强百倍,
其实真正coding的工作没多少,前期需求做好,比什么都强。
等到大量返工工作量出现的时候,也是体现出你无能的时候。

如果是外包项目,在项目的需求阶段,要跟合伙人把每个细节都过一遍,不用具体的实现,
只是过一遍,预估一下是否会有瓶颈,以及风险评估,大坑等问题。

需求分析并非一日之寒,需要多次与甲方或产品经理进行沟通,此处需要整理出《需求分析文档》,
让需求方邮件确认。

如果是外包项目,最好派个人去甲方现场,有可能的话尽量常驻,
在现场跟需求方零距离的沟通,这样甲乙双方都踏实。

量化与执行

量化与执行是我们解决问题的方法与手段。我们要完成一件复杂的工作,或实现一个较远的目标,
需要对实现过程进行具体的计划和安排,并按照计划进行强制执行,最终实现目标。
那么如何量化什么是好?什么是不好?

不仅仅是在软件开发的项目中,我们要完成任何一个复杂的事情,
都要想办法将其量化成为可以操作(执行)的具体步骤。

管理者遇到这样的事情往往会更多些,例如:2年内成为占领某某行业30%的市场份额,
或者5年内称为最成功的企业。
这样的目标是否可行,是否能够实现我们姑且不论,
但为了完成这样的目标我们必须制定出切实可行的操作步骤,
才能按照步骤一步步的去实现,也才有可能完成任务、实现目标,否则目标就变成了一句口号而已。

计划需要可视化,可量化,并指定deadline。
计划也需要是可视的,团队目标和计划不要定的太高,不要拍脑门定,不要想当然,
否则累死大家也做不到,影响全军的士气。。

例如:
目标是这个月100万的业绩,不是到月底看一眼大家的完成情况,然后没完成的话,leader再一顿喷就完事了。

要可量化,这100万是怎么来的,制定计划,大计划拆解成小计划,
leader需要分节点去check每天、每周、每月的任务是否达标,是否合理。
如果出现问题,会第一时间暴露出来,第一时间去分析,第一时间去解决,第一时间调整。
而不是最后一天才爆发所有的问题。

前移的量化管理

例如年初你跟一个销售说今年他的目标是100万,年底的时候他跟你说,这个月就能签下百万大单,
但现在是0,你信吗?我们需要在前面就制定出可量化的指标,比
如每月需要多少的电话邀约量啊,需要多少的面谈记录啊等等。

例如:
单元测试覆盖率到达百分之多少算是符合标准?
pmd&checkstyle&findbug等插件的故障率低于百分之多少算是符合标准?
codereview要发现低于百分之多少的缺陷算是符合标准?
平均每月&每周线上发现的bug总数是否符合标准?

注重可持续性发展

leader在制定计划的时候一定要预留buffer时间,制定计划不要可丁可卯,
不要给自己给团队非常大的压力,因为在日常工作中经常会出现打断的事情,
例如排查一个线上的问题,解决一个其他同事的问题等等。

每天的工作不仅仅是满负荷状态在运行,
那一旦解决了其他的事情而导致今天该完成的工作没有完成,就只能加班。
天天加班势必会造成士气低落,因此需要有一些buffer时间,
如果进度非常健康,那这些buffer时间可以:

  1. 让下属调研团队中能用到的新技术,之后再让下属分享给团队,是双赢的,切记要让下属调研的东西与团队需要的东西是一致的,要双赢,而不是单赢。
  2. 检查线上服务器是否健康,分析日志。(没有专业运维的前提下)
  3. 做代码评审,可以从核心重要的代码开始评起来,,每周一次的代码评审,让下属上去讲,
    leader负责把点记录下来,每次评审下来,都能有新的收获。
    大家达成共识,要有惩罚措施,例如买个水啊做俯卧撑啊等等,代码质量一次比一次好。
    代码评审机制,一定要有,而且是在开发阶段的前期就要做,并且所有开发人员都要参加,
    我们之前吃过亏,前期没有代码评审,后面全是bug和隐患。项目越大,越吃大亏。
  4. 总结&复盘会,本次迭代哪里做的好要保持,哪里做的不好,下次要避免。
    每次开周会,都需要recheck上周提的一些点。
  5. 技术分享,技术分享一定要搞,总结技术知识,会让大家的能力提升,包括演讲的人。
    持续让不同的人做分享,对于分享者和听众是双赢的,打造团队内部的分享文化,进行良性循环。

让员工除了在日常工作外还能有成长的空间,也是所谓的可持续性发展。

如果员工保质保量的做完了,能者多劳,又没有奖励机制,
又不给时间让下属学习,下属慢慢就会没有激情了。

注重团队的可持续发展,计划&工期不要安排的特别紧张,员工是人,不是工具,
不要累死一批再招下一批,招聘&培养&离职成本非常高,尤其是核心员工&leader。

leader要制定目标,中期目标,长期目标,
让团队有方向,有预期,让大家持续不断的成长。

预见性与路演

在项目初期-需求调研阶段,就要对风险点做预判,要有预见性,不要等到了那步再做决策,
提前做决策。需求分析时,先做一遍“路演”,leader先过一遍,识别自己团队内的风险点。

类似于第三方登录或者地图相关的地方,打好提前量,加强对风险点的把控,
准备充裕的时间以及人力资源做好调研以及相关的准备工作,因为你无法去控制其他团队的时间。

小步快跑而不是憋大招

憋大招的方式,搞的大家都很累,管理上也累,测试也累,开发也累,
一次性东西,逻辑太多,工作量太大,并且bug还多。
建议使用小步迭代的方式,往前走。

需求方想要的东西跟我们所理解的东西,是有可能存在奇异性的。

如果是憋大招,那我们的失败成本就特别高了。
这就是为什么我们要玩敏捷,要小步快跑,要迭代。

乙方主导需求(外包项目)

前期是甲方在把控需求,中期是乙方在把控需求。乙方要掌握需求的主导权,
不要甲方让你干什么你就干什么,不然会被坑死,项目进入了无止境修改的恶性循环中。
引用乔布斯一句话:“客户在没有使用产品之前,他们也不知道想要什么”,
所以我们要小步快跑,先走起来,再说别的。

审批需要提前量

把前期需要注册审批的东西都罗列出来,开小会碰,提前申请,不要等项目中期时再申请,
卡进度,因为审批需要时间。依赖外部环境的事情都列出来,提前做。
因为你无法控制外部资源,外部资源的优先级需要提高。

制定规范与流程

真正项目开始之前,要制定好自己团队的编码规范等等一些文档以及相关培训,来约束组员,
否则后续会有很多坑,对于拉完屎没开屁股的同事,改他们的代码会很艰难。
强调代码注释以及单元测试用例编写,并且强调不是代码的功能开发完毕之后才叫做完了一个功能,
而是测试通过后,才算做完。您传说中做完的功能,一测试发现20多个bug,那不叫做完了,
依然是没做完,并且这种人可以考虑请出团队(屡教不改的情况下 )。

开发很贵

作为技术leader,要有勇于发出“不要什么事情都丢给开发”的声音,因为普遍开发工程师的工资比较高。
让开发工程师去做一些测试或者其他廉价的工作,会让开发工程师的价值没有最大化,
开发心里不爽,也浪费了资源,双输的局子。

组织(organize)

决定需要做什么之后?怎么做?谁去做?
制定计划前要决策做什么,找合适的人来做,并告诉组员怎么去做。
你的决策需要有人去执行。
也需要跟大家商量,集思广益,自己的决策也可能是错误的,
一意孤行也许会众叛亲离。

千万不要相信你能统一大家的思想

因为那是不可能的,不要想方设法的脑JIAN别人。30%的人永远不可能相信你,
不要让你的同事为你干活,而让他们为我们的共同目标干活,
团结在一个共同的目标下,要比团结在一个人周围容易的多。

其实leader除了自己以外,无法真正的去控制任何一个组员,
他能做的只是引导、培养、达成共识、双赢。

不要把下属当成工具

每个人是有感情的,有心理需求的,需要被关怀的。注重员工面谈,
帮员工做未来职业规划,
跟员工培养感情(不是让你与女下属谈恋爱),与下属交朋友,把下属当成工作伙伴,
站在他们的角度上去思考问题,为他们着想,培养他们,团队管理,攻心为上,
这样团队才有凝聚力,区分什么是团队与团伙。

leader必须care下属的成长,leader要会激发下属。他们的成长是leader的核心价值体现。

无论什么项目,什么公司,员工都是项目的宝贵资源以及生产力,
需要爱惜他们、尊重他们、培养他们、挑战他们、让他们脱离舒适区、让他们成长。

千万不要认为你的下属就必须无脑听你的指挥,像你的仆人一样,招致则来挥之则去。

如果下属辞职不干,对团队与公司的影响与成本。。。要尊重下属。

当leader不要抠门,隔三差五的请下属吃吃喝喝,
体现你的人格魅力,这样团队氛围会更好一些。

定期面谈

leader需要定期(2-3周、1个月)一次做员工面谈,即使没有什么特别重要的事情也要做面谈,
让下属能感受到,自己是在被关怀的,这个团队很有温暖。

面谈非常重要,抓住面谈的机会,更加了解下属的机会。每个月都要去做。
并不是无情的对待员工,而是无情的对待指标。
帮助员工成长,是leader的责任。
对员工尊重与鼓励,激励。尊重别人,别人才会尊重你,服你。这是相互的。
面上服你,不代表心理服你。
让员工思考,leader要怎么做才能帮助员工解决问题。
leader要注重聆听,倾听,切入对方的心理需求。
可以拿出来一些可量化的绩效考核指标来跟员工进行面谈。
。多鼓励员工。
有些下属的心智模式还不太成熟,leader需要及时的矫正员工。

沟通要达成共识,非常重要。
常见话术:
我理解你的心情,
你有什么建议?

识别员工的真需求与伪需求。
总结沟通结果,做面谈汇总,对于员工的诉求我们满足不了的情况下。
leader需要疏通&引导员工的情绪,例如:还有比我们更不好的地方,和人,知足。
leader需要自己总结,以后该怎么办?怎么样能提升自己的能力,还有哪些需要加强?
不断提高自己的管理水平。
记录员工的诉求。
培训+绩效 = 让员工成长。
面谈要提前打好招呼,不要出其不意的。
面谈时需要双方都是最好的状态下。

清理负能量的员工

对于进度慢或者事儿多的组员,如果教育&安抚&面谈不行,那就第一时间换掉,
换更能胜任本项工作的人,负能量会传播,一定要多准备备胎,有备无患(备胎是私活情况)。

如果想开掉一个员工

首先,请不要轻易开掉一个员工,因为招聘成本太高了。之前有遇到过好几个周都在面试,
招不到合适的人,浪费了大量的时间和精力,得不偿失。

在团队中偶尔会遇到让自己很不爽的下属是一件很正常的事情,但如果很多下属都让自己不爽,
那就要去思考,是不是自己有问题,自己让别人不爽?

当下属出现错误时,leader需要第一时间发现&教育&谈话,
并记录下员工的问题,发生时间&背景,员工的态度,与员工沟通的结果等细节。

如果员工屡教不改,问题越来越多时,那我们就可以数罪并罚,结果就是把他请出团队。
如果只因为员工犯了一种错误就开掉他,会让其他人觉得你以点概面,
同时又没有容忍员工缺点的肚量,不是客观公正的态度来面对员工的问题。

需要给上级与hr报备员工问题的细节,以及你与员工沟通的过程与结果。
千万不要看谁不爽就开了他,这样上级领导和hr也会质疑你的领导力,
如果刚招进来一个新人,干了几个月就开掉,也会侧面证明自己的面试能力有问题,
识人辨人的能力有问题,甚至升华到自己的管理有问题。
plus,如果自己团队的人员流失率很高,也侧面证明自己的管理能力有问题。

并且正规的公司也会由上级领导&hr做全面的背调,除了2个当事人以外,
还会去单独询问团队内部的其他人,以求客观公正的面对问题。

当好面试官

面试时,作为面试官来说,要对面试者nice一些,因为这是双向选择,
给候选人留下好的印象,会增加候选人接受offer的概率,面试官是代表公司形象的。

一个优秀的候选人,肯定是许多家用人单位一起竞争的。
无论候选人的能力强弱,都要尊重对方。
简历会上有陷阱,包括他的学历,学习时间,工作年限,以及相关的项目,项目内容等等。

很多小孩都会把在校的练习项目的工作经验写进去,需要筛选项目是否为真实的工作项目。
面试题也可能会作假,类似于上网搜的这种。
项目经验中会有猫腻,需要关注开始时间和结束时间,是否有端倪。

有些小孩会把工作经验的时间写错,可能是故意的,需要甄别。
有的人其实没有任何工作经验,但还会写假的1-2年经验,为了蒙混过关,之前吃过这种亏,
需要给前任公司领导打电话,问一些细节问题。
要面试通过的人有需要可以上机做测试,且需要有背调。

简历中的pass项

每天会收到许多简历,如何快速甄别无效简历?

  1. 期望薪资太低,直接pass掉,对自己能力不自信,要的少,能力也差。
  2. 教育背景,是专科的院校,需要看当时的候选人情况,候选人多,就选本科甚至更高。
  3. 如果还没有毕业,则表示是在实习中,选择性pass。
  4. 年龄太小的,直接pass掉,一般心智不成熟的小孩会干出很多特别幼稚可笑的事情。
  5. 用4-5个月从培训机构出来的人直接pass了,通常基础都非常差,像一个月催大的鸡,你敢吃吗?
  6. 近期还在使用已经被淘汰&很古老的技术的直接pass,培训成本太高
  7. 对于工作年限不高,写xxx技术精通的人直接pass,对技术要有敬畏之心。

面试中的pass项

  1. 面试过程中沟通比较困难或者有gap的,直接pass,不然后续的沟通成本太高。
  2. 脾气太爆个性太强的人,直接pass,就算能力再好,不然会让团队鸡犬不宁。
  3. 被发现简历严重造假的人直接pass,例如学历、工作经历、年龄等等,做人,诚信为本。

给新人温暖

新人对于团队来说就好像是一张白纸,请让新人感受到团队是有温度的,
这样新人在日后的工作中也会更加的有激情而并非冷冰冰的混日子。

首先新人落地的第一天,需要由leader介绍给团队,团队需要有一种欢迎仪式,
让新人感受到温度和归属感,让他有一种被重视的感觉,生活还是需要有一些仪式感的。

然后带他认识一些相关的接口人和熟悉整个公司的环境,然后需要给这个新人指定一个老人带他,
如果新人带的不好,那么老人也要有连带责任。
当然了,新人落地前,要准备好团队的规章制度和流程规范,并且文档化,让新人看,减少沟通成本。

试水新人

对于新人,无论他的能力是高是低,都先分给一个小模块给他去试水,之后再做评估。
不要刚上来就分给他一个大的,这样他的压力会非常大,最后很可能坑死你。

要挑战下属,让他努力一些能达到目标,而不是制定太高的目标把对方坑死。

对不熟悉的组员,不要听他说自己多么牛,要逐步放权,其实有的人没有真才实学,耽误进度。

领导(command)

指导和激励组织成员,并且解决大家的冲突。
工作中避免不了各种冲突,需要在第一时间去化解冲突,调和气氛,打造和谐团队。

对组内成员都有清晰的认知,知人善用,并询问组员的诉求,
他想要的与你能给的是否能达成共识。

和谐是打造有竞争力的团队的第一步。
团队成员的问题都是领导的问题,如何让他们试错,知错,改错,放权,让他们成长,

他们做错的时候你会指导他们,并挑战他们,爱一个员工的最好方式就是让他们成长。

所谓职位越大,权利越大,责任越大,
下属犯的错误,责任都是leader的。

leader需要勇于承担下属犯的任何错误。leader没有教育培养好下属?没有用好下属?
没有跟下属沟通好?没有严格要求下属?

anyway,下属的问题,先想想leader自己有没有问题。

愿你是个好leader

leader是团队的灵魂,一个leader的能力会决定团队的能力上限,
正所谓兵熊熊一个,将熊熊一窝。

我个人认为,一个好的leader应该是可以很好的把控项目的质量与进度,在项目出现危机时,
是临危不乱的,他不会遇到大事小情都往领导那反馈, 因为他知道,什么事情都要领导来搞定,
那他的价值就无法体现,他的价值就是体现在他到底能抗住多少事儿,帮下属抗多少事儿。

他对于团队的组员的协调以及同事关系处理上,完全没问题。
他有人格魅力,要能很好的沟通能力与理解能力,同时还得会做人。
他会起到一个承上启下的作用,如何处理好上下级关系,是一门学问。

项目的成功与失败,与他密不可分。项目出现任何问题,他都有解决方案来对应。
并且他是团队里最负责的。他的控制能力要很好,能把项目玩弄于鼓掌之间。
就像马云说过,宁可让一流的项目经理做三流的项目,
也不让三流的项目做一流的项目。前者会做成二流甚至一流的项目,而后者只能做成三流的项目。

然而,他所站的位置越高,他所可能犯的错误越多。因为这个部门所有出现的问题都是他的问题。
他决策错误,是他的问题,他执行不够,是他的问题,员工执行错误,也是他的问题,员工不合作,
也是他的问题,员工无能,还是他的问题。他承受了这个部门所有的问题。

技术管理者的核心价值在于技术和管理的结合。如果丢掉了技术,那么就丧失了核心竞争力。
如果你的技术背景丧失了,那么你怎样带领,指导一个技术团队完成技术性很强的软件开发工作呢?

leader需要为团队设立一个明确的、可量化的、科学合理的、具有挑战性的目标,
并且这个目标必须要得到大多数团队成员的认可。目标定的太低没有挑战性,没有激情,
目标定的太高大家会觉得是不可能完成的任务,而中途放弃,那目标就变成了一种形式主义。
组员认可与接受这个目标,愿意为之付出努力去完成,才有可能完成这个目标。

作为技术负责人,需要建立一种技术文化,技术&学习氛围,做好内训&技术分享,做好技术交流,
培养大家良好的工作习惯。还要对技术比较敏感,给大家指明方向。宣传推广公司的技术形象,
需要吸引更牛逼的技术人员进来。

leader三要素:业务,技术,管理,管理是情商,技术是智商。

那这正是你价值体现的地方,
不要害怕组员的成长超过了leader的成长,如果你能让一个组员快速成长,
在这里你有能力带好团队,那么在别的地方你依然可以有这个能力,快速复制一个团队。

要求下属做到的事情,要自己先做到

这一点非常非常重要,用自己的人格力量带动下属,争取同事以及下属的敬重。
自己都做不到的事情,千万千万不要要求下属做到,
例如:自己都懒得写日报,那就不要要求别人去写。
自己开会看手机,就不要要求别人开会时看手机。
自己总隔三差五的迟到但总要求下属不能迟到,要扣绩效等等。

管理别人的前提是先管理好自己,用自己的行动来给下属做榜样。

言出必行

很多leader喜欢给下属画饼,例如:指标达到多少多少我们就去高档酒店吃大餐,
就去欧洲旅行,就去什么什么。

然而等下属被激励后,充满了激情,整个团队努力的完成了目标后,leader又变卦了,
这种leader以后再说话,就没有权威性了,大家慢慢的也就失去了激情,
leader嘴里说出来的承诺就去落地,要不然您就别说,
有承诺就会有期待,不要让下属总是失望,所谓的“不落地都是吹牛逼”。

总结&复盘失败教训

所有的失败都是有利于帮助我们成长的。
既然选择走上技术管理道路,无论前途是否艰难,都要咬着牙走下去,只要别人不赶你,
你就做下去。如果不吸取失败的教训,那么失败就仅仅是失败。

当团队很差时,反省自己而非指责别人

作为一个leader,认为团队不好,不应该去指责团队,
而应该反思自己,从自己身上找原因,不要到处甩锅。

定期谈话&沟通

leader需要主动发起谈话&沟通,因为下属大多数是腼腆的,不会主动与领导发起沟通。
下属有什么问题与痛点,大多数也是藏着掖着,不会跟领导当面说。
而领导与下属没有建立有效的沟通就会导致,领导不知道下属想要什么,
而自己又能给予下属什么,最后导致下属离职。leader要思考自己能给下属什么,
钱?快乐?能力?成长?激情?梦想?
还是什么也没有?与员工保持顺畅沟通,大家的团队目标一致,心往一处想,劲往一处使。

勇于替下属背锅

当管理者把工作布置给下属后,下属遇到了困难,或者没有办好,上级指责和追究时,
管理者要主动承担责任,为下属解决疑难,不要推卸责任,或训斥批评下属,
只有这样才能赢得下属的信任。也只有这样,下属才能放开手脚,干!
管理者的工作也才能顺利展开。

公平公正的对待每一名下属

当leader要做到公平,别一碗水端不平,让大家说闲话,
让大家觉得某个人有特权,
不利于团队健康发展,因此要本着公平的原则对待每一个员工。

让员工成长

不要蜀中无大将廖化作先锋,
不要让自己变成团队的瓶颈(所有的东西都是自己捏着,自己请假后流程瘫痪),
下属在解决问题或加班的时候,leader要跟大家站在一起,但绝不能事必躬亲。
员工的成长是需要过程的,不能立竿见影,leader要有耐心。

项目大的话,需要放权给组员,让组员来管理某些模块。不然会像诸葛亮一样累死,
学会放权与培养组员,培养下属独立思考和自主判断的习惯。

不要让两个组员的管理权限有交集,容易造成内部矛盾。
切忌不要立刻过大放权,要循序渐进并暗中观察。

爱一个员工最好的方式,就是让他成长,他在你的领导下,有没有变得更强?
要适当挑战员工,脱离舒适区,但总挑战也会有反作用,所谓物极必反,度自己拿捏。

不要跟他翻来覆去讲太多道理,如果他不认可你,那你就让他去快速试错,让他摔倒一下,
然后你帮他爬起来,然后告诉他这里有坑,加深他的印象,这样他也会更服你。

该挑战的时候就挑战一下,不该挑战就不要挑战,
要换位思考员工的心理,不要让对方很没面子,尊重每一个人。

叫到小黑屋里怎么骂都行,但是在外面一定要给员工留面子。
尊重每一个员工,对员工说话和蔼可亲一些,谁都不欠你什么,选择也是双向的,
员工也有权利say no。

制定考核指标

制定ORK、KPI,制度要有考核,员工犯错的时候要记录在绩效考核上。
职责与绩效需要挂钩,绩效需要把这些工作任务进行量化,然后对员工进行面谈,拿数据说话。

批评的艺术

解放初期,人们的思想比较单纯,批评与自我批评在全国遍地开花,
那个时代的批评可能会被大家接受。但在强调个性与自我意识的今天,
直接批评只会招致对方的不满和愤怒。因此卡耐基提出了通过正面鼓励,
让人们意识到自己的问题,并积极的改进,比指责和批评更容易被人们接受,效果也会更好。

当被下属挑战

遇到表现欲强&能力强&情商不高的下属,会被挑战,
作为领导要有一颗包容的心,比下属更广阔的胸。
对于经常爱挑战领导的员工,会有压力,可能会面子挂不住,但事情都是有两面性,
他也会帮助我们快速成长。那么下面问题来了,你是想跟着员工一起成长接受他的挑战,
还是把他挤走不让自己成长。。。

低效的开会是一件很浪费的事情
如何高效?会议的目的是什么?参会人是谁?结论是什么?哪些内容需要在会议上讨论?
哪些不需要?会议后的结果有没有人去跟进?如果没有结果又或者收效甚微,那会议的意义何在?

刚柔并进,双重人格

有制度,有原则,有人性,双重人格是每个领导的铁布衫。

该强硬的时候强硬,该柔和的时候柔和。

管理风格不要非常严格严厉(除非你的能力真的非常非常强),
否则大家都吃不消,最后众叛亲离,至于尺度,自己把握。

平时多搞好关系,说话的时候和蔼可亲一下,会增加亲和力。
如果总是一脸严肃,大家跟你会特意保持一定的距离,团队就没有凝聚力了。

适当的请大家喝饮料吃饭喝酒等,搞好关系,和谐的团队才有竞争力。

学会换位思考

尤其是批评下属的时候,记得不要当着别人的面,伤害下属的自尊心。
另外谁都不傻,不要把员工当傻子。
leader需要学会换位思考,尤其是批评下属的时候,记得不要当着别人的面,伤害下属的自尊心。
另外谁都不傻,不要把员工当傻子。
如何留住有价值的员工?细节不展开了。主要是学会换位思考,如果你是他,你会怎么想,
给你什么你才会留下来。如果得出的结论是没有办法挽留住,那就放。

不要当劳模

劳模最擅长凡事带头干,干的最多,
但他却不能培养激励和培养下属。真正优秀的领导是能让下属成为劳模的人,而不是自己当劳模。

此外管理者不要参与开发工作,因为整个项目必须有一个人是站在最高的位置上,审视全局,
给船掌舵的人,把握好宏观的度,这样才能控制好项目的总体进度。
如果没有这个人,很容易项目的方向就会发生偏移。
但并不代表管理者就不懂开发,技术管理者必须要懂开发,而且非常懂开发才能服众,
大家跟着你才会有信心。项目前期管理者可以介入编码工作,跑在一线,鼓舞士气。

团队需要有激情

团队需要有激励机制、绩效考核机制(OKR还是KPI),团队需要有一些激情。
一个职位做好几年,员工对工作的新鲜感就会逐渐消失,表现出工作积极性不高,反应迟钝,
效率降低等现象,如何有效的提高员工或团队的士气,我们需要激励机制,
奖金或者是升职或者是团建或者是?

不要教条主义

不要认为自己什么都是对的,自己的下属肯定在各个方面都不如自己。
事实证明,leader不一定什么时候都是对的。

如果这个世界一直秉承着教条主义,那直到现在,我们还认为地球是方的,地球是宇宙的中心。

有一些年纪和经验不如我们的下属,会提出一些积极的意见或建议,
不要轻易磨灭他们那颗炙热的心,认真听取他们的理由,并积极的做配合和响应。
所谓心胸大的人能听得进去不同的声音。

高效开会

开会的目的是大家一起讨论,获得结果,
但它会消耗大家的时间,成本比较高。

很多时候,人们开会的目的不够明确,以至会议期间得不到共识,只是白白浪费时间。

为了让会议有成效,应该先让所有与会者明白究竟要做什么,而主持人在发出开会通知前,
应该先问自己这样的问题:
这个会议是否真的重要,即使中断很多人的工作也值得?有没有

比开会更好的方式?
这次会议的目的是什么?我该怎样做才能达到目的?
不要让开会变成漫无目的的讨论。

大家开会要有会议纪要,并保存到一个地方。
开会的东西不落地就没有必要开了。

工期紧不要尝试太多新的东西

工期紧张的项目,千万不要尝试太多新的技术,
新技术或新的模式(对于团队来说)往往会有一些坑,
而这个填坑的过程可以会导致整个项目delay。

同理,不要乱拆项目,乱升级项目,时间和人力成本不允许,
步子迈的太大容易扯到蛋,压力会非常大,大家也会质疑你的领导力。

不要总是做临时决定

晚上不要把新的工作委派给别人,不要总是安排临时任务,委派任务时,需要先预计完成时间。

需要安排时间定计划的时候,宣告,然后商量的口吻,因为民主的力量是很强大的。

有些举棋不定的决策。临时想起来的东西,等总结会的时候提出来,
下次在跑,不要临时想起来,就临时做,
否则下面会质疑你的领导力。

写周报

作为leader一定一定要写周报,将目前项目的进度、下周的计划、遇到的问题等内容发给领导,
抄送给相关接口人(包括在一起大项目中的同级leader)和团队成员,让大家感受到你的专业。

传输给下属正确价值观

1.好记忆不如烂笔头

把临时的事情记录在本子上,然后再去转化&复盘,不要记在脑子里,脑子很容易忘掉,
如果一个人总是丢三落四,忘这忘那的,那团队会质疑你的能力,尤其是leader。

2.集体荣辱观

一荣俱荣,一损俱损。大家都是一条船的。好好干!塑造共同目标,以结果为导向,
最后看的是结果,结果是集体的,不是个人的,这才是团队。

3.责任感很重要

不能说发现了一个问题,不是我负责的,我就不管了,要通知到当前责任人,使用打电话的方式,
不要丢到那就不管了。。。有歧义的时候,主动打电话,不要这个事情不是你的责任,
你就不通知了,不要发短信,微信,QQ的形式,因为对方可能看不到,直接打电话效率最高。
要把这种思想,传达给每个组员,强调主观能动性。

职位越高、权利越大、责任越大,从小培养团队的责任感,为大家以后的成长铺路,养成良好工作习惯。

4.要有ownership精神

告诉组员,自己的代码出现bug之后,求人,丢给别人改是一件很丢人的事情,要有ownership精神,
owner担负起责任,这才是一种成长。

主动承担难的工作任务,主动提出新的想法,这样的人会更优秀。

5.出bug后抱有歉意

自己的代码出了bug,需要有一种愧疚感&责任感&歉意,而不要是一种无所谓的态度,
不就是出一个bug嘛,谁还能不出bug,改不就完了嘛,千万不要有这种心态。

6.不要无脑编程

告诉组员,千万不要无脑编程,在开发的时候多思考,站在用户的角度上去思考问题,
一定要定期做代码评审工作,等到最后一定会吃大亏。

7.尽早沟通,主动沟通

使得问题早发现,先处理,避免发展到了无法收拾的局面,并在解决问题的方法上先有对策,
在沟通中占据主动的地位。

8.沟通必须是双向的

沟通非常重要,沟通不畅会导致非常多的问题,也可以直接影响项目的成功与失败。

例如你想往东走,他想往西走,最后你们俩在沟通后还达成了共识,那真的非常非常可怕。

必须保证信息被接受者接到。所有的沟通方式必须有反馈机制。

如果沟通的接受者收到的信息是有歧义的,那责任在于沟通的发起者。

9.当面沟通是最有效的沟通方式

没有之一。俩人都就坐对面,沟通时必须要发一封mail吗?必须要发一条微信吗?
可以直接叫他一下吗?mail是为了存档留证据用的。

10.与甲方保持沟通

在项目执行过程中(外包项目),仍然需要加强沟通,让客户及时了解项目的进度,
以及项目中出现的问题和困难。即使项目中出现了没有预料到的困难,通过和用户的协商,
也能够得到有效的解决办法。

11.与外部团队沟通要留证据

与组外人员沟通时,必须要电话&当面+邮件的形式,必须要再三确认准确无误,
并留好证据,这块我们吃过大亏。

控制(control)

leader的主要职责其中有两项:搞定项目的质量与进度,
那你怎么做能控制住能hold住质量与进度,
怎么做会失控?失控非常可怕,就像开车的时候刹车失灵一样。那后果是可想而知的。。。
控制得好,项目的进度与质量都有保障,否则。。。

对任务进行监控,确保其按照计划完成。
我们的目标是本月完成上线,那如何控制好进度,保证月底上线呢?
每周&每日的成果物节点或里程碑check?及时良好的沟通等一系列机制来保证,我们可以上线。

收集工作日报&抽查工作

收集员工日报,通过检查员工日报可以看出很多东西,
例如:时间管理、进度控制、工作饱和度等等,leader要去抽查员工的工作内容,
让员工提高警惕,让员工对自己的质量负责。结果导向,工作有没有达标,
有没有再进一步提高的可能?激发员工的潜能。

不定期抽查组员的工作,尤其是那些不让你放心的组员。
工作需要可视化,可量化。ok,你说你做完了?能在测试环境上看吗?
接口都写完了没有可视化的界面,ok,测试用例跑一下,覆盖率达标吗?性能达标吗?

培养团队精神

精益求精,是为了自己,而不是为了公司,打造双赢理论,要让每个员工知道这一点。
传达团结精神,在企业中培养起团结互助的精神,鼓励员工们协作完成某些任务,
以团队目标作为导向,而不是大家都处于竞争状态,各自为营,信息孤岛。

不要每天都加班

不要留给员工一种错觉,天天要加班,不加班就不对。
长时间不间断的加班会使得团队的效率大幅度降低,
甚至大家都在混时间,反正也要加班,不如抻着做,适得其反。

建议结果导向而非过程导向,当然也可以有必要的加班,度需要自己拿捏。
晚上不要把新的工作委派给别人,不要总是安排临时任务,委派任务时,需要先预计完成时间。

没有人能总像上了弦的机器人,总是对工作充满热情。等到他休息够了,
自然会精力充沛的迎接工作的挑战。长期的紧张工作和长期的工作散漫都不利于企业的长久发展,
只有张弛有度,企业用人方能长久。

同是我们需要尝试去降低工时,哪些该做?哪些不该做?
找到浪费时间的工作,例如那些费劲开发&测试过的功能,结果因为种种原因没有人用。。。
那就是大大的浪费,保质保量按时完成都变得没有意义。

deadline是项目进度的最强推动力

如果是外包项目(包括私活),别告诉组员真正验收的日期,把这个日期提前一段时间(1-3周),
这1-3个星期作为buffer(缓冲期),这样整个项目压力会小很多,定好每个模块完成的时间,
小时间节点要卡住,如果按你定的时间完成任务,其实属于提前完成,你可以申请项目奖金。

否则也属于正常进度,你跟team说现在项目已经延期了,需要再加把劲。(其实是正常工期)
这种善意的欺骗对项目管理者来说,压力会小很多。deadline是项目进度最强推动力。

学会抓大放小

学会抓大放小,不要追求十全十美,注意把控大局,不要被一个非核心点卡住,
然后卡非常长的时间导致核心点delay,最后整个项目delay,小功能有问题,先放一下,
继续往前赶路,先把核心流程串起来,之后再完善之前的遗留项,
跟期末考试不要被小题卡住是一个道理。开发过程中,如果发现有攻坚问题或者技术壁垒,
一定要给自己设置一个时间节点,过了这个节点,如果没有结果,也先PASS,不要卡住,
其他功能都开发完之后,再回过头来处理,前期不要太关注例如界面美化这种问题,
聚焦在流程是否跑通等核心业务上,把这个思想传达给组员。

早发现早治疗

每天开例会,碰进度等,需要组员编写日报,leader编写周报。有问题及时抛出,早发现早治疗。
遇到自己无法hold住的问题,第一时间上报给上级领导,周会上给领导做汇报,
问题发现的早,对于所有人来说压力都小,一旦在后期集中爆发各种问题,那将是一场灾难。

积极面对失控

一旦遇到失控情况,首先leader要保持头脑冷静,沉着冷静客观的面对问题,
浮躁&吐槽&抓狂等是无法解决问题的。
失控后,及时与相关人员(包括上级与下属)商讨对策,亡羊补牢,为时不晚。

不要悲观,因为悲观情绪是可以传染的,尤其是对于leader来说,
你可以假装,但是一定要让团队里的人看到,leader永远是积极向上的。

如果是工作量估算错误或风险点把控不准,
可以往项目里填人或商量减需求或加班或换一种解决方案。
事后一定要及时总结与复盘失控原因,不要重复入坑。

使用管理工具

必须要使用项目管理软件,例如持续集成工具、bug&质量管理、项目&进度管理+成本管理等,
可以考虑禅道+project。

卡住里程碑时间节点

小时间节点要卡住,卡准,有delay就加班或填人,或减需求,如果不卡的话,每个里程碑都delay,
顺延到最后会拖垮整个项目,整个项目大量的delay,失败。

注重测试

引入专业测试人员进行白盒,黑盒测试,并且与开发组同步,需要前期编写出测试文档:
包括测试计划、测试用例等等。测试力度不够,会直接影响你的项目的健壮性。
这里说的测试不单单是功能测试,还有性能测试。
通过专业的测试工具,例如loadrunner或jmeter等等。如果是互联网项目必须要用自动化测试。


一些真实案例

人们往往在顺境的时候,沉不下心来,总结的东西自然是很虚的东西。
人们往往在逆境的时候,总结的教训才是深刻的,才是真的。
以下是我在做软件项目外包创业时(我是创始人之一)遇到过的真实管理问题。

3 故事一,过度放权被坑

曾经有个下属A(周XX),性格比较刚烈、豪爽,但编码的能力还凑合。
后来有一个APP的外包项目开始启动了,在当时的环境下,需要定服务端的leader,
安卓端的leader,IOS端的leader,而A则是服务端leader的最佳人选,当时我比较信任A,
因为A之前的表现还算良好,于是我任命了他作为服务端的leader,并且由于我手头的杂事比较多,
就没怎么去check过他的工作,并给A分派了几个下属听他指挥,本以为可以放权,让他hold住全场,
且让他从这个项目中快速成长,成为公司的中坚力量,但。。。我错了。。。

我们每周几个leader都要开周会碰一下项目的进度以及问题,刚开始A还比较好,比较符合标准,
但到了项目中期,A就开始产生大量的负面情绪,例如:抱怨加班时间长,创业太累,
没时间陪家人,薪酬太低等等。复面情绪会传染,因此需要第一时间去进行安抚,
我当时几乎每天要花2个小时左右的时间安抚他的情绪。耗费了我大量的精力与时间,
但当时又是骑虎难下,没有其他合适的人选,除了我之外,而当时我又在谈其他的项目,
根本抽不出身,所以就没有把他换下来。

到了项目中后期,我开始有些不安,我主动的去check项目的进度&质量,
安卓和IOS两个组并没有让我很操心,但服务端组让我非常失望&生气,因为bug非常非常多,
当时又恰逢过年,大家的状态都是想赶紧回家过年,
没有办法,最后由我亲自揽起服务端的大头,开始改bug,甚至很多代码进行了重写,
从大年初一到正月十五,我几乎是在恐慌与疯狂工作中度过的,因为年后项目就要验收了,
给我们的时间非常非常少,当时压力非常大,
每天都要抽将近2盒中南海以及晚上喝半瓶伏特加才能睡着(鬼知道我经历了什么)。。。

故事二,过度责备,导致下属离职,后果惨重

曾经有个下属B(吕XX),他并不是leader,只是一个普通程序员,
当时我们在做一个XX油田的项目,因为是驻场开发,到了项目后期,我们的大部队要撤了,
但需要留守一个人作为甲方与乙方的接口人,B之前也算比较靠谱的类型,于是我们选择留下了B。
我跟B说:“你的任务很简单,就是每天给我发日报,甲方有什么问题,你能解决的就解决,
不能解决的就上报”,以及一些其他的琐事。B答应的非常痛快,我们都觉得他很靠谱,
然后就撤退了。

等我们撤退完毕后,我发现B几乎没有给我发过任何日报,
并且我通过一个甲方处的很好的哥们口中得知,B在我们走之后,每天经常看跟工作无关的网站,
总打电话聊QQ等等,并且甲方出现问题经常在工位上找不到B,让我非常生气。

有一天我的小火山喷发了,给B打电话,劈头盖脸的一顿骂(没有带脏字,但非常非常非常严厉),
骂的小伙子目瞪口呆,狗血淋头,哑口无言,骂了将近半个小时。。。
我本以为小伙子会痛改前非,努力工作,没想到。。。
B要离职。。。并且怎么劝都没有用。。。 那么问题来了,谁来接他的班?


总结

每个人的能力,在其他人的心中都有一杆秤,是好是坏,大家心里都有数,但并不会说出来。

能力这种东西,是骗不了人的。而技术管理对大家的能力要求较高,
希望大家快速提高自己的各项能力,及时总结&复盘,在日益激烈的职场竞争中脱颖而出。

猜你喜欢

转载自blog.csdn.net/piantoutongyang/article/details/89639128