小修小改当然是你来定义啊，难道客户跟你说，这个问题嘛，简单，你就说没问题？一般来说不涉及流程修改或者修改的影响范围比较小的，都可以定义为小修改，涉及流程变更，或者调整影响的内容比较多，就不能算小修小改了。

一般情况下客户定义的小修改是：你原来帮我批发公司做的进销存，现在我要开门店了，麻烦你稍微改一下，支持门店POS收银。

或者，公司现在人多了，又不希望让大家用QQ，要不你在软件里面加个聊天功能吧。

你要说这个功能安装QQ呢或者其他聊天软件，他会告诉你，希望在聊天的时候，可以一点就打开一张软件中的销售单查看。

开发员定义的小修改是：任何控件的标题文字错误或是表达不清楚，由客户提供正确的表达，开发员修改。

这种小修小改口头说说尚可，放到合同中是万万不能的。什么叫小修小改，这样说本身就是一个模糊的概念，最近肯定双方互相扯皮。合同一定要规范化，对每一项修改进行明确的描述、规范。超出规范之外的自然就是额外的收费范畴了。

另外，不论你做什么项目，按规范来说，在进行开发之前，都应该有相应的需求文档或开发规格说明书一类的，用以规范双方的工作需求及工作量，后期的维护是基于之前的开发功能点来维护的。这样就能清楚规范了。

半小时能解决的就是小修小改，否则就是大修大改

小心被坑到吐血…

.NET 里有种修改叫做：只改View不需要编译的升级

找到最终决策人

这个简单，合同添加条款，如果大的修改～ 需要重新评估工时，然后增加费用，甲乙双方共同协商～如果没有规定，就被套牢了～

爱编程的大叔

说的很好，本来是个进销存，后来又要支持POS机这种，绝对是大修大改。

至于说辞上就像满损谦益说的。

所谓维护，即围绕之前的功能点来说，新添加的功能，哪怕是一点点小功能，

实际是可以送客户的，但嘴上一定不能免费送，要让客户了解到这个原本是要收费的。。。。

哥们 ，什么小修小改  这是不靠谱的。既然维护 就要收全部维护的款  ，做全面维护的活。

根据项目,修改小不小:个人认为有两个方面,第一:界面修改. 第二:业务逻辑更改

比如:一个视图的整体布局都变了,但是业务逻辑没变,肯定定也算打的变更了.

不过不太懂技术的客户,大多比较注意界面展示的问题.