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

自上一篇的文章《记一次完整的安全技术解决方案遭遇成本考验后的“退步与博弈”》记录了我作为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到,才是真本事。

这也是为什么我在面对任何一个客户时候,客户都想吸纳我,让我过去帮他的理由!!这里我不是炫耀自己有多厉害,我只是真的想表达一个观点。

——————————

认真对待是每一个工程师需要具备的基本素质,决心做好一定会比想要做好的心态,产生的结果会好上百倍千倍。

——————————

在经过了几次的分享,大家一定有点好奇,我到底在哪一家公司工作,为何能有如此好的“土壤”来历练自己,这里还是买个关子,因为我一直是那个工程师,踏踏实实的工程师,从没改变过。

我的初心一直是这样,我在尝试着真诚地描述自己遇到的问题和解决经历。

——————来自一个正处于人生转折点的网工Allen

QQ:549675970

QZONE:http://user.qzone.qq.com/549675970

E-mail:

[email protected]

[email protected]

人生格言:越努力、越幸运

时间: 2024-08-03 03:02:10

一位架构师用服务打动客户的故事的相关文章

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

有些日子没有整理案例了,回顾了下上次案例分享的日子,已经有将近四个月了.. ~~~~~~~ 从开始在51CTO上写架构师服务这个系列后,因为留了联系方式后,有不少志同道合的的朋友留言.加好友对一些特定的场景进行交流,其中个人收获并纠正了不少错误的观点.无论如何还是要谢谢有这么个地方,让我去记录并分享个人的一些经验和心得. ~~~ 又脱更这么久了,抱歉抱歉~~~(读者:"信不信我把你按着地上摩擦~~!!") 最近确实忙着很多连续性的工作,但都不是具体配啥了,让各位失望了~~~:),如我前

一位云架构师用服务打动客户的故事之七「腾讯云·如何在临场用服务拿下甲方Boss认可?」

距离上一篇文章有很久了,确实一直想保持这种节奏,但一直出现'脱更'的情况实属无奈.除个人工作的调整之外更多是因为到处出差'飞'的状态. 时间越久,越是发现技术和沟通的两把武器,技术在技术人员身上是没有问题的,但是在沟通上问题极大.虽然说'自古套路得人心',但初心总归是好的.在国内,目前有非常的做云计算服务的公司,今年格外多.尤其是伴随华为云发力.AWS发力和各类公有云在基础架构上的'白菜价'上,对'迁移.上云服务.对持续运维服务'上有简单而又粗暴的需求.因为信息敏感问题,最终用户以"用户&quo

一位云架构师用服务打动客户的故事之八「顾问式销售的三把武器」

今天接着上一次文章接着聊,开始之前了也聊聊上一篇文章的反馈情况,自从上一次对话方式的文章发布后,有非常多的正在前线的作战的销售伙伴们加我好友了,并通过邮件联系到我,表达了很多正在遇到的'困境',比如:我不懂技术,怎么能跟客户互动好?.我是个技术,但是我就是跟别人不来电,不知道怎么开场? 文章收益人员:销售.售前.正在转型做销售的技术(售前) 其实有的人看性格,有的人看心情,也有的人看经验,但不得不说售前是一个急各种综合素质能力于一体的岗位,需要不断修炼自己,强行让自己走出舒适区的工种.包括我坚持

一位云架构师用服务打动客户的故事之六(阿里云上的MSP最佳实践项目分享)

最近找了一个典型的云服务客户的案例对内进行分享,今天把核心内容脱敏后分享出来.希望能给目前在路上(做云服务MSP)的同行,有一些借鉴意义或者帮助. 该用户据全年跟进情况,目前该客户距正式启用我们公司云服务(运维服务)的日子已经有半年有余了,目前整体趋于稳定,故将目前用户进行深度复盘剖析,让各位伙伴更好的从该客户案例中提取一些有用的"武器"."售前技巧". 云产商:阿里云 企业背景-日企上来的终极三问~ > 为什么选择我们做云服务商?PS:此云服务并非指的是阿里

转:每个架构师都应该研究下康威定律

今天的分享主要来自我之前的工作经验以及平时的学习总结和思考.我之前的背景主要是做框架.系统和平台架构,之前工作过的公司 eBay.携程.唯品会都是平台型互联网公司,所以今天主要带着平台架构视角和大家分享心得体会.架构的视角每个人都不一样,可以说一万种眼光,有业务架构.安全架构.平台架构.数据架构,各不相同,这里仅是我的一家之言,欢迎大家加入『聊聊架构』社群参与讨论.今天聊的话题主要包括以下几点: 我对架构定义的理解 架构的迭代和演化性 构建闭环反馈架构(Architecting for clos

关于架构优化和设计,架构师必须知道的事情

概述 这篇译文最早发布在infoQ下面的一个微信公众号:“聊聊架构”上,想着我在园子几乎沉寂了接近两年之久,于是借机复活.哈哈哈,这是一篇关于架构的译文,会介绍比较多的一些工具.以及框架,给对架构感兴趣的同学一个知识扩充. 近几年来随着互联网的飞速发展,新的架构实践方式不断涌现,但是有一件事情是永恒不变的,那就是-“架构之道”:关于如何设计出灵活.高可用性以及能够快速适应变化的系统架构,我们依旧还有很大的发挥空间.本文会介绍关于如何构建前沿的.易维护的.安全的架构的几个要点,同时你也可以把它当作

全栈软件工程师和系统架构师的异同

看完后.发现.不用怕....因为程序员不会看完.只有"架构师"才有耐心看这么长的. 一 每个好架构师都是一位出色的程序员(卓越的程序员) 架构师,听起来是如此神秘的一个称号.尤其是在开发领域刚入门不久的菜鸟级程序员眼中,架构师都是高手,都是牛人,都是如此高高在上的存在. 不过,在搞了四.五年编程之后,程序员们往往早已失去了当年对这些"高级"职位的神秘感,甚至会对自己所在项目的架构师抱怨不已,背后里称他们是一群水王.所以有江南白衣曾撰文述说:"国内的架构师到

关于架构优化和设计,架构师必须知道的事情(转)

转自:http://www.cnblogs.com/jesse2013/p/things-architect-must-know.html 概述 这篇译文最早发布在infoQ下面的一个微信公众号:“聊聊架构”上,想着我在园子几乎沉寂了接近两年之久,于是借机复活.哈哈哈,这是一篇关于架构的译文,会介绍比较多的一些工具.以及框架,给对架构感兴趣的同学一个知识扩充. 近几年来随着互联网的飞速发展,新的架构实践方式不断涌现,但是有一件事情是永恒不变的,那就是-“架构之道”:关于如何设计出灵活.高可用性以

关于架构的优化和设计,架构师必须悟透的事情

近几年来随着互联网的飞速发展,新的架构实践方式不断涌现,但是有一件事情是永恒不变的,那就是-“架构之道”:关于如何设计出灵活.高可用性以及能够快速适应变化的系统架构,我们依旧还有很大的发挥空间.本文会介绍关于如何构建前沿的.易维护的.安全的架构的几个要点,同时你也可以把它当作系统设计的准则或者用它来验证现有的架构是否合理. 就像我们经常所说的:没有最好的架构,只有最合适的架构.一个好的架构师,可以根据具体的需求.所拥有的资源等因素综合考虑而设计出最优的架构方案.特别是现在,业务的飞速变化.数据无