Friday, November 23, 2012

Google呼吁开放网络


  联合国旗下的国际电信联盟(ITU)将于12月在迪拜举办会议,商讨对于全球通信协议的修改。俄罗斯提议修改规则,让各国政府可以直接监视人民的上网行为,目前已有巴西、印度等国支持俄罗斯的提案。做为国际互联网服务的巨头,Google决定做出反击。
  Google建立了一个名为Take Action的签名网站,呼吁全世界公民一同捍卫互联网的言论自由。
  Google在网站上声称“国际电信联盟 (ITU) 准备将世界各地的监管机构聚到一起,重新协商一份有数十年历史的通信协议。
  某些提案一旦获得通过,政府将获得对合法言论进行审核的权利,甚至政府还将有权切断互联网接入。还有其他一些提案要求诸如 YouTube、Facebook 和 Skype 等服务必须支付新的服务费才能跨境提供服务。这会限制信息访问(尤其是在新兴市场中)。
  只有政府在 ITU 才有发言权,而打造和使用网络的工程师、公司和普通大众没有投票权。ITU 的协议会议和提案均属机密信息。”
Google建立网站呼吁网络自由开放
  Google最后呼吁,“全世界的用户、专家以及公司或组织都发出了自己的心声,反对政府通过 ITU 管制互联网。自由开放的世界依赖于自由开放的互联网。政府不能单方面决定互联网的未来。全球使用互联网的几十亿人以及构建和维护互联网的专家也应该有发言权。”
  签名网站地址请点击这里,由于签名使用的是appspot服务,因此中国用户需要代理才能成功签名。宣传视频如下。

Thursday, October 11, 2012

转载:也谈大公司病4——大公司中的反模式


多数大公司大了后都不可避免会遇到大公司病,机构臃肿,行动缓慢,协调困难,思维僵化。为此,大公司采取了各种各样的做法,建设企业文化,调整组织机构,更换领导人,加强流程规范,建立特区,建立快捷通道,引入敏捷方法。这些措施往往都能取得一定时间的效果,却很难与整个公司抗衡,随着时间流逝,大公司病还在蔓延。
为什么会这样?是解决措施有问题?还是管理能力不足?还是没有找到真正的问题?
下面对大公司病的一些另类思考,试图向真正问题迈进一步,“大公司中的反模式”是其中第四篇。

正文

整个系列应该叫《理解大公司病》,不理解大公司病,如何能够治病。这是第四篇,在前面三篇“正确是最大的错误”、“减少错误不等于增加成功”、“治大国不是烹小鲜”中,从一些大家平时不甚关注的角度向大家讲述了大公司病的部分理解。本文将对上三篇进行一些总结。

正确、安全、简单 vs. 成功、创新、复杂
正确、安全、简单是存在于每个人心中的渴望。公司的本质还是由人组成的,人和人与人之间的关系构成了公司的基石,所以源于个人的这些渴望在不自觉地影响着人们的行为,最终体现到公司行为中。在大公司,尤其如此。即使在大公司中,你依然会听到人们对缺乏安全感,不知道什么是正确,太复杂不够简单等种种抱怨,这正是力量的表现。
成功、创新、复杂是真实世界对企业的要求。公司是一个盈利性的组织,成功是公司追求的,因为不成功则成仁。创新是公司持续成功的保障,公司必须持续满足客户的需求。而复杂是公司面临的现实情况,在互联网时代,公司服务的人群快速扩大,市场竞争越发激烈,公司生存的环境越来越复杂。公司,尤其是大公司需要在这复杂的环境中不断创新以取得持续的成功。
当正确、安全、简单在大公司碰到了成功、创新与复杂,会发生些什么?正确、安全、简单代表着公司向内的力量,它们引导着公司看自己,关注公司内部。成功、创新和复杂是外部环境要求,是外在的驱动力。如果两者不能匹配上,会出现各种怪现象。当然,100%匹配几乎不可能。
下面,就以大公司中几个常见话题作为示例进行简单讨论。分工和绩效两个话题因篇幅限制,讨论不深刻,未来可能单独成篇。

