Onsite和Offshore的开发过程的讨论

to airbird ：

其实能够采用分级开发方式进行项目开发的，有个前提是公司的业务、产品都很成熟。
我们现在SAP的开发是分为功能组、技术组和开发组，功能组定义业务功能设计说明书，技术组定义技术开发设计说明书，开发组做编码，开发组的人员确实一点都不知道业务功能，这种模式要求：一、公司有产品、有完善的技术体系；二、业务方面，有资深的顾问和产品实施人员，知道业务要做什么，以及怎么做；三、技术方面，开发框架和工具都很成熟。四、开发工作与实施工作相比，其内容很小，是在产品功能的基础上进行的补充。

但是根据你提的情况看，你们公司是做国内的项目，这些前提条件可能不具备。

高端组的人员如果是单纯的做技术方案设计的话，可以采用分级方式，如果是高端组还要做业务的需求分析和设计，我的经验是很难达到效果，架构好办，业务难做，一个项目中的功能设计人员如果无法跟完项目，这个项目失败的可能性会很大，业务分析和功能设计人员最好不要想独立出来，要进入一线，和开发人员一起完成项目开发，不要指望文档，国内的项目客户的业务成熟度都很低，文档只能做到大致的流程和规则，还有很多内容是无法通过文档来说清楚的。而且我们一般都还没有做深做精一个业务领域的思路，做的项目往往都是不熟悉的业务领域，这时候就更不可能将功能设计人员分出来。

在人力不够的情况下，公司可能要确保几个项目，把项目做分级，保证这几个项目的力量，有的项目则没办法，可能只有通过商务手段延缓项目进度或者采用分包方式，逐步调整人力结构，这样的运作可能会好些。如果你觉得公司领导要求你必须分级，你可以跟领导商量，从公司运作的风险上，建议逐步采用，先拿优先级低的项目做试点，优先级高的项目人力要保证资源配备合理，这样几方面都可以平衡。

另外，总体设计的评审，如果公司没有项目涉及到的业务的顾问和专家的话，评审没有任何意义，谁都不知道要做的是不是对的。

香港外包有采用这种方式的，结果就是项目作为完了，程序员还不知道程序是用来干啥的。奇怪吧。

一蓑烟雨任平生:
我也反对这种方式，可是一直难以找到更好的理由去说服领导。
就让实际项目去检验一下吧。只要在心里对自己说：如果项目成功，是我们的功劳，如果失败，是领导的责任，尽管实际截然相反。

呵呵，是啊，您提到的这点是这种工作方式的首要成因：高端组能力强，做好了需求分析，总体设计之后，可以拍屁股走人，参与其他的项目的高端工作。高端组人员为公司的项目组共享。所以，领导振振有词的说：这种方式有助于缓解高端的分析设计人员短缺的现状。
可是事实真的如此？我很担心。

是的，我总认为，一个人连自己做什么都不知道，谈何做好？

这样做公司是为了省钱吧

呵呵，他们（那些老总）只是因为恐惧，而又不知道该做些什么，所以病急乱投医罢了。

能省钱吗？能保证软件质量吗？能保证开发进度吗？
他们这些家伙心里根本就是没底的！

老兄,这样做对于一个公司而言毫无疑问是正确的,无论什么时候既了解业务又精通技术的人员都是绝对稀缺的资源,将他们的时间放在更加有价值的核心和概要设计上,我想这样考虑的老总恐怕不是外行吧?
而且也是对项目质量最负责任的考量,当然如果项目只有1-2个人月的项目就不说了:)

让水平较高的人做核心和概要设计是没错，但是问题在于硬性拆分成高端组和低端组，这个问题就比较大了。

要是所谓高端组真的对于设计精通也就罢了。但实际情况由于技术的高速发展，往往高端组的设计陈旧，或者高端组试图尝试新技术但自己不去验证，低端组就得帮助完成这份费力不讨好的工作，后果将是举轻若重。总之，自己不参与实现的设计者，往往好高骛远，心中描绘着自己的空中花园，认为这就能建立宏伟的丰碑。害人害己阿。