如何处理软件项目中发生的需求变化

在IT行业中，有一个不能忽视的问题。这个问题就是如何面对那些经常在发生变化的业务需求。做IT项目，客户老是喜欢在项目进行过程中修改需求或者增加新需求。诚然，在项目一开始的阶段，客户不清楚自己到底需要怎么样一个系统，往往在项目进行中突然明白或者说清楚自己真正想要个什么样的系统。所以这些在项目过程中提出来的变化需求也并不是客户在无理取闹，反而对客户来说比在项目开始阶段那些双方互相确定的需求更加有意义和重要。

    就我以前的经验和思路，我对这个问题的解决思路基本上是这样的。

首先，变化就意味着风险。我们当然要把这个问题当作项目中风险的一种来处理。那常规的处理方法也就这么几个。风险的量化，风险的监控什么的。实际上判定一种风险对我们的影响程度究竟有多大的时候，我们往往只需要问自己一个问题就可以：新需求发生或者老需求变化时候，我们是否已经习惯处理这样类似的突发事件?我总结了一下，我们以前处理的时候无非也就是这样五种情况。

1．  我们以前解决过，这对我们没什么，很正常的事情。(作战能力强的团队都有资格这么说)

2．  我们没解决过，但公司里其他项目组，产品组好像解决过。有专门的解决方案文档可以查阅。（向公司内部寻找帮助是个好办法，但在中国行不通，我就看见过有人可以解决但就故意不配合你，让你自己解决去，而不给予任何帮助。）

3．  公司里没有这样的解决方案的资料，但是有很多第三方的资源可以利用。（做JAVA的人好像都喜欢，的确我也听说这样一句话：“内事不决问老婆，外事不决问google”）

4．  好像听说过有人解决过，不过记不清楚了。（等于没说，其实就是没办法解决问题）

5．  的确之前没有解决过这样的问题。但可以试一下，可以作点有开创性的工作应该会有成就感。（以积极的态度来看待自己从来没有经历过的工作）

    其实当我们面对一个变化的需求或者新需求时候，可以看看我们是采取上面五种情况里那一种来解决。我认为如果能用前面三种情况解决，基本上我们就可以答应客户去做或者更改需求。如果是后两种，最好还是慎重点为好，特别是最后一种，虽然态度是不错的，但态度有时候并不决定一切。好心办坏事的事情屡见不鲜。

   但是就算这样，并不能算结束了。其次我们还要评估一下需要增加或者修改的需求对客户的重要性问题。对于客户那边的业务人员来说，这样一个需求在他们眼里是怎么样的也决定了我们是否答应他们做这个需求。

    如果系统中没有这样一个功能，业务人员是否会注意？或者他们会注意到没有这么一个功能但觉得并不影响他们使用系统。又或者是一小部分或者一大部分甚至整个系统都需要依赖这个功能，没有它影响很大？这个也是我们在评估的时候需要考虑到的。

    还有一点就是如果我们这个项目团队没有人会完成或者修改这个需求所需要的技术怎么办？因为我是做JAVA的，JAVA的东西是在是太多了，就我看见的技术人员，没有一个人是十八般兵器样样皆精的。所以这也是需要考虑的。这样一个需求所需要用的技术是否是我们需要一段培训时间才能掌握的？或者有可能我们会，但是掌握的不太熟练，需要用一段时间才能达到熟练水平。当然也有可能我们已经很熟练了。或者对我们来说这完全是小菜一碟。

    所以当我们面临这样一个崭新的或者变化的需求，我们要从过去的风险解决经验，对客户业务人员的重要性和技术团队使用技术水平这三方面来评估。

    我以前也是经常这么做的，说老实话我觉的还凑合，基本上不会让客户说闲话。而且有时候我们要顶住客户的无理需求时候，拿这三个做理由往往都能让他们无话可说。毕竟我们讲的出道理为什么不答应做这个新需求。

评论

17 楼 redK 2009-05-22  

黑暗浪子 写道

dongjq 写道

......

多数情况下背后捅项目组刀子的倒不是客户，往往就是自己的老板！！！
这也是IT行业流动率高的原因之一。某些老板是不值得为其效力的。眼光狭小，刚愎自用，昏庸暴躁。赵云为什么死命效力于刘备而不是公孙瓒，袁绍等人我认为也是这个道理。
为什么会有风波亭？呵呵。

