艾伟也谈项目管理,让亲身实践者执行工作流程

  文 / 黄易山

  在这里,我使用“工作流程”这个词来描述“个人或团体为了完成一项活动而遵循的步骤”意义上的流程,以及组织的一般制度。随着一家公司的成长,有必要增加或整理工作流程。

  最重要的利弊权衡通常是工作流程所带来的阻力,以及效率或效益上的收益孰轻孰重。

  一方面,很难评估这种权衡中的利弊,因为其中牵涉到很多因素,所以有一条可能会有帮助的原则:只允许那些有特殊需要的工作流程被执行,而且要由那些直接使用它的人来执行。通常,经理和管理人员会提议工作流程,因为它会帮助他们更好地指挥、控制、协调或沟通。但新工作流程的执行不应该为这些目标服务,因为它的收益是不实际的,而且往往被高估:管理人员可以看到它带来的好处,但由于至少在一个(或多个)层面上不需要他们的直接操作,所以他们没有认识到它的真实成本。

  另一方面,那些亲自动手的人(如工程师)可以很容易地辨别,何时需要适当补充组织要素或工作流程,因为他们可以更直接地认识到收益将大于成本。只有在这种时候,才应该在组织中增加一个新制度或工作流程。

  经理们必须抑制住自己天生的恐惧,不要害怕由于缺乏对细节的能见度而造成的混乱或失控。他们应该重视依靠建立准确、翔实的背景情况和目标来进行领导,促进技术工人(不知为何,他们通常不是那种容易陷入无政府状态的人)之间互相合作而形成的自然组织。 

  影响

  个人制定并执行的工作流程,会针对真实工作的情况进行更多优化调整。管理者设计的工作流程,最多能接近实际工作流程,它需要管理、优化或整理。这是许多愚蠢、低效的工作流程的来源。

  在人们亲自制定工作流程时,会感到更大的自主权。在今后,随着情况不可避免地变化,也就更有权视情况对其调整,而不是任其僵化。外部强加的(自上而下的)工作流程更加难以打破,而且往往会被神化,从而产生非常大的组织惯性。

  对协调和沟通的影响

  对于协调和沟通,会有什么影响?这些不是管理者的职责所在吗?是的,这是他们的重要职能之一。然而,为此而创建的工作流程应该由经理来执行,而不能强加在普通员工身上。例如,团队状况和项目更新的广播是一种有用的功能,可以通知该部门或公司的其他人哪些事情正在发生。这是一个完全可以由管理人员完成的工作流程,并不需要团队中其他人的直接参与:经理可以撰写这些更新并分发给团队成员,但他不应该反过来要求团队成员也做同样的事情,因为经理与他们一同工作,可以(也应该)知晓团队运行的状况。

  这里的关键是,我们有一个有益于管理人员的工作流程,而这其中的成本也由他们承担,从而允许他们为自己的共同利益对工作流程进行优化。这不需要(也不应该)涉及到其他任何人。

  描述性工作流程的微妙危险

  指令性的工作流程意思是“这是为了完成X,你必须采取的步骤”,描述性的工作流程则是 “今天我们完成X后,让我们记录下采取过的步骤”。首先,描述性的工作流程是一个普通的、看似无害的建议,但不可避免地会导致同样的不必要的工作流程要求和僵化的组织制度,因此我们应该同样积极地避免使用它。

  首先,写下“我们通过这些步骤,完成了X”(其中的X可能是“推出一款产品”或“将一个想法从概念变为现实”或“申请一张新桌子”)的无害建议被采纳,而且这个工作流程被归档成一份文件,然后(也许)会被张贴在公司内部网络上。

  然后有一天,一名新人问道:“我们该怎么完成X?”在回答时,我们不再像老前辈那样非正式地解释完成X要如何如何,而是让他们去参考那份文件。毕竟,这比口头解释更简单快捷。在快速成长的组织中,新人加入的速度很快;很快地,这名新人变成了老前辈。另一名新人碰巧问他们同样的问题,这次轮到他们让别人去参考那份文件了。这个过程重复循环几次,该文件就被视为完成X的权威指南了。

  在公司现有的大多数人(在快速成长的公司中,新人总是比老前辈多)的概念中,原创的具有适应性的工作流程(适应性强、有机和运作良好,而且它的非正式使人们觉得它灵活)被文件所取代,文件现在被看成做某事的非常精确的规范。

  巧妙、可控制的灵活性减少,而且描述性工作流程成为了规范,但这无法归咎任何人。有时会更糟,因为有意的指令性工作流程存在的背后通常有一个权威的、能够亲自站出来呼吁的特定的人支持。僵化的原创性工作流程存在的背后有一篇单独的文件支持,给人们一种无法形容的类似法律的权威感,也就是说,超越任何一个个人的权威,在必要时就更加难以推翻和创新。

  长期影响

  在不同时期,我都曾参与过对潜在收购目标的慎重调查。最令人惊讶的发现之一是,在许多情况下,一个相对较小的公司却有更多的正规工作流程,这主要是由它们自己的员工所导致的,也是他们发展相对缓慢的原因:很少想法能得到执行,并最终导致了相对弱势的市场地位(有时,这是我们认真考虑某次收购的原因)。

  在Facebook,公司文化与工作流程是有抵触的,引入新工作流程的通常模式是“只有在事情快要不可收拾的时候,才会考虑引入新的工作流程”。尽可能地做到这一点,而且可能要更变本加厉,因为这样你所得到的回报将是整个公司的高效率。如果你的公司比其他同等规模的公司拥有更少的工作流程,你的创新和执行速度会更快,将想法从一个概念到最后推向市场也会更加快速。在内心深处,经理可能要和更多让他们不安心的混乱作斗争,但是让人不安心的混乱和真正对公司造成威胁的混乱有着很大的区别。越接近后一时刻,就越能够对比出技术行业的最大的优势之一:执行速度。

  工作流程通常建立在有规律的和大致固定的执行速度的基础上。因此,形成这种执行速度是保持长期高效的关键。如果你的公司有特定数量的工作流程,而且比其他同等规模的公司要少,那么你的执行速度会更快,而当你的公司变得异常庞大时,其中的官僚主义也比较少,这同样会产生倍增效果:当公司规模较小时,执行速度快两倍,意味着同一件事,你需要两个星期完成,而你的竞争对手需要四个星期;而一旦公司规模扩大,你可以在两年内完成的一件事,你的竞争对手需要另外两年才能迎头赶上。这多出来的两年对他们来说,可能意味着末日。

  (本文来自《程序员》杂志11年04期,更多精彩内容敬请关注04期杂志)

