人员管理方法Word文件下载.docx
《人员管理方法Word文件下载.docx》由会员分享，可在线阅读，更多相关《人员管理方法Word文件下载.docx（14页珍藏版）》请在冰豆网上搜索。
主管在带新业务员时至少一起去拜访十家客户，且实施五个步骤：
A、我做你看。
在访问前三家客户时完全由主管来做，新人在一旁看着主管如何做；
这时主管应该尽可能拜访陌生客户，让新人学习如何去面对陌生客户，该如何去介绍公司及自已等。
B、我做你帮。
接下来再拜访三家客户时，由主管主要负责商谈及介绍，新人则在一旁帮着做些辅助性工作。
C、你做我帮。
主要由新业务员来做，然后主管在一旁帮着做。
D、你做我看。
拜访第十家客户的时侯，主管可以基本不参与，让新人自己做；
但要看着他做。
E、你做我管。
在以后的工作中，主管做好管理及监督工作，失败或出现问题可帮着总结，并告之属于正常的过程，并指导如何做对。
新人在拜访客户时是会有恐惧心理的，特别是他不知怎么和客户打交道时，或被客户拒绝的时侯，做主管或经理的一定要在这个时侯教他怎么做，帮助他，鼓励他。
2、制度与情感。
二者相比，情感重于制度，相互的关系和要求如下：
A、执行制度是目的，但却靠情感去推动。
就像我们每个部门，其实可算是一个个小型企业，在小型企业里，就应该是人情化的管理。
人情化的管理不是说可以脱离制度，而是以人情化的管理去达到执行制度的目的。
B、经理应当非常了解部门人员的情况。
包括员工的学历、专业、生活、家庭、性格等基本情况，以便于更好地交流。
还有就是要注意到下属的实际困难，特别是一些生活上的困难，要能及时地了解到并给予关心。
C、主管带新人的管理边际要留大，以一带四或五为宜。
D、新人建立日志，做好其成长跟踪；
E、在以上基础上决定去留。
3、公平理性A、能吃亏。
为下属解决困难，善待下属是德行修炼的要求。
有的经理怕吃亏，让下属请客吃饭。
靠请领导吃饭搞关系是没有用的，要的是把工作做好。
如果下属把工作做好了，经理应该要能“吃亏”。
还有的经理在用人时，容不了下属比他强，怕下属超过他。
就像武大郎开店专挑比他矮的人一样，这样肯定不行。
B、工作中，要做到对事不对人。
二、业务管理1、授之以渔带新人学会如何打电话，如何与客户交谈，如何介绍公司；
不能少于10次。
特别是在电话行销时，一定要让主管当着新人的面给客户打电话。
让新人学习该如何说，说什么。
公司的经理人最好须从业务员做起，只有做得非常优秀，才会有更加具体而丰富的经验。
在带新人时，经理就应当教授新人如何做。
2、处理各种危机A、新旧员工交接时。
主管应该掌握客户的情况。
有员工离职，在做交接时，主管须了解客户的情况。
绝对不能让要离职的员工去带新业务员。
马上要离职的业务员他能尽心尽责地带好新人吗而且有些时侯让老业务员带新人也不行，因为老业务员的利益和新人是不一致的，他也没有责任会好好带新人。
只能是主管或经理一定要做好这个工作。
B、价格争议时。
主管或经理可予业务员一定的议价权利及空间，须掌握底线，合理地决策之。
C、关键的客户维护。
在处理问题的过程中，主管不能在下属面前抱怨，不能当下属的面前叫苦。
如果主管叫苦抱怨，试想下属听了心里会怎么想。
员工听了还会有信心吗3、2:
8定律按照业绩进行分析，往往80%的业务量是在20%的客户上产生的。
所以对20%的重点客户，主管一定要亲自拜访；
即使有业务员离职，主管还是要掌握这些客户的情况。
三、人员招聘1、什么样的人合适做业务员，应从以下几方面考虑：
A、性格。
性格开朗一些可能更容易和客户打交道（选择B型血型的人搞营销较好，不可统括）。
B、家庭情况。
一般来说，我们更需要一些“苦大仇深”的人员，特别在乎这份工作的人。
一些家庭条件太优越的往往不是特别渴望得到这份工作，呆不了多久就会走。
当然也不排除一些例外。
C、年龄性别。
一类是刚刚从学校毕业的，他们往往充满激情；
另一类是小妈妈，初为人母，接人待物特别有责任心。
D、经验方面。
往往社会经验重于业务经验。
E、直觉。
相信你的直觉，如果你第一次见到这个应聘者就感觉哪也不对劲，那在今后的同事当中也觉得别扭，这肯定不行。
2、如实地介绍公司情况A、告知工作性质和难度。
让新人从心理上有所准备，要如实地告知他们业务的艰难，看他们的反映。
B、告知三个月是最关键的时期。
但同时也要鼓励他们，告诉他们前三个月是最辛苦的，只要坚持过了这三个月，以后也就慢慢地适应了。
C、告知发展前景。
把公司的发展前景介绍给他，让他对自已的选择充满信心。
3、推出功勋业务员概念公司总有些优秀的业务员并不适合做管理，一些业务员可能业务做的很好，但在部门里,人际关系却并不一定相处的好，并不适合做管理者。
对于这样优秀业务员的发展空间应该从哪方面来体现呢即推出功勋业务员概念。
如可以提供一些培训甚至出国游游的机会，或提高其工资等；
使其有直属经理的相关待遇及优越感，提倡职业的专向发展。
人员管理有方法没绝招
人员管理是最基础的管理工作
主持人：
您认为做好管理工作，是先管人还是先管事这两者之间关系如何？
王玉萍：
从我个人体会来看，一个公司要发展，当然还是要先管人。
应该说它是一切管理工作的基础，没人根本没法做事。
IT这个行业，人是维系客户和运作项目的主要承担者。
少了人的管理，公司没法正常运行。
管理好了人，培养了符合企业需要的人才，那么什么事就可以放心大胆地让员工去运作，老板只负责整体运营的协调，那么这种协作型的公司就一定能把事情做好，取得长足的发展。
在近几年的发展过程中，星际的人员管理工作做得如何？
星际平稳的发展还是要归功于人员管理的到位，这是一个良性循环。
在人的管理工作上，星际还是积累了一套属于自己的方法，或许没有绝招那么高效，但这些方法从现在公司发展情况来看，可以说在某种程度上对公司业务发展起了很好的保证作用。
人员是一切工作的基础，管好了人，自然就很好运作，而每个人都把自己的工作做好了，能力得到提升，有了成就感，找到了前进的目标，自然就会与公司共进退。
总体而言，一般商务等内务型工作人员的流动性很小，分销部和大客户部由于公司积淀很久，有着稳定的客户资源，所以这两个部门人员稳定性比较高。
人员流动最大的是专卖店部门，而其中以店面销售员居多。
虽然人员流动并不是人员管理的主要工作，但是稳定的工作人员往往可以很好保证公司各项业务的正常完成。
人员管理工作挑战很大
刚才您提到员工跳槽的事情，请问人员管理工作容易出现哪些方面的问题哪方面是最重要的工作？
人员管理工作很具有挑战性，尤其是现在市场环境，使得许多企业制度在实施过程中总是很难按期望达到预定的效果。
IT行业并不是很规范，竞争激烈且无序，各公司之间恶性挖人的事情很严重。
虽然对于星际来说保持一定比率的人员流动率是必须的事情，但对于人才培养，星际还是从薪酬设计、奖励措施以及人员发展规划等多方面设定相关制度，通过执行，既保持合理的人员流动率，还做好了人才储备工作。
人员管理工作是一个复杂的过程，从人才的选用到人才的培养以及到最终求得最好的发展，对公司对其个人来说都是一个非常重要的事情。
除人员的流动性问题之外，人才培养和安置的问题也是很让人费心的事情，其中人才培养工作是最重要的方面。
星际在用人上实行“疑人不用用人不疑”的原则，适度的放权往往更能激发其工作热情，也可在实践中提升他们的工作能力，而这一切管理的结果都要求公司能通过发现其特长将员工安置到最佳的工作岗位上，让其得到最好的发展，这样人员流动的问题就能得到很好解决。
最近陕西某公司的一个店长带着8名员工集体跳槽，您如何分析和看待这样的事件？
在星际，像这种大规模的跳槽没有发生过。
作为总经理，我很反对这种事情的发生。
我不是对这个事做一个评价，只是说一个自己的看法。
这种集体跳槽其实对公司发展影响很大，这些培养出来的人才在新的公司或新的岗位可以说又成为自己的竞争对手，这是很可怕的。
他们很熟悉公司的一些管理方法，也了解公司整个的业务运作流程，甚至他们与公司的许多客户都有良好的关系，他们的跳槽有可能就是一个复制过程，使得原公司只有经过重新调整，才能求得竞争的胜利。
而这造成的损失不仅仅是人员成本的增加，还有经营风险的加大。
据我所知，这个跳槽的店长及员工，并不是公司核心人员，只是业务能力比较强的销售能手，可能造成的经营上的损失有限。
发生这种事情原因是多方面的，并且每个公司都会有不同。
人员薪金、工作环境、人员心情、个人发展等均是造成人员流动的原因。
我不会对此事做任何的个人评价，只是许多同行推测，这个事件很可能是因为他们公司改变了薪酬考核制度，造成工资落差很大，员工不愿意接受的情况下所做出的抵抗行为。
当然，这些员工在新的岗位上是否能求得同样的发展，那就要看其与新公司文化融合的情况了。
人员管理有方法没有绝招
做好人员管理，请问星际是从哪些方面来进行的这在防止人员恶性流动上有什么作用？
人员管理是很难把握的事情，我认为“以人为本”的管理思想很重要，人员的选拔、人员的培训、人员的分工等工作，需要公司制定一个标准，在这套标准之下，员工实行起来就有的放矢。
例如在人员选择方面，员工以往的信誉、学习能力以及主观能动性都是必须注意的方面。
在管理上，星际店面人员的选拔是由店长自身完成的，公司会给予专卖店部门经理及每个店长相应的岗位津贴，以此来鼓励店面的管理者根据自身需求来选拔和解雇自己所管的员工。
其他像大客户部和分销部门的人员选拔都是在总经理的指导下完成招聘工作的，这些岗位特殊，要求的专业性能力比较高，这种选拔是为以后公司管理人员做储备的，所以总经理参与不可缺少。
有了这种前期的把关，后期的培养工作也就可以顺利展开，而在这种管理之下，员工有了成就感，就不会轻易跳槽了。
正如上面所提到的，商务、会计等内务人员流动性很少，星际这些岗位工作人员的工龄都在6年以上，这与他们的工作环境和收入的设定有关，当然人本关怀也是不可缺少，这些岗位人员的稳定性，往往使后勤支持工作得到保障，因为他们熟悉业务流程，可以高效率的支持前方的销售工作。
在星际，公司还制定了每季度20%的未位淘汰制度，允许在这个范围内的人员流动是可取的。
而这也激励着员工工作热情，当然在具体执行上，公司还是会从实际情况出发，做出相关决策的。
20%的淘汰率也许太高了，可能容易引起不稳定，您是如何想的？
这个比例后来证实确实有点高，但我一直强调我们会从实际出发再做考量。
员工跳槽这是很正常的事情，但是恶性的跳槽则是不可取的。
星际通过严格的人员管理，虽然无法杜绝跳槽事件发生，但可以防止这种恶性跳槽的事情。
在我看来，一个员工在一个公司呆满四年，如果选择离开是可取的。
一般来说，有了四年的专业工作经验，他们都可独挡一面了，这个时候，他们选择的去向就有很多，可以去厂商做产品经理或业务经理，也可以到其他渠道公司当某类产品操盘手，以在新岗位上求得更大发展。
而如果其还呆在原有公司，相信一方面他可学的东西在他看来会越来越少，发展空间似乎也受限，受制于此种思想，他们工作很可能会产生惰性。
并且四年的积累，他们有了自己的固定客户群，市场开拓能力必然会有所停滞，这对公司和个人都是不好的，选择离开是最佳的。
这样也可以防止员工因呆得时间过久，积累了太多的人气而导致集成跳槽。
网络公司人员管理方法与技巧
在软件行业，大部分经理们都希望自己率领的团队能像军队一样具有铁的纪律性。
在一次敏捷培训中，我们与众多来自国内软件公司的项目经理们讨论了敏捷，以及他们现在各自的开发方法和问题。
闲谈中，一位学员冒出一句，“开发团队应该像军队，不仅要整体阵法严密，而且每个兵都要纪律分明。
”这次培训主要是介绍敏捷的技术实践，比如测试驱动开发、持续集成、用户故事等，该学员认为这些敏捷实践不仅可以提高员工的技战术，还可以塑造团队成员的纪律性。
如果这些敏捷实践在日常开发中都能落在实处，势必将提高团队成员的“战斗素养”和“战术素养”。
一言以蔽之，相较于其他软件开发模式，敏捷方法对团队成员的纪律性提出了更高的要求，鼓励团队成员成长为项目经理心中的“合格军人”。
其实，抛开敏捷方法，哪一种软件开发方法又何尝不强调团队成员的纪律性计划驱动的传统型开发方法给软件过程制定了严格的计划书和检验标准，希望能提高团队的纪律性。
它们的出发点是对的，但因为缺少了具体的技术实践导致计划书并不能匹配团队的真实状态；
检验标准大多是着眼于与最终交付软件无关的中间文档，这些都使得成员在工作中对项目开发的约束力感受不深。
比如，很多项目里面的规范说明书、WBS表和甘特图都画得非常详细，但大多数时候这些东西与项目真实情况的落差太大，很难指导督促成员的日常开发工作。
而且，这些文档与需要交付的软件产品的关联性不强，也很难能让成员和其他人通过这些文档建立对软件交付的信心。
长期看到团队的表现与计划的不相符，项目经理们往往会感叹团队的纪律性不行。
那么，为什么说敏捷方法能相对一定有效地提升团队成员的纪律性呢我们先来看看纪律的定义。
纪律
一般来说，纪律有三种基本涵义：
1.纪律是指惩罚；
2.纪律是指通过施加外部约束达到纠正行为目的的手段；
3.纪律是指对自身行为起作用的内在约束力。
这三层意思概括了纪律的基本内涵，同时也反映出良好纪律的形成过程是一个由外在的强迫纪律逐步过渡到内在自律的过程。
从纪律的含义来看，达到自律是最终的目标，也是施加外部约束的目的所在。
通过奖惩来达到一定的纪律性，比如程序员开发过程中的bug率等等，这是生活中最常见的一种形式。
这种方法因为检查的结果与具体生产过程差得太远，而且评判标准还是比较粗放，所以应该是最低级的方式。
施加外部约束，比如检查列表，指导产品的具体生产，可以评判成员的各个环节是否符合标准，应该算中级方式。
只有自律，真正让成员把纪律的观念贯穿在生产的每个环节，主动改进，从而改善生产。
而这，也是纪律性的高级方式。
对比这个标准，我们可以看到：
计划驱动型的软件方法学强调更多的是奖惩，也涉及到一些外部约束（代码复审等），这也是为什么它们在培养团队成员纪律性上难度比较大。
而敏捷方法，通过强调承诺，强调每个成员都是“理性人”的事实，借助于成员的自律性来达到严明的纪律性。
国内有一家业内非常有名的技术网站InfoQ，四月份在北京举行的QConBeijing就是由InfoQ主办。
除了有限的几位全职员工，大部分的中文编辑都是社区的活跃分子，他们走到一起，通过之间的承诺和信任维持着日常工作，也给全国技术爱好者传播国内外的业界最新新闻和技术。
撇开具体项目团队而言，这就是敏捷团队最好的写照。
但是，我们也应该看到，InfoQ类型的团队是可遇不可求的。
现实中，大部分的开发团队还是良莠不齐，项目经理们很难去完全授权给手下的员工。
为什么敏捷方法又能有效地提升成员纪律性呢答案在于敏捷方法不仅仅强调承诺，也包含了丰富的技术实践：
不仅给个人带来更短更频繁的反馈，也给团队和组织带来了多层次较全面的反馈。
而反馈的频繁程度，则是外部约束发挥作用的重要基础，也即提升纪律性的重要手段。
戴明环（PDCA）
我们来看看被认为是组织或团队改进或解决质量问题的基本准则的戴明环。
戴明环（PDCA）是由美国质量管理博士戴明在20世纪50年代提出，PDCA是英语单词Plan（计划）、Do（执行）、Check（检查）和Action（行动）的第一个字母，PDCA循环按照“计划－执行－检查－行动”的顺序进行，并且循环不止地进行下去，是一个立体多层级的螺旋式的演化过程。
PDCA循环最开始是用在质量管理领域，但实际上它是有效进行任何一项工作的合乎逻辑的工作程序，是放之四海而皆准的指导性原则。
下面我们就用它来说明外部约束对纪律养成是如何影响。
PDCA循环里面的Action是一个循环的关键，对Check的结果进行处理，成功的经验加以肯定并适当推广、标准化；
失败的教训加以总结，未解决的问题放到下一个PDCA循环里，但它必须以上一环节的Check结果为基础。
如果Check不到位，不能具体到实际工作，Action的正确性和出发依据就很值得商榷。
软件开发是一个以不确定性为主要特征，强调知识的活动。
为了采取的Action具有较高的正确几率，更需要强调开发过程的Check比较频繁、具体，不断给团队提出直接的反馈，这样才能减少不断累积的不确定性最后带来成不可控制的后果。
如此来看，短而频繁的反馈对外来约束真正施加到个人的效果是非常重要的。
PDCA循环还有一个特点是多层级性：
各层级质量管理都有一个PDCA循环，形成一个大环套小环，一环扣一环，互相制约，互为补充的有机整体。
软件开发通常会把个人、团队和组织都牵扯进来：
个人完成功能的开发，团队完成软件的开发，组织负责完成客户需求的完成。
传统的软件开发方法更多的是强调团队、组织层级的计划、图表等文档，关注于团队与组织层级的反馈。
对于真正创造产品质量的日常开发环节，则缺少必要的检查和反馈。
与之相反，支撑敏捷方法的敏捷实践，就从“个人－团队－组织”的几个层面都提供了相应的反馈：
低层次的反馈，为上一层次的反馈提供了依据，同时也作为上一层次反馈的落实和具体。
敏捷实践
下面，我们从“个人－团队－组织”的不同层次分别选取几个突出实践简要解释它们是如何提供频繁、直接的反馈。
个人层级
测试驱动开发能给开发人员提供最直接也是最快捷的反馈：
先写测试，再用最简单的方式实现，再重构代码以符合简单设计的原则。
如此短间隔的反馈能很快地告诉开发人员刚才增加的代码是否破坏了已有的功能。
而且，已完成testcase的列表能很清晰地告诉其他人开发任务的完成情况。
对比着用户故事的验收条件，开发人员很容易评估剩余的工作量，并不至于破坏已有的功能。
团队层级
敏捷实践中的持续集成，强调尽可能快尽可能频繁地提交代码，与系统的其他部分进行集成。
在提交新代码之前，必须保证本地的构建过程是成功无误的。
谁提交代码使得持续集成服务器构建失败，必须立即停下手中的活，负责修复构建直到成功。
下班之前必须要保证持续集成服务器上的集成构建状态是成功的。
这样，开发人员和团队很容易检查新功能与其他模块的集成，另外也把未来的集成风险降到最低。
组织层级
用户故事是开发团队与客户之间讨论需求的基础。
用户故事必须对客户有真实可见的业务价值，并且必须包含对该需求完成的验收条件。
用户故事作为业务分析人员、测试人员、项目经理与客户一起确定的用户需求，具有经过验证的确切性。
开发人员开发故事之前，必须和业务分析人员、测试人员沟通理解需求；
开发完故事之后，必须要由业务分析人员与测试人员根据验收条件进行验收。
组织和客户之间可以针对达成共识的故事列表来分析项目状态，从而验证或者修改项目计划。
上面只是从“个人－团队－组织”的层次分别挑出了测试驱动开发、持续集成，以及用户故事的实践阐述了敏捷实践如何在不同的层次提供频繁的反馈，一孔窥豹，还有其他若干实践在这里就不再赘述。
总之，敏捷众多的实践就像组成了一张全面立体的安全网，时时刻刻从各个角度给项目成员、团队，以及组织提供短周期的反馈，帮助团队成员不仅感受到开发过程中的同伴约束，而且也可以感受到来自整个团队的约束，甚至是来自组织之间的约束。
这些外来约束也像是缠绕在个人周围的催化剂，纠正或改善个人的行为，达到提升个人的纪律性。
实际团队
经过几天魔鬼般的技术实践培训，我们在第三天给学员们安排了全天的模拟项目演练。
在演练中，由学员自行组织自己的团队：
选出自己的团队名称和口号、推选出项目经理、各自分配开发任务，所有人都信心满满。
在刚开始接触开发任务的时候，他们还是有一些不好的习惯，这时候，我们鼓励他们把前几天学到的敏捷实践都用起来。
于是就出现了这样的形式：
当结对中的一人先写实现，而不是先写测试时，另一个人会指出问题，然后重新使用测试驱动的方式；
在提交代码时，会有培训讲师监督着他们按照正确的方式来提交；
开发用户故事，要求开发人员必须跟分析人员沟通清楚细节，验收故事时，开发人员必须与分析人员和“现场客户”同时参与验收......虽然有些磕磕碰碰，但整体上团队还是有条不紊地进行下去，而且每个人只需要关注自己手头的那部分工作，也易于让他们把事情做得正确。
到了下午，随着学员对技术和业务理解的加深，他们也开始自觉地维护起开发过程，使其保持顺畅。
开发过程中，结对的两人激烈地讨论实现的方法，达成一致后又一起开怀大笑；
碰上了问题，主动招手找业务分析师询问需求细节，如果业务分析师也弄不清楚，再找现场客户来解答，直到三方都满意；
多人开发遇上了冲突，主动找到对方，商量沟通解决方案，实在不行，就找项目经理进行沟通协调；
当有人提交了代码使得持续集成服务器构建失败，所有人会善意地提醒犯错的人，督促他们修复；
谁遇上了技术问题，有人听见了他们的讨论就会自发上前提供自己的信息；
项目经理因为团队自组织也就从繁杂的管理工作里面脱身而出，饶有兴趣地与开发人员一起结对干起了开发的活......整个团队像一列火车一样，前轮带动后轮，后轮推动前轮，井然有序，毫不停歇地往前行进。
最后，我们作为模拟客户参加了这个团队的showcase会议，惊讶地看到这个团队的士气和活力，以及他们完成的工作。
特别是他们表现出来的团队集体感，让人会以为他们是一个磨合很久的团队。
项目经理还在为没有完成更多的工作任务觉得惋惜，但对于“如果给更多时间，是否有信心这个团队可以更好地完成更多的任务”这一问题，他表达了明确的认同。
然后再问“为什么”，他说，这个团队的士气和纪律让他刮目相看，目前完成任务的质量让他对未来的任务充满信心。
最后问“愿意率领这样的团队么”，答案是“为什么不”
论属下管理方法和技巧
所谓属下管理可以表述为：
管理的本质是激励，引导属下去实现预定目标，故而把属下看作管理对象，运用各种激励手段，调动和充分发挥属下的积极性和创造性，以增强企业活力。
具体的说，就是要求管理者给属下充分的自主权，各尽所能，自由发挥，出色完成本职工作；
管理者必须尊重属下的人格和要求，积极为属下创造参与民主管理的环境，不要求属下所作完全与自已一致，也不能苛求属下的工作都百分之百的正确，但必须保证属下为企业利益而尽职尽责，最
升级会员 