Miten kuulentoprojektista tuli menestys?

Kesällä 2024 tulee kuluneeksi 55 vuotta siitä, kun ihminen ensimmäistä kertaa laskeutui kuun pinnalle. Tämän aikaan saaneeseen Apollo-ohjelmaan liittyen muistetaan useimmiten vain joitakin kuvia ja filminpätkiä astronauttien puuhista kuun pinnalla, pieniä askelia ihmiselle mutta valtavia harppauksia ihmiskunnalle. Hieman asioista paremmin perillä oleville monenlaiset kuulentojen vaatimat tekniset ratkaisut ja saavutukset tietotekniikasta materiaalitekniikkaan tulevat myös helposti mieleen. 

Harvemmin kuitenkaan ajatellaan niitä organisaatiohallinnasta ja suunnittelufilosofiasta opittuja seikkoja, joita näin massiivisen projektin läpiviennissä havaittiin. NASA:n  vapaasti ladattavissa olevassa, julkisessa raportissa SP-287, WHAT MADE APOLLO A SUCCESS näitä havaintoja kerättiin ohjelman vielä jatkuessa tulevaisuudessa tehtäviä kuulentoja suunnitteleville neuvoiksi ja huomioitaviksi. Nythän nämä tiedot ovatkin tulleet arvokkaiksi NASAn Artemis-projektin ja siihen liittyvien SpaxceX -hankkeiden läpiviennissä. Ja onhan se mielenkiintoista ja opettavaista luettavaa muutenkin.

Helpottuneita NASAn insinöörejä (mm. Wernher von Braun) onnistuneen Apollo 11:n laukaisun jälkeen (NASA, Public domain, via Wikimedia Commons)

Raportissa esitetyt opit on saatu hyvin erikoislaatuisesta, erittäin vaativasta ja tiukalla aikataululla suoritettavasta projektista, jonka päätavoite oli lentotehtävän onnistunut suorittaminen eikä esimerkiksi maksimaalinen suorituskyky tai kustannussäästöt. Saadut opit eivät kaikilta osin sovi tuleviin kuulentoihinkaan, esimerkiksi lentojen pituuden ja siihen liittyvien pitkäaikaiskestävyyteen ja laitteiden uudelleenkäytettävyyteen liittyvien ongelmien suhteen. Vaikka raportti lisäksi keskittyy monin paikoin teknisiin yksityiskohtiin, on siinä jokaiseen projektin hallintaan sopivia, yleisiä havaintoja, joista varmasti on hyötyä monessa paljon vaatimattomammassakin kehitysprojektissa.

Alla on lueteltu muutamia ydinkohtia menestyksellisen avaruusaluksen kehityksestä tehdyistä yleisistä havainnoista viitedokumentin luvuista 1 ja 2 (toisessa järjestyksessä). Kursivoidut kohdat ovat omia kommenttejani.

