处理无法看到用户无法立即看到的改进中的价值的管理

#1 楼

您实际上是在谈论技术债务。隐喻可能会帮助您的经理。我经常将软件技术债务的影响与在肮脏的厨房里做饭的效果进行比较。如果水槽，柜台和火炉上堆满了脏盘子，并且地板上有垃圾，则用餐时间将更长。但是，准备下一顿饭的最快方法是在混乱中工作。清洁厨房并保持厨房清洁将延迟下一餐，但会改善所有后续餐点的送餐时间。就像饭厅里的饥饿的人看不到凌乱的厨房，也不知道为什么要在开始做饭之前清理一下，您的管理人员也看不到代码中的混乱。您需要向他们展示乱七八糟的东西，或者表明由于乱七八糟造成的质量问题和延误。

也许您还可以谈论紧迫的任务和重要的任务。如果重要任务没有完成，那么紧急任务将花费更长的时间，并且花费更多。

#2 楼

您偶然发现了一些困扰着职业生涯各地程序员的东西：该代码需要重构，那里存在体系结构问题，该模块变得难以维护，等等。但是，由于您组织的当前文化，您将被迫专注于只能产生直接可见收益的工作。

它再次成为经典的《冰山秘密》。秘诀在于，就像一座冰山在水下90％一样，任何开发项目中的大多数也是如此：90％的工作将对最终用户完全不可见。该代码将对最终用户产生影响，但是管理人员无法确定为什么您花了六个小时来重构维护/发布和自动引用调用，而他们看不到任何差异并且一切正常。

有一些事实可以解决。


管理，除非他们自己是程序员，否则他们将不了解Iceberg Secret。
这是无知而不是恶意的问题。 CEO想要一个好的产品-他只是不了解成为一个好的产品的一切。
CEO（和您的直接老板）并不愚蠢-研究并准备一些事实和一些具体数据，说明为什么应该花时间在此以及其他冰山问题上。

别忘了-您是公司的一个或多个男人。不是代码人。您正在为对成功或失败有既得利益的公司开发该产品-您的项目和项目建议应反映这一点。向公司和产品展示您的热情，向您的老板和首席执行官证明您的知识，并向您的老板和首席执行官证明他们应该信任您，并说他们需要工作。向他们展示如何为底线做出贡献-是通过为产品增加价值（更多的人购买副本）还是通过节省时间（在产品出现故障时减少生气的客户）。

#3 楼

你不知道。

我认为这个问题以及所有类似的问题有点死胡同。您不能“说服”任何人。如果他们还没有意识到或正在调查这种事情，那么他们很可能不会放弃。而且没有任何数据能够使他们信服。变革必须来自内部。您可以将一匹马带到水里，但不能让他喝水。就像，嘿，我们“必须”升级到Apple引入的这个新框架。不要让不使用ARC成为您的发展蓝图。没有选择。迁移到ARC是唯一的方法。

#4 楼

我之前在这里回答过类似的问题，因此可以将其视为重复。基本上，您不会获得批准来进行“重构工作”。编写代码清理器的方法是遵循童子军的规则：始终在离开代码清理器时离开代码清理器，而不是在抵达时。

就像还清真实债务一样，这似乎是一项无法克服的任务（或清理一栋凌乱的房子）。诀窍是逐步改善它，直到您开始看到“清洁岛”为止。一旦有了强大的动力，团队中的其他开发人员将开始注意到并最终为这项任务做出贡献。

我建议阅读“叔叔”鲍勃·马丁（Bob Martin）的“清洁编码器”。编写好的代码是您工作的一部分。您不需要征求您的许可就可以做。

#5 楼

与其他此类问题一样，您需要提供管理层可以理解的数字。数字显示了通过实施这些改进将节省多少时间，将发生多少次“随机怪异崩溃”，等等。使他们相信崩溃对最终用户是可见的，并且为防止崩溃所做的一切都对企业有利。 br />
您还可以尝试在自己的时间（即工作时间以外）实施这些改进，然后向管理人员展示其好处。只有在管理层不了解您要传达的内容和/或他们不想为您分配时间甚至尝试时，我才会这样做。

祝您好运！

#6 楼

提出业务案例

工程师建议经常被忽略的原因很多。解决几乎所有原因的最佳方法是提出为什么要这样做的商业案例。经典的成本/收益分析。这不仅引起了有说服力的争论，而且还给您的老板带来了更高的回报。


前期成本是多少？
持续成本是多少？ ？
，预计节省的金钱/时间是多少？它们来自何处？
需要多长时间才能看到ROI？

做业务案例时，您应该始终用数据来支持您的论点。


当前开发需要花费多少时间来解决或消除这些问题？
您收到多少与该将消除或缓解的问题相关的用户投诉？ br />还有其他好处吗？

