关于软件开发,你的老板不知道的 7 件事

一则或许对你有用的小广告

欢迎加入小哈的星球 ,你将获得:专属的项目实战 / 1v1 提问 / Java 学习路线 / 学习打卡 / 每月赠书 / 社群讨论

  • 新项目:《从零手撸:仿小红书(微服务架构)》 正在持续爆肝中,基于 Spring Cloud Alibaba + Spring Boot 3.x + JDK 17...点击查看项目介绍 ;
  • 《从零手撸:前后端分离博客项目(全栈开发)》 2 期已完结,演示链接: http://116.62.199.48/ ;

截止目前, 星球 内专栏累计输出 63w+ 字,讲解图 2808+ 张,还在持续爆肝中.. 后续还会上新更多项目,目标是将 Java 领域典型的项目都整一波,如秒杀系统, 在线商城, IM 即时通讯,权限管理,Spring Cloud Alibaba 微服务等等,已有 2200+ 小伙伴加入学习 ,欢迎点击围观

你的老板可能很棒。在我的编程生涯中,我当然遇到过一些很棒的老板,但即使是最棒的老板似乎也不总是“明白”。

事实上,我想说 大多数软件开发经理在涉及多个编程元素时都有些短视

因此,我整理了一份简短的清单,列出了我认为是编程中最容易被误解的一些方面,而您的老板、开发经理、大魔法师,或任何您称呼他或她的人可能并不……理解。

1.技术债务比其他任何事情都更能拖慢项目

在充满技术债务的代码库中工作就像试图在泥泞中奔跑。起初,当泥浆不是很软时,你可以直接穿过它。但是当它深入几英尺时,你几乎无法移动。

我最喜欢的作者之一, 《高效能人士的七个习惯》 一书的史蒂文·柯维 (Steven Covey) 将此称为“P/PC 平衡”或“生产与生产能力”。

管理人员和其他非技术人员似乎常常不明白,当你提高生产力但愿意牺牲质量时——从而招致技术债务 ——这就像杀鸡取卵。

当然,你可能会拧断鹅的脖子并威胁它,从鹅身上多拿几个蛋,但一段时间后,死鹅就会停止下蛋。

如果你的老板患有技术债务盲症并且不明白技术债务是如何让你放慢脚步的,请从他的书中翻一页,并按照 《高效能人士的七个习惯》 中提到的 P/PC 平衡来讨论技术债务。

大多数经理都读过这本经典的管理和自助书籍,因此您更有可能理解您的观点,而不是说因为代码库太糟糕而很难编写新功能。

2. 估计大多是公牛** t

软件开发中超过 2 小时时间窗口的估计大多是废话。

你知道这一点,我知道这一点,即使是你团队中可怜的项目经理也知道这一点——好吧,好吧,也许他不知道,但他现在应该知道了。

众所周知,软件开发中的任何事情都很难估算 ,因为您永远不会两次构建同一座桥。

每个软件项目,每个任务都是新的。每次您坐下来编写代码时,都会发生一些意想不到的新事情。

就是那样子。没有人应该为此负责。这不是你的错。这不是我的错。这不是任何人的错。它只是发生了。

然而,我们仍然像估计问题一样玩这个游戏。

“你认为构建客户登录页面需要多长时间,乔?”

“哦……嗯……” 从a**中拉出随机数。 “两天……哦等等——” 忘记加倍到 CYA 了 。 「——让那四天吧。」

“好吧,那我就放下五天。”

“是的,五天。”

如果你的老板仍然坚持估计,就像它们实际上很重要并且基于除了随机滚动 d20 之外的任何东西,你可能想引导他阅读我写的关于软件开发估计的文章之一。

另一个好的解决方案是 坚持将任务分解得足够小,以便所有估计都在四个小时以内。

经验告诉我,我们可以在估计需要不到半天的时间的事情上做得相当不错。超过这一点,我们就开始进入废话领域。

3. 可以正确或快速完成

匆匆忙忙的专业人士通常不是一个好主意。