这个是赞同的

16 楼 黑暗浪子 2009-05-21  

dongjq 写道

黑暗浪子 写道我不知道你以前是否经历过这样的事情，当客户要求变更需求时候，我们要求客户在我们的需求变更单上签字。可是绝大多数客户都不愿意签字，因此我们正好有理由拒绝这样的需求变更。
不过客户满意度就低了很多，解决这类问题我的看法是从两方面分析。
第一要求变更需求的客户是否是客户公司里主要stakeholder还是一般的小角色。
如果是小角色，最好让项目经理或者老板和客户领导高层协商。在我碰到的情况中，我一抬客户的领导出来，小角色客户就灰溜溜的走了。
如果是大boss，那也需要先问问自己的领导和老板，看看他们是否决定需求变更。如果决定变更，你可以索要更多的时间，人力，设备等项目资源。毕竟没有多余资源让我们来做范围之外的工作也太没有人情味了。
第二如果需要变更的需求能立竿见影的提高客户满意度，那么可以做这个变更，当然也是需要让其他项目干系人（stakeholder）知道这一情况。只要其中有人反对，那么做不做就不是我们的事情，就还是回到第一条的情况。当然我们就算做变更也是需要事先向客户讲一下条件，如果该条件客户不同意，那么我们也是按兵不动。
那么是什么条件呢？for example：在项目资源比较缺乏情况下，做这个变更，那么客户需要同意在项目其他方面的要求能否低一点，比如验收测试的标准，质量审核的严格程度，或者是质量标准，又或者是减少一些没有大意义，大用途的可交付物。（有一些可交付物只是政绩工程的体现，因此非政绩工程体现的交付物可以让客户同意不交付）。
不过这是盘外招，如果客户很顶真的话，这也行不通。
呵呵，大家可以再想想或者根据自己碰到的情况说一下解决办法。我暂时就想到这一些。

签字这个太难了，估计没有几个做项目能在合同上写清楚的。

客户提出需求，这个时候我们就要分析修改带来的风险，这要让客户知道，如果客户执意要改，那么这个风险客户就应该知道，甚至负责。具体怎么负责，就是谈上的功夫了。一般没有那种客户，修改一堆，又不肯拖延时间，最后推卸修改的责任，这样的客户就是刁难了，我还没遇到。如果客户需要这个软件，我们又真心想把项目做“好”，那么大家一起努力，即使有需求变更，还是能够完成，只是路会曲折。

我的观点和你基本一致，风险较大的改动，如果客户不能接受修改带来的种种后果，我基本上不会改变，这个时候就是谈，直到有一方退步。不过也有来自公司内部上层的压力，例如老板就说，这个给他改，那我就得改，不过后果还是有人承担，就是老板了！

多数情况下背后捅项目组刀子的倒不是客户，往往就是自己的老板！！！
这也是IT行业流动率高的原因之一。某些老板是不值得为其效力的。眼光狭小，刚愎自用，昏庸暴躁。赵云为什么死命效力于刘备而不是公孙瓒，袁绍等人我认为也是这个道理。
为什么会有风波亭？呵呵。

15 楼 dongjq 2009-05-21  

黑暗浪子 写道

我不知道你以前是否经历过这样的事情，当客户要求变更需求时候，我们要求客户在我们的需求变更单上签字。可是绝大多数客户都不愿意签字，因此我们正好有理由拒绝这样的需求变更。
不过客户满意度就低了很多，解决这类问题我的看法是从两方面分析。
第一要求变更需求的客户是否是客户公司里主要stakeholder还是一般的小角色。
如果是小角色，最好让项目经理或者老板和客户领导高层协商。在我碰到的情况中，我一抬客户的领导出来，小角色客户就灰溜溜的走了。
如果是大boss，那也需要先问问自己的领导和老板，看看他们是否决定需求变更。如果决定变更，你可以索要更多的时间，人力，设备等项目资源。毕竟没有多余资源让我们来做范围之外的工作也太没有人情味了。
第二如果需要变更的需求能立竿见影的提高客户满意度，那么可以做这个变更，当然也是需要让其他项目干系人（stakeholder）知道这一情况。只要其中有人反对，那么做不做就不是我们的事情，就还是回到第一条的情况。当然我们就算做变更也是需要事先向客户讲一下条件，如果该条件客户不同意，那么我们也是按兵不动。
那么是什么条件呢？for example：在项目资源比较缺乏情况下，做这个变更，那么客户需要同意在项目其他方面的要求能否低一点，比如验收测试的标准，质量审核的严格程度，或者是质量标准，又或者是减少一些没有大意义，大用途的可交付物。（有一些可交付物只是政绩工程的体现，因此非政绩工程体现的交付物可以让客户同意不交付）。
不过这是盘外招，如果客户很顶真的话，这也行不通。
呵呵，大家可以再想想或者根据自己碰到的情况说一下解决办法。我暂时就想到这一些。