反模式1:分工不应该是扯皮的基点,逃避责任的港湾
大公司强调的分工会逐渐演变成“圈地运动”。分工在传统意义上是通过分工加强专业能力,降低人员培养成本,提升整体工作效率,最终有效提升公司的成功、创新,帮助公司更有效的应对复杂环境。而在大公司,分工的主要目的却是为了划分职责地盘,不能有任何模糊,因为只有这样,工作中谁该做什么才是简单清晰的,谁该承担什么责任是清晰的,人们才知道什么是正确。主导分工的管理者觉得正确、安全、简单,接受分工的员工也这么感觉。然而,分工与成功、创新、复杂的关系越来越弱。
“圈地运动”式的分工往往成为扯皮的基点。类似的场景经常出现,两个农夫各自站在自己的田里骂对方的田没种好,说对方没有证据证明自己的田没种好。一个例子可以参看王建硕博客《写代码这件事》http://www.huxiu.com/article/3267/1.html?odby=agree
“圈地运动”式的分工往往成为逃避责任的港湾。还有一种情况,在所有分工都明确的情况下,产品依然失败了,是谁的责任?要不是都没有责任,因为每个人都做好了自己分工内的工作,找不出做错的证据,最终公司承担;要不是大家承担责任,每个人都有错,才导致了错误的发生,最终法不责众。

反模式2:绩效KPI应该是跑道而不是终点
绩效评估是大多数大公司都有的制度,而这项制度在大多数大公司都实施的不尽如人意。其本意是通过绩效评估,统一组织发展方向,传递组织目标,保持组织活力,帮助组织在复杂环境中成功与创新。然而在实际过程中,因为成本原因、因为沟通障碍、因为工作复杂度增加,绩效评估的难度不断上升。因为各种原因,管理者会采用简单的方式来进行绩效评估。从而导致如下结果:
绩效评估最终促成KPI导向。绩效评估极大的破坏了员工的安全感,尤其是在有末位淘汰的情况下。绩效评估清晰向员工指明什么是正确的。只做KPI上规定的事是最简单的。从而为了正确、安全、简单,员工变成了KPI导向,唯KPI是从,不在KPI上的一概不做,在KPI上的积极做好。
绩效评估最终促成老板导向。绩效评估可能成为老板显示威严的工具。它用简单的方式帮助老板巩固了安全感,清晰阐释了老板需要的正确。员工为了自身的正确、安全、简单,唯老板之命是从。
KPI导向、老板导向极大制约了公司的成功、创新,阻碍公司灵活应对复杂环境。对于员工来说,正确、安全、简单的创新是在是太难了,一个人在对抗一个体系。在有些公司,情况甚至发展到阻碍公司发展的程度。

其他反模式
流程制度能防止错误,也能阻碍成功。流程制度是好的,仅在他们能够帮助公司更加成功这一前提下。因为分工过细,每个人都站在自己的田里看问题,为了保证自身的正确、安全和简单那,大公司中的流程制度如果不经刻意控制的话会源源不断的增加。然而,这与公司的成功、创新、应对复杂很可能存在一定矛盾,降低了整体运行效率,甚至会出现内部分工中的矛盾冲突。
Smart目标让我们捡了芝麻丢了西瓜。管理学课程告诉我们,目标要Smart,但对于知识密集型产业例如软件研发而言,Smart目标不是个好主意。符合Smart目标能让管理者感到正确、安全和简单,但员工则会用另一种方式让Smart目标不能达到效果,例如单元测试覆盖率。单元测试是软件研发中的流行实践,80%的单元测试覆盖率显然是Smart目标,制订此目标的目的是提升研发团队的软件研发能力,保证软件质量。然而,提升单元测试覆盖率却不去提升软件研发能力是更简单的选择,员工可以用自动生成单元测试方法的方式,他们总能达成管理者规定的Smart目标,却让管理者的期望变为流水。

尾声

国庆大假几天,终于写完了近期关注的“理解大公司病”话题。后续的话题还很多,如复杂系统、敏捷、管理实践、软件研发等等。如同乔布斯所说,大公司病、复杂系统、管理实践、敏捷、软件研发这些都是点,我们需要不断学习回顾以让这些点最终都汇聚成线。希望在不久的将来,能够把串起的线呈现给大家。
配合正确、安全、简单vs.成功、创新、复杂,可以设计出一系列的小工具来检查公司对内力量与对外力量间的协调程度,还可以进行针对性的一些改进。读完了,你有什么收获呢?

