Why-结论先行
在我写这个文章的同时，公司内部举行了首届属于工程师们的辩论，在现场听得让我着急，心里想着“结论是什么结论是什么，快抛出来”。但工程师们仿佛都不懂“结论先行”，一句“我方认为”都没有出现，简直欲哭无泪。这仅仅是个无关痛痒的辩论比赛，但是在职场，真的不用“结论先行”吗？
这里我来说说，我在公司的亲身经历。话说当年，我们有个技术很牛的同事，建国，他发现了一个我们桌面产品的一个重大的技术风险，某个功能很有可能会因为网络原因卡死。于是他写了封邮件来说明这个问题，邮件内容大致如下：
Hi，all
我测试了桌面产品的A，B，C，D四大功能，以下是测评的数据：
[紧接着，一张数据严密想尽的表格来呈现在眼前，洋洋洒洒30多行的表格]
分析结论
1. 发现A有轻微内存泄漏，128字节左右，原因是变量c没有释放；
2. B正常没有问题
3. 发现C流量消耗大，但分析原因是视频下载，合理
4. D功能可能会因网络不通，导致卡死
邮件发出，无人问津。然后建国同学开始带着哀怨说，老板不懂技术不看邮件，这么严重的问题都不帮忙推进下。结果，在发布前的几天，蛋蛋作为发布前最后一环的专项测试，写了一封类似的邮件，发送内容如下：
Hi，all
测试结论：不通过
1. D功能因主线程I/O卡死，严重影响约520w的用户的用户体验
2. A，B，C功能均无严重风险
详细分析
[紧接着，一张数据严密想尽的表格来呈现在眼前，洋洋洒洒30多行的表格]
老板回复到，感谢蛋蛋快速定位，我们快速修复。
一封邮件无人问津，另一封老板快速回复，推进解决。大家知道两封邮件的区别吗？核心的关键区别就在“结论先行”四个字。我们在公司工作的应该也会发现，无论是一般员工还是老板每日的邮件量都很大，当然职位越高的被抄送的机会约多，邮件量也约多，所以一般情况下每封邮件的处理时间都不会超过5到10秒，看一眼就过。如果没有结论先行，老板就很容易错误重要的信息。
很多人会用废话当结论
”结论先行“，无疑是最简单的动作，只要把“结论”放到邮件内容的最前面、PPT的标题、字体加粗、标红等等，各种各样的方式让结论最先被关注。但是有个前置条件，我们要弄清楚，什么是结论。下面来列举两个反面例子：
第一种，老板你说型。数据给你，老板自己判断，责任我负不起，但工资你要付我。标题叫选型，其实没有作出任何选型。
邮件标题：消息队列选型
结论：
1. 消息量相同情况下，Kafka比PhxQueue消耗内存多2MB左右，CPU多消耗20%
2. Failover 期间，Kafka入队成功率比PhxQueue低30%
第二种，元芳型。元芳曾说据我分析，这具无头尸体，一定是死于他杀。这样没有营养的废话，也会出现在我们IT职场。如下表的例子，为什么偏偏是TOP1，为什么之前没发现，是什么导致了函数返回空，全部都没分析，仅仅是把事情的结果用更详细地复述了一次。
邮件标题：外网TOP 1Crash事故分析
分析结论：
TOP 1 Crash是由于某某函数空指针错误导致Crash
解决方案： .......
正确的结论，也许应该张这个样子。对于《外网TOP 1Crash事故分析》，我们可以拆解分析给结论，一、TOP1是因为错误位于用户使用的关键路径；二、泄漏到外网是因为开发置空全局变量，但之前仅在部分调用方法内判空；对于《消息队列选型》，我们可以给一个总结性的判断，例如，从资源消耗与稳定性角度看，PhxQueue比Kafka更优，建议使用PhxQueue。总结一句，借用在百度查到的解释，结论是从一定的前提推论得到的结果，对事物做出的总结性判断。
形形色色的结论先行
作为工程师，除了邮件报告，我们还有许多地方会使用到“结论先行”。
回答老板的提问
老板问，那个竞品测试的进度怎样？
结论先行的回答：现在进度60%，预计下周3之前完成，更具体规划邮件方式发给你。
技术面试/通道晋升的成果举证
结论先行的成果描述，XX云IaaS到PaaS上下游打通，人力节省60%
紧接着后面从问题、解决思路、解决结果来举证成果的真实性与技术含量
写技术分享的文章
结论先行的标题，综合实力最强的PNG图片压缩工具TinyPNG
正文，各种尺寸、内容的图片的测评结果分析
