第2章 组织结构和人力资源管理.docx
《第2章 组织结构和人力资源管理.docx》由会员分享，可在线阅读，更多相关《第2章 组织结构和人力资源管理.docx（28页珍藏版）》请在冰点文库上搜索。
第2章组织结构和人力资源管理
组织结构和人力资源管理
第2章
2.1常见问题与解答2
2.1.1把IT员工当作有特色的人才还是无特色的民工看待2
2.1.2项目矩阵结构的优缺点3
2.1.3项目经理的管理才能重要还是技术才能重要4
2.1.3通过什么途径挑选项目经理4
2.1.4项目结束后如何对待项目经理5
2.1.5按时上下班还是弹性工作制5
2.2理念和方法6
2.2.1建设组织结构的指导原则6
2.2.2理清产品和项目的关系7
2.2.3中小型项目的组织结构模型8
2.2.4软件项目的角色职责表10
2.2.5团队的人才结构11
2.2.6如何理解“知人善用”13
2.2.7开发人员的绩效分析方法14
2.1常见问题与解答
2.1.1把IT员工当作有特色的人才还是无特色的民工看待
大部分人看了这个问题觉得可笑，在他们的观念里，IT人士往往和“高科技、精英、白领”这些词汇联系在一起，和“民工”毫不相干。
十年前也许是那样的，如今形势已经改变了。
现在大部分IT企业的软件硬件技术门槛在下降，非专业人士也可以从事软件硬件开发工作。
社会上已经涌现了无数IT蓝领，人数太多，但是就业机会有限，很多大学生刚毕业就失业了，他们能够养活自己已经不错了。
我曾经和比较大的外包软件公司的一名经理谈论大学教育话题，他以嘲笑的口气对我讲：
我真是不明白计算机系和软件学院是怎样培养学生的，其实我们想要的就是月薪1000元，老老实实干活的人。
如果学校愿意培养这样的蓝领，那么我们招聘、解聘就轻松多了。
公司形势好的话就一个班一个班地招进来，形势不好的话就一批一批地裁员，再也不必看简历、东挑西拣了。
这是我亲耳朵听到的，尽管让人寒心，我还是如实写下来，让IT人士明白自己的处境。
在上海和北京这样的城市，月薪1000元的IT蓝领，他们的生存状态其实和“民工”差不多。
本节问题没有标准答案，没有“对”“错”之分。
甚至也不必指责后者心太黑，因为企业的本性就是追求利益最大化。
作者想说明的是，该问题的不同答复将产生截然不同的管理方式。
如果企业领导把员工们当作有特色的人才看待，那么这个企业必定走“精兵强将”的路线。
“特色”意味者每个人都有特别的优点和缺点，领导只有在充分了解每个下属的“特色”后，才能够做到扬长避短，有所为而有所不为，使团队的战斗力最强。
这种管理模式下，一个领导比较适合带领不超过7个直接下属，如果人数再增加他就操心不过来了。
例如高级经理带领7个中级经理，每个中级经理带7个基层员工，50个人员的机构需要8名经理。
如果企业领导把员工们当作无特色的民工看待，那么这个企业要走“量贩”的路线。
企业并不关心每个员工擅长什么、不擅长什么，它更加关注：
（1）以最低的工资招聘恰好能够干活的员工，使“人月”成本最低；
（2）准确地估计项目的工作量，总的人月收入减去总的人月成本，就是利润；（3）努力承接项目，活多就多招人，活少就少招人。
例如，企业承接一个合同项目，双方讨价还价后确定：
该项目共需3个人月，每个人月报价1万元。
如果企业的人工成本是每人月5000元，刚好花费3人月完成该项目，那么利润率达50％。
但是如果估计不准或者开发不顺利，预计3人月的工作却花费了6人月才完成，那么利润为零。
2.1.2项目矩阵结构的优缺点
矩阵结构的概念如图2-1所示：
公司的人员属于各个职能部门（例如开发部门、测试部门），当项目需要用人时，则从各个职能部门抽调相应的人员；当项目不再用此人时，职能部门把人员收回，将用于其它项目。
项目A
项目B
项目C
职能部门1
职能部门2
职能部门3
…
图2-1矩阵结构示意图
矩阵结构的主要优点：
（1）将人员按照职能部门划分，专业化程度更高。
（2）人力资源的组合、释放很灵活。
（3）理论上可以承接最多的项目。
但是如果职能部门划分过细，反而会对项目造成很大的伤害。
我曾经给一个软件公司做了2个月的咨询，发现该公司的最大毛病就是采用了“过度的”矩阵结构。
该公司软件人员大约30人，却划分了如此多的部门：
（1）项目管理部：
项目经理都从这个部门选取。
（2）业务咨询部：
该部门人员从事需求分析。
（3）开发部：
都是程序员，从事软件开发，其实就是编程。
（4）测试部：
都是测试人员，负责所有软件的测试。
（5）界面设计部：
负责所有软件的界面设计。
（6）公共平台组：
为大部分项目提供公共的技术平台。
（7）部署组：
这些人把软件部署到客户现场。
（8）应用推荐部：
他们负责售后服务、技术支持。
这些部门都是相对独立的，部门之间没有上下级关系。
每个项目都没有固定的人员。
每个周五下午，公司领导把所有项目经理和所有部门经理（或者组长）招集开会，商定下周哪些人员用在哪个项目上，称为项目协调会。
我调查总结了如下缺点：
Ø每周开项目协调会，大家争夺人力资源，非常疲惫，浪费中层干部的大量精力。
Ø部门划分过多，条块分隔，沟通代价很高。
Ø项目没有稳定的开发团队，上下两个环节的人来自不同的部门，难以默契配合，项目开发进度和质量都无法保证。
Ø大部分项目人员都是“临时借用的”，基本上各自为政，没有团队的凝聚力、荣誉感。
Ø各部门人员的知识技能太狭窄，长此以往，对个人、对企业的发展都不利。
该公司的一位项目经理发了幽默的感叹：
矩阵结构妙得很啊！
界面不好用，设计人员不着急；软件有Bug，开发人员不着急；用户手册写不好，推进部不着急；只有项目经理干着急。
2.1.3项目经理的管理才能重要还是技术才能重要
管理才能和技术才能都很重要，不能绝对地说“谁比谁”更加重要，应当视项目的规模和复杂性而定。
如果项目的技术难度很高，但是规模比较小，只有几个人干活，本来就没有什么好管理的，那么项目经理的技术才能比管理才能更加重要。
特别是一些创新程度比较高的小型项目，如果项目经理能够解决技术难题，弟兄们就服他了。
反之，如果项目的技术难度不高，但是规模比较大，只要团队成员超过十人，那么项目经理的管理才能比技术才能更加重要。
项目经理可以找到技术高手帮他解决项目中的技术难题。
我曾经参与一家大型外资电信企业的研发管理体系项目，项目经费约200万美元。
这个项目技术难度比较高，但是管理难度更高。
投资方派来监督（找茬）的有法国人、德国人、意大利人，咨询师来自美国和台湾，开发合作伙伴有印度人和HP公司在中国的雇员。
本人毫无疑问是本项目技术水平最高的“土专家”，但我不是项目经理。
公司领导任命了一位搞情报出身的管理人员当项目经理。
他真的是对软件硬件技术一窍不通，但是他有极强的协调能力。
每次开项目会议的时候，他都很“谦虚加自嘲”地说：
本人不懂技术，在座的每个人的水平都比我高，项目开发就靠各位专家兄弟了。
我的主要工作就是为大家提供服务，让大家舒服开心地工作，大伙儿有事情尽管找我。
刚开始大家认为项目经理没有多少真本事，觉得这个项目的麻烦会很多。
过不了多久，大家就发现他真有过人的本领：
来找茬的法国人、德国人、意大利人和他玩了几天后，乐得哈不拢嘴地回去；他把自以为是的美国人、台湾人恭维得屁颠屁颠；把印度人感动得离别之际写文章赞扬“中印友谊”；开发团队经常带家小外出“TeamBuilding”。
真的做到了“让大家舒服开心地工作”。
他的协调能力，我自叹弗如。
如果我当项目经理，必定和“鬼子们”讲真理闹革命，项目必败无疑。
后来，他顺理成章地升为公司的副总裁。
可见在IT企业当领导并不见得必须是技术专家出身。
2.1.3通过什么途径挑选项目经理
一般有两种途径，首先从公司内部挑选合适的人员担任项目经理，如果内部没有合适的人员，那么从外界招聘项目经理。
大部分情况下，领导任命自己信任得过的人担任项目经理。
除此之外，还要留一些机会给普通员工，让他们自己竞选项目经理，给员工们一个盼头。
当公司人员超过50人后，公司应当有立项制度，保证公司的员工们有公平的机会竞选项目经理。
例如有员工提出很好的立项建议，被公司采纳后，一般地该立项建议人被任命为项目经理，因为他的功劳大、最希望项目成功。
2.1.4项目结束后如何对待项目经理
从理论上讲，项目经理是个临时的职位，项目结束后项目团队就解散了，项目经理也不存在了。
尽管项目经理算不上是高职位，但是至少也是个“小官”。
中国人的心理习惯是“能上不能下”，除非犯了错误才可能撤职或降职。
他曾经是项目经理，尽管没有犯错误，但是项目结束后他就不是项目经理了，大部分项目经理会有抵触情绪。
他可能会拖延项目，做一些消极的事情。
公司领导应当了解这种“能上不能下”的情结，妥善处理问题。
一般地，如果项目经理是合格的，当项目结束后，应继续保留“项目经理”的头衔和相应的待遇。
如果后面有新的项目，那么优先考虑他为新的项目经理。
反之，如果原先的项目经理不合格（例如他不懂得项目管理，无法带领团队工作），那么当项目结束后，自然而然地免职。
2.1.5按时上下班还是弹性工作制
技术开发做得好不好，主要取决开发人员的技术水平和当时的体能、情绪。
软件人员在编程和调试时，干活要一鼓作气完成，不要中途停下来做其它事情之后再接着编程调试，否则思路丢失，重新捡起来很费劲。
所以程序员经常在夜里干活，这样效率比较高。
据说真正的程序员不会在上午9:
00到下午5:
00之间工作，如果你看到他在上午9:
00工作，这表明他从昨晚一直干到现在。
我在读大学的10年里有8年是当程序员，通宵编程是家常便饭（有时化20个小时追踪算法错误），曾经引以为豪。
现在反思，觉得很不值得，因为夜里干活白天睡觉的生活很不正常，天长日久绝对伤害身体健康。
我曾经给一个软件公司讲课，建议程序员要学一点养生之道，席间有个程序员大发感叹：
我的大学专业不是计算机，很少编程，毕业后到公司当程序员，很兴奋，工作两年来经常熬夜干活。
你看我现在脸色发青，毛孔粗大，背有点弯了，时不时腰椎发痛。
我以后再也不熬夜干活了。
弹性工作制在软件公司比较流行，但是要适度，不可完全抛弃正常的上下班制度。
一些建议：
（1）弹性工作制只能在小范围内采用（例如小型项目内部），不能用于大的机构，否则大部分人员随意上下班，公司无法正常运营。
（2）经常和客户联系的人员不该采用弹性工作制，否则如果客户有急事找他，他却在睡大觉，那么客户对公司的印象会很差。
（3）即使有些人可以采用弹性工作制，也应该在正常上下班的基础之上适当弹性1－2个小时，不应该白天黑夜颠倒过来。
公司毕竟是集体，不是一盘散沙的个体。
2.2理念和方法
2.2.1建设组织结构的指导原则
在以前的国有企业和政府机构里，很小的部门就设立多个正副领导，又给每个领导配些人员体验当领导的滋味，所以人很多，什么事情都做不成。
同样的毛病传染到中学和大学的班级里，行政类的班干部有：
班长、副班长、学习委员、体育委员、劳动委员、文艺委员等；政治类的班干部有：
团支部书记、副书记、组织委员、宣传委员等；还有跨班级的干部：
学生会主席（若干副主席）、科协主席（若干副主席）、美协等。
有个同学生病住医院，同学们来看望他。
为了避免过多的人进病房干扰病人休息，医生说先让班干部进去看，结果进去了十来个干部。
在臃肿得机构里，平时干活的时候不见有干部，等到需要表现的时候，就会涌现很多干部。
企业建设组织结构的目的是为了把工作做好，使企业的利益最大化。
而不是为了给某些人安排职位（虚职），为了给他事情做而建立机构。
如果企业里面有很多“务虚”的职位，那么这个企业基本上没有前途。
企业里面要尽可能减少交叉管理，一个员工最好只有一个直接领导，否则若干领导指挥一个下属，那个下属都搞不清楚他究竟该听谁的、该干什么。
交叉管理会导致管理混乱，而且导致“法不责众”的现象。
在企业中，下达或者汇报一项工作时，尽可能减少管理层次。
管理层次越多，信息失真就越厉害，而且效率越低。
最快捷的方式是，A下达任务给B，B向A汇报工作情况。
例如在项目中，大部分的事情，项目经理和项目成员直接沟通就可以了，只有重大事情才需要高层领导介入。
简而言之，建设组织结构的指导原则是：
（1）勿设没有价值的职位（虚职）；
（2）避免交叉管理；（3）减少管理层次。
评价一个组织结构好不好，最简单的方法就是看组织结构图。
一眼就能看明白的组织结构，其运行效率通常比较高；反之，如果看半天搞不清楚组织结构的意图，那么其运行效率就比较差。
案例说明：
图2-2是一个约40人左右的软件公司的研发组织结构图，我给这个公司做咨询时，花费了数天时间才搞明白该公司的复杂关系，费了好大的劲儿才绘制了组织结构图，连我自己都很难看得懂。
该公司40个人中有一半人是经理或TeamLeader的头衔，大约有十人的头衔带“总”，那么谁在第一线干活赚钱啊？
每个经理头衔的人都想插手管项目，导致项目结构非常复杂。
不到10个人的项目，竟然要划分决策层、监督层、执行层。
这个软件公司发展了十年，还只是数十人的规模，其中一个重大缺点就是组织结构太务虚。
希望同行企业引以为戒。
其它职能组。
。
。
界面设计组
测试组
质量保证员
副总裁
质量部
总裁助理
应用推进工程师
应用推进部
公司总裁
项目经理部
业务咨询部
开发部
咨询与项目管理部
首席技术官CTO
研发部职能组
副总裁助理
研发管理副总裁
图2-2（a）某公司的研发组织结构（虚职过多，条块分割）
界面设计组
开发工程师…
开发工程师…
项目监督层
项目决策层
研发部各职能经理
项目执行层
协商
协商
应用推进工程师
应用推进工程师
应用推进部
公共平台组
网络管理组
软件测试组
开发工程师…
图2-2（b）某公司的项目结构（过于复杂）
2.2.2理清产品和项目的关系
IT企业可能开发“产品”也可能开发“项目”，有些时候一个产品分成若干项目，公司里面有产品经理又有项目经理。
很多人搞不清楚什么是产品管理什么是项目管理，概念不清楚导致干活稀里糊涂。
产品开发完成后，它是可以重复销售的，产品将一直存在直到它被淘汰完止。
而项目则是一次性的，项目结束后就不存在了。
项目生命周期是产品生命周期的一部分，如图2-3所示。
产品生命周期
项目生命周期
产品淘汰
营销、客户服务等
产品构思
调研、可行性分析等
需求定义、设计、实现、测试等
结束项目
立项开发
图2-3产品生命周期和项目生命周期的示意图
产品管理侧重于可行性分析、营销和客户服务等，而项目管理侧重于需求定义、设计、实现、测试这些开发过程的的管理。
产品要升级换代，每次升级开发，都是一个新的项目。
例如“集成化项目管理系统Future”是我公司的产品，Future产品每个6个月推出新的版本，我们在开发Future1.0,2.0,3.0的时候都会成立对应的项目。
在大企业里，人力资源比较充足。
产品经理和项目经理是不同的人员，产品经理关注“产品是否符合市场需求，是否卖得好”，项目经理的主要职责是“把当前版本的产品开发好”。
对于小公司而言，产品经理和项目经理通常是一个人，他不仅负责把产品开发好，而且还要卖得好。
2.2.3中小型项目的组织结构模型
根据前面所述的建设组织结构的指导原则：
（1）勿设虚职；
（2）避免交叉管理；（3）减少管理层次，本节介绍中小型项目的组织结构模型，如图2-4所示。
项目组织结构按照职务高低划分为三个层次：
机构领导、项目经理、项目成员。
机构领导是项目经理的直接领导，这里机构可以是公司，也是可以是公司的开发部门。
一般地，机构领导是本机构内所有项目的决策者。
机构领导下达任务给项目经理，项目经理向机构领导汇报工作。
项目经理是本项目的管理者，他带领所有项目成员共同完成机构领导下达的任务。
项目成员是指在项目中执行具体任务的人员，例如开发人员、测试人员、界面设计师等。
项目经理下达任务给项目成员，项目成员们向项目经理汇报各自承担的工作。
项目成员并非固定在一个项目中工作，他们可能来自于相对独立的职能单元，可以为多个项目提供服务（例如测试）。
职能单元和项目之间的关系，可以用测试组和项目的关系来解释：
如果机构内没有相对独立的测试组，那么测试人员的直接领导就是项目经理。
如果机构内有测试组，那么测试人员的直接领导是测试经理，而项目经理相当于测试人员的“临时雇主”。
当测试人员接受了某个项目的测试任务，那么他要向测试经理和项目经理汇报工作。
当项目结束后，该项目的人力资源被释放。
机构领导决定本机构内部的人力资源如何应用。
项目成员：
需求分析员、界面设计师、开发人员、测试人员、客户服务人员等…
加入
项目
协商
资源
各职能单元如测试组等
项目经理
各项目
汇报工作
机构领导（决策者）
图2-4中小型项目的组织结构模型
案例说明：
作者曾给国内某著名IT公司“机顶盒”事业部做研发管理咨询，帮助该事业部制定了组织结构图（如图2-5所示）。
该事业部大约有30人，大部分人是软件工程师，小部分人是硬件工程师和测试工程师（共约6人）。
软件工程师
软件工程师
测试工程师
硬件工程师
软件工程师
公共资源组
经理
客户定制产品
项目经理
有线机顶盒
项目经理
卫星机顶盒
项目经理
事业部经理
协助项目
图2-5某公司“机顶盒”事业部的组织结构
该事业部有三个产品线：
卫星机顶盒，有线机顶盒，客户定制的机顶盒。
每个产品线都有相对稳定软件开发团队，产品线的经理兼任项目经理。
一个项目结束后，原班人马并没有真正解散，他们会接着做该产品线的下一个项目，不断积累该领域的开发经验。
硬件工程师和测试工程师组成公共资源组（设立一名经理），他们为3个产品线的所有项目提供硬件开发和综合测试服务。
这个事业部的组织结构“精干高效”，一年多时间里面没有发现不合理之处。
该事业部经理认为自己最大的收益是：
从烦琐的研发管理事务中摆脱出来，自己有更多的精力关注市场，做最重要的事情。
2.2.4软件项目的角色职责表
每个项目成员可以拥有多个角色，视项目情况而定。
每个角色必须有明确的职责（说明要做的事情和所负的责任）。
常见的软件项目角色职责如表2-1所示。
项目角色
该角色在项目中的职责简述
机构领导
（1）他是项目的决策者，确定立项后下达《项目任务书》给项目经理。
（2）在项目结束时，对项目进行综合评估。
项目经理
（1）参与立项过程，和机构领导协商《项目任务书》的内容。
（2）负责“项目规划与监控、变更管理、需求管理、质量管理”。
及时检查项目的执行状况，对项目的需求、进度、工作成果的质量、项目费用负责。
（3）在项目结束时，对本项目进行自我评估，对项目成员的业绩进行评估。
需求分析员
（1）负责调查客户需求，撰写《需求规格说明书》，努力将需求准确地传达给其它项目成员。
（2）根据需求构思用户界面原型，和界面设计师共同设计产品的用户界面。
界面设计师
（1）根据需求，设计用户界面原型，不断优化。
（2）撰写相关文档，建立用户界面图片的索引（用HTML页面）。
软件开发工程师
（1）根据项目计划执行“设计、编程调试”等开发工作。
（2）撰写本项目的技术文档和《软件使用说明书》。
（3）在项目结束时，开发工程师及时总结经验教训，在公司范围内共享。
测试工程师
（1）根据项目计划执行测试，使用Bug跟踪工具，及时将测试信息反馈给相关责任人。
（2）测试工程师及时将共性的质量问题汇报给项目经理。
客服工程师
（1）按照“客户申请－处理－答复－客户反馈”的流程开展客户服务工作，提高客户的满意度；
（2）周期性地主动和客户沟通、交流，发掘并记录有价值的信息，及时反馈给项目团队。
表2-1常见的软件项目角色职责表
2.2.5团队的人才结构
团队的人才结构是金字塔形的，可以简单划分为三层：
团队领导、核心成员和普通成员，如图2-6所示。
比较合理的人员比例为：
团队的领导不超过10％（当官的不能太多），核心成员占30％左右，普通成员占60％左右。
10%
团队领导
30%
核心成员
60%
普通成员
图2-6团队的人员结构
只有为企业创造的效益高于企业为其付出的成本的那些人，才是企业所需的人才。
团队需要优秀的人才。
技术开发是智力创作而非体力劳动，优秀人才的创造力比平庸之人要高得多，如果团队没有优秀的人才，几乎不可能开发出有竞争力的产品。
优秀人才要价通常比较高，但是他物有所值。
但是团队中的优秀人才并不是越多越好，优秀人才太多反而有更大的弊端。
一是人力成本太高，他们可能消耗掉该团队创造的大部分效益，那么就不划算了。
二是团队分裂的风险太高，因为团队的空间有限，无法同时满足很多优秀人才事业发展的欲望；当这个矛盾激化时，优秀人才的内讧将产生极大的破坏力。
“一山不容二虎”就是这个道理。
所以，团队中的优秀人才恰好够用就行了。
一般地，让最优秀的人才当团队的领导，让次优秀的人才成为核心成员，让平庸之人成为普通成员。
图2-6所示的团队结构比较“稳定安全”并且“经济实惠”。
一、物色团队的领导
开发团队的领导应当具备四项素质，按级别从低到高排列：
不错的技术才能，较强的管理能力，丰富的产品开发经验，敏锐的商业头脑，如图2-7所示。
敏锐的商业头脑
丰富的产品开发经验
重
要
性
较强的管理能力
不错的技术才能
图2-7团队领导应当具备的四项素质
IT企业在物色中小型团队的领导时，主要考察候选人的管理能力和技术才能。
对于搞技术出身的人，如果他能当上小头目，一般地讲他的技术才能不会太差，否则他岂有出头之日。
然而即使某个人的技术水平是团队里最强的，如果他不具备带领团队所有成员正确干活的能力（即管理能力），那么他就不能当团队的领导。
进一步，企业在物色重大的团队的领导时，不仅要考察候选人的技术才能和管理能力，尤其要关注商业头脑和产品开发经验。
商业头脑是团队领导最重要的素质。
有商业头脑的领导能够带领团队朝着最赚钱的道路前进，即使遇到一些坎坷，也无碍于最终的成功。
反之，缺乏商业头脑的领导通常不知道产品的卖点是什么，却一味在技术方面下功夫，经常让团队干些不赚钱的南辕北辙的事情。
如果团队的领导有丰富的产品开发经验，那么他就能复用以前的成功经验，能够规避失败的风险。
当项目遭遇一些意外困难时，他自己不会手忙脚乱，能够从容地带领团队克服困难。
就如战斗中，存活率比较高的通常是队伍中的老兵，因为他们有丰富的战斗经验，而不是枪法比新兵好。
几年前我已经意识到“技术才能、管理能力、产品开发经验、商业头脑”是团队领导者必须具备的素质，只是四项要素的重要性刚好和图2-7所示的颠倒。
自从我对某公司多个重大研发项目的失败进行调查分析之后，我就把四项要素的重要性顺序纠正过来。
三年前，该公司对几个重大研发项目总共投资了近亿元。
每个项目的研发人员达百余人，研发经费达千万元以上，结果这些项目都以惨败而告终。
有几个项目做着做着就无声无息了，有几个项目好不容易推出了产品，结果因质量太差而被客户退回。
一时间公司内部怨愤极大。
我曾私下里做了调查分析，失败的原因有许多，最重要的一个共性原因是：
公司领导用错了项目经理。
这些项目经理都是博士，在技术方面算得上是专家，管理能力虽然没有技术才能那么强，但是也有中等水平。
最糟糕的是他们都缺乏商业头脑，缺乏产品开发经验，竟然沿用大学搞科研的方式在企业里开发产品，焉有不败之理！
这些人没有成功地运作过几十万元、上百万元的资金，猛地一下子拥有千万元的经费
升级会员 