您如何平衡业务流程变更与软件变更带来的挑战？答案

【问题标题】：How do you balance business process changes against the challenges of changing software?您如何平衡业务流程变更与软件变更带来的挑战？
【发布时间】：2009-10-29 19:03:10
【问题描述】：

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

虽然软件是让企业生活更轻松的工具，但作为开发人员，我们在什么时候建议改变业务流程，而不是将软件作为解决特定问题的“灵丹妙药”。
作为开发人员，我们如何宣传对软件的一定程度的尊重，以及仅仅为了支持业务的怪癖而进行更改所涉及的困难？

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

【问题讨论】：

标签： performance business-process

【解决方案1】：

你可以看看

高效能的七个习惯人

，因为您需要建立一个足够大的影响范围来尝试改变业务流程。

您最好的选择是表明您在工作中非常称职，并努力与业务方面的人建立关系，这样您就可以在工作之余坐下来讨论相关的业务流程。

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

异端时代

例如，您会看到一些公司在做出改变方面过于成功，然后被公司摧毁了。

目前，您最好的选择是尽可能地进行更改，以使软件更具适应性，以便在流程发生变化时您可以轻松适应新规则。

【讨论】：

【解决方案2】：

在您做任何事情之前，您最好退后一步，尝试了解业务。如果他们通过调整流程来应对变化，那是一件好事。当他们多年来保持完全一样的事情时，你就可以忘记他们仍然是一家公司。但是，您需要确保您响应的更改不会对上游或下游业务流程产生负面影响。业务部门不经常进行这种检查。但是，当一切都陷入困境时，你知道他们会责备谁，对吧？通过这样做，您可以解决这些问题并传播“更好的方法”。不这样做是永远沮丧的处方。

在您考虑编写代码之前了解他们的业务。

关于机制：我总是让我的团队写的是“通用软件”。某些业务部门可能需要一种方法来捕获表格并生成报告。好吧，很简单，对吧？错误的。始终将请求视为某事*200。您想支持 200 个这样的应用程序，它们都几乎做同样的事情吗？不是我。太懒了。

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

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

实际上，您会遇到的大多数应用程序都是相同的 Programming Wheels（顺便说一句，这是一本很好的算法书），它们已经永远完成了。他们只会被那些不了解业务并且更不了解他们的手艺的人做得更差。

除非您是第一次编写 MS DOS，否则他们不会围绕您或您的软件开展业务。一旦你提出建议，你就会离开。而且......你应该是。

【讨论】：

【解决方案3】：

任何最终客户（即您的雇主或客户的客户）听到的最令人沮丧的事情之一就是“计算机不允许我这样做”。比如说，在计算完运费后将商品添加到订单中，或者在计算完销售税之前取消某些东西，等等。软件应该为企业服务。当然，这意味着软件必须进行很多更改，有时它会发生很大变化，以至于您必须重新开始。随着经验的增长，您将编写更容易更改的软件，因为业务流程更改、法律更改、税法更改、客户更改等不可调整的现实。有一天，您可能会成为客户值得信赖的商业顾问。这在你职业生涯的早期是不寻常的。我现在正处于那个阶段，但我正处于获得节目报酬的第四个十年。我很少建议企业使用该软件。需要大量判断才能知道什么时候建议是正确的。不管你对你的软件有什么崇敬之情，尽你最大的努力向那些付费的人隐藏它。他们将其视为支持他们所从事的实际业务的工具。

【讨论】：

【解决方案4】：

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

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

【讨论】：

【解决方案5】：

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

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

就您的具体问题而言：

一看到它们。重要的是用建设性的措辞表达你的建议。还使用与业务相关的术语（ROI、NPV 等）。并找到附带的好处（）。因此，如果软件更改确实不能缓解业务问题，成本很高并且修复业务流程可以显着节省辅助成本，那么您会提出一个完全不同的场景，而不是仅仅说“我们不能这样做，因为它成本太高"。
该软件归企业所有 - 与公司拥有的任何其他具有类似价值的软件相比，它不会受到更多或更少的尊重。

【讨论】：

我喜欢你的第二点，但我的问题是你如何评估软件的价值......？
这是大多数业务问题的核心。只有了解业务优先级和机会成本的人才能回答这个问题。而且您还会发现，有时即使被认为是优秀的商业人士也会有巨大的盲点，即使他们被告知需要考虑的概念。大多数情况下，商界人士会形成一个假设，并且只重视证实该假设的信息。
@Achilles：软件的商业价值与开发人员在工作中获得的乐趣程度成反比。 :)

【解决方案6】：

当面对与当前软件形式相关的不断升级的业务规则复杂性时，请尝试考虑Aspect-Oriented-Software-Development，以实现更好的模块化和关注点分离。这样一来，新的或不断变化的业务规则，就像它们出现的那样，可以作为插件集成到您现有的代码库中，仅用于那些需要它们的模块，而无需重写大量不相关的代码。
想法是，毕竟很多业务规则都来自于具体的立法，而且是业务的责任，也传递给软件，实施和适应。我个人认为，由于感知困难而缺乏遵循规范的意愿是导致大多数网络浏览器或多或少落后于网络标准的原因 - 更改规则是一种临时解决方法，通过支持及时导致更大的累积成本每个浏览器的特定怪癖。尝试尽快实施新的业务规则，因为它们出现或发生变化 - 不这样做会导致对新功能的支持累积不足，并最终导致您的软件被弃用。

【讨论】：

【解决方案7】：

这有点像 CIO 的角色/优势。如果 IT 方面可以说服业务方面，更改业务流程比更改代码更容易/更便宜/更具成本效益，那么你就有了意义。否则，古怪的商业实践可能比你想象的更有价值。我也怀疑您是否明确表示，如果您花时间解决这个古怪的问题，您将无法按时交付所需的功能（祝您好运）。

如果技术人员按照自己的方式行事，那么 GUI 和鼠标/指针将永远无法走出实验室。对于日常用户来说，他们会一直存在。

【讨论】：