本文是从 How to manage your Programmers 这篇文章翻译而来。
以一个组织的形式完成项目、任务或实现某些目标,这被称作公司,这需要有完善的信息流转机制和长期的规划。过程管理在这种组织里是一个非常复杂的问题。这就是为什么这些年会出现了大量的诸如Scrum,
Kaizen, Kanban等技术和方法论来尽可能简化这个过程。简言之,这些东西都是用来最有效的发掘你的员工的全部潜能的。
基于此,我们通常会有一个重要人物,他可能是一个领导,一个经理或一个总监,等等。这就有了问题:这些人有什么样的特征?一个管理者和一个程序员之间的不同之处在什么地方?他们的角色可以互换吗?
为了弄明白这个问题,我们需要从人的视角上去思考。换种方式来说,我需要用到人的因素这个词。
首先,要想管理人,你需要去理解他们。要做到这些,我们需要有情商。这并不仅仅指只针对我们这部分人。我们做的任何事情中都存在情感,你要从个人角度去体验它,要熟练掌握,在我们的公司管理中的合作方式上不能忘记这一点。管理并不仅仅指控制和命令,它还包括聆听,理解,沟通和对复杂的情绪上的问题给出有效的方案,这都是至关重要的。
很多人都忽略了管理工作中的这方面问题。有时候会很戏剧化,类似于这样:“鲍勃,从明天开始你就是一名项目经理了,因为我们的程序员太多了,需要去管理,但不用担心,你就要去上一个Scrum大师班了”。我们都知道这样的认证证书是什么样的,有什么价值。这跟那个10天的ICC培训课程后成为一名教练的故事非常的相似——这行不通,你要铭记!
另一方面,Mark Foster在他的标题为《How to make your dreams come true(如何实现你的梦想)》一书中谈到,实现目标有两种方式:推(Push mode)和拉(Pull mode)。前者是使用一种工艺上的技术来完成一项任务,比如程序员编程,而后者依赖于经验、直觉和情商,从而选择最好的方式解决一个问题——这是管理者的视角。当使用这种管理模式时,管理者是不能和程序员进行角色互换的,反之亦然。一些大公司通常使用这种管理模式。而这种方式有时会损失一些员工的潜能,因为在多个级别的管理职位中产生的太复杂的层级关系。
为什么?很多的小公司都使用敏捷方法论。这是一种基于合作的方法论。上面描述的模式并不能满足他们的需求。在不同层级上的管理者和程序员之间始终存在着一个隔膜。人们会被分成“脑力劳动者”和“体力劳动者”。结果就是导致我们失去那些同样有大脑却从来未被使用的人。如今,所谓使用有效率的员工就意味着把所有人都当作脑力劳动者。
Evan Rose 说:
命令/控制(Command-and-control)文化使人们把公司成员分成了脑力劳动者和非脑力劳动者。他们让脑力劳动者去思考,让其他人去执行命令。这种文化中,合作没有基础。更重要的,信息的流转应该是多向性的,而不是瀑布式的从高层经过多个管理层流到一线员工。事实上,如今的每个人都有资格成为一个脑力劳动者
现在出现了一种称作自我管理的形式,这种形式本是我们这个世界的基础。如果我们本来是自我管理的,为什么不更进一步呢?也许我们根本不需要管理者。37Signals 和 DHH都实现了这样的思想,描述起来如下:
我们同样也让我们的团队管理自己。每周,一个员工会站出来当管理者,他制定简单的日程计划,审查其他人的工作,更新公司动态信息,他对于其他同事来说是一个关键人物。这种职务轮换每周一次。你知道我们发现了什么吗?当每个人都知道自己要当一周的国王时,神奇的事情发生了。对管理者强迫自己做某些事情的抱怨消失了,因为职务的轮换让他们有机会同时清楚的了解了围栏两边的景观。如果你让员工们这样做,这给了他们提高和成长的机会。
但不要想当然。这并不是适用于任何地方任何人。但就像David说的:这种方法可行性很大。如果你能理解这点,你可以在团队或部门里试验一下。通常在小公司里当某方面出现问题时你能相当很快的对其作出反应,这能让你更容易的避免重大事故的发生。
简言之,不管你的管理方式是什么样的,永远要记住,在公司组织结构的深处有一种叫“人的因素”的东西,它在等待着你去照顾,它能摧毁你所有美丽的计划。唯一你防止这种灾难发生的办法就是要认识到:你在跟人打交道,不是机器。