Category: agile 敏捷

云计算2013~2014纵谈(下)

回顾2013,Hypervisor和Container虚拟化技术都基本尘埃落定,云计算领域的大玩家也都已经基本进场,更多的中小玩家在纷纷自立山头。这只是云计算的起点,根本不是云计算的重点。展望2014,更多的领域将等待着云计算团队们去突破,云计算更多的想象空间等待着整个市场去挖掘。笔者不才,妄自预测了2014年的云计算新趋势,可分为如下四个方面:

  • Cloud Native Application:运维从未有像今天一样这么深远地影响到软件的开发和设计。软件应用在架构上如何更好地弹性利用已有的云服务,这将成为未来一段时间的重要命题。传统的软件开发对于可扩展性和运维考虑的是各级模块的纵向扩展和HA,但Amazon AWS的CloudFront、EC2、EBS、S3、DynamoDB基本就涵盖了网站的CDN、计算、文件系统、存储和数据库,这些对于一个中大型的互联网网站已经绰绰有余,企业又有什么理由不去利用?再比如,传统的软件监控往往强调MTTF,Netflix开源的Chaos Monkey则对系统的MTTR提出了更严格的要求。
  • Cloudify OPs:传统的运维只是单机版1.0,未来的运维需要同时操作上千台机器;传统的运维只是被动地执行变更,未来的运维需要主动地提出变更。如何结合企业的运维流程和要求,从整个企业全局的角度提高运维的效率?如何即提供服务平台,同时又保障运维的合规?《Measureing IT》这本书里面提出了SPO(Servers Per Ops)指标——一个运维人员,能够支撑多少台服务器的运维、配置管理、应用部署、监控警告等。类似于互联网思维对于产品经理的思维改造一样,运维人员用云计算的思维、技术和工具对自己的日常工作进行改造。这一点对于国内的运维团队更为重要,否则,人力成本导致“人海战术”的难以为继只能阻碍运维团队为企业创造更多的价值。
  • I&PaaS:2011年,NIST定义了云计算的几种类型,但谁又规定了IaaS、PaaS和SaaS的边界不能被打破?IaaS、PaaS和SaaS都只是运维服务平台化的实现方式而已,只要有需求,就没有不能被打破的藩篱。Amazon AWS支持Beanstalk,Google除了GAE之外也推出了自己的Cloud。如今,OpenStack也加入了LXC的支持,业界涌现出来OpenStack加上CloudFoundry或OpenShift组合向外提供PaaS服务的案例。未来IaaS、PaaS两者的融合会越来越多、越来越快,也算是上文提及的IaaS厂商下沉IT服务的一类。
  • Cloud Security:随着企业的应用迁移到云计算服务厂商,视数据为生命的企业对云平台的安全性也提出更高的要求。Amazon和GMail在2012~2013的几次事故都给云平台的可用性和安全性提出了质疑。进入2014年,随着个人云、穿戴设备的兴起以及小白用户对云平台SLA的不了解,都给数据和云的安全提出了更高的挑战。如何从云的整体技术栈着手,构建全面的安全服务,不出现任何的短板;如何从租户的隔离上下手,减少租户对底层系统的突破,减少租户之间的攻击;又如何在第一时间侦测到安全的问题并采取措施修复问题,这些都是云服务厂商需要考虑并强化的点。

当然,相信2014年云计算的创新会远不止以上的四个方面。当第一块多米诺骨牌倒下,第32块多米诺骨牌可以推倒帝国大厦,谁又能完全正确地预料云计算的未来?至少据Gartner预测,随着云计算服务认可度的持续增加,云计算服务市场这种高速增长的态势将至少持续到2014年,2013年全球云计算服务市场总收入将突破1500亿美元,2015年突破1800亿美元。无论从哪个角度,这都是一块足够大和诱人的蛋糕。

“这是一个最好的年代,也是一个最坏的年代”,狄更斯在《双城记》中的开场白吐尽了无限的沧桑。电影《这个男人来自地球》的主角从山顶洞人时代一路走到现代,看尽风月通晓古今,却谓叹无法突破时代的局限,只能追随时代的弄潮儿。时代的弄潮儿已然登场,我们是台下的观众,抑或后台等待,又抑或门外的路人?当2014流逝,我们未来回顾的时候,又会以什么样的心情来看待自己在其中的位置呢?

