您可以捐助,支持我们的公益事业。

1元 10元 50元





认证码:  验证码,看不清楚?请点击刷新验证码 必填



  求知 文章 文库 Lib 视频 iPerson 课程 认证 咨询 工具 讲座 Modeler   Code  
会员   
 
   
 
 
     
   
 订阅
  捐助
让软件公司的管理多一点“灵魂”
 
作者 李智勇  火龙果软件 发布于:2014-07-10
  2330  次浏览      13
 

不少软件公司的成功是源自产品、人口红利,而不是因为管理,甚至有的公司的管理带来的是负值。这样的公司之所以成功,只是因为正面值太大。而另外一面,现实中很多的软件公司,其管理很可能已经陷入了困境。

什么是管理的灵魂?

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

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

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

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

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

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

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

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

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

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

  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的程度,就已经可以成为非常有益的系统。它最初也许受企业文化的影响,但长线来看则可以塑造良性的企业文化。

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

   
2330 次浏览       13
相关文章 相关文档 相关课程



给开发人员的时间管理建议
创业公司打造“A级团队”的七个方法
正视研发管理才是高水平竞争
资深经理谈团队建设和绩效管理
研发项目管理实战
研发及技术人员管理技能培训教程
RDM026_研发项目管理培训教材PPT
团队建设与管理
研发团队与工作管理
IPD原理与实践
研发资产和过程管理
从技术走向管理
最新课程计划
信息架构建模(基于UML+EA)3-21[北京]
软件架构设计师 3-21[北京]
图数据库与知识图谱 3-25[北京]
业务架构设计 4-11[北京]
SysML和EA系统设计与建模 4-22[北京]
DoDAF规范、模型与实例 5-23[北京]

正视研发管理才是高水平竞争
需求是如何变成产品原型的
产品经理能力模型解说—把控
产品经理的正确定位
谁是合格的产品经理?
产品管理与产品营销的区别
更多...   


统一过程及应用
敏捷过程实践
基于XP/RUP的迭代开发
软件开发过程指南
SCRUM过程实践
敏捷测试-简单而可行


某博彩企业 产品经理与产品管理
北京 研发团队与工作管理
广东金赋信息 敏捷开发过程与项目管理
某支付平台 软件配置管理与发布管理
富士 软件外包项目管理与进度管理
塞孚耐 基于Scrum的敏捷开发
更多...