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

标签：style   blog   http   color   get   width   

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

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

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

好了，说这么多，开始进入正题了。问题大概是这样的，支持“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人日），按优先级列表进行排期，若列表里的需求都排上了，固然最好，若排不完，看其他产品线的资源有没剩余的，即看乙和丙有没有剩余的人力，若有，则寻求支持，若无，排不完的需求顺延到下周再排。
• 若在支持需求期间，有新的需求插单，则插单需求的产品自行与其他产品协商，确定出谁的优先级更高。支持方只需关注协商的结果即可，若同意插单，则其他需求排期顺延，若驳回插单，则按原计划进行。
• 若在支持需求期间发生需求变更，视变更大小更新需求文件或重提需求，支持方重新评估工作量并修改排期。

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

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

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

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

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

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

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

项目变更模板主要内容，用于项目内容有较大变更或者有其他需求插单时：

项目待确认模板主要内容，用于本环节完成时：

通过几个阶段的邮件，使自己的计划、输出清清楚楚，不但有利于自己的时间管理，保护自己免于各种误会，还可以使产品和上下游清晰地知道你的进程以及对他们的影响，减少沟通成本。而由于这些邮件都有现成的模板，你只需填内容进去即可，并不需要花多少时间在邮件的编辑上。

Ok，回到最初的问题，如果上下游都这样管理自己的项目，自然就没有问题了。在上下游都有序管理自己的项目的前提下，如果进行过程中，项目变更了，该当如何呢？结合当时大家的讨论结果和自己的想法，简单总结一下：

变更内容由产品经理通过需求管理系统或邮件发出，尽可能集中。根据变更内容对现有开发的影响程度和变更量的不同采取不同的措施。

以上，欢迎拍砖~通常来说，明事理的产品经理都是支持资源方这样管理自己的项目的，因为这样也更利于他们对项目进度和项目风险的把控。总之，一切只为合作更愉快，一切只为工作更顺畅，一切只为项目更高效！

以上，欢迎拍砖~

2014.6.19

一个重构眼中的“项目管理”,布布扣,bubuko.com

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

标签：style   blog   http   color   get   width   

原文地址：http://www.cnblogs.com/lilaczhu/p/3798180.html