Tärkeimmät käsitteet

Hankemallit ja menetelmät

Ketterä kokeilu

Ketterällä kokeilumallilla pyritään edullisiin käytännön selvityksiin, kuten prototyyppeihin, ennen isompaa hankintaa tai järjestelmään sitoutumista.

Ketterä toteutus

Ketterä toteutusmalli soveltuu erityisesti omaan ohjelmistokehitykseen tilanteessa, jossa markkinoilta ei löydy tarpeeseen sopivaa valmisratkaisua tai tuotetta räätälöitäväksi. Ketterää toteutusmallia voi käyttää myös hankittavaan valmisratkaisuun ja käytössä olevan järjestelmän jatkokehittämiseen.

Perinteinen malli

Perinteinen malli sopii parhaiten sellaisiin hankkeisiin, joista tiedetään tarve ja haluttu lopputulos hyvällä varmuudella jo ennen toimeksiantoa. Perinteisen mallin tehtävänä on varmistaa, että tavoiteltu lopputuotos saadaan aikaiseksi ennalta määriteltyjen reunaehtojen puitteissa. Itse toteutus voidaan tehdä sekä iteratiivisesti että ns. vesiputouksena. Kyseessä on usein laaja investointihanke, jonka koko ja/tai monimutkaisuus vaatii selkeää hankejohtamista ja raportointia.

Kanban-ohjaus

Täysin jatkuva prosessiohjausmalli. Tiimi ottaa jatkuvasyötteisesti uusia ominaisuuksia kehitettäväksi tuoteomistajan priorisoimasta kehitysjonosta, sitä mukaa, kun kaistaa vapautuu. Puhtaassa Kanbanissa ei siis ole sprinttejä. Kanban edellyttää Scrumia vähemmän formaalisuutta esimerkiksi valmiin määritelmän ja käyttäjätarinoiden suhteen. Tuoteomistajan ja kehittäjätiimin kollaboraatio korostuu. Kanban ja kaikki muutkin ketterät menetelmät edellyttävät riittävää kokonaissuunnittelua. Tarkka vaihesuunnittelu ei kuulu Kanbaniin, vaan samaa asiaa hoitaa Kanban-taulu.

Scrum-ohjaus

Iteraatiomalli. Kehittäminen palastellaan 1-4 viikon mittaisiin peräkkäisiin minikokonaisuuksiin, eli sprintteihin. Scrum malli edellyttää Kanban-ohjausta enemmän formaalisuutta, kuten kattavan valmiin määritelmän jokaiselle kehitettävälle ominaisuudelle ja toimivalle tuoteversiolle ja kattavat käyttäjätarinat eli käytännössä ominaisuuskuvaukset. Scrum tuo jämäkkyyttä ominaisuuksien määrittelyyn ja rauhoittaa tiimille riittävän pituiset, mutta silti nopeasykliset kehitysjaksot. Tuoteomistajan ja kehittäjätiimin kollaboraatio korostuu. Scrum ja kaikki muutkin ketterät menetelmät edellyttävät riittävää kokonaissuunnittelua. Tarkka vaihesuunnittelu ei kuulu Scrumiin, vaan samaa asiaa hoitaa sprint backlog.

Perinteinen hankeohjaus

Hankepäällikkövetoinen suunnittelua korostava ohjaustapa. Johto/ohjausryhmä asettaa kokonaistavoitteen. Hankepäällikkö määrittelee tarkat etukäteissuunnitelmat vaiheittain. Vaiheet ovat huomattavasti suurempia ja pidempikestoisia kuin Scrum-ohjauksen sprintit. Sen vuoksi perinteinen ohjaustapa edellyttää vahvaa muutoshallintaa ja tarkemman tason päätöksen tekoa johto/ohjausryhmässä.

Johtaminen ja hahmottaminen

Visio

Kehittämishankkeella on oltava jokin visio, jota lähdetään tutkimaan ja toteuttamaan. Kehityshanketta ei yleensä ole tarkoituksenmukaista käynnistää ilman jonkinlaista visiota tai näkemystä siitä, mitä olisi tarkoitus lähteä tutkimaan, kokeilemaan tai toteuttamaan.

Tiekartta

Hankkeen tiekartta on karkealla tasolla kuvattu hankkeen kulku riippuvuuksineen, se sopii ohjaus-/johtoryhmän käyttöön sekä viestintätyökaluksi sidosryhmille. Tiekartta menetelmälaarissa.

Visiolakana

