码迷,mamicode.com
首页 > 其他好文 > 详细

让软件公司的管理多一点“灵魂”(转载)

时间:2014-07-11 20:56:25      阅读:169      评论:0      收藏:0      [点我收藏+]

标签:style   http   color   使用   strong   width   

其管理很可能已经陷入了困境。

bubuko.com,布布扣

什么是管理的灵魂?

如果彼得德鲁克说管理是种实践是对的,那管理的灵魂就必然是一种独立思考的精神,因为唯有独立思考才能完成打穿理论与现实,完成特殊到一般,一般再到特殊这样的轮回。

那如果管理缺了灵魂,那会怎样?

那就会因为失去一种自省的精神,而变得四处都是被分享的成功经验,但其实管理上问题不断。

当一个庞然大物比如:柯达轰然倒下时,人们往往会去反省它可能是管理出了问题。但当它还在时,人们往往会认为是管理支撑了它的存续,而并不能去识别其管理的失败很可能是正在导致肌体的腐坏。

不少公司的成功是源于产品、人口红利

管理就是这样的一种东西,每个人都可以说上几句,但你很难识别这是对的还是错的,很难识别它究竟对公司的成功是一种正向的助推力还是一种逆向的杀伤力。很多公司的成功更多的是由于窗口期,由于产品,由于人口红利等等,通常骨子里并不是因为管理,甚至说管理其实带来的是个负值,只是因为其它方面正值太大,或者成功所带来的傲慢而被抵消了。

如果管理失去了灵魂,那就会在问题丛生之际仍在感觉良好中过活,而错失深刻认识问题、思考问题本质及解决方法,并尝试解决问题的机会。下面我们来通过问题是什么,本质原因是什么,怎么解决这样的思考之旅来进一步阐述如果管理有了灵魂,更应该是什么样子。

很多软件公司因缺“灵魂”的管理而陷入困境

现实中很多的软件公司,其管理很可能是已经陷入了困境。

这种困境起源于这样的基本事实:

 

  1. 知识迅速膨胀和市场环境的迅速变化导致对工作的把握被倒置,现场的人好过他的上级。
  2. 组织结构必须是一种金字塔结构,这进一步要求上级必须评价下级绩效。 
  3. 软件的特质使与其相关的产出物无法被精确度量。
  4. 纯粹的市场结果相对客观也让人信服,但需要较长的反射弧,并且结果涵盖范围宽泛更适于度量高层绩效,而不适于度量个人绩效。

 

面对这样的基本现实,如果我们去独立思考,认真分析,就可以发现更多的东西:

第三点促使评价本质上必须依赖于判断,而无法依赖于代码行生产率,Bug率这样的数字化指标。第一和第二则使判断艰难并且结果难以被普遍信服。这就是困境。我们知道越可以清晰度量的地方,公司政治的影响力就越小,比如:比如销售员与销售额;而越是模糊的东西则人治氛围越重。判断力是只属于人的能力,但人则是相对主观的,所以任何判断结果中必然会融入主观因素。一旦组织变大,利害相关方变多,判断的过程就更容易受非理性因素的影响。

这种困境的关键危害在于他会使公正被虚化、个人化,最终评价者与被评价者在认知上的差异会导致每个人都觉得自己未受到公正待遇,进一步发展下去就是个人意愿与组织的目标严重背离。

它很像慢性毒药,公司越大存续时间越长,就越容易滋生派系和政治,而派系和政治的影响也就越容易影响到判断自身,危害也就越大。反倒是小的公司更容易规避其可能带来的负面效果。依赖于某个人或某几个人的品德以及眼光,小的公司里更容易维持普遍认可的公正。但是对一项工作比如管理,如果其结果主要依赖于个人或某种巧合,那个案也许可解决,却无助于改变这项工作自身已经陷入困境的事实。

 

  • 随着这种困境的加深,各种带着负面的现象就会逐次出现,比如:
  • 每个人都处在防御状态,不求有功先求无过,花很多时间去分析证明那个不应该我做。
  • 出事后互相推诿,努力证明这和我无关,但不认真考虑如何解决和防止问题,总结分析成为过场。
  • 抱怨专营多于努力。
  • ... ...

 

如果管理当事人真的独立思考,认真分析,就不会经常去分享成功经验,而会更多的考虑如何解决,这样就会来到问题的本质:

下面以整体是部分之和为前提建立一个公式来描述组织力量与个人的关系,这个公式出自《完美软件开发:方法与逻辑》一书:

假设一个人的工程素养为E,一个人的工作意愿为W,组织所能提供的基础力量为O,内耗系数为M,那么对于一个拥有n个人的组织,从纯量的视角看,其在单位时间内最终可能贡献值可以表示为:
[(E1*W1  + O) + (E2*W2 + O) + ... ... + (EnWn  +O)] * M

通过这样的分解,我们可以发现,工作意愿、组织平台所能提供的基础、内耗系数、个人能力都可以是影响组织效能的关键因素,但长线来看最为根本的则是工作意愿。在长时间轴上,如果工作意愿可以保持,那其它项目总是有变好的趋势,反之则其它因素则会普遍变坏。

