偏头痛杨的技术团队管理经验总结(持续更新)

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

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

程序猿的职业发展规划,我个人认为可以有这样一条路。
应届毕业生->
实习生->
程序员->
组长&主管->
技术经理&项目经理&架构师->
技术总监->
CTO&技术VP&技术合伙人

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

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

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

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

本文内容持续更新中。。。


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


故事一,过度放权被坑
曾经有个下属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要离职。。。并且怎么劝都没有用。。。 那么问题来了,谁来接他的班?


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

管理是指同别人一起,或通过别人使活动的过程完成得更加有效的过程。
这里,过程的含义表示管理者发挥的职能或从事的主要活动。
这些职能可以概括的称为:
计划(planning)、组织(organizing)、领导(leading)和控制(controlling)。
简而言之:管理就是通过计划、组织、领导、控制的方法和他人共同完成某个目标的过程。

计划(plan):确定目标,制定战略
本周团队的任务是什么?每个人的任务是什么?团队的目标是什么?下个月的目标是什么?
今年的目标是什么?制定了目标后,需要让团队成员达成共识,然后如何去使这个目标落地?
切忌目标不要定的太飘渺,否则累死大家也做不到,会让士气低落。

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

领导(command):指导和激励组织成员,并且解决大家的冲突
工作中避免不了各种冲突,需要在第一时间去化解冲突,调和气氛,打造和谐团队。
对组内成员都有清晰的认知,知人善用,并询问组员的诉求,他想要的与你能给的是否能达成共识。
和谐是打造有竞争力的团队的第一步。
团队成员的问题都是领导的问题,如何让他们试错,知错,改错,放权,让他们成长,
他们做错的时候你会指导他们,并挑战他们,爱一个员工的最好方式就是让他们成长。

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


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

职位越大, 权利越大, 责任越大
下属犯的错误,责任都是leader的。leader需要勇于承担下属犯的任何错误。
leader没有教育培养好下属?没有用好下属?没有跟下属沟通好?没有严格要求下属?anyway,
下属的问题,先想想leader自己有没有问题。

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

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

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

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


沟通篇
沟通非常重要,沟通不畅会导致非常多的问题,也可以直接影响项目的成功与失败。
例如你想往东走,他想往西走,最后你们俩在沟通后还达成了共识,那真的非常非常可怕。

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

沟通必须是双向的
必须保证信息被接受者接到。所有的沟通方式必须有反馈机制。
如果沟通的接受者收到的信息是有歧义的,那责任在于沟通的发起者。

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

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

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


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

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

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

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

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

技术管理者的核心价值在于技术和管理的结合。如果丢掉了技术,那么就丧失了核心竞争力。
如果你的技术背景丧失了,那么你怎样带领,指导一个技术团队完成技术性很强的软件开发工作呢?
 
leader需要为团队设立一个明确的、可量化的、科学合理的、具有挑战性的目标,
并且这个目标必须要得到大多数团队成员的认可。目标定的太低没有挑战性,没有激情,
目标定的太高大家会觉得是不可能完成的任务,而中途放弃,那目标就变成了一种形式主义。
组员认可与接受这个目标,愿意为之付出努力去完成,才有可能完成这个目标。

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

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

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


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


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

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

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

千万不要认为你的下属就必须无脑听你的指挥,像你的仆人一样,招致则来挥之则去,
如果下属辞职不干,对团队与公司的影响与成本。。。要尊重下属,要爱他们,让他们成长。


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

要求员工做到的事情,要自己先做到
用自己的人格力量带动职工,争取同事以及员工的敬重。自己都做不到的事情,
千万千万不要要求下属做到,例如:自己都懒得写日报,那就不要要求别人去写。
自己开会看手机,就不要要求别人开会时看手机。

当团队很差时,反省自己而非指责别人
作为一个leader,认为团队不好,不应该去指责团队,而应该反思自己,从自己身上找原因,
不要到处甩锅。
 
定期谈话&沟通
leader需要主动发起谈话&沟通,因为下属大多数是腼腆的,不会主动与领导发起沟通。
下属有什么问题与痛点,大多数也是藏着掖着,不会跟领导当面说。
而领导与下属没有建立有效的沟通就会导致,领导不知道下属想要什么,而自己又能给予下属什么,最后导致下属离职。leader要思考自己能给下属什么,钱?快乐?能力?成长?激情?梦想?
还是什么也没有?与员工保持顺畅沟通,大家的团队目标一致,心往一处想,劲往一处使。

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

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

