请允许我荣幸地带领各位进行一场“办公室巡猎”,可以这么说。在今天的旅程中,我们将穿梭于计算机领域的走廊,寻找广泛存在但难以捉摸的不良经理行为学,或者用通俗的说法,坏经理。他们将很难被发现,因为在某种意义上,我们是在寻找所有生物中最难以捉摸的生物:我们自己。也就是说,我们中的许多人很可能与我们将要遇到的各种类型的坏经理有一些共同的特点。我还要补充一点,这些特点是我们不愿承认自己拥有的。
为了帮助您应对这种令人不安的镜中审视,我准备了这份识别坏经理的实地指南。我希望您发现它在识别您自己和您的上级(如果适用)身上的坏经理时很有用。但首先,让我们了解一些背景信息。
所有坏经理都是经理行为学科目的成员。它们是组织食物链中的顶级掠食者1和资源消耗者。经理科目由三个不同的属组成:好经理(bono managerium)、坏经理(mal managerium)和庸才经理(mediocris managerium)。
坏经理的活动范围不受限制。它们存在于财富500强公司、私营企业、政府和非营利组织中。他们可以管理软件需求、开发和测试运营,或监督服务台和呼叫中心。不良经理行为学存在于每个行业和每个应用领域,并且可以随意迁移。软件/IT行业似乎是它们最喜欢的栖息地。至于为什么,无人知晓。
在接下来的指南中,您将看到每个物种的通用名称和学名、识别它的最佳方法(定义特征),以及遇到它时正确的处理方式2。在某些情况下,该物种非常危险,最好的行动方案是逃跑。
识别。 在做出决定之前,对数据(通常是无意义的)有着永不满足的渴望。有时,对数据的这种渴望根植于对更多信息的真正需求,但更多时候,这种渴望只是一种转移注意力的策略,用于让敌人或竞争对手保持距离,让数据驱动型经理的下属忙于无意义的工作,或避免做出有意义的决定。
例如,考虑这样一种情况:您被要求对一个联网应用程序进行性能分析。在模拟和实际负载下运行测试后,您提出“它不会过度增加网络压力”的观点。数据驱动型经理回应说:“这是你的观点,给我更多的事实数据!” 您进行了更多测试,它们证实了您的结论。但这对于数据驱动型经理来说永远不够,因为每次您带来所需的数据时,他们都会要求更多。
处理。 数据驱动型经理可能会让人感到沮丧,因为每次您认为自己已经满足了他们对信息的渴望时,他们都想要更多。在与不良经理行为学 indicium 打交道时,要坚持不懈。从某种意义上说,正如他们试图耗尽您一样,您也要尝试用数据来耗尽他们。当然,索要数据比获取数据消耗的精力要少,如果数据驱动型经理并没有真正查看数据,您可能无法获胜。但是,如果这些经理是诚实的,那么最终您可能会满足他们的需求,或者在尝试的过程中让他们感到疲惫。
在刚才描述的情况下,例如,您可以询问经理:“确切地说,您需要什么数据?” 如果您得到明确的答案,那就太好了。如果您得到不确定的答案,那么您可能是在被搪塞。
识别。 过分干预他人的细节;坚持要求不断报告您的活动。对他们的下属进行无休止的纠缠和吹毛求疵。
为了说明这一点,不良经理行为学 minimus 会给软件设计师设计方案,而不是让设计师实际进行设计活动。
处理。 直接对抗可能会导致不良经理行为学 minimus 暂时停止其特征行为。
在前面的例子中,您必须询问微观管理者:“你想自己做设计,还是让我来做?” 然而,从长远来看,微观管理者不太可能改变。不断用数据和报告来使不良经理行为学 minimus 超负荷运转,可以提供足够的掩护,以便完成真正的工作。
识别。 无法做出艰难的决定,表现出不知所措或能力不足。在所有情况下,这种行为都使不良经理行为学 incertus 显得软弱。
例如,当被要求在两个硬件平台之间进行选择时,无论提供什么信息,不良经理行为学 incertus 都会犹豫不决。
处理。 不良经理行为学 incertus 必须由上级管理层识别或自我识别,并将其剔除。否则,您可以尝试通过提出探究性问题来调和这位经理。您还可以通过重新调整和帮助阐明组织愿景来提供经理的指南针。如果一切都失败了,那就逃跑吧。
在前面的例子中,您可以询问有关两个竞争平台的性能特征的具体问题,以突出它们之间的差异。您还可以询问公司战略、成本或战略联盟是否暗示了其中一个硬件平台。
识别。 行为混乱;尝试这个想法和那个想法;从一个问题跑到另一个问题,没有重点。例如,不良经理行为学 abrumpo capitas pullus 似乎毫无理由地在一种架构或平台与另一种架构或平台之间来回切换。观察无头苍蝇式表现的人自己也会感到困惑和士气低落。
处理。 必须让这些经理意识到他们是无头的。也许一位密友可以告诉他们。也许他们可以自己意识到这一点。但是,如果无头苍蝇型经理没有醒悟过来,那么组织(至少是那位经理)注定要失败,唯一的解决办法是让上级管理层想办法让这只鸡摆脱痛苦,或者您逃跑。
也许您可以记录下前面例子中草率决定的顺序,以显示它看起来有多么荒谬。
识别。 一位不准备面对坏消息的经理。相反,不良经理行为学 invertabrae 会派一名下属去背黑锅,或者过于迁就——千方百计地想让每个人都高兴。但结果通常是谁都不高兴。
假设您的项目已被取消,需要解雇您的两名团队成员。不良经理行为学 invertabrae 回避这种令人不快的责任,即使您“只是”技术主管,也让您去解雇他们。
处理。 没脊梁骨型经理必须由您带入现实,您必须避免通过中间人进行沟通。但是,正如没脊梁骨型经理害怕做出决定一样,他们在捍卫自己不做决定的能力方面也表现出极大的凶猛。因此,在没脊梁骨的问题上接近不良经理行为学 invertabrae 时,要格外谨慎。
在示例中,您必须提醒您的老板,您是一名技术主管,而不是经理——处理人事问题是经理的工作。然而,没脊梁骨型经理可能会反击,对您强硬,只是为了避免不得不进行裁员。
识别。 优柔寡断、无法下定决心的经理。通常看起来像是在对抗,但实际上,他们是在与自己搏斗。不良经理行为学 pendulus 可能会被误认为是不良经理行为学 incertus。不同之处在于,前者在任何一天都认为他们已经做出了决定,但后来又会自我怀疑(让他们的朋友和敌人都眼花缭乱)。后者根本无法做出任何决定。
例如,有一天,不良经理行为学 pendulus 在接到一个特别愉快的电话后,决定选择软件供应商 A。几天后,由于不良经理行为学 pendulus 在一份行业期刊上读到一篇热情洋溢的报道,供应商 A 被供应商 B 取代。但一周后,在受到供应商 A 的午餐款待后,不良经理行为学 pendulus 再次反悔。
处理。 与该属的大多数物种一样,您需要正面与这些坏经理对质,并迫使他们认识到自己的摇摆不定。您可以通过提出引导到正确答案的问题来做到这一点。
因此,在示例中,您可以准备一份包含供应商 A 和供应商 B 优缺点的功能列表,并将其提交给不良经理行为学 pendulus。保存经理对此回应的“证据”,这样如果不良经理行为学 pendulus 稍后反悔,您可以出示之前的分析并迫使他们给出理由,并最终做出决定。
使坏经理的正确识别和处理变得复杂的是,存在许多混合型。如果您遇到混合型个体,那么您必须使用此处概述的与当时表现出的特征行为相对应的应对技巧。因此,您必须密切关注坏经理的行为,即使您已经暂时处理了这种情况。坏经理是足智多谋的生物,他们可能会采用同胞物种的任何不良行为,或者调整现有行为以求生存。
我希望您喜欢这份简略的坏经理观察和处理指南。一份包含所有物种的完整指南,包括艺术渲染图,即将面世3。
菲利普·拉普兰特是宾夕法尼亚州立大学大峡谷研究生院软件工程副教授。他的研究兴趣包括实时和嵌入式系统、图像处理和软件需求工程。他撰写了大量论文、20本书,并共同创办了《实时成像》杂志。他编辑了 CRC Press 图像处理系列,并担任四种期刊的编辑委员会成员。拉普兰特获得了史蒂文斯理工学院计算机科学学士学位、电气工程工程硕士学位和计算机科学博士学位,以及科罗拉多大学的工商管理硕士学位。他是 IEEE 的高级会员、 和国际光学工程学会 (SPIE) 的会员,以及宾夕法尼亚州的注册专业工程师。
最初发表于 Queue 第 3 卷,第 4 期—
在 数字图书馆 中评论本文
凯瑟琳·海耶斯,大卫·马龙 - 质疑评估非加密哈希函数的标准
虽然加密和非加密哈希函数无处不在,但在它们的设计方式上似乎存在差距。存在许多由各种安全需求驱动的加密哈希标准,但在非加密方面,存在一定程度的民间传说,尽管哈希函数历史悠久,但尚未得到充分探索。虽然针对真实世界数据集的均匀分布很有意义,但当面对具有特定模式的数据集时,这可能是一个挑战。
妮可·福斯格伦,埃里尼·卡利亚姆瓦库,艾比·诺达,米凯拉·格雷勒,布莱恩·豪克,玛格丽特-安妮·斯托里 - DevEx 行动
随着领导者寻求在财政紧缩和人工智能等变革性技术的背景下优化软件交付,DevEx(开发者体验)在许多软件组织中越来越受到关注。技术领导者凭直觉接受良好的开发者体验能够实现更有效的软件交付和开发者幸福感。然而,在许多组织中,旨在改进 DevEx 的拟议举措和投资难以获得支持,因为业务利益相关者质疑改进的价值主张。
若昂·瓦拉让,安东尼奥·特里戈,米格尔·阿尔梅达 - 低代码开发生产力
本文旨在通过展示使用基于代码、低代码和极限低代码技术进行的实验室实验结果来研究生产力差异,从而为该主题提供新的见解。低代码技术已清楚地显示出更高的生产力水平,为低代码在短期/中期内主导软件开发主流提供了强有力的论据。本文报告了程序和协议、结果、局限性和未来研究机会。
伊瓦尔·雅各布森,阿里斯泰尔·科克伯恩 - 用例至关重要
虽然软件行业是一个快节奏且令人兴奋的世界,其中不断开发新的工具、技术和技巧来服务于商业和社会,但它也很健忘。在其快速前进的过程中,它容易受到时尚潮流的影响,并且可能会忘记或忽略一些针对其面临的一些永恒问题的成熟解决方案。用例于 1986 年首次引入,后来得到普及,就是这些成熟的解决方案之一。