我从 15 年多的代码编写中学到了这一点,所以我知道当我雇用某人做某事时, 如果我催促他们,他们很可能会按时完成,但结果会很糟糕。

不幸的是,我发现许多软件开发经理似乎仍然不理解这个普遍真理。不知何故,他们认为代码可以写得又快又好。

现在,请不要误会我的意思,也有一些例外。 有时您可以很快地写出好的代码 ,但更多的时候做错事情需要额外的时间。

同样不幸的是,大多数程序员在被告知要快速完成任务时,往往会采取牺牲质量的捷径来加快流程。

更不幸的是 ,这些“牛仔编码员”经常被誉为英雄 ,因为他们可以更快地完成工作,而且他们从不退缩或要求更多时间。

当然,这些“牛仔编码员”经常会留下一大堆技术债务,让其他人清理一团糟。

如果您正在与那种似乎不了解快速通常与良好之间存在相当大的权衡的开发经理打交道,您可能需要汇总一些统计数据,以显示 修复错误的成本比修复错误的成本高 得多。 这是为了防止他们。

组织越大,涉及的繁文缛节越多,最终因快速而不是正确地做事而付出的代价就越大。

(让我们不要忘记关于这个主题的经典书籍 《人月神话 》。)

4. 一些开发人员实际上可以生成少于 0 的代码

面对现实吧;我们都曾与实际上最终伤害团队而不是帮助他们的程序员一起工作。

软件开发领域的能力和技能水平存在巨大差异。

事实上,一些软件开发人员的工作非常糟糕,以至于他们编写的每一行代码实际上最终都会 花费公司 更多的时间和金钱。

这些类型的开发人员可能应该向公司付款,而不是相反。

这对您来说可能是显而易见的,但如果不是这样,您可能想知道为什么您的老板没有意识到 乔实际上是一个彻头彻尾的失败者 并且需要被解雇,因为他似乎与点石成金相反。 他接触到的一切都变成了垃圾。

如果你的老板似乎不明白你的团队中有些人实际上比死重还要糟糕,你该怎么办?

好吧,大多数软件开发人员都害怕像个告密者一样被人举报,也不想举报同事是个懒惰、无能的**——我完全理解。

但是……无论如何你都必须这样做。这是正确的。 如果有人真的在伤害团队,让你的经理知道绝对是你的工作。

我知道处在这种情况下会很不舒服,但 如果你不报告明显的无能,那么你也是无能的 。你是个无能的帮凶,我就让你戴红字。

只要确保措辞得体,并留下一些提示,这将导致更多的调查。

你可能会这样说:

“嘿,我不喜欢做这种事,但我觉得如果我处在你的位置,我会想知道是否有人直接阻碍了球队。所以我觉得我有责任告诉你我一直在观察的事情。

现在,这些只是我的观察,所以一定要与其他团队成员和你自己的经验核实一下,但是……”

或者,如果您更喜欢不太微妙的方法:

“嘿!乔是个傻瓜**。他写代码很烂,而且速度很慢。事实上,他唯一的可取之处就是他的速度 很慢,因为他只能以蜗牛的速度做事。你绝对应该 s**t-can 他。

5. 更好的设备是您可以做出的最便宜的生产力投资之一

我讨厌程序员告诉我他们的吝啬鬼老板不让他们有第二台显示器,或者他们使用的是五年前的电脑。

老实说,我不明白为什么有些软件开发经理 没有意识到,花 2,000 美元为程序员购买好的硬件,而您每年要支付 80,000 美元以上的员工费用,这实际上是一项很好的——不, 很棒的 ——投资。

严重地。这是一种真正让我生气的狗屎!

每当程序员告诉我工作中的这种情况时,我通常会告诉他们 另谋高就 ,因为这简直是愚蠢之举,而且恐怕也无药可救。 (接下来,我会告诉你我对这个主题的真实感受。)

这里没有太多要说的,除了这个:

好的设备可能每天只为软件开发人员节省一个小时,或者使开发人员每天的工作效率提高一个小时。即使它只是这个数量的一半,它也很可能会增加很多。