—Done—

云计算2013~2014纵谈(上)

“旧时王谢堂前燕,飞入寻常百姓家”,在2013已然逝去、2014徐徐展开的时间节点,用这句话来描述云计算是再合适不过了。曾经被视为小众的云计算,正式成为市场的主流,传统的重量级厂商纷纷投靠唯恐落后;曾经处庙堂之高的云计算,已然走下神坛,大量的小厂商和产品如雨后春笋;曾经遥不可及的云计算,已经来到身边,深刻地影响着国内广大的公司和开发人员。行云流水间吉光片羽,除了不胜唏嘘之外,更令人深思和激动。

2013年12月18日,Amazon宣布推出中国区域云计算服务,取道宁夏而屯兵北京。“银瓶乍破水浆迸”,消息传出,阿里云推出“12.18新起点再起航”部分免单活动,全线产品降价;IBM宣布与世纪互联合作将其云计算基础架构服务SCE+(SmartCloud Enterprise+)正式引入中国;微软也正式宣布联想成为中国首家微软Cloud OS战略合作伙伴;腾讯云的年终大促也拉开大幕……一时间山雨欲来,溪云压城。

只是这一次,Wintel的美谈已成历史,微软也早不复当年之勇。且不论Windows 8、Windows Phone和Surface的评论与销售双双滑铁卢,Windows Azure挣扎这么多年,仍然无法成为市场主流。虽然亲生的Hyper-V虚拟技术对Windows系统的支持最好,但始终不温不火。只有深度依赖微软技术栈的客户,还保持对微软技术的不离不弃,倒也不负恩泽。

廉颇老矣,何论冯唐?百年IBM在给宣传SmartCloud时自豪地宣称专注虚拟化40年,一口气将自己的虚拟化寻根到上世纪70年代的System/360,俨然一副“蓝色巨人”的风范。只是2013年6月当NASA宣布放弃IBM而选择Amazon AWS的时候,不知道40岁的SmartCloud是否老泪纵横?

屋漏偏逢连阴雨,过去的一年中国内云计算界在淘宝的带领下也掀起了对“巨人的进击”——“去IOE”的声音越发响亮。在云计算的时代,IBM的小型机、Oracle的商业数据库、EMC的存储在X86的廉价集群前溃下阵来。淘宝在2005年以蚂蚁大军击败eBay大象,如今“蚂蚁缠斗大象”的一幕似乎将在IT基础设施的领域再一次上演。2013年5月17日,阿里最后一台IBM小型机在支付宝下线。那张照片是这次“去IOE”革命的最好注脚。

无怪乎RedHat、Canonical、VMware、Intel等厂商也纷纷追随RackSpace和NASA,进入以OpenStack为代表的开源云计算社区,或以产品、或以资助、或以资源等方式试图在廉价云计算市场占得先机。除了收购DynamicOps和Nicira,VMware组建了一支专门的开发团队向OpenStack代码库提交针对vsphere Hypervisor的代码。Intel从2012年起,就开始深度参与到OpenStack的开发中去,其上海的测试团队就一直对OpenStack的各个版本提供测试。在移动市场失掉先机之后,Intel在云计算、大数据和穿戴式设备领域终于找回了感觉。

“三十年河东,三十年河西”,在过去的一年中,开源社区和中小型厂商迎来了属于它们的机会。我们不仅看到了基于容器的虚拟化技术的兴起,也看到诸多新鲜血液加入到云计算的市场。

Joyent在收编了Solaris的一批开发骨干之后推出了SmartOS,不仅进一步完善了Solaris的Container/Zone以及ZFS,而且将Linux下的虚拟化Hypervisor KVM移植过来。于是,以NodeStack和Fengqi.Asia为代表的部分公有云厂商选择了SmartOS作为云平台底层虚拟化的核心组件。除了Unix,在Google的大力推动下,基于cgroups技术的LXC在2013年也是在Linux社区得到了极大的重视和发展。腾讯基于LXC推出游戏云,为QQ游戏提供更弹性的资源配给和资源隔离服务。与此同时,以Docker为例的工具在过去的一年内也夺取了很多眼球,甚至进入到商业市场。百度在它的BAE(Baidu App Engine)中就使用Docker来管理底层的资源。

