从业务想法到可投入生产的数字产品
创新并不会因为一个想法有趣就产生价值。价值产生于想法变成一个清晰的问题、一个具体的使用者、一个站得住脚的产品概念、一个真正可用的方案、可衡量的业务价值——以及一个在生产环境中确实能够被维护下去的东西。
大多数想法就消失在这些步骤之间。要么问题从未被想得足够清楚，要么原型被误当成了产品，要么产品在演示里运转良好，却扛不住真实用户、真实数据和真实的系统对接。
VODIS 支持从概念走向可用数字产品的整条路径——为客户、与合作伙伴共同进行，或在自身的产品尝试中——在速度、架构、安全、易用性与长期可维护性之间取得平衡，而不是把这些全部让位给一个快速的首版。
不同的想法，同一套产品纪律
同一套纪律服务于三种相当不同的情形：
- 面向客户的定制开发——为某一客户的业务需求、运营流程、客户、员工或技术生态而构建的产品或应用
- 与合作伙伴共同开发——与技术或业务伙伴一起打磨想法、设计方案、结合互补能力，并共同构建产品
- VODIS 自身的产品尝试——VODIS 也可能开发自有的工具、可复用能力、加速器与产品概念。这里描述的是一种能力，而不是一份目录：本页并不宣称已有任何产品组合
商务安排、知识产权安排与运作方式按每一次合作分别约定。此处不预设最终谁拥有什么：知识产权、许可与所有权通过合同约定，而不是默认成立；也不存在任何既定的收益分成、股权安排或合资约定。
这类工作可以与欧洲在数字化、创新与竞争力方面的优先方向相契合，意思是这些产品服务于那些目标。这是关于工作内容的陈述，而不是关于资金的陈述：VODIS 不宣称具备任何补助资格、项目资格、研发税务待遇，也不宣称拥有获得公共资金的任何权利。
从业务问题开始
在做出任何技术决定之前，少数几个问题就能完成大部分工作：
- 究竟要解决什么问题，并且在陈述时不提及任何方案
- 使用者是谁，他现在的一天是怎样度过的
- 涉及哪一条业务流程，它今天卡在哪里
- 产品应当创造什么价值，为谁创造
- 哪些约束真正重要——监管、运营、技术、商务
- 现有的哪些东西已经承担了其中一部分
- 它必须与什么对接，那些系统归谁负责
- 成功将由谁、依据什么来评判
并不是每个业务问题都需要人工智能，也不是每个业务问题都需要一个新应用。正确的答案有时是一次集成、一次自动化、一次简化、更好地使用组织已经付费的平台，或者一次流程调整。早点说出来，比建完之后才发现要便宜得多。
产品探索
产品探索是短的、有结构的，并且指向一个决定——而不是伪装过的需求规格阶段：
- 界定问题并识别相关方
- 用户与业务的需求，通过了解获得而不是靠猜测
- 产品目标，以及承载这些目标的使用场景
- 范围：什么包含在内、什么被有意排除，以及为什么
- 功能需求，细到这个决定所需要的程度
- 非功能需求——性能、可用性、安全、数据
- 从既有技术版图继承而来的架构约束
- 价值假设，写成可以被证伪的形式
- 按价值、风险与工作量排定优先级
- 一份真的有人能据以开工的最小可行产品定义
产出是足以据以启动第一次构建的清晰度，而不是一份在任何人学到东西之前就把产品冻结的文档。
在规模化之前先验证想法
早期原型的存在是为了回答问题，而且通常比为此争论的那场会议更便宜。它可以验证：
- 使用体验，并且是与真的会使用它的人一起验证
- 困难部分的技术可行性，而不是容易部分
- 在真实数据上的人工智能可行性，前提是人工智能确实在范围内
- 与那些真正重要的系统之间的对接可行性
- 端到端的流程，包括那些别扭的例外情况
- 所有人一直当作事实来对待的那些假设
原型不是产品。它有权是狭窄的、未经加固的、用完即弃的；把它当成可以投产的东西，是这项工作中最常见也最昂贵的错误之一。
最小可行产品是下一步，也是另一回事：产品中最小的、仍然有意义的版本，同时品质仍足以产生可信的反馈。它不是廉价的半成品软件——而是一个刻意收窄、但确实能用的产品。
- 核心流程，端到端，面向一个真实的用户群体
- 那些一旦缺失、产品就只剩演示价值的对接
- 一个无需专门培训就能上手的界面
- 埋点与度量，让使用情况可以被测量而不是被争论
- 数据与场景真正需要的那一层安全
- 一条事先规划好的验证与反馈闭环，而不是临时应付
描述这条路径的一个实用说法就是：探索、设计、做原型、构建、验证，然后运营与演进。这是一个合理的顺序，而不是什么专有或经过认证的方法论，并且会按照客户的工作方式加以调整。
围绕业务需求构建的应用
视具体情形而定，交付可以围绕这一类应用来组织：
- 网页应用以及面向客户或伙伴的门户
- 内部业务应用与运营工具
- 流程、审批与案件处理类应用
- 仪表板以及报表或分析类应用
- 基于既有数据资产构建的数据驱动应用
- 针对某一具体业务决策的决策支持应用
- 在本来并非为彼此设计的系统之间做集成服务
- 对重复性运营工作的自动化
- 把某项能力干净地开放给其他系统的接口
- 人工智能赋能的应用，前提是使用场景确实需要
- 在既有应用之上的扩展与新功能
- 对已有产品的架构演进、投产加固与技术债削减
新应用很少独自存在。集成工作通常涵盖接口、数据交换、身份与权限、流程、企业平台、事件或消息层，以及与那些不会被替换的系统共存。此处不宣称拥有万能连接器：每一次集成都取决于对方系统实际开放了什么。
如果起点是一个既有系统而不是一张白纸——尤其是必须先理解才能改动的老系统——这类工作与遗留核心系统现代化服务并肩而立，而不是重复它。
产品中的人工智能——与工程过程中的人工智能
这是两件不同的事；把它们合并成一句含糊的说法，是制造错误预期最稳妥的办法：
- 人工智能赋能的应用——人工智能是产品本身的一部分，被产品所服务的人看见并使用
- 人工智能辅助的工程——人工智能帮助工程团队分析、构建、测试、编写文档并演进产品，而产品的使用者从来看不到它
一个产品可以只有其中之一、两者都有，或者两者都没有。把它们当作同一种能力，往往会得到一个被当作“智能”卖出去的产品，以及一套其实没有改变的工程过程。
人工智能赋能的应用
在业务论证站得住脚的地方，应用可以包含如下能力：
- 在明确且有边界的任务内使用生成式人工智能
- 限定在某一角色或流程范围内的企业助手
- 在获批的组织知识范围内进行检索
- 文档的抽取、分类与校验
- 对冗长或零散材料的摘要
- 在既有功能之上的自然语言界面
- 起草与建议、而不是替人决定的流程辅助
- 以选项形式呈现并附带理由的推荐支持
- 对运营数据的分析与模式识别
- 会展示其输入依据的决策支持
- 对判断成分低的重复步骤做智能自动化
- 把工具、接口与规则结合起来的受控代理式流程
并不是每个产品都需要其中任何一项。当人工智能比其他方案更好地解决了问题时，它就值得占据一席之地；当它并非如此时，它带来的是成本、延迟、评审负担与新的失效方式。
在使用组织知识检索时，价值来自把答案锚定在获批的来源上，并让这些来源可见，从而使答案可以被核对。这能减少缺乏依据的输出并使核实成为可能；但它并不能消除错误答案，本页也不作此主张。
当产品把人工智能与工具、接口和流程结合起来时，VODIS 会把它们设计成受控的代理式流程：范围有边界、工具有定义、以规则设限、留有日志，并在关键节点设置人工审批。对于有后果的决策，适当的人工控制与验证仍是设计的一部分。完全自主的决策既不被宣称，也不是目标。
人工智能辅助的工程
在工程过程内部，人工智能辅助可以在以下方面支持有经验的团队：
- 需求分析，以及规格说明留下的那些未决问题
- 在已经过评审的设计之内生成代码
- 解释不熟悉或没有文档的代码
- 重构与结构性清理
- 生成测试、测试数据，以及覆盖那些别扭的路径
- 文档，否则它通常写在最后，或者根本不写
- 排查缺陷与根因分析
- 在人工评审之前先做一轮代码审查
- 对较老代码库的迁移分析
- 占用资深人员时间的重复性实现工作
运用得当时，这可以缩短工程周期、减少重复性手工投入、提升一致性，并放大工程的杠杆效应。是“可以”，不是“一定会”。VODIS 不公布任何生产力百分比，也不承诺具体的提速或降本幅度，因为任何诚实的数字都取决于代码基线、业务领域与团队本身。
人的责任
人工智能辅助的开发并不消除对有经验工程师的需要。以下事项的责任仍由具名的人承担：
- 产品决策，包括决定不做什么
- 架构，以及其背后的取舍
- 安全设计与安全评审
- 代码评审，无论初稿是由什么产生的
- 测试，以及对“测过了”在此处意味着什么的判断
- 业务验证——它确实解决了原本要解决的问题
- 把某个东西投入生产的决定
- 投产之后的运营责任
借助人工智能产出的工作，与其他工作一样要经过评审。交付物的责任不会转移给工具，本页也不宣称人工智能取代开发者，或者软件开发可以自主运转。
为持续演进而构建
原型优化的是学习。生产系统必须优化上线之后的那些年，这是另一个问题：
- 可维护性——明年换一个人，他能不能安全地改动它
- 与现实需求而非想象需求相称的可扩展性
- 在对方系统发生变化时仍然成立的集成
- 与数据和暴露面相称的安全
- 韧性，以及某个依赖出问题时的合理表现
- 可观测性——能回答真实问题的日志、指标与链路
- 数据的管理、归属、留存与质量
- 可重复执行的部署，而不是靠人记住的部署
- 可支持性，让真的有人能够运维它
- 把同行评审与自动化测试当作日常，而不是某个阶段
- 依据约定标准进行的集成测试、回归测试与验收测试
- 在产品确有必要时进行性能测试与人工智能效果评估
这一切都不承诺零缺陷，本页也不把任何一次合作描述为交付无缺陷的软件。它让缺陷变得可发现、可理解，并且修复得起。
安全与数据掌控
安全是设计的输入，而不是最后的一次评审。视产品的敏感程度而定：
- 身份与权限设计，默认采用最小权限
- 不能只靠自觉的密钥与凭据管理
- 融入日常工作流的安全开发实践
- 与场景相称的日志与审计
- 数据分级，使保护强度与数据本身相称
- 在确有必要处使用加密
- 依赖项与软件供应链管理
- 与风险相称的安全测试
- 把隐私与数据保护要求当作真正的需求
- 哪些数据会发送给模型，哪些被有意排除在外
- 模型与服务商的配置、留存与日志设置
- 访问、保密、个人数据，以及数据存放地或数据治理方面的约束
人工智能赋能的产品尤其值得关注最后这一组，因为造成数据保护问题最简单的方式，就是把超出使用场景所需的内容发送出去。当环境有要求时，架构可以采用经批准的企业级人工智能服务、私有环境、本地模型运行或受控云——与遗留核心系统现代化服务中的思路一致。
VODIS 在这项工作上不持有任何正式认证，也不作此宣称；本页不提供任何安全方面的保证——安全是被设计、被证明、被评审出来的，而不是被承诺出来的。
生产是另一套标准
走出最小可行产品是一个决定而非例行手续，而且并非每个最小可行产品都该走这一步。真要走，这一步通常包含：
- 在最小可行产品有意走了捷径的地方加固架构
- 把安全做到真实运行场景所要求的水平
- 一套有人愿意真正依赖的测试
- 像样的环境，彼此隔离且可重建
- 版本控制，以及自动化的构建与测试
- 持续集成，以及受控且可回退的部署
- 监控、告警与日志管理
- 演练过而不只是配置过的备份与恢复
- 运维流程与明确的支持模式
- 技术文档与运维文档
- 面向未来接手者的交接、知识转移与培训
- 上线之后产品有明确的归属人
对于归客户所有的产品，目标是客户自己的团队能够在不依赖 VODIS 的情况下运维并改动产品。若希望更深入地建设自身能力，这自然与人工智能与技术培训服务相衔接。本页不规定任何特定云厂商或供应商的方法论；交付流水线跟随客户的环境。
一次合作可以如何设计
形式取决于要回答的问题，而不是某个标准套餐：
- 一次产品探索，以一个决定而不是一份文档收尾
- 针对某个具体不确定性的原型或概念验证
- 交付给特定用户群体的最小可行产品
- 对已约定产品增量的范围明确的开发
- 在范围确实仍在变动时采用按工时与材料计费
- 在较长周期内的专属或扩展产品团队
- 受管的产品交付，由 VODIS 承担交付结果
- 与合作伙伴的共同开发安排，按合同具体条款执行
商务条件、费率与工作量按个案协商确定，不在此处公布。当瓶颈在于工程产能时，这项工作与近岸技术交付服务并行；当产品只是更大转型中的一部分时，则与项目与变革管理并行。
产品治理保持适度——足以做出决定，但不至于喧宾夺主。视合作情况，它可以涵盖：
- 产品负责人与发起人就“什么最重要”达成一致
- 有人对其负责的待办事项优先级
- 一份在证据出现时允许被修改的路线图
- 连同其理由一并记录下来的架构决策
- 事先约定的发布决策与验收标准
- 公开作出的风险决策，而不是被悄悄消化掉
- 与场景规模相称的变更控制
- 构建、度量、学习、演进——用使用情况、反馈、性能、质量与采纳度支撑下一个决定
最后这条闭环属于普通的产品实践，而不是什么专有方法；而且只有当埋点在足够早的阶段就被设计进去，它才能产出值得一读的依据。
产品类型示例
以下是这类工作可能产出的示例，而不是 VODIS 既有产品的清单：
- 一个取代电子表格与邮件的内部流程应用
- 一个限定在具体角色范围内的员工助手
- 一个用于抽取与分类的文档智能工具
- 一个面向客户或伙伴的门户
- 一个流程与审批应用
- 一个基于既有数据构建的报表或分析工具
- 一个基于获批内部来源的知识助手
- 一个面向特定团队的运营仪表板
- 一个由人工智能赋能、并保留人工复核的客户支持工具
- 一个面向特定行业的数字应用
- 一个位于既有系统之间的集成或编排层
- 一个为既有产品补上的度量与埋点层
技术选择跟随产品、架构、客户环境与各项约束。本页有意不公布技术栈清单，也不宣称在每一种技术上都具备现成能力。
可能的产出
视约定范围而定，一次合作可以产出：
- 一个产品概念与一份使用场景定义
- 一份产品与技术路线图
- 用户流程与界面设计
- 一套解决方案架构
- 一个原型或概念验证
- 一个最小可行产品
- 一个可运行的应用
- 接口与各项集成
- 一项人工智能能力，前提是它在范围之内
- 一套测试与测试证据
- 一条部署流水线
- 技术文档与运维文档
- 交接材料与知识转移
- 一套面向下一个决定的度量方法
以上是一次合作可能包含的示例，而不是固定的交付物清单；其中任何一项都不构成对交付日期、成本结果、生产力提升、投资回报或市场成功的保证。真正适用的内容，在工作范围中约定。