Onsite和Offshore的开发过程的讨论

军队硬性的将人分为军官和士兵,确实有问题,呵呵,玩笑之言

如果要用军队来类别
那么楼主和他手下的低端组大概可以算军官和士兵，
至于高端组就只能算高级参谋了……

打仗部署错了没机会改，软件开发不是。打仗输了就会死人，软件开发不是。

一个可以发奖金的月份变成没有奖金的月份,一个可以挣钱的项目变成不能挣钱的项目,一个可以盈利的公司变成不能盈利公司.
有多少机会可以让我们浪费

呵呵,又想起robbin讨论的跑题的帖子来了.

这样分组没有什么大问题，初级开发人员一般都是刚毕业工作不久的吧，他们应该很清楚自己的地位和境况，而公司这种做法纯属资源优化手段，谈不上把人分成高低贵贱，故不应该存在打击士气之说。

在实施的过程中，
第一，要给初级组的优秀人员晋升到高级组的机会，保持其中的希望和活力；
第二，高级组在项目设计完成后，不能全部转移到其它项目，应该保留部分人员放到初级组里担当开发组长一类的角色，既可以为初级组的人员解惑，又能在一定程度上对项目进度的监控。

这里做外包的人可能不多，对外包作业好像不了解。
在日本，欧美业务外包这样风行，总不至于怀疑他们做出来的软件都是质量很差的吧？外包就是分工协作，只要各个环节处理得好，一样能保证质量。



如果你的工作态度是这样的话，不管在外包公司还是其他什么公司，都不会有什么成果的，我认为。

我以为评价一个架构的设计的好坏很难以该架构采用的某些技术相对保守还是激进作为标准吧？一个项目需要考虑的除了技术层面的先进度（或者说热度）外应该还有很多考虑吧？这些考虑 partech 都考虑了吗？

而且作为设计者每个新技术都去尝试的话当然是得不偿失的一种做法，最好的方案当然是提出构想由手下的兄弟去实现，然后汇总到设计者这里，最后进行分析决策了。这种随手可得的事情我就不举例子了。

人无高低贵贱，本身都是做工作，只不过由于技能、经验甚至于资质的不同才有了不同的分工（尤其在软件这个行业里做技术，没有那么多猫腻）。只要真真正正做好自己范畴的工作，都是值得尊重的。至于一个设计者是不是参与实现 恰恰 和这种评价没有关系 ，因此使用“好高骛远，害人害己”这种措辞非常的不合适，同时也非常的不公正。

做构架的人自己都不了解具体技术，他凭什么来决策？就凭几本技术白皮书麽？或者一些英文电子书？
只有在自己熟悉的领域，才有可能在各种可选方案中，做出评估。这种工作通常是极具挑战性的，一般人员根本吃不消。即使你让手下的兄弟这样做了，你放心
他的结论吗？构架设计和方案需要有经验和实力的人员来做。

我曾经见过你说的这种开发模式，本来两三个月的小项目，硬是做了9个月还说只完成了75%，最后开发出来的东西完全没用，因为使用一个已有的构件就完成了同样的任务，公司白白浪费了二三十万。。。。。

兄弟，作架构当然是从白皮书入手的，而且也绝少上来就关注细节的，这种事情恕在下实在懒得举例了。至于你说的挑战性的工作，如果我没有理解错的话，应该是为了项目选型而提供的试验,HEHE。至于您是不是放心您的手下，就要看您自己指导他人的水平了，当然如果愿意什么事情都自己去做也没有什么不好。

贵公司损失二三十万的那件事情，如果阁下对PM稍有了解的话，也应该知道这种问题产生的领域和软件的开发模式是无关的，在PM中有专门的关于自制和外购的评判的流程，有相关的工具、输入、输出，感兴趣可以下载PMBOK的电子书看看，呵呵又是 英文电子书 ，不愿意看也是您的自由。

顺便说一下：感谢T1兄弟给了我许多学习的动力。

兄弟，作构架绝对需要宏观微观都要关注，有时候往往一个细节就决定了整个方案是用还是不用，这种事情在下也懒得举例子了，假如你做构架时，只从宏观考虑，而不在微观上考察，那么你永远不可能产生对构架必定可靠的真正信心，你不但需要知道可以这样做，而且还需要知道它到底是怎么做的。

另外，我实在不太明白在自己都不懂的技术上，如何指导他人？还望告知。

赫赫，马后炮都会放，但在项目初期，谁也不知道这个技术是否有现成的可用。
另外PM并不是技术专家，他是没法评估的，再考虑一下，对构架师的尊重，通常是不会直接干预技术和实现的选择的。
所以基于这点，我认为软件开发要成功就在于选对人，其余的都是扯淡。