而工作意愿的核心支撑首先是公正,是为:不患寡而患不均,其次才是收入整体水平,自我实现程度等。而上面所说困境恰恰对公正的基石有逐步腐蚀的效果。(参见组织行为学中的公平理论等,此处不展开。)

怎么做才能让管理不失去灵魂?

答案也许不是上面这个,但认识到这类本质问题后,就会努力思考解决办法,可先参照现有的方法论,在软件领域里,敏捷和CMMI等都算与管理关联比较密切的方法论,但很可能你会很震惊,发现他们都有用但其实不解决上述问题的关键部分。再进一步思考可能就会发现自己的方法,比如:

不管资源,现金流这些东西多么重要,管理首先是人的管理,知识的权重越高,人的管理也就越重要。而人本身首先体现为一种关系,在这种关系之上通过与他人的协作,人开始扮演各种角色,在职场中角色具体可以表现为程序员,架构师,CTO,设计师等等。

这反过来意味着与某人产生关联的所有人可以对此人进行客观公正的评价,因为正是在与周围人的协作交互中这个人才完成了自己的角色。这样一来绩效考核的终极目标就是把体现在关联中的评价发掘出来。

这似乎很有些抽象,但我们可以借助一些类比来让事情更加清晰。程序员这个群体应该都非常熟悉StackOverflow这个网站。当你长时间使用它后,你会发现这个网站的投票非常客观精准的表述了一个回答乃至一个问题的价值。而达成这一目标的关键手段又出奇的简单:针对具体成果物投票。

在StackOverflow上人与人之间关联的主要纽带是问题以及答案。当A发起了回答,所有看到这一回答的人与A产生关联,而投票结果则是所有关联人对A的此次工作的一种评价。

如果把类似的场景推广到工作,我们就可以发现除了受众变小外,工作中人与人的关系与StackOverflow上人与人之间的关系并没有本质的差别。在很多时候职场中人也要靠具体的成果进行协作,而某个人的某项工作成果也会同时影响A、B、C。

这反过来意味着只要能够普遍建立起来类似StackOverflow上投票机制,如果关联人也积极投票,那就有可能建立起来非常客观的评价体系。

这背后的哲学非常简单:当所有用到A的成果物的人都对其进行反馈了,那么其结果就是公正客观的。

也许会有人由此想到360度绩效考核。但两者其实是不同的,关键点在于,这里要强调的是对成果物进行持续的投票,最终通过对物的评价汇总成对人的评价。而非直接评价人,直接评价人总是会导致更多的主观。

这样的评价体系也可以移植到工作中

这类机制也许可以移植到工作中:一切成果物皆可以验证过的身份匿名投票(对短期任务可能需要限制利害相关者)。最终一个人获得认同的的个数基本上可以等价于他在指定成果物上的绩效。

为使这种系统可以运行,那么需要进一步明确公司与个人的责任边界。这事实上等价于让参与到这系统中的人成为运动员,而公司则扮演规则制定者与裁判员的角色。

 

  • 公司的职责是制定规则与维护规则,比如:
  • 每个人指定时间段内必须投出指定票数。
  • 非验证者不能投票。当然验证不一定实名。
  • 总计一定人票数之上为可取信结果,比如10人票。
  • 确保只有工作上产生关联者可投票。
  • ... ...

 

同时来保证投票中没有违反基本规则:

 

  • 抽查是否有人无关联的基础上投票。
  • 是否有人恶意拉票等。
  • ... ...

 

个人的职责就很简单,你只要公心公论的投票即可。

结束语

说来可怕,这种迅速反馈的体制下,其最终的客观程度只依赖于人们公心公论的程度,这并不是这种方法的缺陷,而是人的缺陷,但确实影响这一方法的结果。这导致这样的方法也许很难推广到全社会,而有一个较窄的适用边界,但应该可以解决软件公司中的种种问题。因为软件公司中各种产物天生是数字化的,容易公示和追踪。

这样的系统不需要达到无比精确的程度,只要达到StackOverflow或者Github的程度,就已经可以成为非常有益的系统。它最初也许受企业文化的影响,但长线来看则可以塑造良性的企业文化。

如果思考进行到这一步,已经需要做些具体的尝试了,并从实践中再进一步汲取养分完善自己的思想,它不一定对,也许需要扬弃,并再起炉灶。但经历过这样的步骤也许才算的上管理没有失去灵魂,比“单纯的我做了什么、它是成功经验,我把它分享给大家”这样的故事有意思多了。

bubuko.com,布布扣作者介绍:李智勇,V众投发起人,《完美软件开发:方法与逻辑》作者。目前正在免费发布《程序员生存定律》,微博:李智勇SZ,微信:vfacebook。


让软件公司的管理多一点“灵魂”(转载),布布扣,bubuko.com

让软件公司的管理多一点“灵魂”(转载)

标签:style   http   color   使用   strong   width   

原文地址:http://www.cnblogs.com/hxb316/p/3833328.html

(0)
(0)
   
举报
评论 一句话评论(0
登录后才能评论!
© 2014 mamicode.com 版权所有  联系我们:gaon5@hotmail.com
迷上了代码!