一个重构眼中的“项目管理”

来TID做重构两年多了，眼看着团队像自己一样，从无序到有序，从青涩到成熟，一步步成长起来。从最初的每次例会上轮流抱怨需求变更、需求插单，到现在井然有序的需求排期、项目邮件，这其中的蜕变，看似简单，实则十分不易。前不久支持“XXX”项目时，看到上游的小伙伴们还在混乱中摸爬滚打，故写下此文，希望对这方面有需求的同学有所帮助，也希望这方面有想法的前辈、同学指导、探讨。

开始之前，有几点需要特别声明下：

此处所说的“项目管理”并非专业的项目管理（所以我打了个引号），项目管理这碗水太深，并未做过甚至都没看过别人做的我不敢在这儿评头论足。这里只是作为重构，作为项目的一个环节，对所遇到的问题及解决方法的一点浅见。
我所谓的解决方法，主要是团队leader鬼哥和bboy90的思想和方法，我只是从执行者层面表达一下自己的看法和认识。
每个团队的情况都不一样，遇到的问题和适用的方法也不一样。这里的团队背景是，需求（包括日常优化需求和项目）由产品经理来规划并跟进实施，对效果负责，也就是说，产品经理是需求的主导者。支持需求的各方资源，如交互、视觉、重构、前端、后台等都是公共资源，并不100%跟某个项目，而是在自己负责的产品线内，哪里有需要，哪里就现身影，也就是说，每个环节的资源（如重构）和产品经理之间是一对多或者多对多的关系。

好了，说这么多，开始进入正题了。问题大概是这样的，支持“XXX”项目时，频频收到来自上游的变更，与其沟通后发现他们也是深受其害而不知如何应对。下面是大概的沟通内容：

重构：亲，交互不是已经定稿了吗？怎么还在持续更新啊？

交互：没办法啊，之前开会提到过几个问题，产品方案做了点变更，交互也要重新设计下呀。

重构：为什么不让产品提个需求变更呢？这样你可以集中处理，也方便排期，对下游的影响也小一点。

交互：开会一起讨论过的，不用产品提变更了吧？

重构：那你其他需求不会受影响吗？

交互：会！有个“YYY”的项目，本来几天前就该启动的，这几天一直在优化我们这个，那个项目已经推迟4天了。领导一定觉得很奇怪，你这个项目不是已经结束了吗，怎么还在做。我也很无奈啊。。

……

重构：你最近很忙吧？除了我们的“XXX”项目，听说还在支持其他几个需求。

视觉：是啊。

重构：那你是在并行处理吗？应付地过来吗？

视觉：是啊，没办法，一起给过来了，都很急，只能自己撑着了。

……

这样的情况比比皆是，尤其是在新人中。因为大多数同学会有一个误区，觉得自己是来干活儿的，如果活儿来了自己反馈数量太多应付不来，会让人觉得工作态度不积极，或者能力有问题。所以都会先揽下，然后，要么很幸运的，有个项目卡在了上游环节，就可以理直气壮地说那啥啥稿还没提供过来；要么自己拼死拼活加班赶；要么忽悠产品经理，评估多点时间；要么谁催得紧先做谁的，催得松的就往后延呗，反正一般也不会投诉的。据我感觉，最后一种情况最多，第一种次之。羊毛出在羊身上，大家都是人，不是神，没有三头六臂，工作多的时候也不过在一定程度内提高点效率而已，不可能同样时间内有多少就能解决多少的。大家都明白这个道理，但大家都不敢把它放到台面上来讲，就像皇帝的新装一样，于是大多数人就这么糊里糊涂地躲过了一劫又一劫。通常，陷入这种境况时，除了手忙脚乱，还会很苦恼。明明自己很辛苦，明明自己已经尽力了，明明自己的工作能力也不差，却总是心虚的，怕这个催那个问。放在前面支持的，产品也不过是道声辛苦，放在后面支持的，产品虽也表示理解，但难免有不满的情绪。这种时候，也唯有祈祷上游提供得晚一点，或者会议、插单的事情少一点。

