一位架构师用服务打动客户的故事

Posted 2021-08-25 Allen在路上

tags:

篇首语：本文由小常识网(cha138.com)小编为大家整理，主要介绍了一位架构师用服务打动客户的故事相关的知识，希望对你有一定的参考价值。

自上一篇的文章《记一次完整的安全技术解决方案遭遇成本考验后的“退步与博弈”》记录了我作为PM+架构师为客户提供的一次咨询、实施交付、售后运维的整个项目生命周期（除商务）很感谢51CTO这样的平台，能让结实不少志同道合的朋友一起探讨技术，探讨生活（CTO运营人员：时隔一年多，这小子终于讲出来了，，一万吨感动！！！）

在6月12日，我们的交付物得到了客户的高度认可，并顺利进行了项目结项会议的开展，包括接下来即将前往客户现场全面讲解一次我们此次项目所有交付物。

今天发散的聊下在2017年传统的系统/网络/存储等集成工程师转型做服务的如何养成系列之一。因为这就是我拿下客户信任、认可最核心的东西，服务行业在个人的理解当中，就是当一切IAAS的层面变成的“风火水电煤”后演进出来的理念，其实这早在很多偏门的行业里面早有雏形。这里就不举例了，直接进入分享的主题，仍然以上次我在项目中的角色展开（PM+架构师）

————三大重点————

第一，除了对技术细节以及各个part的性能耦合的对接非常了解之外，还要有很多的整合理念。

第二，海外的客户在上线一个系统时，经常会把整个项目打散分成好几个part交给不同的供应商做，一方面是打碎风险，另一方面是取百家之长。

第三，做事严谨有计划并详细的有表格和文档进行体现

写在前面，今天我详细的去聊下这三点，当然和往常一样。文档会和谐并保护好任何一个客户的权益

第一个重点———技术堆栈实力先行，资源整合的概念跟上

回到架构师的角色，架构师需要一份对细节执着和肯钻研的精神，同时拥有较好的关键汇总能力和撰写PPT的能力。

我这里从项目签单的那一刻开始说起。立项后，按照我们做事的风格会立刻着手整理一封XX项目协作邮件-【2017年6月15日】，如下：

项目目录总表：

项目进度总表：

大家应该会很明白，为什么我要单独列出一个（问题）的清单，大家可以理解为这是实施过程的“风险”，作为一个PM，你需要有纵观全局的潜在风险洞察能力，并结合自身技术能力进行阐述，当然因为我个人本身是技术出身，所以这对于我来讲没有任何问题。至此，内部协作的邮件虽然发了，但关于项目启动这件事情仍然没有完。还要召集所有关联人员进行责任指定。

PS：表格中人员我和谐过，大家勿这样理解。这个项目里面涉及到的人员跨越了五个部门之多，涉及人员超过20人以上。

所以择吉日，通过钉钉推送会议通知。开会过程介绍这里省略，只介绍会议开展的核心要点：

1. 责任指定：必须将非个人只能范围能做的事情，指定到对应的部门的人身上。不可指定一个范围（比如：国内运维部门）

2. 项目启动的“广播”：会议的召开，不是show能力也不是show销售的打单能力。是要清晰的告知大家，这件事情开始做了。张三、李四、王五你们都需要来协助我完成这个项目，并且你们的协助程度，决定了我对你在此次项目中的表现打分，间接与所在部门考核挂钩。

3. 项目负责人再次强调：注意为什么我要强调万不可认为发完邮件就结束了，因为这对需要协作你的部门以及人是极其不尊重，打个不恰当的比方“招呼都不吱一声，就让我配合你做事，什么嘛！！！”

PS：所以这些大家在未来的一定务必要注意，这决定你在国内这个极具特色的环境中开展项目实施工作，同样还是那句老话，我踩过坑。

好，至此项目启动会议顺利完成了。这也是我个人的经验，自己个人也没经历任何系统性的培训，完全是“野路子”，所以大家发现有问题，一定及时斧正，避免因为我，而误导很多正在努力路上的工程师。第一点，我暂时先聊到这里，因为一篇文章很难讲完和讲明白这个点上的点点滴滴（又暴露了我喜欢卖关子的性格—：））

第二个重点———统一接口，项目中的多面手

聊聊第二点，避免大家往上翻，我复制一下：

第二点，海外的客户在上线一个系统时，经常会把整个项目打散分成好几个part交给不同的供应商做，一方面是打碎风险，另一方面是取百家之长。