除了上面的重量级厂商和公司,国内的中小、创业公司也是捷报频传。先是2013年8月金山云宣布2000万美元的融资,接着上海的UCloud宣布获得1000万美元的A轮投资。最近,想做中国AWS的QingCloud又在2014年元旦之际宣布2000万美元的B轮融资。风投资本再一次投出了自己的一票,用赤裸裸的金钱证明了他们对于国内云计算市场的看好。

上述都是针对基础设施的厂商,他们结合底层的各种Hypervisor和Container将面向IT的服务固化到他们的云平台之中。与之对应的是,传统意义上位于运维上层、离一线运维人员更近的配置管理、任务编排、日志监控以及日常运维等领域也是英雄迭起、精彩纷呈。很多厂商将不同层次的技术结合起来,以期在IaaS上提供更多的增值服务。RightScale将IaaS和Chef结合,提供跨越不同云平台的虚拟机镜像服务,甚至支持企业内部的vSphere;Travis-CI将Vagrant和VirtualBox结合,向GitHub这类的代码托管厂商提供持续集成的服务;ScaleWorks将vSphere、OpenStack和Chef结合,向企业提供针对已有虚拟化技术的云化方案;Modern.IE则把眼光放在了Windows IE版本兼容性测试的领域,结合VirtualBox、VMware和Parallels提供标准的虚拟机镜像服务……更别说Chef背后的OpsCode、Puppet背后的PuppetLab和Ansible后面的AnsibleWorks了。大量的运维人员将自己的最佳实践转化为开源或商业产品,守得云开见月明。

实质上,云计算从来都不是目的,背后的CapEX、OpEX以及Productivity才是真正的诉求。而这,是永远不变的主题。云计算通过虚拟化和标准化,将精通运维的团队与个人的生产力池化而后量化、再服务化,使得大量的非运维人员可以以很低的价格享受优质而有SLA保障的运维服务。因此,云计算可以算得上是技术挑战商业的又一次成功案例。

—TBC—

让非技术人员理解设计

作为技术人员,我们经常需要跟客户、业务分析人员等非技术人员沟通软件设计方面的问题。如何比较直观地向这些非技术人员解释设计、软件质量对项目的影响,解释糟糕设计、不干净代码给项目带来的风险,解释我们必须开始关注软家设计问题?这里有两个概念(metaphor)可以帮助我们达到这一点。

Continue reading

浮潜与水肺潜水

不同形式的分析活动贯穿于项目的整个生命周期:自上而下、自下而上以及先中间后两边。


浮潜潜水员游弋于海水表层,看鱼戏浅滩,望影掠深海。水肺潜水员可以潜过海水表层的深度;他能潜到更深的地方,在一定的区域内研究那些影子以发现鱼类、沉船残骸以及珊瑚的细节。在相同的时间内,浮潜潜水员可以游历更宽阔的水域;而水肺潜水员则在潜游深度上占据优势。成功的项目团队在项目的整个过程中会把浮潜和水肺潜水这两种方式结合起来使用,在特定的时刻明智地选择合适的方法,从而有效地利用了时间。

浮潜是一项很好的技术,项目团队可以用来弄清楚需要研究多少领域,以理解问题和达成目标。往往在项目或者子项目的起始阶段,团队通过浮潜识别出研究范围、目标、利害相干人、研究边界、已知事实以及需要进一步水肺潜水的地方。

当潜水员感觉到一些有趣的东西、陌生的事物或者更深的细节信息需要考察时,他会进行较深的水肺潜水。深度潜水的发现常常会改变浮潜阶段所设定的假设。假如我们发现了某种海产生物,而此前我们并未预料到能在这片水域找到这种生物;那么,我们就需要调查更宽更广的范围,以找出这种生物的繁衍区。

本模式的迹象之一是团队在做广度(浮潜)考察的同时,也会——而不是忽略——针对特定问题进行具体的(水肺潜水)工作。关键是团队在项目的整个过程中应用广度深度究技巧的能力。研究的广度范围识别出可能会对项目产生影响的人、组织、硬件和软件系统。在广度上知晓得越多,就能识别出高风险与高收益的领域,以及如果辅以进一步的深度研究可能大有裨益的领域。

