最近为了写投标书搞的焦头烂额，由于自己也是第一次比较深入的参与标书编写，实在摸不到方向，好在有人指点得到不少经验教训，特记录下来以备后用。
1. 读懂找标书：如何写首先要看如何要求
今天又被痛批一顿，原因就是标书根本没看仔细。我以为自己写技术标部分就可以了，其他部分只是很粗略的过了一遍，结果写出来的章节内容就是想当然，孰不知人家前面的要求里有很明确的说明。人家就是要求对未进行检测的功能有实质性说明，也就是说主要说明内容就是未检测功能，说明的方法是具体实现的途径和相应截图。
2. 理清方向：想清楚客户想看到什么，你要从哪个角度去写
最近两份标书在写，一是项目投标，另一个是产品选型。看了一下内容很相似，就直接把一个标书复制到另外一个标书中了，结果又被一顿教育。其实前者是一个项目，那标书中要说明的是我们系统有哪些功能，能够适应项目需要。而后者是一个选型，并不要具体产品，但要说明它的需求是怎么实现的。这就应该完全是两个角度去写，其实这些要求应该从为什么招标以及招标的具体内容角度去琢磨。
3. 前后呼应：先从总体上考虑宏观设计，再用细节章节描述具体实现
在最近一次写标书的过程中，几个人分工协作，章节一列，大家一份就各自写去了，等到合并的时候发现前后连贯性极差。参考了别人以前写的标书发现整篇前后呼应非常好，先是一个总体设计目标，然后给出相应的架构设计，指出每个子系统怎么分工协作，实现上有什么技术难点，后面就是针对每一个系统一一详细说明，再用关键技术章节说明怎么解决这些难点的，感觉就是一气呵成。仔细想一下，我们做的时候应该先大家讨论出一个总体设计和一个详细的系统功能图，再确定每个模块的具体功能，然后才是分工，这样才能保证整体的连贯性。
4. 响应需求：必须对用户需求有提炼，形成自己系统的功能
刚开始写标书，为了响应用户需求，能做的最简单办法就是换成问答题，就是他说要什么，我就说有什么，但最后写完感觉整个标书没有自己的东西，特别是自己特用的东西往哪里写都不知道了。经过指导才认识到需求是要先经过提炼，然后消化成自己系统功能的一部分，这样给别人看才认为你是理解需求了。其实你很容易发现用户提的需求是很零散的，有些需求放到一个并不太相关的子系统需求中去说明，而你实现肯定会在其他地方，这就要根据实际情况去写，还要写的有道理。其实这个过程感觉就像是给你一个新需求，让你去重新设计一套系统。对于响应的一一对应当然也是要的，这是体现在技术偏差表中，但也不是把用户招标文件照搬，还是要有一定的提炼概括，否则20页的偏差表专家会有心情看吗？！
总结一下，刚开始写投标书真是觉得摸不清标准和尺度，但想明白了发现其实没难。首先要看清楚客户到底要的是什么，然后想明白自己怎么才能给出一个满意的答案，最后就是有条理、有针对性、有信服力的把这些内容写出来。以上是这些标书编写的一点感悟，希望大家能多提意见，共同提高。
本文转自passover 51CTO博客，原文链接：http://blog.51cto.com/passover/708938，如需转载请自行联系原作者
