项目中几个技术问题的解决方案（解决方案如何写）

实际的工作中，不管是项目经理还是售前工程师，给客户提供的大部分解决方案一定是基于某个类似解决方案或者参考模板，这样做的好处就是能够快速高效的产出一份解决方案，解决方案的内容、层次、思路等方面出现问题的几率都比较小，相对是一份完整的、可读性强的方案。但是如果长时间依赖原有解决方案，对于客户提出的个性化的一些要求，我们可能就难于下笔，或者提交客户的解决方案无法体现出客户个性化的解决方案，难以让用户满意。

通过对低质量的解决方案的分析，我们不难发现他们都具有如下一些特点：

• 追求数量，而不是质量，看似厚厚的几百页方案，其实有效的、可读的内容少之又少，更多的是一些套话、政策、功能的一些罗列，完全是为了写方案而写方案。
• 客户痛点分析不透彻，解决方案的最关键也是最基础的工作就是总结客户面临的问题，低质量的解决方案这部分内容基本都是东凑凑、西凑凑，总之，这部分内容有就行，是不是客户的痛点，并不重要。
• 解决思路不清晰，所谓解决思路就是根据现有客户的问题，提出我们的解决思路，不少的解决方案缺少这部分内容，也有的一些方案基本也是找一些套话放进去，体现不出解决方案的针对性。
• 提出的解决方案过于臃肿，客户本有有一些小问题或者痛点，解决直接被你放大到5倍、10倍。本来100万预算能够解决的问题，非得给客户规划500万、1000万，实际经验告诉我们，这些都是徒劳无功，没有任何作用。
• 格式不规范，这个是属于比较低级的，有的解决方案编写完成后，目录、标题、缩进、图例等等都不规范，整个文档看着非常的粗糙，这种解决方案基本客户都会PSS掉，不会采取的。强烈建议，如果你长期需要编写方案，建议你整理一个通用模板，避免一些低级错误，如果大家没有，小编给大家提供一个：

10年项目经理推荐的“项目可研报告”，12章节，共100页

1、相关资料收集很重要

实际经验告诉我们，平时工作中，愿意收集资料的同事，更容易写出高质量的解决方案文档。“工欲善其事，必先利其器”、“他山之石，可以攻玉 ”这些蕴含的道理大家应该都明白，在我们编写解决方案时，不管是痛点分析、解决方案的提出，如果我们有一些基础资料能够材料，对我们会有非常大的帮助，也能启发我们的灵感，特别是我们有思路、有想法的情况，更是能够帮助我们快速整理出一份高质量的解决方案。

2、写上去的一定是自己理解的

给客户提供的解决方案的每一个段落，不管我们是找参考资料还是从类似方案中借鉴，只要写到解决方案的内容，一定是我们自己理解的。实际的工作中，不少的同事自己提出的解决方案，客户随便找个点咨询，竟然被问的一塌糊涂，遇到这种情况，你觉得客户还有相信你吗？所以，只要你写到解决方案上面的内容，你一定要理解。

3、掌握业务要全面，不能一知半解

对于客户的业务，特别是有规模的企业，他们的业务相对也复杂，给编写方案的人员带来一定的难度。对于复杂的业务，我们可以不全盘掌握，但是方案中涉及的业务我们要全面的了解，比如业务涉及的部门、涉及的人员、业务的流程等等，这样我们在需求分析的时候，才能更加的准确到位。

4、公司产品的特色、优点要掌握

提供给客户的解决方案，如果能列举同等规模、同等级别、遇到的问题类似的企业的成功案例，解决方案的说服力会更强，也有助于客户理解提供的解决方案的思路。但是这样做的前提就是编写方案的人员需要掌握公司的产品的特色、优点。如果不具备这个能力，那就不要胡乱写，不能对号入座的案例，客户可能会怀疑公司的实施能力。

5、客户关注的内容，单章节呈现

如果我们前期有和客户沟通，或者通过商务已经了解到客户关注的内容，我们需要把客户关注的章节单独成章节展示。这样的好处有：客户能够快速找到自己关心的内容，而不是包含在整个文档里面，让客户去查找，如果客户没找到，客户会认为你提交的方案不专业，不予采取。

6、解决方案的基本思路要掌握

很多的方案也能够提出客户的问题，也给出了对应的解决方案，但是没有详细的阐述解决方案中的措施是如何解决客户的问题。类似与我们高中时候写作文一样，只有论点，没有论证。就像高中语文老师讲到的，满满的800字的文章，全是论点，对于文章开头抛出的问题，一概没有提出论证，前后没有呼应，一篇不合格的论文。写解决方案也是一个道理，相信大家应该理解了。

7、检查、检查、再检查

解决方案编写完成后，还有一个非常重要的步骤就是检查，首先要检查的就是目录、页码、页眉、项目名称等等这些基本信息，其次要检查的就是图例，文中可能从别的文档复制的一些图片，一定要改掉，客户是非常反感的，最后就是非本次解决方案需要的文档一律删掉。