gitbook/雷蓓蓓的项目管理实战课/docs/204421.md
2022-09-03 22:05:03 +08:00

11 KiB
Raw Permalink Blame History

19用户故事我想从头到尾把事情做成

你好,我是雷蓓蓓。在这里,首先我要感恩在疫情中仍然坚持认真学习的你,好久不见,非常想念!

在专栏完结以后,我很想了解我的课程对同学们都有哪些帮助。于是,极客时间帮我邀请了一些同学分享自己的学习故事。今天,我想跟你分享一篇小文同学的故事。小文同学在他的文章里,非常坦诚地记录了他的真实学习经历,一下子把我拉回到了阔别已久的录音笔前。

我在专栏结束语中说过从程序员转做项目管理只是因为我想从头到尾把事做成。Wuli小文同学每次听课都特别认真无疑是抓到了精髓。他说只具备技术上的积累,很多时候并不能把一件事做成。技术积累就像做加法,而一边做技术一边了解项目管理就像做乘法。下面,我们一起来看看他的学习收获吧。


Hi我是小文同学一名Java工程师坐标广州在一家游戏公司工作快四年了。

我应该算是极客时间最早的一批用户了。可以说,我见证了极客时间从最初的几个专栏到内容不断丰富的发展过程,也可以说,极客时间这个 App 陪伴我度过了初入职场的关键三年。

从2017年开始我成为了技术负责人2018年上司离开我被迫独自面对项目里的技术问题再到2019年我开始作为主程研发新项目这一路走得并不顺利。如果没有极客时间的老师们在知识上的支持我或许早就已经因为各种困难中途放弃了。所以这些年在工作上除了感谢上司的培养外就是要感谢极客时间的老师们了他们的一篇篇文章让我有足够的知识和能力去抓住工作中的机会。

担任新项目的主程是我在2019年遇到的最大挑战。在研发的过程中项目出现了各种各样的难题除了技术上的难题最难的就是解决项目进度和协作等非技术问题。

项目在导用户内测时,很多潜在的问题都暴露了出来,比如说,产品提的需求经常被技术误解,测试的 Bug 跟踪不到位导致修复进度慢,开会时常常只有讨论没有结论……面对这些问题,大家特别像热锅上的蚂蚁,忙得焦头烂额,但却不知所措。那个时候,我每天除了匆匆忙忙地补“锅”之外,就是不停地思考项目的核心问题到底出在了哪里。之前我百思不得其解,直到遇见了雷蓓蓓老师的“项目管理”专栏,我才对项目内部的底层问题有了新的认识。

现在,极客时间的专栏推出得非常快,以致于我都没注意到这个专栏的上线。在我意识到项目管理出现问题的时候,专栏已经更新十来讲了。不过我刚开始订阅专栏的时候,其实并不指望专栏会解决我遇到的问题,我只是希望借专栏的专业知识分析眼下项目的病症所在。

结果,我在阅读第一篇文章《角色转换:程序员做项目管理的三大误区》的时候,就醍醐灌顶,当天我就根据文章里的“三个误区”认认真真地反思了自己的不足。从留言区也不难看出,这篇文章戳到了很多同学的痛点。我有预感,我能在这个专栏里逐步剖析甚至解决自己项目的问题。

我是怎么学习专栏的?

有些技术性很强的专栏我会在通勤的时候听但是在学习《项目管理实战20讲》专栏的时候我会非常认真地准备好一切并且确保自己有一个小时以上的空闲时间。我通常会在下班后带上电脑去图书馆或者咖啡厅学习。

不得不说,一些专栏的文章只读一遍是不够的,比如“十大领域五大过程组”这两篇文章可以算是框架级别的内容了,不认真阅读的话,是很难串联起后面的知识的。

项目管理是一个体系的课程,它不同于修 Bug ,找到问题的时候就是解决它的时候,项目管理的学习、项目问题的剖析和修复,都是需要耐心的,这是一个理论、思考和实践都不可缺少的过程。

我认为,阅读专栏文章最好的办法,就是把自己的项目代入老师的文章中,一边阅读,一边思考团队中的人员分别属于文章提到的哪些角色、自己处在哪个位置,等等

在学习“项目管理”专栏的时候,我一般会打开音频(蓓蓓老师的声音非常好听),对照着文字逐行去读。我会带着自己对当前项目的理解,仿佛老师马上就要剖析自己的项目那样去阅读和聆听,这样就很容易在普普通通的一段话中,发现和自己的项目相契合的问题。这时候,我一般会暂停下来,选定文字,把引起我共鸣的地方写下来,顺便做些分析。在遇到有感觉的内容、但没办法用语言表达清楚的时候,我就划线标注,如下图所示:


这种阅读方式可能比较苛刻,要全神贯注。但是,每读完一篇文章,我都能发现我们项目的一些潜在问题。最重要的是,蓓蓓老师在分析完问题之后,往往还会给出一些建议,这些建议帮我解决了很多痛点问题。

学习专栏有什么收获?

