Sovellusten ylläpito- ja tukipalvelu
Jo tuotannossa olevien ohjelmistojen pitäminen toiminnassa teidän SLA-sopimuksenne ja tikettijononne sisällä: luokittelu, korjaukset syyn tasolla, päivitysversiot, riippuvuus- ja alustapäivitykset, tietoturvareagointi ja häiriöiden hoito. Toinen ja kolmas linja kehittäjien toimesta, jotka myös rakentavat, joten toistuva vika korjataan eikä käynnistetä uudelleen.
Miksi tämä on kumppanin ongelma
Tuki on se osa hallinnoitua palvelua, jonka myyminen on helppoa ja miehittäminen vaikeaa. Se saapuu epätasaisesti, se vaatii ihmisiä, jotka osaavat lukea vierasta koodia aikapaineessa, ja heti kun parhaat kehittäjänne laitetaan siihen, he eivät ole enää käytettävissä paremmin tuottavaan työhön. Tavallinen vastaus on erillinen halvempi taso, joka sulkee tikettejä korjaamatta mitään, ja asiakas huomaa sen neljänneksen kuluessa.
Meidän vastauksemme on, että tukea tekevät kehittäjät. He voivat muuttaa järjestelmää eivätkä vain kuvata sitä, mikä on ainoa tapa, jolla toistuva häiriö lakkaa koskaan toistumasta.
Mitä kannamme
Luokittelu ja diagnoosi
Otetaan hoitoon se, mihin ensimmäinen linja ei osaa vastata, toistetaan ongelma ja kerrotaan, mikä oikeasti on vialla, eikä suljeta tikettiä toistumattomana.
Korjaukset, jotka pitävät
Viat korjataan syyn tasolla, ja regressiotesti kirjoitetaan koko bugiluokkaa vasten eikä yhtä tikettiä varten, jotta sama häiriö ei palaa ensi neljänneksellä.
Julkaisut ja päivitykset
Päivitysversiot toimitetaan teidän putkenne kautta teidän muutosprosessinne mukaisesti, ja riippuvuudet, kehysversiot ja alustan ajoympäristöt pidetään ajan tasalla, jotta ne eivät ajaudu päivityskriisiin.
Tietoturvareagointi
Julkaistu tietoturvatiedote jostakin, mistä olette riippuvaisia, on ehdoton syy päivittää, ei backlog-kohta. Seuraamme sitä, päivitämme sen ja kerromme, mikä altistuminen oli.
Valvonta ja häiriöt
Seurataan jo olemassa olevia hälytyksiä, lisätään ne, joiden pitäisi olla, ja hoidetaan häiriöt niin, että jälkikäteen on kirjallinen selostus siitä, mitä tapahtui ja mikä estää toistumisen.
Pienet muutokset
Tasainen virta pieniä parannuksia, jotka pitävät asiakkaan tyytyväisenä eivätkä koskaan oikeuta projektia: hoidetaan samalla kapasiteetilla samoilla ehdoilla.
Teidän SLA-sopimuksenne, rehellisesti arvioituna
Emme julkaise vaste- ja ratkaisutavoitteita, koska luku, joka on keksitty ennen kuin kukaan on nähnyt teidän järjestelmänne, ei ole mitään arvoinen teille eikä asiakkaallenne. Sen sijaan luemme SLA-sopimuksen, jonka olette asiakkaallenne velkaa, kerromme, mitkä osat siitä voimme aidosti kantaa ja mitä kattavuus vaatii, ja sitoudumme sitten siihen kirjallisesti.
Sama koskee virka-ajan ulkopuolista päivystystä. Kun toimeksianto sitä vaatii ja siitä on sovittu etukäteen, se miehitetään ihmisillä, jotka on rekrytoitu tai osoitettu niille tunneille, eikä herättämällä joku ja toivomalla parasta. Pyöritämme jo Euroopan, Australian ja Yhdysvaltain Tyynenmeren aikoja muissa toimeksiannoissa, joten kysymys on siitä, mitä aikaikkunaa tarvitsette, ei siitä, onko se mahdollista.
Sellaisen järjestelmän haltuunotto, jota emme rakentaneet
Mikä on tavallinen tapaus. Tähän mennessä yhdeksän haltuunottoa, vanhin kirjoitettu vuonna 2008.
Ensin vain lukemiseen perustuva katselmus
Saamme pääsyn koodiin, infrastruktuuriin ja tikettihistoriaan ennen kuin olemme vastuussa mistään siitä, ja katsomme sen sijaan, että muuttaisimme.
Kirjallinen riskilista
Mikä on hauras, mikä on päivittämättä, mikä on dokumentoimatta ja mikä herättää jonkun yöllä, järjestettynä tuotantovaikutuksen mukaan. Teidän pidettäväksenne riippumatta siitä, jatkammeko pidemmälle.
Keskustelu kattavuudesta
Luemme SLA-sopimuksen, jonka olette asiakkaallenne velkaa, ja kerromme rehellisesti, mitkä osat voimme kantaa, mitä työaikoja se vaatii ja mitä se maksaa, ennen kuin kumpikaan osapuoli allekirjoittaa mitään.
Luovutus, sitten käyttöön
Määritelty varjostusjakso sen kanssa, jolla tieto nyt on, minkä jälkeen otamme jonon haltuumme. Jos tietoa ei ole enää kenelläkään, aloitamme sen sijaan riskikatselmuksesta.
Teidän nimenne alla, jos se on järjestely
Tuki on yleensä hallinnoidun palvelun näkyvin osa, joten se on myös se paikka, jossa white-label-toiminta merkitsee eniten. Kehittäjämme voivat työskennellä teidän antamienne postilaatikkojen ja tilien kautta, vastata teidän tikettijärjestelmässänne ja kirjoittaa häiriöraportit, jotka välitätte muuttamattomina; asiakkaanne asioi koko ajan teidän kanssanne. White-label-kehitys kertoo, miten se järjestetään, ja se koskee tukea täsmälleen samalla tavalla.
Miten tuki hinnoitellaan
Henkilöä kohden, kuukausihintaan, jotta teidän oma kustannuksenne on ennustettava ja voitte hinnoitella tukisopimuksen asiakkaallenne sen perusteella. Kaikki kirjaavat ajan omaan portaaliimme, näette tunnit koko kuukauden ajan, ja lasku muodostuu samoista luvuista, joten on yksi kirjaus, jota vasten molemmat osapuolet täsmäyttävät.
Kun tuki on uuden kehityksen rinnalla, nämä ovat yleensä yksi toimituspod eikä kaksi sopimusta, jolloin hiljaiset viikot toisella puolella maksavat kiireiset viikot toisella.
Kysymyksiä tukijärjestelyistä
Mitä hallinnoitu sovellusylläpito kattaa?
Tuotannossa jo olevan ohjelmiston pitäminen toimivana: jonoon tulevien asioiden luokittelu, virheiden toistaminen ja korjaaminen, teknisiin kysymyksiin vastaaminen, joihin ensimmäinen taso ei pysty, korjausjulkaisujen toimittaminen, riippuvuuksien ja alustaversioiden pitäminen ajan tasalla, hälytysten seuranta ja häiriöiden hoito, kun jokin hajoaa. Kyse on toisen ja kolmannen tason työstä; teidän ensimmäinen tasonne pysyy paikallaan.
Voitteko toimia SLA-sopimuksemme mukaisesti?
Kyllä. Emme julkaise vaste- ja ratkaisuaikatavoitteita, koska etukäteen keksitty luku, joka ei perustu teidän järjestelmäänne, ei ole minkään arvoinen. Luemme asiakkaallenne jo lupaamanne SLA:n, kerromme rehellisesti, mitkä osat siitä voimme kantaa ja mitä kattavuus edellyttäisi, ja sitoudumme siihen kirjallisesti.
Voitteko tarjota työajan ulkopuolisen kattavuuden tai päivystyksen?
Kyllä. Työajan ulkopuolinen ja päivystyskattavuus sovitaan etukäteen, kirjataan tukiehtoihin ja miehitetään ihmisillä, joiden työajat vastaavat sitä, joten yöllä sattunut häiriö tavoittaa vuorossa olevan eikä herätettyä henkilöä.
Voitteko ylläpitää järjestelmää, jota ette ole rakentaneet?
Se on tavallinen tilanne. Yhdeksän haltuunottoa tähän mennessä, vanhin kirjoitettu vuonna 2008. Perityn järjestelmän ylläpito alkaa vain luku -tilassa tehtävällä katselmuksella ja kirjallisella riskilistalla tuotantovaikutuksen mukaan järjestettynä, joten ensimmäiset viikot käytetään sen ymmärtämiseen, mistä todella vastaatte, eikä arvailuun paineen alla.
Tekevätkö samat ihmiset, jotka ylläpitävät järjestelmää, siihen myös muutoksia?
Kyllä, ja siinä on koko pointti. Ylläpidon kehittäjät ovat kehittäjiä eivätkä erillinen tikettejä sulkeva taso, joten toistuva häiriö voidaan korjata syystä sen sijaan, että se käynnistettäisiin uudelleen joka maanantai. Kun teillä on meillä sekä kehitys- että ylläpitovirta, ne jakavat koodikatselmoinnin ja arkkitehtuuripäätökset.
Miten ylläpito hinnoitellaan?
Henkilöä kohden kuukausittain, jolloin oma kustannuksenne on ennustettavissa ja voitte hinnoitella ylläpitosopimuksen asiakkaallenne sen pohjalta. Tunnit kirjataan portaaliimme ja ovat teidän nähtävissänne koko kuukauden ajan, ja samat luvut tuottavat laskun, joten molemmilla osapuolilla on yksi lähde.
Onko teillä järjestelmiä pidettävänä käynnissä?
Kertokaa meille, mitä järjestelmät ovat, mitä SLA-sopimuksenne lupaa ja missä tuki nyt tökkii. Luemme sen ja kerromme, mitkä osat voimme kantaa, myös ne, joita emme voi.