参考

再次推荐《BBC系列:神秘的混沌理论》http://v.youku.com/vshow/idXMTcyNjE2MzMy.html,理解复杂系统,理解简单与复杂的关系,非常重要。
我有另一系列文章讲述了分工在软件研发中不再有效,《债思维——软件研发新视角》http://www.ituring.com.cn/article/1836

转载:也谈大公司病3——治大国不是烹小鲜


多数大公司大了后都不可避免会遇到大公司病,机构臃肿,行动缓慢,协调困难,思维僵化。为此,大公司采取了各种各样的做法,建设企业文化,调整组织机构,更换领导人,加强流程规范,建立特区,建立快捷通道,引入敏捷方法。这些措施往往都能取得一定时间的效果,却很难与整个公司抗衡,随着时间流逝,大公司病还在蔓延。
为什么会这样?是解决措施有问题?还是管理能力不足?还是没有找到真正的问题?
下面对大公司病的一些另类思考,试图向真正问题迈进一步,“治大国不是烹小鲜”是其中第三篇。

正文

“治大国如烹小鲜”是《老子》中的一句话,后世有多种解读。在网上搜索一下,你会感叹中文的博大精深。在此处,“治大国不是烹小鲜”取其大小、简单复杂用于对比,意思是治理大公司是复杂的,不像小公司那样简单。在大公司中,简单和复杂有什么关系?

大公司喜欢简单的解决方案
当产品有质量问题的时候,怎么办?创业公司的解决方案可能是全民质量反思,国外的方式可能是请顾问,而国内的大公司会如何应对?答案很简单,大公司大多会选择一个很简单的解决方案:增加质量经理岗位。这一选择有很多重要的作用: 1. 向大家宣布,其实我们很重视质量; 2. 告诉大家,不是我们不努力,只是在质量上不够专业; 3. 告诉领导,我们已经有了持续的解决方案,有专门的岗位来解决质量问题,请放心。小小的一个选择,既解决了问题,满足了方方面面的愿望;又摆脱了责任(不犯错),让自己从此不再为质量问题头疼,多么简单漂亮的解决方案。
假如你就是这位新上任的质量经理,你会怎么做?也许你想成为质量教练,提升团队的质量意识;也许你想推动质量实践,提升团队的质量能力。但别忘了,你的岗位之所以存在,是为了质量问题负责,不是为质量意识或能力负责。所以,对你来说,不犯错的简单的解决方案应该是,设定质量检查点并进行检查,分析质量问题并给出质量报告。
有了质量经理,还有质量问题怎么办?我们可以搞质量培训,可以选质量标兵,可以加强质量过程管理,让大家看到我们在质量上的努力。
如果还有质量问题怎么办?我们已经做了所有我们能做的,应用了所有简单的解决方案。看来不是我们不努力,只怪敌人太强大啊。
前一段时间,微博上有一个有意思的问题:What’s the value of quality manager? http://weibo.com/1408827293/yoBRIuLz8里面的讨论有点意思。 与此类似,于是我们有了项目经理,有了架构师,有了需求分析师,……。到最后,公司一个开发人员3天就能完成的工作,就由专业项目经理1名,架构师1名,需求分析师1名,开发人员1名,测试人员1名,前端开发1名的专业团队完成,为这个团队服务的有5名经理。
流程制度也是一个典型。因为流程制度是所谓可重复的、可靠的,这满足了公司管理者的愿望,同时,随着分工越发复杂,人们需要更简单的解决方案,所以流程制度是简单同时又面面俱到方案的一个代表。公司的流程每天都在增加,可能原因是因为我们又发明了一个新岗位,这个新岗位需要新的流程;也可能是我们出现了某个错误,为避免错误再度发生,我们又发明了新流程;也可能是我们想进行管理改进,为此发明了新流程。
同样简单的东西放到一起变成了难以想象的复杂
软件是由一行行代码组成的,但是并不表示每一行代码都写好了,这就是个好软件。单行代码考虑更多的是语法,而软件在代码之上衍生出了架构特性,需要设计。流程制度由一系列流程制度组成,但不表示详尽的、全面的流程制度就是好的流程制度,单个流程制度考虑的是必要性,而放到一起的流程制度有了效率、适用范围等新特性需要考虑。
从上面的质量问题解决到新的流程制度可以看出,对于单个问题,寻找一个简单而又面面俱到的解决方案其实很容易,然而简单绝对不是1+1=2。当这些简单的事务放到一起,会衍生出很多需要考虑的新特性。然而,我们对此的解决办法却是? 第一种视而不见。目前一切良好,这让我想起了源自微博的一个笑话“目前一切完好”http://weibo.com/1812458977/yDP33cBFN。 某人从100层高的楼上掉下,路过第99层的时候,楼里的人说“目前一切完好”。第98直到第2层的人也都发出同样声音,结果是这个人在每一层的人都知道结果的情况下,在一次次“目前一切完好”的呼声中————————死了。笑话里没错,从第99层到第2层,的确一切完好。
第二种分而治之。“请告诉我哪个流程是不合理的?哪个分工是有问题的?哪个会议是不必要的?哪个报告是不需要的?我们可以改变它、取消它。”这是经常得到的答案。嗯,经过梳理,我们废弃了某些流程,对分工职责也进行了清理。但是,绝大部分流程、分工都依然保留不变,因为它们可以证明自己是正确的、必要的。分而治之是很好的策略,但它必须要建立在对问题的完整理解之上啊,这种分而治之,受教了。
第三种简单应对。“公司近期发现了会议太多,工作效率明显下降的情况,请各部门注意提升工作效率。”领导如是说。于是,无会日、站立会议等简单有效的工作方式被发明出来,并进行推广。
然而,关于这些简单和复杂,却很少有针对性的学习和辅导。
当公司有很多项目的时候,应该如何管理多项目带来的新特性?新特性管理与以前的管理如何有机结合?投资组合管理和项目群管理对很多公司而言还是新名词。 当公司搭建了一个技术平台,应该如果管理技术平台由多个系统组成带来的新特性?新特性管理与以前的管理如何有机结合?还是分成一个个系统来管理。
人们因为胜任当前的岗位被提拔,却很少有针对下一岗位的针对性辅导,他如何面对新的简单与复杂?成为软件工程师,大公司都提供了很多培训,而成为一个管理者,公司提供了哪些培训?彼得定律:在公司中人总是倾向于被提拔到不胜任的位置。
KPI设置是否是对上一级目标的简单分解?上级的KPI是否下级KPI的简单堆砌?KPI如何分解现在依然是个摆在各公司案头的难题。

