与某客户的需求交流

    去年春节前后，组内损失2员大将，新年伊始，公司新上两个全国性的大项目，14、5个省一起实施，写文档、做测试、远程部署、突发性事件支持，着实好好忙活了一阵。

    一个项目，其中部分是做IT监控的，某个省的客户单独提出了一部分需求，写得比较笼统，研发那边看了就头疼，把我叫过去一起商量了一下。主机和数据库都好说，但是存储涵盖的厂家有华为、中兴、EMC、SUN、HP、IBM等等，如何通过命令行的方式取得相应指标，还真得花费一番功夫。最后我们达成共识：由于客户的需求都是笼统，由我先把需求按照对我方有利的理解，整理成具体的指标并对指标进行分级：1、可以实现，实施简单；2、可以实现，实施复杂；3、可以实现，但是由于某些原因不建议实现；4、技术上目前无法实现。然后再拿着这份指标，参照客户原来的要求，与客户逐一讨论，最终确定实现哪些功能和指标的监控。

    连夜完成了指标的梳理，第二天订了中午的票，项目经理、产品经理、一名研发人员，加上我一行4人踏上了火车。达到客户现场，客户来了7、8人，应该是除了领导意外，精干的技术力量全部出动了。产品经理让我把电脑接到投影仪，我问：“是我讲吗？”他问我：“有问题吗？”我笑了笑，会议开始...

    为了减轻研发和我部门实际部署的压力，我尽可能地将对方的需求转化成了简单直接的指标，比如对方要求监控Oracle数据库热点，我将这个热点理解为：IO最集中的数据文件、IO请求最多的SQL、CPU占用最多的SQL、内存占用最多的SQL、执行时间最长的SQL；对于一些诸如监控操作系统用户和数据库用户的所有操作，这需要打开审计和应用logminer工具，我这么建议用户:为了对一些问题的主动监控，这些问题发生对系统的影响不是非常严重，但是为了实现主动监控，却需要付出非常大的代价，有点得不偿失，请斟酌；

    用户中有几个人还挺感兴趣，饶有兴致地跟我进行讨论，我也尽量本着谨慎地原则，有把握的，一口答应，没太大把握的，措辞就相对有一些回旋，和研发相关的问题，就请产品经理来回答。随着讨论的深入，用户逐渐开始忙碌起来，时不时就有人给他们打手机，他们进进出出地接电话，也很难讲注意力集中到讨论中来了。接下来我的介绍几乎就是走一个过场，有惊无险地结束。产品经理将之前的讨论结果做了一个简单总结，请客户确认，客户如此回答：“简单的、重要的、工作量不大的需求，做到本期产品中；复杂的、工作量较大的，可能需要花钱的，本期暂不考虑。”如此一来，需求就基本清晰，而且趋向简单了。