掌握浮潜与水肺潜水技能的项目团队不会因问题域之宽而气馁。团队成员知道自己不需要对整个问题域都进行同样深度的研究。例如,如果他们决定针对问题的某一部分购买已有的解决方案,那么他们的研究只需要深入到足以验证解决方案是否适用于工作情形即可。当他们决定开发自己的解决方案,则他们需要判断这项变动要求多深的研究。他们同样知道某些更深入的研究可以推迟到以后某个更为合适的时间。面对较宽问题域的项目团队在响应变化上面更胜一筹,因为他们可以预见改动所引发的影响。他们对于哪些是自己所知道的、哪些是自己所不知道的、哪些是需要加以探索的以及哪些是可以放在一边的,都是心中有数。他们能够计划如何使用资源以获得最佳效果。

引入浮潜与水肺潜水技术的项目很可能把软件原型、模拟物与上下文建模联合在一起使用。他们也可能使用增量式的交付方法,在项目早期交付价值最高的功能。同样,他们也能够只用一页的篇幅就清晰地解释项目的范围和目标。

本模式的反例是团队要么沉迷于细节(“我们只做水肺潜水——懦弱无用的浮潜免谈”),要么惧怕细节(“我们是浮潜潜水员——换句话而言,大海深处有怪物”)。并且,当人们谈论“更高层次”和“细节”就好像它们互不相关、了无牵连的时候,也属于本模式的反例。

优秀的开发人员不会画地为牢:他们既可以浮潜,也能水肺潜水。他们依据自己需要考察的对象来选择技术。侦察的时候,浅层潜水就已足够;但如果审察,就需要更深的潜水了。

有时,仅仅用脚趾探探水就足以知道不能跳下水。

浓浓的特性汤

    “体面汤、浓又黄,

盛在锅里不会凉!

说什么山珍海味,哪儿有这样儿香?

半夜起来喝面汤,体面汤!

——刘易斯·卡罗尔(Lewis
Carroll
),《爱丽丝漫游仙境

产品夸耀自己繁多的零碎特性,其中很多对于解决客户真正的业务需求几乎毫无帮助。

在一开始的时候,一切都显得那么美好。市场部有一个来自于客户的请求——添加额外的下拉菜单。然后,在产品中添加一个输出接口的需求来了,产品经理想要加上一份新的分析报表,DBA要求在数据库里增加一个新字段以改变背景的颜色。所有这些需求以及其他更多的需求,都交由开发人员负责加进到产品里面。随着需求的不断添加,产品的特性集不断增长,但过了一段时间之后,每个人——市场部、客户和开发团队——对如何将所有这些碎片整合在一起、这些碎片如何帮助实现业务目标,失去了理解。曾经带着明确目标出发的项目变成了难以下咽的、由各种无关特性炖成的一锅汤。

情况变得更加汤汁淋漓,因为感兴趣的各方都从不同的角度来看待产品的需求,根本不存在共同的、连通的思路。市场部从营销的角度把需求打包成一组一组的特性集合,也不管它们在功能上是否内聚。开发人员则按照自己所使用的实现技术对需求进行归类。各个客户也只是从他个人工作的角度出发单独地对需求进行考虑。这些离散的需求所带来的影响就是各人谈论进度或者对变更做出决定的方式都不一致。按照产品版本的主题再取折衷已不可能,因为根本就不存在一致的主题;相反,产品变成了混杂着各种玄机的大杂烩。

为什么如此多的产品最后以沦为特性汤收场呢?这一切都始于需求的源头——人们。

人们很自然而然地会认为自己的需求才是最重要的。同一个组织中的不同部门,或者不同的客户,都想获得属于自己的、与众不同的特性,于是提出的需求根本不顾及产品在整体业务上的一致性也就不足为奇。而这,就是分析师的工作了。

当零散的需求来了之后,分析师需要将它们与受之影响的业务流程映射起来。这种映射提供了一种方法——向不同的人们展示建议的变更对他们的工作可能产生的影响(有时非常令人惊讶)。这种分析让分析师获得了基本的理解,从而进一步发现人们真正需要的——以及变更是否提供了真正的好处,抑或仅仅是另一个滴入汤中的特性。

