谈谈我对软件开发项目管理的理解



        首先声明一下，我并不是一个PM，也从未做过与项目管理相关的工作。作为一个每天都偏安一角静静地写代码的程序猿，本不应该发表与项目管理相关的观点。无奈，以个人的角度和眼光，鉴于工作中出现的一些问题，还是想在这里以“关二爷绣花”的立足点聊一聊软件开发项目管理相关的问题。

        先简单地从个人经历说起吧。我工作过的第一家公司是一家在国内外牛逼哄哄的互联网公司，我在的那个部门也是有几百号人来开发一款产品，我入职的时候该产品开发已经接近尾声，其时该项目已经走过四五年的光景。工作期间，感受最大的东西就是流程，每做一件事情都有一套有章可循的流程。与之相关的就是工作台系统，与工作相关的内容都有一个明确的工单。到最后，产品版本严格控制的时候，要提交一行数据甚至修改一个标点符号，都要经过以分级而定的review流程才能提交（比如我当时的级别还是实习生，review是“1 + 3”：即自己先检查确认提交、然后需要另外两个普通同事review确认、最后是需要一个组长review确认）。我们每个人都隶属于不同的小组，受小组长管理。组长上面有大组长，大组长管理若干个小组长，每个大组根据术业和职能划分有一两个大组长不等。然后有一个整个部门的总监。每个人各司其职、每个管理层也各事其位：即一般情况下普通员工会单向和自己的小组长沟通；大组长也是单向与总监以及小组长沟通，工作上很少出现那种跳跃沟通的情况。同事之间的工作任务提交到工单后，会有提单者、工作人、相关关注者、组长、QA方面以及PM等人员跟进。其中，PM相当于是勤务兵的角色，负责产品需求和具体工作的协调以及工单的跟进。因此，会有若干个PM，PM也有自己的组长。

后来，我到了现在的公司，一个软件外包公司，在此感受到的就是另外一种截然相反的项目管理方式了。因为外包的性质，也就是给客户做产品写代码，所以好像一切都变了。首先，每个项目的人数变少了，少则几个多则几十个，这要视具体情况而定，而且还是变化的，一个人可能身兼多个项目，可能这段时间在做一个项目，过一段时间又在做另外一个项目。其次，因为每个产品客户都催的很急，每个开发每天都在加班加点甚至到了用第六感在写代码，所以流程神马的都成了浮云。于是，客户每天在疯狂地下达需求、开发每天在疯狂地造代码、测试每天在疯狂地测测测测、运维每天在疯狂地发版本和紧急抢险。在这种情况下，工作台和工单系统不能得到有效使用，个体有什么疑问就只能靠嘴皮子去来回打听；出了问题的时候，就成了一窝苍蝇，翻来覆去查BUG。另外，组织结构也发生了变化，那就是PM成了终极BOSS。PM既直接对接普通员工，又领导各个组长，还面对客户处理产品需求。在这种管理形式下，普通员工可能会同时接到其他同事、直属组长、PM以及客户的工作安排，而又没有明确的优先级以及截止日期，却又往往会突然被要求验收成果。

以上介绍了软件开发过程中流程化和非流程化两种项目管理方式。前者稳健，后者精简，也各自基本上符合以上两个公司的实际情况。但综合来看，一定范围内的流程化还是有益的。以下分几个方面说明一下哪些做法可能不仅就过程而言还是就结果而言更值得参考。

①.工单系统

什么事都提交工单，可能会比较繁复，就眼前来说可能浪费时间拖慢进度。但长远来看，完整的工单让工作明确明了、可追踪可查询、质量有保障风险有控制，是完全有必要采用的。

②.线上版本控制

线上发版需要走一套成熟稳定的流程，这包括固定发布时间和发布周期、明确的直接发布人员和相关人员、有预先计划的完整发版内容以及经过系统地预发环境测试。

③.串行管理优先

每个员工尽量只由一个leader（组长或其他）分配任务，可以把任务分配给leader再由leader转分配。如果这种箭头乱点的分配情况较多并且长期存在的话，会很让人凌乱。

④.专职专用而非一职多用

一个职位只负责一类工作，跟产品写代码测功能做运维的职位是疯狂而又冒险的。

⑤.一人一事而非人人都做“全科医师”

这跟上一条有些重复的嫌疑，但上一条是就职位而言，这一条是就具体的人而言，重复的部分就当是强调了。术业有专攻，工作分工不仅仅存在于实物生产加工工厂，软件项目开发中也越来越实现技术细分，即每个人只负责一小部分工作。因为时间差的原因，某些职位的某些员工可能暂时工作空闲，然后就会被调去做另外的事情。好的方面是给员工提供扩展其他能力的机会，但也很容易产生尴尬的境地。比如，能找到对象的男青年越来越少男科也越来越萧条，而因为“二胎”政策来妇产科就诊的妇女越来越多，就把男科医生拉到妇产科打下手，于是生的娃越来越多了，儿科又缺人手了，就又去妇产科拉人……最后，就会形成拆来拆去的局面，一个人在自己不熟悉的位置上做另一个人熟悉的工作，而那个人则在自己熟悉的岗位上。

⑥.适应和习惯每个人的沟通方式

有的人喜欢什么事都口头沟通、有的人喜欢打电话、有的人喜欢用聊天工具、有的人喜欢发邮件，而同时有的人不喜欢甚至忌惮这其中的某些沟通方式，这是需要留意的。另外，每个人都有属于自己的下班生活，能不打扰尽量不要打扰。

⑦.恶语伤人六月寒

不论是项目管理人员（PM或组长等），还是普通人员，当然主要是管理人员，说话表达应该要像写代码一样理过一遍后再讲出来。这不得不让我想起老“征途”有个叫“家族管理员”的NPC的一句欢迎语——“管理是一份高尚的职业”，管理者应该对得起“高尚”二字。当然这是从感性出发的。如果从理性出发，管理也应该是需要技巧的，可以称为管理的艺术。这种艺术就是应该要调动每个人的工作积极性，忘我的工作；而不是让员工失去对工作的热爱，放下对自己所坚守岗位的敬意。

作为一个运维，可能比软件开发中的任何其他岗位都能感受到一套适宜而行之有效的项目管理体系是多么的重要。毕竟，这是一个背锅又补锅、吃力又操心、救世界于水火而又总被忽视的职位。如果项目管理得当，运维就会幸福一点。因此，这篇文章就谈谈与之相关的东西。最后，当然再次强调，本文并非有章可循的学术成果或者经验之谈，而只是个人的感想，想到哪写到哪。