Onsite和Offshore的开发过程的讨论

公司打算在国内项目上，参照外包的方式Onsite 与Off shore的方式进行，开发。一个项目项目分为一个高端组，一个低端组。高端组负责需求分析和总体设计；低端组负责详细设计与开发。二个组的接口是总体设计。低端组看不到需求分析。希望和大家讨论一下，这样子行得通么？
那么，我担心的是：总体实际是否能够做到这么好以至于可以使这种方式顺利进行下去？这样，总体设计的评审就十分的重要了，怎样做这种评审标准好呢？

在公司内把人分高低等，会打击士气的。

我现在的公司是做外包的。

如果不是不可抗拒的外力，严重不推荐你们这样。

我们这里，程序员没有一个愿意为了项目多出力，只是想完成工作就回家。为什吗?自卑，别人看不起你，你还想干吗？

拿到模块，心里想的就是完成功能，至于质量，规范，以至于体系结构，根本不会花时间去想。如果自己感觉不到自己是项目的主人，成就感在哪里？动力在哪里？就剩下钱了。

他们也不会去主动了解、研究你的设计，你的思想。你就算真能设计的好，他们也未必真的能在编码上，最终实现你的想法。

成就感和平等的感觉对程序员来说太重要了。
你不给他机会，他怎么成为所谓的精英

这样分，如果高端组的设计行不通，怎么办？低端组如果对设计有异议又如何处理？
同时由于不是一个人同时负责需求，分析设计，实现整个过程，必然会导致信息丢失，从而产生浪费。

是啊， 严重影响。本来还以为做国内项目为荣。现在，公司彻头彻尾的向工厂进军了。心凉哦。。。

高低端组的设置，目的在于：高端组，集中了公司的骨干，精英；低端组，除了PL之外，对其他人的要求很低，但是人员数量较大，人员随时可替换，变更。
偶本人十分反感这种分法，可是一时又不能拒绝领导的安排与尝试。
您提到的这个问题是很关键的，一方面，领导说意思是，高端组的人员能力应该具备做出最优设计；另一方面，领导让我（低端组负责人）制作以分足够全面的评审checkList，随项目慢慢补充，完善成为规范，对总体设计进行严格的评审。而对于低段组程序员，可以参与总体设计评审。出现争议后，双方协商解决。但是原则上，低端组成员应该遵照与尊重高端组的设计。

阁下的眼下之意难道是应该一个人去负责同时负责需求，分析设计，实现过程？

是的，这样几乎没有浪费。
并且划分任务时，任务之间尽量是最少的交互。
否则，会在相互交互间浪费大量的时间，同时也避免不了误解的发生。

当然最好让一个经验丰富的人负责总体的设计，构建切实可行的框架，其他人就可以依葫芦画瓢了。实际上通过用例和Aspect的关注点分离的方式，可以使得
构架的实现同功能的实现分离开来。

其实，只要每个低端组的哥们能够看到点阳光，比如干了一段时间有机会跑到高端组去，还是可行的。

这种模式最近很多公司都在提及，主要的问题是缺乏有经验的开发人员，项目很多的时候，显得人力很紧张，人力资源部门能招聘到的只有大量初级开发人员，公司高层也就很自然的想集中高级开发人员，不想分散使用。这种想法我觉得很正常，一个公司领导应该考虑如何有效的利用手上的资源，否则项目完成不了，大家吃什么。

项目型公司的问题不是出在技术人员身上，主要在于业务的理解和项目的把握，这些都无法通过技术人员的分级使用来解决，而且高级技术人员设计的架构能否适应实际项目的特点，这些都要高级开发人员具体的实现一个实例，通过反复比较平衡后才能逐步形成一个技术方案。

如何组建项目团队，以及各阶段要做什么，这些我觉得有必要进行交流，现实情况下这种问题是很常见的，每个公司只要规模一大就要面对。

如果公司决定采用这种模式，我的意见是需要通过一个小的项目来尝试或者能在有成功实践的顾问指导下逐步采用，不宜在没有任何经验的情况下贸然进行开发过程的变更，一个公司的开发过程应该逐步改进和调整。本来是为了适应公司目前的人力资源现状，结果反倒给自己定了一个僵化的模型，这样就得不偿失了。