林锐《如何管理软件企业》第3章 组织结构和人力资源管理.docx
- 文档编号:6222233
- 上传时间:2023-01-04
- 格式:DOCX
- 页数:26
- 大小:80.95KB
林锐《如何管理软件企业》第3章 组织结构和人力资源管理.docx
《林锐《如何管理软件企业》第3章 组织结构和人力资源管理.docx》由会员分享,可在线阅读,更多相关《林锐《如何管理软件企业》第3章 组织结构和人力资源管理.docx(26页珍藏版)》请在冰豆网上搜索。
林锐《如何管理软件企业》第3章组织结构和人力资源管理
组织结构和人力资源管理
第3章
3.1组织结构的主要弊病和建设原则2
3.2关于项目组织结构4
3.2.1项目矩阵结构的优缺点4
3.2.2中小型项目的组织结构模型5
3.2.3软件项目的角色职责表7
3.3关于项目经理8
3.3.1项目经理的管理才能重要还是技术才能重要8
3.3.2通过什么途径挑选项目经理8
3.3.3项目结束后如何对待项目经理9
3.4如何组建研发团队9
3.4.1组建团队的基本流程9
3.4.2物色团队的领导10
3.4.3物色团队的核心成员11
3.4.4物色团队的普通成员12
3.5如何管理研发团队12
3.5.1团队管理的基本策略12
3.5.2规范化的管理13
3.5.3超越规范化的管理13
3.6研发人员的绩效分析方法15
3.7其它问题与解答18
3.7.1把IT员工当作有特色的人才还是无特色的民工看待18
3.7.2按时上下班还是弹性工作制19
3.7.3理清产品和项目之间的关系19
3.1组织结构的主要弊病和建设原则
组织结构的主要弊病有:
人员臃肿(不能产生效益的人过多);交叉管理;管理层次过多;岗位职责不清晰等。
在以前的国有企业和政府机构里,很小的部门就设立多个正副领导,又给每个领导配备人员供其体验当领导的滋味,所以人很多,什么事情都做不成。
同样的毛病传染到中学和大学的班级里,行政类的班干部有:
班长、副班长、学习委员、体育委员、劳动委员、文艺委员等;政治类的班干部有:
团支部书记、副书记、组织委员、宣传委员等;还有跨班级的干部:
学生会主席(若干副主席)、科协主席(若干副主席)、美协主席等。
有个同学生病住医院,同学们来看望他。
为了避免过多的人进病房干扰病人休息,医生说先让班干部进去看,结果进去了十来个干部。
在臃肿的机构里,平时干活的时候不见有干部,等到需要表现的时候,就会涌现很多干部。
企业建设组织结构的目的是为了把工作做好,使企业的利益最大化。
而不是为了给某些人安排职位(虚职),为了给他事情做而建立机构。
如果企业里面有很多“务虚”的职位,那么这个企业基本上没有前途。
企业里面要尽可能减少交叉管理,一个员工最好只有一个直接领导,否则若干领导指挥一个下属,那个下属都搞不清楚他究竟该听谁的、该干什么。
交叉管理会导致管理混乱,而且导致“法不责众”的现象。
在企业中,下达任务或者汇报工作时,尽可能减少管理层次。
管理层次越多,信息失真就越厉害,而且效率越低。
最快捷的方式是,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)避免交叉管理;(3)减少管理层次;(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章 组织结构和人力资源管理 林锐 如何 管理软件 企业 组织 结构 人力资源 管理