Ohjelmiston versiohallinta: miten julkaista VÄHEMMIN valituksin

Kyse voi olla versiosta 2 tai versiosta 12 – mutta yleensä mitä monimutkaisemmaksi järjestelmä ajan mittaan muuttuu ja mitä enemmän siihen lisätään ominaisuuksia, sitä todennäköisemmin version julkaisuun liittyy ongelmia.

Ja mitä suuremmaksi käyttäjäkunta kasvaa (useilla laitteilla, käyttöjärjestelmillä, selaimilla – mitä vain), sitä enemmän on mahdollisuuksia käyttäjävirheille, bugeille ja incidenteille julkaisun jälkeen.

Joskus se on väistämätöntä: vaikka tekisimme työtä kuinka ahkerasti ja huolellisesti, emme ole täydellisiä. On kuitenkin suorastaan hämmästyttävää, kuinka moni uuden version julkaisuun liittyvä ongelma voidaan välttää viestimällä käyttäjille yksinkertaisesti ja tehokkaasti.

Ja unohda julkaisutietojen, ”KUUMAT UUDET OMINAISUUDET!” -listojen tai lehdistötiedotteiden lähettäminen sähköpostitse. Puolet näistä viesteistä päätyy suoraan roskapostiin. Loput joko sivuutetaan tai ymmärretään väärin.

Onneksi käyttäjäkunnalle voi viestiä paremmillakin tavoilla ja varmistaa sujuvan siirtymän versioiden välillä – vähemmillä valituksilla ja tukipyynnöillä.

Julkaisun jälkeen käyttäjät valittavat heikentyneestä toiminnallisuudesta – vaikka kaikki ominaisuudet ovat yhä tallella

Merkittävä julkaisu voi olla raskas jo ennen kuin muutokset on hyväksytty ja otettu käyttöön. Mutta kun käyttäjät pääsevät sovellukseen, asiat voivat muuttua sekaviksi.

Joskus toimintoja ja ominaisuuksia siirretään, jotta tilaa saadaan muille, uudemmille tai tärkeämmille ominaisuuksille. Jos et ole viestinyt tästä käyttäjille tehokkaasti, varaudu lukuisiin tukipyyntöihin siitä, miksi ”tuota juttua” ei enää löydy.

Muista: kaikilla ei ole aikaa käydä sähköpostejaan läpi ja lukea versiotietoja. Moni sähköpostijärjestelmä suodattaa automaattiset viestit pois, etenkin nopeatempoisissa ja kriittisissä organisaatioissa. Vaikka automaattinen sähköposti on helppo ja yksinkertainen ratkaisu sinulle, tärkeimmät ihmiset eivät saa tarvitsemaansa tietoa – tai se esitetään surkean tehottomassa muodossa.

Tarvitset ehdottomasti version julkaisutiedot. Mutta tarvitseeko kaikkien lukea ne? Mieti muutamaa tapaa parantaa käyttäjien julkaisukokemusta:

• Lisää kirjautumis- tai aloitusnäyttöön ”uudet ominaisuudet” -ponnahdusikkuna. Pidä se nopeana ja yksinkertaisena, jotta käyttäjät eivät turhaudu.

• Pyydä PR- ja markkinointitiimejäsi laatimaan keskeiset viestit, tai: Kirjoita kuin iltapäivälehti – kerro käyttäjille uusista ominaisuuksista OTSIKKOTASOLLA ja linkitä sitten version täydellisiin julkaisutietoihin. Kokeile lyhyttä ”Mitä uutta versiossa X?” -selitysvideota.

• Viesti useissa kanavissa, ei vain sähköpostitse. Varmista, että kaikissa kanavissa on selkeä viesti, ja linkitä julkaisutietoihin.

• Kirjoita kuin iltapäivälehti – kerro käyttäjille uusista ominaisuuksista OTSIKKOTASOLLA ja linkitä sitten version täydellisiin julkaisutietoihin.

• Kokeile lyhyttä ”Mitä uutta versiossa X?” -selitysvideota.

Pysyäksesi askeleen edellä tarkista foorumeilta muiden julkaisujen yleisiä ongelmia (ei välttämättä omiasi) ja pyri ehkäisemään niissä havaitsemasi ongelmat ennakoivasti.

Voi ei. Tämä ON oikeasti incident!

Incidenttejä tapahtuu, ja ne ovat vakavia. Reagointinopeus on suurin vahvuutesi vakavan incidentin aikana, joten varmista, että olet valmis.

Yhdistä CI/CD-putkesi Jira Service Managementiin (tai muuhun ITSM-alustaan), jotta tiimisi tunnistaa tuotantoympäristöön juuri julkaistut ongelmat nopeammin.

Hyvä järjestys on tässä avainasemassa: luo luokkia useiden attribuuttien avulla, jotta korkean prioriteetin asiat huomataan ensin. Aseta tapahtumakynnykset linkitettyjen incidenttien määrälle ja määritä sitten automaattiset eskalointipolut.

Jira Service Management Service Centre ja Confluence voivat yhdessä nopeuttaa toimintaa ja tukea selkeää viestintää incidentin aikana. Käytä tageja ja avainsanoja tuodaksesi sisältöä esiin ennen kyselyn lähettämistä.

Kun tapahtuu vakava incident, noudatat todennäköisesti vakavien incidenttien prosessia. Osa tästä tapahtuu työnkulussasi ITSM:n sekä dokumentointi- tai yhteistyötilojen välisen automaation ja integraatioiden avulla.

Osa tapahtuu ITSM:n ulkopuolella: resurssien ja suhteiden hallinta.

Ylin johto esittää kysymyksiä. Asiakkaat vaativat vastauksia.

Samaan aikaan kehitystiimisi tekee kovasti töitä incidentin ratkaisemiseksi. Voi olla houkuttelevaa pommittaa heitä tilannekyselyillä, kun saat niitä itsekin. Muista kuitenkin, miten se vaikuttaa heidän keskittymiseensä, tehokkuuteensa ja hyvinvointiinsa.

Ja pidä huolta myös omastasi.

Vakavat häiriöt ovat harvinaisia, mutta niiden sattuessa haluat tietää olevasi valmis rajoittamaan seuraukset.

Onko Jira ja Confluence määritetty käsittelemään vakava häiriö version julkaisun jälkeen?

Palkkaa Atlassian-asiantuntija tehostamaan työnkulkujasi

ClearHub on erikoistunut löytämään maailman parhaat Atlassian-konsultit: heidät on arvioitu, heidän osaamisensa on varmistettu, ja he ovat valmiita valmistamaan DevOps- ja ITSM-alustasi kaikkeen.

Δ