林锐《如何管理软件企业》第3章 组织结构和人力资源管理Word文档下载推荐.docx
- 文档编号:19227655
- 上传时间:2023-01-04
- 格式:DOCX
- 页数:26
- 大小:80.95KB
林锐《如何管理软件企业》第3章 组织结构和人力资源管理Word文档下载推荐.docx
《林锐《如何管理软件企业》第3章 组织结构和人力资源管理Word文档下载推荐.docx》由会员分享,可在线阅读,更多相关《林锐《如何管理软件企业》第3章 组织结构和人力资源管理Word文档下载推荐.docx(26页珍藏版)》请在冰豆网上搜索。
学生会主席(若干副主席)、科协主席(若干副主席)、美协主席等。
有个同学生病住医院,同学们来看望他。
为了避免过多的人进病房干扰病人休息,医生说先让班干部进去看,结果进去了十来个干部。
在臃肿的机构里,平时干活的时候不见有干部,等到需要表现的时候,就会涌现很多干部。
企业建设组织结构的目的是为了把工作做好,使企业的利益最大化。
而不是为了给某些人安排职位(虚职),为了给他事情做而建立机构。
如果企业里面有很多“务虚”的职位,那么这个企业基本上没有前途。
企业里面要尽可能减少交叉管理,一个员工最好只有一个直接领导,否则若干领导指挥一个下属,那个下属都搞不清楚他究竟该听谁的、该干什么。
交叉管理会导致管理混乱,而且导致“法不责众”的现象。
在企业中,下达任务或者汇报工作时,尽可能减少管理层次。
管理层次越多,信息失真就越厉害,而且效率越低。
最快捷的方式是,A下达任务给B,B向A汇报工作情况。
例如在项目中,大部分的事情,项目经理和项目成员直接沟通就可以了,只有重大事情才需要高层领导介入。
简而言之,组织结构的建设原则是:
(1)勿设无价值的职位(虚职);
(2)避免或减少交叉管理;
(3)减少管理层次;
(4)岗位职责要精炼且无重叠。
评价一个组织结构好不好,最简单的方法就是看组织结构图。
一眼就能看明白的组织结构,其运行效率通常比较高;
反之,如果看半天仍搞不清楚建设组织结构的意图,那么其运行效率就比较低。
案例说明:
图3-1是一个约40人左右的软件公司的研发组织结构图,我给这个公司做咨询时,花费了数天时间才搞明白该公司的复杂关系,费了好大的劲儿才绘制了组织结构图,连我自己都很难看得懂。
其它职能组
界面设计组
测试组
质量保证员
副总裁
质量部
总裁助理
应用推进工程师
应用推进部
公司总裁
项目经理部
业务咨询部
开发部
咨询与项目管理部
首席技术官CTO
研发部职能组
副总裁助理
研发管理副总裁
图3-1(a)某公司的研发组织结构(虚职过多,条块分割)
开发工程师
项目监督层
项目决策层
研发部各职能经理
项目执行层
协商
公共平台组
网络管理组
软件测试组
图3-1(b)某公司的项目结构(过于复杂)
该公司40个人中有一半人是经理或TeamLeader的头衔,大约有10个人的头衔带“总”,那么谁在第一线干活赚钱呢?
每个经理头衔的人都想插手管项目,导致项目结构非常复杂。
不到10个人的项目,竟然要划分决策层、监督层、执行层。
这个软件公司发展了十年,还只是数十人的规模,其中一个重大缺点就是组织结构太务虚。
希望同行企业引以为戒。
3.2关于项目组织结构
3.2.1项目矩阵结构的优缺点
矩阵结构的概念如图3-2所示:
公司的人员属于各个职能部门(例如开发部门、测试部门),当项目需要用人时,则从各个职能部门抽调相应的人员;
当项目不再用此人时,各职能部门把人员收回,准备用于其它项目。
项目A
项目B
项目C
职能部门1
项目成员
职能部门2
职能部门3
…
图3-2矩阵结构示意图
矩阵结构的主要优点:
(1)将人员按照职能部门划分,专业化程度更高。
(2)人力资源的组合、释放很灵活。
(3)理论上可以承接更多的项目。
但是如果职能部门划分过细,反而会对项目造成很大的伤害。
我曾经给一个软件公司做了2个月的咨询,发现该公司的最大毛病就是采用了“过度的”矩阵结构。
该公司软件人员大约30人,却划分了如此多的部门:
(1)项目管理部:
项目经理都从这个部门选取。
(2)业务咨询部:
该部门人员从事需求分析。
(3)开发部:
都是程序员,从事软件开发,其实就是编程。
(4)测试部:
都是测试人员,负责所有软件的测试。
(5)界面设计部:
负责所有软件的界面设计。
(6)公共平台组:
为大部分项目提供公共的技术平台。
(7)部署组:
这些人把软件部署到客户现场。
(8)应用推进部:
他们负责售后服务、技术支持。
这些部门都是相对独立的,部门之间没有上下级关系。
每个项目都没有固定的人员。
每个周五下午,公司领导把所有项目经理和所有部门经理(或者组长)招集开会,商定下周哪些人员用在哪个项目上,称为项目协调会。
我调查总结了如下缺点:
✧每周开项目协调会,大家争夺人力资源,非常疲惫,浪费中层干部的大量精力。
✧部门划分过多,条块分隔,沟通代价很高。
✧项目没有稳定的开发团队,上下两个环节的人来自不同的部门,难以默契配合,项目开发进度和质量都无法保证。
✧大部分项目人员都是“临时借用的”,基本上各自为政,没有团队的凝聚力、荣誉感。
✧各部门人员的知识技能太狭窄,长此以往,对个人、对企业的发展都不利。
该公司的一位项目经理曾发出幽默的感叹:
矩阵结构妙得很啊!
界面不好用,设计人员不着急;
软件有Bug,开发人员不着急;
用户手册写不好,推进部不着急;
只有项目经理干着急。
3.2.2中小型项目的组织结构模型
根据前面所述的组织结构建设原则:
(1)勿设虚职;
(2)避免交叉管理;
(4)岗位职责精简。
本节介绍中小型项目的组织结构模型,如图3-3所示。
汇报工作
项目成员(执行者)
需求分析员、设计师、程序员、测试员等
各项目
加入
项目
资源
职能单元
项目经理(管理者)
机构领导(决策者)
图3-3中小型项目的组织结构模型
项目组织结构按照职务高低划分为三个层次:
机构领导、项目经理、项目成员。
机构领导是项目经理的直接领导,这里机构可以是公司,也是可以是公司的开发部门。
一般地,机构领导是本机构内所有项目的决策者。
机构领导下达任务给项目经理,项目经理向机构领导汇报工作。
项目经理是本项目的管理者,他带领所有项目成员共同完成机构领导下达的任务。
项目成员是指在项目中执行具体任务的人员,例如程序员、测试人员、设计师等。
项目经理下达任务给项目成员,项目成员们向项目经理汇报各自承担的工作。
项目成员并非固定在一个项目中工作,他们可能来自于相对独立的职能单元,可以为多个项目提供服务(例如开发和测试)。
职能单元和项目之间的关系,可以用测试组和项目的关系来解释:
如果机构内没有相对独立的测试组,那么测试人员的直接领导就是项目经理。
如果机构内有测试组,那么测试人员的直接领导是测试经理,而项目经理相当于测试人员的“临时雇主”。
当测试人员接受了某个项目的测试任务,那么他要向测试经理和项目经理汇报工作。
当项目结束后,该项目的人力资源被释放。
机构领导决定本机构内部的人力资源如何应用。
作者曾给国内某著名IT公司“机顶盒”事业部做研发管理咨询,帮助该事业部制定了组织结构图(如图3-4所示)。
该事业部大约有30人,大部分是软件工程师,小部分(共约6人)是硬件工程师和测试工程师。
软件工程师
测试工程师
硬件工程师
公共资源组
经理
客户定制产品
项目经理
有线机顶盒
卫星机顶盒
事业部经理
协助项目
图3-4某公司“机顶盒”事业部的组织结构
该事业部有三个产品线:
卫星机顶盒、有线机顶盒、客户定制的机顶盒。
每个产品线都有相对稳定的软件开发团队,产品线的经理兼任项目经理。
一个项目结束后,原班人马并没有真正解散,他们会接着做该产品线的下一个项目,不断积累该领域的开发经验。
硬件工程师和测试工程师组成公共资源组(设立一名经理),他们为3个产品线的所有项目提供硬件开发和综合测试服务。
这个事业部的组织结构“精干高效”,一年多时间里面没有发现不合理之处。
该事业部经理认为自己最大的收益是:
从繁琐的研发管理事务中摆脱出来,自己有更多的精力关注市场,做更重要的事情。
3.2.3软件项目的角色职责表
软件项目的主要角色有:
机构领导,项目经理,需求分析员,系统设计师,界面设计师,程序员,测试员等。
每个角色必须有明确的职责(说明要做的事情和所负的责任),每个项目成员可以承担多个角色,视项目情况而定。
常见的软件项目角色职责如表3-1所示。
表3-1常见的软件项目角色职责表
项目角色
该角色在项目中的职责简述
机构领导
(1)他是项目的决策者,负责立项,任命项目经理,调配本部门的人力资源。
(2)在项目结束时,对项目进行综合评估。
(1)参与立项过程,向机构领导争取资源。
(2)负责“项目规划与监控、风险跟踪和变更控制、结项管理”过程域。
对项目的需求、进度、质量、成本负责最大责任。
(3)在项目结束时,对本项目进行自我评估,对项目成员的业绩进行评估。
需求分析员
(1)参与客户需求调研,分析需求,撰写需求文档。
(2)参与需求评审,将需求准确地传达给客户和其它项目成员。
系统设计师
(1)根据需求,设计软件系统架构,撰写设计文档。
(2)参与设计评审,将设计方案准确地传达给其它项目成员。
界面设计师
(1)根据需求,设计用户界面原型,不断优化。
(2)建设公共界面库,便于其他人员复用。
程序员
(1)对自己承担的模块进行“设计、编程、调试”,对进度和质量负责。
(2)对所有源代码进行配置管理。
测试员
(1)根据计划执行测试,使用Bug跟踪工具,及时将测试信息反馈给相关责任人。
(2)测试工程师及时将共性的质量问题汇报给项目经理。
3.3关于项目经理
3.3.1项目经理的管理才能重要还是技术才能重要
管理才能和技术才能都很重要,不能绝对地说“谁比谁”更加重要,应当视项目的规模和复杂性而定。
如果项目的技术难度很高,但是规模比较小,只有几个人干活,本来就没有什么好管理的,那么项目经理的技术才能比管理才能更加重要。
特别是一些创新程度比较高的小型项目,如果项目经理能够解决技术难题,弟兄们就很服他。
反之,如果项目的技术难度不高,但是规模比较大,只要团队成员超过十人,那么项目经理的管理才能比技术才能更加重要。
项目经理可以找到技术高手帮他解决项目中的技术难题。
我曾经参与一家大型外资电信企业的研发管理体系项目,项目经费约200万美元。
这个项目技术难度比较高,但是管理难度更高。
投资方派来监督(找茬)的有法国人、德国人、意大利人,咨询师来自美国和中国台湾地区,开发合作伙伴有印度人和HP公司在中国的雇员。
本人毫无疑问是本项目技术水平最高的“土专家”,但我不是项目经理。
公司领导任命了一位情报出身的管理人员当项目经理。
他对软硬件技术真是一窍不通,但是他有极强的协调能力。
每次开项目会议的时候,他都很“谦虚加自嘲”地说:
本人不懂技术,在座的每个人的水平都比我高,项目开发就靠各位专家兄弟了。
我的主要工作就是为大家提供服务,让大家舒服开心地工作,大伙儿有事情尽管找我。
刚开始大家认为项目经理没有多少真本事,觉得这个项目的麻烦会很多。
过了不久,大家就发现他真有过人的本领:
来“找茬”的法国人、德国人、意大利人和他玩了几天后,乐得合不拢嘴地回去了;
他把自以为是的美国人、台湾人恭维得屁颠屁颠;
把印度人感动得离别之际写文章赞扬“中印友谊”;
开发团队经常带家小外出“TeamBuilding”。
真的做到了“让大家舒服开心地工作”。
他的协调能力,我自叹弗如。
如果我当项目经理,必定和“鬼子们”讲真理、闹革命,项目必败无疑。
后来,他顺理成章地升为公司的副总裁。
可见在IT企业当领导并不见得必须是技术专家出身。
3.3.2通过什么途径挑选项目经理
一般有两种途径,首先从公司内部挑选合适的人员担任项目经理,如果内部没有合适的人员,那么从外界招聘项目经理。
大部分情况下,领导任命自己信得过的人担任项目经理。
除此之外,还要留一些机会给普通员工,让他们自己竞选项目经理,给员工们一个盼头。
当公司人员超过50人后,公司应当有立项制度,保证公司的员工们有公平的机会竞选项目经理。
例如有员工提出很好的立项建议,被公司采纳后,一般地该立项建议人会被任命为项目经理,因为他的功劳大、最希望项目成功。
3.3.3项目结束后如何对待项目经理
从理论上讲,项目经理是个临时的职位,项目结束后项目团队就解散了,项目经理也不存在了。
尽管项目经理算不上是高职位,但是至少也是个“小官”。
中国人的心理习惯是“能上不能下”,除非犯了错误才可能撤职或降职。
他曾经是项目经理,尽管没有犯错误,但是项目结束后他就不是项目经理了,大部分项目经理会有抵触情绪。
他可能会拖延项目,做一些消极的事情。
公司领导应当了解这种“能上不能下”的情结,妥善处理问题。
一般地,如果项目经理是合格的,当项目结束后,应继续保留“项目经理”的头衔和相应的待遇。
如果后面有新的项目,那么优先考虑他为新的项目经理。
反之,如果原先的项目经理不合格(例如他不懂得项目管理,无法带领团队工作),那么当项目结束后,自然而然地予以免职。
3.4如何组建研发团队
3.4.1组建团队的基本流程
物色人才
项目人员需求
产品开发需求
建立团队
组建团队的基本流程如图3-5所示,分四个步骤:
首先要了解产品开发需求,从而确定团队的人员需求,然后物色符合需求的人才,最终建立团队。
图3-5组建团队的基本流程
团队的人员从哪里来?
通常先在企业内部挑选,最大程度利用现有的人力资源。
如果企业内部不能满足要求的话,再通过社会招聘获取人才。
团队的人才结构是金字塔形的,可以简单划分为三层:
团队领导、核心成员和普通成员,如图3-6所示。
比较合理的人员比例为:
团队的领导不超过10%(当官的不能太多),核心成员占30%左右,普通成员占60%左右。
只有为企业创造的效益高于企业为其付出的成本的那些人,才是企业所需的人才。
团队需要优秀的人才。
技术开发是智力创作而非体力劳动,优秀人才的创造力比平庸之人要高得多,如果团队没有优秀的人才,几乎不可能开发出有竞争力的产品。
优秀人才的待遇需求通常比较高,但是他“物有所值”。
但是团队中的优秀人才并不是越多越好,优秀人才太多反而有很大的弊端。
一是人力成本太高,他们可能消耗掉该团队创造的大部分效益,那么就不划算了。
二是团队分裂的风险太大,因为团队的空间有限,无法同时满足很多优秀人才事业发展的期望,当这个矛盾激化时,优秀人才的内讧将产生极大的破坏力。
“一山不容二虎”就是这个道理。
所以,团队中的优秀人才恰好够用就行了。
一般地,让最优秀的人才当团队的领导,让次优秀的人才成为核心成员,让平庸之人成为普通成员。
图3-6所示的团队结构比较“稳定安全”并且“经济实惠”。
10%
团队领导
30%
核心成员
60%
普通成员
图3-6团队的人员结构
3.4.2物色团队的领导
开发团队的领导应当具备四项素质,按级别从低到高排列:
不错的技术才能,较强的管理能力,丰富的产品开发经验,敏锐的商业头脑,如图3-7所示。
敏锐的商业头脑
丰富的产品开发经验
重
要
性
较强的管理能力
不错的技术才能
图3-7团队领导应当具备的四项素质
IT企业在物色中小型团队的领导时,主要考察候选人的管理能力和技术才能。
对于搞技术出身的人,如果他能当上小头目,一般地讲他的技术才能不会太差,否则他岂有出头之日。
然而即使某个人的技术水平是团队里最强的,如果他不具备带领团队所有成员正确干活的能力(即管理能力),那么他就不能当团队的领导。
进一步,企业在物色重大的团队的领导时,不仅要考察候选人的技术才能和管理能力,尤其要关注商业头脑和产品开发经验。
商业头脑是团队领导最重要的素质。
有商业头脑的领导能够带领团队朝着最赚钱的道路前进,即使遇到一些坎坷,也无碍于最终的成功。
反之,缺乏商业头脑的领导通常不知道产品的卖点是什么,却一味在技术方面下功夫,经常让团队干些南辕北辙不赚钱的事情。
如果团队的领导有丰富的产品开发经验,那么他就能反复借用以前的成功经验,能够规避失败的风险。
当项目遭遇一些意外困难时,他自己不会手忙脚乱,能够从容地带领团队克服困难。
就如战斗中,存活率比较高的通常是队伍中的老兵,因为他们有丰富的战斗经验,而不是枪法比新兵好。
几年前我已经意识到“技术才能、管理能力、产品开发经验、商业头脑”是团队领导者必须具备的素质,只是四项要素的重要性刚好和图2-7所示的相反。
自从我对某公司多个重大研发项目的失败进行调查分析之后,我才决定把四项要素重要性的顺序纠正过来。
三年前,该公司对几个重大研发项目总共投资了近亿元。
每个项目的研发人员达百余人,研发经费达千万元以上,结果这些项目都以惨败而告终。
有几个项目做着做着就无声无息了,有几个项目好不容易推出了产品,结果因质量太差而被客户退回。
一时间公司内部怨愤极大。
我曾私下里做了调查分析,失败的原因有许多,最重要的一个共性原因是:
公司领导用错了项目经理。
这些项目经理都是博士,在技术方面算得上是专家,管理能力虽然没有技术才能那么强,但是也有中等水平。
最糟糕的是他们都缺乏商业头脑,缺乏产品开发经验,竟然沿用大学搞科研的方式在企业里开发产品,焉有不败之理!
这些人没有成功地运作过几十万元、上百万元的资金,猛地一下子拥有千万元的经费,稀里糊涂地浪费了许多钱。
这些项目给公司造成了重大损失,似乎没有一个责任人认真地反省过,从来没有人写过一篇总结为什么失败的文章。
重大失败就如轻飘飘的雪花那样融化了,连个故事都没有留下。
不少企业干过类似的蠢事,同行们要引以为戒,尤其要当心那些拥有高学历、占据重要职位的败家子。
简而言之,如果一个人想成为普通团队的合格领导者,他应当具备不错的技术才能和较强的管理能力。
如果他的抱负更大,想成为“将帅之才”,那么他必须具备丰富的产品开发经验和敏锐的商业头脑。
3.4.3物色团队的核心成员
领导者应当从团队里面挑选出一些核心成员,为自己分担压力。
不仅分派重要的任务给他们,而且也要给他们更多的利益。
区别“核心”与“普通”的要素是“才能、责任心、忠诚度”。
让责任心强、才能出色的人成为核心成员这是顺理成章的,无需解释大家都明白。
不少人对“忠诚度”有狐疑,觉得这是鼓励“拉帮结派、玩权术”。
大家不必忌讳“忠诚度”这个词,世上没有哪个领导不“拉帮结派、玩权术”的,否则他怎么能够巩固地位、向上发展呢。
只要他拉对了人、玩对了权术,这就是他的领导才能。
英明的领导不仅让那些才能出色、责任心强的人成为核心成员,而且还有能力使核心成员忠诚于他,从而使团队越来越强,大家的事业发展越来越好。
反之,平庸的领导常常重用亲近自己,但是才能平庸、责任心不强的人,当他自己陷入困境的时候,团队就“树倒猢狲散”。
3.4.4物色团队的普通成员
连普通成员都要物色吗?
是的,任何成员都会对项目产生影响,有正面的也可能有负面的,所以团队领导也要用心物色普通的成员。
如果把医院当成一个大的团队,把核心成员比做医生,那么普通成员就相当于护士,好医生加上好护士才能把医务工作做好。
选择普通成员的主要指标是“技能合格、安分守己、任劳任怨”。
技能合格是最低要求,因为招聘他来是干活的,而不是摆设。
团队中技能不合格(没有用处)的人应当通通剔除,即便他是个老好人。
如果项目要招聘程序员,而有一个落魄的博士前来应聘,他虽然写过许多文章却几乎不会编程,那么请他另谋高就,而不要招来撑门面。
安分守己是指这个人比较老实,不搞破坏,也没有非分之想。
安分守己的成员让领导放心。
安分守己向前一步就是任劳任怨,不仅让人放心而且让人感动。
任劳任怨是指领导让他干啥他就认真地干啥,即使很劳累、没有多少成就感,他也乐意。
任劳任怨这种美德只有普通人员才可能具备,因为优秀的人才只会对自己追求的东西倾注热情,很少对上级指派的工作任劳任怨。
任劳任怨的普通成员虽然在事业方面成不了大器,但是很值得交朋友。
朋友的交情是用情感而不是用功利来衡量的。
无论你的领导才能多么出众,在你强盛时期,你要用心照顾那些任劳任怨的普通成员,让他成为你的朋友。
而当你脆弱之际,他们会回馈给你友情,帮你走出心灵的困境。
小结:
就如人们找对象一样,你极难找到心目中完美的人,你目前所拥有的其实就是最适合你的。
在现实中,物色人才不要太挑剔,不要期望太高,甚至聚散离合都是正常现象,因为你不可能让所有理想中的好人全聚集在一个团队之中。
重要的是利用现有的条件组建一支能战斗的团队,向目标前进并努力获取胜利。
3.5如何管理研发团队
3.5.1团队管理的基本策略
团队管理的基本目标是:
让所有成员有条不紊地开展工作,在预定的时间和成本之内,开发完成质量合格的产品,从而使企业和个人获得预定的利益。
团队管理的努力目标是:
调动一切积极因素,努力提高产品质量、提高工作效率并且降低开发成本,使企业和个人获得比预定目标更多的利益。
团队管理的基本策略:
大部分的管理工作是成熟的,有成功的模式可以套用,应当走规范化管理的路线;
而另外小部分的管理工作可能是富有个性的,并不适宜套用规范,那么应当采用超越规范化的管理方式。
规范化的正面意义是“稳定有序”,负面意义是“僵化死板”。
超越规范化的正面意义“高效灵活”,负面意义是“混乱无序”。
团队管理既需要大量的规范化管理方式,又需要小量的超越规范化的管理方式。
通常前者约占80%,而后者约占20%(注意80-20仅仅是参考数据)。
国内大部分软件企业的管理现状是:
规范化管理太少了,非规范化的管理太多了,到处都是土匪游击队的运作方式。
阻碍中国软件企业发展的瓶颈问题通常不是技术,而是杂乱无章的管理,这个共性问题值得业界人士高度关注。
3.5.2规范化的管理
规范化管理有两层含义:
首先制定工作规范,然后按照规范开展工作。
研发团队的主要工作既有技术开发又有管理,因此至少需要两类规范。
一类是技术开发规范,它规定了如何开展需求分析、设计、
- 配套讲稿:
如PPT文件的首页显示word图标,表示该PPT已包含配套word讲稿。双击word图标可打开word文档。
- 特殊限制:
部分文档作品中含有的国旗、国徽等图片,仅作为作品整体效果示例展示,禁止商用。设计者仅对作品中独创性部分享有著作权。
- 关 键 词:
- 如何管理软件企业 林锐如何管理软件企业第3章 组织结构和人力资源管理 林锐 如何 管理软件 企业 组织 结构 人力资源 管理