大家能否分析下象类似我们公司开发流程的优缺点

纵向划分当属于自给自足的农耕时期，横向划分才算是有了基本的现代的分工模式。
小农意识作祟，很多人认为了解的知识越广越好，但是，如果没有一种自己专精的，也拿不出台面来。技术上都是有相通性的，你学精了一门后，就会触类旁通了。

zyp731所谈的分不清哪里出错的原因，一个可能是技术不够；二可能是没有人去真正的调查，都是在做口头原因分析；三可能是管理不足，谁的错重要吗？基本上就是这三个原因。

我认为这个流程很好啊，如果设计合理，所有人员完全可以并行工作。

1.主要靠项目经理或者高级程序员来协调，如果协调不出问题，这点就不是问题。如果直接就能把所有接口定出来，那就更不是问题了。

2.从项目角度看，员工的个人发展根本就不是一个问题，那是员工自己的事情。项目只需要在合适的位置上安排好合适的人就可以了。

3.这是一个工作协调的问题，不是流程本身的缺点。项目经理应该有办法去协调工作量。不过如果不用协调工作也能满足项目的交付的话，稍微放任一下也未尝不可。

我们现在是分模块开发，一直想分层进行呢

首先回复这位朋友的答复，呵呵。你可能没有看清楚我一开始写的，我们写底层的人员是要吧业务逻辑都通过mock或者junit测试通过了才提交到版本服务器的。所以只要到了接口就不存在业务上的基本错误，要错或者调整也是需求改动的问题了。

这里还要补充下zyp731的提问：下层的人工作的时候，上层的人在干嘛呢？

要知道其实往往做web层的人员有很多细节要去反复倒腾，html,css,js...layout等等有太多的要注意，所以做上层web的同事反而空闲的时候少。这里要说的是，其实我们做底层的同事反而有时候会存在空闲（一般都是高程人员），毕竟他们做起来都比较娴熟了。

在这里看了下大家的发言，看来在一个团队考虑到个人发展还是个人的事情，呵呵。可能真验证了一句话：八小时工作时间外才是竞争

这样好，专业分工，利于提高深度，至于广度的问题，你可以在不同的项目中做不同的事情，对于同样一个项目，你做的越窄，效率越高，节省重复学习和来回切换的成本，熟练程度大大提高。

项目规模有多大？
重复地方可以考虑工具生成
人员配备够不够，或者说预算多不
软件成熟度能达到几级？
文档全吗？
详细设计作得怎么样？
如果说文档支持不够，像楼主说的那样进行。应该是要出问题的。
或者说整个项目运作起来很吃力。

  什么项目？为啥改成spring+hibernate了？

楼上的朋友，我的意思并不是说一个项目突然改成了另一种形式，而是从某一个项目开始起采用新的结构