zoukankan      html  css  js  c++  java
  • 如何写好解决方案

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

     

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

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

  • 相关阅读:
    理解java容器:iterator与collection,容器的起源
    【软件构造】-<笔记>-浅谈java中类的初始化过程
    CSAPP HITICS 大作业 hello's P2P by zsz
    2年经验,java后端必备技术点总结(脑图)
    手把手教,手写AVL树
    Redis源码分析-底层数据结构盘点
    验证mysql事务隔离级别机制加锁情况与MVCC机制
    Layui镜像站
    elasticsearch技术实战——第一篇(使用篇)
    【基础1】JniHelper静态函数和非静态函数的调用
  • 原文地址:https://www.cnblogs.com/soundcode/p/1925931.html
Copyright © 2011-2022 走看看