其实，这个问题并非没法破，只是对于新人或者资历尚不是很深的底层员工来说太难了。因为他们不够自信，他们知道自己的工作质量、效率都不是一流的，他们知道自己还有很大的提升空间，如果把问题抛出来，那就意味着要被挑战。这也是为什么say“Yes”容易，say“No”难的原因。所以，这个问题历史性地落在了项目管理或者团队leader的肩上。

所幸我所在的团队leader很给力，这方面一直管理有方，而且也在持续改进。下面就大概说下我们团队的“项目管理”之术吧：

首先，每个人都是资源，而且是稀缺资源，一个人工作一天的工作量叫1人日。假设团队有3个人甲、乙、丙，那一周可以支持的总工作量就是3人*5日=15人日。
假设这个团队要支持的产品线有两条，产品线A和产品线B。产品线A重要程度更高些，工作量也更大些，经协商，对产品线A和B按3：2的比例来安排资源支持，也即每周为产品线A投入9人日，为产品线B投入6人日。那资源的安排上，3个人中会有一个人（比如甲）全部投入到产品线A，一个人（比如乙）全部投入到产品线B，另外一个人（比如丙）部分支持A，部分支持B。
对于各产品线的需求，由产品线自己的接口人进行优先级排列，周一早上统一发给支持方接口人（如产品线A的需求优先级列表发给支持方的甲），支持方接口人评估每个需求需要的时间，根据协商好的人力数（如每周9人日），按优先级列表进行排期，若列表里的需求都排上了，固然最好，若排不完，看其他产品线的资源有没剩余的，即看乙和丙有没有剩余的人力，若有，则寻求支持，若无，排不完的需求顺延到下周再排。
若在支持需求期间，有新的需求插单，则插单需求的产品自行与其他产品协商，确定出谁的优先级更高。支持方只需关注协商的结果即可，若同意插单，则其他需求排期顺延，若驳回插单，则按原计划进行。
若在支持需求期间发生需求变更，视变更大小更新需求文件或重提需求，支持方重新评估工作量并修改排期。

如此，把原本就该产品内部协商的优先级问题抛回去了，支持方不必再为先支持谁的需求左右为难了，需求时间冲突时，也不必并行支持多个了。当然了，世上没有免费的午餐，要求别人规规矩矩地，那自己也不能乱来。这样做了之后，对自己的要求也更高了：

首先，需求的时间评估要准确。

其次，排期结果要反馈给产品，要按自己承诺的时间完成。

不想别人浑水摸鱼，自己首先就不能浑水摸鱼了。

当然了，制度是死的，人是活的，实际操作中可以适当灵活点。比如需求变更不大时，在自己可承受的范围内可以开开绿灯；比如紧急需求插单时，可以帮产品分析如何既支持插单需求，又把对原需求的影响降到最低。制度是为了让整个流程更规范、更顺畅、更高效的，但遵守制度的同时我们也要时刻记住，我们的目的是为了解决问题，为了更好地解决问题，而不是拉仇恨的。在别人需要的时候帮别人一把，不但是职业素养的体现，也为自己日后寻求别人帮助打下了基础。不过一定要把握好度，切记过犹不及。

上述方式对于日常需求来说可以了，但对于项目还远远不够。因为项目规模比较大，时间比较长，支持期间难保有其他事情插单、上游提供内容不及时、项目变更等等意外情况。诸多的意外可能造成你项目延期，或者完成后又返工，但其他人是不知道个中缘由的，别人只会看到你没按计划完成，看到你流转下游后还在修改。夸张点说，你可能在背黑锅，你可能在背黑锅你都不知道。这种情况怎么办？透明化！在我们团队，是有一套项目专用的邮件模板的：

开发计划模板主要内容，用于项目启动时：