将数字对齐并使其成为一个粗略但简单的等式。

注意：如果要实现一个学术上的好主意过于昂贵，请不要感到惊讶。

#7 楼

这种更改属于重构类别。敏捷的方法是，您应该将充足的重构时间整合到您估计的每个故事中，这正是原因。除了工程师之外，没有人会明白为什么要这样做，没关系，确定正确编码的方法不是您的工作，而是您的。

所以下次您要做很多工作为此，请确保这些更改是其中的一部分。如果您要提供估算值，请确保将估算值增加30％以便进行重构；如果您不提供估算值，则只需将重构作为工作的一部分即可。

这可能会使您变慢-好吧，不是，这不是看待它的方法，看待它的方法是，您当前的速度是一种错觉，本质上是您沿着链条上行的谎言，由于这项工作，您实际上应该慢一点您知道需要做的事情。

如果不使用混凝土作为基础，您可能可以更快地建造房屋-这些房屋对客户来说看起来不错，但是-甚至-如果客户看不到基础的需要，则构建者需要。 （这实际上是一个有趣的相似之处，因为事实证明，构建者并不总是做他们知道应该做的事情，因此我们需要通过法律来迫使他们去做，即使我们面对同样的问题，也没有这样的法律来管理软件开发往往会做出错误的决定...）

#8 楼

您提到您很幸运，您的经理和CEO都是程序员。因此，他们可能确实了解什么是技术债务。

您应该通过尝试根据事实解决情况来处理这种情况，这意味着您很可能最终不会做出想要的技术改进（事实可能会令人讨厌）。

您的工作是确保他们了解偿还您承担的任何技术债务的成本和收益。他们的工作是确定资源的最佳用途是偿还资源还是做其他事情。

就像不参与代码的人很难看到改进“隐藏”的东西的好处一样，程序员可能很难看到可见代码更改的好处。

很好，如果您的管理层可以向您解释为什么可见功能比付技术债更值得您花时间，那真是太好了，但实际上无论如何，您都无法做出决定。因此，向您解释这一点对您的业务没有多大帮助，只会让您开心。从某种意义上说，坚持要求他们这样做是不信任他们完成工作。如果您不喜欢他们进行微观管理，那么您应该了解。

因此，只要您让他们知道所有技术债务的状况以及忽略的成本和收益，与还清相比，您已经完成了自己的工作。除非您真的不信任管理层去做，否则您将遇到更大的问题，这将是另一个完全要解决的问题。

#9 楼

也许这不是答案，而是基于我犯过的错误的回应。也与我在这里阅读的一些哲学观点有出入。


不要与程序员最懂的信念相违背。
说实话。继续进行重构，但不要为了自己的目的撒谎和填充估算值。
您没有代码。不要从事未经领导认可的工作。
你可能在某些事情上是对的；您可能错了...但是您应该做自己应该做的事情。

但是一定要听从改善情况的出色建议。

#10 楼

您显然是为一个尖头的老板（PHB）工作。他不再编程了，如果曾经的话，如果他这样做了，他可能还算不上什么好（尽管他确实喜欢使用“ const正确性”和“分段错误”之类的词组，以便这些家伙知道他已经赢得了自己的荣誉。 ）-这就是他被挑选出来进行管理的方式。

CEO（实际上有莫霍克族）喜欢PHB，因为PHB具有功能。他自豪地为每个冲刺展示了一个新的复选框（略有对齐，带有模糊的标签），一个闪闪发光的图标（在Citrix上为8位颜色，但在任何环境下均无法使用）和一种形式（由于比赛条件而随机崩溃）在基于C的定制xml变体中实现的本地数据库中，开发团队中没有人敢于接触，因为它是10年前一位守卫的开发传奇人物编写的，并且对具有5个字母名称的宏进行任何操作，无论他们需要5个字母还是不是）。

实际上是在做“工作位”的程序员（您知道会发生这种情况，在完成诸如白板上的画圈，大喊大叫以及吃掉微型Battenburgs之类的所有实际工作之后，就很不方便了）我们知道，在一个理智的系统中，仅花了10个人10天的时间就辛苦地砍掉这个未维护的丛林的工作，包括测试在内，大概需要一到两个工作日。但是要使系统正常运行可能需要6个月的真正努力，而几乎没有明显的外部回报。

PHB知道在6个月内，通过挂钩或通过骗子，他可以在应用程序中获得三十或四十个新功能，以使销售人员（鉴于他们实际销售的产品必须是魔术师）可以用来诱惑新的购买和升级。

PHB的应有之举：如果没有这些复选框和表格，销售可能会停滞不前或下降，竞争对手可能会获得市场份额，这可能比其他选择更糟糕。

