Время, необходимое команде разработчиков системы на освоение новой технологии, может ограничить количество новых функциональных возможностей, добавляемых в продукт. Познакомьтесь с наиболее типичными проблемами, связанными с внедрением новых технологий в существующие продукты, и узнайте, что можно сделать для обхода этих проблем и успешного обновления ваших продуктов.Модернизация любого продукта с целью использования преимуществ самой новой технологии может стать проблемой, но Web-приложения в этом смысле наиболее коварны. База пользователей Web-приложения не только динамически изменяется, но и распределена по всему земному шару. Это означает, что приложение должно быть чрезвычайно доступным, надежным и масштабируемым.
При принятии решения об обновлении продукта для использования развивающихся технологий проблемы могут возникнуть вопреки самым лучшим намерениям. Рассмотрим несколько примеров.
Продукт, предназначенный для использования в маленьких и средних по размеру предприятиях, хорошо работает в рамках двухуровневой архитектуры. Видя этот успех, руководство решает сделать продукт доступным также для более крупных предприятий. Это означает, что продукт должен справляться с большей рабочей нагрузкой, поддерживая такие же настройки среды и сервера, к которым привыкли клиенты маленьких и средних предприятий.
Технический отдел принимает решение перейти на n-уровневую архитектуру для распределения рабочей нагрузки по уровням. Кроме того, руководство решает добавить ряд функциональных возможностей для новой категории пользователей, поскольку продукт еще развивается.
Менеджер проекта устанавливает напряженный график работ, и время сдачи быстро приближается. Руководство не уделяет должного внимания оценке времени, необходимого для разработки принципов перехода на n-уровневую стратегию, а также времени, необходимого команде разработчиков на освоение этих технологий. Невозможность уложиться в запланированные сроки настолько не удовлетворяет высшее руководство, что после длительных дискуссий оно решает сменить менеджера проекта и других работников среднего звена.
Высшее руководство решает выполнить интернационализацию продукта и предложить стабильно работающую в одной географической зоне версию продукта для распространения в других зонах. К сожалению, объем работ по осуществлению интернационализации был недооценен. Менеджеры решили, что изменения языка в элементах пользовательского интерфейса будет достаточно, и пропустили тот факт, что интернационализации подлежат также обращения, метрики и единицы измерения, символы валюты, календари и т.д.
График работ срывается, а получившийся в результате продукт работает не стабильно, даже после задержки поставки. Это приводит к язвительным оценкам многих, ранее довольных пользователей, и на долгое время ухудшает репутацию брэнда.
Успешный продукт, работающий в двухуровневой среде, имеет много пользователей. Руководство решает сделать продукт трехуровневым, для того чтобы пользователи имели доступ через Web и могли использовать тонкие клиенты. Размер кода довольно значителен, поэтому руководство в последний момент решает, что вместо поддержания работы основной программной части продукта промежуточный уровень будет просто передавать вызовы интерфейсного уровня на уровень хранения данных.
Разработчики не сорвали сроки, но в действительности продукт не является трехуровневым. Существующие пользователи должны заплатить значительно больше за продолжение работы со следующей версией того же продукта, не получая взамен никаких улучшений в плане возможности распределения рабочей нагрузки. В результате компания теряет многих имеющихся пользователей.
В предыдущих сценариях были сделаны типичные ошибки, которых можно было бы легко избежать. В следующих разделах анализируются некоторые проблемы, часто возникающие по вине разработчиков, менеджеров и руководителей проектов при внедрении новых технологий в существующие продукты.
Недооценка количества необходимого времени
Когда развитие продукта должно пойти по новому пути, многие аспекты разработки часто остаются незамеченными, что приводит к неверной оценке объема работ. При любом добавлении в продукт новых возможностей вы должны правильно оценить затрачиваемые на это усилия.
При оценке затрат на внедрение новой технологии необходимо проведение пробного эксперимента. Вы должны тщательно изучить результаты эксперимента до предоставления всех расчетов по затратам. Не забудьте включить в затраты время на освоение новой технологии. Если к разработке привлекаются новички в данной технологии, предусмотрите дополнительное время в цикле разработки.
Недооценка необходимой квалификации
Часто руководители проекта не принимают во внимание время, необходимое разработчикам на достижение необходимого уровня квалификации. Это еще одна главная причина срывов графика работ.
При любом обновлении продукта с целью использования новых технологий также должен обновляться уровень квалификации персонала. Вы всегда должны помнить об этом при выполнении оценочных расчетов. Вы должны составить план обучения персонала и выделить на это достаточно времени.
Зачастую руководство не принимает во внимание требования по модернизируемости, рентабельности, надежности или экономичности. Менеджеры могут посчитать, что эти функции будут учтены в следующей версии. Это почти всегда фатальная ошибка, поскольку новые версии, не удовлетворяющие этим минимальным требованиям, могут вызвать дискомфорт как у существующих пользователей, так и у новых. Как только начинается распространение продукта, вернуть его обратно уже очень трудно. Рентабельность, надежность и экономичность всегда должны быть в центре внимания.
Гарантия обеспечения важных свойств
Вы должны быть способны обеспечить в продукте определенные свойства при любых обстоятельствах. Концентрация на этих требованиях будет гарантировать пригодность продукта к использованию во все времена. Некоторые свойства желательны, но следующие обязательны.
В команде разработчиков нужно постоянно поддерживать определенный уровень производительности. При внедрении новой технологии обязательно оцените производительность работы персонала с этой технологией. Если уровень производительности неадекватен, не начинайте разработку до достижения нужного уровня.
Для сокращения времени достижения этого уровня вы можете принять решение провести командой разработчиков пробный эксперимент с применением новой технологии. Заставьте персонал нести ответственность за освоение технологии за назначенный период.
Экономичность имеет два аспекта. Во-первых, компания должна суметь обновить продукт, не превысив бюджет. Во-вторых, продукт должен быть доступен по стоимости для пользователей. Если хотя бы один из этих аспектов не соблюдается, продукт обречен на неудачу.
Вы должны постоянно следить за стоимостью разработки и контролировать перерасход средств. Очень часто на пике энтузиазма, пришедшего с новой технологией, организация может решить заняться делами, не входящими в ее основную компетенцию, увеличивая, таким образом, риск перерасхода средств. Кроме того, вы должны адекватно оценить последствия разработки или покупки компонентов перед принятием любых решений.
Вы должны также отслеживать общую стоимость владения продуктом, чтобы гарантировать доступность продукта по цене, не смотря на внедрение новой технологии. Учитывайте специфику ваших клиентов, их инвестиционные возможности и рентабельность инвестиций (return on investment - ROI).
На всех этапах разработки вы должны держать под контролем количество ошибок (багов), непреднамеренно внесенных в продукт. Часто ошибки рассчитываются как процент от количества строк кода. Вместо этого они должны рассчитываться в абсолютных значениях.
В некоторых сферах деятельности количество ошибок определенного типа должно быть сведены к нулю, для того чтобы продукт был приемлем для пользователей. Например, в сфере охраны здоровья простая ошибка в соответствии симптомов фамилии пациента может быть фатальной. Следовательно, любые даже самые простые в обычных случаях ошибки должны быть тщательно проанализированы перед занесением их в категорию допустимых.
Ошибка, которая может не дать воспользоваться преимуществами новой технологии, но не препятствующая функционированию, в большинстве случаев может рассматриваться как допустимая. Например, если кэширование в приложении не работает, то продукт может быть хотя и медленным, но рабочим, естественно до тех пор, пока он не станет нестерпимо медленным.
Когда популярность приложения растет, количество пользователей может значительно увеличиться, и это увеличение может быть многократным. Время отклика может стать проблемой, если приложение не имеет соответствующих возможностей для масштабируемости.
При смене технологии масштабируемость является одним из самых часто затрагиваемых параметров приложения. Неэффективная масштабируемость может значительно понизить популярность системы. Вы должны понимать, что с точки зрения пользователя очень медленно работающее приложение аналогично приложению, не работающему вовсе. Следовательно, нужно должным образом позаботиться о том, чтобы внедрение новой технологии не повлияло на масштабируемость приложения.
В идеальном случае в руководстве по вашему продукту должно быть указано, как ваши клиенты могут добавить аппаратное обеспечение для работы с увеличившимся количеством своих пользователей. Информирование ваших клиентов о том, как добавить аппаратное обеспечение так, чтобы не вызвать простоя приложения, в дальней перспективе будет способствовать росту доброжелательности как ваших пользователей, так и пользователей ваших клиентов. Рекомендации по максимальному количеству пользователей в руководстве по продукту будут дополнительным плюсом.
Набор функциональных возможностей в продукте должен удовлетворять требованиям рынка. Уменьшение функциональных возможностей ниже допустимого уровня может оказаться фатальным для продукта. Можно реализовать желаемую функциональность позднее, если новая технология заставила вас пойти на такое уменьшение функциональности продукта, но минимальный набор возможностей должен поддерживаться всегда.
Никогда не полагайтесь на то, что ваши пользователи могут пойти на компромисс по отношению к функциональности. Вы должны помнить, что имеющиеся пользователи принимают регулярно используемые ими функциональные возможности как должное. Следовательно, именно они пострадают больше всех и будут наиболее раздражены из-за уменьшения функциональности.
Ваши пользователи должны иметь возможность легко обновить данные и используемый продукт с предыдущей версии на новую. Не обновляемые функции обычно приводят к снижению используемости продукта и потенциально могут сделать приложение бесполезным.
Даже если ваши пользователи уверены в возможности модернизации, вы должны предоставить инструкции по миграции, для того чтобы каждый пользователь был доволен новым продуктом. Это, возможно, потребует времени на понимание способов использования продукта пользователями.
Рентабельность продукта страдать не должна. Всегда нужно тщательно рассчитывать ROI продукта, принимая во внимания все упомянутые выше факторы. Если на некоторое время баланс будет отрицательным, необходимо предоставить руководству четкую аргументацию и получить одобрение. Руководство всегда должно быть проинформировано.
Многие последующие версии успешных продуктов терпят неудачу из-за того, что не уделяется должное внимание одному или нескольким ключевым аспектам. Рассмотренные в данной статье аспекты должны всегда быть в центре внимания на всех стадиях разработки продукта. Игнорирование хотя бы одного из них может привести к прекращению выпуска продукта.
Шантану Бхаттачария, главный консультант, Siemens Information Systems Limited
