在问答频道和大家聊过的关于项目开发的技术选择，觉得有些乱，于是搬来这里，重新整理下。
在软件公司，搞技术的都喜欢尝试新的技术，做管理的又都整日里盯着成本不能放松。矛盾和冲突应该会时不时就会发生。自己就曾向做管理的嚷嚷：“不尝试，永远都不会，永远都落后！”；也曾心里犹豫最终向￥妥协，反过来劝别人：“要不，这次还是先用以前的架构吧！”
通常考虑尝试新技术的应该大多都是架构师（对各种叫法不是很清晰，这里是按自己习惯的称呼。），好的架构师不可或缺的一项技能，就是：“说服别人！”
只你认为好没有用，说服大家都觉得好才成。那句话怎么说来着，“大家好才是真的好！”
成本控制，这个是技术人员看不起但心里也承认至少在发工资奖金时承认对项目乃至公司都至关重要的内容。所以你要说服做管理的，也要站在对方的角度——成本控制上来讲才行。
（说起来，想要说服任何人都得这么着才可能有效。）
比如，你想要选择iBatis时，
- 说iBatis比hibernate性能好。
性能好？完了吗？如果说到这就完了的话，技术人员可能会被说服，做成本控制的根本不会被说服。
考虑成本控制的话这么说：“这个项目对性能有要求，如果上hibernate的话，会在性能调试上花很多工数；如果上iBatis的话，可以节省很多工数！”
工数 = $，对方就被K.O.了！哈。
- 谈到更换技术有一定的风险。
这个很对的，的确有风险。
要说服他，你可以讲iBatis也有成熟社区，有大量用户等等。他认为的风险有哪些，1，2，3列出来，你一一作答就好了。
如果你是名合格的有经验的架构师，甚至应该自己先列出1，2，3来，自问自答，他再也无话了。
我以前的经验是，
- 谨慎选择技术。 比如，最新的技术不可以；生僻的技术不可以；活跃度低的不可以等等。
- 事先培训。 可以通过某些项目事先让大家掌握该技术。比如，研讨性质的，小的，时间充裕的等等。
- 挑选切换的时机。 在上面的条件满足之后，应该能够积累出一个可以用来正式开发的架构以及足够的人力资源了。然后——通常都是——在某个新的项目上应用它。
如果能做到以上这些的时候，你就不是在冒险尝新，而只是从既有架构中根据需求选择哪个。理想状态下，甚至都没有必要还要去说服谁了。
最后，就是队员培训，短期看有投入无产出，长期看在面临各种复杂需求时能够灵活应对，能节省更多的工数。当然，这些都是基于正经做公司的情况。
注：iBatis现在叫MyBatis。但我觉得iBatis要更酷些。