Yrityskenttää nähneenä olen valitettavasti tullut siihen johtopäätökseen, että Suomessa niin isoissa kuin pienissäkin firmoissa ohjelmointia pidetään ei-toivottuna puuhasteluna.
Jos koodia tarvitaankin, niin siitä maksetaan mieluummin ulos vaikka 10 miljoonaa, kuin perustetaan tiimi, jolla voitaisiin toteuttaa homma itse. Mikäli on oikein paniikki, niin otetaan talon harvalukuisista koodareista yksi, joka tekee spaghetin, jolla saadaan tulipalo sammutettua.
Tilanteen mentyä ohi, laitetaan sama kaveri pihalle seuraavissa yyteissä. Kohta ollaan liemessä taas, mutta onpahan joku, jota syyttää kaikesta. Se yksi teki koodin, josta ei kukaan muu ymmärrä, ja lähti jättäen meidät pulaan.
Kuulostaako tutulta?
Tämän takia ainakin sovellustasolla pitäisi suosia kieliä, joissa on vain yksi tapa tehdä asioita. Tällöin esimerkiksi tietorakenteet esiintyvät melko standardinomaisesti.
Torvalds C++:sta:
“It’s made more horrible by the fact that a lot of substandard programmers use it, to the point where it’s much much easier to generate total and utter crap with it. Quite frankly, even if the choice of C were to do nothing but keep the C++ programmers out, that in itself would be a huge reason to use C.”
Sinänsä ihan ymmärrettävää. Hyvin harva firma haluaa johdettavakseen osa-aluetta, johon ei ole omaa kompetenssia. Kysehän ei ole siitä onko henkilöitä jotka osaa koodata, vaan onko osaamista johtaa ja ohjata sitä toimintaa ja mitä riskejä tuosta syntyy liiketoiminnalle. Monesti pienet ohjelmistotarpeet on kuitenkin halvempaa ja tehokkaampaa ostaa avaimet käteen -tyyppisesti ulkoiselta toimijalta, ja voi riskienhallinnan mitigaationa myös reklamoida, jos toimitettu tuote ei vastaa tarpeita tai vaikka sovittu SLA ei täyty ja syntyy taloudellisia tappioita. Ulkoistetussa toiminnassa isoin ongelmasyy on, että yhtiö ei osaa järkevästi ostaa ohjelmistokehitystä, eikä osaa asettaa toiminnalle sellaisia vaatimuksia jotka esimerkiksi suojaisi tuolta mainitsemaltasi "kukaan muu ei ymmärrä" -tilanteelta. Pitäisi vaatia myös dokumentaatio, toiminnalliset kuvaukset ja muu jos tilaajan on tärkeää myös itse ymmärtää ohjelmiston sisäinen toiminta ja vaikka toiminnallinen logiikka.
Näissä ulkoa ostetuissa sovelluksissa/ohjelmistoissa on se hankala puoli, että tuki maksaa niin kauan, kun sovellusta on tarvetta käyttää. Se taas tulee "liian kalliiksi" ja helposti käy niin, että tukisopimus irtisanotaan ja ohjelma säilötään virtuaalihostin syövereihin ajoon parasta toivoen.
En tiedä olisinko sen parempi päättäjä, ja paljon tietysti riippuu firman koostakin. Kuitenkin olisi hyvä olla joku strategia, ja harkita vakavasti, voisiko omalla porukalla tehdä työ omaan ympäristöön sopivaksi. Henkilöstön pitäminen maksaa, mutta maksaako kuitenkaan yhtä paljon kuin tuen saaminen ulkoa? Lisäksi mitään takeita ei ole siitäkään, etteikö ulkoa ostettu sovellus jossain vaiheessa jäisi ilman tukea, eikä millään rahalla saa enää henkilöitä, jotka pystyisivät tekemään asialle jotain. Näin voi käydä, kun ei pääse valvomaan ja auditoimaan, että toimittajalla todella on henkilöitä, jotka pystyvät tukea antamaan. Siinä nukkuu helposti firman hallitus ruususen unta liian pitkään.
Tietoturvapäivityksiin en edes viitsi tässä mennä.
Asiat eivät toki ole helppoja, mutta yleinen linja mietityttää. Voiko tällaisilla eväillä syntyä mitään uutta, jolla nokian poistumisen jälkeen alkanut ikuinen lama saataisiin päättymään? Olisiko tarve nostaa niiden arvostusta, jotka pystyisivät muuta liiketoimintaa tehostamaan, jos vain annettaisiin mahdollisuus?
Tottakai aina se strategia laaditaan, ja se monesti on syynäkin miksei omaa ohjelmistokehitystä harrasteta. Tuotekehittäjien palkkaaminen mm. edellyttää että sitä ohjelmistokehitystä on jatkossakin, kun se puolen vuoden duuni on valmis eikä että kaverit istuu jatkossa tyhjänpanttina.
Ja monilla firmoillahan sitä omaa ohjelmistokehitystä on, kun ovat strategiassaan sellaiseen valintaan päätyneet. Jos omassa yrityksessä oma ohjelmistokehitys olisi kannattavampaa mitä ulkoistettu, asiasta kannattaa tehdä aloite ja esitellä
A.) Rahoitusedut ja taloudellinen hyöty
B.) Johtamismalli ja seuranta
C.) Operatiiviset hyödyt
Ja toki pitää esitellä myös haitat, kuten esim. se että reklamaatio-oikeutta ei ole jos syntynyt tuote ei vastaa haluttua, ei toimi tai että osaaminen loppuu kesken ja tarvitaan joka tapauksessa ulkoista konsultaatiota.
Tietoturva on hyvä esimerkki eduista: Ulkoistamalla tietoturvan saa myös yrityksen hallitukselle hyötyä, koska sopimuksellisesti voidaan vahvistaa mahdollisessa oikeudenkäynnissä, että tietoturvan ylläpito ja SOC oli firman Ab Oy vastuulla ja että heille oli vaatimukset asetettu. Ja Mikäli vuosikellon mukaisessa raportoinnissa esiintyy tietoa että päivityksiä ei olla asennettu tai että 0-day exploitteja ei olla läpikäyty, voidaan jälleen kerran myös reklamoida.
Kyse on kai aika usein suhteellisesta edusta. On yleensä järkevämpää tehdä joitain asioita laadukkaasti ja ulkoistaa muut asiantuntijoille kuin yrittää tehdä itse. Usein ohjelmistoja tehdessä pitää ottaa monta asiaa huomioon ja ohjelmointiyritykset tuntevat (toivottavasti) vaikkapa alaan liittyvät lainsäädännöt, kuten esteettömyysdirektiivit, tietoturvastandardit yms., paremmin kuin ei-ohjelmistokehitysyritykset.
Aatelkaa jos otetaan tähän keskusteluun vielä julkinen sektori mukaan.
Tulee mieleen eräskin apotti joka maksoi 800miljoonaa.
Itse olisin senkin softan tehnyt 10000eurolla, tosin sillä erotuksella että minun softa olisi toiminut.
wy5vn kirjoitti:
Aatelkaa jos otetaan tähän keskusteluun vielä julkinen sektori mukaan.
Tulee mieleen eräskin apotti joka maksoi 800miljoonaa.
Itse olisin senkin softan tehnyt 10000eurolla, tosin sillä erotuksella että minun softa olisi toiminut.
10.000e kuulostaa melko pieneltä, kun itsekin olen tässä väsäillyt pelkkiä keskisuuria webisovelluksia 20.000e:n hintalapuilla.
Plus, muistelisin, ettei Apotissakaan koodaukseen ollut mennyt tuosta budjetista lähellekään isointa osaa, vaan konsulttien palkkioihin. Ja tämä sama näkyy myös ihan työelämässäkin, että budjetista iso osa käytetään määrittelypalavereihin, asiakasviestintään yms. yms.
Eräs työkaveri sanoikin erään projektin lopuksi, jossa suunnittelu jätettiin tekemättä ja jälkikäteen oli korjailtu kaikenlaista, että siinä 4 viikon koodauksella säästettiin se kolmen tunnin suunnitteluun käytettävä aika.