这里请大家先不着急往下看，仔细的分析下我作为PM+架构师在项目中忧患！！！噢去，千夫所指一点都不夸张。此话怎讲？待我为君一一道来。

1. 网络和系统架构是我“主刀”

2. 设备的选型虽不是我主导推荐采购，但到货日期我需要控制住，这个决定了我如何进场实施

3. 存储与以太网对接的细节是我来把控，所以这个必须依附软件商的业务部署概念来制定部署方法

4. 三个软件商、我们都是最终客户的“乙方”，每个角色都回积极去表现个人所在公司的能力。就是会给我这个“主刀”的医师，提出各种奇奇怪怪的疑问，并且你必须要合理解决这个技术问题的同时，还要妥善的处理好大家和甲方关系。这一点相当考验一个人的协调能力，还有立场的应变能力。

PS：这个时候应该会有部分工程师说，那你专心做你的技术就行了嘛，干嘛要去当这个PM、当这个架构师。做精做深技术不就好了，这么年轻去碰这些世俗的干嘛？

我这里简单的自问自答一下，大家很清楚在国内这种情景中，如果你占据主导地位。就会像我今天的角色一样（PM+架构师），去要求：

1. 供应商在指定地点和时间必须将设备清单全部送达

2. 软件商的系统和网络架构必须按照我的方式来，你们这种做法虽然可用，但不是最好的，虽然是高可用，但风险依旧

3. 实施过程和细节，必须由我来主导。我来保证每一个时间节点该做什么事情，避免整个项目交付周期中出现失控的情况

提一句其他的，如果你不是奔着研发去的。可以纯粹的做一个技术专家，但我相信你一旦处于各种项目中的时候，你会发现你的能力明明可以规划和配置出一套更安全、更可靠的MPLS网络的时候，但架构师会告诉你不允许这么做，你必须按照他的方法来。可在你看来，这个方案就是有极大缺陷的，但此时你无能为力。你可以沉默，继续满足架构师的要求，满足最终甲方客户的要求。不过，你真的会感到开心嘛？你的钻研精神遇到这样一个没有资质的架构师，才华就这样被否定了~~~~~~~【顺带的瞎侃两句，不过这的的确确是国内很多项目中真实的场景，所以我在此次项目中，考虑了个人的能力范围后，毫不犹豫的选择了顶在最前面，所有的事情我说了算，】

好，这里第二点算是给大家简要的阐述了下，不过前面都是比较主观的观点和认知。我这里客观去汇总总结下（精华，请细细品读），一下三点：

1. 作为架构师，你的立场需要拥有“上帝视角”，合理看出哪个角落存在问题，并指出和给出合理解决办法

2. 作为PM。你需要巧妙的处理三方甚至四方和客户的关系，因为你对于客户来讲也是乙方，你的立场应该是和其他乙方一致（给客户做好这件事情）

3. 深入了解其他三方或四方的工作和能力范畴，为他们解决困难，换句话讲“你作为架构师即作为PM，你要给他们背书”

第三个重点———项目交付物的质量！

大家坚持一会，今天的分享还剩下最后一点

第三，做事严谨有计划并详细的有表格和文档进行体现。这里我简单share下大家一些交付物

文档容量达到：90M

当然，如果各位希望能得到一些实质性的帮助，我完全可以进行和谐后分享给大家去download，因为很有可能你的思维会比我更好，会更加完善这些思路。

我这里详细的展示一张表格，这张表格也是我们最最最最最核心的东西，决定了此次交付的严谨、专注等服务能力。

说说最后一张表，这是每次客户线下需求我们协助调整的内容记录，可以看出我们对事件请求记录非常重视，因为这个可以帮助客户去回溯很多问题。目前我们已经正在和公司内部的研发团队洽谈，我们要把该客户的事件请求集成在客户侧的用户中心，切实的感受我们为他做了多少事情。那接下来服务报告、年度回访自然就非常的顺理成章了。

再晒一点关于项目实施完成后，我们对架构高可靠性的“人为”故障的验证测试报告

最终形成一份完整的交付报告，不夸张的讲，如果你也做IT服务的工程师，你拿着这些文档，去打单，你会非常容易的拿下客户。因为你的做事风格就是如此让人放心。另外，这些文档都是我所在团队，我所在的公司的文化积极打造出来的结果，你可能会想拿走（做伸手党），我倒是不介意你做伸手党，但你的未来，你自己需要负责的，所以get到，才是真本事。