Модернізація Web-додатків з використанням нових технологій

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

Модернізація будь-якого продукту з метою використання переваг самої нової технології може стати проблемою, але 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>

*

*