不支持，没办法

    场景A：
         系统已经上线，并且运行一年左右。随着业务的发展，用户的需求是不断变化的；而且数据量，并发量也随之增大。
         客户：“请帮我们实现某某功能，可以吗？”
         开发商：“对不起，目前不支持”
         客户：“请帮忙把某某功能修改（调整）一下，可以吗？”
         开发商：“不支持”
     客户往往得到的答案是让他非常沮丧，非常无赖的。只能让他们将就着使用系统，每天都在抱怨，见着开发商就笑了；甚至在背后痛骂开发商。
     开发商可能处于成本的考虑，一个小的调整，需要重新设计，增加不少的开发工作，所以赤裸裸的告诉顾客－－不支持。商人都会从商业利益的角度考虑。当然此供应商是鼠目寸光的，他们的这种服务态度，商业手段，迟早是会把自己憋死的。
     设计开发人员是否能够站在更高的层次上面分析和设计系统，使得系统的稳定性、可用性、可扩展性、性能能够达到最优呢？当然需要更多的技术经验和行业背景。我们尽可能的做的更好，让顾客满意，充分发挥我们的价值。

    场景B：
         我们在开发过程中，肯定会遇到这样或那样的问题，都会要想尽一切办法去解决。
         TM Leader：“这个问题有什么办法解决？”
         开发人员：“这个我没有办法了”
         TM Leader：“除了这个办法，还有其它方法吗？”
         开发人员：“肯定没有其它方法了”
     TM Leader肯定不愿意听到这样的回答，大家也不希望的；实在是让人头痛的。团队领导应该经常的和团队成员进行沟通交流，及时的跟进项目进度。有问题，大家一起想办法解决，尽快的扫清前进的障碍，推进整个项目，使得项目顺利进行。团队领导要起到一个教练员、指导员的角色。当然，在项目核心问题上，也能够卷起袖子，卷起裤脚，下地干活。
    开发人员应该通过平时的自学，网上学习等等，迅速的提高自己分析问题解决问题的能力，而不是一遇到问题就给自己下了一个定义，这个问题我肯定没办法解决了，这个方法是唯一的解决方案。应该树立信心，查找相关的资料，肯定有其它的办法，只是我没有想到，这样我们才能够积极主动的解决问题，用一种上进的心态去解决问题。这样才能让自己更充满活力，而不是郁郁寡欢；解决问题也是一种乐趣。

不能说你说的没理，但是至少偏颇了。
A场景的现象是很多时候增加修改功能要增加开发成本。而用户不愿意支付这些成本。非要开发者自己消化。B场景同样有这种问题。要员工干得更多，但是又不愿意付出成本。
如果处于开发者或者员工的位置。无论如何也无法说服对方就新的工作量支付对应的成本，很多时候又不能得罪对方，不得不自己扛。那么说不行就很可能出现了。毕竟不能干比不肯干得罪对方的程度要小。

可能场景描叙不是很详细，补充：
场景A：
    该系统还处于开发商的维护期，也就是在保质期中，那么功能的维护是应该负责的。新的需求，公司也是支付了大把大把的银子。

场景B：
   开发人员是没有太大工作量的，没有让他加班。

场景A，场景B是不同的项目的。

说到得罪，开发商肯定惹怒了用户。用户已经卷起袖子自己干了。搜索到确凿的证据，开发商就自己消化吧。
场景B的开发人员的待遇不低。
处于工作两三年，还年轻，还是可塑的，毕竟都是打工，能够让他有长进，能够让他多学，多教教他。团队成员之间能够共同分享，那么大家干起活来愉快些。

只有把少先干好了，再向别人讨价还价了。

例如：第一次项目你要做什么，我们尽量把完成，如果真的需要加成本，就尽管提好了。
这一次项目完成了，下次项目遇到此类情况，就根据自己的难度需要让对方加成本啦。

本来就是这样子的，人干活就要动力的么，有了动力一切都好办，是不是。

一句话，和气生财。。。

那就是说明不够细化咯？

A.客户可以提出多个new feature，排优先级，让开发商评估时间和工作量，既然说了在合同内可以不新增费用，就可以增加新功能，可以直接和开发商的销售协商，和开发人员说这些也是浪费时间。他又拍不了板。

B.看你们的项目是怎么推进的了，每周的工作量是如何制定的，如何评估一个人手头到底是有没有工作，有没有高级工程师可以评估这个issue点的难度和风险。如果手下只有一个开发人员，软的可以攀交情，硬的可以威逼利诱。看上头人的手腕了。

是人都懒
做事都要担责任.

钱没给到位.
给的钱翻10倍 效果肯定不一样

现在很多拿了钱不想干活；诚信度差；服务态度也差。
当然也见过，活帮你做好了，一直不提收款的事。

有些毛病是灌出来的；有些怕麻烦。
职业道德，责任感

职业道德?
责任感?

公司里谁不知道维护是个受气包?
销售工资> 开发 > 测试　＞　部署

这个环境道德能存活下去么．