好的售前解决方案需要这样写

一.动笔前先打一个电话
    一般情况下,方案撰写人只是按照别人的要求提供方案,并非直接利用方案的人。所以在写方案之前,问问需要方案的同事,甚至是客户,听听他们对方案的想法和建议,这样对写方案会有很大帮助。
    闭门造车往往导致接受者对方案不满意,要求返工修改。所以动笔前先打几个电话,问清楚客户需求,这样不但可以提高方案的针对性,也可以获得大量的解决思路线索,对写方案大有好处。
二.努力按客户业务逻辑写
    一般写方案最简单的方式就是按照协同软件设计思路和功能模块来写,因为有大量素材可用。但这样撰写方案并非是一种最佳选择,因为对客户而言,他必须转换角色进行思维,要站在供货商的思维模式上才能看懂方案字句之间的含义。
    如果从以客户为中心的角度出发,方案应尽量让客户容易看懂,好理解,自然也就取得了较好的印象分。
    方案应先仔细探讨客户业务,而不是将调研结论一一罗列,应从业务分析中推导出业务需求,最后描述技术实现手段。从这个意义上讲,解决方案要按照简明的业务手册来准备。
三.按标准套路写方案
    同类型的方案都有自己的套路,例如可行性报告、解决方案、建议书等都各有套路。一个公司可以经常讨论完善和丰富方案的写作套路。我们应尽量按照标准套路准备方案,不要自成体系。在既定套路下发挥,套路就体现了一种结构化、体系化的思维模式,很多客户本身也是习惯阅读有套路的文档。

    套路和为客户定制并不矛盾,好的套路反映了专业文档定制的经验。

四.先构思提纲,经过讨论,最后动笔

    很多时候方案的准备时间并不充分,很多人接到任务之后立即找个范本修改,这是不好的工作习惯。
    有时候利用模板的确可以较快地完成任务,但时间长了就形成了惰性,形成用替换方式抄改方案的习惯。真在实际工作中遇到个性化较强的项目,而标准供应链管理方案模板没有涵盖时就无从应对。这是因为平时写方案过程中思维始终缺少结构化思考练习的结果。
    写方案时一定不要急着动笔,而是先想提纲。提纲中的逻辑联系和业务衔接在脑海中推导得比较有力和充分了,才开始动笔;有了提纲,思路就不会断,写起来才快。
    如果有条件的话,这个思路还应该和大家讨论,特别是一些重要方案,一定要先反复讨论提纲。各种意见和思路在提纲中统一了,再动手写。这样就不至于遇到方案写完评审时又被否定,不得不推倒重来的痛苦。
五.找一个安静的地方和完整的时间段开始
    写方案最怕中间不停地被打断,这样思路无法保持连贯性。所以无论接到多么紧急的方案编制任务,也不要急着去写,而是先把手头该处理的小事情处理干净,确保编写的时间段相对安静和完整,这样才能保证方案的质量。
    定要保证在一个时间段内初步拿出完整的推导思路和结构提纲,然后就可以逐步补充和丰富内容,不至于在写的过程中还为结构苦恼,不清楚从哪里下笔,每次要花费大量时间从头构思。
六.认真准备方案的阅读提示和摘要
    客户决策领导往往公务繁忙,时间有限,很难保证将厚厚一本方案的内容全部认真研读,所以方案可以单独附一份摘要以供客户领导浏览。摘要重点介绍整个方案中的精华部分,当然也可以附带实施方法和典型用户介绍。通过摘要让方案的解决问题的思路在短短几页纸中得到清晰、准确的描述,这种用精炼文字描述业务思路的能力往往更能给人留下深刻印象
    对于较复杂、内容较多的方案一定要提供一份阅读提示,告诉不同的人其关心的内容可以通过阅读哪些章节直接获得。实际上很多论文和书籍序言都会有一段来说明文章的结构,读者可以直接进入感兴趣的话题,这对我们编制方案也是一个有益的启发。
七.注意积累素材
    写方案时,无论按照何种客户业务组织材料,必然有80%的内容是相似的,毕竟软件设计理念不会在短期内发生巨大改变,方案涉及功能边界在短期内也不会发生大的改变,所以不同时期不同用户解决方案中很多素材是可以通用的。特别是一些公司通用素材,更是要随时注意积累、补充、完善和归类保存,只有在乎时多作有心人,在写方案时才不会因为缺少素材而将大量时间浪费在查找数据上。
    还要注意基本素材的运用要随时和公司的宣传口径保持一致,防止引用过期素材。标准素材库应由公司统一维护。
    获取素材的途径主要有:
    》现场初步需求调研与交流。
    》与熟悉类似项目的销售经理、技术支持工程师、实施工程师进行沟通。
    》与营销人员交流。
    》可收集的同行方案。
    》客户的网站。
    》相关行业的资料介绍。
    》行业书刊。
    例如客户企业介绍一般可以从客户的网站获取。从网站获取的客户企业介绍需经“角色转换”和“内容筛选”。角色转换是指站在软件公司的立场描述该客户的情况,要把第一人称改为第三人称。内容筛选是指主要介绍客户信息化的基础,包括客户的经济实力、管理水平、已完成和正在进行的信息化项目等内容,不要简单地复制粘贴。
    又如:行业战略分析可以从相关行业网站中寻找素材和灵感;对业务问题解决思路可以从同行方案中寻求素材和灵感,并结合自己的素材进行组织和提高。