签字这个太难了，估计没有几个做项目能在合同上写清楚的。

客户提出需求，这个时候我们就要分析修改带来的风险，这要让客户知道，如果客户执意要改，那么这个风险客户就应该知道，甚至负责。具体怎么负责，就是谈上的功夫了。一般没有那种客户，修改一堆，又不肯拖延时间，最后推卸修改的责任，这样的客户就是刁难了，我还没遇到。如果客户需要这个软件，我们又真心想把项目做“好”，那么大家一起努力，即使有需求变更，还是能够完成，只是路会曲折。

我的观点和你基本一致，风险较大的改动，如果客户不能接受修改带来的种种后果，我基本上不会改变，这个时候就是谈，直到有一方退步。不过也有来自公司内部上层的压力，例如老板就说，这个给他改，那我就得改，不过后果还是有人承担，就是老板了！

14 楼 CoffeeBean 2009-05-21  

合理的系统架构和设计是应付需求变更的基石，需求变更时开发过程的常态，当架构和设计不具有可扩展性和业务的前瞻性，一些变更势必工作量大影响面广甚至要求推到重来，结果是导致客户满意度下降、开发团队内怨声载道

13 楼 黑暗浪子 2009-05-21  

dongjq 写道

需求变化是项目开始后，最大的风险之一

有很多时候，没有办法，在项目开工的时候甚至连需求都没定，边做边改，这个时候就是考验项目经理的时候，如何控制好项目。

另外项目的成功与否，不在于你项目是否做的好，代码多好，技术多先进，是否按时完成，而是客户是否满意。如果客户满意，你做的怎么样都好。所以需求变更的时候，我觉得，如果客户坚持，而且自己原因承担之后的一切风险，那么你喜欢怎么改就怎么改。最后项目做不下去了，钱给我就OK。

我是不是太功利了？

我不知道你以前是否经历过这样的事情，当客户要求变更需求时候，我们要求客户在我们的需求变更单上签字。可是绝大多数客户都不愿意签字，因此我们正好有理由拒绝这样的需求变更。
不过客户满意度就低了很多，解决这类问题我的看法是从两方面分析。
第一要求变更需求的客户是否是客户公司里主要stakeholder还是一般的小角色。
如果是小角色，最好让项目经理或者老板和客户领导高层协商。在我碰到的情况中，我一抬客户的领导出来，小角色客户就灰溜溜的走了。
如果是大boss，那也需要先问问自己的领导和老板，看看他们是否决定需求变更。如果决定变更，你可以索要更多的时间，人力，设备等项目资源。毕竟没有多余资源让我们来做范围之外的工作也太没有人情味了。
第二如果需要变更的需求能立竿见影的提高客户满意度，那么可以做这个变更，当然也是需要让其他项目干系人（stakeholder）知道这一情况。只要其中有人反对，那么做不做就不是我们的事情，就还是回到第一条的情况。当然我们就算做变更也是需要事先向客户讲一下条件，如果该条件客户不同意，那么我们也是按兵不动。
那么是什么条件呢？for example：在项目资源比较缺乏情况下，做这个变更，那么客户需要同意在项目其他方面的要求能否低一点，比如验收测试的标准，质量审核的严格程度，或者是质量标准，又或者是减少一些没有大意义，大用途的可交付物。（有一些可交付物只是政绩工程的体现，因此非政绩工程体现的交付物可以让客户同意不交付）。
不过这是盘外招，如果客户很顶真的话，这也行不通。
呵呵，大家可以再想想或者根据自己碰到的情况说一下解决办法。我暂时就想到这一些。

12 楼 dongjq 2009-05-21  

需求变化是项目开始后，最大的风险之一

