同样一个小程序定制项目，有的客户返工三四轮，有的一次过，差别往往不在服务商的水平，而在需求是怎么表达的。把话说明白，听起来简单，做起来最能省钱，沟通质量直接决定返工次数，这话说出来没人反对，做起来却是另一回事。
别用形容词描述功能
我要一个好看一点的首页，用户系统做得灵活一些，这类话开发听了等于没听。好看的标准是什么？参考哪个产品？灵活指什么？形容词是主观的，参数是客观的，开发要的是参数。有效的表达长这样：首页参考某品牌的排版，顶部轮播图三张，下面四宫格入口，具体图标我提供。一句话把页面结构、数量、素材来源都定了，设计师不用猜，返工自然少。同样的需求，说清楚和说不清楚，报价能差出三成。找不到参考案例的，就在纸上画个草图拍个照发过去，也比口头描述强。
一张需求清单应该长什么样
不需要专业文档功底，一份文档就够了，但要有几块核心内容：
- 目标用户和使用场景，给谁用、在什么情况下打开
- 核心功能列表，按优先级排，必须有的和可以后加的分开
- 参考案例两三个，指出喜欢哪里、不喜欢哪里
- 后台管理需求，谁来维护、要改哪些内容
- 内容素材谁提供、什么格式，提前写清楚
优先级这个动作很关键，上线时间紧张时，砍掉的是低优先级项，而不是临时拍脑袋。清单写完自己先读一遍，能不能照着做出来，读不出来的地方就是模糊的地方。有这份清单，服务商的评估和报价都会准很多，漏项导致的加价自然就少了，写文档花的是你两小时，省的是双方几十个工时。
需求变更要留痕
开发中途说顺便加个小功能，是工期失控的头号原因。不是不能改，而是每次改动双方确认一下影响的时间和费用，微信里说清楚也算留痕，变更不是洪水猛兽，没有管理的变更才是。比格网络的项目群里，所有需求变更都要求文字确认再动手，一开始有客户觉得麻烦，后来都感谢这个规矩。再配一个每周固定十分钟的需求同步，别等问题攒大了再谈。定制项目的顺利，一半靠技术，一半靠沟通的习惯，沟通习惯好的客户，服务商也更愿意投入，这是双向的，写文档的过程也是理清自己思路的过程，一举两得。道理讲了这么多，落地就一句话，把你要什么用大白话写下来，再加几个参考案例，这份土办法的需求文档，比任何客套寒暄都更能推动小程序定制项目往前走，试试就知道。
