Модернізація Web-додатків з використанням нових технологій, HTML, XML, DHTML, Інтернет-технології, статті

Для підтримки успішної діяльності компанії часто впроваджують переваги нових і технологій, що розвиваються в свої основні продукти. На жаль, інтеграція з новими технологіями іноді може погіршити функціональні можливості системи і несприятливо вплинути на час виходу продукту на ринок. Час, необхідний команді розробників системи на освоєння нової технології, може обмежити кількість нових функціональних можливостей, що додаються у продукт. Зустрітися з найбільш типовими проблемами, пов’язаними з впровадженням нових технологій в існуючі продукти, і дізнайтеся, що можна зробити для обходу цих проблем і успішного оновлення ваших продуктів.

Модернізація будь-якого продукту з метою використання переваг найновішої технології може стати проблемою, але Web-додатки в цьому сенсі найбільш підступні. База користувачів Web-додатки не тільки динамічно змінюється, а й розподілена по всій земній кулі. Це означає, що додаток повинен бути надзвичайно доступним, надійним і масштабованим.


Аналіз типових сценаріїв


При прийнятті рішення про оновлення продукту для використання технологій, що розвиваються проблеми можуть виникнути всупереч самим кращим намірам. Розглянемо кілька прикладів.


Сценарій 1


Продукт, призначений для використання в маленьких і середніх за розміром підприємствах, добре працює в рамках дворівневої архітектури. Бачачи цей успіх, керівництво вирішує зробити продукт доступним також для більш великих підприємств. Це означає, що продукт повинен справлятися з більшою робочим навантаженням, підтримуючи такі ж настройки середовища і сервера, до яких звикли клієнти маленьких і середніх підприємств.


Технічний відділ приймає рішення перейти на n-рівневу архітектуру для розподілу робочого навантаження по рівнях. Крім того, керівництво вирішує додати ряд функціональних можливостей для нової категорії користувачів, оскільки продукт ще розвивається.


Менеджер проекту встановлює напружений графік робіт, і час здачі швидко наближається. Керівництво не приділяє належної уваги оцінці часу, необхідного для розробки принципів переходу на n-рівневу стратегію, а також часу, необхідного команді розробників на освоєння цих технологій. Неможливість укластися в заплановані терміни настільки не задовольняє вище керівництво, що після тривалих дискусій воно вирішує змінити менеджера проекту та інших працівників середньої ланки.


Сценарій 2


Вище керівництво вирішує виконати інтернаціоналізацію продукту і запропонувати стабільно працюючу в одній географічній зоні версію продукту для розповсюдження в інших зонах. На жаль, обсяг робіт по здійсненню інтернаціоналізації був недооцінений. Менеджери вирішили, що зміни мови в елементах користувальницького інтерфейсу буде достатньо, і пропустили той факт, що інтернаціоналізації підлягають також звернення, метрики і одиниці вимірювання, символи валюти, календарі і т.д.


Графік робіт зривається, а вийшов в результаті продукт працює не стабільно, навіть після затримки поставки. Це призводить до уїдливим оцінками багатьох, раніше задоволених користувачів, і на довгий час погіршує репутацію бренду.


Сценарій 3


Успішний продукт, який працює в дворівневої середовищі, має багато користувачів. Керівництво вирішує зробити продукт трирівневим, для того щоб користувачі мали доступ через Web і могли використовувати тонкі клієнти. Розмір коду досить значний, тому керівництво в останній момент вирішує, що замість підтримки роботи основної програмної частини продукту проміжний рівень буде просто передавати виклики інтерфейсного рівня на рівень зберігання даних.


Розробники не зірвали терміни, але насправді продукт не є трирівневим. Існуючі користувачі повинні заплатити значно більше за продовження роботи з наступною версією того ж продукту, не отримуючи натомість ніяких поліпшень в плані можливості розподілу робочого навантаження. В результаті компанія втрачає багатьох наявних користувачів.


Дослідження типових проблем


