在写规范书通常要经过什么样的步骤，做什么事情可以达到最后的结果？在你正在写之前，首先需要确定你要解决的问题，最要紧的是从市场需求来了解，我这个软件到底该做什么，这个软件是为什么样人服务的，做什么样的事情。定出你所要的功能之前，首先先要了解使用方案，三步法，知道客户的使用方案，从那个得出你的需求到底是怎样的。然后根据体的需求总结，定出你要设计的功能到底是哪些。由这些需求、总结定出这些功能，最后根据三步法设计功能。这样你设计的功能都是为了解决客户具体的使用方案，而不是设计的功能是毫无作用的。你不按照这样的方法做，常常让开发工程师自己随意开发出一些功能，功能开发出来看起来很不错，我们叫做很酷，可是不在客户的使用方案里起到具体的作用，可以在某一个软件的菜单上按一下可以做一些什么事情，可是客户根本用不着这个，这种开发出来是一个很大的浪费。让功能的建立设计在了解使用方案的基础上，由此得出的需求上就能避免浪费。这样每个开发出来的功能都是有目的的。
写之前，在很多比较大型的、复杂的系统上，开发团队希望能够有一定的时间做一些技术可行性的调查，先写一个样品。设计经理认为我应该有这样的功能，可是这个开发团队认为说，你设计的功能可能不见得达到你这样的要求，我要看在我现行的平台上，用我现行的技术，可不可以设计出你所要的技术。在之前先做一个简单的调查，看是不是可行。样品做出来了，团队花时间写最后的规范书之前，在四面围着玻璃窗的房间里，把客户请来，做调查。整个使用方案的流程，按这个键可以灌入这个数字，可以起这个效果，你把这个不是真正的软件，是一个虚假，甚至用图象拼起来的，先把这个东西让客户用一下，看一下是不是符合你的要求。他用了说很不错，你就知道你的设计方案是对的，如果有50%认为不符合自己的要求，你就知道你的设计方案出问题了。最后你才定下来写规范书。规范书不是写完一次就完了，也是好几个回复，我们先写一个出版，把开发团队人员叫来，开发团队的领队，测试师、工程师都叫来，大家一起审核，设计这个东西是不是合理的。第一次出稿回来以后马上推翻了，开发团队说完全是不合理的东西，没有办法开发，一定要重新设计。先有出版，做审核，然后再写正版。有一个回复，可以完了以后这边再倒回去，这是一个流程。我这边写出来重点，非常要紧一点，作为我们项目开发的领导，你会看到每一个具体工作都是要时间的，都需要人去做。要定一个项目开发计划都没有算时间，如果要来回走五遍，可是你只有一遍的时候，你的计划一定要出错。最后写正版，然后审核，全部通过大家签字，说这是我们可以开发的。在某些情况下让客户签字，客户也同意了说你这个设计完全符合我的想法。如果前面的事情都做到家了，对你后面的事情是起到很大的作用。
提纲的内容，通常在微软一般包括先写一个前沿，或者梗概，用非常简单的一小段解释这是给领导看或者是给客户看。你对产品开发高层次的理解是不是很清楚，总结你所开发的产品软件到底怎么做，有什么功能。你对一个产品的功能理解，是不是能够精简到几句话，不光你作为一个项目经理可以说出来，让你开发团队所有成员都能够明确无误的说出来，这是非常要紧的。特别是客户要求，你这个文件给他读的时候，可以很清楚的知道，对客户要求的理解是不是很清楚。等规范不完的时候，最后回去做对照。看一下我原来定的总结是要完成这些任务，最后设计完以后，回去对照是不是跟原来的计划一样的。从高层次帮你指导整个开发方向应该是怎样的。
此文章共有8页 上一页 1 2 3 4 5 6 7 8 下一页
文章来源：互联网
 软件开发项目管理培训课程方案
|
Leadge.com首页 > 知识库 
