M.I.A.I

业务应用开发

如何将业务流程输入一个不写技术规格的应用程序

您不需要写一个技术规格来开始构建有用的商业应用程序。 首先要取得一个成果,确定谁负责这项工作,描述所涉信息和决定,并商定未经审查绝不能发生的事情。 一个有重点的澄清过程可以把业务说明变成人们能够理解、测试和批准的要求.

这一过程的可重复版本,请探索 M.I.A.I Builder.

从业务结果开始, 不列出一个特性列表

“我们需要一个软件来解决股票问题”这样的请求是可以理解的,但过于宽泛,无法核实。 一个更好的出发点是:“当Shopify股票不同意我们的ERP时,向目录组显示不匹配之处,解释哪个系统拥有该价值,并在更换商店之前需要批准。” 该句确定了事件、用户、信息、决定和安全界限.

这种结果第一的方法防止了一个项目成为无法解决原始问题的屏幕集合. GOV.UK服务指南同样建议理解用户以及他们试图在全面背景下解决的问题. 任何企业的实际经验是,在决定哪些软件应取而代之或予以支持之前,先观察目前的工作.

用简单的英语撰写一页流程简况

第一个简报应足够短,以便从事这项工作的人能够提出质疑。 记录触发,当前步骤,所涉人员,使用的信息,决定点,预期结果和重要例外. 避免规定数据库、框架或屏幕布局,除非有实际的限制使其有必要.

将事实与偏好分开. “命令必须保留Shoppify ID”是一项身份与和解要求。 “按钮应为蓝色”是一种列报偏好。 两者都可能都很重要,但如果混淆,就更难判断申请在业务上是否正确.

  • 触发器:什么是进程开始?
  • 用户:谁完成,审查或接受作品?
  • 输入:需要哪些记录、文件或客户细节?
  • 规则:应用程序必须计算、比较或决定什么?
  • 结果:当过程完成时,应该如何?
  • 例外:什么需要人的决定而不是自动化?
  • 证据:必须记录什么才能稍后检查结果?

将不确定性转化为重点明确的澄清问题

澄清应揭露将实质性地改变申请的决定。 一次问一个问题,解释答案为何重要. 如果预订申请可以提供发型预约或小屋停留服务,则不能假定持续时间:一个需要分钟,另一个可能需要晚上、可用规则和入住边界.

好的问题提供了真正的替代办法。 谁拥有股票价值: Shopify 或 NetSuite? 一个例外应该暂停整个运行还是只暂停受影响的记录? 团队成员能批准价格变动,还是必须是管理员?. 每个答复都成为接受条件,而不是消失在会议说明中.

  1. 用企业使用的语言描述结果.
  2. 只提出改变数据、行为、访问或风险的问题.
  3. 概述商定的程序和尚未解决的假设.
  4. 与从事这项工作的人确认接受条件.
  5. 构建能够证明结果的最小完整路径.

在连接系统之前定义数据所有权

连接的应用程序需要每个重要领域的明确真相来源。 产品所有权可保留在Shoppify,可用库存来自Sage 200,财务状况仍保留在NetSuite. 应用程序应当通过出口、进口和审计记录携带稳定的提供者标识符,因此,一个可编辑的标题、手柄或SKU不能意外地指向错误的记录.

认证和许可边界属于要求,而不是事后考虑。 Shopify的官方文件解释, 访问符带有决定应用程序能读能写的内容的范围。 询问所需的最窄权限,将证书绑定在正确的组织和存储上,并在用户运行数据操作前显示连接状态.

在正常工作流程中构建控制

一个有用的商业应用 使得安全行动是容易的行动。 预览批量变化,在确认前显示差异,防止重复提交,并将例外放入可见的队列. API成功的响应与已调节的业务结果不同,因此完成应包括记录盘点,失败和可追踪运行状态.

NIST的安全软件开发框架以结果为基础,旨在使安全的开发活动与业务要求和风险承受能力相协调。 对于一个小型的可操作应用软件来说,这一原则转化为具体的控制:保护资质,隔离客户数据,审查高影响的变化,测试预期的失败并保存足够的证据来调查一个问题.

  • 使用最优准入和组织范围证书
  • 在应用前预览进口、删除和批量更新
  • 破坏行动需要明确确认
  • 使用稳定的外部ID进行更新和调节
  • 记录谁批准了一个行动, 当它运行和什么变化
  • 明显失败,在安全时保留未受影响的记录

一个具体的例子:解决股票不匹配

想象一个批发商在NetSuite控制库存的同时通过Shoppify销售. 当前的过程是每日电子表格比较. 工作人员复制了SKU,调查差异并手动调整商店. 业务结果不是“制作一个仪表盘”;而是“迅速查明真实的股票错配情况,并纠正核准的记录,而不改变错误的产品”

第一个应用程序路径连接了授权的Shopify和NetSuite账户,用其稳定的ID比较记录,显示自有系统和当前值,并让授权用户批准选定的更正. 它记录了跳过的记录和连接错误 。 以后的版本可能会增加时间表或通知,但最初的构建已经很有价值,因为它完成了一个可控结果.

如何判断申请是否准备好

用现实的例子进行测试,包括缺失的数据,重复的标识符,过期的访问,相冲突的编辑和一个没有批准权的用户. 要求行动小组在无解释的情况下完成这一过程。 如果他们不能告诉发生什么,需要注意什么,或者最终结果是否正确,应用就没有完成.

衡量业务结果,而不是软件产量。 有用的措施包括取消重返记录、解决例外、防止不正确的更新、完成时间和成功调节运行的比例。 保持原始结果的可见性,因此未来的变化会改善相同的过程,而不是逐渐地将应用变成一个不相关的特性集合.

授权来源

本条中使用的指南

自由提问

关于将业务流程转变为应用程序的问题

我该提供什么信息来启动一个应用程序?

描述业务结果、谁执行工作、他们使用的信息、他们作出的决定和需要人审查的例外情况。 开始时不需要技术规格.

一个应用程序能连接到我们已经使用的软件吗?

是的,当提供者提供经批准的连接和所需的认证时,可以提供授权和数据映射。 每种联系仍然需要一个商定的真相来源和经过检验的失败行为.

第一版应该有多小?

它应该是提供并证明一个有用结果的最小的完整工作流程。 部分地收集屏幕比从触发到核实结果的狭义过程更不值钱.

我们如何防止自动应用程序改变错误的记录?

使用稳定的提供者身份证明,租户的证书,预览和批准控制,在支持的地方写作,以及操作后调节.

我们需要自动化所有例外吗?

没有 很少、模棱两可或影响大的例外情况在明确的人类审查排队中往往更安全。 自动化应去除日常工作而不必隐藏需要判断的决定.