您如何平衡业务流程变更与软件变更带来的挑战？
在我诚然年轻的职业生涯中，我发现自己编写代码来支持古怪的业务规则和流程。不可避免的是，这些更改总是出现在一些非常困难的代码库中，并导致了许多问题。我的问题有几个部分：
虽然软件是企业让生活变得更轻松的工具，但我们作为开发人员在什么时候建议改变业务流程而不是改变软件作为解决问题的“灵丹妙药”虽然
作为开发人员，我们如何传播对软件的一定程度的尊重，以及仅仅为了支持业务怪癖而进行更改所涉及的困难？
作为
我知道业务流程的这些变化促进了我们的行业，但我父亲会理解一个类比：哪个更容易，熔化锤子锻造螺丝刀来驱动螺钉或简单地使用钉子，因为你的锤子已经很棒了。 .?
In my admittedly young career I've found myself writing code to support quirky business rules and processes. Inevitably these changes were always in some massively difficult code base and caused many issues. My question has a couple of parts:
While software is a tool for businesses to make their lives easier, at what point do we as developers suggest a change in business process rather than in the software as the "magic bullet" to solve a particular problem.
How do we as developers evangelize a certain level of reverence for the software as well as the difficulty involved in making changes simply to support the quirks of the business?
I understand that these changes in business processes promote our industry, but in an analogy my father would understand: Which is easier, to melt down a hammer to forge a screwdriver to drive screws or to simply use nails since your hammer is already awesome...?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（7）
你可以看看
认为，你需要发展一个足够大的影响范围来尝试改变业务流程。
您最好的选择是表明您非常胜任自己的工作，并致力于与业务方面的人员发展关系，以便您可以在工作之外轻松地坐下来讨论相关业务流程。
这是一个缓慢的过程，但如果你试图操之过急，业务就会推迟，并像虫子一样压扁你。如果你读过
，你会看到一些公司在变革方面过于成功，但最终被公司摧毁的例子。
目前，您最好的选择是尽可能进行更改，以使软件更具适应性，以便在流程发生变化时您可以轻松适应新规则。
You can look at
, as there is the sense that you need to develop a sphere of influence large enough to try to change business processes.
Your best bet is to show that you are very competent at your job, and work on developing relationships with people on the business side, so that you can feel comfortable sitting down outside of work to discuss the business process in question.
This is a slow process, but if you try to rush too fast the business will push back, and squash you like a bug. If you read
for example, you will see examples of companies that were too successful in making changes, and the corporation destroyed them.
At the moment your best bet is to make changes, as you can, to have the software be more adaptable, so that if the process changes you can easily adapt to the new rules.
在你做任何事情之前，你最好先退后一步，尝试了解业务。如果他们通过调整流程来应对变化，那是一件好事。当他们多年来保持一切都一模一样时，你就可以忘记他们仍然是一家公司。但是，您需要确保您所响应的更改不会对上游或下游业务流程产生负面影响。业务部门并不经常进行这种检查。但是，当一切都变得糟糕时，你知道他们会责怪谁，对吧？通过这样做，您可以解决这些问题并传播“更好的方法”。不这样做就会导致永远的挫败感。
在你考虑将其编纂之前先了解他们的业务。
至于机制：
我总是让我的团队编写的是“通用软件”。某些业务部门可能需要一种捕获表单并生成报告的方法。好吧，很简单，对吧？错误的。始终将请求视为某事*200。您想要支持 200 个这样的应用程序，它们都做几乎相同的事情吗？不是我。太懒了。
我指示我的团队制作一个通用表单系统并使用现成的或通用的报告机制。我强调尽可能多地使用 XML/XSLT（例如，不要依赖 Microsoft 的 easy-bake-oven 技术，该技术似乎随着每个新版本的发布而中断）。然后，当另一个业务部门想要“类似的东西，但有所更改”时，核心已经存在 - 我们只需要一个新文件夹，修改 XML/XSLT，然后我们就完成了。
这总是——总是——让未来的变化更容易处理。 “需要新字段？更改 XML 文件。需要更改生成报告的方式？更改 XSLT。无需更改程序。”得到它？没有程序改变。尽可能远离逻辑。甚至业务流程也可以用 XML/XSLT 表示。
事实上，您将遇到的大多数应用程序都是相同的编程轮（顺便说一句，一本很好的算法书），而且已经永远存在了。如果那些不了解业务、更不了解自己手艺的人会把事情做得更糟糕。
他们不会围绕您或您的软件开展业务，除非您是第一次编写 MS DOS。一旦你提出建议，你就会消失。而且......你应该是。
Before you can do anything, you'd better step back and try to understand the business. If they're reacting to change by adapting their processes, that's a GOOD thing. It's when they leave things exactly the same for years that you can forget about them remaining a company. You need to make sure, however, that the change you're responding to won't negatively impact up- or down-stream business processes. Business units don't often do that checking. But, when it all goes to hell, you know who they're going to blame, right? By doing this, you can head those issues off and evangelize, "better ways." Not doing it is a prescription for eternal frustration.
Learn their business before you even think of codifying it.
As for the mechanics:
What I always had my teams write was, "generic software." Some business unit might have needed a way to capture a form and produce a report. Okay, easy enough, right? Wrong. Always consider a request as something*200. Would you want to support 200 such applications, all doing almost the same thing? Not me. Too lazy.
I directed my teams to make a generic form system and use off-the-self or generic reporting mechanisms. And I stressed the use of XML/XSLT for as much as possible (not relying, for example, on Microsoft's easy-bake-oven technologies that seem to break with each new release). Then, when another business unit wanted, "something similar, but with changes," the core was already there - we only needed a new folder, modified XML/XSLT and we were done.
That always - ALWAYS - made those future changes easier to handle. "Need a new field? Change an XML file. Need to change the way a report is produced? Change XSLT. No program changes." Get it? NO program changes. Keep as much as you can OUT of the logic. Even business processes can be represented in XML/XSLT.
In reality, most of the applications you'll come across are the same Programming Wheels (a good algorithm book, by the way) that have been done forever. They'll just be done more poorly by people who didn't understand the business and understood their craft even less.
They're not going to build their business around you or your software, unless you're writing MS DOS for the first time. The second you suggest it, you'll be gone. And... you should be.
任何最终客户（即您的雇主或客户的客户）听到的最令人沮丧的事情之一是“计算机不允许我这样做”。比如说，在计算运费后将商品添加到订单中，或者在计算销售税之前取消某些商品，等等。软件应该为业务服务。当然，这意味着软件必须进行很大的更改，有时它与原来的位置相比发生了很大的变化，以至于您必须重新开始。随着经验的增长，考虑到业务流程变化、法律变化、税法变化、客户变化等不可调整的现实，您将编写更容易更改的软件。有一天，您可能会成为客户值得信赖的商业顾问。这在你职业生涯的早期是不寻常的。我现在正处于这个阶段，但我已经进入了第四个十年。我很少建议企业使用该软件。需要大量的判断才能知道什么时候提出建议是正确的。不管你对你的软件有什么崇敬之情，都要尽力向付费的人隐藏它。他们将其视为支持他们从事的实际业务的工具。
One of the most frustrating things any end customer (that is, a customer of your employer or customer) can hear is "the computer won't let me do that". Say, add items to an order after the shipping is calculated, or cancel something before the sales tax has been calculated, or whatever. The software should serve the business. Sure, that means the software has to change a lot, and sometimes it changes so much from where it was that you have to start over. As you grow in experience you will write software that is easier to change, given the unadjustable reality that business process change, laws change, tax codes change, customers change, and so on. Some day you may be a trusted business advisor to your clients. That is unusual early in your career. I'm in that stage now but I'm in my fourth decade of being paid to program. I rarely suggest the business accomodate the software. It takes a lot of judgement to know when that might be the right thing to suggest. And whatever reverence you might feel for your software, do your best to hide it from the folks who pay for it. They see it as a tool to support the real business they're in.
我认为质疑构建新解决方案以适应现有业务流程与调整业务流程以适应现有解决方案的成本效益是有价值的。但现实中，我还没有看到商家从这个角度考虑。
考虑到这一点，我认为您可以做的下一个最好的事情是预测业务未来可能要求的具体变化，并开发您的解决方案，以便它可以轻松适应这些变化。
I think there is value in questioning the cost effectiveness of building new solutions to adapt to existing business processes versus adapting business processes to adapt to existing solutions. However, in reality, I have not seen the business consider this angle.
With that in mind, I think the next best thing you can do is to anticipate specific changes that the business might request in the future and develop your solution such that it can adapt to those changes easily.
不幸的是，这完全取决于具体情况。
即使在业务和软件方面拥有丰富的经验，这仍然是一个复杂的问题。
至于您的具体问题：
一旦您看到它们。重要的是用建设性的措辞表达你的建议。还使用与业务相关的术语（投资回报率、净现值等）。并找到附带的好处（）。因此，如果软件变更确实不能缓解业务问题，成本很高，并且修复业务流程可以节省大量辅助成本，那么您会提出一个完全不同的场景，而不仅仅是说“我们不能这样做，因为成本太高” ”。
软件归企业所有 - 与公司拥有的类似价值的任何其他软件相比，它不会受到更多或更少的尊重。
软件
Unfortunately, this is entirely situation-dependent.
Even with a great deal of experience in business AND software, it is still a complex issue.
As far as your specific questions:
As soon as you see them. What is important is to couch your suggestion in constructive terms. Also using terms relevant to the business (ROI, NPV, etc). And finding ancillary benefits (). So if the software change really doesn't mitigate the business problem, the cost is high and fixing the business process has significant ancillary cost savings, you pose a completely different scenario than just saying "we can't do it because it costs too much".
The software is owned by the business - it isn't owed any more or less reverence than anything else the company owns of similar value.
这有点像 CIO 的角色/力量。如果 IT 方能够让业务方相信更改业务流程比更改代码更容易/更便宜/更具成本效益，那么您的观点就说得通了。否则，古怪的商业实践可能比你想象的更有价值。我还怀疑您是否明确表示，如果您花时间在奇怪的问题上，您将无法按时交付所需的功能（祝您好运）。
如果技术人员按照自己的方式行事，GUI 和鼠标/指针将永远不会走出实验室。对于日常用户来说，它们会一直存在。
That's kind of like the role/strength of the CIO. If the IT side can convince the business side that it would be easier/cheaper/cost effective to change the business process than the code, than you have a point. Otherwise, the quirky business practice may be more valuable than you think. I also doubt that you are making it clear that if you spend time on the quirky problem, you won't deliver the needed features on time (good luck with that).
If technologists had their their way, the GUI and the mouse/pointer would never have made it out of the lab. For everyday users, they're here to stay.