zoukankan      html  css  js  c++  java
  • 《新下级学》第八章第十一节(本章完)——网状结构

    8.11网状结构

    随着经营模式日益复杂、组织结构日益灵活,已经有一部分传统的一上多下树状结构被网状结构替代。网状结构中,除了一上多下,也可以有一下多上,或者没有明显的上下级关系,三者混合存在。这种结构中的生态又如何呢?

    最正规的网状结构就是矩阵式管理,常见于大型公司。很多小公司虽然没有明确实行矩阵式管理,但老板会临时找个人,给他个跨部门的任务,可能还配个“项目经理”之类的头衔,实质也是简易的矩阵式管理。

    网状结构对大老板的领导水平、中层干部的协作能力和全体人员的工作积极性有很高要求。一旦搞不好,就会陷入“诸侯——浪人”模式。该模式意味着资源竞争无序、遮蔽效应恶化。下面先看资源竞争。

    部门经理是诸侯,他们手里有人,以及大多数资源的管理权。项目经理是浪人,他们有老板的临时任命,可能还有项目专用的少数资源。浪人需要诸侯的支持,但诸侯也有自己的任务,不是专门给浪人当后勤的。设想这种并不罕见的情况:老板在项目会议上对浪人说“你的任务很重要,谁不配合你,我骂死他”,又在部门会议上对诸侯说“你的部门要管好,保质保量完成工作”。老板真正的想法是“我全都要”,但结果只能是各人自扫门前雪。多数情况下,浪人处于弱势,因为员工考核是部门经理决定的,员工本质上听诸侯的,浪人难以越过诸侯调动员工和设备。

    那么浪人会不会真的向老板告状呢?偶尔几次是可以的。频繁告状也是可以的,如果他足够傻。频繁告状的后果,一个是和诸侯彻底闹翻,一个是在老板面前显得自己只会告状。再说了,老板诚心支持的话,为什么不直接把资源拨过来?说到底还是这个任务不够优先嘛!这样一想,弱势浪人就丧气了。强势浪人会珍惜每次告状的机会,拳拳到肉一击必杀,告一状顶一万状。

    如果任务比较简单,经过一两次协调后,也能解决。但若任务复杂多变,要走一步看一步的,弱势浪人就非常不利了。久病尚且无孝子,总麻烦诸侯,人家也给脸色啊。有时,浪人甚至会运用“人情黑市”,但只是杯水车薪,并使工作量更加不可控,老板还以为浪人不专心工作,真是两头受气啊!

    再来看遮蔽效应。对部门员工来说,他是被派来协助浪人的临时下级。虽然他和浪人之间是临时组合,不一定有鸡犬式信任关系,但也依然被浪人所遮蔽。干得再好,功劳是浪人的,自己恐怕分不到什么好处。另一方面,他本来是部门的人,由诸侯考核,在浪人这干得怎么样没多大意义。所以他很容易产生“凑活”心理。

    总之,网状结构搞不好的话,会让诸侯、浪人共同争夺资源,又使浪人因遮蔽效应无法拥有得力团队。

    那么,为什么不直接让诸侯兼任浪人呢?因为这样也有很多问题:任务需要特殊技能而找不到合适的诸侯,大老板想借机发掘新人,等等。实际上,确实也有很多人是先做好项目经理,才提拔为部门经理的。项目经理简直就是部门经理的黄浦军校。

    这时,遮蔽效应的危害又显示出来了。大老板难以了解浪人手下那支“乌合之众”的详情,让他怎么评估浪人的能力呢?项目做好做不好,有没有运气成分呢?

    可能有人会说:多做几个项目,不就排除运气成分了吗?我说这是理科书呆子思维。项目和项目不一样,要做多少个才能放心呢?员工难道没有自己的追求、像小白鼠一样听任大老板拿自己做实验?有可能做完两个项目就跟大老板拜拜了。作为大老板,不去想怎么尽量准确地观察,而是用下级的热血、年华给自己的平庸、愚蠢当燃料?草菅人命!

    换个角度。假设浪人离职了,公司要重做这个项目,如果知道当时浪人团队的详情,岂不很有帮助?又或者公司要优化基层人员结构,浪人团队的详情也同样是有用的信息。

    第九章同样会探讨此问题的解决方案。

  • 相关阅读:
    高效、稳定开发功能的一些心得
    记录一些遗忘的程序基础知识
    Linux NFS
    Nginx Upstream模块
    Redis命令总结
    手动搭建redis集群(3台)
    laravel使用总结(二)
    InnoDB体系架构总结(二)
    laravel 设计思想简单了解
    Redis原理及集群相关知识
  • 原文地址:https://www.cnblogs.com/XXJX/p/12991883.html
Copyright © 2011-2022 走看看