1. Jokaisen projektiin osallistujan on oltava tuskallisen tarkka yksityiskohtien huomioinnista ja omistauduttava työnsä hyvin tekemiseen kaikilla organisaation tasoilla ja osastoilla. 
2. Pidä rakenne yksinkertaisena. Avaruusaluksesta puhuttaessa tämä tavoite voi tuntua oudolta, mutta moni ratkaisu Apollossa on tehty ainakin osittain tältä pohjalta; Kaikki osat olivat kertakäyttöisiä ja käyttöiältään lyhyitä, lämpökilpenä toimi passiivinen, hiiltymällä lämpöä sitova ja eristävä rakenne jne.
3. Käytä olemassaolevaa teknologiaa. Jos uutta teknologiaa joudutaan käyttämään, hyväksymismenettelyt ja varasuunnitelma on tehtävä.
4. Käytä hyväksi aiemmin kerättyä kokemusta.
5. Käytä olemassaolevia (turvallisuus)standardeja.
6. Edellytä komponenttien luotettavuutta.
7. Tee rakenteesta redundantti. Jos jokin rakenteen komponentti pettää, jokin toinen rakennekomponentti tai alijärjestelmä pystyy suorittamaan hajonneen komponentin tehtävät. Staattisesti määräämätön rakennetyyppi ja "fail safe"  / "damage tolerant design"-filosofia edustavat tätä ajattelutapaa.
8. Minimoi eri järjestelmien väliset liitynnät. Tällöin eri järjestelmien kehittäjät pystyvät tekemään työtään suhteellisen itsenäisesti.
9. Pidä laitteiden käyttö yksinkertaisena.
10. Automatisoi toistuvat ja yksinkertaiset rutiinit, mutta anna operaattorille työkalut valvoa järjestelmiä, selvittää ongelmatilanteen syyt sekä tarvittaessa ottaa ohjat itselleen tai siirtää ne toimivalle varajärjestelmälle.
11. Tärkein syy Apollo-ohjelman alusten korkeaan luotettavuuteen oli erittäin laaja ja yksityiskohtainen komponenttien ja järjestelmien testaus yhdessä ja erikseen. Nykyään on toki mahdollista suorittaa "virtuaalista testausta" simuloimalla tietokoneilla, mutta simuloinnit eivät koskaan voi ottaa huomioon kaikkia todellisuudessa esiintyviä ilmiöitä. Usein testauksessa löydetään merkittäviä ilmiöitä, joita ei pystytä etukäteen epäilemään tai joita pidetään merkityksettöminä. Lopulliset testaukset jonkin vaativan osan tai laitteen toiminnan varmistamiseksi on joka tapauksessa syytä suorittaa todellisilla prototyypeillä, vaikka kehitystyössä voidaankin testausmäärää huomattavasti vähentää simuloimalla.
12. Muutosten vieminen hallitusti suunnitelmiin ja valmistukseen on projektia aloitettaessa usein unohdettu, mutta tärkeä seikka. Ei ole mitenkään poikkeuksellista, että esimerkiksi laivoissa huomataan asiakkaan, viranomaisen tai analyysien/testien vaatiman ajan vuoksi muutostarpeita myöhään, joskus vasta siinä vaiheessa, kun laivaa jo ollaan rakennettu. Apollo-ohjelmassa myöhään havaitut tai merkittävät muutostarpeet vietiin erillisen työryhmän arvioitavaksi. Tämä työryhmä koostui eri alojen osaajista, jotka tekivät yhdessä päätökset muutosten hyväksymisestä ja tarvittaessa viemisestä suunnitelmiin ja toteutukseen huomioiden kaikkien osapuolten näkökulmat. Samalla pidettiin osapuolet informoituina tilanteesta. Työryhmästä muodostui päätöksentekofoorumi avaruusaluksen kehittäjien ja käyttäjien välille.
13. Suoritetaan vaativa kehitysprojekti useissa askelissa siten, että jokaisella askelella pysytään siedettävällä riskitasolla, mutta samalla kuitenkin saavutetaan riittävästi uutta tietoa ja kokemusta järjestelmän toimivuudesta. Tarvittaessa toistetaan sama askelma kunnes seuraava askel voidaan turvallisesti ottaa. Apollo 11 ei lentänyt kuuhun "kylmiltään", vaan sitä edelsi monta Mercury- Gemini- ja aiempaa Apollolentoa, joissa edettiin järjestelmällisesti kohti lopullista kuulentoa.

SpaceX on sittemmin ottanut varsinkin viimeksi esitettyyn kohtaan osittain toisen lähestymistavan, jossa tarkan suunnittelun ja testauksen avulla hallittavissa olevan suoritusarvojen rajojen laajentamisen sijaan "harpataan askelmien yli" pyrittäessä säästämään aikaa ja kustannuksia. Esimerkiksi keskeneräiselle, kokonaiselle avaruusalukselle suoritetaan testilento jättäen "tyhmiä" testejä tekemättä  käyttäen nk. “build, test, and learn” -filosofiaa, jonka joku vanhan liiton insinööri voisi ehkä happamasti suomentaa ilmaisulla "vauhti korjaa virheet". Harpattaessa kehitysaskelien yli on riski osin hallitsematon, mistä oletetaankin seuraavan jonkin verran epäonnistuneita lentoja ja onnettomuuksia. Mahdollisesti tuhoutuneen lentolaitteen telemetriasta ja muista havainnoista toivotaan sitten saatavan riittävästi tietoja ja oppia saman tai korkeammankin askelen ottamiseen onnistuneesti halvemmalla ja nopeammin kuin perinteisellä insinöörityöllä ja hallituilla askelilla. 

Näyttää vain siltä, että samaa askelta joudutaankin joskus toistamaan useampaan kertaan, eikä säästöjä ajassa tai kustannuksissa ehkä saadakaan. Samalla taivaalla toistuvasti räjähtävien rakettien aiheuttama mainehaitta voi vaikuttaa päätöksentekoon tai tulevien miehistöjen luottamukseen avaruusaluksen toimittajan käyttämien metodien turvallisuudesta. Voikin olla, että riittävän luotettavuustason todentamiseksi edellytetäänkin lopulta enemmän testausta ja analyysiä verrattaessa tilannetta kehitystyöhön, joka tehdään useissa pienemmissä askelissa jo alunperin Apollo-ohjelman tapaan.