为什么软件项目开发要写规格书

开发软件项目为什么要写规格书

以上内容，纯是个人的观点，全局默认加了，在我看来，毕竟每句话加上，在我看来，在我看来，有点傻傻的

为什么人们不写?

大部分人都知道有规划书肯定好，因为有总比没有好嘛，或者说，有些人，觉得有这个东西在，肯定有他被造出来的理由啊，开个玩笑。其实大多数人，是知道他的处好的，但是知道的可能只是冰山一角，却没有看到大冰山。

那大多数人的认知里，规格书是什么样的存在呢？

甲说：简直就是浪费时间，我写的项目，我心里还能没有逼数吗，规格书还用写出来吗？全都在我的脑子里。我有这个时间，还不如多打几行代码呢，多完成一些业务呢。

乙说： 这么高级的东西，都是航天局，造原子弹的人才配拥有的，对于我们来说没什么意义，作用太渺小，我都不想看它。

但是，实际上，大多数时候，并不是大多数人想的那样，规格书，好处还是很大的，同时还可以补救，提升表达对象是人的能力，毕竟完成这个之后，是给人看的嘛，这个能力很多程序员都是匮乏的，因为成天和代码语言沟通，和人的沟通就少了。话题扯得有那么一点远了。。。

那么来说一下，到底有哪些好处，值得我们去写。

规格书最重要的作用就是对程序功能进行设计，即使规格书，只有你一个人看。在写规格书的过程中，当你强迫自己去写，你就会体验你在做真正的程序设计，而不是脑子里像的那个初略的样子。

规格书，就好比在建造一个人在做一个项目的大局观，虽然建造的过程中，对业务的进度来说看起来几乎为零，但是实质上真的为零吗，不然，他只是在为后期铺路，打地基，只要一完成，速度就开始飞起来了。而没有规格书的项目，表面上看上去，一直都有进度的样子，当时间久了，缺点就暴露出来了。

没有规格书的项目什么样子 ?

一直都是凭着开发者，脑子中的 “规格书” 来写，但是因为脑子的记忆容量是有限的，而且还有时效性。昨天想到的东西，或者，某个没有解决的BUG，睡一觉起来，什么事都没有发生过的感觉，去继续项目。这样的项目写的代码，一般是想到写到哪，没有总体的布局，就像一座房子盖的歪歪扭扭的，很不平衡，极容易因为一点小动静就倒塌了，写出的项目代码，一般比较差，BUG还多，不容易维护。

没有规格书的项目，很难去估计项目当前的进度，因为某一时刻人们的大脑能回忆起来的东西是有限的，当一个项目很大的时候，不可能回忆出项目的边边角角，而且，随着时间推移，记忆还会遗忘。

有规格书的项目是什么样子?

比较容易去估计项目的进度，因为就像一本有目录的书，你可以安排几天看完，而没有目录的书，你真的很难去做规划。而规格书，写了对程序的设计，怎么去实现，需要什么技术。这些一看，就可以比较容易估计出，项目的进度怎么安排，大概需要投入多少资源，有什么技术上的需求，项目在进行的过程中，会出可能会现什么样的问题，都会有一个整体的把控。而且项目做起来，就会很有条理，因为，好比是看着目录做的。

再者，对于团队其他的成员来说，有了规格书，就省去去了很多沟通上的障碍，描述不清楚的问题，因为其他项目成员，人手一本规格书，看起来一目了然，节约了很多时间。以前沟通上需要付出的大量时间，而且有一个问题，某个成员问了你某个项目的问题，可能当时你描述清楚了，但是，时间久了，他可能又忘了，又来问你了，你又要说一遍，这在编程上来说，就是冗余，还有一种一种情况，就是：你也忘了。这个时候，要是有一本规格书，他就不用来问你啦，他翻一翻就能解决疑问了。

在写规格书的过程中，所有不好的设计，都会暴露在规格书中，如果没有写，很容易被忽略，等，项目都做好差不多了，才发现，那就真的麻烦了，就像一座房子，都盖好了，你又说，他地基盖的不好，要改，你说改的难度大不大，要是一开始就有了蓝图（规格书），早就发现了问题，提出了改进的方法，也不至于后期投入那么多时间去改正一个扎根比较深比较的问题了。

对于投资者来说，一看你的规格书,心里很快就有了低了,毕竟功能设计都说明好了，连规格书都有，逼格高，显得很专业，投资几率就大了，而且有什么问题,他也好容易提出来，及时改正。

总的来说： 写规格书，利大于弊啦，不要吝啬这点时间啦，赶快趁着有项目的时候体验一把，写规格书之后带来的快感吧，不是短暂的快感哦，是持久的！！！