从一个例子出发，看项目评审材料的准备

当前有些项目在立项，另一些项目在收尾。共同点是这些节点上都需要外部评审。在项目负责人准备评审材料的时候，要注意把故事脉络讲出来，让评审团队听明白。

正好看到一个相关的例子，可以部分参考。

这篇2016的文章，是backblaze blog的一次存储单元升级的介绍性文章。

将其类比为一次产品升级项目的评审介绍，我们看到它的结构是这样的：

先说这次升级使得成本下降到$0.036/GB，比上一代降了22%，这可能是读者最关心的。既是为什么backblaze要做这个升级的原因，也是读者为什么还要继续花时间看后文的原因（看看怎么达到这个数字的，自己 DIY 成本几何）。

紧跟着简述了项目历史版本，尤其是上一版。帮助读者预热一下思路，脑子里有个模糊的背景

介绍 what's new：硬盘数量变了，容量变了。

提出（评审）问题：影响域分析（所做的 feature 和 bugfix 影响哪些功能，怎么证明不会引入新的问题？），包括尺寸、散热、供电、带宽、线材信号衰减、处理能力、缓存性能容量、硬盘兼容性等等

给结论：对所有问题，给项目团队最终确定的结论。

对一些重要结论附上解释：例如尺寸、成本分析

提供评审输入文件供浏览，这里是设计稿、bom、接线图、作业指导书（build book）等

最后我们看看评审团队（blog reader）问了什么：

What is the power draw like at idle/heavy use?
Are the rails used to mount the pod into a server custom made? Or standard off the shelf? Curious about mounting a 4U server with this much weight.
What is the copyright/license status of these Storage Pod blueprints/designs? Can I use them commercially, for example to make and sell my own products based on these designs?

对应到我们的评审里，相应的问题可能是

把这些问题一一回答，评审完毕。

整个过程从宏观到细节，从结论到过程的。

如果有评审人员质疑项目不该做，step 1-3就可以喊停。

接受项目的价值，但是质疑项目范围考虑不周，那么step 4-5可以提出。

认同项目要解决的问题是正确的，但是不同意结论，step 5-6可以提出。

但凡进行到step 6之后，项目团队这次评审已经搞定。开始细节讨论了，这时候评审组怎么可能比项目负责人和项目团队专业&了解细节？！后面就是费口舌和找证据支撑项目团队决定的活动了。