http://www.szlghsjx.com/

软文推广:方案怎么做?

废话不说了,为了帮助大家尽快进入工作节奏,今天聊一聊做方案的东西。老手们可以跳过本篇,对于一些面对这类任务感觉无从下手的同学来说,可以参考一下。

关于如何做方案,之前有过一些文章,从某些点出发讨论方案的撰写,今天我们从工作流程的角度,看看一份方案是怎样从无到有、从一个想法变成一份能够交付的方案的。当然,这个所谓的流程只是根据自己的经验做了个简单的整理,仅供参考。

一般而言,一份方案从接到任务到交付出去,可以分为“构思”、“草案”、“草稿”、“制作”、“检查”这五个阶段。名字是我瞎想的,看看具体都干了些什么就基本清楚了。

构思:考虑清楚这个方案到底是要干嘛的

草案:搭好方案的框架

草稿:添加枝干,确定各模块的具体内容

制作:完成方案

检查:让方案更完美

当然,这套流程的前提是时间足够,遇到紧急任务的同学,可以参考这篇文章:《很急?试试快速迭代》

下面简单介绍下每一步都要做什么,做到什么程度,输出是什么。

构思:考虑清楚这个方案到底是要干嘛的

先前的一篇文章《能解决问题的方案才是好方案》里,我们提到过“一份解决方案的主要内容很简单:一个问题和一个答案”。这个步骤主要就是为了干好这件事,即找到这份方案要解决什么问题,同时给出解决办法。

关于如何找对问题和答案的内容,参考上面提到的文章就好,这里就不再多说了,只想再一次提醒大家,这一步至关重要。

我在工作中见过不少同事一接到任务就匆匆忙忙开始写东西,最后却对着看似完成却乱七八糟的方案头疼,不得不一次次重新来过(我见过修改了一年还算不上好的方案)。究其原因,还是因为一开始就没想好这份东西交出去到底是用来做什么的。

换句话说,构思这个阶段,就是确定好一个大方向,大方向出了问题,后面做得再用心,也是白费力气。而如果一开始就找准了这个点,后面的工作就轻松多了,所以在这一步,我强烈建议大家多花些时间和心思,思考为主,动手为辅。

通常这个阶段完成的标志是,很清楚这个方案是给谁的、用来解决什么问题以及如何解决问题。输出的东西,有可能只是两句话:问题和答案;也有可能是一份简单的导图。这个看各人习惯。

草案:搭好方案的框架

在这一步中,我们要做好这几件事。

理清逻辑线和故事线:通常我们会按照某种逻辑思考一个问题的解决方案,我们称之为逻辑线,也可以叫思考线。但有些情况下,我们需要用“讲故事”的方式来做这份方案,就需要重新调整各部分的顺序,或者增减内容,我称之为故事线。比较常见的是发布会上用到幻灯片、用于忽悠客户的市场材料、用于特定教学方法的课件等。

确定方案架构:确定了主线之后,方案所需的各个部分也就基本清楚了,这个就是整体架构,就像是一棵大树的主干,在后面,我们就要围绕它来添加各种内容。

确定要填充的东西:注意,这个是“东西”而不是“内容”。也就是说,我们现在不需要确定具体的内容是什么,只需要知道这里大概要放个什么东西就可以了,举个例子,在方案的某个部分,我们只需要标注“这一节论证一下喝酒容易造成损失”就可以了,而不需要标注为“举一个案例:喝醉了之后去球场玩耍还妄图去抓幻想出的小偷结果摔断腿”。之所以这么做,是为了在后续的工作中保留余地,更有弹性。

这个阶段的输出,通常是一份主题明确,主线清晰的导图或大纲。如下图。

草稿:添加枝干,确定各模块的具体内容

这时候的主要任务是将大纲细化,并补充针对各部分或模块的大概描述,说明白每个部分要写什么内容。有些次级议题的论证逻辑,也需要在这个时候补充完整。另外,一些需要填充的具体内容也要在这个阶段确定下来,比如某个图示,或上面提到的具体案例。

事实上,我们可以把前面这三步看作是规划的阶段。这个阶段的输出也是看各人喜好,如果你喜欢修改方便,更专注于思考,或许可以输出一份手稿。

当然,如果时间比较紧急,或者内容已经烂熟于胸,或者需要其它人的合作,也可以直接用powerpoint来做。比如下图,除了少有的几个现成素材外,其它都没有具体内容,只是标注了每一页要放什么东西而已。

制作:完成方

这部分其实没什么好说的,前面都已经规划好了,剩下的几乎可以看作是体力活,该写什么文字就写什么文字,该画什么图就画什么图。

如果前面逻辑清楚,每一部分的文字都只是一篇短短的命题作文,甚至几句话而已,每一张图,也不过是依样画葫芦,简单得很。只要前面花了足够多的时间,这里拼的就是打字速度或者做PPT的熟练度了。

这阶段的输出当然就是一份完整的方案了。

检查:让方案更完美

写完方案,不检查肯定是不行的,先不说一些错别字,单就是逻辑这一块,至少都会有一些需要修修补补的地方。这个检查,要么自己来,要么让别人来。之前的一篇文章《构建方案的逻辑》里提过这件事,摘录如下。

讲给自己听:这一招在撰写方案的过程中就应该养成习惯。试着把每一个思考和做成导图的片段都用语言描述一遍,如果逻辑有问题,很快就能发现。在整个方案完成之后,也应该至少完整的试讲一遍,看看是否通顺,如果磕磕绊绊的,往往就是逻辑有问题。

讲给别人听:有时候习惯了某种思考方式就难以察觉到其中的逻辑错误。这时候,多讲给持不同意见的人听是最好的选择。想想看林肯为了完善决策任命了多少自己的政敌,而你的方案同样也是为了要说服那些最顽固的反对派,所以不要怕对方提出质疑,只有勇敢的面对这些质疑,才能持续改进和提高。如果公司有内审机制,也是个不错的选择,多一些意见就会多一些改进的可能性。

检查这个阶段最让人痛苦和烦躁的是,它并不是一遍就可以完成的。为了让最终输出的结果更令人满意,在有时间的情况下,我们得一直重复“发现问题 → 修改 → 发现问题 → 修改 → 发……”这个过程。这里再放一张老图反映一下我的心情吧。

不过让人欣慰的是,最终,你的方案将会越来越完善,越来越有说服力。

OK,以上是一个简单的步骤分解和解释。在实际工作中,前三个阶段的分界其实并没有那么明显,大家也可以根据自己的习惯进行调整,但绝不可忽视它们。通常如果一份方案需要在一周内搞定的话,我会至少花2-3天时间在前三个阶段,1-2天用来写方案,剩下0.5-1天来检查和修改。

以上,供参考。有机会的话,会慢慢把各部分内容再细化。