有人说想做一套系统，我很愿意听。不过，比起先讨论用什么框架、做多少页面，我更想知道：现在到底是哪件事不好办？
技术做久了，容易有一种习惯，听见问题，手就想往键盘上放。能快点做出东西当然好，但如果问题听偏了，做得越快，回头改的时候越热闹。
我一般先问谁在用。老板想看经营情况，店员想少录一遍数据，老师想及时知道学生哪里不会，他们说的可能都是“需要一个平台”，实际需要却很不一样。先确定一个具体使用者，讨论才容易落下来。
接着问现在怎么做。表格、纸张、群消息，甚至某个人记在脑子里的办法，都值得看一看。它们可能不方便，却往往藏着不少实际规则。谁来确认，什么时候交接，漏了一项怎样补，都要先弄明白。新系统不能只把旧流程搬到屏幕上，也不能把旧流程里有用的部分一起丢了。
找到最值得先解决的那一处
第三个问题，是现在最费时间、最容易出错的地方在哪里。
假设一家小店每天要处理预约报名。有人在群里发姓名和联系方式，有人填写纸质表单，最后还要有人核对名额、通知变更。这个例子只是为了把问题说具体，不是现有客户案例。先别急着做完整报名平台，提醒给谁，缺一项资料怎样补，名额满了谁确认，临时取消怎样留记录，这些更值得先聊。
也有可能，聊完发现一张报名表和一条固定的确认消息就能解决眼前的问题。这样的结果我觉得不算白聊。少做一个用不上的系统，双方都省事。需要代码时再写，代码也不会介意。
第四个问题，是有哪些条件绕不过去。预算、已有设备、网络、人员、培训时间，都要放在方案里。一套需要专人维护的东西，如果交给一个已经忙不过来的人，就算功能合适，使用条件也没有对上。以后换系统或结束服务时，资料能不能带走，也应该提前问。
有些要求必须保留，有些可以晚一点做，还有些值得重新讨论。把这些分清楚，比在合同里写一个含糊的“功能完善”更踏实。
约好先做到哪里
最后一个问题，是第一步做到什么样，大家才觉得有用。
我愿意先选一条不大的流程，从填写报名信息到确认结果，走完整。正常时怎样，出错时怎样，需要谁确认，换个人能不能操作，都在这一小段里试清楚。只做几张漂亮页面，使用者很难判断；一下答应全部功能，双方也很难判断。
第一步跑通以后，再决定增加什么。有些需求只有用起来才会出现，有些原来很看重的功能，后来未必还需要。留一点调整的余地，不是准备少做，而是承认开始时谁都不可能全想明白。
做技术服务，我希望客户能清楚地知道自己的钱和时间花在哪里，我也知道答应的事情能不能做好。先把问题问明白，往往就是合作里很实在的一部分。
如果你正想着做一个系统，可以先写几句话：谁用、现在怎么做、哪里最麻烦、有什么限制、希望先看到什么变化。带着这几句来聊一聊，就已经是个很好的开始。
接着读：软件写完了，离真正用起来还有多远。