У попередніх сценаріях були зроблені типові помилки, яких можна було б легко уникнути. У наступних розділах аналізуються деякі проблеми, часто виникають з вини розробників, менеджерів і керівників проектів при впровадженні нових технологій в існуючі продукти.


Недооцінка кількості необхідного часу


Коли розвиток продукту має піти по новому шляху, багато аспектів розробки часто залишаються непоміченими, що приводить до невірної оцінки обсягу робіт. При будь-якому додаванні в продукт нових можливостей ви повинні правильно оцінити витрачаються на це зусилля.


При оцінці витрат на впровадження нової технології необхідне проведення пробного експерименту. Ви повинні ретельно вивчити результати експерименту до надання всіх розрахунків по витратах. Не забудьте включити у витрати час на освоєння нової технології. Якщо до розробки залучаються новачки в даній технології, передбачите додатковий час в циклі розробки.


Недооцінка необхідної кваліфікації


Часто керівники проекту не беруть до уваги час, необхідний розробникам на досягнення необхідного рівня кваліфікації. Це ще одна головна причина зривів графіка робіт.


При будь-якому оновленні продукту з метою використання нових технологій також повинен оновлюватися рівень кваліфікації персоналу. Ви завжди повинні пам’ятати про це при виконанні оцінних розрахунків. Ви повинні скласти план навчання персоналу і виділити на це достатньо часу.


Пропуск важливих вимог


Найчастіше керівництво не бере до уваги вимоги по модернізованої, рентабельності, надійності або економічності. Менеджери можуть порахувати, що ці функції будуть враховані в наступній версії. Це майже завжди фатальна помилка, оскільки нові версії, не задовольняють цим мінімальним вимогам, можуть викликати дискомфорт як у існуючих користувачів, так і у нових. Як тільки починається поширення продукту, повернути його назад вже дуже важко. Рентабельність, надійність і економічність завжди повинні бути в центрі уваги.


Гарантія забезпечення важливих властивостей


Ви повинні бути здатні забезпечити в продукті певні властивості за будь-яких обставин. Концентрація на цих вимогах гарантуватиме придатність продукту до використання в усі часи. Деякі властивості бажані, але наступні обов’язкові.


Продуктивність


У команді розробників потрібно постійно підтримувати певний рівень продуктивності. При впровадженні нової технології обов’язково оціните продуктивність роботи персоналу з цією технологією. Якщо рівень продуктивності неадекватний, не починайте розробку до досягнення потрібного рівня.


Для скорочення часу досягнення цього рівня ви можете ухвалити рішення провести командою розробників пробний експеримент із застосуванням нової технології. Змусьте персонал нести відповідальність за освоєння технології за певний період.


Економічність


Економічність має два аспекти. По-перше, компанія повинна зуміти відновити продукт, не перевищивши бюджет. По-друге, продукт повинен бути доступний за вартістю для користувачів. Якщо хоча б один з цих аспектів не дотримується, продукт приречений на невдачу.


Ви повинні постійно стежити за вартістю розробки і контролювати перевитрату коштів. Дуже часто на піку ентузіазму, який прийшов з новою технологією, організація може вирішити зайнятися справами, що не входять в її основну компетенцію, збільшуючи, таким чином, ризик перевитрати коштів. Крім того, ви повинні адекватно оцінити наслідки розробки або покупки компонентів перед прийняттям будь-яких рішень.


Ви повинні також відслідковувати загальну вартість володіння продуктом, щоб гарантувати доступність продукту за ціною, не дивлячись на впровадження нової технології. Враховуйте специфіку ваших клієнтів, їх інвестиційні можливості і рентабельність інвестицій (return on investment – ROI).


Надійність


На всіх етапах розробки ви повинні тримати під контролем кількість помилок (багів), ненавмисно внесених в продукт. Часто помилки розраховуються як відсоток від кількості рядків коду. Замість цього вони повинні розраховуватися в абсолютних значеннях.