不要每天都加班
不要留给员工一种错觉,天天要加班,不加班就不对。
长时间不间断的加班会使得团队的效率大幅度降低,甚至大家都在混时间,适得其反。
建议结果导向而非过程导向,当然也可以有必要的加班,度需要自己拿捏。
晚上不要把新的工作委派给别人,不要总是安排临时任务,委派任务时,需要先预计完成时间。
没有人能总像上了弦的机器人,总是对工作充满热情。等到他休息够了,
自然会精力充沛的迎接工作的挑战。长期的紧张工作和长期的工作散漫都不利于企业的长久发展,
只有张弛有度,企业用人方能长久。

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


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

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

该挑战的时候就挑战一下,不该挑战就不要挑战,要换位思考员工的心理,
不要让对方很没面子,尊重每一个人。叫到小黑屋里怎么骂都行,但是在外面一定要给员工留面子。
尊重每一个员工,对员工说话和蔼可亲一些,谁都不欠你什么,选择也是双向的,
员工也有权利say no。


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

预留buffer时间让下属学习
leader在制定计划的时候一定要预留buffer时间,制定计划不要可丁可卯,
不要给自己给团队非常大的压力,因为在日常工作中经常会出现打断的事情,
例如排查一个线上的问题,解决一个其他同事的问题等等。
每天的工作不仅仅是满负荷状态在运行,
那一旦解决了其他的事情而导致今天该完成的工作没有完成,就只能加班。
天天加班势必会造成士气低落,因此需要有一些buffer时间,如果进度非常健康,
那这些buffer时间可以用来让下属调研新技术,
之后再让下属分享给团队,是双赢的,切记要让下属调研的东西与团队需要的东西是一致的,
要双赢,而不是单赢。
如果员工保质保量的做完了,能者多劳,又没有奖励机制,又不给时间让下属学习,
下属慢慢就会没有激情了。

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

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

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

刚柔并进,双重人格
有制度,有原则, 有人性,双重人格是每个领导的铁布衫。
管理风格不要非常严格严厉(除非你的能力真的非常非常强),
否则大家都吃不消,最后众叛亲离,至于尺度,自己把握。
适当的请大家喝饮料吃饭喝酒等,搞好关系,和谐的团队才有竞争力。


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

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


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

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

不要总是做临时决定
需要安排时间定计划的时候,宣告,然后商量的口吻,因为民主的力量是很强大的。
有些举棋不定的决策。临时想起来的东西,等总结会的时候提出来,下次在跑,不要临时想起来,
就临时做,否则下面会质疑你的领导力。

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

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

试水新人
对于新人,无论他的能力是高是低,都先分给一个小模块给他去试水,之后再做评估。
不要刚上来就分给他一个大的,这样他的压力会非常大,最后很可能坑死你。
要挑战下属,让他努力一些能达到目标,而不是制定太高的目标把对方坑死。
对不熟悉的组员,不要听他说自己多么牛,要逐步放权,其实有的人没有真才实学,耽误进度。


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

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


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


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

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

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

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

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


量化篇
量化与执行是我们解决问题的方法与手段。我们要完成一件复杂的工作,或实现一个较远的目标,
需要对实现过程进行具体的计划和安排,并按照计划进行强制执行,最终实现目标。
那么如何量化什么是好?什么是不好?
 
不仅仅是在软件开发的项目中,我们要完成任何一个复杂的事情,
都要想办法将其量化成为可以操作(执行)的具体步骤。

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


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

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


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

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

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

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

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

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

最好派个BSE去甲方现场,有可能的话尽量常驻,在现场跟用户零距离的沟通。
这样甲乙双方都踏实。


需求文档
需求文档的编写,是一门学问,编写完成后,需要组内会议讨论,看看是否描述的有歧义点,
避免导致以后的问题隐患。

小步快跑而不是憋大招
甲方都是外行,不让他看到UI,他自己也不知道是怎么回事。
所以乙方描述的需求,和甲方真正想要的需求,是存在歧义的。
这就是为什么我们要玩敏捷,要小步快跑,要迭代,而不是憋大招。

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

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


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

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

deadline是项目进度的最强推动力
如果是外包项目(包括私活),别告诉组员真正验收的日期,把这个日期提前一段时间(1-3周),
这1-3个星期作为buffer(缓冲期),这样整个项目压力会小很多,定好每个模块完成的时间,
小时间节点要卡住,如果按你定的时间完成任务,其实属于提前完成,你可以申请项目奖金。
否则也属于正常进度,你跟team说现在项目已经延期了,需要再加把劲。(其实是正常工期)
这种善意的欺骗对项目管理者来说,压力会小很多。deadline是项目进度最强推动力。

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

