介绍一个敏捷团队的绩效评估方法

有很多不做绩效评估的理由。Google是不做的。在google每个人有一个网页,里面有照片,个人简介,三个月目标。每个人在这个网面里做自我评估。

如果你必须得做绩效评估的话,在这里介绍一个1993首次在Easel公司实施并且后续在多家领先的企业中得到优化的评估流程。Hyperproductive团队曾使用这个方法来加速改进他们的效率。 (Hyperproductive 曾创记录的快速递交产品,很多计算机媒体的记者曾惊叹这是他们所见过的同类产品里最好的。) Read more

建设自管理团队的九个要点

自管理团队的概念并非源自于软件行业,在传统的制造业中这个概念的存在已经有很长的时间,其最早可以追溯到20世纪50年代的英国和瑞典的汽车制造业。

自我管理型团队,是新型横向型组织的基本单位。自我管理型团队是早期团队方式的发展产物。例如,许多公司都使用跨职能团队以获得跨部门的协作,用任务组来完成临时项目。还有的公司使用“解决问题团队”,这种团队由自愿临时参加的雇员组成,他们开会探讨一些有关改善质量、效率和工作环境的方式。 Read more

敏捷绩效评估

每年我们都痴迷于为团队成员评级。回顾软件开发领域,好像已经有近50年历史,有一些我们可以肯定的是:软件是由团队来创建的,而不是个人的。此外,每个人都需要积极主动的合作来生产有质量的软件,这意味着团队中的每个人来承担集体所有制,并且相互帮助。因为他的主旨并不是成为一名英雄,而是创建一个超高质量和可预测的最终产品。 Read more

我所知道的关于Scrum团队的一切都来自MASH

我热衷于参加团队组。我喜欢进行讨论,也乐意见到参与讨论的朋友。有很多问题重复出现,但是经常都能引起不同的讨论,而我个人认为这是好事。因为这些话题每次出现的时候总是能够让我学到新的东西。

一个经常出现的问题就是:“应该让谁来当Scrum Master?”有时候问题简单得就像“我们要开始实施Scrum了,所以我们要一个Scrum Master。但是应该让谁当呢?”有时候问题又稍微深入一点。很多这样的对话都集中在团队在向Scrum转型的过程中,如何将项目经理转变成Scrum Master,而这个问题是转型过程中一个自然的步骤。虽然,我觉得这是自然过渡的一环,但是我不大确信它像想象中那么有用。在我们无休止地追寻自我的过程中,我将会用70和80年代一部非常有名的节目——MASH来解释。 Read more

命令和控制:让我们来聊聊权力

命令和控制不光只是一种思想和管理风格(虽然同时是这两者),但我们却不曾提起处于管理角色的人们所拥有的权力。

传统的管理层都拥有一定的权力,虽然权力的来源多种多样。有些时候管理者对权力的滥用会激怒公司中的其他人。当然,我并不是说要将所有管理者都开除掉,或者说取消能够帮助公司在一定边界内有效地运行的“控制与被控制”的关系,这种关系对于公司财务、培训、行政或者其他系统都有着不可或缺的作用。但是,这里所说的“控制”并不是指利用职位的权力把大家都限制在一定的界限内,这就是泰勒式管理的本质。 Read more

支持特性团队

当我最初给某个位于加州的游戏工作室做咨询的时候,它的团队是按照存在于他们开发的游戏中的具体的内容和对象来组织的。对于每个角色有一个单独的团队,比如包括武器团队、车辆团队等。这带来了一些问题,比如武器太弱以至于不能够杀死怪物,颜色太暗以至于不能显示秘密通道和障碍,这样的问题,即使是那些最耐心的玩家也会感到沮丧。

在更传统的企业应用项目上,当团队结构是几乎按照应用程序分层来划分的时候,我们看到了同样的问题。举例说明,一个典型的项目早期阶段的错误,它将有4个团队:一个富客户端团队,一个Web客户端团队,一个中间层团队,以及一个数据库团队。创建一个这样的组件团队会带来各种问题,它们包括 Read more

良好的团队结构指导原则

以下是一套用于思考如何设计一个合理的团队结构的指导原则。每一个指导原则,以向现有团队或者拟议的团队提出一个问题的形式出现,并且这些问题需要迭代地询问。询问现有团队或拟议团队每一个问题后,根据答案改变团队结构;当团队结构改变后,重新再询问,直到对于每一个问题,你都可以回答“是”。
这个结构是否可以突出优势,弥补不足,并帮助团队成员提升积极性? Read more