尾声

“治大国不是烹小鲜”。大公司是简单的,也是复杂的,仅仅是大就带来了很多额外的问题。深入理解复杂性,将有助于理解大公司病。

参考

要想理解简单与复杂的关系,推荐《BBC系列:神秘的混沌理论》http://v.youku.com/vshow/idXMTcyNjE2MzMy.html
搜索“治大国如烹小鲜”,从结果中你能体会到中国文化的博大精深。

转载:也谈大公司病2——减少错误不等于增加成功


多数大公司大了后都不可避免会遇到大公司病,机构臃肿,行动缓慢,协调困难,思维僵化。为此,大公司采取了各种各样的做法,建设企业文化,调整组织机构,更换领导人,加强流程规范,建立特区,建立快捷通道,引入敏捷方法。这些措施往往都能取得一定时间的效果,却很难与整个公司抗衡,随着时间流逝,大公司病还在蔓延。
为什么会这样?是解决措施有问题?还是管理能力不足?还是没有找到真正的问题?
下面对大公司病的一些另类思考,试图向真正问题迈进一步,“减少错误不等于增加成功”是其中第二篇。

正文

稳重是大公司的特点,安全的成功是大公司的追求,不断减少错误是大公司的一条行事准则。你可以做不成事,但是千万别犯错。大公司这种减少错误的倾向从何而来?是大公司病的一种吗?会影响大公司的成功吗?
对于产品而言,减少错误不等于增加成功。
在产品选型上,大公司力求减少错误。大公司有充足的财力人力,会投入大量的成本进行产品论证和市场调研。与此同时,还得与公司的已有产品,尤其是现金牛产品划清界限。为保证进入足够大的市场,为保证不与公司自身产品自相残杀,为证明本产品的重要性超过其他产品,n论PPT的论证和产品PK是不可少的。直到产品方向得到市场论证或高层一致,方才放行,既花费了巨量的成本,又消耗了相当的时间。
进入产品研发阶段,研发团队力求减少错误,此处以软件研发为例。因为不敢犯错,研发团队会力争力求一次完成,瀑布模型成为必然选择,因为瀑布模型是错误最少的模型。然而,研发团队对产品认识不够深刻,一次完成的风险太大,一定会犯错,怎么办?研发团队会争取把错误变成别人的错误,为此不惜吹毛求疵。曾多次参加这样的需求评审会,开发、测试人员围绕着产品的设计细节不断追问需求人员,要求需求人员解答所有的需求细节,需求人员也从来没有做过这个产品,双方对着需求文档纸上谈兵式的纠缠细节。为了一次考虑清楚与相关系统的关系,设计讨论、评审也不能缺少。需求评审、设计评审等各种评审、讨论让软件研发变成会海。到了编码阶段,要求不高,没错就行,同时时间也不足,匆匆完成。而测试时间则会不断增长,因为产品宁可不上线,也不能有很多错误,哪怕是小错误也不行。
每个产品研发的参与者都致力于减少错误,每个人都很努力,都没错,这能帮助产品成功吗?
  1. 公司在选型和研发上都有巨大投入,一旦没有大产出,公司怎么处理?
  2. 选型和研发的效率低下,产品可能错失时机?
  3. 前期产品论证时和后期瀑布研发时对产品进行了从大方向到细节的纸上谈兵,这种纸上谈兵完全有可能在不断强化错误的方向,谁敢承认这些错误,谁来为这些大错买单?
  4. 因为时间被前期的其他事务占据,导致时间不足,从而对设计和代码质量降低了要求,从而导致产品投向市场后难以快速演进,响应市场变化缓慢,怎么办?
  5. 在整个过程中,缺少来自真正用户的反馈,团队也缺乏学习,怎么可能推出市场真正满意的产品?