我得出的结论是，走出泥潭的唯一出路是在一个新的初创公司中工作，一些人与您分享您应该如何完成软件的愿景，然后顽固地坚持这一理念（我还在努力到达那里！）

#11 楼

还有其他答案未提及的其他隐藏成本。即，好的工程师倾向于离开所描述的环境类型。最终，任何有野心或重构能力的人都离开了公司，然后事情将会以非常糟糕的方式出现，可能无法解决。不幸的是，您不能不自夸地告诉您的经理（“我是您最好的程序员之一”）和急躁的混蛋（“如果您不做我想做的事情我就会离开”）。但是，切记在退出面试中提及它，以确保您不会被重新雇用。

#12 楼

你们是对是非，这就是为什么这些问题会长期存在并产生难感的原因。

上面明确说明了原因：管理层以金钱为中心；或更具体地说：收入。对于他们来说，有些成本很高但无法直接看到客户的东西并不会增加收入，所以这是一个坏计划。

您的愿景也是对的：对客户有利，但从长远来看。与短期计划相比，您的行为将来可能会产生更大的收入。

您不是经理，您也不是直接负责收入的人（我想当然是）。因此，您将他们的问题混在一起（这就是管理的感觉），而您并没有专注于自己的工作：进一步扩展软件。出于通讯错误。你们都想要同一件事，但是您的短期决策却有所不同。都是因为开发人员与管理人员的前景不同。

您如何解决此问题？在许多问题上，您可以很好地交流和理解。

要以一种稳定的，面向未来的方法来解决此问题，就需要达成共识：衡量旧代码中的错误修复成本。测量使用旧软件的时间以及使用新代码库的时间。

例如，要证明这一点，您可以做一件非常简单的事情：在版本控制中分支该软件。首先执行管理部门想要的操作，然后创建该功能。您可以这样做，但可以达成协议的是您有时间展示不同的方式。然后在新分支中执行相同的操作，但首先解决您要摆脱的问题。然后还要开发解决方案。

现在，您拥有相同的解决方案，但完全不同。从中创建一个案例，将解决方案彼此相邻，包括一些管理信息，例如稳定性，所需代码量和代码本身。

现在聚在一起喝咖啡，开始看看，不是在争论谁是对的，而是这两个方向对公司的影响。这将创建一个真正有用的会议，而不是更糟糕的讨论，因为这不会产生你们俩都需要的气氛。那不会使您的产品更好。

#13 楼

如果您有代码审查，请创建技术证明，指出应使用ARC改进代码并分配给经理。

说服他。向他解释一些您所做的类似技术增强及其对项目的好处的小例子。

#14 楼

您必须以管理层愿意购买的唯一方式来出售这些变更：

找到面向用户的功能，以至于引人注目以至于管理层只需要拥有它，但是如果没有一点点困难就不可能做到级别的代码改进。

#15 楼

确保公司将开发重点放在提供客户所认为的增值上是您老板的工作。有两种因素可以改变这种看法：


应客户要求交付货要花多长时间？
您会如愿以偿地交付吗？

大多数人宁愿说要花5个星期才能交付6个星期，而不是要花3个星期才能交付4个。使您可以更快地交付并提高可预测性。如果您花费大量时间进行错误修复，则可用于添加新功能的资源将减少。评估花费在修复代码上的资源数量以及功能部件的准确性。这种确定您当前代码（按照老板的哲学）是否花费过多的方法。

#16 楼

让我告诉您一个20亿美元的机会，由于管理层的惯性，差一点就落空了。

我们中的有些人倾听客户的声音，这意味着理解他的需求。他所要求的并不总是这样，但是如果您能够与客户进行对话，那么您最终将对他想要的东西达成共识。 （然后，他可以明确地开始要求它。）话虽如此，了解谁应该与客户进行对话很重要。通常，您需要业务开发人员以及一些主要设计师来完成。如果您有任何竞争，您可以期望客户也与他们进行这种对话。

同时，重要的是开发人员必须保持与自己领域的最新动态，因为这会导致竞争

在您的情况下，它将击败您。

在我们的情况下，我们有一个现有客户，并且有一个基于旧技术的有效产品，客户需要快速升级。他们真正需要的是一个完整的替代产品，但是我们公司的心态是，这将立即迫使我们进入竞争地位，而修改现有产品可以使我们的客户继续与我们合作，而无需法律上使其具有竞争力。我们的管理层认为他们拥有这个市场。问题在于他们不能跟上升级请求，因为现有产品结构不够灵活，无法升级。

客户变得不耐烦，开始与竞争者进行对话。我们失去了对该市场的“所有权”，失去了数十亿美元的收入。但是，一旦市场迫使我们进入竞争地位，管理层别无选择，只能倒闭或竞争。 （最终成为障碍的大多数人都被解雇了。）我们参与了竞争，并能够通过最细微的路线重新夺回业务。就我提到的收入来说，我们把生意还回来了。如果我们一开始就准备好适应客户的关注，就不会有任何真正的竞争。

