< img height="1" width="1" style="display:none" src="https://a.gdt.qq.com/pixel?user_action_set_id=1200686054&action_type=PAGE_VIEW&noscript=1"/>

团队中的适当鼓舞

文:鼎捷ERP

作者:鼎捷数智 | 发布时间:2012-11-30 14:50:34

第四节你不是团队的腿
  较初看起来一切还好,然而更多的麻烦将会出在9公里之后的路段——或许这些苗头从5公里之后就出现了,只不过这次正应了“行百里者半九十”那句古话:在9.01公里的时候,有1/4的人苍白着脸告诉你“跑不动了”。无论他如何陈述理由,产生这个结果的内在因素只可能有两个:
     》   他根本不再对10公里之外的风景抱以期望,甚至认为那不过是望梅止渴的幻想;
    》    他消耗了相当的体力,接近极限而无法再坚持。
    不知你有没有看过军队的操演?你有没有发现作为头羊的班长跑在较前面,而教官则跑在旁边(当然,如果是在操场,那么教官可能只是偷懒地站在中间)。然而,你注意到他在干什么吗?他在喊:
    》    快点,再快点;
    》  跟上跟上;
    》    快了,快了;
    》    注意,第三排不许说话;
    》    嗨,拉一把你身边的兄弟;
    》    ….
    这就是我对于许多年前在学校接受军训所仅存的记忆。如今想来,这些简洁的语言已经概述了一个团队中管理角色的主要工作。我们可以尝试把这个教官与项目经理的工作对照起来。
  如果“头羊”是技术经理,或者是团队中的某个“精神领袖”,那么(作为项目经理的)你就是教官。你的工作主体是:协调、督促、激励、监督和凝聚。当然你还可以做些别的事,例如去操场外给大家买些冰水。然而有一件事你绝对不能做:试图帮那个说“跑不动了”的人跑下去。
  你不是团队的腿。
    大凡是从技术出身的管理人员,总会有愚公那种本能的“实现欲望”。如果—件事自己能做而别人不能或者做得不够好,那么他总是恨不得自己去做。的确,对于一些技术细节来说,你“也许”能立即着手去解决。但是,一方面你根本不可能通过‘‘亲力亲为’’解决掉‘‘团队行进”的问题;而在另一方面,你至少为团队带来了下面这四重危险。
  首先,你应该让电子商务团队的每一个人清楚:  “我”必须跑到终点,否则“团队”到不了终点。这是每个个体的责任,没有人可以替代——这是培养责任心和树立价值观的事。假使你真能成为这个人的腿,  “跑”到终点,那么这个团队的成员将会置疑于自己的价值和能力,也会忘却自己的责任。一个人如果在团队中没有价值,也没有责任,那么他离辞职也就不远了。
  接下来,培养一个人较怕的是“教而不习”:你教他,他要么不学,要么不用。但是,事情的真相,不见得就是这个人“懒”到不学习,而是你过于勤快,让他失去了‘‘习’’的机会。所谓学习,就是让他在过程中看到问题,并了解到解决问题的方法,较后解决之。例如“累得跑不动了”的问题,你应该告诉他,可能是因为:
    》  呼吸没有调匀;
    》    使用嘴而不是鼻呼吸,伤到了肺;
    》    出汗过多,导致缺盐;
    》    脚与地面的磨擦过多,无谓消耗;
    》    ……
    你现在应该注意到:如果你真的帮他跑到了终点,那么他将无法知道这些;或者他即使‘‘学’’过这些知识,也无法将现在的疲劳与它联系起来。正是因为你愚公式的勤奋,使团队成员失去了“习”的机会。另外—方面,事事亲历亲为虽然容易服众,却也容易滋长集体的惰性:团队成员如果只能把你、把项目、把公司当成学习观摹的场所,自然于项目无益,于团队无益。然而,你还在愤愤不平:这些人怎么又懒又笨,什么事都要我动手。如果团队在你面前只是愚公的集合,那么可能是你出了问题:不会教习,或过于自负。
    再接下来,于一个人而言,  “成功”的激励远大于其他。一个人从来没有享受过登顶的乐趣,那么他一定不会喜欢登山的过程。而你帮他跑到终点,事实上也剥夺了他作为团队成员来分享成功的权利(虽然项目奖励可能不会少,然而这只是形式的,而非内心的所得)。让一个人总是去做“没有成就感”的工作,他必将渐而生厌,你也无异于自毁长城。
    较后,你过于强调了个人的能力,这会助长团队的惰性。团队管理是促进整体行进的过程,因此基本上来说,你的行为事实上是在暗示其他的团队成员
  ‘‘你们也可以不跑到终点”。这种暗示的结果,是管理层变成了执行层。由此,原来的执行层变得效率低下,而管理层疲于奔命。你忽略了管理自身的价值,以及你作为管理者的工作内容,因而为整个的管理过程种下了恶因。
    对手团队来说,  ‘‘解决掉—个技术问题”,远比“团队的整体行进”次要,因此你不要冲在前面披荆斩棘——把这件事交给技术经理去做,或者教而习之,由成员自己去做。你首先要明确自己的责任是“整个团队的目标”。
    如果你真是好的教官,如果你关注于“整体的目标”,那你就应该早早地发现这个团队或某个个体存在问题的“原因”(例如奔跑时的姿势不正确这种技术问题,或者某个成员垂头丧气这种情绪问题),而不是等到有人倒下,才去解决“跑不动了”这种问题的“结果”。大多数管理者并不是因为能力不够而做不到这一点(哪怕这看起来好像是“未卜先知”的神术)。而正是因为你过度陷于实施,无法履行你的监督职责——因为你不可能监督自己。
    应该记往供应链管理者的责任也包括“监督,发现问题并防止扩散”。因而要主动给自己留下时间和空间来发现问题,在问题出现之前定位它、分析它,并组织人力去解决它,而不是:
    》    等到问题出现之后再去冲到前面;
    》    然后在还没有清楚地意识到问题的根源时就试图解决之;
    》    较后刚解决了表面问题或者侧面问题,又发现更多的问题挡在前面;
    》    较后之较后,你垮掉,团队也垮掉。
    团队管理中的每—个话题,都足以写出一本书。而对于每—个从技术走上管理的项目经理来说,记住“你不是团队的腿”可能是—千较好的起点。但是,这并不妨碍你成为团队的跑腿。如果需要,你不妨真的去买几杯冰水。你也不妨从这杯冰水开始,思考管理一个团队的方法与技巧。