对于管理而言,减少错误也不等于增加成功。
对于管理而言,有一点我一直没搞清楚,管理是为了成功还是为了安全?很多人可能都认为管理是为了可重复的成功,那么是可重复重要呢还是成功重要?对大公司,安全、可重复、少犯错可能更重要一些,毕竟“稳定压倒一切”嘛。
流程制度是减少错误的典范,因为不遵守流程是有错的,而流程多了无所谓。流程制度是典型减少错误的工具,与成功关系不大。在某公司,基本上没有人知道项目中有多少个流程。这不仅是因为流程繁多,还因为不断有新流程被发明出来,旧流程版本被更新。为什么人们会热衷于发明新流程?表面原因很多,例如提升服务质量,工作规范化等等。但除了部分工作必须的流程外,其他流程被发明的根本原因在于
  1. 责任界定,出了问题时流程可以证明问题是别人的问题,我没错;
  2. 防范错误的重复出现,因为曾经出现过重大风险,所有我们要增加审核;
  3. 防范坏人,留下记录。嗯,最后一句防1%的坏人,把99%的好人也防住啦。
会议占据了大量的时间,因为不开会是有错的,而“必要”的会议是没错的。为了减少错误,人们利用会议相互试探、扯皮,把决策权向上推,找人共同担责,等等理由不一而足。一个有一个的会议就此被发明出来,每一个会议都非常“必要”,因为一定有足够的理由证明其必要性。劣币驱除良币,会议的盛行导致会议综合症,部分必要的会议受到抵触,并不能取得预期的效果。
报告在大公司是如此盛行,因为不做报告是有错的,而多做报告是没错的。因此按照时间维度的日报、周报、月报,按照工作类型的项目、部门、业务、财务,各种报告层出不穷。虽然并非所有的报告都是坏的,但放到一起,报告繁多显然是大公司一绝。同时有一些糟糕的例子,例如软件研发中的日报。至今为止,大多数软件公司开发人员依然要填日报,原因是什么呢?在某会议上有位演讲者是这么讲的。“虽然大家都知道日报与成功没啥关系,但是这是当前唯一有效的选择。”也就是说,这是不犯错的选择。
流程、会议、报告是管理中减少错误的典型案例。很难说某个流程、某个会议、某个报告是不必要的,没有意义的,但是为了减少错误,肆意的增加流程、会议、报告后,这就成为了公司不能承受之重,不仅降低公司运行的效率,甚至影响正常工作的开展。

