您的位置:首页 > 运维架构

2次转管理失败后,我对项目、团队、敏捷转型的新认知 - 运维

2020-04-05 00:00 2606 查看

大家好,我是孙冲。这次分享是我从技术转管理后,经历的一些项目管理和敏捷转型的实践和经验总结。希望能对一些初步转管理,刚涉及项目管理和正在尝试敏捷的团队提供一定借鉴的思路。

 

主要由以下五部分内容组成:

 

  • 以现在的角度重新去看过往的一些项目

  • 第一次真正实践敏捷

  • 再一次尝试敏捷

  • 经历敏捷的实践后对敏捷的一些思考

  • 最后是概述总结

 

主线

 

在整个分享过程中,主要穿插着两条主线:时间线和能力线。

 

时间线分为三部分:

 

  • 第一部分是2016年-2018年的一段项目经历。当时的背景是,没有转型管理,没有项目管理经验,没有敏捷常识知识。

  • 第二部分是18年到19年的一段项目管理经验。当时的背景是,刚刚开始转型管理,项目管理经验较少,第一次尝试敏捷。

  • 第三部分是19年到现在。自己已经完成初级管理转型,项目经验也有了一定的积累,开始第二次尝试敏捷。

 

第二条主线是一条能力主线,并且随着时间主线的延申,能力主线也在不断变化。

 

从管理能力(对下管理、对上管理、以及平级之间的竞合关系),到项目管理能力,再到敏捷项目管理能力。

 

第一章:回顾以前的项目经验

 

好,我们开始第一章节,回顾以前的项目经验。站在当前这个位置,回望自己16年到18年的印象深刻的一个项目。

 

 

这是一个内部项目,CRM客户管理系统,级别很高。公司不是矩阵架构,各个职能部门之间进行协调配合,所以没有真正的项目经理。

 

再就是开发在青岛,但是测试、产品和前端都在北京,是典型的异地沟通。这个项目迭代两年多,自己一个人差不多维护了近两年。所以我被称为活文档,甚至说比产品更了解当时的这个系统。

 

那么在以上这些背景下大家能够预料到存在哪些问题?

 

 

第一个现象:估工时,砍工时

 

各种”O“大大们强调30天后必须上线,我作为开发估了50天,

主管看后砍到45天,经理看后砍到35天。最终”O“大大们接受了从50天压缩到35天的这个事实。我也间接为自己多争取了5天时间。

 

第二个现象:级别差距悬殊,没有话语权

 

上面提到了各种”O“直接提需求,好的方面是系统等级提高了,不好的是领导的需求提过来基本没有还手的余地,更别说是中途改需求,加需求这些事情了。

 

经常是我们非常不理解领导层这么快上线的初衷,也就是不能够明白这一次迭代的价值。

 

第三个现象,因为主要是我来维护,所以问题理解程度有的甚至比产品更深入

 

请假后,自己越想没事,往往时刻盯着群里。第二天去公司已经发现有很多问题需要回复和处理了。

 

第四个现象,会议多而长

 

因为是异地沟通,再加上需求的频繁变化和没有实质的项目经理,所以基本是面向产品开发,产品指哪儿我就打哪儿。

 

我们经常是临时拉起会议,然后讨论一个流程上的问题。有时也会组织一次会议,专门讨论需求,但是会议的效果不理想,经常超时,讨论进展缓慢,每一次会议产生的成果也少,很多时候我们就一个问题深入讨论很长时间都没有结论。

 

关键是我那时对会议超时反而觉得自豪,心里想:看呐,我们讨论的多激烈,这个项目多复杂,需要我们来回讨论好几轮。

 

大家经常参与会议的应该会深有体会,预定会议室,协调各个工种人的时间,会议上讨论,没有讨论完的继续预定下一轮讨论。再加上我们时异地沟通,其中的沟通成本可想而知。

 

其实这些现象对项目中的每个人而言都是一种煎熬。表面上我们看上去很忙,实际上我们的产出价值有待商榷。

 

期间我至少有两次机会可以转型管理,因为对这个项目太熟悉了,但我印象中的两次都失败了。

 

我一步一步越陷越深,直到我自己都有些迷茫了。我到底要不要转管理?转管理这个问题是充满诱惑的。转,是一种瓶颈突破。不转,可以全力投入技术。

 

