How To Do POC

What is POC

POC，Proof of Concepts，中文译作“概念验证”，指对某些想法的一个较短而不完整的实现，以证明其可行性，示范其原理，目的是为了验证一些概念或理论。
In brief，我们从商业活动或者工作业务中发现了某个需求，想要为此启动一个项目方案。在进入代码层面的工作之前，很可能要事先确定好这个方案的可行性和成本、价值；而POC这种手段，就为我们提供了一种深入浅出的方法论。

POC of Architecture

架构的POC，目的是在于撷取出最核心的解决方案，以作为解释架构的概念依据。

架构POC具现化后的可能样貌：

Framework/Pattern: 解决方案所需的相关技术
Sketch: 利用UML语法建立概念模型草图，以表达一解决方案
Simulation: 利用模拟的方式提出解决方案
Prototype: 可以被执行的原型

Prototype

Prototype可以：

通过Prototype，大家比较容易对概念产生共鸣，并致力于改变未成形的东西；
Prototype可以协助架构的建立，帮助从整体、宏观的角度看待复杂系统，避免一头栽进种种细节；
Prototype可以将目标清晰地描绘出来，让每个stakeholder都更容易提供意见、进行改革；
其对系统内部的结构分析与设计的实现，也能协助成员形成一番基本认知；
在架构落实前，让团队自由表达看法，并进行讨论、提出建议；
让团队成员随时表达意见，有机会影响你正在着手进行的方案；
不断加快前述两步（一般称之为“快速建构原型”）。

Prototype的内容，包括：

能表达整个系统的使用案例模型；
几个具代表性的使用案例，可能附带概念性的类别图或顺序图；
平台依赖的细节类别图与顺序图；
确定可输出、可执行的程序代码和测试代码；
简单的UI图，作为执行画面的呈现与说明。

Prototype并非是粗糙或应付性的，它应该是一个闭环，是可验证的，但并非仅利用外表好看的UI界面来对系统作POC。Prototype of Architecture，UI不是其重点，而应是一种对系统的整体结构观的强调。对系统整体有了正确的认知，往正确的大方向走后，才确定要做的细节性工作，可以把它做对。人们，尤其是组织性的团队，最常犯的错误是：把不必要的事情做得太好。

Technology Stack

很多解决方案的架构都会形成一种“堆栈”式结构，就像体系结构中的网络层次一样。
技术栈的设计与呈现常常作为POC的重要组成部分。

Standards

作为解决方案设计的一部分，POC的评估标准有待被定义。对于工程师，这些标准可以被转化成能够设计、衡量、持续自动化测试的评估标准。
以AI行业的解决方案为例，我们可以设置三个方面的评估标准，分别评估方案的商业价值、运行状况、决策质量，包括

准确性、完备性、时效性；
扩展性、兼容性、灵活性、工程性；
偏见/偏差、公平公正、因果联系、透明性、安全性。

POC Test

在POC方案制定好后，进行产品的原型方案的安装测试，调整测试环境，考虑用户方的需求逐条开展测试，用户方记录测试结果。

Vertical Extended POC

在POC已经成功构建、测试和部署之后，还有一些用户需求之外的概念需要考虑。
虽然说，积极的用户体验有利于提升用户需求，以获得更大的成功；但是，POC也会因此遭遇风险，成为对用户体验过多关注的牺牲品。为了确保POC持续保持成功，为方案战略提供支持，可以增加纵向扩展能力和解决方案可迁移能力的考量。粗略来讲，就是不要随便押宝在某一个狭小的领域，项目的开发方向往往是充满变化的。

POC (Proof of Concept)