再谈解决方案编写(12.09)

对于技术建议书或方案的编写，实际上在我博客上有专门的文章详细谈到过，今天还是想再谈下解决方案编写方面的话题。大家都知道，我们在日常工作中，涉及到内部技术选型，产品研发，或者对外的投标等往往都涉及到解决方案编写。解决方案的编写本身不是一件容易的事情，因为解决方案基本就是你要告诉别人这件事情该如何做？遵循什么方法来做？在解决方案最终评审完成后通过后可以基于解决方案进行具体的建设和实施。

解决方案编写为啥难？这个绝对不是简单的文档编写方面的技能问题，而是你有无类似的领域本身的大量实践并总结为自己的方法论的问题，即所有的方案都不是你简单的理论糅合，而是你已经有了大量的实践后自我总结出来的可以付诸于实施，可以落地的行动。否则方案很容易就变成了空中楼阁并无法落地，看上去很完美，但是却无法进行落地实施工作。

所以对于解决方案要能够编写的比较好，一个是你大量的实践经验积累，一个就是抽象和结构化的能力。同时如果你经常都做同一个类型的项目，那么你就会积累大量的可复用的知识库，这个知识库越强大那么你编写解决方案的能力也就越强。

即任何一个解决方案的编写都有明确的套路，简单来说就是基于需求和问题域，分析清楚有哪些特定和差异化的内容，对于这些差异化地方给出有针对性的解决思路，然后改解决思路+共性可复用的知识库资产共同糅合，就形成一个完整的解决方案。这个解决方案既具备了针对性，又完全复用了我们已有的资产内容，达到快速编写方案的目标。下面谈下一个解决方案的编写关键。

需求和问题域

所以的解决方案都是从需求驱动的，这个需求也可以叫做是问题，目标等，不论哪种方式描述最终都必须转换为两个层面的内容，即问题和目标，目标的描述最终也是从问题驱动出来的。而衔接问题和目标之间的就是具体的解决方案。所以任何解决方案编写完成后你要能够回答，或者让客户能够想明白的就是你给的解决方案为何能够从问题到达目标。

从问题到解决方案

从问题到解决方案，里面核心的就是问题分析的过程，即如何从问题到解决方案？整个问题的定义，问题分析过程究竟是如何的？实际上我们看到当前很多解决方案基本都不会详细的对这块思路进行阐述，因为整个过程要说清楚相当不容易，而且看你文档的客户本身和你的知识储备可能也不一样，因此这个问题分析过程很难说清楚。正式由于这个原因，当前更多的思路我们看到是：

基于我们类似的项目经验和已有的知识库积累，分析差异化后直接给出最终的解决方案或者说目标架构，然后我们再来分析目标解决方案和架构为何能够解决当初提出的问题。即你只要能够论证解决方案为何能解决问题，而不需要讲你的解决方案是如何推导出来的。

如果你以前没有类似项目经验的积累，那么可能的方法就是你只能够去参考业界这块的最佳实践是如何的，然后结合实际的问题和需求，对业界的多种最佳实践和方案进行评估，给出切合客户需求的解决方案。但是这种解决方案能否最终解决问题你实际不清楚，你只能够说是从理论角度应该这样做而已。如果要自己心里面更加有底点，那么更好的方法就是你需要先去做一个简单的POC验证，通过验证情况再来归纳和整理你的解决方案，这样你自己心里往往会更加有底点。

解决方案的细化展开

我们希望的解决方案细化展开本身也是逐层分解细化展开的，具体到每一个目标实现点，这个时候你要能够看到当初我们的提交的问题点和最终的目标实现点之间是能够映射上的。即问题点能够映射到具体的目标实现点。任何一个子问题点都有具体的解决方法点说明。实际上按照严格意义上的问题分析和解决，你是在得出具体的解决点后，再将各个子目标解决方法糅合为一个完整的大的解决方案。然后在大的解决方案上体现分层，分维度等内容。

简单来说，解决方案细化展开就是要把你详细做哪些事情都全部说清楚，并让用户很容易理解这些要做的事情和问题点之间的映射关系。