On heinäkuun 20. päivä 1969. Yli 600 miljoonaa katsojaa jännittää televisioidensa ääressä, kun Neil Armstrong ja Buzz Aldrin aloittavat laskeutumisen kuuhun. Noin kilometrin korkeudessa tutka käynnistyy. Silloin tietokone hälyttää. Seuraa 15 pitkää sekuntia, kun Houstonissa yritetään päästä tilanteen tasalle.
Tietokoneen ohjelmisto on kirjoitettu Cambridgessa sijaitsevassa Massachusetts Institute of Technologyssa eli MIT:ssa. Lentoa seuraavat ohjelmoijat huomaavat kaikkien televisiokatsojien tavoin virheen, mutta eivät ymmärrä sen syytä. Jokin kuormittaa tietokonetta. Ryhmä pohtii, pitääkö laskeutuminen keskeyttää.
Pian tietokone hälyttää uudelleen, nyt useaan kertaan. Tietokoneen näyttö pimenee kerran. Ja toisenkin. Vaikka näyttö on pois päältä vain muutaman sekunnin, Armstrongin pulssi kohoaa 150:een.
Armstrong vaihtaa käsiohjaukseen. Hän säilyttää hermonsa ja laskeutuu onnistuneesti. Ylimääräistä polttoainetta jää vain muutaman sekunnin polton verran. Kukaan ei vielä tiedä, estääkö ohjelmisto-ongelma kuumoduulin pääsyn takaisin kiertoradalle.
George Silver kuuluu MIT:n koodariryhmään. Hän tajuaa nähneensä virheen aikaisemminkin. Silverin havainnon avulla ohjelmistotiimi saa varmistuksen siitä, että tietokone toimii kuten on tarkoitettu, eikä tutkajärjestelmässä oleva virhe estä lentämistä. Houstonissa huokaistaan helpotuksesta. Armstrong ja Aldrin voivat palata kotiin.
MIT:n kehittämä järjestelmä oli lopulta Apollo-ohjelmalle korvaamaton, vaikka sana ohjelmisto mainitaankin vain kaksi kertaa alkuperäisessä Apollo-ohjelman kuvauksessa. Koodin kirjoittamiseen vaadittavaa työtä ei ollut alunperin lainkaan mukana aikataulussa tai budjetissa.
Vähäisenä pidetty tehtävä oli ulkoistettu yliopiston hoidettavaksi. MIT:n nörttien piti suunnitella tietokone, joka mahtuisi matkalaukkuun. Ennen Apolloa pienimmätkin tietokoneet vaativat huoneen verran tilaa. Ohjelmoijat joutuivat kehittämään lukuisia perusrutiineja, jotka nykyohjelmoijat pitävät itsestäänselvyyksinä.
Apollo-ohjelma työllisti yli 400 000 henkilöä, eikä avaruuslentoihin erikoistuneita osaajia ollut tarjolla. Siksi töihin haalittiin kaikenlaisia touhukkaita. Esimerkiksi 23-vuotias Don Eyles ei kelvannut vakuutusyhtiölle töihin, mutta pääsi saman tien avaruusohjelmaan, vaikka ei ollut koskaan kirjoittanut riviäkään koodia. Eylesistä tuli yksi Apollo-ohjelman tärkeimmistä ohjelmoijista.
Ensimmäistä kuulentoa kiusannut ja ensin virheeksi luultu ominaisuus on nykyisistä käyttöjärjestelmistä tuttu. Jos tärkeät tehtävät vievät paljon laskentatehoa, vähäpätöiset rutiinit laitetaan jonoon odottamaan. Tämä ominaisuus suunniteltiin myös Apollon koodiin, koska tietokoneen kapasiteetti oli mitätön tehtävään nähden ja laskennan jumittaminen haluttiin välttää. Kuumoduulin tietokoneen muistiin mahtui tietomäärä, joka vastaa puolikasta yhdestä nykyajan sähköpostiviestistä.
Varsinainen ongelman aiheuttaja oli tutka, jonka järjestelmät saivat sähkönsä eri lähteistä. Sähkötaajuudet eivät olleet synkronissa, minkä vuoksi tietokone tulkitsi tutkalta saaneensa signaalin väärin ja pyysi uutta vastausta 6 400 kertaa sekunnissa. Se ylikuormitti järjestelmän ja aiheutti Armstrongin näkemän virheen.
Apollon ohjausjärjestelmä ei mennyt tyystin jumiin ongelman takia. Se priorisoi laskeutumislaskennan tärkeämmäksi kuin Armstrongin näyttöpäätteen, aivan kuten oli tarkoitettukin.
Apollo-lennon tarinassa on monta seikkaa, jotka palveluiden pilotoija voi kopioida projektiinsa:
- Mahdottomasta mahdotonta. Presidentti John F. Kennedyn puhe siivitti amerikkalaiset suoritukseen, joka näytti 1960-luvun alussa täysin mahdottomalta. Hyvä ja konkreettinen tavoite asetti suunnan Apollo-ohjelmalle. Markkinoita mullistava hittipalvelusi tarvitsee vastaavanlaisen innostavan maalin.
- Tilaa uusille innovaatioille. Ohjelmistoja ei pidetty avaruusohjelman merkittävänä osana, mutta matkan varrella niistä kasvoi sellainen. Ilman tietokonetta laskeutumisen onnistuminen ei todennäköisesti olisi onnistunut. Myös palvelukehityksen aikana ilmenee yllättäviä tarpeita, joiden täyttämiseen tarvitaan kekseliäitä keinoja ja joustavuutta.
- Harjoitus tekee mestarin. Laskeutumista simuloitiin lukemattomia kertoja ja Apollo-ohjelman alkutaipaleita vaivanneet ongelmat saatiin ratkaistua. Koemyynti ja pilotointi ovat vastaavia keinojasi, jolla valmistat palvelusi varsinaiseen tavoitteeseen eli kannattavaan tuotantoon.
- Nopea palaute ja reagointi ongelmatilanteessa. Astronautit ja taustajoukot tottuivat ratkomaan ongelmia ja toimivat tehokkaasti yhdessä, kun oikean kuumatkan aika koitti. Lentoa ei tarvinnut keskeyttää yksittäisen virheilmoituksen takia, vaan vaikutukset osattiin arvioida pikaisesti. Palvelukehityksesi tavoite- ja ohjausmallilla on sama tehtävä.
- Huipputiimi, joka ratkaisee ensi vaiheen ongelmat. Vaikka lentoa simuloitiin lukemattomia kertoja, tarjosi tositilanne useita yllätyksiä. Kokemus auttoi ratkaisemaan mahdottomiltakin tuntuneet ongelmat. Vakaviin teknisiin ongelmiin keskeytyneen Apollo 13 -kuulennon astronauttien tuominen elossa kotiin on tästä hyvä esimerkki. Vaikka palvelupilotoinnissasi eivät olisikaan ihmishenget pelissä, tarvitset silti huippuosaajia, jotka osaavat toimia yllättävissä tilanteissa.
- Suunnitelma B, jos kaikki menee pieleen. NASAlla oli valmiudessa joukko matemaatikkoja takahuoneessa. Heidän avullaan astronautit olisi saatu lennätettyä kotiin, vaikka tietokone olisi pettänyt. Myös palvelukehityksesi henkivakuutukseksi kannattaa pohtia vaihtoehtoinen suunnitelma, jos olettamasi osoittautuvat vääriksi tai olosuhteet ennakoimattomiksi.
NASA:lle ei ollut projektin käynnistysvaiheessa tarjolla valmista ohjetta, joka olisi kertonut miten kuuhun lennetään. Sama pätee pilottiprojektiisi. Ensimmäinen toimitus tuo aina yllätyksiä, mutta hyvällä valmistautumisella voit taklata monta ongelmaa.
Teksti: Antti Apunen: Haastajasta hittipalveluksi
