用新技术升级 Web 应用程序

 

 <o:p></o:p>

用新技术升级 Web 应用程序<o:p></o:p>

 <o:p></o:p>

为了在市场中立于不败之地，很多公司经常将新兴技术整合到其现有的主流产品中。但是，集成新的技术有时会牺牲产品的某些特性并且会影响合适的上市时间。产品开发团队常常要先熟悉这些新技术，在这方面所花费的时间又不能太多，这在某种程度上会限制所能添加到产品的新特性。通过本文，您可以了解与将新技术整合进现有产品相关的一些常见问题，学习如何才能避免这些问题，进而成功升级您的产品。

为了利用最新技术的优势而升级现有产品并不是件容易的事，其中，基于 Web 的应用程序是最难的部分。一方面基于 Web 的应用程序的用户群常会急剧变化，另一方面，这些用户常会来自世界的每个角落，因此应用程序必须高度可用、可靠和可伸缩。

 <o:p></o:p>

常见的场景分析

 <o:p></o:p>

在决定升级产品以便利用新兴技术时，即使考虑得再周到也难免会出现问题。请看下面的几个例子。

 <o:p></o:p>

场景 1

 <o:p></o:p>

现有针对中小型业务设置的一款产品，该产品在两层架构中工作得很好。看到它的成功，最高管理层决定将它推广到大型业务。这意味着产品必须能够处理大型负载，与此同时，还必须保持中小型客户所熟悉的同样的环境和服务器设置。

 <o:p></o:p>

技术团队决定将此产品转换到 n 层架构来将负载分散到各个层。此外，由于该产品还处于市场的磨合期，因此管理层认为还需要为新的一类用户添加尽量多的特性。

 <o:p></o:p>

给产品经理的时间太紧，结果是进度几次拖延。管理层没有正确估计实现 n 层架构转换所需的时间和产品开发团队熟悉 n 层技术所需的时间。进度的拖延让最高管理层很不高兴，经过一番考虑之后，最终决定换掉产品经理和其他几位较高级别的员工。

 <o:p></o:p>

场景 2

 <o:p></o:p>

最高管理层决定要实现全球化，将一个在一个地理区域业已稳定的产品推广到另一个地理区域。但不幸的是，全球化所需的工作量被严重低估了。管理层觉得更改一下 UI 消息的语言就足够了，他们却忽视了这样的一个事实，即国际化涉及的内容很广，包括打招呼的习惯、度量制式、货币符号、日历时间表示等等。

 <o:p></o:p>

任务还是无法如期完成，即使交付几经延期，做出的产品仍然很不稳定。招致的批评之声不断，甚至一些以前很满意他们服务的那些客户也都表示了极度的不满，这一切在今后很长一段时间内都将影响该公司的品牌形象。

 <o:p></o:p>

场景 3

 <o:p></o:p>

现有这样一款产品运行于两层环境，而且用户也很多。管理层突然决定要将该产品升级到三层结构以便客户能通过 Web 访问和使用此产品，而且它具有瘦客户机。为了实现这个目的所需的编码工作相当巨大，考虑到这一点，管理层稍后决定放弃包含产品的内容，只要求简单地格式化中间层以便可以进行前端到后端的调用。

 <o:p></o:p>

开发人员虽然如期完成了任务，但产品还是没有被很好地分为三层。现有客户必须支付额外的费用才能运行同样的产品，只不过版本不同而已，客户并没有在负载处理能力上获得任何实惠。结果显而易见，现有的客户大范围丢失。

 <o:p></o:p>

常见问题

 <o:p></o:p>

在上述场景中，出现了很多常见错误，这些错误本可以轻易避免。接下来的章节将来着重看看在将新技术整合进现有产品时开发人员、经理和产品经理所常犯的一些错误。

 <o:p></o:p>

低估所需时间

 <o:p></o:p>

当产品需要进行新的升级时，有许多开发方面常常会被忽视，进而导致不正确的任务和工作量估计。无论何时向产品添加新的维度和层面，都需要正确地估计所需要的工作量。

 <o:p></o:p>

在对新技术整合进行估测时，进行概念证明（proof of concept）是必需的。在提供正式的估计之前，应该仔细研究这个概念证明的结果。确保将熟悉新技术所需的时间也包括进来。如果一些新技术方面的新手将要参与开发，还需要在开发周期中留出额外的时间。

 <o:p></o:p>

低估技能集

 <o:p></o:p>

通常，项目经理都不会考虑其团队升级到新技能集所需的时间。这是进度拖沓的另一个重要原因。

 <o:p></o:p>

当产品需要升级以利用新技术的优势时，开发团队中的个人技能集也要相应更新。在进行估计时，需要时刻牢记团队技能集这个因素。您需要为团队草拟培训规划并为之分配一定的时间。

 <o:p></o:p>

忽视重要的要求

 <o:p></o:p>

很多时候，产品管理都会忽略可升级性、可盈利性、可靠性和可购性。经理们可能会觉得这些能力可以在后续发布中逐步解决。这种想法大错特错，因为新版本若未包括这些基本的要求就会为现有客户和新客户带来极大的不便。一旦产品上市，就很难将其再召回。可盈利性、可靠性和可购性必须被加以足够的重视。

 <o:p></o:p>

 <o:p></o:p>

 <o:p></o:p>

 

 <o:p></o:p>

 <o:p></o:p>

 <o:p></o:p>

 

 <o:p></o:p>

 <o:p></o:p>

 <o:p></o:p>