我提供的要点是：始终保持领先地位在你的个人能力上。始终开发出灵活的产品，并且可以快速适应客户的需求。如果您为一家不这样认为的公司工作了太长时间，您将会枯萎，并且您的个人动力将会减弱。我已经看到了它的发生。

当您出于任何原因有改善产品的想法时，请问自己以下问题：-这就是我认为客户想要的吗？我能否根据客户的声音来验证我对产品​​开发的想法？我的公司有能力满足客户需求吗？如果是这样，怎么办？ -然后，您应该就您的产品开发建议说服力。

#17 楼

在所有领域和行业中，企业共同的语言是金钱。您描述的问题不是编程问题：这是业务问题。如果您想对业务主张做出适当回应，则需要以业务语言来构架。这意味着您必须能够提出包括所有成本和收益的替代项目计划。

您需要了解机会成本，ROI（投资回报率）和NPV（净现值）之类的东西。您不需要MBA才能做到这一点，但是您确实需要访问可能不可用的数据，例如人力成本，间接费用成本和潜在的收入。如果您可以明确地说，使用硬数字，一条路径将比另一条路径提供更多的价值，那么您将得到管理层的充分关注。

#18 楼

当我是一个很小的团队的新开发人员时，我在空闲时间做了很多这种改进。我很喜欢它;晚上和妻子坐在客厅里时，我会登录并尝试一些有趣的新技术。当我成为一名高级开发人员，然后成为一个更大的团队的经理时，我的空闲时间消失了。我们正花费额外的时间来完成功能和关键修复程序。即使大家都知道花时间在日常家务工作上，也很难证明是有道理的。降低成本，减少未来增长的成本，聘请有才华的开发团队等。如果这样做，您会遇到大麻烦。但是，他们可能需要的是计划。因为现在我猜测它们在“添加功能”方面有各种各样的计划，时间表，路线图，承诺和压力，这与开发人员团队的一厢情愿和开放性要求竞争。

您可以尝试的一件事就是制定书面计划。查看您是否可以将其与发行版绑定，或退出新功能的标准。要求“花一些时间来重做参考计数”的请求可能很难让老板批准，但是从现在起安排4周的5天时间段可能会更容易。但是，基本上，您基本上会看到新功能的计划和安排，请尝试模仿它，或在其中添加“引擎盖”部分。

首先，要求分配给此类东西5％的时间，然后逐渐建立自己的技术路线图优先级，并不断寻找合理的业务案例，ROI，风险水平等在他们每个人身上。很快，您甚至可以领会老板的挑战，因为您会很快发现比自己有更多时间去做的好主意。

祝你好运！

#19 楼

这就是为什么您的自动引用计数请求被拒绝的原因：



这不是一个改进。一旦您拥有比问候世界更大的东西，任何改变都将朝错误的方向发展。大量的重构都不会改变以下事实：如果您需要进行更改，那么它总是会朝错误的方向发展。诀窍是要知道您的更改何时足够重要，以至于仍值得承担引发新问题的风险。您的管理层已明确表示，如果最终用户看不到它，那就不值得冒险。

引用计数是完全疯狂的功能。您看到一些现有的知名大公司实现了某些功能，然后立即想到您需要相同的功能。好吧，您的代码库很可能与苹果使用的代码完全不同。引用计数可能无法正常工作，或者只是浪费时间。您应该找到一种不需要在代码中各处传播引用计数基元的方法。可能您的重新计价计划需要在代码库中进行数千次修改，而其中大多数修改都是不必要的。只是浪费时间和金钱。

您正在解决错误的问题。管理层通常知道系统中存在什么样的问题。刷新解决方案正在解决的一些无关的内存泄漏问题不是其中之一。关注于计算机处理内存的实际问题，而不是一些想象中的问题。

实施它花费的时间太长了。苹果公司比没有多少程序员和一些管理人员的微不足道的团队要大得多。他们只需付出代价就能做出重大改变。如果要花费几百万美元来实现某件事，那就是花生。如果小公司试图做同样的事情，他们将很快耗尽金钱。软件开发已经非常昂贵；增加不必要的成本将无济于事。一个不相关的功能（如内存管理）将打开闸门：批准后，一半的程序员希望实施自己的“改进”。这是永无止境的故事，公司可能会做一些有用的事情。

以下是您可以用来解决问题的一些步骤： >找出真正的问题是什么
开始做一些有用的事情
仔细计划您的时间使用方式
找出您的改进如何带来收益
仅选择带来收益的功能花费最多的钱
意识到软件开发的编程方面只是整个系统的一小部分-对其进行改进永远都不值得花时间