2

业务和IT分离的时代已经过去? - OSKAR

 2 years ago
source link: https://www.jdon.com/59223
Go to the source link to view the article. You can view the picture content, updated content and better typesetting reading experience. If the link is broken, please click the button below to view the snapshot at that time.

业务和IT分离的时代已经过去? - OSKAR

业务和IT分离的时代已经过去,问题空间和解决方案分离的时代已经过去:

“请给我解决方案,而不是问题!” 我从业务和管理部门多次听到这句话。你也听说过,不是吗?

我们程序员应该回喊“请给我呈现问题,而不是解决方案!”(你在教我做事吗?)

想象一下,你正在从事人力资源系统的工作:假期、合同,诸如此类的事情。"业务 "来找你并说

"听着,让我们做一个网络应用,员工将在其中记录他们的工作时间。我们最近在厨房里谈到了你的那些 "Reacts "和 "Angulars"。我们可以用它们来使它看起来不错。你愿意做吗?"

于是,规划开始了:严肃讨论我们是否应该把表单放在这里,或者把网格放在那里。与后端进行激烈的谈判,我们是做一个REST API还是GraphQL。在另外的会议上讨论合同应该是这样的还是那样的。

争吵过后,最后发现我们甚至能够按时完成项目,即使是Jira中的需求(呜呼!)。

这个系统只有几个bug。我们需要多个冲刺阶段,但工作已经完成了!这就是我们的工作。

如果它是如此美丽,为什么它如此糟糕?

事实证明,系统用户并不乐意在工作时每天手动输入。以前,他们把自己的工作时间输入Excel表格,每周一次发送给他们的主管。然后,主管将其混合成一个大的Excel文件,并将其发送给人力资源部门。

这些不快乐的用户会唠叨着要你在你巧妙设计的系统中增加或纠正一些东西,以解决呈现给你的问题。在这种情况下,当不高兴的用户遇到他们不喜欢的解决方案时,最终会发生对抗。对抗可能是痛苦的,但也可能是有益的;它们可以暴露出需要解决的真正问题,而不是别人交给你的解决方案。在这种情况下,事实证明,用户填写时间表的能力并不是需要解决的实际问题。

它是由别人决定的问题的解决方案。

真正的问题是,人力资源部门需要知道每个人工作了多少天,以核实时间表和计算费用。永远忙碌的小组长们被其他工作埋没了,迟迟不能把这些Excel文件放在一起。他们还把它当作一项繁琐的职责,犯了很多复制/粘贴的错误。工作人员也浪费了核实这些数据的时间,并在之后纠正这些条目的错误。

如果我们要问实际问题是什么,我们可能会得出结论:你可能不需要创建一个新的网络应用程序。也许你不需要制作新的API。

  • 创建一个集体的电子邮件账户来发送和接收Excel电子表格。
  • 将这些与电子邮件系统整合,从该账户中抓取电子邮件,导入附件并进行解析。
  • 如果Excel中不包含错误,数据将被保存到人力资源系统中。之后,它将向雇员发送带有确认的答案。
  • 如果电子邮件不正确(例如,它不包含附件,不可能解析它或条目是错误的),系统将发送一封电子邮件,要求更正。

结果可能是更有道理,做起来更快,对每一方都更方便。

我们程序员通常有两种态度:

  • "业务不会告诉我们如何写代码":我们是大写的程序员,我们最了解一切。
  • 业务知道系统应该如何运作。我不会要求他们澄清的一些疑问。我只要按需求编写代码。

这两种态度都可以说是不负责任和危险的。

作为程序员,我们了解技术:这就是我们获得报酬的原因。因此,"业务 "不应该来告诉我们使用什么框架,或者如何创建API端点。

当然,前提是应用程序与我们的设计:

  • 做它应该做的。
  • 准时交付。
  • 维护成本与其他解决方案大致相同。
  • 不增加项目风险(例如,更高的开发成本)。

技术决定应该完全属于我们。当然,我们的选择的后果也应该是我们的。

然而,我们必须记住,我们不是商业专家,即使我们是一个高薪职业。让我们把话说清楚:我们是高薪的工匠,而不是艺术家。我们的工作应该是帮助企业有效地挣钱。我们不是某个领域的业务流程的专家。

我们不能假设 "业务 "知道一切。如果我们的业务领域是人力资源和工资,"企业 "会明白授权管理面板应该是什么样子吗?或者他们会知道我们有哪些选项可以与外部系统整合?他们会知道登录屏幕应该是什么样子的吗?或者哪个表格会更漂亮?

也许他们会,但很可能他们真的不知道,因为这不是 "核心 "业务领域。商务人士都是专家,例如,人力资源和工资单。他们可能会猜测其他功能应该如何工作。

通常的情况是,"业务 "想要帮助我们解决问题,并自动提出解决方案。当我们问:"为什么要这样?"那么我们经常会得到这样的答案:"我不知道,我想这样会让你更容易。"。

我最近就遇到了这样的情况,我的产品负责人希望我们在一些后台操作的时候阻止所有用户使用该记录。

我们必须主动询问,以确定我们得到的是对实际问题的描述,还是只是别人向我们提出的解决方案(潜在的商业解决方案)。当我们试图理解一个商业流程时,我们不会质疑它的正确性。事实上,我们的职责是帮助企业解决问题。盲目地接受需求,我们根本没有帮助他们:我们甚至会使情况变得更糟

我预测,软件公司和商业公司各自为政的时代很快就会过去了。这是过去的遗迹,IT系统重复人们正在做的事情,以使其更快。现在随着SasS解决方案的不断发展,IT就是商业。因此,业务和IT之间的密切合作不再是 "很好拥有",而是 "必须拥有"。

考虑一下以下情况是一个问题还是一个解决方案?

  • SASS系统中的许可系统
  • 用户管理面板
  • 认证和授权
  • 唯一的发票号码
  • 开发一个货物处理系统

About Joyk


Aggregate valuable and interesting links.
Joyk means Joy of geeK