PDF案例研究：RIA开发
评论：没有路线图的旅程
Peter Christy，互联网研究小组
SalesCentrix 为了现有产品开发新的 RIA 功能所做的努力，是 尝试创建类似于现代商学院经验核心案例研究的一部分。这是一个艰巨的挑战。首先，大多数商学院案例研究至少会参考支持性文件。通常，即使是潜在的财务数据也能提供一些有价值的线索。然而，在这种情况下，所涉公司已经消失，只留下这份案例研究供我们评估。因此，我无法区分对公司实际做出的技术选择的观察，以及这些选择在案例研究中的呈现方式。因此，如果任何原始参与者有机会阅读本文，我在此提前为任何误解道歉。—PC
从广义上看，编程项目失败的次数远多于成功的次数。在某些情况下，失败是通往成功的有用一步，但往往它仅仅是失败——浪费的努力（除了让参与者比以前更聪明一些，希望如此）。
在这个案例研究中，失败的种子太明显了，至少以事后诸葛亮的智慧来看是这样。真正突出的两个警告信号是，缺乏任何连贯的需求或目标声明（例如，请注意，性能的概念似乎是事后才想到的），以及团队选择了一种他们几乎没有资格的技术方法——即编写 PC 软件，同时避免使用任何微软技术。因此，如果这里的工作只是事后解释失败（很像解释为什么股市在任何一天上涨或下跌），我们现在就可以停止了。但也许我们仍然可以从经验中学到一些东西。让我们关注需求问题。
在这方面，案例研究的开头是不祥的：“SalesCentrix，一家位于温哥华的小型初创公司，在 2006 年意识到，必须对其 SaaS（软件即服务）解决方案做些什么，该解决方案用于在 QuickBooks 和 SalesForce 之间同步数据，以便用户更好地利用 Web。” 用户可能需要更快或更好地完成任务，但在这种情况下，需求不能字面上确定为“更好地利用 Web”（尽管这似乎准确地描述了公司所采取的路径）。然后，案例研究很快跳到结论，认为正确的方法是构建 RIA（富互联网应用程序）。当然，RIA 是使用 Web 的一种方式。
SalesForce 是商业 SaaS 的成功先驱，这是一种应用程序交付形式，其重要性只会随着时间的推移而增长。SalesForce 在许多重要的架构问题上做对了（例如，一个高度可靠的、多租户的数据库系统，具有基于元数据的个性化），并且它设法选择了一个市场（客户关系管理/销售管理），在这个市场中，Web 和 SaaS 特别有吸引力，因为目标用户的移动性质。
小型企业是 SalesForce 最初的关注点，因为他们无法在内部实际运行自己的 CRM 系统。鉴于许多小型企业使用 Intuit 的 QuickBooks 进行会计，SalesCentrix 促进 QuickBooks 和 SalesForce 协调的想法也似乎很有道理。对于新的 SalesForce 用户来说，QuickBooks 通常是许多客户信息的最佳来源。此外，用 QuickBooks 数据预填充 SalesForce 的能力显然是一个好主意——同步能力也是如此，以便一旦潜在客户在 SalesForce 中转换为客户，就会在 QuickBooks 中自动创建一个新条目。
不清楚的是 SalesCentrix 希望通过 RIA 解决这个问题的哪个部分，以便用户“更好地利用 Web”，因为案例研究从未真正触及这些问题。这导致持怀疑态度的技术人类学家得出一个合理的假设，即 SalesCentrix 的努力很快变成了一种技术寻找要解决的问题（一种非常常见的现象）。为了同情工程师，RIA 和 Google 在这项工作开始时非常热门，为 SalesCentrix 团队对使用它们感兴趣提供了足够的动力。但目的是什么呢？
对于稍后偶然遇到的技术人类学家来说，这里案例研究留下的可供研究的东西很少。众所周知，当目标是将 Outlook 同步到运行某种固件版本的随机手机时，同步设置是一个棘手的问题。在这种特殊情况下，SalesCentrix 解决方案的必要通用性（具有在基本上无限的移动平台变体上运行的多种 Outlook 版本）显然会使帮助用户正确处理细节非常具有挑战性。
但这不是这里的问题。当然，QuickBooks 版本蔓延是需要考虑的，但这可能比预期的要少，仅仅是因为税法和报告要求的变化是 QuickBooks 用户保持更新的相对强大的动力。然而，更重要的是，在任何时刻，都只有一个版本的 SalesForce，仅仅因为它以 SaaS 形式交付，这意味着所有用户都在同一个系统上，并在同一时刻更新。我不清楚为什么正确设置是一个问题，反过来又需要用户“更好地利用 Web”。技术人类学家再次认为这带有（有趣的）技术寻找问题的味道。
能从中学习到什么？教训可能与产品营销和产品管理的价值有关。可悲的是，不能指望程序员花足够的时间思考软件用户的需求。一些开发人员认为他们比用户自己更了解用户应该做什么。有些人专注于他们构建了什么，而不是它将如何被使用。有效的产品经理可以通过将用户需求反馈给开发团队来弥合差距。理想情况下，这种动态具有相当大的互动性。创新和设计通常最好由工程师驱动，因为他们可以最好地看到技术进步如何使新的解决方案成为可能（RIA 就是一个很好的例子）。然后，产品经理可以将创新与用户面临的挑战和机遇联系起来。答案不在于孤立地依赖任何一种观点，而在于有效地融合这两种观点。
我们如何避免重演这段悲伤的历史？一个好的开始是不要想象用户想要或需要什么，而是与他们谈论它。尝试设身处地为他们着想，了解您的软件如何帮助改善他们的生活（或者没有，就像本例一样）。如果您没有时间自己做这件事，那么您至少应该与优秀的产品营销人员合作，并倾听他们的意见。
PETER CHRISTY是互联网研究小组的负责人之一，该小组是一家专注于互联网风险投资的咨询公司。
最初发表于Queue杂志第7卷第1期—
在数字图书馆中评论这篇文章
更多相关文章
Edward Steel, Yanik Berube, Jonas Bonér, Ken Britton, Terry Coatta - Hootsuite：追求响应式系统
当使用微服务时，框架和标准对于开发团队的重要性已经变得显而易见。人们常常将微服务提供的灵活性误认为是每个服务都需要使用不同技术的必要条件。像所有开发团队一样，我们仍然需要尽可能减少我们使用的技术数量，以便我们可以轻松地培训新人、维护我们的代码、支持团队之间的调动等等。
Kiran Prasad, Kelly Norton, Terry Coatta - LinkedIn的Node：追求更薄、更轻、更快
Node.js，这个用于构建可扩展网络应用的服务器端JavaScript软件平台，在过去几年中一直是许多开发者热议的话题，尽管它的流行也激怒了一些其他人，他们发布了大量负面博文来指出其被认为的缺点。尽管Node仍然是新的且未经充分测试的，但它仍在继续赢得更多拥护者。
© 公司，版权所有。