Visiolakanan avulla kiteytetään selvityksen tai valmistelun aikana hankkeen visio. Visiolakana konkretisoi yhteen kuvaan visiosta tulkitun tarpeen ja ratkaisulinjauksen sekä sen ainutlaatuisen arvon, minkä vuoksi hanke kannattaa tehdä. Visiolakana konkretisoi asiakkaan, eli kenelle ratkaisua tehdään, sekä kertoo, miten käyttäjien palaute otetaan huomioon. Visiolakana myös listaa lyhyesti rajoittavat tekijät ja miten onnistumista mitataan. Visiolakana menetelmälaarissa.

Vaihtoehdot

Kehityshanketta ei tulisi edes kokeilun osalta käynnistää pidemmälle ilman, että erilaisia vaihtoehtoja olisi punnittu. Vaihtoehtojen punnitseminen edellyttää usein markkina-analyysiä, teknologiavaihtoehtojen tarkastelua sekä nykytilan ja tavoitetilan karkeaa määrittelyä. Kokeilun tapauksessa vaihtoehtotarkastelun tulisi kuitenkin olla lähinnä sen tunnistamista, mitä kannattaisi lähteä kokeilemaan. Tähän liittyen suoritetaan riittävä määrä erilaisia kokeiluja. Liian jäykkä ja raskas vaihtoehtotarkastelu voi tehdä kokeilut tarpeettomiksi. Vaihtoehtojen tunnistaminen menetelmälaarissa. Vaihtoehtotarkastelu menetelmälaarissa.

Ratkaisulinjaus

Vaihtoehdoista tehdään johtopäätökset ja valitaan etenemistapa sekä ratkaisulinjaus kehityshankkeelle. Ratkaisulinjaus siis karsii vaihtoehdot periaatteessa yhteen kokeiltavaan tai toteutettavaan vaihtoehtoon.

Hankesuunnitelma

Hankesuunnitelma konkretisoi tiekartan sisällön. Hankesuunnitelman ei ole tarkoitus olla tarkka toteutussuunnitelma. Toteutussuunnitelmat ovat yleensä hankesuunnitelman liitteitä. Itse hankesuunnitelma on kattodokumentti, joka kertoo hankkeen sen hetkisen tavoitteen ja sisällön (laajuus), aikataulun, budjetin, laatuolettaman, ohjaustavan, riippuvuudet ja sidonnaisuudet. Mahdollinen hankintamalli sisällytetään hankesuunnitelmaan. Hankesuunnitelma menetelmälaarissa.

Kehitysjono

Kehitysjono on prioriteetti- ja toteuttamisjärjestyksessä oleva työlista, jonka pohjalta kehitystyö tehdään. Se on lista kaikista järjestelmään tulevista ominaisuuksista, toiminnoista, vaatimuksista, parannuksista ja korjauksista. Lista on prioriteettijärjestyksessä, jotta kehittäjät voivat poimia siitä aina ylimmän tehtävän ja olla samaan aikaan varmoja, että tuottavat työllään palvelun kannalta parasta mahdollista arvoa.  Kehityksen aikana kehitysjonon tehtäviä poimitaan usein näkyville kanban-taululle (ks. Kanban) tai sprint backlogille. Kehitysjonon lisäksi on tärkeää pitää silmällä edistymistä suhteessa tuotteen kokonaisuuteen. Kehitysjono menetelmälaarissa.

Hankinta

Hankintamalli

Hankintamalli määrittelee hankinnan kohteen (mitä hankitaan), hankinnan vaiheet (milloin hankitaan) ja hankinnan kokonaiskustannuksen eli hankinnan arvon sekä käytettävän hankintamenettelyn. Kun hankinta koskee tietojärjestelmää, hankintamalli määrittelee myös ratkaisun toteuttamistavan sekä ylläpidon järjestämistavan, sekä huomioi järjestelmän elinkaaren. Hankintamallin valinta menetelmälaarissa.

Hankintapäätös ja rahankäyttöpäätös

Hankintapäätös on hankintayksikön viranhaltijan tekemä virallinen päätös hankkia (esimerkiksi hankintajohtaja). Hankintapäätös valmistellaan ja kirjataan yleensä Ahjo-päätöksentekojärjestelmään. Pienhankinnat voidaan joissain tapauksissa tehdä pelkästään Kosti-tilausjärjestelmällä. Hankintapäätöstä valmistellessa on aina syytä konsultoida hankinta-asiantuntijaa ja tarvittaessa myös oikeuspalveluita. Rahankäyttöpäätös tehdään hankkeelle määrärahat myöntäneen viranhaltijan toimesta (esimerkiksi tietohallintopäällikkö). Vasta rahankäyttöpäätös mahdollistaa hankkeelle hankintapäätöksen toimeenpanon. Ilman rahankäyttöpäätöstä hankinnan toimeenpanoa ei ole kohdennettu vuosittaisiin määrärahoihin.