有很多时候，没有办法，在项目开工的时候甚至连需求都没定，边做边改，这个时候就是考验项目经理的时候，如何控制好项目。

另外项目的成功与否，不在于你项目是否做的好，代码多好，技术多先进，是否按时完成，而是客户是否满意。如果客户满意，你做的怎么样都好。所以需求变更的时候，我觉得，如果客户坚持，而且自己原因承担之后的一切风险，那么你喜欢怎么改就怎么改。最后项目做不下去了，钱给我就OK。

我是不是太功利了？

11 楼 whaosoft 2009-05-20  

在项目时老是有变化 客户还老是特别着急 烦死人了~

10 楼 seemoon 2009-05-20  

在做项目计划的时候，应该明确项目范围，确定边界，范围内的事要做也必须做，范围外的事坚决不做。这是原则。
如何确定范围需要方法和技巧，对项目背景理解，产品了解，用户需求分析...这些是技能和方法。
当用户提出这样或者那样需求的时候，要根据确定的范围进行管理和控制，这是执行力。

原则+方法+执行力=需求管理

原则和方法可以通过学习和实践获得，而执行力更多依赖于管理者的个性、能力，包括职权。

在需求管理上面，实战经验没有多大意义，在他那边行得通在你这边却行不通，就是因为项目环境和人之间的差异。因此只有一些原则方法来作为指导，具体管理仍要看管理者自己。

由于软件的“软”特质， 用户对需求的认识是逐步明朗化，因此应对需求变化需要软件系统具备一定的弹性和适应性，这一方面来源于软件的架构和设计，一方面取决于开发方法的采纳，比如用敏捷方法开发软件在应对变化上必然强于过程开发。

9 楼 david_hg123 2009-05-19  

黑暗浪子 写道

david_hg123 写道

黑暗浪子 写道

david_hg123 写道

mock1234 写道讨论应对需求设计变化的项目管理技术很重要！

javaeye论坛讨论气氛很差，书籍或者软件广告倒是很多。我看到了一个可笑的“项目管理系统”软件广告，可笑地是，难道OA、电子表格之类的软件商把垃圾模块重新包装之后塞在一起就可以自诩为项目管理软件？

我们所谈论的大多数项目管理看来真的是垃圾啊。

到底什么才是项目管理？什么才是软件项目管理？什么才是敏捷团队的项目管理？这是有深度、需要专业性知识的问题？OA，或者办公室管理，简单地偷换成项目管理，这类找不着半点行业知识的软件会让真正在具体行业中因为懂行而才能够进行项目管理实践的人耻笑。

因此，回到楼主的讨论，提高软件项目管理应变水平要落实到技术上，从架构师自身是否由于长期管理此类项目而习惯于高水平地进行设计着手（他自己进行重构、适配设计，随时控制、协调各个开发团队的进度），而不仅仅是看看公司其它部门或者网上有没有可抄袭模仿的代码。掌握了这种技术的人才应该做项目管理。

例如，经常可以看到一些专门给大型科研企业、机关等一个办公局域网内全面进行管理并且要求高负载的复杂一些的系统，其设计者竟然直接扎到一个数据库表结构设计中去开始进行设计，而不是从了解网络互联、业务对象的通讯技术、业务对象的缓存设计等等高层次方面着手，这就是小软件作坊公司或者虽然在大公司但是只做过编程没有应对过需求设计变化的结果。就算找到很会侃架构的项目管理者，尚且有可能不能灵活应对需求变化，那些连架构都没有而是抄袭来一段段代码来“解决”需求变化的人则更难以搞懂应该使用什么技术来应对需求变化了，因为抄袭来的一个一个片段不可能具有完全一致的业务背景知识，可能是一个个非常低级的代码演示程序而只能满足普通程序员收集一些编程技巧的爱好而已。

不清楚这位“mock1234”仁兄是在和楼主交流看法和经验，还是纯粹的展示自己对项目管理的“理解”？

楼主交流的是自己的实战经验，而不是在对现目前的风气进行说三道四。我们需要的不是说教，而是各位的实战经验分享。

其实他说的也是有道理的，我十分欢迎这样有独特见解的帖子，有些事情不辩不明。通过互相交流自己的想法学到点新东西也是一件好事。

引用一个不恰当的例子：

1、用“纸上谈兵”来指挥你作战