对于个人而言,减少错误同样不等于增加成功。
有个小故事讲得很好。一天,需求分析师向公司技术牛人提出了一个需求,牛人看过后有点不高兴的问道:“你觉得这个需求有价值吗?”需求分析师诚恳的回答:“没有价值,但是我要写周报啊。”牛人听后,沉思了一会说:“好,我帮你做,我也要写周报啊。”需求分析师和牛人都不想犯错,因为在大公司有个最严重的错误,工作量不饱和。一旦工作量不饱和,所有人都能看见,而实际工作干了什么,却不一定有人清楚。
有一种方式的减少错误,就是老板导向。因为不能犯错,揣测上意、溜须拍马在大公司的某些地方开始盛行,抢功、挣表现、求亮点成为必备功课。听说在某公司,几个部门管理者相互安插内奸,目的只是为了比其他人领先几分钟发项目战报。这对部门管理者非常重要,是否实干并不重要,在老板面前增加成功、减少错误显然是更加关键。
还有一种方式的减少错误,KPI导向。每到KPI评定的时候,都会拿出KPI,这里那里有错。曾经出现一种情况,某部门的测试团队有一个月停止工作,全员编写无人使用的自动化测试,因为团队每个人的KPI中都有自动化测试脚本覆盖率要求。
大公司的螺丝钉精神也与减少错误相关,因为甘当螺丝钉最安全。大公司有很多优秀人才,随着时间变迁,他们会成为优秀的螺丝钉,在不犯错的条件下继续寻求成功。

尾声

综上所述,大公司中有很多行为是以错误-惩罚的形式驱动的(套用句流行语,看起来大公司的负能量好足啊。),减少错误作为一种本能被不断放大,而且大多数人难以认识到它的危害。当所有减少错误的倾向走到一起,会带来整体工作效率的急剧降低,会议冗长、报告繁多、流程复杂、分工增加等大公司病征仅仅是其表象而已。
最后用一个科学实验“大猩猩再也不敢犯错了”来结束。把5只大猩猩关进笼子里,在笼子的左边放上香蕉。哪一只大猩猩去拿香蕉,就暴打5只大猩猩。后来不用你去暴打,哪一只大猩猩去拿香蕉,另外4只就会暴打它。这时,往笼子里再放一只大猩猩,新来的大猩猩想去拿香蕉,另外几只大猩猩会用暴打让它学会别犯错。再往后,以此类推,从此大猩猩们养成了不吃香蕉的文化。据说,后来不知情的大猩猩打其他大猩猩打得最狠。

参考

IBM:删繁就简,衰落巨人重振雄风 http://money.163.com/10/0426/08/656DQP5S00253G87.html

转载:也谈大公司病1——正确是最大的错误

多数大公司大了后都不可避免会遇到大公司病,机构臃肿,行动缓慢,协调困难,思维僵化。为此,大公司采取了各种各样的做法,建设企业文化,调整组织机构,更换领导人,加强流程规范,建立特区,建立快捷通道,引入敏捷方法。这些措施往往都能取得一定时间的效果,却很难与整个公司抗衡,随着时间流逝,大公司病还在蔓延。 为什么会这样?是解决措施有问题?还是管理能力不足?还是没有找到真正的问题? 下面对大公司病的一些另类思考,试图向真正问题迈进一步,“正确是最大的错误”是其中第一篇。

正文

“做正确的事比正确的做事更重要。”另一种说法是“做对的事情远比把事情做对更重要。”这句话翻译自一句英文:“It’s more important to do the right things than to do things right.”这句话是在是太正确了,不少人常把它挂在嘴边。然而,在大公司中,这句话却带来了太多的问题呢。

