为无为，则无不治。
——老子
公元两千多年前，我们脚下的这片土地，处在一个人人向往的太平盛世，以至于现在我们这些后人，都时时引之以为荣。（更有些高高在上的人，不知脸皮为何物地吹嘘当世可以为它的翻版。）
这段我们向往的历史，即是“文景之治”。其治理策略更为人所熟知：“无为而至”，“轻徭薄赋”，“与民休息”。（说白了，就是什么也不干?）
很不幸，作为开发人员，似乎我们很难碰到像刘恒或刘启那样的老板。正好相反，项目经理或者主管们往往会在我们沉静在思考中时，像苍蝇一样嗡嗡地飞来采集进度，不懂技术的，只是一个会说话的监视探头；略知技术的，往往会提出一些干扰性大于操作性的建议；即使有真的精通技术的，除了提了建议炫耀自己的实力，更多的是打击开发人员并养成其依赖性……
结果……
我常常听到下面的人抱怨：我们领导烦死了，除了监工啥也不干!
同样有趣的是，我也常常听到管理者抱怨：下面这些员工啊，素质低，爱偷懒，不把工作当回事，只图完成任务交差而已！
软件开发归根到底是以人为主的行业，人性化是无法忽略的。我们渴望在软件开发工作中抛弃官本位，拒绝垂直命令，解放自己，同时也解放管理者。
SCURM的一个原则——拜托！请您不要管太多
SCRUM提醒经理们，你的任务是支持开发人员，扫清障碍。而不是传统的命令和控制！
习惯了指挥的人不明白：支持？只是支持？不会吧？那种自我膨胀和虚荣的感觉都没了？我一定要控制，要发号施令！再说不这样也不行啊，不催项目就会延期。
让我们对比一下大家常见的真实世界和SCRUM提倡的情景吧！看看究竟那种方式更有成效。
场景一
初步制定了一个开发周期计划以后，开发组和项目经理一起开会讨论计划，表述了计划日期和原因以后。
真实的世界
开发组长（小心翼翼地）：“您看着计划如何，同意否？”
项目经理：“恩，还行。不过我觉得这个功能看起来没有那么难吧，你们估算的时间怎么这么长？”
开发组长: “（陈述原因）……”
项目经理：“哎…大家加加班，辛苦点嘛…有什么要求尽管可以提嘛…（画饼。通常提了要求也得不到满足）
后果：开发组不得不听从上头意见加班，满肚子怨气，责任心进一步降低了。开发组长觉得自己的评估遭到否决，自己的话语权被剥夺，还要为了缩短的时间不断催促成员。
SCRUM的世界——开发组是交付成果的主要负责人！
开发组长（小心翼翼地）：您同意否？
项目经理：你们觉得该计划没问题？能按时按质量完成？
开发组长：是的。
项目经理：那就按照你们的做。
后果：开发组长对自己有了信心，开发组成员感觉到了自己的话语权（虽然是很有限的），即使加班，也是对自己的计划负责。
场景二
开发组例行会议，项目经理也来凑热闹。
真实的世界
会议开始，开发组长打开一个word或者什么文档，然后请每个人轮流汇报进度。
会议进行中，每个人轮流汇报进度…项目经理突然就汇报中的某问题提问，开发人员回答解释….
会议趋于尾声，开发组长请项目经理发言
项目经理：“恩，我觉得…你们应该注意…，你们还要…还要…
会后结局：开发组认为自己被干涉，上面管的太多太琐碎。
SCRUM的世界——只有开发组自己才能对自己负责！
项目经理：“我不应该出现！这个会议不是为了向我汇报成果展示绩效, 而是为了解决开发过程中的问题，应该由他们讨论。”
会后结局：效率高的会议！组员不只是为了秀自己的进度给上级，更关键的是提出了自己的问题和困惑并得到其他成员的支持去解决问题.
场景三
交付成果审查，项目经理发现了一个问题。
真实的世界
项目经理：“你们这里有一个漏洞，我知道一个解决方案，你们应该…”
结果：开发人员的信心被打击，并趋向与养成对经理审核的依赖性。
SCRUM的世界——项目经理不应该干涉过多，发现问题，解决问题都应该留给开发组自己！
项目经理：“恩，非常好！不过好像没有考虑到一个问题，(但是我不会说出来)，我相信你们自己会发现，请仔细审查一下。”
结果：开发组自己发现并解决问题，面子被照顾，并且日后会更加认真。同时对项目经理的能力表示赞同。
场景四
不干涉不行 ——重回老路？
实施SCRUM有一段时间后，项目经理发现开发组的工作效率和工作热情都提高了！一切似乎进行的不错，开发组长和组成员都开始从心里对项目，产品有了较高的负责心，不再只是单纯为了对付上面的任务了。可是有一天，项目经理的上司，公司的高层来了。高层要求审视所有进度和发布成果。在项目经理完成展示后，高层很不高兴。
高层：“这个项目进度不好！客户要求很急！你应该保证进度！”
项目经理：“可是我们正在实行SCRUM，自我负责的开发团队已经建立。开发人员工作热情很高而且他们已经很努力了！这个进度已经是建立在大家尽全力工作基础上了…”
高层:“这个不是我需要关心的！开发那边对他们自己负责，你也需要对你任务负责！你的任务就是保证按时完成！”
真实的世界
项目经理明白，SCRUM没有饭碗重要，于是他找到开发组。
项目经理：“从今天开始，每天早晨我参加你们的会议！你们每个人都要及时汇报进度和问题，上面催的很急！”
开发组长：“可是我们已经很努力了…您的意思是…？”
项目经理：“不行，我不放心你们，我一定要全程参与”
结局：项目经理越来越多地参与各个组的会议，甚至高级经理也在关键问题上参加开发组的会议来催进度。管理模式回到了垂直的老路上。开发人员又开启了消极的一面，因为完成任务应付上面的质疑成了的工作动力（如果还算是动力的话）。有人开始跳槽…有人开始怠工……项目的结果是仍然延期。
SCRUM的世界——每个经理都要明白命令和压迫是有害的。
项目经理有义务保护下属并提醒高层，SCRUM的原则是自我组织，自我负责，这一条不能放弃。即使不断给到下级压力，也未必能取得满意结果。
并非什么也不做！勿以小事而不为
无为不是毫无所为，除了发号施令，经理们还有很多事情需要做，概言之，即扫清一切开发中的障碍，保护项目成员的工作不受任何负面影响。这包括协调资源，激励士气，优化流程，创建好的环境和氛围等等，一切的一切 – 甚至是给每个开发人员一个座椅的靠垫。
让每个人都有参与和负责的权利，并尽全力保障他们的这种权利，这就是一个身处SCRUM中的经理该做的事。
我相信不少人人都遇到过垂直管理的问题，作为被管理者，每个人都渴望平等（哪怕表面的），被尊重（哪怕偶尔的），有归属感（哪怕仅仅两三年）。在软件行业，SCRUM确实是提高员工工作热情的一个已经被实际证明的模式。但是不得不说，SCRUM是需要一定的企业文化的！而在中国实行真实的SCRUM，我个人认为，真的非常难。
SCRUM要求管理者，尤其是中层管理者，对下属提供相当的支持和保护，作为下层员工，获取自由的同时，则要承担相当的责任，并从心底认可这一点！可是现在，彼此信任是如此艰难。上对下，更多的是粗暴压榨，而不是对其激励和负责。反之，下对上所谓的“尊重”，更多是迫于对权势的恐惧，而不是打心里的钦佩。上下级之间朋友般信任的关系，如同白娘子要遇许仙，千年修一回。
作为知识型组织的软件公司，专家权力无疑是会被员工从心底认可的。我觉得，每个PM都应该想想，下属们对你的尊重，其中有多少来自你的“专家权力”？以此类推，你对自己的上级，也有多少发自内心的钦佩？
来源：教育简点
声明：本站部分文章及图片转载于互联网，内容版权归原作者所有，如本站任何资料有侵权请您尽早请联系jinwei@zod.com.cn进行处理,非常感谢！