- Чому польським підприємцям подобаються IT On-Premise системи? - 24 Вересня 2024
- Чи є низький код і відсутність коду лише варіаціями на одну тему? - 13 Березня 2023
- Чи система no-code не позбавить програмістів роботи ? - 1 Березня 2023
Твоя система вже готова. Ти успішно використовуєш його протягом кількох тижнів. Все працює «як треба», і ти починаєш бачити, що ще можна покращити. Автоматизація базової діяльності настільки полегшила роботу команди, що хочеться більшого.
Нічого незвичайного!
Але як повернутися до співпраці з компанією-реалізатором після офіційного завершення проекту? Почати все спочатку?
Розслабся, не треба. Для чого потрібні SLA. Саме для чого?
SLA – кілька слів пояснення
Угода про рівень обслуговування (у значенні ІТ) — це угода про підтримку та систематичне вдосконалення реалізованої програми. Підписуємо в будь-який час. На початку проекту, під час його реалізації і навіть після закінчення терміну. Траплялося, що eVolpe обслуговував системи, створені іншими організаціями. Однак важливо встановити певні правила. Тоді ти точно знаєш, кому це належить і в який момент вимагає реакції.
Чи знаєш ти, що…
Все, що ми виробляємо на етапі реалізації, є твоєю власністю і ти маєш повне право вільно розпоряджатися придбаним інструментом.
Як виглядає співпраця в рамках сервісу?
Розробка системи як частини веб-сайту дуже схожа на проект впровадження. Ми все ще працюємо в Scrum і базуємося на проблемах, повідомлених у системі Redmine. Ми погоджуємося на час і ресурси, витрачені на обробку запитів. Різниця полягає в частоті таких ситуацій.
У проектах Sprint переганяє Sprint. Backlog продукту повний нагальних проблем. Інкременти системи виникають динамічно і видаються циклічно кожні 2 тижні. Багато чого відбувається.
У фазі обслуговування набагато спокійніше. Ми готові надати технічну підтримку, консультації з обслуговування та адміністрування. Ми виправляємо помилки, коли функція не працює належним чином. Ми також виконуємо «спецзамовлення», які надихнули на життя і роботу в системі.
Години для використання
Зазвичай ми організовуємо пакет годин для реалізації. Гарантуємо бойову готовність. Ми резервуємо для цього час наших розробників. Ефективне управління ресурсами залежить від тебе. Для цього ти можеш довірити нам будь-які завдання, і в такому обсязі, який дозволить сума годин до вичерпання за місяць.
Звичайно, кожне питання підлягає попередній оцінці. Інформація про витрати часу завжди прозора. Тож ти можеш жонглювати пріоритетами, щоб залишатися в пакеті або не створювати невикористаних годин.
Як справи з кросовером?
Однак не завжди ми працюємо за заздалегідь визначеним планом.
Звичайно, найпростіший спосіб – це передати на сайт створені раніше #приємно мати проблеми. Здобута таким чином система продовжує розвиватися.
Іноді, правда, такий список перевіряється життям. Є питання, які раптово поспішають швидше або з’являються «нізвідки» у відповідь на несподівану ділову ситуацію.
Звичайно, ми тут, щоб зустріти цей виклик.
Wrzelki – це природна річ у бізнесі. На щастя, діючи в Scrum, ми вміємо швидко адаптуватися до змінених умов і нових домовленостей.
Будь ласка, запам’ятайте одну річ. Іноді те, що виглядає тривіально, вимагає комплексної перевірки на сервері.
Trafiłem zresztą niedawno na taki oto obrazujący tę kwestię diagram. 👇
Alex Xu, autor grafiki, w swoim poście na LinkedIn celnie zauważa, że najzwyklejsze powiadomienie w systemie wymaga współpracy nawet kilku obszarów. I chociaż chodzi Ci tylko o “małe wyskakujące okienko” – mechanika takiego procesu najpewniej jest bardzo złożona.
Kiedy rozpoczniemy współpracę serwisową, nie krępuj się więc generować pomysłów na nowe usprawnienia. Z pewnością zadbamy, by zostały odpowiednio przemyślane.
A jeśli przypomni Ci się powyższy diagram, tym łatwiej porozumiemy się w sprawie terminu realizacji. Każdorazowo i koniecznie — w ramach ustalonego pakietu godzin.
Виправлення помилок
Na koniec kontrowersja.
Баги в ІТ-системах – досить незручна тема. Тим не менш, він поширений, тому я вирішив його взяти.
Навіть найміцніші інструменти час від часу ламаються. З програмним забезпеченням справа не відрізняється. З програмним забезпеченням справа не відрізняється. Адже їх роблять люди. І вони не безпомилкові.
Втім, можна спокійно спати. Якщо помилку у вашій системі спричинив eVolpe, її, безсумнівно, буде ефективно «відремонтовано».
Сервісний договір eVolpe (у стандартній редакції) передбачає усунення критичних помилок протягом 1 робочого дня (24 години з моменту повідомлення), а інших помилок – протягом 5 робочих днів.
Чи знаєш ти, що…
Критична помилка визначається як недоліки, відхилення або невідповідності у запатентованих елементах програмного забезпечення, які заважають користувачам виконувати свої обов’язки, наприклад, раптова неможливість увійти.
Некритичні помилки істотно не впливають на поточне використання програмного забезпечення та можуть бути усунені пізніше.
Staramy się oczywiście reagować jak najszybciej. Twoje zgłoszenie uruchamia u nas lawinę kolejnych zdarzeń. Będziemy się uwijać, żeby dostarczyć efektywne i natychmiastowe wsparcie dla dotkniętych bugiem użytkowników.
Przy okazji (i nie tylko w przypadku bugów) stosujemy się do zasad HyperCare. To typowa dla serwisu w eVolpe technika współpracy.
Czasami naprawdę wystarczy telefon do jednego z naszych programistów. Michał, Dawid czy Marek na pewno przeprowadzi Cię przez proces tak, by w miarę możliwości wszystko od razu wróciło do normy.
Сервіс та розробка ІТ-систем – резюме
Serwis systemów IT to jeden z filarów oferty eVolpe. Bardzo dobrze zdajemy sobie sprawę z istotności wsparcia udzielanego Ci po zakończonej fazie prac deweloperskich. Nawet po tzw. starcie produkcyjnym systemu pozostajemy do Twojej dyspozycji.
Nasi specjaliści udzielą Ci pomocy na wypadek problemów technicznych czy administracyjnych. Pomożemy z konfiguracją dostępów dla nowego pracownika. Udzielimy też konsultacji na wypadek trudności w obsłudze nierozpoznanego obszaru systemu.
Ти хочеш знати більше? Запишися на індивідуальну консультацію. Я залишаю попередній перегляд свого календаря. Використай то!
Зареєструйся на консультацію з експертами по впровадженню eVolpe
- Чому польським підприємцям подобаються IT On-Premise системи? - 24 Вересня 2024
- Чи є низький код і відсутність коду лише варіаціями на одну тему? - 13 Березня 2023
- Чи система no-code не позбавить програмістів роботи ? - 1 Березня 2023