2、用“实战经验”来指挥你作战

你喜欢哪种？

呵呵，不必这么排斥。理论也有它合理之处，关键看使用理论的人如何使用～

呵呵，你说出了我的真实意图。补充一点，那为仁兄说了那么多理论，却没有说出是如何使用的。

8 楼 黑暗浪子 2009-05-19  

david_hg123 写道

黑暗浪子 写道

david_hg123 写道

mock1234 写道讨论应对需求设计变化的项目管理技术很重要！

javaeye论坛讨论气氛很差，书籍或者软件广告倒是很多。我看到了一个可笑的“项目管理系统”软件广告，可笑地是，难道OA、电子表格之类的软件商把垃圾模块重新包装之后塞在一起就可以自诩为项目管理软件？

我们所谈论的大多数项目管理看来真的是垃圾啊。

到底什么才是项目管理？什么才是软件项目管理？什么才是敏捷团队的项目管理？这是有深度、需要专业性知识的问题？OA，或者办公室管理，简单地偷换成项目管理，这类找不着半点行业知识的软件会让真正在具体行业中因为懂行而才能够进行项目管理实践的人耻笑。

因此，回到楼主的讨论，提高软件项目管理应变水平要落实到技术上，从架构师自身是否由于长期管理此类项目而习惯于高水平地进行设计着手（他自己进行重构、适配设计，随时控制、协调各个开发团队的进度），而不仅仅是看看公司其它部门或者网上有没有可抄袭模仿的代码。掌握了这种技术的人才应该做项目管理。

例如，经常可以看到一些专门给大型科研企业、机关等一个办公局域网内全面进行管理并且要求高负载的复杂一些的系统，其设计者竟然直接扎到一个数据库表结构设计中去开始进行设计，而不是从了解网络互联、业务对象的通讯技术、业务对象的缓存设计等等高层次方面着手，这就是小软件作坊公司或者虽然在大公司但是只做过编程没有应对过需求设计变化的结果。就算找到很会侃架构的项目管理者，尚且有可能不能灵活应对需求变化，那些连架构都没有而是抄袭来一段段代码来“解决”需求变化的人则更难以搞懂应该使用什么技术来应对需求变化了，因为抄袭来的一个一个片段不可能具有完全一致的业务背景知识，可能是一个个非常低级的代码演示程序而只能满足普通程序员收集一些编程技巧的爱好而已。

不清楚这位“mock1234”仁兄是在和楼主交流看法和经验，还是纯粹的展示自己对项目管理的“理解”？

楼主交流的是自己的实战经验，而不是在对现目前的风气进行说三道四。我们需要的不是说教，而是各位的实战经验分享。

其实他说的也是有道理的，我十分欢迎这样有独特见解的帖子，有些事情不辩不明。通过互相交流自己的想法学到点新东西也是一件好事。

引用一个不恰当的例子：

1、用“纸上谈兵”来指挥你作战

2、用“实战经验”来指挥你作战

你喜欢哪种？

呵呵，不必这么排斥。理论也有它合理之处，关键看使用理论的人如何使用～

7 楼 david_hg123 2009-05-19  

黑暗浪子 写道

david_hg123 写道

mock1234 写道讨论应对需求设计变化的项目管理技术很重要！

javaeye论坛讨论气氛很差，书籍或者软件广告倒是很多。我看到了一个可笑的“项目管理系统”软件广告，可笑地是，难道OA、电子表格之类的软件商把垃圾模块重新包装之后塞在一起就可以自诩为项目管理软件？

我们所谈论的大多数项目管理看来真的是垃圾啊。

到底什么才是项目管理？什么才是软件项目管理？什么才是敏捷团队的项目管理？这是有深度、需要专业性知识的问题？OA，或者办公室管理，简单地偷换成项目管理，这类找不着半点行业知识的软件会让真正在具体行业中因为懂行而才能够进行项目管理实践的人耻笑。

因此，回到楼主的讨论，提高软件项目管理应变水平要落实到技术上，从架构师自身是否由于长期管理此类项目而习惯于高水平地进行设计着手（他自己进行重构、适配设计，随时控制、协调各个开发团队的进度），而不仅仅是看看公司其它部门或者网上有没有可抄袭模仿的代码。掌握了这种技术的人才应该做项目管理。