Hankintayksikkö ja Tilaaja

Hankintayksikkö on se toimielin, joka suorittaa hankinnan (esimerkiksi TASO, Hankinnat ja kilpailuttaminen). Tilaaja tarkoittaa käytännössä samaa asiaa, mutta viittaa kyseisestä hankinnasta vastuulliseen viranhaltijaan (esimerkiksi hankintajohtaja).

Toimittaja

Toimittaja on hankinnan toimittava osapuoli eli se yritys, yhteisö tai taho joka toimittaa hankinnan kohteen mukaisen tuotteen tai palvelun.

Arkkitehtuuri

Nykytila ja tavoitetila

Nykytila on ajantasainen kuvaus juuri sillä hetkellä vallitsevaan prosessi-/toimintakenttään, tietojärjestelmiin, tietovarantoihin ja teknologioihin. Tavoitetila kuvaa samasta kokonaisuudesta sen, missä tilassa niiden tulee kehityshankkeen tulosten käyttöönottamisen jälkeen olla. Kokeilun tapauksessa kehityshanke ei välttämättä tavoittele käyttöönottoa, mutta tavoitetila silti tulisi olla harkittuna käyttöönotto silmällä pitäen - ellei sitten kyse ole yleisestä tutkimisesta ilman hyötyvisiota.

Muutostarve

Muutostarve kuvaa käytännössä tavoitetilan ja nykytilan erotuksen. Se on konkreettisesti visualisoitu muutos verrattuna nykytilaan. Muutostarve käsittää muutokset prosesseihin, tietojärjestelmiin, tietovarantoihin ja teknologioihin.

Reunaehdot

Ratkaisulla on aina ulkoa tulevia reunaehtoja, joihin pitää sopeutua. Tärkeimmät reunaehdot tulevat EU-asetuksista, EU-direktiiveistä ja kansallisista laeista. Kokonaisarkkitehtuurilinjaukset rajaavat valittavia teknologioita, tietovarantoja liittyviä järjestelmiä ja prosessimuutoksia. Toimittajahallinta rajaa toimittajakenttää. Ratkaisulle asetetaan yleensä saatavuus- ja suorituskykyreunaehtoja sekä käytettävyysreunaehtoja esimerkiksi liittyen esteettömyyteen. Reunaehdot menetelmälaarissa.

Tietoturva

Arvio tietoturvatasosta

Arvio tietoturvatasosta koostaa yhteen vähimmäisvaatimukset ja noudattamistarpeet muun muassa tiedon julkisuudelle ja salassa pidettävyydelle.

Tietoturvan riskianalyysi

Tietoturvan riskianalyysi tehdään siksi, että olennaisimpiin toimintaan tai järjestelmään kohdistuviin tietoturvaan kohdistuviin uhkiin löydetään kehityksen aikana sopiva hallintakeino. Tietoturvan riskianalyysi menetelmälaarissa.

Tietosuoja

Henkilötieto

Henkilötietoja ovat sellaiset tiedot, joiden perusteella henkilö voidaan tunnistaa joko suoraan tai välillisesti yhdistämällä yksittäinen tieto johonkin toiseen tietoon. Henkilötietoja ovat esimerkiksi nimi, sähköpostiosoite, puhelinnumero, paikannustiedot, henkilötunnus, potilastiedot, IP-osoite ja auton rekisterinumero. Tietosuoja tarkoittaa henkilötietojen suojaamista. 

Henkilötietojen käsittely

Henkilötietojen käsittelyllä tarkoitetaan kaikkia toimia, joita kohdistetaan henkilötietoihin joko automaattista tietojenkäsittelyä käyttäen tai manuaalisesti. Käsittelyä ovat tietojen kerääminen, tallentaminen, järjestäminen, jäsentäminen, säilyttäminen, muokkaaminen tai muuttaminen, haku, kysely, käyttö, tietojen luovuttaminen siirtämällä, levittämällä tai asettamalla ne muutoin saataville, tietojen yhdistäminen, rajoittaminen, poistaminen ja tuhoaminen. Myös pelkkä tietojen katselu on niiden käsittelyä.