首先,大公司中存在太多的正确。
对于小公司而言,能够生存、能够过得更好就是正确。而对大公司而言,正确却并非那么显而易见。常见的有:
  1. 文化与价值观正确:大公司大多有自己推崇的文化和价值观,文化建设往往也是公司非常重视的一点;
  2. 流程制度规范正确:公司大了,当然要更加规范化,流程制度规范纷纷出台;3. 分工正确:机构岗位划分更细了,人人都要按照分工来做事;
  3. 绩效正确:要用绩效给团队指引方向,绩效管理必不可少;
  4. Smart目标正确:目标不仅要有,还必须Smart,即使Smart到错误的方向,不Smart也不显专业;
  5. 老板正确:目标层层分解,绩效归老板管理,所以老板才是最正确的。当然,还有战略、产品、业务价值等等,各有各的正确。
在大公司中,正确在逐渐变异。当公司倡导的n种正确出现冲突,哪一种更正确?正确们在PK,通常PK会剩下三大正确,他们分别是
  1. 老板正确:老板永远是正确的,如有疑问请参照前一句,从而事事请教,溜须拍马,专注执行;
  2. 自己正确:为了证明自己是正确的,价值观、老板、流程、分工等等都可以成为工具,最大化利用规则,相互攻击职责不在话下;
  3. 集体正确:集体的决定一定是正确的,如果集体不正确我也是正确的,文山会海自此诞生。

其次,追求正确本身就是错误。
做正确的事比正确的做事更重要,本身是错误的简化。做了不正确的事,那就是错误的,这是简单的二分法推定。这种适用于书本教学的童话却往往出现在现实生活中。
评审中某位同学很积极的提出一些细枝末节的问题,并且非常执着的要求必须得到解决,经常导致会议延时,有时将项目组导向错误方向。“项目组,这位同学提这些问题有帮助吗?”“没太大帮助。”“他这么做为什么大家都不说呢?”“这符合公司规定啊,而且不这么做,怎么证明他的价值观很好呢?怎么证明他的工作做到位了呢?”“但是工作效率的损失呢?”“这个规则里面没有,我们的规则是不能遗漏任何问题。”
公司近期有一个创新型的大项目。某人提出建议:“能不能减少低效的需求评审,改用其他办法?”得到的回答是:“嗯,你的建议很好。但是这个项目很重要,我们必须遵循公司所有的规定,否则就算做好了,我们怎么能证明我们做好了呢?”
公司基本每天都有新流程被发明出来,新的流程制度规范越来越多,逐渐成为了巨大的束缚。某项目要紧急发布。“你走的流程不对。”“为什么?”“因为你没有遵循最新的流程。”“流程在哪里?我怎么不知道。”“这是地址,先去学习一下。”“已经按流程提交了。”紧急发布后,“为什么我遵守了流程还是有问题?”“哦,我重新整了一下,已经好了。”“无语!!!!!!”
开发人员给某产品提出建议。得到的第一反馈是“你的建议很好”。然后隔天某主管过来暗示,产品是PD的工作,千万别越界。
最后,正确延误了学习创新。
正确延误了学习,长期看带来能力降低。正确的事情不需要学习思考,只需要做,这就是执行力。曾听到一句话,“这事领导都批准了,你还质疑什么业务价值。”逐渐演变成领导思考,下属执行;领导决定什么是正确的事,却发现下属执行常能力不足。别说犯错,有时连思考的机会都不给,让听得到炮火的人决策,就这样变成了一句空话。听得到炮火的人没锻炼到决策能力,决策的人当然也不放心。当下属成为领导,当干活的人突然变成需要做决定的人,他们如何具备做决定所需的能力?长期以往,公司的中层管理能力自然呈下降趋势。
正确延误了创新,阻碍了变革。在大公司中大量存在两种人,一种是躲在各种正确后面,得过且过;另一种是利用各种正确,打击他人,凸显自己。大量失败的尝试是创新的基础,而很多尝试都会打破某些限制,带来变革。结果第一种人不会跟随,因为不正确就错了。更可怕的是第二种人,让尝试的努力受到各种打击。当然,很多人开始都不这样,但是在公司的环境中他们逐步变成第一第二种人,只有正确才能生存。

尾声

“正确”是否真是一个问题?公司有清晰的标准判断吗?谁在维护、破坏正确?你和你身边的同事如何看待正确?你能举出多少与正确相关的案例? 你认为什么是真正的正确?怎么让其他人知晓并执行?你有什么解决方案没有呢?

参考