之前,我听过一个观点,大概意思是说,如果一个程序员选择了专攻技术路线,目标是成为一个能解决所有问题的技术专家,他就不需要关注项目管理方面的知识和积累了,可以独来独往,不受公司规则的约束。我刚毕业的时候也多少有点认同这种观点,甚至很仰慕那些技术专家。

以往我订阅的专栏和阅读的书籍一直以硬技术为主比如Java、算法、计算机网络等这些知识可以让我稳扎稳打地解决技术上的一个个难题。但是当我需要承担一个项目的时候我发现**只具备技术上的积累,很多时候并不能把一件事做成。**随着自己专业技术的进步,下意识地提升技术以外的软实力,变得越来越重要。这就类似于我们必须用两条腿走路,才能走得又快又稳。

打个不完全恰当的比喻,**技术积累就像做加法,而一边做技术一边了解项目管理就像做乘法。**一个技术人员在拥有深厚的技术积累的同时,能够兼顾一些项目管理工作或者是具备项目管理意识,团队的协作就会更加顺利,自己的技术也可以更好地落地在项目中,技术的价值也会因此大大增加。我所熟知的架构师、技术专家们除了有深厚的技术积累外,大多数在软实力上也都非常出色,尤其是项目管理能力。

读完专栏,我的直观感受是,虽然不是每一个程序员都要管理项目,但每个程序员都需要懂得项目管理。我之前算是一个不爱开会的程序员,对于很多项目问题,我都执着于用更好的代码去解决,因此我们团队也很少开会,往往到事情比较严重的时候,我们才会开会,想办法补救。

说到这儿,我很想跟你分享一个我的故事。

在阅读《高效会议: 项目中要开好哪些会?》之前,我们项目内部因为会议过少造成的沟通缺失问题就像推倒的“多米诺骨牌”一样,接二连三地引发了很多新问题。程序员思维让我一直觉得需要用新的工具和技术去解决问题,但在阅读文章之后,我才明白,我需要学习的不是新工具,而是开会的技巧。

在看蓓蓓老师对不同会议的分析时,我经常因为之前思维的固化而感到愧疚,又为不同会议的不同效果而感到震撼。我发现,能够掌握会议技巧和有效地召开或参与会议,其作用力绝不亚于学会一个高端的技术框架。学技术框架是一个漫长的过程,而培养高效的会议意识却是现在就可以做到的事情。

我记得,那个时候,我很快就在项目组分别召开了部门负责人会议和技术团队会议。我按照专栏的讲解为两个会议做好了准备。在开会的过程中,我最大的感触是,很多问题单靠自己钻研琢磨是很难解决的,但在开会的过程中,大家一起讨论,问题很容易就会迎刃而解。

会议模块是我通过专栏知识着手优化项目的开始,没过多久,我就看到了成效。紧接着,在一次会议中,我根据《质量管理:一次把事情做对》这篇文章里提到的优化项目版本质量的办法,给我们的项目提出了一些监控的措施。

我的措施并没有立竿见影的效果毕竟版本质量的提升不是一蹴而就的事情。但是因为建立了一套改善版本质量的流程项目组中的各个同学在面对Bug时都更有信心了。我也相信我们的版本质量会越来越好。现在我非常期待继续把专栏中的经验应用到我们团队的项目中。

总结

在专栏的结束语中,雷蓓蓓老师写道:“因为我想从头到尾把事做成。”我对这句话的印象格外深刻。但凡决定开始做的事情,我也希望都可以做成。

项目在研发过程中确实遭遇过不少困难,甚至有的同学不看好这个项目,于是就选择离开了,我自己一度也非常沮丧。我至今都非常感谢遇到蓓蓓老师,她的专栏给了我不少新的思路,让我重新梳理了项目的问题,确立了中短期的项目目标,我自己也做好了持续精进的准备。我很希望自己的项目管理能力能够不断提升,也希望我能把越来越多的事情从头到尾做成!


正如小文同学所说,专栏的文章只读一遍是不够的!项目管理是一个体系化的实战课程,你需要先了解整个知识框架,然后把自己的项目代入到专栏文章中,一边阅读一边结合实践思考,逐步剖析并解决项目中的实际问题,这才是实战型专栏的正确打开方式。

感谢极客时间,把我从一个实战中的学习者变成了一个老师。作为一个初出茅庐的“老师”,遇到爱学习的你,有机会分享我的实践心得,我特别得感恩。尤其是当我看到这样一个专栏,能够让人在繁忙工作之余,回到在图书馆学习的状态,一点一滴地从头学习“如何开好一个会,如何做好一个计划…”想到这些实战中带来的变化,我特别得满足。

作为一个学习者,主动学习的最高境界,就是像小文同学这样,能够把自己的学习实践所得讲给别人听。还记得我们的加餐题目吗?“‘学习’到‘实战’的距离,到底有多远?”你,还差一篇用户故事。欢迎你也分享一下你和项目管理的故事。

如果小文可以,你也一定行!