这是彭文华的第137篇原创
最近在家安心改稿，一个3000字的稿子，我一上午就写完了。结果没想到改了一个月！简直要被陈章鱼老师给打磨到原地爆炸！
正郁闷呢，我北航同学李老师找到我，说他们有个交通大数据项目快被甲方整死了，让我给他出出招。这不是瞌睡送枕头么？案例来了！我二话没说，兴冲冲的直奔他公司去了。
把人整神的甲方
到那正好是饭点，于是我们找了个地方边吃边聊。刚点完菜，李老师就直切主题，抛给我一个问题：“赶紧帮我弄一个数据迁移方案，甲方逼死我了！”
我说：“你别慌，把事情说清楚”。
他喝了口水，说：“我是20年中接手这个项目的，主要是两部分：前面的交通监测应用，后面的大数据平台。我以前都做应用端，大数据这边接触的比较少。公司请了一个大数据高手帮忙搭的平台，一直在接数据呢。按照计划，这个月月初就要把数据接完，结果上周项目周例会甲方突然发难，找我要迁移方案，这之前也没说过要啊！”
我迅速找到这个关键点，这里得好好问问：“突然发难的情况多不多？”
这下完了，仿佛捅破了装满水的气球，李老师一顿捶胸顿足：“可不是咋地？平时关系处的挺好的，这一开项目会就发难，一次次的谁能受得了啊？都不知道他们到底要干啥！怎么搞关系都不行，这是要把我整神啊！”
甲方平时关系好，上会就发难，这说明咱平时的客户关系维护到位，但是项目中该做的事情没做到位，客户无法向上交差啊。不过我知道问他也问不出啥来，于是安安心心吃完饭下午去他公司跟项目组开个会了解一下。
望闻问切
吃饱了饭，李老师带我去他公司，火急火燎的把项目组核心人员叫过来一起沟通。
我让老李把标书中建设内容部分快速过了一下，跟一般的大数据项目没啥区别，就是数据怎么接、存、管、用。
我又让大数据高手把现在的大数据平台架构设计讲了一下，接数用的是Flume+Kafka，存储用HDFS，然后扔到Hbase提供查询服务，计算引擎用的是Spark+SparkStreaming，应用那边是MySQL，用CDH，所有组件做了HA，到这里都还没问题。
我又问大数据高手数据接入的进展是怎样的。高手说已经持续在接了，每天接数量都按TB计算。
我有些奇怪，技术这边问题没啥大毛病啊。高手抱着脑袋郁闷呢，每次项目经理开完会回来就骂他，整的他也不知道是啥情况。
我继续问：“你们的数据接入方案给我看看，我看看是不是遗漏了什么东西”。李老师说：“每天都赶进度，哪有时间写那个玩意啊！文档基本都是项目结尾的时候补的。”我寻思也是，转过头问高手：“草稿或者沟通记录啥的总有吧？要不你们怎么接的啊？”
高手连忙到处找，聊天记录、临时文件夹、各种截图一通找，总算把事情说明白了。我有些明白问题所在了。
我问李老师：“你跟我说说每次都咋开会的”？李老师：“那还咋开啊？就一帮人在哪，甲方坐镇，总集挨个问进度呗。我们就照常回答进度啊。但是会议总会问技术问题，我就答不上来，然后总集和甲方就发难了。”
我说：“你们除了周例会，还会有其他的会议么”？李老师摇摇头。我基本上已经明白是怎么回事了。
我继续问：“除了数据迁移的事情，甲方现在还在追的问题吗”？李老师说：“还有大数据平台测试的事情。高手写了一个，但是我自己都看不下去。”
我让他打开文档看看，看到的是大数据平台各个组件的测试结果。我心里已经笃定了，然后让高手切到大数据环境中简单看了一下，然后简单总结之后散会。
辩证
李老师知道我要跟他说事儿，屁股都没动一下。项目组的人从外面关上门之后，李老师迫不及待的问我：“老彭，这该咋整啊？”
我说：“不急。现在不是解决问题的时候。你们现在有些歪了，跟你先说清楚。”
我在白板上画一条竖线，一边写正式沟通，一边写非正式沟通。说：“你们非正式沟通这边没问题，是因为客户关系处的好。但是问题出在项目例会这种正式沟通环境，说明你们有些工作没到位。这个能理解吧？”
李老师也不是外人：“废话，我当然知道，但关键是哪里没做到位呢？”
我不管他的问题，问了他一个其他的问题：“你装修房子的时候最怕啥”？李老师有些摸不清头脑，但还是如实回答：“当然是怕他们偷工减料了！”李老师拍了拍脑袋：“你的意思是说我们没让甲方放心？”
“对！我刚刚看了一下，大数据平台问题不大，高可靠、高可用都做了，很中规中矩。数据也接了，我刚才偷偷看了一下，至少跟聊天记录里说的大致能对上。但是你们其他地方可不咋地。”
“你看现在装修房子，装修公司之前会给材料的检测报告，弄完之后都会装装样子给测个甲醛啥的。但是你们这也太糙了，啥也没有，光说个进度管啥用？”我在白板上写上：
调研-需求分析-设计-开发-测试-部署-试运行-用户测试-上线-维护
“这是软件开发的大致流程，在每一步，都会产生很多文档，也会跟甲方做无数次的汇报工作。但是我发现你们私下沟通挺勤快，但是正式汇报很少。另外，文档工作很糙，甲方根本不知道你说的进度到底是啥情况。应用端还行，所见即所得，这大数据平台藏在后面，客户又不会打开看看，怎么知道你做的好不好呢？”
我在流程上面写上甲方-乙方，并在甲方上圈了一下：“甲方要的不是进度汇报，而是掌控感。跟你装房子一样一样的。所以该到位的必须要到位，先做事，后补文档是OK的，但是不能不写文档。”
我让他切屏到测试文档“还有，每个文档都必须按照计划、设计、执行、结果四个步骤写。不能只是跟这个测试文档一样，好像是写了，东西还不少，但是你这么测试的依据是什么？为啥要这么测试？科学不科学？这文档里都没说明。”
“测试文档最少要有测试计划、测试方案、测试用例、测试报告、测试结果分析、用户测试报告。而且，这些文档最好都单独拆开。测试内容必须包括功能性测试、性能测试、安全测试等等，而不是往Kafka里扔1G的数据，然后落到HDFS、最后在Hbase看到就行。那只是功能性的测试。大数据平台最关心的就是性能和安全性，结果你都没体现。”
“现在头疼的数据迁移的问题，反倒不是重点。现在数据都快接完了，你们的数据迁移方案就可以补上了。因为是后置的，所有信息应该都已经掌握了，也就是把跟客户、其他第三方沟通的聊天记录转成文档的过程，要迁移/接入的数据有哪些，有多大的量、用什么方式接入、接入后存在哪里、整个接入计划是咋样的，写进去就好了。”
李老师全程都支着脑袋，皱着眉头，也不发声。等我说完，就来一句：“这得多少活啊，太费劲了。”
我叹了口气：“你们现在最大的问题不是技术层面的，而是自己的文档工作和沟通层面。咱们技术的确不喜欢写文档，但是文档可以简单写啊，之后慢慢完善呗，态度分是肯定要拿到手的。有了这些，再勤着点汇报，甲方也不会在正式会上发难了。”李老师重重的点了点头。
直面甲方
我拍了一下李老师：“这些都是我从咱这边了解到的，你能不能约一下客户，我们去会会他？”
李老师二话不说给客户拨了个电话，表明意向，约好时间后直奔客户现场。
客户的脾气还是很好的，虽然没有提前预约，但仍然腾出时间跟我们聊。
简单寒暄过后，我表示有些问题想再请教清楚。这时候客户表示很惊讶：“我比较奇怪，你为什么会问这个问题，因为所有的问题我都跟驻场工程师说的很清楚了。”
我连忙打圆场：“我这不是怕工程师脑子笨嘴笨说不清楚么，还是过来听您说更放心一些。”
这个客户还真是很耐心，遇到脾气不好的客户估计就开骂了。他详详细细把他的期望和担心都说了一遍，我这边也一一做了记录。针对一些不清楚的问题做了详细的追问，并探了探客户的底。
果然，客户的一些担心跟我此前的判断是一致的，就是对我们的工作不够放心。
紧接着，我就把刚才我们分析的结果向客户汇报了一下：“数据迁移的事情，我们一直在进行，数据已经接入过半，并且在系统中已经能看到数据了。数据迁移方案我们下周就能补上。测试工作我们也已经进行了大部分了，功能性测试已经做完了，文档也写好了，安全测试那边有漏扫报告，我们回头再自测一下。目前还缺压力测试，预计也是下周结束，相关文档下周末之前都会提供。其他事项也在逐步展开，请领导放心。您看还有其他什么没做到位的吗？”
客户点点头：“这样就清楚多了。上次有个乙方，页面写的挺好的，最后一看数据库都没连上，这不是胡闹么？”
总结
把客户送走之后，我就在客户现场跟李老师说清楚，最核心的一点：甲方要的不是进度汇报，而是掌控感。以此为出发，下面所有的改进事项就都能列出来了：
1、处好客户关系很重要，但是工作细致同样重要；
2、必须增强正式汇报，每周周例会之前要正式汇报一次；
3、文档可以慢点出，质量也可以慢慢提高，但是必须要跟上；
4、所有文档，能拆开就拆开，必须按照计划、设计、执行、结果步骤组织；
5、驻场工程师很重要，建议找一个人培养一下，客户认为跟工程师说了，就是跟整个项目组说了；
6、项目内部沟通一定要加强，很多细节你都不知道。你可以不懂技术，但是不能不清楚现状。如果怕问技术细节，可以带上工程师一起开会。
随后，我帮他把数据迁移方案、测试计划、测试用例、测试报告文档都写了一个大概，给大家开会告诉他们应该怎么做，怎么写。并且告诉他们周五的周例会应该怎么应答。
经过这次跟甲方的沟通，以及现有若干问题的准备，周五的例会非常的顺利，李老师可开心了。