例如，经常可以看到一些专门给大型科研企业、机关等一个办公局域网内全面进行管理并且要求高负载的复杂一些的系统，其设计者竟然直接扎到一个数据库表结构设计中去开始进行设计，而不是从了解网络互联、业务对象的通讯技术、业务对象的缓存设计等等高层次方面着手，这就是小软件作坊公司或者虽然在大公司但是只做过编程没有应对过需求设计变化的结果。就算找到很会侃架构的项目管理者，尚且有可能不能灵活应对需求变化，那些连架构都没有而是抄袭来一段段代码来“解决”需求变化的人则更难以搞懂应该使用什么技术来应对需求变化了，因为抄袭来的一个一个片段不可能具有完全一致的业务背景知识，可能是一个个非常低级的代码演示程序而只能满足普通程序员收集一些编程技巧的爱好而已。

不清楚这位“mock1234”仁兄是在和楼主交流看法和经验，还是纯粹的展示自己对项目管理的“理解”？

楼主交流的是自己的实战经验，而不是在对现目前的风气进行说三道四。我们需要的不是说教，而是各位的实战经验分享。

其实他说的也是有道理的，我十分欢迎这样有独特见解的帖子，有些事情不辩不明。通过互相交流自己的想法学到点新东西也是一件好事。

引用一个不恰当的例子：

1、用“纸上谈兵”来指挥你作战

2、用“实战经验”来指挥你作战

你喜欢哪种？

6 楼 黑暗浪子 2009-05-19  

david_hg123 写道

黑暗浪子 写道
就是他们领导不同意，而且是两个项目经理对等交流，人家那组项目经理根本不鸟你。这是我看到过的。不过另外一些情况中，由CTO或者技术总监去push的话，解决问题成功率几乎是百分之百。唉，这年头没有活雷锋啊

其实换个位置思考，每个领导都有自己的难处和顾虑，想想周围到处都是虎视眈眈的竞争者，谁敢懈怠？所以更谈不上无私奉献。

因此，为合理处理需求的变化，（有）沟（才）通也是非常重要的一门学问，在下不才，也经常为这类的事情犯愁。

其实我这篇文章是来源于《敏捷软件开发》中的一段。我当时写此文目的是针对作者的美国思维说一些自己的想法。毕竟中国的情况很不一样。不能照搬美国的做法。特别是关于这个内部寻求帮助的事情，其实是作者提出的。我针对我看到的情况说几句自己的话而已。

5 楼 黑暗浪子 2009-05-19  

david_hg123 写道

mock1234 写道讨论应对需求设计变化的项目管理技术很重要！

javaeye论坛讨论气氛很差，书籍或者软件广告倒是很多。我看到了一个可笑的“项目管理系统”软件广告，可笑地是，难道OA、电子表格之类的软件商把垃圾模块重新包装之后塞在一起就可以自诩为项目管理软件？

我们所谈论的大多数项目管理看来真的是垃圾啊。

到底什么才是项目管理？什么才是软件项目管理？什么才是敏捷团队的项目管理？这是有深度、需要专业性知识的问题？OA，或者办公室管理，简单地偷换成项目管理，这类找不着半点行业知识的软件会让真正在具体行业中因为懂行而才能够进行项目管理实践的人耻笑。

因此，回到楼主的讨论，提高软件项目管理应变水平要落实到技术上，从架构师自身是否由于长期管理此类项目而习惯于高水平地进行设计着手（他自己进行重构、适配设计，随时控制、协调各个开发团队的进度），而不仅仅是看看公司其它部门或者网上有没有可抄袭模仿的代码。掌握了这种技术的人才应该做项目管理。

例如，经常可以看到一些专门给大型科研企业、机关等一个办公局域网内全面进行管理并且要求高负载的复杂一些的系统，其设计者竟然直接扎到一个数据库表结构设计中去开始进行设计，而不是从了解网络互联、业务对象的通讯技术、业务对象的缓存设计等等高层次方面着手，这就是小软件作坊公司或者虽然在大公司但是只做过编程没有应对过需求设计变化的结果。就算找到很会侃架构的项目管理者，尚且有可能不能灵活应对需求变化，那些连架构都没有而是抄袭来一段段代码来“解决”需求变化的人则更难以搞懂应该使用什么技术来应对需求变化了，因为抄袭来的一个一个片段不可能具有完全一致的业务背景知识，可能是一个个非常低级的代码演示程序而只能满足普通程序员收集一些编程技巧的爱好而已。

不清楚这位“mock1234”仁兄是在和楼主交流看法和经验，还是纯粹的展示自己对项目管理的“理解”？

楼主交流的是自己的实战经验，而不是在对现目前的风气进行说三道四。我们需要的不是说教，而是各位的实战经验分享。

其实他说的也是有道理的，我十分欢迎这样有独特见解的帖子，有些事情不辩不明。通过互相交流自己的想法学到点新东西也是一件好事。

4 楼 david_hg123 2009-05-19  

黑暗浪子 写道

就是他们领导不同意，而且是两个项目经理对等交流，人家那组项目经理根本不鸟你。这是我看到过的。不过另外一些情况中，由CTO或者技术总监去push的话，解决问题成功率几乎是百分之百。唉，这年头没有活雷锋啊

其实换个位置思考，每个领导都有自己的难处和顾虑，想想周围到处都是虎视眈眈的竞争者，谁敢懈怠？所以更谈不上无私奉献。

因此，为合理处理需求的变化，（有）沟（才）通也是非常重要的一门学问，在下不才，也经常为这类的事情犯愁。

3 楼 david_hg123 2009-05-19  

mock1234 写道

讨论应对需求设计变化的项目管理技术很重要！

javaeye论坛讨论气氛很差，书籍或者软件广告倒是很多。我看到了一个可笑的“项目管理系统”软件广告，可笑地是，难道OA、电子表格之类的软件商把垃圾模块重新包装之后塞在一起就可以自诩为项目管理软件？

我们所谈论的大多数项目管理看来真的是垃圾啊。

到底什么才是项目管理？什么才是软件项目管理？什么才是敏捷团队的项目管理？这是有深度、需要专业性知识的问题？OA，或者办公室管理，简单地偷换成项目管理，这类找不着半点行业知识的软件会让真正在具体行业中因为懂行而才能够进行项目管理实践的人耻笑。

因此，回到楼主的讨论，提高软件项目管理应变水平要落实到技术上，从架构师自身是否由于长期管理此类项目而习惯于高水平地进行设计着手（他自己进行重构、适配设计，随时控制、协调各个开发团队的进度），而不仅仅是看看公司其它部门或者网上有没有可抄袭模仿的代码。掌握了这种技术的人才应该做项目管理。

例如，经常可以看到一些专门给大型科研企业、机关等一个办公局域网内全面进行管理并且要求高负载的复杂一些的系统，其设计者竟然直接扎到一个数据库表结构设计中去开始进行设计，而不是从了解网络互联、业务对象的通讯技术、业务对象的缓存设计等等高层次方面着手，这就是小软件作坊公司或者虽然在大公司但是只做过编程没有应对过需求设计变化的结果。就算找到很会侃架构的项目管理者，尚且有可能不能灵活应对需求变化，那些连架构都没有而是抄袭来一段段代码来“解决”需求变化的人则更难以搞懂应该使用什么技术来应对需求变化了，因为抄袭来的一个一个片段不可能具有完全一致的业务背景知识，可能是一个个非常低级的代码演示程序而只能满足普通程序员收集一些编程技巧的爱好而已。

不清楚这位“mock1234”仁兄的意图，是在和楼主交流看法和经验，抑或是纯粹的展示自己对项目管理的“理解”？

楼主交流的是自己的实战经验，而不是在对现目前的风气进行说三道四。我们需要的不是“高度”的说教，而是各位切合实际的实战经验分享。

2 楼 黑暗浪子 2009-05-19  

yiding_he 写道

如果另外一个项目组解决过该问题，那么你应该跟他们的上级商量，腾出专门的时间来帮你们解决，而不是直接找人家的开发人员，因为人家也有事情要做。

就是他们领导不同意，而且是两个项目经理对等交流，人家那组项目经理根本不鸟你。这是我看到过的。不过另外一些情况中，由CTO或者技术总监去push的话，解决问题成功率几乎是百分之百。唉，这年头没有活雷锋啊

1 楼 yiding_he 2009-05-19  

如果另外一个项目组解决过该问题，那么你应该跟他们的上级商量，腾出专门的时间来帮你们解决，而不是直接找人家的开发人员，因为人家也有事情要做。