特性汤的另一个来源是设计人员在面对一项新需求的时候,不去追究其与既有产品在整体上的关联,就将其加入进来。设计人员应该发问,“它是否属于已声明的范围?”“与既有产品的接口是什么?”“它是否重复或者搞乱了已经存在的东西?”

在解决这些问题上的重复失败导致产品变成了一堆离散碎片的组合。需求是基于离散的特性,从本质上这意味着项目对于“什么是属于范围内的”以及“什么是超出范围的”没有客观的定义。因此,额外的需求就很容易从不同的来源渗透进产品里面——事实也确实如此。产品变得越发分离崩析,它也就越发难以评估,做出的变更就越发难以前后一致;一路螺旋直下,回天无术。

避开特性汤的组织有着很多的共同点:

  • 尽可能不留余地、尽可能早地定义项目目标和非项目目标。

  • 声明项目范围,并以精确定义输入/输出数据的形式时刻保持更新(参阅第24项模式,“白线”)。

  • 拒绝那些对声明的目标没有积极效应、而又明显超出项目范围的需求——进一步锤炼、巩固了钢铁般的意志。

  • 新需求的添加遵照被核准的、可追溯的变更管理流程进行,同时使用项目声明的目标对它们进行评估。

避免特性汤得靠纪律。时刻牢记着是你们——整个项目团队,而不是零散特性的请求者——将会身陷浓汤:这绝对划算。

同事预审


在如今大部分的组织里面,是否给申请技术职位的人提供工作机会——这个最终决定权属于管理部门。经理们雇人,经理们裁人:一切都天经地义。然而在某些组织里面,这些技术人员能否得到工作机会却是取决于——至少部分取决于——他们将来的同事。这种同事预审的最终结果只有一种:当经理们让技术职员拥有发言权的时候,每一个人——申请人、职员和经理——都会和盘托出自己的想法。

招聘流程的前期阶段基本上没有变化:通常由第一线经理对申请人的材料进行最初的筛选。经理也许会要技术方面的高级职员先审阅简历,把所有的申请人归为“下一步”和“不,谢谢”两类。经理也许会给那些简历看上去非常华丽的申请人拨打电话聊一聊,做一个初步审查,决定邀请哪些人过来现场参加面试。获邀的申请人会被告知他将和团队在一起呆上36个小时。一旦众多的同事参与到招聘的过程中,面试的当天往往非常的漫长。

在抵达公司并与经理寒暄过后,申请人就随同各位团队成员开始一系列的面试。每轮面试的会谈时间从30分钟到90分钟长短不等。

虽然每位参加同事预审的面试官从申请人身上得到的信息相同,但每个人都会使用不同的方式调查。很显然,每个人都希望对申请人的知识、技术和能力做出评估。所以,针对招聘职位的类型不同,从团队的角度出发也许会要求申请人编写一些代码,或者创建一组测试。但是,每个面试官都会再以个人的角度去评估申请人,他会问自己:“我能和这个人一起工作吗?”“他能适合我们这个团队吗?”“他会让我们团队变得更强,还是更弱?”

此外,每个面试官将以自己在团队之中担当的角色去评价申请人。举个例子,如果申请人是一名开发人员,相较于团队里的开发人员,身为测试人员的面试官就会提出不一样的问题,以挖掘申请人的个性特征。

每个面试官也会根据自己的以往经验去评价申请人,问自己这样一些问题:“这个人展现出的技能与解决问题的方式,是我最为欣赏的吗?”“这个人在多大程度上让我回想起曾经合作愉快的同事,又在多大程度上让我回想起无法合作顺畅的同事?”“这个人是不是像他表现出来的那般优异,又抑或他是在假装如此?”面试官背景的多样性,使得团队可以从多个视角和价值取向来甄别将来的同事。

在把申请人交给下一轮的面试官之后,这一轮的面试官向经理——或者面对面地交谈、或者通过邮件,又或者拨打电话——就他对申请人的印象和意见发表个人的观点。每位职员都需要针对“假如由我来裁决是否雇用这个人”这个议题投下自己的一票。

