跳到正文

网络服务开发

我们创建客户账户、业务系统和独立在线产品。根据首个版本上线后从用户处得到的认识,规划规则如何调整、流程如何发展。

你让用户自己完成什么?

在客户账户中,用户可以跟踪申请、选择条件或支付订单。我们与你一起确定服务应让用户独立完成哪项操作,以及企业需要为此提供什么。

首个版本覆盖从开始操作到获得结果的完整路径,包括员工处理订单的环节。

首个版本

可运行的原型让团队在正式开发前试用想法,发现遗漏的细节。在测试中,我们决定哪些发现纳入首个版本,哪些取代原先的方案,哪些需要单独验证。这样,上线时客户和员工就能使用完整流程。

用户改变决定时会怎样?

用户可能返回上一步、关闭标签页,或者再次点击按钮。服务在这些情况下也必须清晰。

我们检查输入的数据是否保留、错误能否修正、客服人员会看到什么,并分析具体情况。例如,用户已支付订单,但确认页面未能加载。钱已经扣除,而用户尚不知情。

订单已经付款。接下来呢?

一笔订单,一次付款

重复点击不会产生新的付款。服务检查第一笔付款的状态,并显示同一订单的确认信息。

订单仍留在账户中

关闭标签页不会取消已收到的付款。用户回来后能看到已付款订单,从中断处继续。

员工知道发生了什么

员工能看到订单编号和付款状态。用户无需重新说明购买过程,也不用截图证明付款。

为后续版本做好准备

界面、业务操作规则和数据存储变化的原因不同,因此在服务架构中将它们分开。

我们讨论可能的改进,包括新连接、服务方式和访问量增长。决定哪些需要现在准备,哪些灵活性暂时不值得付出成本。评估首个版本费用时,也考虑日常运行、访问高峰和维护的开支。

服务的不同部分因不同原因而变化

客户独立完成操作
你的团队管理规则和业务
用户体验
操作规则
数据存储
  • 客户管理与财务
  • 支付
  • 通知

决策背后的原因

在移交之前,我们就让未来的产品负责人参与讨论。一起分析一项后续改进:它会影响什么,哪里能找到所需信息,发布前应检查什么。具体任务能表明团队理解哪些决策,还有什么需要进一步解释。

团队继续工作

我们交付代码、访问权限、连接说明,以及发布和恢复指引。

另外明确哪些属于企业资产、哪些依许可使用、哪些外部服务需要维护。凭借这些材料,企业员工或选定的开发人员可以继续工作。讨论下一版本时,团队会了解产品的运作方式和这样设计的原因。

可能包含的工作

    1. 选择时间
    2. 支付并确认
    3. 登记到日程

    预约服务

    预约、支付及日程管理。

  • 合作伙伴门户

    经销商订单、个性化条款和文件。

  • 在线配置工具

    选择配置并计算费用。

  • 教育平台

    课程、作业和学习进度。

工作如何组织

确定任务

选择用户应能独立完成的事情。分析企业如何处理用户请求,并确定首个版本的范围。

您提供的资料
想法或原型、任务说明及企业系统信息
阶段成果
首个版本的范围、用户角色和连接清单

测试原型

向未来用户展示服务将如何运作。检查操作是否清晰,并在开发前完善方案。

您提供的资料
用户和员工参与、示例数据
阶段成果
原型及开发任务清单

开发服务

搭建界面并连接实际业务系统。检查数据访问、错误处理和故障恢复。

您提供的资料
资料、系统访问权限和审批负责人
阶段成果
经过流程测试的可用服务

交付给团队

讲解服务架构,并一起分析一项未来改进。展示如何发布更改和恢复运行。

您提供的资料
未来负责维护服务的团队
阶段成果
代码、访问权限、操作说明及决策依据

我们检查什么

  • 数据访问

    检查每个角色允许执行的操作。

  • 市场与无障碍

    记录各国要求并测试主要流程。

  • 恢复运行

    检查备份及恢复服务的方式。

我们交付什么

  • 源文件与项目代码仓库
  • 访问权限与外部连接清单
  • 更新与恢复说明
  • 权利及所用许可的文件
  • 用户操作、数据交换和访问权限说明。

服务应该解决什么任务?

告诉我们人们应该能做什么,并展示想法、原型或现有产品。我们会讨论首个版本的边界、接手团队的工作以及成本估算。

讨论项目

确认工作安排后

  • 主要流程说明
  • 服务内容与运行规则
  • 负责人及所需系统的访问权限