大家都是做程序员出身的，都明白现在学术派虽然不是主导，但程序员还是有一些臭老九的习气在。

我一般碰到类似你这样的问题时，有几种办法：
1，如果他的思路的风险较大，大到一旦出了问题将很难补救，这种情况下，我一般采用相对强硬的方式，比如问他，“你提到的这种方式，你有没有做过性能测试、压力测试等”、“你有没有考虑客户一旦修改他们的需求会怎
样怎样”等，用一些他们无法解决的问题、包括技术上和需求上的问题来压制。根据我的经验，很多程序员在考虑一些技术问题的时候，实际上都属于理论想法，没有做过更多的测试，哪怕真的做过类似的程序，你的技术如果过
硬的话，也能从中找出区别来。当然，压制他的观点的同时，你还要给你的思路找到一些好的说明。

2，如果按照他的思路做，虽然不好但风险不是太大的时候，基于培养人（当然是针对可培养的人）的角度出发，我一般会让他试试。有时候是把核心模块抽出来，让他简单的实现一下，有时候是直接让他在项目中做。这样他自
己很快就能够发现问题的所在。当然，在这种情况下，一般我都会做好二手准备，既实现考虑好当他出现问题的时候，该如何补救。

实际上，在我以前做项目的过程中，我在组内一般都是采用第2种方式，这样能让他们学到更多，但如果我和其他项目经理交流关于我的项目的时候，我一般都是采用第1种方式，因为他们的技术能力和经验的确很菜，欺负欺负
他们也活该，呵呵。

当然，无论用哪种办法，首先你要确定你的思路，如果你不能确定你的思路的确比程序员的想法好，那我劝你，把你所担心的问题说出来，然后就闭嘴，听大家的意见。举个例子，在我今年的项目当中，有个客户临时提出一个项
目，是对Excel文件的进行无损转换的，一个小项目，但要的很急，我按照我的对这个项目的预感和以前在这方面的经验提出了一个设计模式，说句实话，编码难度的确挺大，然后交给另外几个程序员去做，我就不管了，他
们基于他们对需求的理解，认为我的思路他复杂，就提出了另一种方案，我一看的确简单的多，但有可能在需求上出现一些问题，但说句实话，我以前没有用这种思路做过，所以我不能肯定他是错的，这个时候，我就只有说出我
所担心的事，然后就放手让他做。事后证明，他的思路的确是错的，但我并不后悔当初让他这么做。

我想楼主现在恐怕和项目经理间也不是很协调吧？