Як документувати стратегію оновлення комерційного програмного забезпечення?


11

Ми не оновлювали нашу RDBMS або серверну ОС майже десятиліття. Ще один критично важливий для місії пакет програм наближається до двох десятиліть і протягом більшої частини часу його постачальник не підтримує. Деякі з наших керівників, здається, вважають, що це добре - ми заощадили тонни грошей, не купуючи оновлення! Тепер критичний фрагмент програмного забезпечення потребує оновлення, але нова версія не підтримуватиме десятиліття. Зараз жменька з нас втрачає волосся, намагаючись зрозуміти, як оновлювати все відразу з мінімальним часом простою.

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

Як я можу задокументувати, що настільні клієнти A, B, C ... залежать від настільних ОС X та RDBMS Y, що, в свою чергу, залежить від OS Z сервера, і ось, як ми зберігаємо їх у своїх "солодких місцях"? Там повинні бути книги, але весь мій гуглінг лише привів мене до інформації про тактику модернізації окремого програмного забезпечення, а не про стратегію визначення того, коли потрібно застосувати ці тактики.


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

3
Жаргонним терміном для відстрочки оновлення є те, що ви нарощуєте «технологічний борг»; відкладаючи регулярне технічне обслуговування та оновлення, ви, здається, заощадите гроші на короткий термін, але коли в кінцевому підсумку вам доведеться виконувати технічне обслуговування після років нехтування, вам все одно доведеться платити за трубопровід: часто терміни будуть невдалі, продавці не будуть у вас є підтримуваний шлях негайного оновлення $CURRENT-version minus 20 yearsдо $CURRENT-versionі т. д., і ви, ймовірно, прийдете до висновку: це НЕ були фактичні заощадження, а видатки, які доведеться сплатити на майбутню дату .
HBruijn

1
Управління життєвим циклом - це невдячна необхідність у будь-якому зрілому середовищі та організації PITA. Удачі!
HBruijn

Відповіді:


7

Схоже, ви намагаєтеся вирішити багато проблем відразу (і це не виглядає як гарна ідея).

З того, що я прочитав:

  • застаріла ОС та додатки
  • немає довгострокової стратегії
  • проблеми документування вашої інфраструктури
  • нагальна необхідність оновлення критичної частини інфраструктури

Оновлення "критичної частини програмного забезпечення"

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

Тому перше, на що я звернув би увагу, це: чи знали менеджери про ризики застарілого програмного забезпечення? Чи їм сказали?

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

Я б просто проаналізував, що насправді означає оновлення. Підготуйте просту електронну таблицю з діяльністю та скільки часу вони займуть (якщо ви цього не знаєте, дайте найкращі здогадки та чітко підкресліть, що ви точно не знаєте). Але пам’ятайте, що ця "задача оновлення" недостатньо уточнена, неможливо це зробити як fix-time / fix-price.

Складання таких списків також допоможе вам розглянути всю проблему. Наступне - створити журнал ризику та список необхідних ресурсів.

Наприкінці ви повинні мати список видів діяльності, список ризиків, список матеріалів / людей, які вам потрібні. Одним словом, не розглядайте оновлення як повсякденну проблему, робіть це як ПРОЕКТ. Це дасть вам змогу мати хоч якийсь контроль над гострою потребою вашої компанії.

Якщо у вас є проблеми з аналізом того, які дії потрібно зробити, ви можете спробувати якусь карту розуму (мій улюблений sw - xMind), а потім перетворити її в більш офіційний документ.

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

Можливо, саме в цьому випадку: Згадайте, що оновлення можливо взагалі не можливо.

Немає довгострокової стратегії

Створення стратегічного плану зараз вам не допоможе. Це вам зовсім не допоможе, якщо це документ, підготовлений всередині вашого відділу ІТ. Стратегічний план - це те, що потрібно прив’язувати до потреб бізнесу.

Приклад необхідності бізнесу: Через два роки ми будемо відкривати нові офіси в Китаї та Австралії.

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

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

Підтримання та документування вашої інфраструктури

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

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

Є інструменти, які можуть допомогти вам у залежності від документації та обслуговування - CMDB (наприклад, iTop). Але його робота може зайняти деякий час, і вам все одно потрібен інструмент для документації. Найкраща ідея - налаштувати вікі для документації, де відтепер кожен може починати документувати / робити нотатки. Ви можете налаштувати вікі за півгодини, тож це дуже ефективний спосіб розпочати справи.

Особиста примітка: Оновлення ОС до старої була б величезною проблемою PITA, не згадуючи про (можливо, погану / відсутню) документацію. Чи не простіше встановити сервери заново, перенести програми та документувати все з самого початку?


Я ще мушу прочитати вашу відповідь уважніше, але спочатку. . . Повторно "Створення стратегічного плану вам зараз не допоможе": Історія про поточну бурю була призначена лише для ілюстрації. Ми ставимося до цього як до води під мостом і намагаємось разом скласти плановий план для запобігання майбутніх опадів калу. Мені потрібно відредагувати своє питання, щоб зробити це більш зрозумілим.
Фінг Ліксон

1
Так, я знаю, що ти маєш на увазі. Але я думаю, якщо ви викреслите саме це речення, решта відповіді все одно залишається дійсною. :)
Фійш
Використовуючи наш веб-сайт, ви визнаєте, що прочитали та зрозуміли наші Політику щодо файлів cookie та Політику конфіденційності.
Licensed under cc by-sa 3.0 with attribution required.