Kuvaa toiminto ennen tuotteen etsimistä
Määrittele ensin, mitä käyttäjän tai ylläpitäjän pitää pystyä tekemään. Yhteydenottolomake voi tarkoittaa yksinkertaista viestin lähetystä tai useaan vastaanottajaan haarautuvaa kyselyä liitteineen. Näiden tarpeet eroavat toisistaan. Kun käyttötapa on selvä, lisäosia voidaan verrata todelliseen vaatimukseen.
Tarkista myös, löytyykö tarvittava toiminto jo käytössä olevasta kokonaisuudesta. Uusi lisäosa voi tuoda päällekkäisen lomakkeen, välimuistin tai hakukoneasetuksen. Päällekkäisyys vaikeuttaa sitä, mistä asetusta pitää muuttaa ja mikä ohjelma lopulta tuottaa sivun sisällön. Jos tarve on kertaluonteinen, arvioi samalla, tarvitseeko lisäosan jäädä pysyvästi käyttöön.
Määrä ei kerro koko riskiä
Kymmenen pientä, rajattua toimintoa voi kuormittaa sivustoa vähemmän kuin yksi erittäin laaja kokonaisuus. Pelkkä lisäosien lukumäärä ei siis ole luotettava turvallisuuden tai nopeuden mittari. Olennaisempaa on, mitä ne tekevät, missä vaiheessa ne käynnistyvät ja mihin muihin osiin ne vaikuttavat.
Tunnista erityisesti lisäosat, jotka käsittelevät tunnuksia, maksuja, henkilötietoja tai koko sivun rakennetta. Niiden vaihtaminen voi vaatia tavallista tarkempaa valmistelua. Selvitä myös, jääkö sisältö käyttökelpoiseksi lisäosan poistamisen jälkeen. Jos kaikki sivutekstit ovat vain tietyn rakentajan erityisrakenteessa, riippuvuuden merkitys on suurempi kuin pienen käyttöliittymätoiminnon kohdalla.
Tarkista ylläpito ja tuki
Lisäosan ajantasaisuutta arvioitaessa tarkastellaan päivityksiä, yhteensopivuutta ja dokumentaatiota. WordPressin lisäosien hallintaohje muistuttaa muun muassa päivityksistä ja varmuuskopiosta ennen niiden asentamista. Harvoin päivittyvä lisäosa ei ole automaattisesti rikki, mutta epäselvä ylläpitotilanne vaatii selvityksen.
Tuen sisältö on yhtä tärkeä kuin sen olemassaolo. Auttaako tuki vain lisäosan virheissä vai myös oman sivuston yhteensopivuudessa? Onko toiminnon käyttöönotosta riittävä ohje? Yritys voi muuten ostaa lisenssin, jonka lisäksi tarvitaan huomattavasti toteutustyötä. Maksullisuus ei yksin takaa sopivuutta, eikä maksuttomuus tarkoita huonoa laatua.
Laske jatkuvuus mukaan valintaan
Selvitä lisenssin uusiminen, sivustojen määrä ja oikeus käyttää lisäosaa testikopiossa. Tarkista, mitä tapahtuu lisenssin päättyessä: loppuvatko päivitykset, tuki vai myös jokin ulkoinen toiminto? Ehdot vaihtelevat tuotteittain, joten niitä ei pidä päätellä aiemmasta kokemuksesta toisen lisäosan kanssa.
Kirjaa, kuka omistaa lisenssin ja kuka vastaa maksamisesta. Jos lisäosa kuuluu toimittajan yhteiseen lisenssiin, selvitä jatko yhteistyön päättyessä. Sama koskee ulkoisia tunnuksia ja palveluita. Asiakasyrityksen pitää tietää, mitkä osat ovat siirrettävissä ja mitä täytyy hankkia erikseen, jotta sivusto pysyy toiminnassa toimittajan vaihdon jälkeen.
Testaa sivuston oikeassa kokonaisuudessa
Toimittajan esittelysivu näyttää yleensä hallitun esimerkin. Oman teeman, kieliversioiden ja muiden lisäosien yhteensopivuus selviää vasta testissä. Kokeile normaalia käyttötapaa ja virhetilannetta. Lomakkeessa tämä tarkoittaa onnistuneen lähetyksen lisäksi puuttuvaa tietoa, tiedoston rajaa ja vastaanoton tarkistusta.
Tarkastele myös puhelinnäkymää ja ylläpitäjän työtä. Toiminto voi näyttää asiakkaalle hyvältä, mutta olla hankala päivittää. Jos tuotetiedon muuttaminen vaatii joka kerta teknisen henkilön, se vaikuttaa käytön kustannuksiin. Hyväksymiskriteerin pitää siis kattaa sekä asiakkaan että yrityksen päivittäinen toiminta.
Poista käyttämätön lisäosa hallitusti
Ennen poistoa selvitetään, tuottaako lisäosa näkyvää sisältöä, lyhytkoodeja tai taustalla tarvittavaa toimintoa. Pelkkä muistikuva siitä, ettei sitä käytetä, ei riitä. Tee varmuuskopio ja kokeile käytöstä poistamista testikopiossa. Tarkista sivut, joihin lisäosa on voinut vaikuttaa.
Poisto voi jättää asetuksia tai tietoa tietokantaan. Toisaalta lisäosan oma poistotoiminto voi poistaa tietoa pysyvästi. Siksi puhdistusta ei pidä tehdä summittaisesti. Dokumentoi, mitä poistettiin ja mitä jäi tarkoituksella talteen. Näin myöhempi ylläpitäjä ymmärtää ratkaisun eikä asenna samaa riippuvuutta takaisin vain varmuuden vuoksi.
Esimerkki: kaksi ratkaisua yhteydenottoon
Kuvitteellinen pieni palveluyritys tarvitsee nimen, yhteystiedon ja viestin vastaanottavan lomakkeen. Laaja myynnin automaatio voi tarjota paljon enemmän toimintoja, mutta ne eivät välttämättä auta tätä tehtävää. Kevyempi ratkaisu voi olla helpompi ylläpitää, jos viestin vastaanotto, roskapostin torjunta ja saavutettava käyttö on toteutettu hyvin.
Toisella yrityksellä viesti pitää reitittää alueen ja palvelun perusteella useaan tiimiin. Silloin laajempi kokonaisuus voi olla perusteltu. Ratkaisut eivät ole yleisesti parempia tai huonompia, vaan sopivat eri tarpeisiin. Valinta perustuu työnkulkuun ja sen testaamiseen, ei lisäosan markkinoinnin pituuteen.
Mieti myös, miten lisäosasta pääsee myöhemmin eroon
Lisäosa voi tallentaa tietoja tai rakentaa sisältöä tavalla, joka sitoo sen toimittajaan. Ennen valintaa selvitä, mitä tapahtuu käytön päättyessä. Jäävätkö lomakeviestit talteen, voidaanko varaukset viedä toiseen järjestelmään ja näkyvätkö sivujen tekstit edelleen ilman lisäosaa? Nämä kysymykset ovat erityisen tärkeitä, kun toiminnosta tulee osa yrityksen päivittäistä työtä.
Siirrettävyys ei tarkoita vain vientipainikkeen olemassaoloa. Viedyn tiedon pitää olla ymmärrettävässä muodossa ja sisältää jatkon kannalta olennaiset tiedot. Kokeile pienellä, henkilötiedottomalla esimerkkiaineistolla, mitä vienti todella palauttaa. Jos sisältö katoaa käytön loppuessa tai vaatii kalliin uudelleenrakennuksen, tämä kuuluu hankintapäätöksen kokonaiskustannukseen.
Lisenssin omistaja ja maksaja on hyvä erottaa ylläpitäjästä. Yrityksen on tiedettävä, kenen tilillä oikeus lisäosan käyttöön on ja mitä toimittajan vaihto tarkoittaa. Toimiston yhteinen lisenssi voi olla perusteltu ratkaisu, mutta jatkuvuudesta ja mahdollisesta omasta lisenssistä pitää sopia.
Demo ei vielä ole hyväksytty toteutus
Lisäosan esittelysivu näyttää tavallisesti sen onnistuneen perustapauksen. Oman sivuston arvioinnissa testataan myös pitkä teksti, tyhjä tulos, väärä syöte ja tavallinen puhelin. Jos toiminto lähettää viestin, varmista sekä lähetys että vastaanotto hallitussa testissä. Painikkeen painaminen tai onnistumisilmoitus yksin ei todista koko ketjun toimivan.
Ennen kokeilua määritellään, mikä tulos riittää valintaan. Esimerkiksi hakutoiminnon pitää löytää yrityksen oikeat palvelut niiden tavallisilla nimillä, ja hakutuloksista pitää päästä oikealle sivulle. Kaikkien lisäosan tarjoamien ominaisuuksien ei tarvitse olla käytössä. Riittävä, ymmärrettävä kokonaisuus voi olla laajinta vaihtoehtoa parempi.
Valinnan jälkeen dokumentoidaan myös poistettu vaihtoehto ja valinnan syy lyhyesti. Tämä säästää myöhempää selvittelyä, kun samaa asiaa ehdotetaan uudelleen. Tavoitteena ei ole mahdollisimman pieni tai suuri lisäosamäärä, vaan hallittava sivusto, jonka jokaisella toiminnolla on selvä tehtävä ja ylläpitotapa.