IT на стероїдах: плюси і мінуси пришвидшення технологічного прогресу

Harvard Business Review

У 1998 році компанія Research in Motion запустила перший свій BlackBerry. А вже через рік наступна версія була обладнана фізичною клавіатурою. Здавалося, що цього хотіли користувачі.

Попит на Blackberry 850 злетів до висот і у 2004 році RIM перетнула позначку у перший мільйон користувачів. Через три роки, у 2007 кількість юзерів спочатку сягнула 10 мільйонів, а потім - і 12.

За результатами того ж таки 2007 року, коли Apple випустила свій перший iPhone з тачскріном і кращим інтернет-браузером, - виробник ґаджетів BlackBerry зґенерував 1,67 мільярда доларів доходів.

Починаючи з наступного, 2008 року, RIM робила відчайдушні спроби наздогнати свого конкурента, але ні нові телефони, ні нова програмна частина, ні додаткові додатки - нічого з цього всього не вразило ані експертів, ані користувачів.

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

Перед ним були, скажімо, Motorola і Palm, які зазнали ринкових невдач з тієї ж причини.

Такий усе зростаючий і зростаючий темп - який у журналістських і академічних колах називають "інновацією на стероїдах" - починає добиратися і до ІТ-відділів.

Першою серйозною зміною у швидкості видачі продуктів з ІТ-департаментів стало повсюдне перетворення їх на "послуги". До цього часу даний тренд асоціювався з доволі стандартизованими рішеннями типу софта для CRM-систем (customer relationship management), веб-серверів або SQL-баз даних.

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

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

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

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

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

Це не такий уже і новий підхід, наприклад, хмарні технології – новіші, але він вартий детальнішого розгляду. Основне питання до нього - чи можна його успішно масштабувати.

Оскільки це "спритне програмування" стає найбільш популярним методом розробки великомасштабних ІТ-проектів, зростає потреба у пришвидшенні розробки. І корпоративним ІТ нічого не залишається як тільки повлаштовуватися під нові правила гри.

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

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

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

Тобто це ще один серйозний аргумент на користь "спритної розробки".

Власне дослідження Harvard Business Review пішло ще далі. Попередні результати - на основі близько 4300 ІТ-проектів - свідчать про те, що довгі часові рамки реалізації проектів збільшують їх ризики в усіх типах проектів, а не лише у розробці програмного забезпечення.

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

Кожен додатковий рік реалізації проекту збільшує шанси на перетворення його у стан "чорного лебедя" в середньому на 27%.

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

Так, наприклад, для боротьби з перевищеннями запланованих бюджетів і часових перевитрат новоспечені CIO (chief informational officer), не довго думаючи, взяли собі за правило: проекти не можуть бути довшими за 12 місяців.

А деякі пішли навіть ще далі. Наприклад, австралійський штат Південна Австралія взагалі заявив, що розглядатиме лише проекти, реалізація яких займе не більше 90 днів.

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

Звістка про фінансування лише малих проектів призвела до появи дрібних, пов’язаних переважно з економією коштів пропозицій розробки.

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

Не кажучи вже про впровадження інновацій. І аби привести до ладу існуючу ІТ-архітектуру і спростити її - довелося здійснити величезний і довготривалий ІТ-проект - з усіма ризиками його довготривалості і складності.

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

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

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

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

Якщо коротко, то стратегічне лідерство в ІТ у сьогоднішньому швидкісному бізнес-середовищі означає правильну суміш швидкої і повільної розробки.



Коментарі

Додати коментар


Читайте у розділі

Глобальне будівництво до 2025 року: прогноз позитивний

Відео

Загрузка...

Тест-драйв

закрити
E-mail
Пароль
Також, ви можете авторизуватись через Facebook Facebook login

Якщо ви не зареєстровані, пройдіть цю просту процедуру.