POC正确做法：目标清晰化，与"POC不同于MVP"

好的概念验证（POC）通常能在3~5天内做出一个原型应用，最关键的一点是：这个结果本来就是要被丢弃的，一定要牢记这一点——POC唯一的目的是证明项目能够跑通，包括与具体情况相关的所有方面，需要事先想清楚的问题包括：能否在现有架构和工具栈里用上工作流工具？开发方法适合组织现状吗？能不能模拟出具体的业务领域问题？不同角色各需要什么专业知识？这样的项目大概要投入多少精力？流程自动化对运维会有什么影响？为了快速拿到结论和有针对性的反馈，可以找工作流厂商或专业顾问一起做，但要真正理解发生了什么，自己团队至少要参与开发，理想团队规模是2~4人。规划POC之前必须先明确清楚具体目标，因为它会显著影响POC的走向——比如本周末前展示一个漂亮的用户界面重要，还是把所选工作流引擎的所有技术疑问都摸清楚更重要，甚至可能只需要做一些单元测试就够了，最好把这类取舍想清楚、做出明确选择。POC常见目标包括：验证方法或工具在特定场景下是否有效；向内部利益相关者展示一个可信的案例；完成一个完整示例、解决某个具体问题；更深入了解这个工具的原理。团队应涵盖业务领域知识、有针对性的技术方案与建模语言（如BPMN）知识、分析与审核技能，确定一个主导者能避免走太多弯路，和有经验的顾问一起做也是让团队边做边学的好方式。有些公司想直接做最小可行产品（MVP）而非POC——MVP已经提供一定价值、不会被扔掉，这是二者的最大区别；作者认为把这样的MVP投入生产、贯穿整个生命周期持续学习确实很有价值，但仍然主张先做完POC再考虑MVP：POC应被视为验证架构的简易原型，扔掉它、从头开始才是最优选择，因为这样能让团队专注于学习本身，而不是急着写生产级代码，反正POC投入的时间本来就只有几天，成本不高。