市场至上，还是我们应当坚持原则

还真是
以卖专利为生的公司除外


新技术，打哪来啊
提升技术，有啥用啊，小心领先三步成先烈了。。。。。。

--------------------------------------------------------
说的很对，我认为作为一个PM，吃亏是福。我觉得碰到LZ遇到的这种情况，应该做一下四件事：
一、与客户沟通，是否真的有必要变更，如果有则在变更文档中记录变更需求。
二、评估变更所引起的成本，也就是工作量。
三、上报公司，提出建议，由公司做决定。
四、决定已做，坚决执行。

是该有这种魄力！！

楼主描述的现状是国内小软件公司的一个典型生态，没有在这种氛围下做过项目的人是很难理解这种困境的，给楼主几个建议：
1、停止抱怨，立即沟通。
情绪解决不了任何问题，大家是一条船，项目开发经理的一个关键职责是沟通，让老总、销售、开发部门经理明白工作量所在、成本所在，若能做到这一点，你后面抱怨的问题就有解决的可能。
2、实现技术积累
国内小软件公司的最大软肋就是没有技术实现（不仅仅指技术）上的积累，导致的结果是项目越大越低效，楼主应该通过几个项目的时间，逐渐建立起这种技术实现上的积累和升华，比如：共性的技术组件、业务组件，这样你后续的项目会越做越高效。
3、组建合理梯队，分担压力。
楼主还在写大量的代码，这是我曾经经历过的状态，虽说这是因为国内小公司的低成本开发模式决定的，但楼主应该慢慢学会考虑做个“懒人”，组建一个合理的技术梯队，即使小到3人行的小组，也应该考虑技术梯队的问题，逐渐摆脱底层的细节编码，把这些精力腾出来做更合适的事情，如沟通、协调、积累。
4、需求变更要综合考量
天下没有免费的午餐，销售、老总拿客户当爷伺候是有所期待的，这里不存在迁就谁的问题，对于需求的变更要综合考虑，客户的潜在价值、变更的成本、客户强弱势状态，这本质上还是沟通、协调的问题，一旦决定了就是一个合理的工作量，必须完成的，楼主要尝试站在销售、老总的角度换位思考，当然对于小公司，此类变更控制可能人为的随意性比较大，楼主应该积极参与或主导这个流程的制度化管理。

痛并快乐着，这是楼主的现状，只要对这个公司还有信心，就去勇敢面对吧，这也是人生的财富。

对于专门定制客户化软件的小公司来说，市场就是第一，没有钱公司无法运营，这就是公司的原则和立场。
对于PM个人来说，谁都不愿意看到一个需求改了又改，结果可能是无休止的编码-测试-上线，导致最后项目很难控制，以至于失败，最终还是公司利益受损。

所以我觉得对于客户变更要有一个度，不是什么需求变更都可以做的。

在这种公司做PM和客户打交道是会遇到这种问题，关键在于和客户的沟通了。也许做产品是条好出路，呵呵

我也经历过这种事情，但是依然未找到很好的解决办法。
如上面某位网友说的，既然已经打算离开，那不妨和老板、销售人员、客户讲清楚，需求变更是要付出很大代价的，
并且可以推荐老板销售人员看一本书《人月神话》，
让他们明白随便变更需求会对项目造成的伤害，
你应该发挥让你的智慧，让老板和销售人员明白做项目研发的难处，让他们明白你们的困难。

我理解，维护即使有钱也不能到楼主的口袋里，但是问题是这些工作都要维护的人完成，累呀，做过电信项目的人就明白了。无法控制的需求，一个接一个，加班加班。。。，至于技术，当然退到旁边了，客户高兴就行。

开发人员只管写代码 ,实现功能，其它的和你有嘛关系啊 ！改就改 ，需求一天变上万次，也改 ！反正你拿工资，做完就走人  ！不过在责任上 得明确，你要让老板知道 ：不是你没写出来导致项目延迟，而是需求人员的需求，每天给你的都在变。不要给需求人员有机会把全部责任推卸给你 。这种推卸责任的鸟蛋很多 。简单的办法就是每次需求更改都要求他们给你发正式的邮件。
作为好员工 ，偶尔向老板发牢骚，唠叨一下问题，发表下意见也无所谓 。

说得好，顶！
没有这个能力来趟混水，被淹死也正常啊！

呵呵，越来越赞同zqrain的观点了。
一个团队中能力有高有低，每个成年人都有自己的想法，能力高的人是特殊的个体，本来就是异于团队的，这更需要多沟通去推行自己的独特观点！