博客
关于我
强烈建议你试试无所不能的chatGPT,快点击我
如何写好解决方案
阅读量:5888 次
发布时间:2019-06-19

本文共 2526 字,大约阅读时间需要 8 分钟。

 最近手头接了公司一个方案编写的任务,但一直没有好的思路,虽说以前也写过产品的一些方案,有一定的沉淀,但仔细想来,基于产品的解决方案和基于定制开发的方案应该有很大的不同。所以就通过网络和以前的朋友,找了一些方案,分析对比后,把个人的一些感受写下来,以供大家探讨。不妥之处,还望不吝指出,以便改进。

通过这次方案的编写,我个人有以下体会:
1、用户的需求把握很重要,要找到用户的关注点。
方案编写前,实际上有个用户需求调研的过程,要按咨询的一般流程,对用户目前的业务流程进行描述、分析,象医生之于病人一样,通过望、闻、问、切,找出问题所在,然后对症下药。但由于分工不同,往往我们拿到手的资料很有限,对用户的需求的把握不够,甚至于没有和用户正面接触过,这中间就有很大的风险。怎么办?我个人认为,应该这样处理:
基于有限的有户需求,展开广泛的用户需求讨论,讨论的范围是和这个项目有关联的所有人员,包括销售人员、产品和售前组人员、部门的领导。大家从每个人的认识上,充分挖掘用户的需求,并对挖掘出的用户需求分优先级,然后再在统一的思路下去分别展开具体的方案编写工作。领导说得好“方向对了头,一步一层楼嘛”!最后由产品售前组统一进行方案的优选和整合,在整个方案中,要做到突出重点,要有靓点。
下面给个流程图,是基于咨询的,可以给我们提供参考:

 

  2、站的高度要足够高,要从管理层面的高度,既要有就事论事的详细技术解决方案,更要有领导层面的监控执行和决策分析

好的方案,应该是站在全局的高度,从高管层、管理执行层、业务操作运行层三个层面分别提出决策分析、监督控制及数据采集录入的完整解决方案。这个过程中,许多人只专注于技术,关心技术解决方案,而忽略了高层的分析决策及中层的管理控制功能,这也是方案的大忌。我们一般可以采用由下而上写,由上而下检查,上下结合,统一验证的办法处理。

  3、先搭框架,再逐步细化

