转自:http://bigtall.cnblogs.com/archive/2005/10/20/258362.html
深圳的空气是越来越差了,看来要买一个空气净化器了,至少能保证一天有12小时我能呼吸到新鲜空气。如果真的经济发展要付出这样的代价,我宁可发展的慢一些。原来媒体口口声声说要“吸取发达国家发展过程中的经验教训”,可是现在我发现,如果是个人的话也许有可能,但是要让全民都有“吸取人家教训”的共识,还是太难了。国外有一个什么定理,大意就是说“无论如何努力,所有事情都是朝每个人认为的最坏情况方向发展”。
社会是如此,作为一个小社会的企业也是如此。
昨天跟同事谈论了一下软件企业的组织架构问题。我的一贯观点就是企业发展要注重“成本”,一般来说都会表现在“效率”上,如果我们不犯方向性错误的话,“效率”越高,“成本”就越低。但是要达到最高“效率”,就要让所有人对所做的每一件事情都有共识。如何来达成共识?就涉及到了企业组织架构问题了。我认为企业组织架构的根本性目的不在于管理,而在于“沟通”。
亚马逊创始人贝佐斯的名言:“让沟通见鬼去吧!”。他是反对沟通吗?不是的。亚马逊还强调小团队,叫“两个比萨队伍”,就是一个团队吃两个比萨就够了,所以要限制在5、6个人。可见贝佐斯不仅不反对沟通,他及其重视团队内部的沟通。为什么呢?我们先来做一个数学题,把2到10的每个数的2的组合值列举一下:1,3,6,10,15,21,28,36,45。什么意思?也就是说一个项目组的人,每两个人互相谈一次话,分别需要这么多次的谈话,这个数字同时也表示要达成集体共识的难度大小。从这一些数值中我们就会很容易看到为什么我们需要 “两个比萨队伍”了,因为从集体力量和沟通量来评估,这个规模最有利。那为什么贝佐斯却说了这句名言呢?很明显,他是不赞成无意义的团队间沟通。一个团队一般只和有限的团队有合作关系,一个公司大了,就会有很多团队,并没有必要让每个团队之间都去沟通,而且从企业成本的角度来看,我们还要限制无关团队之间的沟通。
一旦建立了组织架构之后,企业内部团队间的沟通就会存在一些天然的障碍,这些障碍不仅是因为团队的存在,更大的障碍是团队文化之间的差别所造成的,比如开发团队和销售团队之间。在目前的市场环境下,小公司也许可以单靠个人关系来开拓市场、解决问题,但是公司越大,就越要靠团队的力量。华为的团队文化就不错,也很有成效。但是我们要清楚,不同团队内部也存在着不同的矛盾,会影响到团队的凝聚力。比如,市场/销售团队中,因为明显的经济利益的关系,相互之间就会存在“抢单”的现象;开发团队中,就会存在有“技术封锁”的现象等等。这些团队中不和谐的因素,说不定就是失败的导火索。
如何来有效消除这些内部的裂缝,加强团队的凝聚力呢?我们就要配合以公司的激励机制。很多公司强调“团队”但是却从来不强调“团队激励”,事实上,如果没有团队激励,又怎么能有一个团结的团队呢?目前我们的团队激励方法还很原始,基本就是“奖金”、“吃饭”等等,难道真的其他非物质类型的激励就不可行了?不是的!几年前专门看了“军事奖励学”,前几天逛书店的时候竟然看到了一本“向解放军学习”的书---它说“中国从来没有一个效率、凝聚力、战斗力上可以与解放军媲美的企业”,所以要向解放军学习。参加去年的M$培训的时候,讲师举了一个例子,说M$曾经开发了一个IE版的office套件,但是因为没有市场,结果上千人的开发队伍从项目领导开始全部解散,所有人在M$内部找3个月工作,如果没有项目组要,就解雇。这个才是真正的“团队管理”,所谓团队,就是“一荣俱荣,一损俱损,概不例外”,不在一条船上的一群人,不算团队!这一点,一般只讲团队的书里边是看不到的!
理论上,企业的组织架构形式基本可以分为职能式,矩阵式和事业部式。现在的软件企业,一般采用后两种组织形式。但是要注意的是,矩阵式适合小公司,事业部式适合大公司。我这里所说的大公司,是类似于联想、华为这样级别的公司,公司总人数要在500人以上。换句话说,基本上我们目前看到的所谓“大公司”都不适合用事业部式的组织架构形式。
事实上却相反!我目前见到的哪怕30个人的公司都想建立事业部。他们这样做当然是有理由的,因为事业部就相当于一个子公司,独立核算(老板看上的也只是独立核算),自主经营(号称是如此)。在目前几乎所有公司不能精确计算自身成本的情况下,公司可以很轻易地划出事业部成本的上限。但是在中国目前的情况下,事业部制是脆弱的。一旦事业部亏损的情况下,老板忍受不住的时候,要么换将,要么整个事业部解散。一旦事业部小盈利的情况下,比如一年纯利10万,老板能舍得拿出起初答应的10%给事业部自主分配吗?因为钱少,很多老板当然会不在乎,承诺也能兑现。但是如果一年纯利500 万,老板能舍得给50万吗?纯利1000万,2000万呢?所以到时候要么整个事业部跳槽另立山头,要么换将。从公司的角度来看,小公司实行“事业部”制并不有利于成本的控制,相反,它阻碍了相关团队的沟通,而且人员配备重复,并且不利于职责的合并和岗位的兼任(小公司经常一人多岗)。
所以我认为目前中国最糟糕的组织架构形式莫过于“事业部制”了。
很自然地,两个比萨队伍+“一条船的团队管理”+矩阵式的组织结构 就是我的首选,还要记得要“成本核算”哦。
不过,我目前还在打工中,纸上谈兵了,哈哈!
分享到:
相关推荐
最后,企业可以根据行业特性、技术特点和自身条件选择适合的组织模式,如职能式、区域式、事业部式、矩阵式、蜂窝式或动态网络式等。每种模式都有其适用的场景和目标,如职能式适合小到中型、产品单一的企业,而动态...
### 企业级应用软件架构开发过程与实践:深入解析 #### 软件与软件的特性:业务上下文视角 软件作为一种独特的制品,其特性显著区别于传统实物制品。最初,软件仅被视为科学计算的工具,但随着其功能的拓展,软件...
本文从敏捷方法的定义,提出背景,实施方法等方面对敏捷方法进行描述,并与传统软件工程方法相对比,分析敏捷开发的优劣。通过实际软件开发的案例分析软件生产的价值观,得出敏捷方法在软件开发中的价值。关键词:...
7. **组织架构设计方案**:在设计新架构时,应考虑多种可能的选择,对比不同方案的优劣,确保选择最符合公司长期发展的架构。 8. **可选择方案和比较**:在实际操作中,可能会有多种组织架构设置的方案,通过对比各...
简述湘军军制及其优劣.doc
3. **架构决策与评估**:论文可能涵盖了如何制定架构决策,如何评估不同设计方案的优劣,以及如何进行风险分析和权衡。 4. **架构风格**:不同的架构风格适应不同的业务场景。例如,分层架构适用于大型企业应用,...
金蝶软件优劣分析.pdf
《软件架构设计:程序员向架构师转型必备》是一本旨在帮助程序员提升技能,迈向更高层次——架构师的著作。在IT行业中,架构师的角色至关重要,他们不仅需要掌握编程技术,还需要具备系统设计、项目管理以及业务理解...
"例文-论软件架构的选择"可能会探讨不同软件架构模式(如微服务、单体、SOA等)的优缺点,以及如何根据项目需求选择合适的架构。这包括对业务需求的理解、技术趋势的考量以及未来发展的预估。选择正确的架构是保证...
数学建模国赛获奖论文整理,使用优劣解距离法topsis做的论文集合,可以系统的学习优劣解距离法topsis在数学建模中的应用,非常有用。
关于铁路企业管理的优劣分析论文.doc
编程语言部分,书籍可能涵盖了多种语言在软件架构中的角色和优劣。比如,函数式编程如何提升代码质量,面向对象设计原则(SOLID)如何指导类和接口的构建,以及如何选择合适的技术栈以适应项目需求。此外,可能还会...
### 企业级应用软件架构开发过程与实践2 #### 软件工程基本原理 **一、问题解决规律与工程学方法** 1. **问题解决的基本步骤:** - **识别与澄清问题:** 明确问题的具体内容,确定问题边界。 - **收集相关信息...
### 企业级应用软件架构开发过程与实践1 #### 第一章:软件与软件的特性——从业务上下文出发的软件图景 ##### 第一节:软件的缘起与信息技术对传统行业的改造 **软件的缘起** 软件的发展可以追溯到计算机技术的...
【现代分布式软件设计架构探讨】 随着信息技术的飞速发展,分布式软件系统已成为众多领域的主流,尤其是在网络技术的支持下,它们的广泛应用已经改变了软件工程的面貌。本文深入剖析了分布式软件的两种主要体系架构...
在方法论部分,报告引用了埃森哲关于组织机构设计的理念,指出战略是决定组织架构的主要因素。组织设计是一个决定未来结构、流程、系统和职责的过程,与公司战略、信息技术、业务流程紧密相关。同时,报告列举了...
### 软件架构入门详解 #### 一、软件架构概览 **软件架构**(Software Architecture)是指软件系统的整体设计框架,它定义了软件的主要组成部分及其相互间的关系。一个良好的软件架构对于软件的成功至关重要,特别...
### 浅析《红楼梦》中林黛玉及薛宝钗的性格优劣论 #### 摘要 《红楼梦》作为中国古代小说的经典之作,不仅展现了封建社会的繁华与衰落,更是通过对众多角色的细腻刻画,反映了当时社会的人情世故和个人命运。其中...