其实做方案是非常难的，方案能否说服自己，能否打动对方，不仅需要技巧，更重要的是对本质需求的领悟和挖掘。就比如预算方案，这些年一直没做好，不是写成了总结，就是写成了计划，今年依然长篇大论不知重点。但是经历了几次以后，现在终于开悟了，只要把领导关心的指标、费用、收入等几个数以及如何达成的策略言简意赅的说清楚，就OK了，多么痛的领悟啊！其实方案有大有小，类型不一，但本质都是一样的。最近团队经历了两件事情，让我决心写一篇文章，探讨一下我们如何做好方案。
第一件事是一个外部客户的技术开发项目。一个客户要重新上线一个官网，找到我们给做方案，出报价。本身这是一个非常常见的简单的项目，我刚开始也没过多关注，但是在参加需求沟通会时看到产品经理给出的方案，我提出了几个问题：
1、管理系统完全根据用户需求设计，从头开发需要多长时间？成本多高？
如果让客户确认按这个做，是压根赚不了钱的！而且用户的开发时间期望是一个半月，根本完成不了！
2、CMS系统本身都有非常成熟的产品，你们有无调研？有无选型？
没有！
这个方案是不能给客户看的，如果客户按照这个方案做，我们就会非常被动！所以我让技术和产品去调研，我根据自己的建议给予一些建议，也推荐了一个产品（简称A）。好，第二次开会，问题又来了！最终技术自己调研了一个半成品的开发框架（简称B），感觉这个框架能快速开发，团队上手快，适应成本低，能够按时完成客户的需求。会后，我要到客户现在网站的后台去看了一下，原来也是用的一套成熟产品，找到技术问了几个问题：
1、客户现在用的功能各方面都比较完整，客户升级系统，你们那个开发出来能比这个好吗？
基本需求肯定能满足，但看起来肯定没有这个完整。
2、有完整的解决方案可以选吗？
有，就是我上次推荐的那个产品A，而且开源！
3、为什么不选这一个？
这个开发人员感觉不如用他们选的那个B好开发！以后好升级！
4、当前的需求有多少开发量？后续维护升级有多少开发量？
事实证明，如果用A，后台基本不需要开发，而且附带大量可扩展功能，只需要写前台模板；用B后台，需求很快能开发完，但是后续功能需要不断的实现。
5、既然有成熟的、成本低、见效快的方案A，为什么选择另外一种的B呢？
因为另外一种对技术比较友好，万一以后有大量的开发维护，B比A要好一些！
但事实证明一个内容发布系统，这些成熟的系统已经把客户的需求提炼的差不多了，各种功能都具备，而且具备很好的扩展性，后续开发的可能性非常小，为这个小概率事件去选择一个可能无法让客户满意，内部无法降低成本的B是得不偿失的。
势。需求分析人员只关注了客户的需求而忽视了实现的成本和难易，因为没有提前准备方案，在沟通需求就处于被动，无法主动的引导到更利于自己的方向；技术人员只关注了技术的实现难度，过度的考虑了以后的技术支持面临的问题，却忽视了项目的实际情况。
所以，做一个合情合理的方案，需要跳出自己的思维，站在对方的角度，综合各种情况（需求、成本、价格、难度、短期、长期），多问自己一些问题，从而得出最优的方案。
另外一件小事就是内部要开发一个局域网的会议服务系统，需要CS架构，但是自己团队没有这方面的人，需要兄弟团队支持。这时候我们需要做出一个方案来进行沟通。
刚开始产品经理认为需求已经沟通过了，可以参考其他公司的产品做（只有零星的照片），有一个简单的沟通的PPT，这个就是方案。这个方案给开发人员，他能明白吗？
我让技术做架构方案，以便跟兄弟团队开发人员沟通，结果最终也没有这样的方案，只是整理了一些思维导图，可能是我给大家留的时间太短吧，也可能大家没有做架构的经验，不知道如何去表达。所以当我问技术方案的时候，虽然他们也讨论了，但是还是表达不清楚，有的地方模棱两可，当我问了几个问题后，大家仍会陷入思考。其实整体方案一张图就OK了，根据实际应用场景开始画网络拓扑图，一共5种客户端，客户端需要分组，还包含一个server；客户端之间，客户端与server之间有http，socket的两种通讯方式；文件读取分为网络读取和本地读取；读取方式不同又决定文件是否需要分发。当每个部分，以及之间的联系，顺序画好，然后讨论了各个通讯协议的优劣，文件读取的优劣，以及分发方案的优劣，最终一个整体方案通过一张图就出来了。然后再分解成为三个子系统，优先级，最后开发顺序也基本确定。
产品经理的产品原型图加上技术给的系统架构图两张图就已经把整个系统的全貌勾勒出来，开发人员看到这两张图基本上对该项目了解了八九成了，稍微做一些沟通就可以开工干活了。否则的话，又是一大堆的问题，又得开一次次的会议，便进入了低效的生产模式。
这个问题反映了我们表达方案的方式，很多方案不能只停留在某几个人的脑子里，一定要能直观的，迅速的表达出来，让其他人能一样看明白，让新人能快速上手，让后期维护迭代升级更加的清晰。而方案的表达方式是图优于文字，数字优于文字。通过图纸看概况，通过文档看细节。
总结一下，做一个好的整体方案我们需要怎么做呢？
1、需要全面的复合型的人才。近几年“全栈”人员被炒得比较火，社会在精细分工的同时，全栈人员也越来越需要，他们对于多个领域知识的融会贯通，才能全面的制定出更适合整体的解决方案。看看那些牛逼的互联网产品经理，他们之前有很多也是牛逼的技术人员，因为知识体系更加全面，所以对于方案的考虑也更加的周到。
2、跳出思维定式，多换位思考。很多时候方案不是做给自己看的，而是给客户，给领导，甚至给队友看的，思维不能框死在自己的能力槽内，要扩展出去。
3、减少线性思维，加强图的思维。我一直在团队里说，用图形来描述全局，做架构、做方案的人一定习惯、擅长画图。很多时候我们都是线性思维，往往会一叶障目不见泰山，以图去思考，才能更容易看到全局，所以领导人都是制定蓝图的。
4、做方案需要多问问题。首先要自己问自己问题，然后是人与人之间问问题，问问题的过程是逼迫你思考更加全面的过程，做方案的过程其实就是不断给问题找答案的过程。
5、方案需要表达出来。好记性不如烂笔头，一定要写出来。一个人懂，其他人不懂不行；今天懂，明天忘了不行。和不同的人沟通方案有不同的表达方式，有的人只需要一句话，有的人需要一张图，有的人甚至需要一本书。
总之，做方案要先整体后局部，先人后己！
最近我们生态圈内一直在提方案营销，方案营销相比与产品营销有何升级？整个集团的架构也在从以前基于产品和某品牌的业务划分，转变为基于不同用户群的业务划分，两者又有什么异同呢？简单来说是就是点与面的关系，产品解决的是客户某一方面的需求，以产品为出发点从根本上来说还是以自我为出发点，对于目标用户其他的需求产品无法提供，因而无法形成营销行为。而方案营销是基于客户需求出发，通过产品的组合，从而为客户提供整体的解决方案。只有能为客户提供全面解决方案的营销，才是真正能赢得客户的营销。
作者介绍
乱谭君（yongtree）
IT男，做程序猿到技术总监，后负责产品，自封团队首席产品经理，目前负责掌上医讯产品的整体运营。和大多数IT男一样比较宅，和大多数IT男不一样的是平时乱写乱说。乱谭君深知祸从口出，所以看我的文章您千万别当真，嬉笑怒骂为宽心，舞文泼墨交友人。高山流水，难觅知音。且写且珍惜！
