草稿的数量并不会让客户(老板)对你的勤勉印象深刻，反而会觉得分摊到每稿的成本很低。把多个草稿交给客户定夺也是你不够专业的表现，如果需求明确，适合的永远only one，而你在这个时刻应该运用专业能力选择判断。你把这事交给了你的客户去干，其结果是客户质疑你的判断和理解需求的能力，从而无形中剥夺掉了你对设计的控制权。剩下的事，你也能想得到了。

　　我见过做logo，给客户提供了3稿，结果客户一下子有主意了，一会加个彩虹，一会做个太阳，后反反复复做了7、8稿，客户还没满意，活活挑花了眼。

　　而多个配色版本这事，也和上面同理。一个配色是一个需求 ，不要因为改起来很简单随便答应。如果走严格的外包流程，多一个配色是多一份需求，多一份需求要追加一份费用的。而且做一点微小改动后复制一个版本的要求，容易出现的后续状况是两个版本会在一段时间内并存，而且两个版本需要同时开发、变更、改bug。这样下来维护成本不是乘2而是乘4。这是程序开发上经常会遇到的大坑之一，技术型项目经理一定要注意。

　　做多个方案这种事更离谱了。只有在出现不同条件和项目背景的状况下才可能要求做多个方案。一般会遇到的是分别做低预算、中预算和全预算的方案，或者做3个月能完成项目、半年能完成、全年能完成的方案。

 　　如果你是雇员，一定要强烈提醒你的老板，不同的条件配置不能混用。

　　如果你是外包方，还是要记住，需求对应费用，不要以为这是是删删改改的数字游戏。

　　状况4：反复改稿;反复纠缠于细节

　　状况：产品端人员经常会遇到客户要求反复改稿，并且十分纠结于细节。

　　比如一个首页改了4、5稿，做了两礼拜还没做好。打翻重做都有2、3回了。 产品A是放在产品B的前面还是后面，产品C是挡住产品B的1/3还是1/2。客户提供的文案或者翻译不停在修动，删行字，明天加行字，每次都得改完文件，导出，请对方审核。明明是对方的失误，耽误的确是你的时间，后你还得为整体项目进度延误付出代价。

　　应对：这种状况首先得由项目经理做好预防。文章开头说过了，调配职责，是调配 时间、资源、需求之间的关系。(资源代表钱和人力)这三者之间是互相钳制的。需求膨胀，需要更多的资源或时间;想要缩短时间，得压缩需求或者补充资源;想控制成本，得压缩需求或同意更长的项目周期。(注意：根据人月定律，人工/单位时间 和 钱是不能换算的。延长开发人员的工作时间也只能让情况更加恶化，项目经理一定要慎重在这两者之间的调配。)

　　1。项目经理再和客户签订预算的时候，应该尊崇这种换算原则下的 付酬及核算方法。(以后我会专门写blog讨论如何制订预算)以单位人工*时间来计费。这样由于客户原因导致的单位人工工作时间增加，可以得到费用上的合理补偿

　　2。开发协议附件要附上项目时间线，里面明确标清几个阶段的时间里程碑。比如需求完成的里程碑、界面完成的、前端切图的、系统架构的、基础开发的、整合的、内部测试的、bug调试的。如果某个里程碑未按时完成，是由于甲方问题导致的，需要标清责任，并在当时向客户声明可能造成整体项目延误的风险，如果非常严重的甚至可以要求甲方赔偿(因为乙方外包公司的时间一样很值钱。)

　　3。开发协议上要声明甲方对设计稿提出修改意见的轮数，一般是2轮。2轮修改已经意味着多3稿，什么样的问题基本都能在3稿中改定，什么样的分歧也都能在3稿内统一。超过这个改稿数需要追加费用。这样可以促使甲方全面集中地一批提出修改意见，而不是想到哪说到哪。(我曾经遇到一个客户，一晚上给我发了20封邮件，每封邮件里提1~2条建议，邮件前后还有反复以及 “以此邮件为准之类”的话。MD，后来发展到只要他想起来什么地方要修改给我打个电话，在第一阶段内测的时候，我曾经在一顿饭中接了他5个电话。)

