一点背景：我有机会向我国的一家大型汽车共享公司的管理层提出公共API的想法 . 目前，预订汽车的唯一选择是非常慢的网络界面和难以到达的呼叫中心 . 因此，我对编写自己的搜索界面，将此功能集成到其他产品和应用程序等中的可能性感到兴奋 .
问题是：由于这家公司的特殊性，我首先必须通过一个委托来获得我的建议，这完全由非技术性和相当保守的人组成 . 如何向这样的受众解释API的概念？
多年来，销售人员基于两件事：特点和效益 . 每个功能都应该有一个相关的好处（对某人，最好是每个人） . 在这种情况下，你're apparently planning to break what's基本上是一个单片应用程序（至少）两个部分：前端和后端 . 明显的好处是1）每个独立工作，因此每个的开发更容易 . 2）不同的人可以开发不同的部分，3）通过简单地购买更多的硬件来增加容量更容易 .
虽然您没有明确说明，但我猜想有一个意图是公开记录API . 这允许外部开发人员接管（至少一些）前端代码的开发（通常免费，不少），同时保持对业务流程至关重要的部分的控制 . 您可以更轻松地[允许其他人]添加新的前端代码以应对新的细分市场，同时保持基础业务流程在此过程中不会受到干扰的安全性/确定性 .
不要像API那样解释技术细节 . 说明业务问题和业务问题的解决方案 - 以及它将如何影响他们的底线 .
HardCode的答案是正确的，因为你应该真正专注于业务问题和好处 .
但是，如果你觉得你需要解释一些东西，你可以使用医疗接待员的模拟 .
医疗实践拥有自己的患者数据库和预约安排系统，由其管理员和医务人员使用 . 这在内部可能非常复杂 .
然而，当您想预约患者时，您可以通过简单的命令与接待员交谈 - “我想要预约”，“我想看医生X”，“我感到恶心”，并且他们与他们的系统接口根据您的病史，所呈现的症状和资源可用性 - 约会 - 明天下午4:30 - 用简单的语言 .
因此，粗略地说使用接待员类似于使用API的外部程序 . 它允许您与复杂系统进行交互，以获得所需的信息，而无需处理内部复杂性 .
他们将能够理解拥有可与预订系统交互的移动电话应用程序的好处，并且API是其中必不可少的组成部分 . API公开的第二个好处是，您不一定要编写该应用程序，其他人将能够（当然，他们实际做的是否是另一个问题） .
您应该解释项目提案将改进哪些用例 . 他们可以期待什么好处，比如客户满意度 .
5 回答
多年来，销售人员基于两件事：特点和效益 . 每个功能都应该有一个相关的好处（对某人，最好是每个人） . 在这种情况下，你're apparently planning to break what's基本上是一个单片应用程序（至少）两个部分：前端和后端 . 明显的好处是1）每个独立工作，因此每个的开发更容易 . 2）不同的人可以开发不同的部分，3）通过简单地购买更多的硬件来增加容量更容易 .
虽然您没有明确说明，但我猜想有一个意图是公开记录API . 这允许外部开发人员接管（至少一些）前端代码的开发（通常免费，不少），同时保持对业务流程至关重要的部分的控制 . 您可以更轻松地[允许其他人]添加新的前端代码以应对新的细分市场，同时保持基础业务流程在此过程中不会受到干扰的安全性/确定性 .
不要像API那样解释技术细节 . 说明业务问题和业务问题的解决方案 - 以及它将如何影响他们的底线 .
HardCode的答案是正确的，因为你应该真正专注于业务问题和好处 .
但是，如果你觉得你需要解释一些东西，你可以使用医疗接待员的模拟 .
医疗实践拥有自己的患者数据库和预约安排系统，由其管理员和医务人员使用 . 这在内部可能非常复杂 .
然而，当您想预约患者时，您可以通过简单的命令与接待员交谈 - “我想要预约”，“我想看医生X”，“我感到恶心”，并且他们与他们的系统接口根据您的病史，所呈现的症状和资源可用性 - 约会 - 明天下午4:30 - 用简单的语言 .
因此，粗略地说使用接待员类似于使用API的外部程序 . 它允许您与复杂系统进行交互，以获得所需的信息，而无需处理内部复杂性 .
他们将能够理解拥有可与预订系统交互的移动电话应用程序的好处，并且API是其中必不可少的组成部分 . API公开的第二个好处是，您不一定要编写该应用程序，其他人将能够（当然，他们实际做的是否是另一个问题） .
您应该解释项目提案将改进哪些用例 . 他们可以期待什么好处，比如客户满意度 .