您的位置:知识库 » 项目管理

公司的中场

作者: Sumtec  来源: 博客园  发布时间: 2009-05-31 15:39  阅读: 2032 次  推荐: 0   原文链接   [收藏]  

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

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

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

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

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

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

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

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

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

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

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

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

0
0

项目管理热门文章

    项目管理最新文章

      最新新闻

        热门新闻