作为一个Inception小白，只是听别人说起过Inception，但是没有正式参加过。这次作为dev参与，激动之余，也是有些疑惑的，作为技术人员，在Inception开始之前需要做些什么准备？在Inception上每天都要做些什么？最后的产出应该是什么？
由于Inception的主要目标是挖掘用户的痛点和真实需求，并且基于这些痛点和需求划定scope和划分milestone，因此技术人员需要参与进去进行技术评估、制定解决方案以及对工作内容进行工作量的估算。在Inception上给出的解决方案以及工作量的估算都会后期的交付工作产生很大的影响。
技术架构一旦定下来，后期如果再需要进行更改，就会花费很大的精力，而且Inception是很难得跟客户一同工作的时间，客户会尽量的把他们的需求说出来，因此此时一定要尽量的考虑全面，了解用户的完整需求，即使在开发的前期不要那么重的架构，也要为后期的改动留出一定的余地。
不仅是技术架构，估算工作量也是一个很重要的工作。工作量估算的过小，在开发交付的时候就会对交付团队产生很大的压力，有一些风险、难点没有考虑到也会对交付产生影响。如果工作量过大，则会让客户产生不信任感。因此在估算工作量的时候要尽量做到准确，基本保证每一点工作量都可以跟客户解释清楚用在了那里、每个功能都要做哪些工作。而且对于一些不确定性，也要写明是基于什么样的假设来进行的估算，为后期的需求变更、假设变更留有一定的余地。
由于这次参与Inception的Tech Lead是一个很资深的Tech Lead，而且非常的有耐心，因此这次也算是长了不少见识，不仅将上述的疑惑得到了解答，也从他身上学到了很多东西。
在Inception开始之前要做哪些准备工作？
-
列出在Inception上技术人员的工作内容，如:
技术部分需要考虑：
- 技术架构
- 部署架构
- 技术栈选型
- 安全策略
- 测试策略
需要做的事情：
- 调研已有系统情况
- 调研项目需要的系统集成，以及集成方式
- 调研客户的技术制约和规定
- 调研非功能性需求：安全、性能
- 确定技术架构、技术选型、测试策略和潜在风险
- 对工作量进行评估
需要进行技术环境访谈和评估的内容：
- 客户方技术组织架构
- 客户方技术流程
- 客户方已有系统关系图
- 基本技术假设
- 技术风险
- 客户方的技术预期
需要根据哪些内容来及时识别Scope的变化：
- 组织结构
- 关键决策人
- 业务述求
- 技术述求
对一些不熟悉的技术进行调研
由于在Inception开始之前可以得到关于项目的一些基本信息，例如项目是要做一个怎样的东西，是一个产品、平台或者工具，客户大概的期望是什么样的，希望解决的是怎样的问题。因此可以根据这些输入有一个大致的技术实现方向，对这个实现方向进行一些现有技术的调研。
在Inception上每天都要做些什么?
以下是我列出的一些个人在本次Inception中对于需要做的内容的总结：
- 了解技术现状
- 了解具体需求
有以下几个可以参考的维度:- 使用条件
- 环境限制
- 输入是什么
- 输出是什么
- 信息集成角度
- 产品都与哪些系统进行交互？
- 产品和不同系统间如何交互？
- 产品和不同系统间信息传递的需求是什么？
- 产品和不同系统间的数据如何关联？
- 产品和不同系统间的集成测试策略、环境？
- 扩展性角度
- 产品的主要业务变化方向？
- 遗留系统角度
- 产品属于遗留系统改造还是全新业务？遗留系统的现状？
- 需要迁移的遗留数据情况？
- 遗留系统改造预期？
- 数据价值化的角度
- 客户对产品数据价值的预期？
- 产品的数据呈现预期？
- 性能角度
- 客户的并发访问需求？
- 瓶颈体现在哪些地方？
- 安全角度
- 客户目前的安全评估要求？
- 运维角度
- 客户产品运维团队的工作方式？
- 生成环境情况？
- 部署上线方式？
- 用户角度
- 重用角度
- 成本角度
- 交付团队角度
- 能力搭配
- 特殊能力
- 开发环境的制约？
- 整体方案角度
- 客户技术规定？
- Inception 阶段做的关键技术假设？
- 产品的整体技术挑战点？解决方案建议？
- 使用条件
- 明确大致的功能点
- 梳理各个功能的流程，明确理解、列出不确定的点
- 输入
- 计算过程
- 输出
- 权限
- 安全
- 性能
- 细化功能到可以落地的程度（
- 每一步是什么，输入输出是什么，各个系统如何打通、关联，技术方案是什么；
- 实体有哪些，关联关系是什么，如何关联起来；
- 抽象的东西具像化、变成一个个可以理解的实体，然后抽出关联关系
- 最好细化到具体用户流程<每个细节可以画出时序图的程度>
- 将大概的思路进行细化<如接口细化到每一个function，每个function细化到输入输出，到实现细节>，细化时通过一些调研／spike进行思路验证）
- 细化到技术栈
- 确定技术架构（内部都有哪些服务、模块，需要依赖哪些外部系统<需要确认用户有哪些外部服务可以使用>）
- 将不熟悉的技术、需要spike的功能内容进行spike，搭建Demo，减少交付风险和假设
最后的产出应该是什么？
- 技术愿景
- 技术架构
- 部署架构
- 使用的技术栈：框架、编程语言等
- 持续交付流水线方案
- 测试策略
- 技术依赖清单
以上这些是最后汇报的产出，但实际上我个人认为最最重要的是技术解决方案，要想清楚整个技术实现流程，每一步大概是用到了怎样的一个技术、大致的交互流程、哪些方案可以实现、有什么风险、要花的effort，这些都是重中之重。
一点点其他的感受
这次的Inception个人感觉比较特殊，因为是在确定了要做交付的前提下去做的，要达到的目标就是把需求细化。结束之后某次吃饭的时候跟白老板聊了聊，有一些观点非常赞同。做Inception其实不止是在挖需求、为后续的交付进行保障，更多的其实也是一种双向的评估，看看客户这个项目做起来对他们有没有意义。如果感觉到这个项目其实并不能解决客户的痛点、对客户的改善意义不大，或者实现的效果会跟客户想象的偏差过大、难以实现，可能会建议客户不继续做这个项目。正是因此，Inception虽然不是交付产品，也能够受到很多客户的欢迎和推崇。
