一个半吊子PM的反思

故事之源

2019年3月,也就是2016级计算机学院的大三时,软件工程这门课程由选修转为专业必修课,而七个葫芦娃共聚罗杰老师的课堂,组成葫芦娃不想写代码小分队。面临着继承往届项目、完成指定项目和自选项目的抉择,葫芦娃们凭着自己在黄金点游戏中的欧气,和“想着写出点自己喜欢的且未来能够写在简历中的东西”这样一个单纯的想法,毅然决然地选择了VisualPytorch这样一个蛇精大BOSS。至此,这场漫漫打怪升级之路,变拉开了序幕……

所得之幸

我在葫芦娃中扮演着主PM的角色,说是PM,其实最开始完全不知道到底该做些什么。在Alpha阶段,我们在开会商讨的时候,有如下对话:

我:我们来做一个那种可以拖组件,然后搭建模型的网站吧...

大家:好呀好呀~

我:我们主要就是要让他可以拖组件到画布里,然后连线搭建模型,然后就可以生成代码了。

开发组:呃……具体是什么样的功能呢?

我:就是左边有一堆组件,从左边拖进来,然后连线,这不就搭出来一个模型了么?然后点一下生成代码,就能生成代码了啊…

开发组:……

我:我们还应该实现登录和注册的功能,这样用户可以把模型保存在他们的账号里。

开发组:……

我:然后我们最好也实现论坛的功能,这样用户可以在我们的网站上进行讨论交流,有人如果有疑问的话也可以求助别人啦!

开发组:……

我:行那要不就先这样?大家分一分活然后抓紧开始学习、开发叭。

开发组:?????功能是啥?原型图是啥?我要干啥?

我:……

这种模棱两可的对话就是我们Alpha阶段初期的状态,我不知道什么是原型图、如何明确地把预期功能交付给开发组同学们,也不知道该如何控制项目的进度,只能每天问问“今天做了多少呀?能完成嘛?要抓紧做哈”。而很快,我可以给开发组同学提供每个网页的原型图,方便他们进行开发;我也习惯了每天召开scrum meeting,来了解组员们的情况,并用Github的issue来把控项目进度,也学会了疯狂push大家

此外,正如那句话所说“PM负责除了开发和测试以外的所有事情”,我学会了在前端与后端之间、开发与测试之间扮演着信使的角色。当我和另外一位PM对网站有了新的想法,我会及时与开发组的同学商量,研究新的功能的必要性以及实现的可行性;当后端完成了某个接口时,我也会及时交付给测试同学进行单元测试。如果经历了一学期的历练,我有一点点的提升的话,全都归功于软件工程给我们的实践的机会…在项目迭代的过程中,我一点点认识到,PM不是团队里的混子,某些时候PM是领航人,带领着团队前进,有些时候PM更像一个打杂的,要给团队提供最好的条件前进,就好像润滑油,PM来保障团队能够顺利地全速推进。

数遇困境

虽说学期结束后来看,我们组顺利完成了VisualPytorch项目,然而实际上,在项目推进的过程中,我们还是遇到了一些困境的,甚至是毁灭性的打击。

在Alpha阶段的中后期,也是我的失职,没有一天都没有询问开发组进度,结果第二天才发现群里超级安静,我就问了下后端大佬进度如何,才发现前端和后端同时停滞了。前端说后端接口没设计好,后端说功能还没和前端敲定,于是陷入了死锁。当天,我紧急召开了会议,大家一起商议,确定好了下一步的工作,使得项目得以继续推进,Alpha阶段顺利完成。这次小风波也让我明白,在团队冲刺的时候一定要跟进各个部门,确保顺利对接配合,如果遇到问题一定要及时解决。

