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

-前言部分---

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

---岗位职责---

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

---背景起源---

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

---任职资格---

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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

 

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