遵循一般问题分析方法,先构建整体框架(参考14一般解决方案模板),然后再提取总的解决方案,再逐步细化,最终抽象出具体的支持方案的模块,接下来再按由下而上的流程,对流程进行验证、修改,保证高层、中层及业务层在数据源、数据结构及业务逻辑上的统一性,最后对每个模块的特点、靓点做详细地描述。
4、方向要明确,最好从管理角度切入,不能单纯的就事论事
做方案时要记住,我们提供给用户的是总体解决方案,不只是单纯的技术方案,用我们熟悉的成熟的技术,加上优化的用户的流程,结合用户总体战略,就可以编制出满足用户需求的方案。
5、最好有参考的方案,做好平常的知识积累
我们遇到的客户,需要解决的问题是各不相同、有时甚至是跨行业的,这就要求我们的售前和需求人员要加强平时的学习和积累。一些好的方案,特别是知名咨询公司的方案,是对我们有启发意义的。平时加强优秀方案的学习,积累一般问题的解决方案,可以使我们有更多的精力关注于具体用户的个性需求,用信息化实现用户个性管理思想,这也为用户最为关注和推崇的,而这个过程的实现,实际上是个双赢的过程,实现上知识的双向转移。
6、最好的方案,是无招胜有招的境界
我们在现实生活中,常遇到这样的情况,许多IT公司的高层,并不是学习计算机专业出身的,看似外行管内行的情况普遍存在。但只要你深入地思考一下,实际上做到一定的程度,在有了广泛知识积累后,就发现各行业总是相通之处的,正是由于他们有了知识转移和复用的能力,高度决定了他们的视野,武功的最高境界是无招胜有招,这决不是空谈。只要你用心去想,这个道理大家都能想通。具体到我们的方案,针对每一个CASE,我们都力争提取出共性的一面,这样,我们的水平也就提高到了另外一种境界。
7、别小看细节和形式
“泰山不拒细壤,故能成其高;江海不择细流,故能就其深”。所以,大礼不辞小让,细节决定成败。我们在方案编写过程中,也要注意细节,比如良好的组织形式,清晰的思路,严谨地措辞,都会使我们的方案添彩,反之,如果一个方案中错别字充斥其中,想想阅读者会有怎么样的感受。还有一点,我们在做给客户的方案中,不能用外行话,涉及到行业的专业术语,如果不懂,不妨GOOGLE或BAIDU一下,网络不是只用来看优酷,看新闻的,网络极大的降低了我们的学习成本,这么好的平台,我们何乐而不为呢!
8、与其面面俱到,不如靓点突出
以点带面,突出靓点。我们做任何事情,都不可能做到尽善尽美。但在方案中一定要突出我们的靓点,突出我们与众不同的一面。对于系统的靓点,我们要不吝笔墨,详细描述,力争用户一想到我们,就想到我们的系统是什么样子,如果做到这一点,方案的胜出也就是顺理成章的事情了。
9、需求和售前人员要勤于思索,凡事怕琢磨
我们不但要站在IT技术的角度,更要从客户的业务角度,以换位思考的方法,以不同的客户角色的身份,阐述实现方案能给用户带来什么,做详细地说明。是降低成本呢?还是方便工作、降低工作强度?是给领导还来决策支持呢?还是提高生产效率?对系统的经济效益进行多维度分析。我们可以设想系统运行的全过程,不断地思考,反复地修订,直到最终定稿。
10、 没有思路的时候,别强行下手
11、实事求是不可忘,可以略带发挥,但不能天花乱坠,不能让用户一看这根本就实现不了,是在做秀。
12、不断学习很重要,不怕不懂,就怕不学。
13、最忌照抄,做事要用心,方案出新,逻辑性要强
这实际上是网络资源的一种滥用,有时转贴或参考一下别人的方案,无可厚非,但如果滥用别人的方案,或断章取义地照猫画虎,对用户来说是不尊重对方,对我们来说,也只是敷衍,你对用户的不负责,怎么可能要求用户对你负责。你始终要明白,你的方案将来会有许多人去阅读,如果有人说,这是网上的照搬,或是网络方案的堆砌,那无疑给你的方案判了死刑。
14、忌只从技术的角度入手,只有技术方案,没有管理方案,要知道方案能否顺利通过验收,主要是领导层决定的。
15、一般解决方案模板

本文转自左正博客园博客,原文链接:http://www.cnblogs.com/soundcode/archive/2011/01/04/1925931.html,如需转载请自行联系原作者

你可能感兴趣的文章
[转]Windows7 64bit下配置Apache+PHP+MySQL
查看>>
CentOS6.5 下在Nginx中添加SSL证书以支持HTTPS协议访问
查看>>
给trac的ticket添加提交时字段验证
查看>>
nodejs安装-配置
查看>>
Node.js学习-1
查看>>
今天你的应用崩溃了么?
查看>>
项目中的*签到*小功能!
查看>>
iOS 获取cell.accessoryView自定义视图以及点击事件
查看>>
java 考试试题
查看>>
[caffe(一)]使用caffe训练mnist数据集
查看>>
闭包,装饰器
查看>>
vs2013编译错误解决: _declspec(dllimport) 动态链接库
查看>>
这是一篇被河蟹了的博客
查看>>
一个两年Java的面试总结
查看>>
转:React Native之旅01-创建项目
查看>>
软件工程项目组Z.XML会议记录 2013/11/27
查看>>
科学计算库学习报告
查看>>
软件测试 -- 软件测试的风险主要体现在哪里
查看>>
修改App.config中的appSettings
查看>>
JQuery选择器总结
查看>>