Performance 您如何平衡业务流程变更与软件变更的挑战？

在我公认的年轻职业生涯中，我发现自己编写代码来支持古怪的业务规则和流程。不可避免地，这些更改总是出现在一些非常困难的代码库中，并导致许多问题。我的问题有几个部分：

虽然软件是企业让生活更轻松的工具，但作为开发人员，我们在什么时候建议改变业务流程，而不是将软件作为解决特定问题的“灵丹妙药”

作为开发人员，我们如何宣传对软件的某种程度的尊重，以及仅仅为了支持业务的怪癖而进行更改所涉及的困难

---

我知道这些业务流程的变化促进了我们的行业，但打个比方，我父亲会明白：哪一个更容易，熔化锤子来锻造螺丝刀来驱动螺丝，或者简单地使用钉子，因为你的锤子已经很棒了…？

我认为，质疑构建新解决方案以适应现有业务流程的成本效益，与调整业务流程以适应现有解决方案的成本效益，是有价值的。然而，在现实中，我还没有看到企业考虑这个角度。

考虑到这一点，我认为您可以做的下一件最好的事情是预测业务未来可能要求的特定更改，并开发您的解决方案，使其能够轻松适应这些更改。

您可以查看

高效的七个习惯 人

，因为有一种感觉，您需要开发一个足够大的影响力范围，以尝试改变业务流程

你最好的办法是表明你在工作中非常胜任，并且努力与业务方面的人发展关系，这样你就可以在工作之外轻松地坐下来讨论相关的业务流程

这是一个缓慢的过程，但如果你试图跑得太快，业务就会倒退，像虫子一样压扁你。如果你读

异端时代

例如，你会看到一些公司在做出改变时过于成功，而公司却将其摧毁

---

目前，您最好的选择是尽可能地进行更改，使软件具有更强的适应性，这样，如果流程发生变化，您就可以轻松地适应新规则。

不幸的是，这完全取决于具体情况

即使在商业和软件方面有着丰富的经验，这仍然是一个复杂的问题

关于您的具体问题：

只要你看到他们。重要的是以建设性的方式提出你的建议。也使用与业务相关的术语（ROI、NPV等）。以及寻找辅助利益（）。因此，如果软件更改真的不能缓解业务问题，成本很高，并且修复业务流程可以节省大量辅助成本，那么您将提出一个完全不同的场景，而不仅仅是说“我们不能这样做，因为它成本太高”

该软件归公司所有——它并不比公司拥有的任何其他具有类似价值的软件更受尊敬

---

在你能做任何事情之前，你最好退后一步，试着了解业务。如果他们通过调整流程来应对变化，这是一件好事。只有当他们几年来一成不变的时候，你才能忘记他们仍然是一家公司。但是，您需要确保您正在响应的更改不会对上游或下游业务流程产生负面影响。业务部门通常不会进行这种检查。但是，当一切都下地狱的时候，你知道他们会责怪谁，对吧？通过这样做，你可以避免这些问题，并宣扬“更好的方法”。不这样做是一个永远沮丧的处方

在你考虑编纂之前，先了解他们的业务

至于机械师： 我总是让我的团队编写“通用软件”。一些业务部门可能需要一种方法来捕获表单并生成报告。好吧，很简单，对吧？错。总是把请求看作是200。您是否希望支持200个这样的应用程序，所有这些应用程序都做几乎相同的事情？不是我。太懒了

我指示我的团队制作一个通用表单系统，并使用非自报告或通用报告机制。我还强调了尽可能多地使用XML/XSLT（例如，不要依赖于微软的easy bake oven技术，这些技术似乎随着每个新版本的发布而中断）。然后，当另一个业务部门想要“类似的东西，但有变化”时，核心已经存在了——我们只需要一个新的文件夹，修改过的XML/XSLT，我们就完成了

这总是让未来的变化更容易处理。“需要一个新字段？更改XML文件。需要更改报表生成方式？更改XSLT。不更改程序。”明白吗？没有程序更改。尽可能远离逻辑。甚至业务流程也可以用XML/XSLT表示

事实上，您将遇到的大多数应用程序都是永远都在使用的编程轮子（顺便说一句，这是一本很好的算法书）。他们只会被那些不懂业务、更不懂他们的手艺的人搞得更糟

他们不会以你或你的软件为中心建立业务，除非你是第一次编写MS DOS。你一提议，你就走了。而且。。。你应该是。

• 当面对与当前软件形式相关的不断升级的业务规则复杂性时，请尝试考虑，以实现更好的模块化和关注点分离。这样，新的或不断变化的业务规则（正如它们出现的那样）可以作为插件集成到您现有的代码库中，只集成到那些需要它们的模块中，而不是必须的