公司的中场

　　一个公司宛如一只球队，成败不是一个人的事情，是一整队的事情。那么球队在某一场具体比赛里面最重要的角色是哪一个？不是教练，如果说整个赛季如何可能是教练的功劳。如果是某一场比赛，最重要的角色是中场。对于公司也有这么一个中场的角色，不过不是老总，而是具体的那个产品经理。

　　其实产品是否成功，部分取决于总体效率如何。我把效率分为两个部分，一个是工作效率，一个是规划效率。

　　工作效率很好理解，就是每个工时的投入产出比。提高工作效率很好描述：如果我们以每一个人为坐标轴来观测，就是要求每个人都有合适的负担，不能够某个人负担过重，更不能某个人负担过轻；如果我们以每一天为坐标轴来观测，就要求每一天都有合适的负荷，不能一天忙死，一天闲死。合起来很简单，就是说每一个人每一天都要有合适数量的工作去做。

　　但是工作效率高了，不代表总体效率就高。比如说每天都在做，但是今天把昨天的推翻了，明天又把今天推翻了，那就是在瞎折腾。所以我们还要有规划上的效率，保证不会出现类似的情况。上面说的那种瞎折腾看起来好像不可能整天发生，但是实际上在我们面对变化的需求时，就会遇到这样的事情。

　　现代的软件工程是如何保证效率的呢？

　　从工作效率来讲，就是尽可能准确的给出每一个任务需要的时间，然后根据这个时间给出一个时间线（Deadline）。当然，不准确是必然的，于是还可能会中间有些CheckLine来避免无法完成任务的情况到最后快结束时才爆发，然后就是加班加班再加班。Checkline订多长合适呢？一星期？我个人认为确定每一天的计划更为合理，如果做不到，那么两三天也比一星期强。因为有的时候你会发现有的人做了一天还是好像没有什么进展似的，可能性有三个：要么规划得不好，没有自行细分更细的CheckLine；要么就是觉得得过且过，到那天再说，不急；要么就是能力不济，到最后都是这样。这三种情况我都见过，因此更紧密地时间检查周期是很有必要的，至少可以及时看出到底出了什么问题，可以有更大的余地进行有针对性地调整。

　　而规划效率呢，则需要准确区分新增需求、对旧有需求（设计）的改进以及对旧系统Bug的改进。作为项目经理，这几个概念是需要严格区分的，否则会产生很大的问题（这我也经历过）。

　　对于Bug，无论任何时候都是需要及时修改的。那么什么是Bug呢？就是系统的实际执行情况，和原来定义的设计是相违背的，或者对于没有定义的部分，是超出常规思维方式或者逻辑上有矛盾的。与此概念最容易混淆的，是对旧需求（设计）进行改进。我们经常会听到用户会反馈类似这样的抱怨：这个文本编辑器非常的不好用，我想要他固定一个具体的大小，它却只能够设置“大中小”，而且还会随着用户的操作变大变小；那个上传图片的地方也很不好用，只能一张一张照片的上传。那么面对这样的问题，我们可以很简单的将它和Bug区分开来：想一下这是当初就这么定义的呢，还是说定义的和用户一样，只不过开发人员弄错了？要区分Bug和需求改进，还有一个很重要的原因，是修改Bug和需求是完全不一样的。修改Bug的时候，只需要告知程序员哪个地方错了即可，而修改需求，则需要很多前期的工作，例如确定需求、制定UE、制作UI、套UI、修改代码等。通常情况下，修改需求都可以“转化为”新增一个需求。

　　而需求方面的新增和改进，则应该在新一个迭代之前收集，迭代开始阶段进行设计，然后进入开发阶段的时候就不应该再随意的更改了（除非证明设计有严重缺陷）。如果不这么做，你就会经常体会到今天推翻昨天的代码的情况。软件工程有讲，软件开发的整个过程中，越到后面进行修改，成本就越高。这里隐含着一个意思，就是越到后面出现的改动，你的沮丧情绪也越严重。这对整个团队是非常有伤害的。当然了，这也要求我们的中场，能够坚守立场不动摇，同时在开始开发之前，认真做好设计。

　　然而这些并不是做好中场的全部，中场还有一个重要的功能是把前后场联系起来，起到承上启下的作用。如果我们把系统限定为软件开发，则后场是UE、UI人员，前场是开发人员。此时中场的一个重要职责是，确定好后场的UE、UI制作是否按时完成，是否达到了前场开发人员能处理的质量水平。有的时候因为各种原因后场过来的东西，开发人员是无法处理的，例如没有切图而把整个页面的PSD给发过来了。中场就要检查和避免这种情况，如果你听UI说做完了，你就认为做完了，那是很不负责任的。最后，你的工作也可能因为这样的原因被拖了进度。

　　如果我们把系统限定为整个公司的范围，则后场是开发部门，前场是销售和客服部门。这时候，一定要想办法尽量减少前后场直接来回的情况。原因是，一个这样会有很多复杂的路径存在，到时候责任人不好理清楚，响应速度也可能很慢。另一个原因是，前后场直接开大脚，质量很难控制。比如说客服接到反馈说文字编辑器很不好用，直接就告诉相关开发人员，开发人员马上就开始修改了。这样做有很多比较要命的缺点：1、所有任务的优先顺序可能无法控制；2、开发质量无法控制；3、没有任何的设计就直接上去了（多数开发人员在这方面确实很差）。也许中场很忙，会有太多的事情做，那么这个时候也需要交由一个专门的副手来执行着一个工作，而不是前后场大脚乱踢。

　　如果你的职业规划中，未来有一段时间是要做中场的，那么上述的这类概念则必须要清楚。我不知道你的经历如何，就我的经历而言，违反上述规则的很常见。甚至有的时候，在某些地方我会被告知那样做是理所当然的（其实对方也说不出是个什么理，只是强调就是这样的，这就对了）。您认为呢？