　　4 。开发协议上要指定几个关键节点的审核确认制。比如首页和全局风格确定了，需要签字确认一次，保证这是终意见。全部UI设计完了，需要签字确认一次，保证不再修改，不然前端切图的同事没法干了。

　　协议这样写：条款*、工程审核及工程验收

　　1. 收到预付款项之后，乙方设计组完成主要页面UI demo的设计开发

　　甲方针对DEMO页面进行审议，提出修改意见。乙方进行DEMO页面的修改，甲再次审议。提出意见，乙方再次修改。甲方需集中在两轮内，全面、统一、明确地提出审议意见。由甲方所提供文案、图片、其它资料变动所带来的修改，乙方可以免费在两轮中提供支持。超出两轮改稿范围的工作，属于维护性工作。请参见《项目维护协议》。或(将不予支持)

　　2 确认UI demo达到要求，甲方需对DEMO页面签字确认修改。

　　签字确认后，进入前端切图环节。甲方如果对页面有其他变动较大的修改要求(更改页面标准色、设计风格、页面布局)，将视为二次设计，乙方可收取二次设计费用。

　　5 。对于甲方提供的文案、图片、资料所带来的麻烦，在协议中提取声明。参见上一段和下一段

　　协议这样写：条款*、甲方责任

　　1. 甲方需对网上内容提出具体要求，若在所规定的时间，甲方不能够及时确认开发设计的内容，所造成的项目进度的延误，乙方不负任何责任。

　　2. 甲方需要为乙方工作人员了解具体业务提供详细的文字、图片等资料。若在所规定的时间，甲方不能够及时提供相关资料内容，所造成的项目进度的延误，乙方不承担责任。

　　有了上述5项预防性措施，你剩下的很多事好做了。

　　客户反复改稿，反复纠缠于细节，一般不是恶意，大部分都是工作方法和缺乏大局观的问题。

　　所以在客户反复折腾，浪费时间的时候，你得告诉他们得付出什么样的代价，同时你能提供明确的依据和协议的保护

　　约束客户的审核行为。审核行为必须成批次，意见统一、明确、全面。

　　帮助客户建立正确的工作方法。简单的做法是提供一个审核意见的模版，让客户按葫芦画瓢地填写。另外一定要教会客户使用截图软件(QQ里的截图行)，这样可以省许多口舌。审核意见模版下载

　　ppt版本下载 (用于产品端，优势，可放置大面积截图)

　　excel版本下载(用于产品端及 程序、功能测试反馈。优势，条理性强，可过滤排序)

　　客户自己提供的资料变动，一次两次可以帮忙，多了是维护性工作，得和开发阶段明确分开。

　　还有一个问题，客户很多时候不知道你需要什么资料，或者资料准备不及时。在项目正式开始之前，要按需要的紧急程度，向客户提供 所需资料的清单，然后用不同颜色标清需求紧急程度，分别晚什么时候要求提供。 这一点很重要，很多资料的缺失将直接影响到你设计和客户需求的匹配。包括logo、标准色、产品图、客户要求放置的大图、客户品牌历史使用的装饰性元素、文案字数等。

 　　12 Comments »

　　项目刚刚开始的时期，项目经理做的主要事情是搜集客户需求，这是一个项目经理非常头疼的阶段，合作的磨合刚刚开始，需求问题上的失误又会导致无穷的后患。

　　三种客户类型：

　　1 的确很专业。能提供基本可用的文档，能给出要求规范，能向你提出有价值的疑问和担心。能快速回答你的问题

　　2 以为自己很专业。 给的文档基本没法用。没法提供规范和标准，喜欢指指点点和挑毛病。只会向你提傻逼问题。基本回答不了你的问题。

　　3 啥都不懂。 不给文档。能给你几个参考范例(打开数个网站，告诉你我要做成和它们一样的。)只能等着你来问100个问题。。。