在5月22日,我们的数据库遭到攻击,数据库内所有信息均被删除,并被勒索0.1比特币来恢复数据库(我们像是有比特币的人么)。幸好,我们的数据库并不是那么复杂,且我们也不是一个商业公司,数据并没有那么重要,我们开发组的大佬只能加班把数据库重新搭建一遍,并关闭了所有的远程连接。大佬说,幸好我们的数据库不复杂,并且不涉及到隐私数据,否则我们只能花钱消灾了。虽说这次危机事件,我们用最笨的方法解决了,其实也不能够算解决,只是让网站能够继续提供服务。但经历了这次事件,我们也都有了经验,警醒要在安全问题上下功夫,如果没了安全产品就像海上飘着的树叶,毁灭只是时间问题。

在最终最终的展示上,我个人由于身体原因,嗓子过敏说不出话,无法完成最终的展示。我们组的ywt同学挺身而出,代替我完成了最终项目的展示。

我们葫芦娃团队虽说是一群毫无经验的学生,我们没有所谓的项目经验,但我们有进去的心和相互帮助、相互搀扶的精神,也正是这样,我们才能一点点进步,完成这个项目。

引以为憾

虽说结果是好的,但其实还是有一些遗憾,有些问题没能够解决,这些遗憾也是我本学期课程所收获的。

在Gamma阶段伊始,我们开会决定第三阶段要进行哪些功能开发时,我提出了几个方案,但开发组的同学似乎并没有什么动力,并想选择一些工程量较小的功能来实现。我理解到了Gamma阶段,大家都比较疲惫,并且各种考试、大作业也都接踵而来,大家没有太多的精力分配到软件工程上。虽说理解,但工作量还是不能过分减少,因此我还是按照原定计划督促大家完成,但很遗憾的是,我试图找到一种让大家都能够愉悦、轻松地完成开发任务的方法,我想要去营造一个较为舒适的团队氛围,但我没有想出一种有效的方式,感觉大家都是在负重前行、疲惫不堪,对此我真的很内疚。我认为一个愉悦的开发环境,无论是对组员的工作效率,还是对组员之间的关系,都是一种保证。我真的不希望大家因为工作上的事情,彼此闹得不愉快、很疲惫厌倦,因此,没能够想出一种调节团队氛围的方法我感到非常的内疚。

另一个遗憾,则是在整个过程中,我有两个问题并没有想清楚,我也和学长进行了交流,感觉也并没有得到足以令我信服的答案,为了解决自己的疑惑,我联系了一位在微软工作了一段时间的前辈,想了解一下真正的公司中是怎么样的,问题如下:

问题一
在Gamma阶段伊始,正如上文所说,开发组组员有些疲惫,对有些功能并不太想实现,并说是因为整体架构的扩展性没那么好,无法进行扩展,如果真的要实现只能进行重构。开发人员认为这些功能都应该是在最开始就设计好的,在最开始就应该考虑到这些功能的添加。而我个人觉得,一个产品会根据用户反馈不断提出新的需求,这些往往是无法在最初就想好、设计好的,那这种情况在公司中出现,应当如何应对呢?如何在最开始就保证项目良好的扩展性呢?

问题二
由于我们开发成员大多数对Django、数据库一类的不太了解,而在Alpha阶段的学习也不太扎实,导致在Beta和Gamma阶段能做的事情就很少,几乎是靠大佬一人撑下来……我个人觉得这种情况如果出现在公司,可能会导致项目进度大大延缓,这种情况在公司中遇到了会怎么办呢?

回首观之

可能因为大家在团队中担任的角色不同,一学期的学习下来大家收获的方面各不相同,但所幸我们都有各自的收获。

于我个人而言,因为我以后也希望能够从事产品方向的工作,所以这段经历算不上经验,但也让我初步尝试了一下作为PM是一种什么样的感觉,也在摸索当中学会了一些东西,认识到作为PM远远不是想想的那么简单,简单的push、简单的功能设计,真正好的PM是能够带动团队、协调团队、发掘出团队的全部能量的,而我也希望自己今后,能在这方面不断积累经验、越走越远。

posted @ 2019-07-06 00:58  zhangzhewei_buaa  阅读(201)  评论(0编辑  收藏  举报