如果面试一切进展顺利,申请人最终会回到经理这里,而此时经理也已经知晓了所有面试官对该申请人的看法。经理现在要从他自己的角度出发来面试申请人,然后告诉申请人是否得到了工作机会。即使其他的面试官都表示认可这名申请人,经理也可能会由于某些原因决定不对其提供工作机会。但是,如果团队的大部分成员都对该申请人倒竖起了大拇指,那肯定是没有理由再雇用此人了。

当团队在招聘过程中真正拥有话语权的时候,此时就出现了多赢的局面:

  • 当前的团队成员是赢,因为新员工加入团队的时候,大部分的团队成员都已经跟他见过面——实际上已经接受了他;不被职员接受的那些人是绝对不可能跨过那道门槛的。

  • 申请人也是赢,因为他处在了更有利的位置来决定是否要加入这支团队。他可以接触到未来的同事,而不仅仅是老板。他可以询问工作的真实情况,同时也可以感知公司的文化。

  • 经理是赢,因为他可以借鉴整支团队在技术方面对申请人做出的评价,而不是仅仅凭借自己的揣测。他也知道团队在一定程度上已经接受了这个“新员工”,而且团队对他个人的成功也非常重要。

  • 最终,团队作为一个整体也是赢,因为团队成员在参与同事预审的过程中,可以向其他人学习。在阅读其他人对申请人的评价时,团队成员能发现其他人使用的问题和标准,而他们可以在以后的面试中把这些派上用场。经理也能对自己团队成员的思维方式有更深的了解。

从经理的角度上讲,同事预审在雇用团队领袖的问题上面同样有效。为什么不邀请团队里的一些成员去面试未来可能成为他们老大的人呢?

不管申请人是开发人员、测试人员,抑或是经理,寻找到一位真正合适的人选从来都不简单,但往往又很重要。这是团队参与的项目。

只有完成本垒打或者击球成功,管理才值得嘉许。”

