谈谈需求的变更

本来只想写一篇的，没想到写着写着就成了系列了。关于这个系列的前两篇文章：《谈谈项目的开发》《谈谈项目的执行》。在写这篇文章之前，先答复一些朋友的疑问，项目的开发，有没有必要到那以细呀？究竟有没有必要，见仁见智吧，毕竟每个管理者在管理时所面临的问题都是不同的。首先说说一名TEAM LEADER往往会面临到的问题吧：

1、保证项目的质量与可维护性。人员很多都是刚毕业的，编码的方法、变量命名都很不好。

举个例子来说，数学的大于用的单词是Bigger，很让人无语。看过我前面的文章都知道，我是很强调要多阅读代码的，如果你是经常阅读一些好的开源代码，是不可能出现这样的命名的。

2、提交的代码，看似完成，但是细节差得太远了。

比如说，TAB键的处理；ENTER键的处理；ESC键的处理；按钮的排列，哪些按钮的放右边，哪些按钮放左边；页面的边距等等这些细节。由于是新手，往往是会不注意这些的，所以必须明确下来，否则做出来的各式各样。

3、人员很不好管理。具体可以参考我前面的文章。

4、开发人员之间缺乏沟通，很多可以重用的方法，却各自都写一遍。

5、作为TEAM LEADER，要去阅读他们的代码，如果不知道问题的解决思路，阅读起来就要花费多时间。还有一个问题，就是新人的能力往往是比较欠缺的，以其在做的时候问，倒不如前事就告诉他们怎样去做。同时，也让他们有个准备，不致于按排的任务因为能力的原因而无法完成。

6、准确汇报项目的进度，每周都要向上汇报一次进度。

7、合理分配任务，协调好各人的开发进度。

由于以上几点，所以必须清楚项目细节，以便掌控整个项目开发，往着自己所期待的方法发展。

另外还有朋友问到的几个问题：

1、关于接口的细节制定：由TEAM LEADER来制定。

2、关于接口的变动。一般都是由于设计的时候没有想好，或者需求的变更。关于需求变更引起的变化后面再讨论。由于设计的不足，队员在开发时候常会碰接口的参数不够，某些功能缺乏相应的接口，关于接口，还有参数，这个应该是在开发前，就应该讨论好，想好的。在后期需要变动，应该是比少。应该怎么变，需要些什么接口，如果队员已经知道是谁负责的，直接找相关人员。否则向TEAM LEADER汇报，再按排人员。由于变动的接口比较少，TEAM LEADER对整个项目还是在掌握中的。

---

关于需求的变更，这人是在每个项目开发的时候的都是会碰到的。一般来说，在对项目进行初期的分析调研后，或分成几个里程碑，每个里程碑都都要完成哪些内容。现在假定有V1，V2，V3…… 这些里程碑版本，其中V1是给客户演示的一个版本，V2是待演示的一个版本，V3是正在的开发的一个版本，其中演示版本和开发版本都好理解，为什么还要有个待演示版本呢？主要是避免当前开发版本出现意外，无法按时发布。

当我们接到需求变更的时候，应该极力避免接到一个需求变就立马修改代码这种情况。需求的变更设为三个等级，轻微、普通、来得。

1、轻微。一般指的是对之前所写的代码，基本上没有影响。比如说增加显示的字段。

2、普通。一般指的是增加一个功能，但是增加的功能和之前的代码没有太大的冲突，基本上通过增加表或者字段就可以实现。

2、严重。一般指的是流程的变更。就是之前的需求分析中，少了一个流程，或者流程错了。

当需求的变更只是轻微和普通的时候，还是按原来计划进行开发。在这个阶段中，接到的需求如果不是严重性的，都放到下一个版本去。在这个过程中，要做好设计方案 ，也就是说，要改哪些API，要怎么去改，和之前文章提到的基本上一样。对于需求的变更，尽可能采用批量修改的方式，而不是有一个改一个。主要是因为：

1、尽量给开发人员一个稳定感。避免他们因为频繁的修改而做出一些过激的行为。

2、这样做会有更有条理，不容易有遗漏。

当接到一个需求变更是属于严重等级，也就是说，对当前开发影响很大的，很多地方的代码都改动的。这个时候首先要做的就是设计了，然后进行讨论，和前面说的基本上一样。在开发之前，记录好当前已经完成的功能，还有未完成的功能。然后开一个分支，不要直接在原来的基础上改，否则哪天客户一拍脑袋，又要改回去，估计你会恨不得撞墙的。不知道你们有没有碰到过，反正我是碰到过的。开一个分支的好处是，在N个版本之后，客户说要改回去，可以把对应的版本找出来，进行合并。

这就是我对需求变更的处理。沟通是需要花时间的，但是我认为，总得来说，还是值得的。