跑马圈地之时，你需要游骑兵
作者 | 林壮壮
来源 | 健壮的大姐姐（ID: is_strong）
前几天我收到一位读者的留言，他提出一个问题：在To B客户的售前谈判中，是不是只要销售就够了？这个问号刚落下，他又自我否定，那客户想了解产品和技术细节怎么办？不成，还是得派产品研发同学护航。那产品研发忙着出差，谁来负责产品需求迭代呢……
多次的假设和推翻假设，最终他迷茫了，试探性地问了句，难不成在售前阶段要配备专门对接客户的人员，这个人懂客户、懂销售、懂产品、懂技术？
Bingo.
诚然，一个项目的胜败，会受到诸多因素的影响，但究其本质，项目背后的组织才是关键点。不妨试着复盘下，在你过去曾经做过的或成功或失败的项目里，人员的组成结构如何？能力模型是否匹配要求？这些项目成员是否有统一的目标？做事的套路是否自成一体，还是彼此冲突？但凡有一个条件不满足，是否都会成为项目延期或停滞的潜在风险？
我们来缩小讨论范围，在售前阶段，甚至是商机线索刚开始引入的时候，你的人员结构该如何布局？
不妨试着回想下，你的团队里，产品同学是不是成日忙着应对客户需求，不是在飞机上就是在去往机场的路上？技术同学时不时被拉到咨询群里当着一流的客服人员，微信群里的消息呈指数级增长？项目经理面对一揽子需求埋头琢磨如何转换成产品能力，烦恼越来越多、头顶越来越凉？
问他们，累吗？超累的。
为什么？
除了传统的销售之外，你要补给什么人力，自然要根据具体项目的需要。但是有些通用的弹药是要提前准备的，比如我们今天要谈到的售前架构师。
一、架构师=游骑兵
很庆幸，我在团队里遇到一支很优秀的架构师队伍，总教头曾经公开谈过他对架构师的定位——游骑兵。何出此言？
先来看下，游骑兵究竟背负着什么使命？
侦察，盘活地形的利害，探察敌军的要害；
独立战斗、防守、生存下去；
呼叫支援，为大部队指明方向；
参与关键的地面战斗。
而对应到架构师呢？
项目商机评估分析，摸底竞品深浅；
编写、评审、交流方案，协助客户完成沟通汇报；
对接项目管理办公室，保障项目交付进程；
项目交付和运维保障支持。
看出二者相同点了没？
我在公司这几年，作为项目管理办公室的一员，算是团队中最直接和架构师接洽的角色，也确实被这只游骑兵队伍的专业素质所折服。
深入的业务理解，是这个行业领域的专家；
扎实的技术功底，能跟客户的IT技术团队无缝交流；
深谙销售套路，媲美商务的谈判和说服能力；
项目管理小能手，具备完整的立项、方案编制、项目控标能力；
连接产品和项目需求，具备关键项目交付控盘能力。
这是什么四通八达的神仙人设？我也曾一度质疑过，但事实证明，这支队伍众望所归，他是产品对外圈地盘的主力军，是项目对接支持的核心区。
为什么？
先来看架构师的日常。
一天伊始，他要去拜访客户。昨天销售拉了一个单过来，客户期望听到一个详尽的方案。于是架构师连夜规划产品方案，给客户进行汇报后，了解到客户目前的整体预算和痛点，再根据客户要求调整方案，尽快推动项目立项审批。而这时候销售敲起了警钟：隔壁老王家也出手了，客户蠢蠢欲动。于是架构师一边要跟对手PK产品技术，持续改善客户方案，牢牢抓住客户的心；一边要从技术层面为项目找到立足点，与项目里的其他产品形成联合方案，共同把项目金额做大。
与此同时，另一个已经谈妥的项目准备启动交付，架构师要跟前方项目经理沟通项目整体规划，协助把控产品交付节奏，并着手配合项目经理引导合作伙伴入场交付。这期间架构师需要持续保持与产品团队的沟通，确保准确传递市场和客户的反馈，明确产品研发的优先级。
而同样的，还有一些已经上线的项目，正准备拉开二期项目的立项，架构师要配合销售保障二次销售机会，进一步打开产品的销售和市场份额……
二、架构师的求存之道
基于架构师的职责要求，我们来一一解读下，对架构师来说，最难的是什么？
1、项目机会的评估
当选择太多时，顾客会被决策过程所困扰，因为要区别出众多选择的不同实在麻烦。而人们又不想放下手头的事情来思考该选哪个，因此导致对产品失去兴趣。
罗伯特·西奥迪尼《说服力》
了解领导：客户领导级别（科、处、CIO级别）的人员，是否具有实质性的决策权； 回顾过去：政府和大企业客户通常都是在前一年规划预算，了解下客户去年是否做过预算，有助于我们判断是否要在今年投入资源； 环顾周边：客户的对手是谁，去年做过什么成绩；客户是否有政绩压力，是否急于出成绩。
商机来源：是销售直接引入的机会，还是通过代理商牵线来的； 销售观察：在商机引入时是否有其他竞争对手，对手在客户侧的评价反馈如何； 销售领导：公司内部负责这单项目的销售领导级别，领导对这单客户的重视程度；比对下竞争对手负责销售的领导级别。
2、客户沟通与汇报
在前期和客户沟通的过程中，伴随着一系列的汇报工作。不要小看这些汇报工作，在你帮助了客户决策人在他的领导面前体现更多的成绩，你和客户之间开始有了更加紧密的关系。
以政府客户为例，每一次国家新政策的颁发、重大会议的开展、评比的举行、领导的视察等，都需要项目团队协助支持编制方案，帮助领导完成政绩汇报。
下面以某政府客户的某次领导视察为例，架构师在这整个过程中需要做些什么？
汇报前：
1）架构师需要提前摸清楚客户决策链里的客户参会情况，包括参会领导级别、关注点、痛点——参会情况可以更好地协助架构师评估本次汇报的投入度；
2）在产品给出的标准化材料之余，通过销售提前了解客户的关注点，针对客户的关注点着重展开专项说明——从编写的方案中体现对客户的重视；
3）摸清楚竞争对手前期跟客户交流的情况，客户对竞争对手的态度如何——尽量搞清楚客户的意向，同时要明确跟竞争对手有一些不一样的点，确定“打击策略”；
4）通过给出清晰完整的案例、实际数据、图表来做展示，直接切入主题——给客户更为直观的体验。
汇报过程中：
1）当面再口头确认一次客户这次交流所关注的重点，再有针对性的介绍；
2）在不清楚客户倾向性意见的情况下，不对竞争对手做主观性的评价，尽量用一些事实案例、具体数据来体现优势，引导客户自己做出判断；
3）察言观色，根据客户对内容的反馈临场进行调整。
汇报后：
1）完成清晰的会议纪要，并跟客户关键人员确认；
2）针对本次交流的未完全明确的问题，通过补充材料的方式，再提交给客户；
3）通过销售或内部人员了解客户决策人对于本次汇报的评价，评估是否对采购意向有推动效果。
简言之，通过每一次协助客户的沟通和汇报中，建立与客户的关系。而良好的关系建立在彼此互利的基础上，主要体现在：
1）你能很好地解决客户的核心诉求。帮助客户完成关键的本职工作，在领导面前引起关注，把成绩单贴在客户名下，支撑他的晋升通道；
2）你是专业的。从规划方案、招投标、交付落地、验收，让客户省心、放心、安心；
3）你和别人不一样。在这过程中树立自己与众不同的专家形象，争取进入到关键客户的核心智囊团。
3、产品和项目的衔接
前面两点我们主要在谈架构师与客户之间的“情感纠葛”，接下来不得不提到架构师与产品内部团队之间的磨合。
从项目需求到产品规划，在To B产品中需要有一个转换器，将项目上的业务需要“翻译”成产品行话，同时又能将产品的能力结合项目的需要形成解决方案。
架构师就是这样的一个角色。作为既懂业务，又懂产品的人员，他需要将项目和产品双向联动起来。
具体体现为：
1）挖掘客户需求背后所关联的产品能力，判断该需求的合理性，为产品需求规划提供原始数据支持；
2）通过分析行业市场、比对竞争对手，为产品研发团队提供更开阔的视界；
3）评估客户所提的定制化功能，是否是这个行业内的通用诉求。项目中的定制功能转化成产品标准功能的比例越高，说明产品路线是越健康的。
三、小结
在To B竞争格局愈演愈烈的情形下，产品同学忙着为客户提供贴身服务、逐渐偏离产品初心，技术同学混迹在各大客户群里既当客服又当测试，项目经理捧着满怀需求两眼泪千行……这种人员结构是否是错位的？是否要开始调整下？
此时正是跑马圈地的时候，你需要配备这样的一支游骑兵队伍。
他在开拓地盘摸索战况的同时，深谙待客之道；他在上阵战斗攻防求存的同时，懂得适时引入内外援，构筑有力的防线。
因为有架构师，我们可以打理好客厅，也同样顾得上后院。产品和项目之间的Gap被填上了，所有项目和产品的相关人员终于可以串联起来，共同朝着同一个目标前进。
回顾往期文章：
欢迎长按二维码关注“健壮的大姐姐”，如果能点个“在看”就再好不过了。感谢阅读，鞠躬。