(我个人认为每个软件开发人员至少应该拥有 其中之一 。)

一年大约有 250 个工作日,我们说的可能是 250 x 每小时 35 美元 = 8,750 美元。即使你将其削减一半或四分之一, 这显然仍然是一项不错的投资。

如果你的老板不明白这一点,老实说我认为你无能为力。如果你真的喜欢你的工作,如果你不先辞职,那就为你自己的设备而努力( 我已经做过好几次了 )。

6. 新技术通常没有你想象的那么危险

没有什么比提及 .NET 版本的最新、最强大的 JavaScript 框架更能让软件开发经理心生恐惧的了。

现在,回到过去,这曾经是一种有效的恐惧。

过去,软件供应商每年大约只发布新版本的框架或补丁,因此 ,一个错误的代价可能相当高。

过去,大多数源代码都被锁在一个没有人可以访问它的金库中,所以如果那家公司停止支持它,你就没有桨了。

但今天,情况有点不同。

如今,有时每天都会对框架进行修补,而且大多数流行的框架都是开源的,因此风险并不那么大。

当然,你可以“在流血的边缘流血”,但这种情况不再那么常见了,而且伤口似乎更像是剪纸的线条,而不是被大刀砍伤。

如果您的编程经理仍然生活在 1980 年,您可能想指出 事情发生了怎样的变化,以及今天留在框架或库的旧版本上比升级更危险。

提到安全漏洞的恐惧策略也总是很好的接触。

7. 业务分析师和项目经理不做事

我知道我会因为这个而受到批评,但我不在乎。我在这里说实话,我称之为我所看到的。

显然,有一些优秀的业务分析师和项目经理 ——我可能会把它扩展到项目经理——但老实说,他们中的大多数人一文不值。

在某个时间和地点,这些角色是必要的。 (虽然我不知道那是什么时候。也许当每个人都在进行瀑布式开发并且开发人员不直接与客户交谈并且我们需要有人来创建一个巨大的甘特图时。)

但是,在大多数情况下, 它们不再是必需的。

软件开发人员应该直接与客户交谈并自己弄清楚需求。我们真的不应该再需要业务分析师了。

这是一个有缺陷的角色,因为他们恰好做了软件开发人员应该能够做的事情的一半,而另一半不能做。

项目经理似乎只是妨碍并搞砸了一切。

我知道他们的意思是好的,但在敏捷世界中没有项目经理的位置,那么他们做什么呢?他们四处走动,试图显得重要;试图弄清楚他们能做什么,但他们最终却妨碍了所有人。

许多软件开发经理仍然停留在过去,这些角色更相关,或者他们一直在听财富 500 强咨询公司的吹笛人告诉他们,他们需要所有这些额外的超高薪顾问人员来填补这些角色。

如果您的经理不太“明白”,唯一真正的解决办法是 继续进行一些敏捷教育

我不建议直接告诉你的老板,业务分析师和项目经理是在浪费氧气——这可能不会那么顺利——但是,相反,我会专注于 明确定义敏捷团队应该如何运作 以及需要哪些角色.

很明显,在真正的敏捷环境中没有业务分析师和项目经理的位置,他们可能更适合担任 Scrum 主管 或产品负责人。

主动

当然,我在这里所说的一些内容是以开玩笑的方式呈现的,但实际上,软件开发经理和软件开发人员 软件开发 的理解往往存在脱节

我敢肯定,软件开发经理会抱怨软件开发人员不了解确保每个人都能拿到薪水所需的业务方面和会议日程安排的挑战——但那是另一回事了。

无论如何,重点是: 这不是“我们对他们”的情况 ,而只是沟通不畅的问题,通常可以通过适当的沟通解决——至少在某种程度上是这样。

采取主动而不是对抗的方法往往是解决这些问题的最佳方法。

我已经概述了一些处理这些误解的技巧,但是你发现什么是最有效的,我遗漏了哪些误解?

请在下方发表评论,让我知道。

相关文章