越迷茫越纠结,越纠结越迷茫。我纠结着很多问题,比如:

 

 

现在的我再来看这些问题我已经有了答案。有几点总结吧,首先我认为转管理最好自己有转管理的意向,其次可以看一些管理认知方面的书籍,如果有人指导一下更好,最好的情况是有行政命令,逼迫你必须转变。

 

第二章:初始敏捷,小试牛刀

 

现在我们再回到时间线,进入第二段:18~19年 敏捷小试牛刀。

 

 

18年进入到轮子科技,自己开始了带人,也开始学习带项目。这个转型过程也是让我印象深刻,简单举出几个例子。

 

 

1)重构32个接口是怎么回事呢?

 

在我第一次成为项目经理时,内心是激动的,幻想短时间内打造一个优秀的项目。

 

这个项目叫”产品中心“,我在这个项目重构后的1个月后接手。没几天我就像领导提出要重构对外的着32个接口,领导应该当时很诧异,只是说一会要去开会,让我回去等等。这一等就把我再次重构的热情降了下来,因为业务系统开始慢慢对接了,后续的需求迭代也开始了。

 

2)中台会议连环发问

 

当时我们在讨论一个中台战略的项目会议,现在我称之为杰哥的人在会上强调了10条建议。我为了显摆自己,针对这10条建议,一一进行了反问、诉苦。

 

会议让我带跑偏了,成了我的抱怨会。因为刚刚成为项目经理嘛,遇到很多问题自己总是认为不是我的问题是其他人的问题。

 

3、瀑布模式的痛

 

第一次做项目经理,比较没有自信,也比较天真。难的任务给自己留下了,一些临时任务也没敢往下分积压在自己这里,例会也没有抹开面子去开。

 

这一次迭代,就迭代了2个月,第一个感觉就是项目快失控了。第二个想法就是测试别测了,赶紧上线吧,真的快被折磨疯了。

 

有时候会对自己很失望,啥也不会。有时候会对其他人很愤怒,怎么这么多事。

 

一个是漫长的瀑布模式,一个是欠缺的项目管理经验,都让我走得很难。在这个版本结束后,我第一次接触了敏捷相关的一些理论。

 

4)尝试敏捷

 

是的,我们开始尝试了敏捷。我们学站立会,学估点,学使用面板,学使用短周期迭代。这种方式我们尝试了2个版本,每个版本基本一个月。也算是积累了一些东西。

 

 

项目概况模板——算是阐述这次迭代的核心点和注意事项。

 

 

检查单——这个主要是弥补项目管理经验的不足。

 

 

打分模板——这个我们虽然打了分,但是每个人对打分的理解完全不一样。

 

 

总结模板——我们每次项目迭代后虽然开了项目总结会,但真也就总结一下就完事了,完全没有形成闭环。

 

 

 

所以我后来就想形成闭环,这一次迭代做了总结然后形成电子版记录,下一次迭代总结会上会再拿出来,对承诺的一个提升点进行盘点。

 

从上面这四个小案例,现在的我再去看那时的我。会发现当时我转变一下思路,很多问题其实就会迎刃而解。

 

 

关于项目管理,项目管理本质是管理好项目,让项目顺利上线。如果我当时拿着这条准则去做,那么很多事情我会安排下去而不是积压在我这。

 

1)这期间我也对向下管理有了一些新认识

 

如果我好好分配自己的时间,给新人一些压力和指导,那么他会成长快一些,反过来还能承担一些工作,我就可以有更多的时间去做其他更重要的事情,这是一个良性循环。

 

2)我也对同级管理有了新认知

 

以前我总是比谁的技术厉害,同级之间是攀比竞争。现在我觉得同级之间很多时候需要互相支持。竞争也算是一种学习,我觉得你项目中好的东西,我可以拿过来尝试一下。

 

3)那个时候对向上管理认知不够

 

以前总觉得领导就是必须主动关心我,如果不经常关心我我就觉得自己被抛弃了,被忽视了。

 

4)对于心态

 

如果我当时多站在业务系统的角度去看问题,就会发现很多的问题都是可以理解的。

 

