入职后正式或非正式的参与过几个Inception，算是从开始的雾里看花，自觉慢慢有了点眉目。关于Inception流程和方法论的资料已经很多了，这里分享一些个人的理解和感受，一是对自己现有思考的总结，二是希望能够给没有参加过Inception的同学一些帮助和启发。
一、前期准备
关于前期的准备，知识储备肯定是必须的，除此之外，也不要忽略了团队协作。
寻找自己在团队内的位置
初次接触Inception的童鞋可能会觉得，好像只有Facilitator在忙耶？实际上，Inception是团队作战，每个人的技能基本没有太多重叠，无论是引导的方向策略，还是给客户的呈现，背后都有大量的收集、整理、思考和讨论。Facilitator忙着跟客户交流，那就需要有人把讨论细节记录下来，之后进行总结和整理；不太擅长出方案？那就帮忙进行方案完善。在Inception开始前，了解团队内每个人的技能，协调并约定好在Inception阶段各自的角色，可以让你更加从容。
参与制定Inception计划
在正式开始Inception前，需要制定Inception计划并提交给客户。初次做Inception计划的时候，我们先预估了每个需求的讨论时间，然后按照dependency排序，从而生成计划。看起来很美好，但其实背后隐藏着很大的问题。
第一，在实际讨论中，客户通常聊着聊着就发散了，不会跟着你的schedule走，有时甚至直接推翻之前的需求，直接开聊新话题；第二，不同需求可能需要客户方不同的stakeholder参与，但不是所有客户都会按照你的计划到场。所以在制定计划同时，需要与团队一起制定应对突发情况的策略，保留计划的灵活度。
搜集背景信息
Inception开始前，或多或少都会有一些输入，有的客户还会提供详细的需求文档。理解客户提出的需求只是第一步，我们还要了解这些需求提出的背景。现有系统、行业信息、竞品信息等等，在时间允许的前提下，从各种角度去挖掘。你了解的越多，在设计方案时视角越广阔，即使客户在现场突然转换方向，那也只是变道，不至于脱轨。
还有比较重要的一点是，要及时将信息与整个团队分享，从而转化为团队资产。要想提升在Inception阶段的沟通效率，所有人“说同一种语言”非常重要。
二、与客户的沟通
与客户的沟通中，我们会遇到各种各样的突发情况，但了解客户问题，给客户提供价值，才是沟通的最终目的。
客户说的一定是对的吗？
“客户说要XX功能，我是答应还是不答应呢。。。？”这是在客户现场经常会遇到的尴尬。其实不必先急着做是非题，与我们对接的客户，一般都不是专业的产品人，也没有经过相关方法论的训练，所以往往会直接描述自己脑海中想象的“成品”。
我们可以推测其脑回路大概是这样的：哎！我现在有个问题要解决 → 咦？好像用这样一个功能就行了！ → 嗯~ 我真聪明，你们说是吧~。基于这个假设，生硬的否决肯定是不可取的，毕竟这是客户智慧的“结晶”；而我们更应该挖掘的，是描述背后没有说出来的问题。
客户不会因为你有理据的说服了他而感到不满，但可以肯定的是，客户绝不会因为你无底线的顺从而感到满意，唯一能让客户满意的只有交付物达到甚至超出了预期的效果。关于如何提升客户的满意度，可以参照Kano模型。
客户都是明白人。
当客户一直坚持某个很“奇怪”的需求时，你的内心一定翻了个白眼：“这人是不是sha？”。其实除去极个别特例，一个在正规企业正常任职的人，双商绝对是在线的。沟通存在困难，可能是因为你不懂他。
为什么他一直坚持要用那么“丑”的按钮？可能是他强烈的个人偏好，也有可能这是他老板的意思，他也无能为力。如果是前者，我们可不可以用对交付物的影响来说服他？如果是后者，我们可不可以帮助客户找到说服他老板的方法？从客户的利益出发，让客户相信我们会站在他的角度思考，会尽力帮助他，客户往往也会从善如流。
不要轻易做承诺
面对客户的一大禁忌，就是随意向客户做出承诺。你应承下来的每一件事，客户都默认为是肯定会兑现的。且不说面对客户是正规的商业场合，设想你找小明借一千块明天急用，小明满口答应，结果第二天跑来跟你说不好意思啊，我手头其实只有五百块，你要么再等等，要么找别人借借，你的内心会没有一点波动吗？无论是需求实现，还是报价工期，如果是未讨论过的或者不确定的，轻易的承诺很可能给后续挖下大坑。遇到这种情况，一是保持头脑清晰，二是要能顶住压力。
三、准备交付物
对Inception有了解的童鞋应该对一系列的标准交付物并不陌生，但在实际操作中，还是会有些疑惑：这样的粒度足够么？这样的表达合适么？工具只是实现目的的手段，当我们考量一个产出是否足够时，可以看看它是否达到了与客户达成一致，辅助交付落地的目标。
业务流程图：业务流程图是对业务流程的可视化，所以流程图需要做到明显提升与客户展开讨论的效率；而进入交付阶段后，开发们会逐步加入项目，周期长的项目，中间还可能出现人员的替换流动，那么对于没有任何context的开发人员来说，业务流程图需要可以帮助开发快速了解业务；
需求全景图：需求全景图是未来可能交付的所有功能的合集，既是与客户再次确认的机会，也是对客户的一种回应，如果发生遗漏，客户容易产生“你竟然都不注意听我说话”的想法。确认过的全景图其实也具备一定的契约效果，帮助圈定交付阶段的scope，一定程度上防止需求蔓延，从这个角度来说，全景图的粒度需要准确把握，不能过于模棱两可。
交付计划：交付计划表现为功能的先后顺序，但背后其实是业务逻辑、业务价值和技术可行性等的综合考量，除了业务价值，还特别要关注两点：一是计划并行开发时，要辨别模块间是否有强相关性；二是管理外部依赖，通常我们会基于外部依赖ready的预期时间制定计划，但现实是外部接口按时ready的情况很少，所以在制定交付计划时要做好后备方案。
此外，交付计划也是客户期望的体现。最后成型的计划往往包含客户要求的milestone，比如XX功能一定要在X月之前上线，赶上业务旺季之类。这些信息可以帮助我们了解客户的想法，对客户行为作出更准确的判断。
Inception既需要专业技能，也需要应变能力；做完一个Inception不难，但做好一个Inception也不容易，这需要一个经验积累的过程。牢记团队合作，牢记客户价值，牢记交付落地，即使暂时不能carry全场，能够清兵守塔不送人头的，那也是好同志！
网友评论