【修炼七】团队建设-尊重

知识型工作者只有让他们感到被尊重，被认可才能激发出他们的工作热情。制造业工厂监工式的管理方法，绝对量化的考核指标在知识型团队管理中将会失效，

这是管理人员面临的挑战，德鲁克也在《卓有成效的管理者》中对管理者和这种监工做了明确区分，其中的观点是监工是上司，但不是管理者。

       

       一个抱着积极、认真负责，打拼事业心态的员工做事的有效产出和机械完成任务的人员的有效产出是多么的不对等，这里不需要再列举各类研究结果。尊重是激励文化构建的基石，如果没有尊重，激励就是空中楼阁亦或是短暂的激情。本篇笔记重点谈谈在项目管理过程中对如何给予员工足够的尊重。

1、项目的意义

    成就感是让团队努力向前的最好激励方案，任何项目的成立都是有意义的，如果能够让整个项目团队时刻清晰的认识到自己是再做一件对部门、乃至对公司意义重大的事，则往往能够焕发出团队很强的战斗力。受到关注就会给人被看重感，人就感觉到要对事情付更多的责任。

    推荐策略：1）项目启动时，高层领导进行动员，宣传项目意义

                     2）项目中期，规划负责人/项目经理要能定期发出 一些 市场人员/客户对项目的 期望

                     3）项目结束后，高层领导要能够反馈项目获得的成绩

2、项目时间估算

   我个人比较推崇的估算方法是自下向上的估算（具体可以上篇文章：时间估算的三步曲），自下向上的估算能够给予项目组员一定的 发言权及主人翁感，并且能够调动大家责任心，通常大家愿意为自己的决定负责，但是如果是领导直接压下来的任务尤其比较紧急时，通常有些抵触。当然在自下向上的估算中，要有专家进行指导和把关，包括估算漏掉的哪些事情，项目组内例行需要消耗的时间等，并且针对”狮子大开口“的时间需要进行讨论，达成一致。

   在这种估算方法做出的项目计划下，如果项目最后出现了问题，尽管项目经理要承担直接责任，但是项目团队成员通常会比较自主的愿意与团队共度难关。因为决策是大家一起制定出来的。

    推荐策略：尽量使用自下向上+专家指导的方法进行估算，如果有人员到位或者估算周期的有限制，至少要保证关键人员的参与，而慎用自上向下的估算方法.

   

3、善用加班文化

     IT公司加班是件很自然的事情，如果哪家公司没有加班情况，反而会让人感觉不正常。做为项目经理应该首先理解，加班虽然是IT公司的普遍现象，但是确实是组员为了项目做出了额外的奉献，他们牺牲与家人团聚的时间，牺牲了休息时间，甚至影响了健康。这种行为值得我们尊重，我们要小心使用这项权力。

    1）不要动不动就抛出一句“ 这个今天搞不定，就打地铺解决”等，这种言论是对员工额外奉献的一个严重的漠视，而且带着很强的个人意愿

    2）时时保证项目的进展的透明性，可以通过周会，日报的形式在团队中发布。当遇到赶工时，跟当事人讲解当前团队面临的困难，总之，加班是个艰难的决定，是为了整个团队的绩效，不是项目经理的个人意愿

   3）任何加班时项目经理都应该尽量身先士卒带队

   4）在一些公共场合，尤其有上级领导在时，公开表扬那些为团队做出很多额外贡献的人

   5）绩效考核肯定以结果为导向，不能以加班多少论英雄，但要有其他措施安慰最辛苦的人

    推荐策略：加班是一种奉献精神，我们要小心使用，认真对待。不能简单的当做管理者的权力，轻言肆用，否则久之必招其离心。

4、开放沟通的团队氛围

    人都希望自己能够有发言权，能够对关心的事情产生影响。上至国家领导人的选举，下至日常的工作生活。如果发言权被长期压制，就会产生压抑和叛逆的心理。因此构建一个具有开放沟通的团队氛围则显得很重要。而往往言路开明后，项目经理总是能在一些讨论中，得到很多比预期更好的解决问题的方案。一个强权的管理者，容易获得一定程度上的执行力，但是容易被自己的盲点击败。而一个开明的管理者，往往能使用集体智慧，获得跟随者，更容易产生威望。

     推荐策略：1）项目沙盘等关键策略制定时，要全体项目参与讨论

                      2）项目经理鼓励大家发现问题，提问问题，对于好的措施，能够采纳执行

5、责任到户 VS 大锅饭

   从头到尾的 责任到户制应该是最理想的工作分配方式了，在这种分配方式下，团队成员有一块自己土地，通常愿意花更多的时间与精力去耕耘（例如：某个全新的模块），如果这个模块又是他一直想尝试的方面，那将会更加完美，我们有理由相信他将会在这里充满了激情。

   然而世界上总没有十全十美的事情及百分百通用的方案，尽管责任到户制如此之好，但是在某些项目上我们达成不了这样的期望。

   我所亲身经历过的两个版本就遇到了这样的状况。两个版本的共性是：在一个很大的系统上做覆盖面很大的，很多小点的修改（例如：更换所有UI系统），但是基于老系统的复杂性及历史问题，项目在中会遇到很多bug，各种各样，在bug没有查到原因之前并不好确定这个问题谁改动引发或是谁的责任，这种情况下责任到户制会出现失效。在面对系统这么多的bug时，项目经理很容易想到一种方法：“那就是给大家分配bug数，下指标，每天每人要解决3-4bug等”。两次项目经历中，项目经理确实都想到了这种方法，区别是前者实施了，后者被我阻止了。原因如下：

    1）团队组员容易产生不被尊重感，被当成解决问题的机器

   2）团队之间的协作会发生困难，而且过度强调这项指标，例如谁每天不修改完这个bug数，就要加班到10:00之类的，会导致部分组员开始取巧，每天争抢容易处理的bug

   3）没法发挥人的主动性，将团队目标和个人目标相背离

   这种情况下大锅饭的机制似乎更合适一些，如果团队没有达成目标则需要一起想办法或加班解决，而不是将这人归咎个某个人。

    推荐策略：在正常项目中尽量使用责任到户制，而对于一些特殊项目，则选用大锅饭制，没有一成不变的方案，具体情况具体变通。