比如:他们上线前几天才通知我加接口。如果我抱着服务的态度去解决这个问题,就不会那么消极。

 

为了避免后续再有这些问题,我会建群,提前关注业务系统的项目动态,经常群里问问他们的迭代计划。有问题解决问题,而不是抱怨。

 

经历了职能转型,项目管理转型,初步尝试了敏捷后,有收获也有惨痛的教训。当公司提出想做敏捷转型,我们开始做试点,于是我们又一次踏上了敏捷之路。

 

第三章:再次开启敏捷之路

 

 

在重新开始敏捷前,我自己看了很多资料很多书籍,对敏捷有了一个全局观的认识。

 

在看书期间也发现了我之前道听途说的一些敏捷是错误的。也发现我们第一次实践敏捷的时候没有准备就上路了,所以很多东西并不知道其中的价值。

 

我从书中总结,现实中再去实践后,又有了一些收获和思考。

 

 

1、物理面板

 

 

 

 

优势:

 

  • 在物理面板前一战,确实显得正式有仪式感。

  • 成员会主动贴、移任务,能够关注到自己在做的需求。

  • 粗粒度看到项目整体概况。

 

不足:

 

  • 用户故事、任务、便利条慢慢占满了物理面板。密密麻麻的信息,此时的物理面板反而不够全局了。

  • 视觉上的冲击很容易让我们分散关注整体,需求,任务的注意力。

  • 字体小的话很难平和的心态去关注这些具体的任务了。

  • 依赖物理面板可能会丢失项目过程中的数据。

 

方案:

 

1)坚持物理面板:

 

  • 需要空白地方:玻璃墙,白板

  • 需要同步好信息:项目需要一些项目数据的,所以同步到电子版是有必要的,每天的站会物理板拖动后,有个人负责同时拖动电子板(为了统计项目信息)。

 

2)使用电子面板:需要投屏,需要培养移动电子面板任务的习惯。

 

3)两者结合:电子面板及时同步物理面板信息。

 

2、产品列表和用户故事长远规划,可以粗可以细

 

 

产品列表按照优先级排列,里面有产品需求也有技术债。以前的我被灌输使用敏捷,需求必须转成用户故事。

 

 

现在看来,这只是一种形式,一种成员都认可接受的描述需求价值的形式。所以只要是成员能够理解这个需求价值到底在哪,至于怎么描述就看大家的接受认可度。

 

“我是开发,我想重构队列服务,队列任务隔离,各自处理各自的,不互相影响,好扩展。”

 

“我是运维,我想最好有一个导出按钮,这样响应客户速度快,我就不用每次邮件申请等待DBA导出了。”

 

“我是用户,希望你们提供一个接口,我能知道某个时间的具体税率信息,这样才能保证我每月的月初订单对账。”

 

建议:

 

我觉得描述完全没什么不妥,就看大家怎么看,哪种接受度高,从语境中能够认可它的价值。大白话一点,直白一点,不需要那么死板官方。建议第一人称,代入感强,身临其境。

 

我认为这个用户故事或者说需求没有硬性要求。合适的就是最好的。

 

难点:

 

难点在于找到团队成员大部分认可的一种表达方式。对产品的要求较高,几句话能够抓住读这句话那个人的大脑,让他跟着你的语境思考这个需求到底做了什么事。然后这个需求实现后能够带来什么。

 

3、计划

 

  • 每一次提前做计划,大家的时间充分利用。

  • 提前参与需求的讨论,理解需求的源来。

 

 

4、估算

 

 

这里的估算我们使用的后面的一种方式,理想工时。当然还有估点,只是我们使用得不够熟练。后面会慢慢尝试,对比两种哪种更适合团队。

 

5、开会

 

以前开会,自认为会议就是用来讨论的,一次不行两次,两次不行三次。期间一个大家否感兴趣的话题一出,群口相声来了。讨论确实激烈,但是时间过得也快。

 

既然是讨论嘛,时间长点就长点,大不了转战另一个地方再战。搞到最后,大家争论不休,会议不止,都很疲惫。会议上没人记录,会后没人总结。一些细节点,一些结论不久的将来忙起来渐渐忘记。

 

