该企业正在不断开发其IT产品。 无法“停下来”，否则即使最好的程序也将不可避免地过时。 我们讲述了我们如何为欧洲创建新版本的医疗应用程序以及同时解决了哪些问题。
医院应用
我们正在为欧洲的医院提供医疗应用程序。 通过减少文书工作，它可以帮助医生在患者身上花费更多的时间。 医生指示有关患者和检查的信息，该应用程序将音频记录转换为文本格式，填写模板并为医务人员和患者生成文档。 在工作的每个阶段，都建立了自己的业务逻辑并与多个外部系统集成。
客户为我们设定了开发新版本应用程序以向投资者进行演示的任务。
项目详情
音讯
如何在2.0版中录制音频：
- 打开应用程序。
- 单击添加记录按钮。
- 在出现的窗口中，我们选择了所需的记录设备版本。
- 听写录音。
- 输入患者编号，访问日期，访问编号（访问=医生的预约）。
- 他们单击“完成”按钮将音频上传并访问数据到服务器。
现在，在3.0版中，编写时所需的工作更少：
- 医生打开应用程序。
- 从列表中选择一个约会（按日期，时间，电话号码或患者姓名），然后单击1次以打开访问卡。
- 录制音频。
- 按“完成”按钮将音频发送到服务器。
在3.0版中，医生的工作是尽可能自动化的。 手术数量减少了，而程序本身增加了有关患者的数据。
处理字母
处理字母也变得更加容易。 在2.0版中，处理它们的过程很困难。 医生无法立即收到完整的信件清单-仅按部分和特定顺序。 要开始使用，您必须：
- 单击以获取您的信件清单；
- 转到另一个窗口；
- 双击字母以将其打开；
- 处理完列表中的字母后，再次单击以在列表中接收以下字母。
在3.0版中，医生会看到所有可用于处理的字母。 他可以通过两种方式选择文档-在列表中手动选择文档，或使用过滤器和排序方式（您可以单击保存它们以进一步打开信函）。 要打开字母，只需单击一次。
介面
通常，版本2.0界面繁琐且不便。 该应用程序的最初任务是通过减少纸张工作流程和处理音频记录来节省医学专家的时间。 实际上，该应用程序无法像我们希望的那样处理该任务。 为了进行记录，医生必须从长的下拉列表中选择很多设置。
我们的专家使用该界面，并突出显示了音频按钮，以便用户可以以最少的点击次数完成任务。
接下来，我们将详细介绍如何开发新版本。
新需求
当客户联系我们升级版本2.0时，该应用程序已经运行了大约三年。 它为用户所熟悉，并具有某些优点：
- 有一组功能可以执行复杂的业务逻辑，并与第三方系统集成。
- 客户习惯了该程序，并且不想放弃该程序；
- 技术支持人员了解该应用程序并迅速为用户提供帮助；
- 有灵活的设置可以根据业务需求配置系统。
- 建立了对系统服务器部分中可能出现的问题的跟踪，已知了解决这些问题的解决方法。
但是，在分析应用程序的运行时，我们发现了以下问题：
- 开发和测试新功能花费了越来越多的时间；
- 添加新功能时，系统中会出现错误；
- 结果，多达30％的复杂改进都无法使用，这有可能使应用程序过时。 例如，在医院中，出现了越来越复杂的模板，有必要在工作流程中添加新角色；
- 应用程序架构无法支持新的解决方案；
- 开发时间的40％用于支持；
- 在安装桌面产品的新版本和更新时遇到困难；
- 2000年代繁琐的界面吓跑了新客户；
- 不方便的设置系统阻止了系统快速启动，并且增加了出错的风险。
在评估优势和挑战时，我们得出的结论是，需要使应用程序更具移动性（Web版本而不是桌面版本），并且必须具有便利性，竞争力和易于适应业务任务的能力。
版本要求
我们分析了应用程序的功能，并确定了使产品对企业有价值的最重要的功能。 根据这些数据，我们确定了新版本中的程序：
- 需要该应用程序对医生和其他用户直观的关键功能；
- 用户-医疗保健提供者和支持人员-应该易于学习如何使用该程序；
- 即使在极端情况下（断电，不稳定的Internet访问等），也可以消除数据丢失；
- 系统生成的文件必须符合法律规范和要求；
- 在系统更新期间，应将对用户和支持服务的不便最小化；
- 有必要基于分布式，松散耦合的组件创建面向服务的模块化体系结构，这将使它们可用于构建复杂的软件系统；
- 使用Active Directory统一配置您的工作环境。
而且，不可能让新版本成为旧版本的“复杂副本”。 因此，必须保存关键功能，但不能使应用程序过载。 我们无情地放弃了多余的复杂环境。
使用2.0版的业务分析师没有立即接受更改。 在职权范围内，经常会找到一些短语：“应该在2.0版中出现”，“在2.0版中采用工作方案”。 与上一版本一样，现阶段最困难的事情是抵制一切诱惑。
项目团队
通常，在每个项目开始时，我们SimbirSoft都会与具有不同背景的专家团队（分析师，质量保证专家（QA）等）建立联系。 在处理医疗应用程序时，我们组成了以下团队：
- 编写代码并改编了2.0版功能的开发人员；
- 质量保证专家（QA）。 他们与开发人员一起熟悉旧版代码，体系结构解决方案和版本2.0的错误，还测试了新功能；
- 测试自动化工程师（SDET），他在桌面版和网络版中设置了自动测试用例验证；
- 商业智能。 他们与客户和医生进行了交谈，了解了业务流程的构建方式，对应用程序的要求和希望。 之后，他们绘制了整个团队都可以理解的业务流程图。
- 设计人员和可用性专家。 他们负责开发用户友好的界面。
- 参与时间安排和管理的项目经理。
在此过程中，我们不断维护新版本中所谓的风险表。 为了防止这种情况，我们考虑了一个灵活的应用程序设置系统，并对其测试进行了自动化，以保护用户免受错误的侵害。 特别是，我们的SDET专家编写了一个框架，该框架有助于快速检查代码中的所有更改，并减少了回归测试的时间。
挑战与解决方案
在升级应用程序时，我们面临几个困难的阶段，我们将在下面讨论。
应用设计
由于先前版本的界面繁琐，因此我们重新设计了应用程序设计。 我们提出了五个初步选择，并将它们显示给应用程序用户中的焦点小组，并进行了可用性测试。 结果，医学专家选择了一种选择，他们认为这是最方便，最有吸引力和最易于使用的。
针对不同浏览器的插件开发
我们提供了与该应用程序相关的各种技术风险。 例如，选择用于实现的插件可能不适用于某些Internet浏览器。 为了降低这种风险，我们首先为大多数合作伙伴医疗机构中使用的软件开发了一个插件。 将来，我们会冷静地为其他浏览器开发该插件。
无效的业务假设
我们的任务是开发该产品的限量版，以介绍给投资者。 因此，我们试图在应用程序中仅实现最必要的功能。 我们分析了客户的某些假设，并拒绝执行它们。
例如，客户建议创建一个日历以规划医疗专家的工作。 根据该假设，日历可以使医生的工作更加方便。 但是，在实际情况下，此功能无法成功执行，因此最终将其关闭。 后来，日历适应了另一组用户的需求-患者，而不是医务人员。 无效的假设─这是业务不可或缺的一部分，您需要为它们做好准备。
与外部系统集成
与我们的合作伙伴花了很多时间就将应用程序与外部系统集成以发送和存储字母的过程达成一致。
该应用程序的用户-医疗机构-希望对版本3.0使用熟悉的旧集成系统，因此无法更改。 我们的合作伙伴认为在这种情况下集成会很快。 但是，实际上，许多任务与集成相关联：
- 收集有关邮件发送系统如何工作的一般信息；
- 列出2.0版中的严重错误；
- 在分析和开发阶段考虑这些案例，以便将它们考虑在内，而不是一刀切；
- 分析版本2.0的功能是否适合版本3.0的过程或是否需要更改某些内容。 如果发生更改，请每次都说明为什么需要特定功能，并与客户的技术专家（而不仅仅是分析师）进行沟通。
在与客户进行谈判的过程中，我们能够证明进行集成需要时间。 我们的合作伙伴同意我们的意见：您不能只是将代码从一个版本转移到另一个版本。
测试和分析
该项目的先前版本是在没有分析师参与的情况下创建的。 开发人员和质量检查专家在创建应用程序的过程中指定了要求。 第三个版本已经基于分析人员的要求，但是，测试仍然存在困难：
- 不同的团队参与了该项目；
- 有大量并行任务；
- 在冲刺期间，需求和任务经常更改；
- 有必要考虑新功能与已经批准的功能之间的相互作用。
为了使用该产品的新版本，我们需要转换各个工作流程，例如：
- 我们从开发和质量保证方面加强了分析，并为此付出了额外的时间。
- 在复审要求中指明被测试功能的目的是一项规则。 这提高了分析人员对任务的理解，并为提出最佳解决方案提供了机会。
- 为了弄清工作条件，我们更改了术语：我们不是将工作时间粗略估计为小时，而是开始将任务分类为“大”或“小”。 我们只有在从开发方面对任务进行了全面审查，质量检查并最终确认了需求的最终版本之后，才开始计算提前期。 如果任务扩展，那么我们将重新计算时间成本估算。
- 我们开始计划在接下来的几个季度中实现哪些功能-在接下来的2-3个版本中。 为了更准确地预测开发情况，我们不再将未通过评估的任务包括在发布计划中。
- 为了方便分析人员和更好地理解系统，我们在清单中指出了在进行需求时应考虑哪些交互。 我们还制定了在JIRA中用Confluence和文档撰写文章的通用规则，并开始遵守它们。
定期与客户进行在线聚会有助于我们增进对客户业务流程的了解。 在对话中，我们的合作伙伴告诉了医生如何工作的细节，并解释了业务目标。 反过来，我们解释了技术上的细微差别，并显示了各种非显而易见的情况。 这使我们能够制定满足医疗机构需求的产品要求，并且在实施成本方面是最优的。
总结
工作流程的灵活性和对业务需求的关注使我们能够克服开发过程中出现的所有困难。 我们已经成功为欧洲医疗机构制作并启动了该应用程序的新版本。
现在，我们继续开发产品并推出新功能。 我们研究了真实用户如何使用该系统，收集了未说明的案例和用户案例，并确定了新的业务价值。
通常，在创建产品的新版本时，开发人员将面临与我们相同的问题，例如：
- 业务方面的错误假设是可能的；
- 用户的需求存在矛盾（保留一切不变或以新的方式对其进行重新制作）；
- 有时有必要重组团队的工作以取得更好的结果。
最主要的是，IT产品的新版本的发布不是从先前版本的“ Ctrl + C”，“ Ctrl + V”代码的副本，而是从头开始的全面开发。 这是因为业务流程，用户需求以及IT解决方案市场的状况正在发生变化。
感谢您的关注！ 希望本文对您有所帮助。