时间: 2024-09-09 00:18:49

艾伟也谈项目管理,让亲身实践者执行工作流程的相关文章

艾伟也谈项目管理,《播客》项目总结——项目管理方面

引言:如果标题改成<被管理总结>的话,我可以滔滔不绝的说上个半天,但是如果是管理项目的话,我实在肚里的货有限,因为到至今做过的最高职位不过是个"班长"而已. 但是这次<播客>项目在管理方面的确出了问题,而且是满严重的问题,以至于到后来项目差点失控,而且最终的交付作品质量的确让人汗颜.如何避免下面程序员很累,但效率却很低:上面不停的催,产品却一个bug接一个bug,完全没法交付:项目经理累的要死,项目却仍然处于失控状态这样的问题和局面?在一个差点失控的项目刚刚结束

艾伟也谈项目管理,如何管理“人”

我们常说工作中应该"对事不对人",但事都是人做的,不同的人做相同的事效果可能相去甚远,再好的业务如果用错了人也会全盘皆输.正所谓"事在人为"嘛,识人.用人.聚人是一个团队管理者获得成功的基础. 先说怎么认识人   人格矩阵法.即所谓的Topk技术,Topk就是由:tiger.owl.peacock 与 koala 4个英文单词的第一个字母组成,即把人的人格类型总结为老虎.猫头鹰.孔雀与考拉这4种动物的行为智慧: 老虎-此类人表现为:做事结果导向明显(不在乎过程),野

艾伟也谈项目管理,Richard Durnall谈系统管理和从外向内的组织结构

InfoQ中文站:能给我们介绍一下"系统管理理论"(System Management Theory)么?能不能跟我们分享一下您在实际应用中的经验? Richard Durnall:系统管理理论是过去五十年里出现并逐步发展而来的.它与传统的那种基于管理和控制方式的科学管理理论有很大的不同.首先让我们回顾一下管理科学的历史来了解系统管理理论. 在19世纪工业革命之前,商业规模通常不大,从业人数十分有限.19世纪30年代的技术革命中出现了大规模的工业企业.与传统的村镇工业不同,这些企业开始

