2

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

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

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

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

4

7 回答 7

1

你可以看看

高效能人士的七个习惯

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

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

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

异端的时代

例如，您会看到一些公司在改变方面过于成功的例子，而公司却摧毁了它们。

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

于 2009-10-29T19:13:04.203 回答
1

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

在您考虑编纂它之前了解他们的业务。

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

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

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

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

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

于 2009-10-29T19:32:14.743 回答
1

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

于 2010-05-31T01:50:21.203 回答
0

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

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

于 2009-10-29T19:05:50.967 回答
0

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

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

至于你的具体问题：

  1. 一见到他们。重要的是用建设性的措辞表达你的建议。还使用与业务相关的术语（ROI、NPV 等）。并找到附带的好处（）。因此，如果软件更改确实不能缓解业务问题，成本很高并且修复业务流程可以显着节省辅助成本，那么您会提出一个完全不同的场景，而不仅仅是说“我们不能这样做，因为它成本太高”。

  2. 该软件归企业所有 - 与公司拥有的任何其他具有类似价值的软件相比，它没有任何或多或少的尊重。

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

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

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

于 2009-10-29T19:56:24.907 回答