八.多写,然后熟能生巧
    写,勤写,主动积极地写。把每次写方案当作一次提高的机会。在这样的心态下才能写出好的方案。再好的经验也必须经过反复练习才能成为自己的习惯,养成良好的方案撰写习惯也是反复练习的成果。
    寻求回馈意见,持续改进
    很多人写完方案后,就觉得任务完成了,是成是败,已经过去。
    但对于一个想写一流方案的人,每次电子商务方案提交后一定要征询相关人员的看法和意见,对于认为写得好的回馈信息,要分析究竟好在哪里,遇到同样情况时,可以有意识地借鉴;对于回馈不好的意见,要力求在下次进行改善。通过有意识地扬长避短,方案就能日见精练,更能打动客户。
    真正有志于写出完美方案的人,对自己的方案是永远不会满意的,也只有这样,才会每次进步一点,解决方案的质量才会不断提高。
已标记关键词 清除标记
1、课程简介 Spring Cloud是一系列框架的有序集合。它利用Spring Boot的开发便利性巧妙地简化了分布式系统基础设施的开发,如服务发现注册、配置中心、消息总线、负载均衡、断路器、数据监控等,都可以用Spring Boot的开发风格做到一键启动和部署。        在本套课程中,我们将全面的讲解Spring Cloud技术栈, 从环境的部署到技术的应用,再到项目实战,让我们不仅是学习框架技术的使用,而且可以学习到使用Spring Cloud如何解决实际的问题。 Spring Cloud各个组件相互配合,合作支持了一套完整的微服务架构。 - 注册中心负责服务的注册与发现,很好将各服务连接起来 - 断路器负责监控服务之间的调用情况,连续多次失败进行熔断保护。 - API网关负责转发所有对外的请求和服务 - 配置中心提供了统一的配置信息管理服务,可以实时的通知各个服务获取最新的配置信息 - 链路追踪技术可以将所有的请求数据记录下来,方便我们进行后续分析 - 各个组件又提供了功能完善的dashboard监控平台,可以方便的监控各组件的运行状况 2、适应人群 有一定的Java基础,并且要有一定的web开发基础。 3、课程亮点        系统的学习Spring Cloud技术栈,由浅入深的讲解微服务技术。涵盖了基础知识,原理剖析,组件使用,源码分析,优劣分析,替换方案等,以案例的形式讲解微服务中的种种问题和解决方案 l  微服务的基础知识 n  软件架构的发展史 n  微服务的核心知识(CAP,RPC等) l  注册中心 n  Eureka搭建配置服务注册 n  Eureka服务端高可用集群 n  Eureka的原理和源码导读 n  Eureka替换方案Consul n  Consul下载安装&服务注册&高可用 l  服务发现与服务调用 n  Ribbon负载均衡基本使用&源码分析 n  Feign的使用与源码分析 n  Hystrix熔断(雪崩效应,Hystrix使用与原理分析) n  Hystrix替换方案Sentinel l  微服务网关 n  Zuul网关使用&原理分析&源码分析 n  Zuul 1.x 版本的不足与替换方案 n  SpringCloud Gateway深入剖析 l  链路追踪 n  链路追踪的基础知识 n  Sleuth的介绍与使用 n  Sleuth与Zipkin的整合开发 l  配置中心 n  SpringClond Config与bus 开发配置中心 n  开源配置中心Apollo 4、主讲内容 章节一: 1.     微服务基础知识 2.     SpringCloud概述 3.     服务注册中心Eureka 4.     Eureka的替换方案Consul 章节二: 1.     Ribbon实现客户端负载均衡 2.     基于Feign的微服务调用 3.     微服务熔断技术Hystrix 4.     Hystrix的替换方案Sentinel 章节三: 1.     微服务网关Zuul的基本使用 2.     Zuul1.x 版本的不足和替换方案 3.     深入SpringCloud Gateway 4.     链路追踪Sleuth与Zipkin 章节四: 1.     SpringCloud Config的使用 2.     SpringCloud Config结合SpringCloud Bus完成动态配置更新 3.     开源配置中心Apollo
©️2020 CSDN 皮肤主题: 大白 设计师:CSDN官方博客 返回首页