昨天以旁观者身份观察了一场答辩，结合自己之前几次不成功的分享和答辩，也算是受益匪浅，有些心得记录一下。

准备

成功的答辩离不开充分的准备。这里的准备分几个方面，第一个也是最重要的就是平时的准备。答辩之前可以针对性地考虑一些可能问到的问题，增加成功率，但很多问题是无法预测的，这就需要打铁还需自身硬，在平时设计开发的时候就做详尽的考虑，事无巨细，尽量做到对自己所做的东西了如指掌，这需要平时的习惯养成。

另外，答辩之前，也需要针对性地做一些准备。首先，需要知道这次答辩的目的，比如昨晚的答辩，实际上最开始以为review一下代码就行，其实最后还是纠结在如何设计和实现。之前我自己的答辩，也是没有对答辩的状况有合理的预期，准备的时候更多的是考虑如何讲更有逻辑性，而不知道评委最终会纠结在什么地方，什么地方他们根本不关心。没有对状况的预期，往往会手忙脚乱。

还有对评委的背景，最好能有一个初步的了解，一般评委关注点更多地跟自己的背景有关。不过有时候很难了解每个评委的风格。

论述

关于如何讲自己的项目或者设计，以前都是站在自己的角度考虑，如何才能清楚、有逻辑地讲完，但对于评委，可能是完全不同的理解。评委对一开始讲的背景、优缺点其实并不是很在意，模型才是关键。有时候一贴架构图，评委就来了精神，这里的图，就是整个架构的模型，也是理解架构的切入点，所以如何讲清楚模型是非常重要的。

评委都有自身的背景，面对模型，也会结合自己的经验。所谓的经验就是定式，如果你的模型符合他的定式，便会非常容易理解；一旦模型不符合定式，就需要花费很大精力去讲解。所以从大众熟悉的模型讲起，逐渐推演，便会容易理解很多。

另外还需要学习一些通用的表达方式，如金字塔原理等。

面对挑战

答辩必然会遇到评委的挑战，有些评委气势如虹，很容易造成答辩者的心理压力，导致不能正常发挥。其实很多情况下，评委的问题只是一时兴起，还没有深思熟虑，稍加思考即可应对，所以回答问题不能急，要慢下来，思考后再回答。

应对挑战也有一些方法：先确认自己理解了问题，必要时复述一遍问题，避免答非所问；对于不会的问题，坦诚承认比硬撑要好，可以说明回去研究之后再同步结论；不要把挑战当作对自己的否定，而是当作完善设计的机会，评委愿意挑战，说明他们真的在听、在思考。