Tietosuojan alkukartoitus

Alkukartoitus tulee tehdä aina, kun ryhdytään suunnittelemaan uutta prosessia, järjestelmähankintaa tai järjestelmän rakentamista. Alkukartoituksen kysymyksiin vastaamalla selviää, käsitelläänkö uudessa palvelussa henkilötietoja ollenkaan ja jos käsitellään, tuleeko tehdä tietosuojan vaikutustenarviointi vai ottaa tietosuoja huomioon tietosuojan tarkistuslistan avulla.

Tietosuojan vaikutustenarviointi

Tietosuojan vaikutustenarviointi auttaa tunnistamaan ja hallitsemaan henkilötietojen käsittelystä aiheutuvia riskejä. Vaikutustenarvioinnissa arvioidaan henkilötietojen käsittelyn vaikutuksia henkilötietojen suojalle.

Tietosuojan tarkistuslista

Tietosuojan tarkistuslistaa käytetään siinä tapauksessa, että vaikutustenarviointia ei tarvitse tehdä. Tarkistuslistaan on listattu tietosuojavaatimuksia, jotka on aina otettava huomioon kehittämisessä, vaikka ei käsiteltäisi erityisen arkaluonteista tai muutoin riskialtista henkilötietoa.

Tietosuoja- ja salassapitoliite

Henkilötietojen käsittelystä on sovittava silloin, kun joku muu, esimerkiksi palveluntuottaja, käsittelee henkilötietoja kaupungin puolesta. Lähtökohtaisesti sopimisessa käytetään kaupungin tietosuoja- ja salassapitoliitettä, joka sisällytetään sopimuksiin. 

Roolit

Viranhaltija

Kunnallisesta viranhaltijasta annetussa laissa viranhaltijalla tarkoitetaan henkilöä, joka on virkasuhteessa kuntaan. Kuntalain mukaan tehtävää, jossa käytetään julkista valtaa, hoidetaan virkasuhteessa. 

Hankkeen omistaja

Hankkeen omistajalla on viranhaltijan mandaatti ohjata hanketta. Hän hyväksyy, päättää tai vie ylempään päätöksentekoon hankkeen tuloksenteon kannalta tärkeät asiat (esim. sisältöön, kustannuksiin, rahoitukseen, henkilöstö-, materiaali- ja muihin resursseihin liittyvät asiat). Hankkeen omistaja toimii hankkeen johtoryhmän puheenjohtajana. Roolit ja vastuut hankkeissa.

Tuoteomistaja (palvelusta vastaava)

Tuoteomistaja toimii palvelun omistajan ohjauksessa ja huolehtii siitä, että käyttäjien tarpeet on määritelty oikein, lopputulos on näiden vaatimusten mukainen ja tuotantokäytössä täyttyy palvelulta odotettu palvelutaso. Tuoteomistaja priorisoi tuotteen kehitysjonoa ketterässä hankkeessa suoraan.

Hankepäällikkö

Hankepäälliköllä on vastuu ja valtuudet hankkeen päivittäisestä johtamisesta, jotta halutut tuotokset saadaan toteutettua johtoryhmän kanssa sovittujen rajausten puitteissa.

Kokonaisarkkitehti

Kokonaisarkkitehti (kaupunki) / ICT-arkkitehti (toimiala) asettavat kehittämishankkeen raamit suhteessa koko Helsingin ja toimialan toiminta-, tieto- ja tietojärjestelmäkokonaisuuteen.

Ratkaisuarkkitehti

Asettaa ja tarkentaa ylätason hankkeen toteutuksen raamit kokonaisarkkitehtuurin linjauksen mukaisesti ja dokumentoi pääasialliset vaihtoehdot kehityshankkeen mahdollisiksi lähtötilanteiksi yhdessä kokonaisarkkitehdin/ICT-arkkitehdin kanssa.

Tietosuoja- ja tietoturva-asiantuntija

Määrittelee ja tarvittaessa dokumentoi tarvittavan tietoturvallisuuden sekä yksityisyyden suojan tason sekä jatkuvuustarpeen käymällä läpi kohdealueeseen liittyvää lainsäädäntöä, käytäntöjä, prosesseja sekä niissä liikkuvia tietoja.

Hankinta-asiantuntija

Opastaa hanketta hankintalain mukaisen hankinnan valmistelun ja toimeenpanon läpiviennissä.