——卡西·史丹格(Casey
Stengel

一叶知秋

(一)
与客户吃饭。客户抱怨,“我司人员流失大,无法建设团队文化。”我说,“以你司推行的工具为例,其思路就是把团队定位于低级、傻瓜式的水平。那么,超出这个水平的人离去、不足这个水平的人加入,不正是延续并巩固了这种傻瓜式的团队文化么?”

(二)
工具或许无关好坏,但要警惕的是工具传递的创建者的价值观。推广工具遭遇困境,原因就在于推广者的价值观与接受者不合,双方价值观上面的认同没有到位。如果以外力强制推行,甚至上升为价值标准,孔夫子曰:始作俑者,其无后乎?

保姆型项目经理

一个优秀的项目经理要对手下员工的能力了如指掌。他分派任务、制定计划,在可用的技能和任务本身的要求之间寻求最佳的契合。这是显而易见的。还有一些项目经理们更进一步:他们提供一个工作环境——不仅是技术性的,而且是社会性的——让人们可以最大限度地使用自己的技能,并且提高自己的技能。这些项目经理确保自己的员工拥有完成任务所必需的工具。这些项目经理鼓励提问,并且乐意、与员工辩论;他们给每位团队成员设定最合适的挑战;他们在需要的时候提出批评;他们建设一个人人乐于工作的场所;而且他们采取必要的调整以保障各项事宜运作良好。简单地说,好的经理们培养他们的员工,就像保姆培养她们照看的孩子一样。

一个保姆,在传统的英式文化中,受雇于某个家庭照看对方的孩子。保姆——通常被训练成教师、护士和厨师——对孩子的体格、心灵、社交、创造性和智力发展都要负责。在每天的日常活动中,保姆要确保孩子远离伤害,保证孩子们得到了足够的新鲜空气与锻炼、食用有营养的食物,并且增进对世界的理解,学会更多在世界上生存的技巧。除了照看孩子,保姆还需要与孩子的父母就他们在孩子成长方面的顾虑进行沟通,鼓励孩子的特殊天赋。保姆创建出一个可以承担风险和学习的安全环境。

当经理们拥有这些与保姆类似的才能,他们就能通过鼓励和培养员工的天赋,从员工那里获得更多、更好的工作结果。

迄今为止,我所共事过的最好的经理是Peter
Ford
。这再明显不过了,比如他确保协调好我们每个人的要求,以做好个人的手头工作。举一个例子,我们有一个开放计划办公室——不是最好的思考环境——而且,他设法为团队弄到一些消音的屏幕,并预订了几间“静室”。所有的这些,以及他为我们做的其他事情,牵涉了我们所不知情的协商和政治。他鼓励我们阅读,在系统开发的时候讨论新的想法。他为我们团队购买书籍和杂志,并安排时间让我们聚在一起讨论。当我们觉得不开心或者不舒服的时候,他会注意到这一点,跟我们交谈,帮助我们。他保护我们不受组织其他人、事的干扰,但如果他对我们不满意,他会让我们知道。他的办公室门很少关闭。Peter就是我们的保姆。

——SQR

如果注意到如下一项或者多项情况,你能发现在你所在的组织已经有一些“保姆型”经理:不必预约就能见到你的头,或者不必在琐碎和生厌的管理工作上花费太多时间。周围是开放的氛围;人们畅所欲言,互相学习。这种经理认为培训或进修非常必要,而不是视为奢侈烧钱。他们还会抽出单独的时间(比如早晨咖啡闲谈或者周五下午阅读探讨),让大家在一起讨论新的想法。

在任何由人组成的团体里面,总会有流言蜚语、小道八卦,和一些磨洋工的情况。然而,在被经理细心呵护的办公室里面,这类浪费时间的事情会被最小化,因为经理确保团队成员对于实际进行中的事情都非常清楚。人们不需要去靠打探小道消息以得知组织内发生的事情。与之相反,他们觉得自己充分知情和受到信任,把精力都放在自己的本职工作上面。

一个类似于保姆的经理会把他自己看成是工作的催化剂。传统保姆的工作满意度来自于看到孩子能力的发展,“保姆”型经理的工作满意度则来自于看到每个团队成员在个人角色方面得到发展、生产率得得提高,并对自己工作更加满意。

这个模式的反模式有:经理把工作重心放在政治上面、放在流程上面,抑或放在逢迎更上层领导上面;绘制、调整PERT图和甘特图比与团队成员交谈更重要;还有一些经理承担了太多的实际开发工作,而不是去解决好团队的需求。

你们组织如何看待这样的经理角色?他们会因为“催化”了工作受到赞扬么?你们是雇佣“保姆”,还是“管理者”?

欢乐的鼓掌会议



高涨的士气永远象征着组织的健康。与之类似,低弱的士气则说明肯定有什么地方做错了。有一种管理理念就是奉这种关系如圭臬,试图从相反的方向来利用这种关系。逻辑是这样的:把士气鼓舞起来,其他美好的东西也就跟随而至。

啊哈,那如何鼓舞士气?尤其是如何在不增加时间、精力和花销——虽然它们是改善事物的必要投入——的情况下鼓舞士气?这是个难题,但别以为人们就不会去尝试。于是,才有了这样的谚语:“打气,打到士气提升为止。”

鼓舞士气的常见举措是仪式性的会议。会上老板笑容可掬,站在集合在一起的团队前面,
大开言路:“让我听听你们的心底话,”他大度地告诉大家。“任何事情都行,即使坏的消息和尖锐的问题。”注意这里的腔调和背后传达的信息:没有什么好隐瞒的,我们是一个欢乐的大家庭。(欢乐,该死的,欢乐。注意了。)

我知道有一家公司,这样欢乐的鼓掌仪式被称作全体会议。之所以称为全体会议,是因为所有人都获邀参加。但是一旦哪位勇敢的人果真举起手,向CEO提出尖锐的问题,最后的结果却根本不是他所预想的。CEO咕哝了几句,就迅速找了个台阶下。在当天的晚些时候,这个冒失的提问者就被他的直接上司叫去训了一顿,打消其尖锐问题受到欢迎的幻想。从此以后,在私底下大家都把这种会议都称为一言堂,因为没人会再次举手发言了。

——TDM

一旦你理解到老板并不是在征求你们的发言,而只是你们的同意的时候,你就能清楚地知道什么在上演:欢迎参加欢乐的鼓掌会议。