代码评审
代码评审机制,一定要有,而且是在开发阶段的前期就要做,并且所有开发人员都要参加,
我们之前吃过亏,前期没有代码评审,后面全是bug和隐患。项目越大,越吃大亏。

预见性与路演
在项目初期-需求调研阶段,就要对风险点做预判,要有预见性,不要等到了那步再做决策,
提前做决策。需求分析时,先做一遍“路演”,leader先过一遍,识别自己团队内的风险点,
类似于第三方登录或者地图相关的地方,打好提前量,加强对风险点的把控,
准备充裕的时间以及人力资源做好调研以及相关的准备工作,因为你无法去控制其他团队的时间。

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


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

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

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


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

适当放权
项目大的话,需要放权给组员,让组员来管理某些模块。不然会像诸葛亮一样累死,
学会放权与培养组员。不要让两个组员的管理权限有交集,容易造成内部矛盾。
切忌不要立刻过大放权,要循序渐进并暗中观察。

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

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

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


创业篇
创业在这篇文章中是意料之外却又在情理之中。说成功学我没有资格,因为我没有成功过,
但是说创业说失败我有资格,因为我创过业,并且失败过,不止一次。

甲方不给结尾款
如果您是自己创业开外包性质的软件公司,您一定要接受一个现实,
那就是甲方很有可能不会给您结尾款,无论项目成功与否,并且如果打官司会把你拖死。
那需要有什么机制吗?自己想。想明白了再创业。

创业非常痛苦
如果您选择了创业,您一定要记得,创业是一件非常痛苦的事情,成功也是非常痛苦的事情,
可能会天天不睡觉,您确定是否要创业? 并且选择创业后,您将得到什么?又将失去什么?
都应该好好想一想。您可能非常非常努力的创业,所有的时间都用来做跟创业相关的事情,
可能会失去了青春、亲情、友情、爱情,最重要的是:结果不一定会成功。
创业前一定要问问自己的内心:“我为什么要创业?”,如果我现在不创业,我活着就没有意义,
我必须要证明我自己是可以的,我不创业就会死,那就开始吧。

创始人要资源丰富
作为一个创始人,知识面一定要广,人脉广,手里可运用的资源较多,
不然在创业过程中会捉襟见肘,失败率也会大大提升。

多读失败学,少读成功学
大家知道马云牛逼,但是有多少个"马云"死在了路上?
成功学可能会让大家有浮躁,飘飘然的感觉,但失败学可能会让大家陷入思考,正视自己,
权衡利弊。不要拿自己的弱项去跟别人的强项竞争,而是拿自己的强项与别人的强项与合作。
认清自己的优缺点很重要。

学会分享
钱不是一个人赚的,要学会分享。别拿大家当傻子,谁都不傻,每次都是你赚钱,
最后会众叛亲离,切忌不要利益最大化。

创业者三要素
作为创业者所必备的三项基本要素:
1.多面手;
2.对创业有激情;
3.具有很强的内部&外部资源的整合能力;

先抄过来再说
很多东西不用设计,业界已经有很多成熟的案例,先抄过来,快速落地,小步快跑,逐渐迭代,
设计很长时间发现还不如抄的快。

纯技术人不易做CEO
不建议纯技术人作为CEO主导创业,但可以作为技术合伙人的身份进行创业,
CEO需要有商业头脑、资源整合能力、较高的情商,且创业中蕴含了非常多的知识点,
包括市场、销售、运营、产品、人力资源等等等等,而这些往往是纯技术人的弱项。


技术&工具篇
项目管理:禅道,project;
缓存:memcache,redis;
消息队列:activemq,rocketmq,rabbitmq;
持续集成:jenkins;
代码质量检查:pmd,checkstyle,findbug;
web服务器:nginx,apache;
应用服务器:jboss,tomcat,resin;
数据库:mysql;
远程通讯:netty;
文本编辑器:kindeditor;
富客户端框架:easyui;
数据证书:x.509,可用于class文件加密;
java开源论坛:jforum;
java监控:jconsole;
测试工具:jmeter;
图表工具:highcharts;
http接口测试工具:postman(非插件版),newman;
分布式框架:dubbo、spring cloud、hsf;
版本管理:git,svn;
构建工具:maven,gradle;


总结
每个人的能力,在其他人的心中都有一杆秤,是好是坏,大家心里都有数,但并不会说出来。
能力这种东西,是骗不了人的。而技术管理对大家的能力要求较高,
希望大家快速提高自己的各项能力,及时总结&复盘,在日益激烈的职场竞争中脱颖而出。



阅读更多

没有更多推荐了,返回首页