Приділяйте пильну увагу підтримці і супроводу

Мнчедізі Каспер

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

У ході проектування програми перед внутрішнім поглядом архітекторів знаходяться головним чином розробники, збройні інтегрованими середовищами та отладчиками Якщо щось йде не так, вправні програмісти перемикаються в режим налагодження і знаходять помилку Така картина цілком природна, оскільки більшість архітекторів основну частину свого життя проводять в ролі розробників, а не адміністраторів системи На жаль, розробник і фахівець служби підтримки володіють різними навичками – аналогічно тому, як середовище розробки / тестування і робоча середовище (production environment) служать різним цілям

Ось приклади проблем, з якими стикається адміністратор системи:

• Адміністратор не може заново відправити запит, щоб відтворити проблему У робочій середовищі ви не можете виконати фінансову транзакцію в «бойовій» базі даних, щоб просто подивитися, де сталася помилка

• Коли додаток знаходиться в робочому середовищі, вимоги виправити помилки виходять від користувачів і начальства, а не від керівника проекту та групи тестування – а розгніване начальство набагато небезпечніше

• У робочій середовищі немає відладчика

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

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

Деякі із симптомів недостатнього планування підтримки виглядають так:

• Більшість проблем вимагає залучення розробника

• Відносини між командою розробників і службою підтримки вельми напружені розробники вважають, що в службі підтримки зібрали одних ідіотів

• Служба підтримки ненавидить новий додаток

• Команди архітекторів і розробників проводять багато часу в робочому середовищі

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

• Адміністраторам вічно не вистачає часу для нормальної налаштування системи, тому що вони постійно займаються «гасінням пожеж»

Щоб ваш додаток успішно працювало після того, як вийде з рук розробників, ви повинні:

• Зрозуміти, що розробка та підтримка вимагають різних навичок

• Як можна раніше залучити до проекту керівника служби технічної підтримки

• Зробити керівника служби технічної підтримки однієї з центральних фігур проектної команди

• Залучити керівника служби технічної підтримки до планування підтримки програми

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

Мнчедізі Каспер (Mncedisi Kasper) – директор з технології та стратегії в Open Xcellence ICT Solutions, південноафриканської компанії, що спеціалізується на інтеграції корпоративних додатків і консультаціях в області SAP (АВАР / XI)

Джерело: Форд Н, Найгард М, де Ора Б, 97 етюдів для архітекторів програмних систем – Пер з англ – СПб: Сим-вол-Плюс, 2010 – 224 с, Мул

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


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

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

Ваш отзыв

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

*

*