组认为自己被干涉，上面管的太多太琐碎。
SCRUM的世界 ---- 只有开发组自己才能对自己负责！=>
项目经理：“我不应该出现！！这个会议不是为了向我汇报成果展示绩效, 而是为了解决开发过程中的问题，应该由他们自由讨论。”
会后结局：高效的会议！组员不只是为了秀自己的进度给上级，更关键的是提出了自己的问题和困惑并得到其他成员的支持去解决问题。


   场景三：交付成果审查，项目经理发现了一个问题
真实的世界 =>
项目经理：“你们这里有一个漏洞，我知道一个解决方案，你们应该#$#$@#...”
结果：开发人员的信心被打击，并趋向与养成对经理审核的依赖性
SCRUM的世界 --项目经理不应该干涉过多，发现问题，解决问题都应该留给开发组自己！ =>
项目经理：“恩，非常好！不过好像没有考虑到一个问题，(但是我不会说出来)，我相信你们自己会发现，请仔细审查一下。”
结果：开发组自己发现并解决问题，面子被照顾，并且日后会更加认真。同时对项目经理的专业能力表示赞同。


   场景四：不干涉不行 - 重回老路？？

   实施SCRUM有一段时间后，项目经理发现开发组的工作效率和工作热情都提高了！一切似乎进行的不错，开发组长和组成员都开始从心里对项目，产品有了较高的负责心，不再只是单纯为了对付上面的任务了。可是有一天，项目经理的上司，公司的高级经理来了。
   高级经理要求审视所有进度和发布成果。在项目经理完成展示后，高级经理很不高兴。
高级经理：“这个项目进度不好！客户要求很急！你应该保证进度！”
项目经理：“可是我们正在实行SCRUM，自我负责的开发团队已经建立。开发人员工作热情很高而且他们已经很努力了！这个进度已经是建立在大家尽全力工作基础上了…”
高级经理:“这个不是我需要关心的！开发那边对他们自己负责，你也需要对你任务负责！你的任务就是保证按时完成！”
真实的世界=>
项目经理明白，SCRUM没有饭碗重要，于是他找到开发组
项目经理：“从今天开始，每天早晨我必须参加你们的会议！你们每个人都要及时汇报进度和问题，上面催的很急！”
开发组长：“可是我们已经很努力了…您的意思是…？”
项目经理：“不行，我不放心你们，我必须亲自跟踪监控”
结局：项目经理越来越多地参与各个组的会议，甚至高级经理也在关键问题上参加开发组的会议来催促进度。管理模式回到了垂直的老路上。开发人员又开启了消极的一面，因为完成任务应付上面的质疑成了唯一的工作动力（如果还算是动力的话）。有人开始跳槽…有人开始怠工…项目最终仍然延期。
SCRUM的世界 – 每个经理都必须明白命令和压迫是有害的=>
项目经理有义务保护下属并提醒高级经理，SCRUM的原则是自我组织，自我负责 - 这一条不能放弃。即使不断压迫下级，也未必能取得满意结果。

3. 并非什么也不做！勿以小事而不为

   无为不是毫无所为，除了发号施令，经理们还有很多事情需要做，概言之，即扫清一切开发中的障碍，保护项目成员的工作不受任何负面影响。这包括协调资源，激励士气，优化流程，创建好的环境和氛围等等，一切的一切 - 甚至是给每个开发人员一个座椅的靠垫。

   让每个人都有参与和负责的权利，并尽全力保障他们的这种权利，这就是一个身处SCRUM中的经理该做的事。

   我相信不少人人都遇到过垂直管理的问题，作为被领导者，每个人都渴望平等（哪怕表面的），被尊重（哪怕偶尔的），有归属感（哪怕仅仅两三年）。在软件行业，SCRUM确实是提高员工工作热情的一个已经被实际证明有效的模式。但是不得不说，SCRUM是需要一定的企业文化的！！而在中国实行真正的SCRUM，我个人认为，真的非常难。SCRUM要求管理者，尤其是中层管理者，对下属提供相当的支持和保护，作为下层员工，获取自由的同时，则要承担相当的责任，并从心底认可这一点！

可是我们国人现在的社会中，彼此信任是如此艰难。上对下，更多的是粗暴压榨，而不是对其激励和负责。反之，下对上所谓的“尊重”，更多是迫于对权势的恐惧，而不是真正的钦佩。上下级之间朋友般信任的关系，如同白娘子要遇许仙，千年修一回。
   作为知识型组织的软件公司，专家权力无疑是最有效并最被员工从心底认可的。我觉得，每个PM都应该想想，下属们对你的尊重，其中有多少来自你的“专家权力”？

以此类推，你对自己的上级，也有多少发自内心的钦佩？

    项目经理胜任力免费测评PMQ上线啦！快来测测你排多少名吧~

    http://www.leadge.com/pmqhd/index.html