建议:

 

  • 前期将一些重要的点可以先找相关人讨论对对。

  • 会议找个资深的作为主持人,控制会议节奏。

  • 有问题没事,记下来会有再重点细致讨论。没有必要妨碍后面的进度。

  • 会后趁热打铁,把会议的问题去确认对应的解决方案。

  • 同一天,最多第二天。把会议上的问题处理方案,发到群里广而告之。

  • 不能确人的问题,记录好接下来持续解决。

 

 

 

 

 

6、评审

 

关于评审,我觉得作用非常大。评审会议需要线下多花精力对接讨论。主流程和难点都浮出水面可以再拉起会议进行沟通。

 

 

 

 

7、代码走查

 

关于代码走查的好处不用多说,这里代码走查的可以融合部门规范,树立良好的代码风格。同时可以检测出相关的bug。这个功夫要花在平时,不太建议拉冗长的会议,大家再会议上去找茬。

 

 

 

 

 

 

 

 

8、验卡

 

验卡,其实可以看作里程碑的交接。就是开发发起,产品验收的同时测试也在旁边。对主流程走通即可。不需要冗长的会议。人少建议工位前花10分钟走一下即可。

 

9、技术债

 

我们的系统随着时间的推移,慢慢会积累技术债。到最后往往是我们不怕新增特性,而是怕在原来的基础上需求变更。主要原因是技术债导致我们系统的扩展性和可维护性大大降低。

 

所以在平时迭代我们会将一定比例的技术债进行迭代(比例:1/6)

 

 

10、项目总结

 

总结如同反省,有反省有思考才会有进步的可能。所以可以和戴明环类似,使项目和成员在迭代中螺旋上升。这一次的项目总结,提出下一次的精进目标。下一次迭代项目总结拿出上一次的总结进行盘点,形成闭环来精进。

 

 

第四章:敏捷路上的思考

 

很多时候我都会到技术微信群里抛出一句“大家有实践敏捷项目的吗?”接下来很多人回复,有的回复“不好用”、“累死”。

 

我就在想说得这些人是不是真正了解过敏捷,又是不是实践过敏捷?

 

 

敏捷有标准吗?

 

在我看来没有~,我们部门四个团队试点敏捷,但是大家对敏捷的这些方法实践各种各样,顺序和形式各种各样。组内的项目成员对敏捷的形式又是一种理解。所以有时候感觉敏捷确实难以实施推动。

 

敏捷不是银弹

 

我一开始比较迷信敏捷,觉得敏捷是一个能解决所有问题的方式。

 

敏捷的价值

 

我们劈里啪啦实施敏捷,到底是图什么?

 

有一个共同的目标引导,自己能力迭代提升(认知、技能、沟通、主动性、心态)。获得更好的收入,更高层次的职级,升职加薪何乐而不为呢?

 

其实这也反推项目的成长,相辅相成。

 

 

第五章:总结

 

成长往往伴随着痛苦,谁不想在舒适区待一辈子。面对着社会压力,面对着家庭压力,面对着自己的价值实现,应该走出舒适区,重新定义自己。

 

 

1、业务和技术互相促进

 

技术人学带项目,会发现平时项目经理处理的事情表面上自己都会。但是一旦自己成为项目经理后发现事情不是自己想象得那么简单。你要考虑客户的感受,你要考虑项目能不能可控,你要考虑组员的成长。

 

你会拥有大局观,你也不再认为技术就是一切。总之会在业务和技术之间学做平衡。

 

2、平级沟通

 

与优秀的人一起工作是一种幸福。

 

3、向下沟通

 

技术人转管理会发现带出一个人很难,但是一旦带出来又很有成就感。

 

4、向上沟通

 

理解了领导也是人,领导也会有情绪,我和领导不是站在对立面,而是站在同一战线,互相支持互相成就。

 

5、项目管理

 

我认为项目管理是技术人的一种基本能力了。

 

6、敏捷虽然不是银弹,但价值无限

 

7、坚持做下去,持续精进下去

 

 

附录:书单

 

 

>>>>

线上问答

 

 

获取本期PPT请添加菲菲VX:dbafeifei

直播回看链接:http://z-mz.cn/nwOy

内容来自用户分享和网络整理,不保证内容的准确性,如有侵权内容,可联系管理员处理 点击这里给我发消息
标签: 
相关文章推荐