与软件开发者的第一次沟通，最有效的方式是带着真实的问题去，而不是一份打磨好的说辞。善于提问的供应商，能把一句粗略但诚实的、关于目前痛点的描述，变成准确的范围和公平的报价；而只能靠猜测想象中的功能清单的供应商，报价往往两种方向都会出错——报低了，缺口之后会以变更请求的形式出现；报高了，是为了覆盖不确定性而加的余量。
这是一份实用的委托前准备清单：该带什么、该让谁参与，以及开发者到底需要你提供什么，才能在第一次沟通——而不是第三次——就准确地评估范围和报价。本文假设你已经决定值得探索定制系统；如果你还在决定是否要建造，请先参阅你的企业已经超出表格能力的迹象。准备好委托之后，定制系统实际需要多长时间和该由谁来建造涵盖了这之后会遇到的问题。
为什么"我们想要一个应用"或"我们想要一个系统"不足以获得准确的报价
开发者无法为自己无法想象的东西定价。"我们想要一个管理订单的系统"描述的是一类软件，不是一个项目——它没有说明有多少订单、谁来输入、取消一笔订单会怎样，也没说结果是否需要与你现有的会计软件对接。两家企业说出同样一句话，可能需要截然不同的建造方式和价格。
解决办法不是在见面前学会技术词汇，而是带着足够细节的真实问题去，细到一个陌生人也能听懂的程度——本指南剩下的部分正是为此而列的清单。
从痛点开始，而不是功能清单
在考虑新系统应该做什么之前，先指出今天到底哪里出了问题。不是"我们需要更好的库存管理"，而是"我们每周一都要把同一份库存数字重新输入三张表格，到周三通常就已经出错了。"第二种说法准确地告诉开发者该修什么、大致要修多大；第一种几乎可以指任何事情。
- 说清楚一项具体任务，而不是一个部门。"销售部需要一个系统"太宽泛。"销售代表用短信把订单发给办公室，再手动录入 Excel"才是一份简介。
- 说明发生的频率和耗时。一个每周一次、耗时十分钟的问题，和一个每天耗时两小时的问题，是完全不同的项目。
- 说明出错时会发生什么。漏掉的订单、重复付款、从没被告知缺货的顾客——目前出错的代价，往往才是这个项目真正的商业理由。
谁会真正使用它，每个人每天具体做什么
系统的范围应该围绕每天要接触它的人来定，而不是委托建造的老板。见面之前，先理清：
- 按角色划分，而不是按姓名。柜台员工、仓库员工、单一的行政人员、每周查看一次报表的老板——每个角色通常需要同一系统的不同视图。
- 每个角色大致有多少人。只有两个人使用的工具，能容忍的摩擦比二十人使用的工具更多。
- 每个角色现在用现有工具一步步具体做什么。不是你希望他们怎么做——而是他们实际怎么做，包括那些没人愿意公开承认的变通办法。
- 谁来判断哪里出了问题。最先发现错误的人，往往不是能解决问题的人，好的系统设计会把这个落差考虑进去。
这很重要，因为按老板想象中的业务运作方式建造的系统，往往会被每天实际使用它的员工悄悄抵制。如果条件允许，带一位每天真正要使用这个系统的人一起参加第一次沟通，或者至少提前转述他们的回答；老板和日常使用者对同一个流程的描述常常不一样，开发者在动笔之前听到这两个版本会更有帮助。
把今天实际运作的流程原样画出来，不是它应该怎么运作
按顺序，从头到尾走一遍目前的流程，包括那些说出来有点尴尬的部分。开发者需要的是真实版本，包括变通办法，因为那个变通办法往往正是新系统需要取代或吸收的东西。
- 从头到尾，按顺序。最先发生的是什么，最后发生的是什么？
- 每一次交接。工作从一个人、一个工具或一张表格转移到另一个的每个节点，都是可能遗漏信息或重复输入出错的地方。
- 每一个变通办法。一张便利贴、一个共享的 WhatsApp 群组、一份别人都不知道存在的表格——这些往往是支撑流程运转的关键，忽略它们的新系统常常在上线那天悄悄出问题。
- 现在"完成"或"正确"具体指什么。如果没人能说清楚你是怎么知道一笔订单今天处理对了的，这本身就是一个有用的信息。
把这些在见面前真正写成一份编号清单会很有帮助，哪怕写得粗略。开发者按顺序读十句朴实的话，比读一段打磨过的文字能学到更多。
它必须对接什么：现有的工具、系统和数据
很少有定制系统是完全独立存在的。列出新系统需要读取、写入，或者至少要能共存的一切：
- 会计或开票软件——新系统需要创建或读取发票，还是只需要帮人更快地把数据输入会计工具？
- 已经在用的收银、电商或预约平台。
- 目前充当某项信息"正式记录"的表格，即使只是非正式的。
- 企业日常使用的沟通工具，例如订单或审批目前是在 WhatsApp Business 上进行的。
- 涉及的账号和登录信息，以及目前由谁掌控。
你不需要知道某项连接技术上是否可行——那是开发者该回答的问题。但你需要知道这项连接是必须的，因为一份没有把它算进去的报价，等到项目中途发现这个缺口时就必须重新修改。
带真实案例，而不只是口头描述
一份真实的文件，比对它的仔细描述更有价值。只要可能，就带上实物，而不是凭记忆解释。
| 该带什么 | 为什么重要 |
|---|---|
| 一张真实的订单、发票或预订记录（如有需要可隐去姓名） | 展示描述往往会抹平的真实字段、特殊情况和例外 |
| 当前数据的表格导出 | 展示真实的数据量，以及数据现在实际的结构，而不是设计时想要的结构 |
| 当前工具使用时的截图或简短录屏 | 展示开发者实际要取代或对接的是什么 |
| 涉及的每个账号、登录信息或平台的清单 | 避免后期才发现新系统需要访问某个东西而措手不及 |
| 一个目前出错的真实例子 | 把一个抽象的抱怨变成一项具体要修复的需求 |
如果文件中包含真实的客户或财务信息，分享前先隐去姓名和数字；结构和字段远比具体数值重要。
大致的预算范围和目标日期
说一个范围，而不是精确数字，而且要主动提前说，不要等着被问。知道你考虑的是几千元的开发者，和听到几万元的开发者，会提出不同的起点建议，第一次通话就发现这个差距，能为双方省下一次白费的方案。Gotka 自己的应用与系统开发服务列出的参考起价是：Web 应用与仪表盘 RM8,000，业务系统与集成 RM12,000，手机应用 RM15,000，每一项都在了解范围后以书面报价确认——即使你还没选定开发者，这也能帮你大致判断规模。
目标日期同样重要，原因相同。"三个月后进入旺季之前"和"随时准备好都行"是范围完全不同的两个项目，开发者需要知道你指的是哪一种，才能提出现实的建议。不要为了测试对方反应而故意把预算说低；诚实说出预算能帮开发者提出与之匹配的方案规模，而刻意压低的数字通常只会让双方在真实范围明朗后，重新修改一次方案。
好的开发者应该问你什么，你又该反问他们什么
第一次沟通是双向的。如果开发者没有问起你目前的流程、使用者或预算范围，那他们要么非常有经验、能从字里行间读出信息，要么就是问得不够；无论哪种情况，你都可以主动用本指南的内容引导这场对话，而不必等对方来问。
听完你的问题后，值得反问的问题：
- "你需要我提供什么，才能给出准确的报价？"——用来判断对方是在仔细评估范围，还是在猜测。
- "从我刚才说的情况来看，最有风险或最不确定的部分是什么？"——能在问题变成变更请求之前先暴露出来。
- "这个项目会按什么定价模式报价？"——参阅固定价格还是按小时计费，了解每种答案对你的风险意味着什么。
拿到书面报价之后，如何并排比较两份定制软件报价介绍了签字前该检查什么；如果由谁来建造仍是个未解决的问题，自由职业者、内部开发者还是开发公司也有涉及。
常见错误
- 一开口就列功能清单，而不是先说问题。你想象中需要的功能清单，往往遗漏了真正要修的东西，还加上了没人要求的功能。
- 描述"理想中"的流程，而不是真实的流程。你不好意思说出口的变通办法，往往才是现场最有用的细节。
- 遗漏每天真正使用它的人。按老板的视角评估范围的系统，常常被每天接触它的员工悄悄拒绝。
- 忘了新系统必须对接的某个工具，结果到项目中途才发现。
- 隐藏预算范围，想"先看看对方怎么说"。这只会浪费一轮报价，而不是保护你自己。
- 到场时没有真实案例——只有描述。一张样本订单或表格导出，两分钟说明的信息，比十分钟口头解释还多。
- 为了不说"我还不知道"而假装有答案。
Gotka Technologies 在其中的角色
Gotka 的应用与系统开发服务涵盖手机应用、Web 应用和业务系统，参考起价为 Web 应用与仪表盘 RM8,000，业务系统与集成 RM12,000，手机应用 RM15,000——每一项都在了解你的流程、使用者和需要对接的内容后，以书面报价确认。带着本指南涵盖的内容（真实的痛点、会使用它的人、需要对接的内容，以及大致的预算和日期）走进第一次沟通，正是把第一次见面变成准确报价、而不是靠猜的关键。
本指南中的关键术语
- 范围：书面描述系统究竟要做什么，报价就是按这份描述定价的。
- 探索阶段：一个较早的阶段，有时需要付费，开发者在报价或动工前详细研究你的流程。
- 正式记录：目前保存着信息"真实"版本的表格、工具或文件，即使只是非正式的。
- 对接（集成）：让新系统能够读取或写入现有工具（例如会计软件）的连接。
- 变更请求：在范围确定之后提出的功能或改动，通常单独定价和排期。
- 变通办法：例如共享表格或便利贴这类非正式的解决方法，人们使用它是因为正式流程没有覆盖到真实情况。
第一次和软件开发者见面应该带什么？
带上你想要自动化或改进的真实案例——一张实际的订单表、发票、表格导出，或者你现在使用的工具的截图，而不只是口头描述它。再带上大致的想法：谁会每天使用这个系统、他们现在一步一步是怎么做的，以及还需要连接哪些其他工具或账号。真实案例能让开发者准确评估范围；只有描述容易让人靠猜测行事。
第一次沟通前需要准备一份书面简介吗？
不一定，但一份简短的一页说明会有帮助：具体问题是什么、受影响的是谁、理想的结果是什么样子，以及涉及哪些现有工具。你不需要技术用语或功能清单——用简单、具体的句子描述你真实的流程更有用。如果你确实还没有写下任何东西，一个真实的案例（一张订单、一份表格）在第一次见面时也可以代替简介。
如果我还不确定具体想要哪些功能怎么办？
这很正常，优秀的开发者也会预料到这一点。带上问题，而不是解决方案：现在哪里出了问题、多久发生一次、影响到谁。开发者在第一次沟通中的部分工作，正是把你描述的痛点转化为功能清单，而不是直接从你这里拿到一份现成的清单。准确了解问题，远比知道功能的名称重要得多。
关于目前流程的细节，我到底需要说明到什么程度？
要详细到一个从未接触过你业务的人也能照着步骤走下来：先发生什么、谁来做、用什么工具做，以及中途出错了会怎样。不必把它整理成一份正式的流程文件；那个不够整洁、但真实的版本——包括大家实际在用的变通办法——比省略了真实步骤的整洁版本更有用。
见面前我应该已经有预算的想法吗？
是的，哪怕只是一个大致范围，也能帮双方省去不必要的时间。你不需要一个精确的数字，但让开发者知道你考虑的是几千还是几万，能让他们提出合适的方案规模，或者及早告诉你，如果你的预期和实际成本相差很远。目标日期即使只是大概的，同样值得提前说明。
如果我还不能回答开发者的所有问题怎么办？
直接说清楚，而不是为了显得准备充分而随口编一个答案。能干的开发者会记下这个未解决的问题，建议该怎么找到答案，或者先按一个假设往下走，并写下来让你之后确认。为了避免说出"我不知道"而当场编造的答案，往往会在系统开始建造之后，变成代价高昂的误解重新浮现。
第一次沟通会让我承担什么义务吗？
这完全取决于供应商，所以应该在见面前直接问清楚，而不是自行假设。有些供应商提供免费、不承担义务的初次沟通或探索式通话；也有些会为范围评估环节收费，或者把第一次见面当作付费合作的开始。提前和你要见的人确认这一点，最好是书面确认，这样之后就不会有意外。