艾伟也谈项目管理,一种适用于真实世界BPM的协作方式

我们在业务流程管理(BPM)领域里摸爬滚打已经很多年了,最近看到人们对它的关注不断提升,这是非常有趣的一件事.对这一趣事儿起催化作用方面的有,工具的日渐成熟.新BPMN2.0规范的形成.以及更多更好的相关出版物带来的人们对BPM的进一步理解,它们代表着BPM领域内最重要的进步. 厂商提供了越来越高精良的图形化工具以及由其承诺的业务流程实现自动化,无需任何编码甚至开发者参与:然而,我们也发现了使用这些"传统"的以厂商为中心方法的一个问题:它们并未履行任何承诺! 我们以前的一些项目可以佐证

艾伟也谈项目管理,我眼中的DevOps

相关文章:DevOps,不是一个传说! 过去一年以来,一批来自欧美的.不墨守陈规的系统管理员和开发人员一直在谈论一个新概念:DevOps.DevOps 就是开发(Development) 和运维(Operations)这两个领域的合并.(如果没错的话,DevOps还包括产品管理.QA.*winces* 甚至销售等领域) 脱节(The Broken) 那么--为什么要合并这两个领域?原因很多,但首要原因是:我们目前的工作流程是脱节的.绝对的脱节.很多公司的开发部门和运维部门之间存在的深刻矛盾,其实

艾伟也谈项目管理,敏捷个人:内容框架之执行力

    执行力是敏捷个人需要学习的一个内容,本篇主要介绍执行力相关的内容,大家在读后可以采用介绍的一些指南开始行动. 执行力的三个层面 按照命令和规则做事的过程,简单讲就是能够听话照做 按照预定的计划行为的过程,简单讲就是做事章法 将想法变成现实的过程,简单讲就是规划实现 对第一个层面来说,要做的事情是片段的.非连贯的,但对第二个层面来说是连续的.整体的.一个计划并不是一两个步骤做好就行,而要将整体的顺序都做好才能达成效果.有了第二个层面的执行,组织的运转就有了相对较高的效率,但仍然不够,这就需

艾伟也谈项目管理,我是如何带领团队开发项目的

最近有不少朋友写信问我一些关于团队开发的问题,由于这段时间有些忙,没有回复.今天写一篇这方面的文章向大家介绍一下我是如何带领团队开发工作流项目的 关于团队建设,项目管理的文章网上已经有很多了,在这里我就不谈这些理论了,直接给大家展示一个我在 项目开发方,后台服务开发方式,前台UI开发方式,后台服务与前台UI对接方式,代码文档,页面的开发文档,源码管理,单元测试,以及单元测试文档,实现思路设计文档,数据库文档,数据库设计规范,编码规范,操做数据的方法命名规则 方面的一些片断,这是一个为期6个月的工

艾伟也谈项目管理,编程习惯

文/Alexey Radul 译/程显峰 原文地址:http://web.mit.edu/~axch/www/programming_habits.html 近年来,我对编程艺术有很多体会.过后,我发现有些体会是错的:有些体会我遗忘了但又重新感受到:而另外有些则是必然会发现的.我还完善了一套项目管理的好习惯,这些习惯包括我自己的,或者小组的,抑或是更大的,公司内部的.一方面,这些习惯对软件的成功开发是至关重要的(太小或者纯粹巧合的不算),另一方面,这些习惯也不是什么高深莫测的东西,较小的篇幅就可

艾伟也谈项目管理,软件架构引言之项目管理的问题

软件架构引言之项目管理的问题   很多朋友都有过或者正在管理一个或者多个软件项目,那么我的文章就从这个问题开始:如果单纯从表象来说,软件项目管理过程中暴露的最大问题是什么?   不同的人的会有不同的答案,但是大致这样的答案我想大部分人都是会认可的,那就是"进度拖延".进度拖延当然是表象之一了,其他诸如质量不过关.功能不完整等等,我觉得都是和进度拖延密切相关的.很多项目经理都想去做那些认为是十分必要的事情,比如计划.测试等,但是"没有时间".为什么会没有时间?等到项目