前言
工作五年了，亲眼见证了我们从一个五六人的小团队成长为四十多人的大团队。回忆这几年的工作，我很开心，偶尔翻到以前工作的照片，内心是愉悦的。我觉得我还是比较幸运的人，找到了一份自己喜欢的工作，找到了一群我喜欢一起工作的人，我们也不断成长、不断取得新的成绩。
团队不断成长过程中，有很多不错的经验，这次想聊一下项目管理。之所以先选这个话题，是因为最近公司在推行一套新的项目管理系统，我们自己用的那套项目管理方法就废弃了，这两种管理系统我都用过，我可以做个比较。
现状
聊项目管理，我觉得我需要先把组内的业务流程讲述一下，毕竟不同的业务流程可能需要使用的项目管理方法也不一样。
我们组负责商城业务，目前商城主框架已经完善，我们的需求方来自产品。
了解商城的同学应该知道，商城业务需要快速迭代，所以我们每周可能有三四十个项目并行，算是人手一个项目，项目从开发到上线一般1~2个月。
每周我们会在指定时间和产品组开会，校对项目进度和项目优先级，确定下周计划。
这便是我们目前的现状。
三套系统
无管理
当我们只有五六个人的时候，几乎所有的项目都被规定了截止时间，产品说了：我就那天要用。
我们能看到业务的快速发展，我们感到干劲十足，我们有满腔的热情，我们不需要项目管理，我们就撸起袖子加油干，然后我们就干成了。
当然，我们也不是一点都没有管理，多少还是做了排期和相关规划的，不过有些简陋，一般是这样的：
一封邮件里包含了项目的时间点和具体的内容分解。当时研发少、项目少、产品经理少，大部分同学素质和水平高，总体是能按照计划完成任务的，所以当时这种管理方案是可行的。
现在想想当时真是轮轴转，完成了很多别人觉得不可能完成的事情，但是没有人觉得累，每个人都干的很开心。
这便是在业务野蛮生长期，我们使用的第一套项目管理系统 - 无管理
自建项目管理系统
随着业务增加，产品经理和研发同学不断扩充，导致项目太多，上述的方法已经无法满足管理。主要有以下几个原因
- 无论是产品还是研发都需要一个能够查看当前所有项目的位置，这样才好把控资源和规划
- 项目有不同的状态，需要查看哪个项目是否长期没有被处理或者是否有风险
- 研发负责人需要知道研发资源使用情况
最初我想自己做一套，但是本身项目就多，领导也觉得没这个必要，这个事情至少还需要一个产品经理、一个前端，没有资源，所以就没做。现在想想，幸亏当时没做，当初觉得做个项目管理系统应该比较容易，完全是夜郎自大。倒不是说项目管理系统在技术上会有多复杂，而是说做出的这个系统是否能真正符合大家的需求。当时的业务规模、业务数量和做项目遇到各种事情都比较少，在这种知识基础下做出的东西未必会是好东西。
后来调研了一下现在有的一些管理工具，使用起来也比较复杂，最终我们使用了一个比较简单的方案解决了这个问题。使用TB
TB
首先我们确定好项目状态有：需求排队、需求评审、技术评审、排期中、开发中、测试中、上线中、已上线、暂停或废弃。每一个状态下会有对应的项目列表。产品和研发一起推动项目状态不断变更。
对于其中的每一个项目细节，配置项如下
-
项目负责人
-
项目开始时间和结束时间
-
项目进度
-
项目覆盖地区：国内/海外
-
产品线：由哪个业务方提出的需求
-
里程碑：关键时间点，开始开发时间、提测时间、上线时间
-
需求提出人
-
产品负责人
-
研发负责人
-
测试负责人
-
预估价值
-
wiki链接
-
备注
因为每周有和产品的周会，所以周会前一天，项目负责人会更新进度，如果有风险点会进行备注。
TB有个好处是搜索做的很灵活，所以可以很容易过滤出自己关心的项目。通过使用TB我们将项目管理了起来。
规范化
当然只靠TB是不行的，我们做的另一点是将项目需求进行规范化处理。每一个项目都需要有
-
需求文档：包含产品的需求细节和原型
-
技术文档：如果项目复杂，技术文档需要包含架构、api等技术细节，该文档需要各个技术方参与评审
-
排期文档：极其重要的一部分，一般包括如下内容
- 上线和回滚文档
这些文档会放到TB的wiki链接配置项上，方便所有人查看。
项目提测的时候，会在提测系统上填写提测内容，也会给测试同学进行演示，防止研发做的项目根本无法使用。当然，研发同学也会一起过测试同学的测试用例。
如果项目有延期和上线风险，需要提前和产品沟通，如果风险无法避免，需要和所有人员开会，重新制定方案和确定新的时间点，并发送延期邮件。
项目上线完成后，根据项目实施情况，大家可以做复盘。通过这种方式，我们不断的优化自己的管理。
就我个人而言，我还是比较喜欢这种管理方式的。
-
首先在于单个项目的详细信息十分容易获取，众多项目的信息也一目了然。
-
其次这种方式是紧中有松的，即把所有项目汇聚成流，但也允许开发人员在遇到问题的时候及时做出调整。
-
第三点就是维护项目代价很低，每周更新一次就能保证各方对项目看法一致
当然，这个也有缺点，缺点在于每个研发同学的工作量没法量化，可能直属leader知道大概，却没法用数字表达出来，这会导致在晋升、评级等事项上，缺乏依据。
自研项目管理系统
今年部门开始自研项目管理系统，拆解后的内容在项目中输入，完成某个小项后，需要更新小项的状态。这样自研系统能够查看每个人的工时和工作情况。
这套系统因为还在建设中，有一些我感觉可以改进的地方，主要如下
- 填写拆分的小项麻烦。以前我们只需要写排期文档即可，而且排期文档可以很方便的看出各个组的工作量。现在需要先写排期文档，然后将排期文档里的小项再填写进系统，需要耗费多倍的工时。可以将填写小项的功能做的更直观一点，清晰明了展示内容。
- 更新麻烦。每个小项完成后，如果不更新，整个的项目进度也不会更新，所以完成一个小项后需要及时进行更新，如果忘记了，显示进度会有问题。这种可以通过邮件提醒来解决。
- 查找项目麻烦。如果想查找自己关心的项目，很难进行过滤，可以对项目属性进行梳理，优化项目搜索功能。
- 查看里程碑麻烦。这个管理系统里缺一个明确显示里程碑的位置，所以查找里程碑通常需要查看排期文档。
- 项目变更缺失。目前只有正常流程的管理，如果项目有风险，这种变更操作没有地方进行操作。
- 分配积分困难。每个项目有积分，项目完成后，参与人员需要对参与的每个同学进行打分，来分这些积分。这就比较考验人性和大家对其他人工作的熟知程度。
- 一些小的改动点无法在系统里体现，如修复bug，追查问题，回答问题等
这个系统有一个好处，无论数据准确与否，但是确实能量化每个人的工作量了，能够查看每个人的工时，也能看到每个人所赚取的积分。希望这个系统能越做越好。
所以项目管理系统还是挺难建立的，需要容易填写、容易查看、容易更新，再加上计算每个人贡献这种更偏向人性的部分，更加考验产品和研发的智慧。
总结
项目管理终归是必须的，所有人只有看到运行的一切才有安全感，才能更好的把控事情。但项目管理的本意是什么？我想最根本的还是想让业务能够更好更快的发展。
那以前我们没有使用任何项目管理的时候，为什么能够完成如此多的挑战呢？是不是里面包含了一些更重要的事情。
希望这边文章能够多少帮助到大家，如果大家有什么其他想法也欢迎大家反馈。
最后
大家如果喜欢我的文章，可以关注我的公众号（程序员麻辣烫）
往期文章回顾：