8年前，当我决定要去印度“开荒”时，怎么也没想到，有一天，我也会像童年时喜欢的孙悟空那般，为了产品可靠应用的“真经”，一路求真探索，“擒妖降魔”，写下了一份属于自己的西游记。
事情还得从“西天取经”之前说起。
2005年初，机械电子工程专业毕业的我懵懂中加入了光网络测试部，成为一名硬件测试工程师。一进组便遇上OSN3500系列产品手册要发布接口的技术指标，主管老潘安排我把近1300个硬件接口指标都测试一遍，检验指标的可靠性。
来华为之前我对通信知识和产品知之甚少，完全不清楚什么是测试，怎么测；同事们嘴里蹦出成串的测试术语，我也一个都听不懂，完全“状况外”。导师老秦看出了我的惶恐不安，给我拿来三本厚厚的指标测试大全和一本光网络“红宝书”，让我先看书找答案。
每天早上七八点来上班后，我就一头扎在实验室一直待到深夜，对照书籍上的标准，一个一个指标研究，一个一个测试，如果测试出来的指标结果比预设标准要低，可靠性不足，就再寻找根因，联合开发人员一起，不断优化指标，并找出测试方法的不足加以提升和改进。
时间一天天过去，入职3个月以来，我完成了上千个光接口、电接口和时钟指标的测试，最终约75%的指标都明显优于友商20%以上，接口指标能力提升了近200%。也正是在这个过程中，开发、测试一起协作、不断改进，在指标上构筑了光网络的竞争力。转正答辩的时候，评委问我：“你在华为几个月，只做了这一件事？”老潘补充道：“是的，老税只做了一件事，但做到了120分。”
可能是性格使然，我认准了一个目标或方向，发现一个问题，就会打破砂锅问到底，之后做硬件测试尤其是可靠性测试，我每个月平均发现问题数200多个，接近项目组其他成员发现问题数的2倍。要知道，开发和测试俨然是一对“相爱相杀”的Couple，测试发现的问题越多，开发要解决的问题就越多，这也让我成了开发人员眼里名副其实的“问题人”。最开始每次走进开发的实验室都不太受待见，但对事不对人，慢慢地也得到了开发的理解，配合越来越顺畅。我和开发也逐渐“相亲相爱”，还记得某版本开发某单板时，开发人员甚至主动申请让我作为他的测试人员。问题也慢慢变少了，因为开发阶段很多问题就已经解决了。
几年后一次偶然的机会，我和当时的招聘负责人老赵聊天，我问他为什么会招一个跨行业又跨专业的人做测试工程师，老赵说：“你积极主动，认真执着，很关注细节，这些都是作为一名测试人员应该具备的良好素质。”回望这几年，我想，当初的这一步，走对了。
2009年，公司MSTP（Multi-Service Transmission Platform，多业务传送平台）产品大举进军印度市场，MSTP是下一代SDH（Synchronous Digital Hierarchy, 同步数字体系），MSTP解决方案架构与设计部部长老孙找到我，给我画了一个饼：“印度市场将是MSTP的第二大粮仓，你去了大有可为啊！”
当时中国是MSTP第一大市场，销售额占比近80%，但印度市场销售额占比不到1%，而且印度人口众多，土地辽阔，和中国市场极其相似，市场空间巨大。老孙的这番话对我着实有吸引力，我做了四年的硬件测试，几乎没怎么碰过壁，也没出过国，感觉很新鲜，当然我也完全没预料到印度条件的艰苦和市场突破的困难，所以没怎么考虑就答应了。很快我以解决方案技术工程师的身份出差印度研究所，对口支撑MSTP产品在印度市场的“开荒”。
然而一到印度，一盆盆冷水泼过来，困难程度堪比西天取经。
刚到印度没几天，我第一次代表公司参加B客户组织的SDH GR（Generic Requirements，SDH业务通用要求）标准修订会，自我介绍是华为的R&D（研发人员），却被现场其他厂商讥笑为是C&D，我一头雾水，后来才知道C是copy，“抄袭”之意。屈辱感瞬间充斥全身，愤怒直往脑门涌，却只能强压住怒火平静面对。会议的结果可想而知，华为的发声并不理想，标准条款大部分由友商主导，我们在印度市场遭遇强劲阻击。
这种情况下，客户也对华为报以不信任。有一次，我本想向B客户展示华为的解决方案，前一天从班加罗尔飞到德里，可是第二天从早上一直等到下午才见到客户，客户只说了一句话：“你根本不了解我们的网络，你现在可以回家了。”那一刻，失落和无助瞬间将我淹没，我恨不得立刻找一个地洞钻进去。
还有一些客户，对我们不拒绝也不认可。记得某客户，我们全力以赴，精心准备，参与了近二个月的比拼测试，逐条解决了测试出的问题，对客户的标书条款也逐条澄清和答复，标书满足度很高；客户提出的100多条需求，我们也逐一澄清和交流，并提供解决方案。仅交流和澄清会议，我们就参加了20多场，还免费提供了一台设备试用。我们自觉尽力了，然而客户态度一直暧昧不明，最终我们还是被淘汰出局。
屋漏偏逢连夜雨，同年，SDH设备在印度销售遇阻，作为下一代SDH设备的MSTP在印销售更是雪上加霜，所有客户担心惹火烧身，不愿意同华为合作，甚至根本不接待我们。
经历了一次又一次的碰壁，我曾经的满腔热血已荡然无存。我一度陷入迷茫、彷徨和无助，甚至想放弃，向主管提出了离职，主管说：“你一直以来都做得很好，就这样放弃的话，是不是太可惜了？你再坚持一下，说不定会峰回路转。”是啊，就这么放弃，我真的甘心吗？老话说得好，树活一张皮，人争一口气，想想那些质疑带来的挫败感，我实在太渴望在客户面前找回尊严和信任了。
我拉上同事对当前局面进行深入分析：由于以前很少接触印度市场，没有深入理解当地市场特点，都是根据对其他国家的运营商网络的理解提供解决方案，而印度客户的网络是什么样子？他们到底需要的是什么？
我们太无知无畏了。为此，我对自己说：一定要跑遍印度客户所有的关键网络和关键局点！
13个关键网络和约200个关键局点，分布于印度的各个角落，从城市到村郊，从楼宇到土屋，从寻常巷陌到羊肠小道，最难忘的是调研部署在贫民窟的网络。我们的部分设备就藏身其中，有些狭小的机房里面堆满了杂物，机柜门常常被人为破坏，设备和单板上布满厚厚的灰尘，蓄电池已老化并不断渗液，油机锈迹斑斑。而塑料布搭盖而成的平房上方是光纤、电缆、居民晾衣线等错乱交织形成的一张张网，网线的两头随意搭在树上或系在树上，甚至有些住户直接将衣物等晾晒在光纤上。我恍然大悟，原来这才是印度网络经常断纤的主要根源之一，是客户的痛点所在，也暴露出我们的解决方案和产品，对这种高温、高湿、高积尘和高硫化的应用环境的适应性能力的不足。
跑遍客户的现网，我们发现，除了断纤外，网络分散、毫无网络层次、应用环境恶劣、掉电频发，甚至GR标准是也集全球各个标准于一体，可以说是全球最严格的标准。这种情况下，客户需要的是，低成本、高质量、高可靠性的产品和解决方案。
心中有数后，我不断和客户对标需求，对各个根因和痛点逐一分析和优化对策，为客户量身打造，逐渐形成了适用于印度市场的传送承载、移动IP承载、行业网超长局传输三大解决方案和12个子方案，并针对客户断纤严重的情况，重点展现了具有抗多次断纤保护的ASON（自动交换光网络）方案和特性，它相当于一个智能导航仪，可以拓扑自动发现、自动寻路、分级保护。客户听完后大喜过望，从座位上站起来竖起大拇指说：“太好了，这才是我们真正需要的最适合的方案和特性。”之后，ASON方案逐步在印度多个客户网络成功部署。
下了这一番苦功，收获也随之而来。客户不断给予认可，印度市场也不断突破，MSTP销售从1%上升至15%。2012年，B客户再次召开标准制定大会。这次是Packet GR（分组业务通用需求）标准的制定，全部由华为主导并制定标准初稿。回想起2009年那一幕，这一刻，感觉真好。
这一仗，过程虽极为坎坷，却让我明白，一定要以客户的需求为导向，最合适的解决方案才是最好的。
2013年，印度A客户计划部署X网络，多家主流设备商都参与争夺这块规模约X千万美元的蛋糕，而且主推IP L3方案或L3+L2方案，华为MSTP的L2方案因为层级低，功能不强大，业务调度不灵活等原因很不被看好，但对印度市场而言，成本为王，这恰好是L2方案的最大亮点，也是MSTP产品最大的竞争力，我们只要弥补客户使用L2时的不足，提升客户的网络指标，不就是最适合客户的低成本、高可靠性的解决方案吗？
我们逐条分析客户的诉求和指标要求，努力做到最优。记得关系到用户上网下载速率的TCP（Transmission Control Protocol）吞吐量的关键指标，在方案介绍会议上，各个设备商都向客户主张他们的价值点，特别是影响TCP吞吐量的关键设备缓存大小指标，友商优于我们50%以上，我们并无优势，但此时的我们对客户网络已有深刻的理解，我们从容面对，拿出相关标准告诉客户，每一种业务类型对时延的具体要求，并针对客户的网络布局对延时指标进行合理规划和分解，对影响该指标的几个参数进行合理控制。最终经测试验证，如果采用华为的方案， TCP吞吐量指标还优于友商20%。
客户对我们非常满意：“最合适的就是最好的，华为才真正了解我们网络，理解我们痛点。”
