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

你可以看看

高效的七个习惯 人

因为有一种感觉,你需要发展一个足够大的影响范围来尝试改变业务流程。

你最好的办法是证明你在工作上非常有能力,并且努力发展与企业方人员的关系,这样你就可以在工作之外坐下来讨论有关的业务流程。

这是一个缓慢的过程,但如果你尝试过快的速度,业务将推后,挤压你像一个臭虫。如果你读了

异端学说的年代

例如,您将看到一些公司在进行更改时过于成功,而公司却破坏了这些更改。

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

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

在你想把它们编纂成法典之前先了解它们的业务。

至于机械师: 我一直让我的团队写的是“通用软件”,一些业务部门可能需要一种方法来捕获表单并生成报告。好吧,简单点,对吧?错了。始终将请求视为*200。你想支持200个这样的应用程序吗? 几乎 同样的事情?不是我。太懒了。

我指导我的团队建立一个通用的表单系统,并使用非自我或通用的报告机制。我还强调了尽可能多地使用XML/XSLT(例如,不依赖于微软的Easy Bake-Oven技术,该技术似乎与每个新版本都有所突破)。然后,当另一个业务部门需要“类似的东西,但有变化”时,核心已经存在了——我们只需要一个新的文件夹,修改了XML/XSLT,我们就完成了。

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

实际上,您将遇到的大多数应用程序都是相同的编程轮子(顺便说一句,这是一本很好的算法书),它们是永久性的。他们只会被那些不懂生意,不懂手艺的人做得更糟糕。

他们不会围绕你或你的软件建立业务,除非你是第一次写MS-DOS。一旦你提出建议,你就要走了。还有…你应该是。

任何终端客户(即你的雇主或客户的客户)都能听到的最令人沮丧的事情之一是“计算机不允许我这样做”。例如,在计算运费之后向订单添加项目,或者在计算增值税之前取消某个项目,或者诸如此类。软件应该为企业服务。当然,这意味着软件必须要改变很多,有时它会从你必须重新开始的地方改变很多。随着经验的增长,您将编写更容易更改的软件,因为业务流程更改、法律更改、税务代码更改、客户更改等不可调整的现实。有朝一日,你可能会成为客户值得信赖的商业顾问。这在你职业生涯的早期是不寻常的。我现在正处于那个阶段,但我正处于我的第四个十年的项目报酬期。我很少建议企业使用该软件。要知道什么时候建议才是对的,需要很多判断。不管你对你的软件有多崇敬,尽你最大的努力把它藏起来,不让那些为它买单的人看到。他们把它看作是一个支持他们真正业务的工具。

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

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

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

即使拥有丰富的商业和软件经验,它仍然是一个复杂的问题。

至于你的具体问题:

1. 你一看到他们。重要的是以建设性的方式提出你的建议。同时使用与业务相关的术语(投资回报率、净现值等)。找到辅助效益()。因此,如果软件的变更真的不能缓解业务问题,成本很高,并且修复业务流程可以节省大量的辅助成本,那么您提出了一个完全不同的方案,而不仅仅是说“我们不能这样做,因为它成本太高”。

2. 该软件归企业所有——与公司拥有的其他类似价值的软件相比,它没有多少值得尊重的地方。

• 当面临与当前软件形式相关的业务规则复杂性不断上升时,请尝试考虑 Aspect-Oriented-Software-Development 为了实现更好的模块化和关注点分离。这样,新的或正在更改的业务规则(如它们所示)就可以作为插件集成到现有的代码库中,仅限于那些需要它们的模块,而不必重写大量不相关的代码。
• 其思想是,毕竟,许多业务规则都来自于具体的立法,而它是业务的责任,也传递给软件,以实现和适应。我个人认为,由于意识到困难而缺乏遵循规范的意愿,是导致大多数Web浏览器或多或少落后于Web标准的原因——修改规则是一种临时性的解决方案,通过支持每个浏览器的特定特性,可以使时间提前到更大的累积成本。尝试尽可能快地实施新的业务规则,否则会导致对新功能的支持累积不足,最终导致软件被弃用。

这有点像CIO的角色/实力。如果IT部门能够说服业务部门,那么更改业务流程比更改代码更容易/更便宜/更经济,这比您的观点更具说服力。否则,古怪的商业实践可能比你想象的更有价值。我也怀疑你是否清楚地表明,如果你花时间解决这个奇怪的问题,你就不会按时交付所需的功能(祝你好运)。

如果技术人员有他们的方法,图形用户界面和鼠标/指针就永远不会离开实验室。对于日常用户,他们会留在这里。