确保满足重要的特性

 <o:p></o:p>

产品必须在任何环境下都能满足尽量多的条件。满足这些要求就能确保产品可以在任何时候都可用。满足的条件越多越好，但如下的几个条件是必须要满足的。

 <o:p></o:p>

生产力

 <o:p></o:p>

团队始终都要保持某种程度的生产力。引入新的技术时，先要估测一下团队在新技术方面的生产力。如果生产力水平不足，就不要开始开发，而是要等到生产力水平足够的时候才开始。

 <o:p></o:p>

为了减少走弯路，可以让研究和开发团队就新技术进行概念证明。让此团队在新技术的启动期间负责传授相关的技术知识。

 <o:p></o:p>

可购性

 <o:p></o:p>

可购性涉及两个方面。一方面，公司必须在预算内实现产品的升级。另一方面，产品的价格必须是客户可承受的。如果可购性的这两个方面中的任意一个都没有加以考虑，那么该产品就很可能会失败。

 <o:p></o:p>

应该不断地监视开发的成本以防成本超出预算。很多时候，受新技术的蛊惑，企业可能会选择进入它不具竞争力的领域，这就增加了成本超支的机会。此外，在选择是自己制造组件还是外购组件时，必须充分衡量二者的后果。

 <o:p></o:p>

您也应该监视产品的总的所有权成本以确保产品不会由于引入了新技术而变得高不可攀。务必对客户定位和客户的投资能力以及投资回报 (ROI) 多加考虑。

 <o:p></o:p>

可靠性

 <o:p></o:p>

在开发的所有阶段，都必须对引入到产品中的 bug 数严加检查。很多时候，bug 数按相对代码行的百分比进行计算。实际上，bug 数应该按其自身进行计算。

 <o:p></o:p>

在某些域，某些类型的 bug 必须保持为零以使产品能被客户接受。例如，对于一个医疗软件，如果存在 bug，将病人的病症张冠李戴，这就是一种性命攸关的错误。所以，即使是看起来无关大碍的那些 bug 也要在被确定为可接受之前仔细加以分析。

 <o:p></o:p>

如果一个 bug 虽然不能获得新技术的益处但却能完成功能性，那么它就可以认为是可接受的。例如，如果缓存在某个应用程序中不能正常工作，那么产品有可能会变慢，但一般来讲这是可接受的，除非慢得让人无法容忍。

 <o:p></o:p>

可伸缩性

 <o:p></o:p>

随着应用程序的流行，用户数量也会大幅度增加，而且这种增加是多种形式的。如果应用程序没有适当的可伸缩性，那么响应时间就会受到严重的影响。

 <o:p></o:p>

在技术的变化发展过程中，可伸缩性一直都是应用程序最为常见的受影响参数之一。可伸缩性不佳会急剧减低系统的普及度。必须看到，对用户而言，响应慢的应用程序与根本不能工作的应用程序没什么两样。因此，必须谨慎确保整合新技术不会影响到应用程序的可伸缩性。

 <o:p></o:p>

理想地，您的产品手册应该能够指导客户该如何添加硬件来适应日益增加的用户数。告知用户如何使用不造成应用程序停机的方式添加硬件将有助于维护您和客户之间的关系。如果能在产品手册中加上一个有关最大用户数的说明就更好了。

 <o:p></o:p>

可销售性

 <o:p></o:p>

产品可用的特性集应该足够满足市场任何时候的需求。若将特性减少到不能接受的程度就有可能对产品造成致命的威胁。如果新技术要求必须削减产品的特性范围，那么您可以在日后再实现所需的特性，但最基本的特性集必须要一直保留。

 <o:p></o:p>

千万不要认为现有客户会对特性的要求有所放松。因为现有的客户更易于把他们经常使用的特性认为是想当然的。因此，如果特性集缩减了，最容易恼怒和受到打击的就是这些客户。

 <o:p></o:p>

可升级性

 <o:p></o:p>

客户常常要求产品的数据和使用必须能轻松从之前的版本升级，除非您能说服客户不这么要求。不可升级的特性通常会导致产品的不可用并可能会使应用程序无效。

 <o:p></o:p>

即使客户信服了产品具有可升级性，您还是必须为每个客户提供具体的迁移路径以便他们不会对新产品产生不满。这个过程可能需要您花费一些时间来了解客户使用产品的具体方式。

 <o:p></o:p>

可盈利性

 <o:p></o:p>

产品的可盈利性永远不能小觑。始终要仔细计算产品的投资回报（ROI），并将上述提到的因素都考虑进去。如果新技术的加入让产品的资产负债表在一定时间内出现了亏空，就应该将这一情况及时向最高管理层汇报，并征得他们的同意，这样一来，最高管理层就总能把握盈亏情况。

 <o:p></o:p>

结束语

 <o:p></o:p>

很多本来很成功的产品常常因为忽视了某些关键的方面而在其后续版本中败下阵来。本文所介绍的这些关键方面在产品的所有发布中都必须给与足够的重视。其中对任何一个方面的忽视都可能会导致整个产品的终结。

 <o:p></o:p>