云时代的领航员--解决方案架构师职位说明

-前言部分---

 

知识工作者只能制定自己的工作方向,所以他必须了解别人期望他做出的贡献是什么,原因是什么。——《卓有成效的管理者》,德鲁克。

 

信息技术持续发展,每一波浪潮都会开辟新战场分化新职业。在云计算这个战场上,有个名头很酷的职业叫“解决方案架构师”。

 

各家公司的JD对这个岗位的定位都很宏大也很模糊,公司的期望值很高但员工目标很模糊,我试着解释下什么是称职的解决方案架构师。

 

本文包含三部分,没有明确的先后顺序,可根据个人兴趣挑选阅读章节:

 

岗位职责——这个岗位对公司和客户有什么意义。

 

背景起源——为什么此岗位逐渐独立出来,和售前/产品的区别。

 

任职资格——什么样的人能胜任此工作。

 

---岗位职责---

 

解决方案工作需要保护和运用好产品和研发团队,给销售和售前提供弹药,最终提供符合客户期望值和公司利益的方案。

 

解决方案架构师需要将现有产品线和技术团队摸透,这样才能保护和运用好产品和研发团队,我们需要掌握下列内容:

 

每个产品的技术特性和适用范围,这是和售前相同的职责。

 

每个产品的大致工作原理,这是为非标准应用和技术改进做可行性评估。

 

核心支撑人员的能力和态度,这是为项目工期和结果负责。

 

过去做产品技术选型的理由和顾虑,这是对产品变更风险的预估。

 

解决方案同事要给销售和售前提供优质的弹药,包括但不限于下列内容:

 

公司产品的核心优势和应用场景,我们和销售可以更接地气的沟通。

 

客户需求的产生原因和应用场景,这会让售前表现的更专业。

 

对内评估旧缺陷改进和新功能进承诺,让商务对内沟通底气更足。

 

公司产品的缺陷和不适用范围评估,这会减少商务侧的盲目承诺。

 

我们要做出符合客户期望值和公司利益的方案,就要做好如下工作。

 

对客户需求做深层技术和场景分析,这可以向客户明确我方的竞争力,还能给产品部门提供有价值反馈。

 

客户需求的风险评估和预期收益,我们可能会拒绝和偏转用户的要求,可以更好的配合销售工作。

 

包装讲解可借鉴的成功案例,这是所有项目中的打单利器,客户总是不愿意承担试错的风险。

 

从技术风险和项目投入等方向评估是否有损公司利益,必要时刻果断叫停高风险项目。

 

---背景起源---

 

解决方案架构师这个职位是从“计算机技术人员”这个始祖行业里分化出来的,它所承担的工作职责一直存在,只是在企业级云服务场景下需要分化成独立岗位。

 

云计算技术还不成熟,大部分情况下只是客户旧架构的改良替代方案,我们需要一个能了解云计算技术,能了解客户需求的架构师职位。面对不成熟的产品,售前同事有很大的认知和使用压力,且每个研发只负责一个功能模块。要谈客户侧的旧架构继承和改良,这是产品和研发很难完成的工作,产品不可能确定客户买虚机是要做什么应用,SDN研发也很难给出RDS的推荐配置。

 

解决方案和售前的共同点是屁股坐在销售一侧,即以达成销售目标优先。前文已经说过云计算产品还不成熟,需要按照商务需求进行快速灵活的改进,售前工程师无法平等的和研发团队做技术对话。

 

但解决方案又不是盲目服务于销售部门,售前和销售以当前快速签单为工作目标,研发团队很难对单个客户项目做深度需求分析,对项目的长期技术风险也需要我们来把握。

 

解决方案必须是一个架构师而不是工程师,因为只有架构师才能和研发团队平等对话,一个架构师也比工程师更能扛得住来自CTO的压力。解决方案工程师只能做架构师的助手而非独立工作。

 

解决方案和产品部门是合作关系,双方共同推进需求梳理和产品演进。ToC的公司里,产品经理的好朋友是运营数据汇总人员,ToB的项目可没有运营数据,但有解决方案同事做客户需求深度分析和精确效果反馈。

 

随着云计算产品的逐渐成熟,客户从要求云平台适应自身业务,变为客户业务适应标准云平台,客户项目逐渐减少前期评估和判断,解决方案这个角色会逐渐弱化,工作职责会分散到售前和产品两大部门中,但这个过程需要很长很长的时间。

 

---任职资格---

 

解决方案架构师是一个规划设计和评估推进的角色,他需要充分的了解产品适用范围、客户需求挖掘、项目可行性分析、产品改进微调和风险评估,其任职资格要求颇高。

 

首先说技术能力,解决方案架构师必须是一个称职的架构师。面对我方云服务,我们会重点考虑各业务模块的对外功能和负载情况,很少涉及单个模块自身属性改动;面对从未见过的客户业务场景,我们能快速梳理出真实的性能和功能需求。

 

再说规划能力,解决方案架构师需要做的是适应业务的项目规划,不仅仅是技术可行性规划,还包括总体成本、施工周期、SLA承诺、维护预案、后续扩容等规划方案。这每一部分规划都会写到标书和合同里,客户要看着漂亮,同事要觉得实用,甚至我们会从技术规划上留下商务伏笔。

 

这个工作的沟通、承诺和推进的能力非常重要。

 

我们要沟通的研发、销售和客户这三方,我们需要听懂每一方的自身需求,并能解释清楚另外两方的顾虑。

 

沟通的目的是为了达成共识,我们要在共识的基础上做出承诺并承担推进承诺的责任。

 

新做的方案需要你亲自去推进和验证,否则开发同事不会太配合,售前同事的底气也不足,我们也需要观察执行过程进一步完善方案,这跟产品经理上线新产品要盯着RoadMap和运营数据是一个道理。

 

有两个听起来很高大上的岗位需求其实没什么用,分别是“把握行业发展趋势”和“汇总方案的可复制能力”。

 

任何一个人都可以观察到行业发展趋势,解决方案只是自认为更超然一些汇报的趋势更中立一些,但能把握行业发展并调整姿势的是公司决策层,这个需求太虚不用刻意去提。

 

方案的可复制性是我们的梦想,但现实是我们做的是可借鉴而非可复制的方案,能直接复制的方案应该由产品经理完成产品化工作。

 

---附加声明(俗称BTW/PS:)---

 

我自己就是解决方案架构师,业绩还算可以,写这篇文章是自我反省和总结,希望能抛砖引玉。

 

我本来想把考核标准也加上,但觉得每个公司实际环境不同,认真看完前文的人会结合自身环境特点去协商定义考核标准。

 

配图是《听琴图》,解决方案是谱曲填词的人,既要思考听众的喜好,又要照顾弹琴者的手艺。话说这个文章写下来,我总觉得像在描述一个定菜单的大厨或者出方案的医生,说谱曲填词太文艺了。

 

有些小公司头衔就是印着玩的,CEO/CTO/VP/专家/架构师满天飞;某些公司内部结构混乱,每个职位安排都是平衡和算计,本文不适用这两类公司。

 

 

收藏 评论(0)
分享到: