开发流程图

当然可以完全不理用户的需求变更来维护计划，可是用户也可以维护自已的利益，不给项目打款。

不是一起用。 开发部门管理项目就是怎样按时把它实现。 对于整个公司第二个图非常好，等我晋升时可能会有体会。 

对于开发部门，一个项目是否能按时的完成很重要。这关系到项目在开发部门的成败。 我画的这个图是想表达这个。非站在公司的整体角度。  这个图主要想说明两点1、要把提需求的客户和程序开发隔离。就是图中的两个大矩形。这个是想避免客户的打扰把项目时间拖后。 2、开发的迭代。就是不要想一次就做到完美。先把基本功能框架做出来，这样就不存在开发不按时完工的问题。然后计划后面的时间，第一波完善什么，第二波完成什么，等等 。

1.对于开发部门，一个项目是否能按时的完成很重要。这关系到项目在开发部门的成败。

我觉得对于开发团对来说，最重要的是能不能满足用户的需求。换句话说，就是开发出来的软件能不能解决用户的问题。是否能按时完成决定软件成败的说法的确不能认同。你的意思是软件按计划晚开发出来一天，这软件就完蛋了吗？这有什么关系！

2.要把提需求的客户和程序开发隔离
现代的软件开发理论，都提倡开发过程有用户参与，还是头一回听说要隔离用户的。在现实的项目中，很多用户都很懒，他才不愿参与到项目中，他就是希望时间一到，就拿到满意的软件。因此，常常需求人员不得不追着用户看相关的的软件成果，以尽早发现需求中的问题，得到反馈，从而纠正软件开发中的错误。

3.开发的迭代。就是不要想一次就做到完美。。。
按你的思考需求在第一部已经定好了呀。即然这样，为什么不能开发出来完善的程序呢？
用迭代就能保证按时完工了？

你们开发的时间是谁规定呀？外一时间规定的不合理，你们岂不糟糕。这的确是时常发生的事。

项目管理的目的 我想是把软件做好 给公司赚到钱！

我看不出来你这两个图怎么分出来公司层面的还是开发团队方面的，直接观查你的两个图有一部份内容是相同的呀：

需求调研                   需求矩形

详细设计                   以开发者分析，设计问题

编码&单无测试              编码、需求的符合度和Bug测试

这两个图明显有内容相同的地方，在我看第二个图只不过是一个瀑布模型的软件开发流程，你怎么分的公司层的？ 其实我没太懂你所谓 公司层 这个词的意思。

 

 

不符合实际，不推荐，

看到大家的意见，我感觉我还需虚心学习。
关于 gdpglc 会员提出的问题很好，但我这不想 answer ， 我想把这个帖子沉下去。主要原因是这个图不值得大家学习。就让它自生自灭。

顺便提下 gdpglc 提的：“很多用户都很懒，他才不愿参与到项目中，他就是希望时间一到，就拿到满意的软件。 ”我也有感触，现实中这样的应不少。

同意

LZ , 我不知道你这是画的什么玩意、

整个一垃圾贴，老兄，我很忙的，别耽误我时间好不好，发贴值得提倡，可以鼓励，也不至于什么贴子都发吧！