У деяких сферах діяльності кількість помилок певного типу повинно бути зведені до нуля, для того щоб продукт був прийнятний для користувачів. Наприклад, у сфері охорони здоров’я проста помилка в Відповідно симптомів прізвища пацієнта може бути фатальною. Отже, будь-які навіть найпростіші в звичайних випадках помилки повинні бути ретельно проаналізовані перед занесенням їх в категорію допустимих.


Помилка, яка може не дати скористатися перевагами нової технології, але не перешкоджає функціонуванню, в більшості випадків може розглядатися як допустима. Наприклад, якщо кешування у додатку не працює, то продукт може бути хоча і повільним, але робітникам, природно до тих пір, поки він не стане нестерпно повільним.


Масштабованість


Коли популярність програми зростає, кількість користувачів може значно збільшитися, і це збільшення може бути багаторазовим. Час відгуку може стати проблемою, якщо додаток не має відповідних можливостей для масштабованості.


При зміні технології масштабованість є одним з найбільш часто торкається параметрів програми. Неефективна масштабованість може значно знизити популярність системи. Ви повинні розуміти, що з точки зору користувача дуже повільно працює додаток аналогічно додатком, не працює зовсім. Отже, потрібно належним чином подбати про те, щоб впровадження нової технології не вплинуло на масштабованість програми.


В ідеальному випадку в керівництві по вашому продукту повинно бути вказано, як ваші клієнти можуть додати апаратне забезпечення для роботи з збільшенням кількості своїх користувачів. Інформування ваших клієнтів про те, як додати апаратне забезпечення так, щоб не викликати простою додатки, в далекій перспективі сприятиме зростанню доброзичливості як ваших користувачів, так і користувачів ваших клієнтів. Рекомендації по максимальній кількості користувачів в керівництві по продукту будуть додатковим плюсом.


Ліквідність


Набір функціональних можливостей в продукті повинен задовольняти вимогам ринку. Зменшення функціональних можливостей нижче допустимого рівня може виявитися фатальним для продукту. Можна реалізувати бажану функціональність пізніше, якщо нова технологія змусила вас піти на таке зменшення функціональності продукту, але мінімальний набір можливостей повинен підтримуватися завжди.


Ніколи не покладайтеся на те, що ваші користувачі можуть піти на компроміс по відношенню до функціональності. Ви повинні пам’ятати, що наявні користувачі приймають регулярно використовувані ними функціональні можливості як належне. Отже, саме вони постраждають більше всіх і будуть найбільш роздратовані через зменшення функціональності.


Модернізованої


Ваші користувачі повинні мати можливість легко оновити дані і використовуваний продукт з попередньої версії на нову. Чи не оновлювані функції зазвичай призводять до зниження використовуваних продуктів і потенційно можуть зробити додаток даремним.


Навіть якщо ваші користувачі упевнені в можливості модернізації, ви повинні надати інструкції по міграції, для того щоб кожен користувач був задоволений новим продуктом. Це, можливо, зажадає часу на розуміння способів використання продукту користувачами.


Рентабельність


Рентабельність продукту страждати не повинна. Завжди потрібно ретельно розраховувати ROI продукту, беручи до уваги всі згадані вище фактори. Якщо на деякий час баланс буде негативним, необхідно надати керівництву чітку аргументацію і отримати схвалення. Керівництво завжди повинно бути поінформовано.


Резюме


Багато наступні версії успішних продуктів зазнають невдачі через те, що не приділяється належна увага одному або декільком ключовим аспектам. Розглянуті в даній статті аспекти повинні завжди бути в центрі уваги на всіх стадіях розробки продукту. Ігнорування хоча б одного з них може привести до припинення випуску продукту.


Схожі статті:


Сподобалася стаття? Ви можете залишити відгук або підписатися на RSS , щоб автоматично отримувати інформацію про нові статтях.

Коментарів поки що немає.

Ваш отзыв

Поділ на параграфи відбувається автоматично, адреса електронної пошти ніколи не буде опублікований, допустимий HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>

*

*