感觉成功的从机械攻城狮窜到了程序猿，遇到了很多新的知识，各种新的名词。inception 最近三四个月断断续续听过几次，一直不明白到底做什么的，有幸参加为期两天的培训，大体上了解了 inception 的流程，特此记录一下自己的感想。
本文内容不是记录知识或者一系列定义、方法论的堆积，也许我的另类视角会为您带来新的理解。
What and Why
Inception 的实践源于 ThoughtWorks 长期做定制交付软件的实践经验
在变化无处不在的环境下，力求设计?种流程，尽可能降低假设带来的潜在伤害。一般是在3天到两周时间里，将相关干系人召集，就产品方案和交付范围讨论，力求达成一致（短期快速、集中互动、达成一致）。
通过短时间的、高效率的讨论及分析，实现 context 的快速交换，且与团队 / 合伙人共同研讨，使双方有更多的合作性、参与性。
在 inception 过程中可帮助相对迷茫的参与者或者需求发起者更好的认知自己的目的，也许谈出的最终结果与开始的设想天壤之别也并非不可能，当然也可能将不切实际的想法、不符合市场供需的需求及时的扼杀，避免盲目直接开发带来的无谓投入。
短期小团队
inception 过程中，相关干系人包括但不限于：业务、开发、UX、市场、PO 等交付团队以及需求决策层。这么多人的聚集，必然要有一定的“组织者”、“主导者”，可以根据需求的类型决定主导者。
Inception 目标
我感觉，从一个产品的生命周期来看可能更好，无论是需求提供方还是需求实现者，大家组合成一个共同的团队，为一个产品的生命及生存去考虑，创生并维生。
明确产品策略
此生命的存在意义？产品的愿景、定位实际上就是生命的价值，团队明白这个生命的价值，才好为其后续如何让生命更好的生存去合理的考虑
明确交付范围
此生命的形态是什么？一个复杂的生命体包含多种部分，联合构成一个完整的生命体，了解目标的生命形态，有助于预计创生过程的复杂性、难度。
明确产品发展蓝图、产出交付计划
此生命的核心是什么？总要有个优先级，生命孕育的过程不可避免的有先后顺序及侧重点
明确基础设计和技术框架
无论是站在巨人的肩膀，还是自己造轮子，创造的过程不能盲目乱跑，尤其是多人协作的情况下，总要有一个大的框架
快速进入交付：let’s go
简易流程
排名不代表顺序、重要性。具体的内容也并非必须，这里实际上是对 inception 目标的细化，每一步具体如何做，也包括了每一步行为的产出物
准备和计划
- 项目及人员信息检查
- 业务背景
- 竞品分析
- 客户信息
- 技术检查
- 物料准备
- 流程计划
初步的探索，包括对合作方的了解以及要共同创造的生命要面对的过去、现在、未来进行初步分析，当然多人参与一两周活动肯定还不可避免的要进行日程安排
愿景对齐
- 产品愿景与定位
- 精益价值树
- EDGE
- 商业模板画布
- 电梯演讲
- Trade-off sliders
- Objective Statement
- 干系人地图 / 干系人分析
先了解合伙人，对产品的发展要有共同的认识，目标一致才好合作
现状分析与痛点识别
- 用户访谈
-
用户画像
- 用户体验地图
- AS-IS 用户旅程地图
- 业务流程图
- 服务蓝图
- 调研问卷
- 现有数据分析
- 痛点识别
- 现状分析报告与痛点
作为创造者，要想让所创造物能够生存下去，一定要“设身处地”。这里算是真的设身处地了，从最终产品的直接、间接干系人入手，来了解未来产品需要面对的
业务方案规划
原型设计
领域建模
技术方案规划
交付计划
最终汇报
短时间内学到了很多“手段”去帮助团队在短时间内尽快的对产品的生命周期进行宏观规划，从 inception 团队成员的相识相知、到最终产品的创造方案，同时在每一步骤中以一定有目的的产出物帮助团队快速 facus 到当前流程，提高每个时间片的效率。
日程安排
日程要具体到到上午、下午的工作安排，工作内容、参与人。
并非所有活动都要所有人的共同参与。整套 inception 流程及每个步骤开始前也要确保参与人对所要做的事情有所了解，必要时候要进行介绍及示例，保证所有人都有参与感。
电梯演讲
- 对于（目标客户 / 用户）
- 他们想（需求痛点的阐述，产品价值产生的根本原因）
- 这个（产品的名字）
- 是一个（核心产品或服务类型）
- 它可以（产品的关键能力）
- 但它不同于（竞品的名称和特点）
- 它的优势是（与竞品比较的独特价值）
就是从使用者的角度出发，讲述“为什么”使用这个产品。那为什么不能像写简历一样，从产品的角度出发，写一写它能做什么？
我观察到（环境、背景）
作为（具有 XX 关键能力的产品）
我可以（主要功能点的阐述）
这使我能够服务于（什么类型的客户）
在（场景）下
我的优势是（比竞争对手的优势）
当然，我们的产品往往是需求的驱动，从使用者来推导出产品的功能点、特点，不会有逻辑的断点，信息采集过程以及推演的过程更加便捷。
但我不认为从产品角度出发是完全没有价值的，最少于代入感上来说，后续开发者可以更容易理解我们要创作的是什么。除此以外还有探索性的产品，此时从产品角度考虑可能会有意想不到的效果。
用户画像
通过一系列数据的汇总，描绘出产品受众的画像(User Persona)，包括用户的基本信息、特征、一般的行为、对事物的观点。
注意给这个用户一个名字，而不是一个类型名，方便讨论
这一部分我更想思考的是，画像的时变性（User Profile），在汇总信息以后，取其精华去其糟粕，我们得到了一个或者多个主要受众类型，并赋予这些类型一个个名字，但人在使用过程会有一系列的演变，可能由于身边的环境、也可能是因为当前的产品好用我想让它更好用。
这种“手段”可能很适合大型系统、产品等相对变化缓慢的产品，或者具有夯实领域特性的产品，对于追求“时髦”、“前沿”的飞速变化的产品可能并不够适用。对于探索性、概念性的产品，可能更无法从普通受众获取足够有效的信息，又或者会获取到各种天马行空的内容……那此时可能会很难取舍。
当然，最终的产品创作过程肯定是有一定目的的（自己想一个目的也是前进的动力），有目的就一定有期望的受众，或者想要针对一拨人打造出一种新的生活 / 工作等使用方式。
事件风暴
领域建模作为业务建模与代码建模的桥梁，在 Inception 中可以使用的，通过对业务需求 / 遗留系统的梳理，整理出事件、命令、领域对象、聚合、角色、外部系统、决策，最后划分限界上下文识别问题域。
就如同好多论文开始会写“术语表”一样，统一用语，拉齐概念有助于提高理解的效率、正确性。
生命体在内有基础的新陈代谢和复杂的思考人生的思想，在外有与外界的各种交互动作。
看到红灯就停下脚步，这是输入驱动带来的输出。
肚子饿了去吃饭，这是内在的变化带来的输出。
天黑了，光线逐渐降低，但还是有很多公司仍然灯火通明，输入的“时间”并没有带来下班的响应。
很困，但这篇文章还没写完，继续坚持，虽然我越来越困……内在的变化持续不断但没有什么特别的输出。
……
事件本就是结束，但可能没有终止，其影响有可能终止于某一刻，也可能激发起一系列其他事件，也可能石沉大海，当前事件的结束不意味着它未产生任何影响。
事件一定是有始的，起源于某一点，可能是外界也可能是自发。无论何种事件一定有迹可循，其表明一个已经发生过得行为。
……
The End
还有很多匆匆带过的知识并未记录，从冰山一角谈论这种多人参与的时间紧凑的高效率的活动，可能理解的过于皮毛、片面。最后谈谈个人理解
前瞻与沟通
inception 就是由需求引起的从产品生命周期角度，根据当前市场行情及技术现状，从相对全局性的角度，对项目进行前瞻性分析，并落实一定指导性的图文内容。这些“指导性图文内容”只是指导，其更偏重于全局视角，从“指导”到最终的“沉淀”不可避免遇到前瞻无法预料的问题，随时变产生的蝴蝶效应是后续开发过程中不可忽视的经历。
沟通无处不在，一场争论可能是两个心灵之间的捷径
“无声”的生命
也许阅读本文过程中，可以发现本文的角度有所不同吧，我更多地是从这个产品、这个生命的角度出发去看待 inception。所以本文更多地提及“团队”、“参与者”、“需求提供者”，而不是“客户”、“技术”等等。
大部分开发团队虽然会谈及生命周期，但那只是一种分析手段，确实从团队关系来看有时候认为开发团队是产品的缔造者，而为团队开发买单者或者说需求的提供者被当做客户。
但既然谈及了生命周期，为什么不真的当做生命来看？无论是机械制造产生的实际物质（跑在路上的汽车；周而复始运转的工业机器；实时待命可被唤醒的手机），还是被一行行代码逐渐构造出来的程序（在桌面上为我们提供友好可视化操作体验的桌面应用；在手机中为我们提供与世界连接桥梁的 APP；在汽车、手表、红绿灯里默默地为我们提供着信息的嵌入式程序；在高高在上的云端服务器里不断忙碌的服务软件）
从生命角度来看，inception 所有参与者都是为了创生，而不断地交流讨论是希望这个生命可以立足于市，而整个 inception 团队研讨过程可以为未来真正的创生过程提供有力的全局视角支持。团队任何一个人都是这个生命诞生的贡献者，所做的行为无论是灵感的贡献、市场分析、业务探索、交互方案、技术开发都是为了给后续创造一个好的基石。
从生存的角度看，最终的产出物 — 产品，其在“社会”上能够生存下去，就是价值的体现。
| 版权声明: 本站文章采用 CC 4.0 BY-SA 协议 进行许可，转载请附上原文出处链接和本声明。
| 本文链接: Cologic Blog - 初识 Inception - https://www.coologic.cn/2019/12/1706/