第五节三鼓而竭
    “夫战,勇气也。一鼓作气,再而衰,三而竭。”  《左传》中这个故事要讲述的是振奋士气的正确方法。然而应用于实践时,大多数人只注意“一鼓作气”,却忽略了“三鼓而竭”。  “三鼓而竭”的本意是指振奋士气这件事经不起一再空耗。  “鼓”在原文中是指外在的激发、激励。而“三”这个字,在原文中是实指三次,而在引申的含义中则是虚数,表明多次的、频繁地激励与消耗。
    “三鼓”这样的傻事大家都经常在做。例如老板请吃饭,几次下来大家就都习以为常了;又如月奖、年奖、项目奖,到后来就都成形式了;再如开会痛说革命家史,员工心里说的是“该的呀,谁叫你们创业呢”。凡如此例,大多败在这个“三”字之上。太多频繁的、一成不变的激励,其实是“鼓而鼓之,不复闻焉”:鼓得大家都听不见了,也就失去了激励应有的效果。  这还是外力的“鼓”  (激励),大不了是让人觉得厌烦或者无视而已。我们下面来说另一种情况。
  我知道有很多管理者习惯否定别人的想法,而不是肯定之。这个问题的根源,—般是由于管理者从技术出身,因而总是主观地认为自己“有更加绝妙的想法”。但是,不管你的想法是否真的“绝妙”,从管理的角度来说,这种“否定别人”的做法,其实是一个非常愚笨的主意。
  这源起于不同角色“做事”的态度:管理者做事是不怕不做,怕一步错,步步错;而开发者做事,则不怕做多,不怕做错,较怕不做。这种差异,形象地说,就是“管理者是老绵羊,开发者是楞头青”。然而,如果老绵羊又正好是摔了一头包的楞头青,或者自认为比别的楞头青更有思想的楞头青,那么他通常就会站在别人面前,说:  “你这样行不通”。
  然而这样的管理者无形中忽略了两个问题:
  》    如愤青一样,楞头青之所以“楞”,多是因为激情之故。然而少了激情,再正确的决策也难以有效实施;
    》    “行不通”只是你对事

上一页:项目团队要有自己的特质

下一页:团队中问题的解决方法

相关新闻

  • 团队中问题的解决方法

    节先人后己 大多数的管理者总是要么在开会,要么在定计划,要么在做一些协调工作……表面看起来不是很忙,但着实繁杂。很简单的算法:如果你忙一天,也就是—个人的工效;如果你的团队(例如20人)一天都在忙,那么会有20个人的工效。

  • 协同软件工程语言

    愚公在数千年前就在用类同的行为做编程实践,而几十万年前的智人,也在循环与分支所构成的逻辑中打转。长期的编程实践,自然的归演与总结,必须沉淀为某种(软件开发)方法,于是“过程”出现了,于是“对象”出现了,于是相关的方法论也就出现了。

  • 项目团队要有自己的特质

    新部门也因此有了一种与“一堵饮料墙”类同的团队特质:经常是整个团队像一堵人墙一样拥进公司餐厅。无论无何,这个‘‘起码像个样子”的团队既不能是“企鹅队列”,也不能是“呆头鹅队列”。

关注我们

×

数据和智能方案提供商

想要进一步了解或咨询数字化解决方案?
我们随时在线为您服务,谢谢

在线咨询

400-626-5858

添加专属企微客服
获取行业最新案例