一个半吊子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是能够带动团队、协调团队、发掘出团队的全部能量的，而我也希望自己今后，能在这方面不断积累经验、越走越远。