Näin kilpailutat ketterän julkisen IT-hankkeen

Scrum Diagram (Wikimedia Commons)

Laadi lista asioista joita järjestelmällä pitää voida tehdä

Vaikka ohjelmistoa tehdään ketterin menetelmin tarvitsee toimittajan saada jonkinasteinen kuva siitä miten laajasta projektista on kyse.  Kirjoita lista yksinkertaisia lauseita kuten: ”Kansalainen voi lähettää hakemuksen sähköisesti”, ”Käsittelijä voi tutustua kansalaisen hakemukseen tehdäkseen sen pohjalta päätöksen” tai ”Käsittelijä tekee päätöksen joka lähetetään tiedoksi kansalaiselle”. Listaa lisäksi projektin reunaehdot kuten: ”Kansalaisen on voitava käyttää hakemuksen täyttämiseen yleisimpiä nettiselaimia” tai ”Järjestelmän täytyy täyttää lain asettamat vaatimukset sähköisestä arkistoinnista”. Älä takerru yksityiskohtiin sillä ketterässä kehityksessä vaatimuslista voi muuttua lennossa projektin aikana. Järjestelmän toimittaja tarvitsee listan saadakseen karkean kuvan projektin koosta voidakseen tarjota oikean kokoista tiimiä. Listan pituuden pitäisi olla enintään sata vaatimusta.

Vaadi toimittajaa sitoutumaan ketterään kehitykseen

Vaadi, että toimittaja käyttää yleisesti tunnettua ketterää mallia kuten Scrumia. Vaadi tarjouksen liitteeksi projektiin sidottavien kehittäjien CV:t. Projektilla täytyy myös olla täysipäiväinen Scrum Master. Scrum Masterilla täytyy olla vähintään kaksi vuotta kokemusta Scrum Masterina toimimisesta. Certified Scrum Professional -sertifikaatti on tästä pätevä osoitus. Certified ScrumMaster tai Professional Scrum Master todistaa ainoastaan, että henkilö on käynyt kahden päivän kurssilla. Scrum Master on ketterän kehityksen erityisasiantuntija, joka hallitsee ketterän kehityksen koukerot ja pitää huolen siitä, että ketterät periaatteet eivät ole vain paperilla. Mikäli tulevan tiimin koko on alle neljä henkilöä saattaa olla perusteltua, että Scrum Master ei ole täysipäiväisenä projektissa.

Lisäksi vaadi, että toimittajan lupaamat henkilöt on sidottu vähintään 90%:sti vain sinun projektiisi koko projektin ajan. Mikäli toimittaja haluaa vaihtaa henkilöitä kesken projektin olet oikeutettu saamaan korvaavan henkilön työskenetelmään vähintään ensimmäiset kaksi viikkoa ilmaiseksi. Vaadi myös, että sinulla on oikeus haastatella ja hylätä projektiin siirtyvät henkilöt ilman selittelyjä.

Sitoudu itse ketterään kehitykseen

Varmista omasta organisaatiostasi, että teillä on yksi henkilö joka on vastuussa projektista. Tämän henkilön pitää tuntea ongelma jota ollaan lähdössä ratkaisemaan, sekä hänellä pitää olla päätäntävalta tehdä päivittäisiä linjauksia ilman ohjausryhmiä tai komissioita. Lisäksi tämän henkilön pitää olla valmis viettämään koko projektin aika toimittajan kehittäjien ja Scrum Masterin kanssa samassa tilassa. Jos projektista vastaavalla henkilöllä ei ole aiempaa kokemusta ketterästä kehityksestä on järkevää lähettää hänet Certified Scrum Product Owner-kurssille, jossa ketterän kehityksen perusteet, sekä häneltä vaadittavat asiat tulevat selväksi.

Järjestä kehitystiimille tilat omalta toimistoltanne

Kun halutaan toimia ketterästi tällöin päätöksiä on tehtävä nopeasti ja läheskään kaikkea ei ole dokumentoitu paperille. Tällöin on äärimmäisen tärkeää, että projektista vastaava henkilö istuu kehitystiimin kanssa samassa tilassa. Tämä vähentää merkittävästi kehittäjien kynnystä kysyä epäselvissä tilanteissa, sekä parantaa tiedonkulua omaan organisaationne. Parasta on jos voitte järjestää kehitystiimille oman huoneen omalta toimistoltanne. Tällöin kehitystiimi on lähellä niitä ihmisiä joiden ongelmaa ratkotaan. Tämä helpottaa kysymistä ja kommunikaatiota silloin kun täytyy selvittää jotain niiltä ihmisiltä, jotka järjestelmää oikeasti tulevat käyttämään ja tuntevat nykyiset prosessit. Vaadi myös, että tiimin on myös työskenneltävä tarjoamassanne tilassa, eikä etätöitä sallita. Tiimitilasta ei ole hyötyä, jos kehitystiimi istuu kotona tai omalla toimistollaan.

Suojaa selustasi vaatimalla yksipuolinen irtisanomisoikeus

Vaadi toimittajilta yksipuolinen irtisanomisoikeus ilman perusteita ja sanktioita. Mikäli sinä haluat irtisanoa sopimuksen milloin tahansa koska sinusta tuntuu, että et ole tyyväinen, sinulla on siihen oikeus. Toimittajalla on ketterien menetelmien puolesta velvollisuus esitellä sinulle toimivaa järjestelmää vähintään kerran kuukaudessa. Vaikka tiimi ei voikkaan esitellä sinulle koko järjestelmää ensimmäisen kuukauden jälkeen, voi se esitellä ne ominaisuudet mitä on siihen mennessä saatu aikaan. Mikäli tiimi ei pysty esittelemään toimivaa järjestelmää vähintään kerran kuukaudessa tai yrittää selitellä, että järjestelmää ei voi esitellä ennenkuin se on kokonaan valmis on aika vaihtaa toimittajaa. Myös mikäli tuntuu siltä, että tiimi piilottelee sinulta jotain tai esitellyt versiot ovat toistuvasti niin bugisia, että niitä ei voi käyttää niin tällöinkin on tullut aika vaihtaa toimittajaa.

Älä vaadi tyhmiä asioita

Älä vaadi toimittajalta 10 vuoden kokemusta juuri sellaisten järjestelmien tekemisestä kuin mitä olette tarvitsemassa. Varsinkin jos toimittaja on iso talo niin se voi listata kymmeniä projekteja jotka vastaavat sitä mitä olette haluamassa, mutta kehitystiimissä ei välttämättä ole yhtään henkilöä joka olisi ollut näitä tekemässä. Toisinsanoen ihmiset osaavat asioita eivät yritykset. Älä myöskään vaadi kohtuuttomia liikevaihto vaatimuksia yrityksiltä. Mitä pienempiä yrityksiä olet valmis huolimaan toimittajaksi sitä parempia tarjouksia luultavasti saat. Suuret talot joutuvat pyörittämään suurta koneistoa vaikka sinun näkökulmastasi ainoa oleellinen asia on ne henkilöt joita projektissa tulee työskentelmään.

Kilpailuta tiimin tuntihinta

Koska vaatimusmäärittelyyn ei tuhlata aikaa etukäteen, ei toimittajaa voi vaatia sitoutumaan kiinteisiin hintoihin missään projektin osissa. Ketterässä projektissa sinä kannat käytännössä riskin, jolloin toimittaja voi myös tarjota huomattavasti tiukemman tuntihinnan kuin kiinteähintaisessa projektissa. Tiimi laskuttaa käytänössä tehtyjen tuntien mukaan kaikesta mahdollisesta mitä projektin tekemiseen tarvitaan. Vaadi toimittajalta arviota myös tarvittavista lisenssikustannuksista. Jos projektissa käytetään valmisjärjestelmää tai komponentteja pohjana voivat nämä kustannukset olla merkittäviä. Yleensä lisenssikustannukset tulevat maksettavaksi vasta kun järjestelmä otetaan tuotantokäyttöön. Kehittäjien työkalujen lisenssikustannukset sisältyvät tuntihintaan.

Vältä toimittajaloukku

Vaadi toimittajalta, että projektissa käytetään ainoastaan komponentteja ja valmisjärjestelmiä joihin kaikilla toimittajailla on tasapuolinen pääsy. Toimittajan oma järjestelmä jota käytetään pohjana saattaa kuulostaa houkuttelevalta, mutta aiheuttaa suuria ongelmia mikäli toimittajaa joutuu vaihtamaan. Vaadi siis, että järjestelmässä käytetään ainoastaan kolmannen osapuolen valmiskomponentteja. Jos toimittajan komponentteja kuitenkin käytetään varmista, että sinulla on niiden lähdekoodiin täydet oikeudet, jotta voit siirtää projektin uudelle toimittajalle tarvittaessa.

Pisteytä tarjoukset järkevin perustein

Pisteytä tarjoukset ensisijaisesti CV:iden ja toissijaisesti hinnan perusteella. Kiinnitä erityisesti huomiota kehittäjien kokemukseen ja osaamisen laaja-alaisuuteen. Kokeneet kehittäjät tulevat nopeasti halvemmaksi kuin halvat ja kokemattomat. Älä kuitenkaan anna lisäpisteitä yli viiden vuoden kokemuksesta. Se mitä kehittäjä on tehnyt yli viisi vuotta sitten on jo jokatapauksessa vanhentunutta. Anna sen jälkeen miinus pisteitä tarjouksille mikäli niistä ilmenee seuraavaa:

  1. Toimittaja tarjoaa jotain osakomponenttia kiinteähintaisena
  2. Toimittaja yrittää myydä projektiin mukaan erikseen projektipäällikön
  3. Toimittaja tarjoaa projektiin erikseen vastuullista arkkitehtiä
  4. Tiimin kokoonpano vaihtelee toimittajan suunnitelmissa projektin aikana
  5. Tarjottu Scrum Master on kokematon
  6. Toimittaja esittää vaihtelevan pituisia sprinttejä
  7. Toimittaja ei halua lähettää kehittäjiään sinun toimitiloihisi
  8. Tarjouksessa mainitaan erillinen hyväksymistestausvaihe
  9. Tarjouksessa määritellään sanktioita tai ehtoja toimitussopimuksen purkamiseksi

Hanki osaavaa apua ja varo lakimiehiä

Osta osaamista ketterältä valmentajalta, Agile Coachilta, tai muulta kokeneelta henkilöltä tai yritykseltä, joka ei ole mukana tarjouskilpailussa. Maksamalla muutaman tonnin etukäteen konsultaatiosta säästät helposti paljonkin aikaa ja rahaa projektin myöhemmissä vaiheissa. Mikäli tarvitset lakiosaston apua varmista, että heillä on erityisosaamista ketterästä kehityksestä. Jos organisaation oma lakimies yrittää tehdä vesitiivistä sopimusta hän luultavasti päätyy vaatimaan perinteistä koko projektin kilpailutusta kiinteällä tai tavoite hinnalla, sekä tarkempaa vaatimusmäärittelyä. Etsi tässä tapauksessa toinen lakimies joka ymmärtää ketterän kehityksen päälle eikä vain yritä tehdä asioita niin kuin on aina ennenkin tehty.

It-järjestelmän toteuttavat ihmiset eivätkä yritykset

Tämän päivän Helsingin Sanomissa Karoliina Liimatainen kirjoittaa It-järjestelmien tilaamisen olevan taitolaji. Karoliinan näkemykset avoimista rajapinnoista oikean suuntaisia, mutta keskittyvät väärään ongelmaan valtion ja kuntien it-järjestelmien toimitusongelmista. It-hankintojen tärkemmäksi ydinongelmaksi nimetään kommunikaatio tilaajan ja toimittajan välillä sekä se, että tavoitteita ei ole selkeästi kirjoitettu sopimukseen. Tästä suurimmasta ydinongelmasta kumpuaa suurin virhekäsitys siitä mikä on pielessä it-järjestelmähankinnoissa.

It-järjestelmiä tilataan valtion, kuntien ja yritystenkin puolesta edelleen kuin ne olisivat massatuotettavaa tavaraa jolle määritellään piirrustukset ja sitten kilpailutetaan edullisin rakentaja. Tämä väärinkäsitys kumpuaa oletuksesta, että it-järjestelmä olisi kuin talo jolle määrittelijät tekevät konsultin kanssa piirrustukset ja sen jälkeen on aivan sama kuka sen rakentaa. It-järjestelmä on kuitenkin aina yksilöllinen taideteos jonka lopulliseen muotoon vaikuttavat merkittävästi enemmän sen toteuttavat ihmiset kuin yritys jolta se tilataan. Lisäksi vaatimusmäärittely on aina vajaavainen, koska niitäkin tekevät ihmiset, eikä kukaan yksinkertaisesti voi hahmottaa etukäteen  mikä on oleellista ja mikä ei.

Suurilla tietojärjestelmien toimittajilla kuten Tiedolla, CGI:llä, Fujitsulla, IBM:llä ja Accenturella on organisaatioina kyky vastata raskaisiin tarjouskilpailuihin kuten Liimatainenkin toteaa. Tämä ei kuitenkaan muuta sitä tosiasiaa, että sillä ei ole juurikaan väliä kuka toimittajaksi valitaan jos ei katsota niitä ihmisiä jotka projektissa tulevat työskentelemään. Lopulta it-järjestelmän onnistuminen on eniten kiinni siitä miten taitavat ihmiset sitä saadaan tekemään ja tämä ei koske pelkästään ohjelmoijia vaan koko organisaatiota joka tulee työskentelmään projektissa kuten projektipäälliköitä, arkkitehtejä, käytettävyyssuunnittelijoita ja tiimin vetäjiä.

Tietysti onnistunut projekti vaatii osaamista myös tilaajan puolelta, mutta paljon enemmän on kiinni siitä, että keskitytään tuottamaan toimivia osia pienissä paloissa, jolloin tilaaja voi jatkuvasti arvioida meneekö projekti oikeaan suuntaan. Parhaita tuloksia saataisiin varmasti, jos it-järjestelmiä alettaisiin tilaamaan ketterin perustein. Tällöin tilaaja haastattelisi ja etsisikin parhaat ihmiset toteuttamaan ratkaisuja vaatimuksiin sen sijaan, että yritetään saada projektin taakse mahdollisimman suuri yritys jota voidaan syyttää jos jotain menee pieleen. Tällöin tilaajalla pitää kuitenkin olla oikeus nähdä tiimien tulokset vähintään kuukauden välein ja mahdollisesti katkaista sopimus halutessaan ilman irtisanomisaikaa. Tämä varmistaisi, että toimittaja joutuu sopimuspykäliin tuijottamisen sijasta vakuuttamaan tilaajan joka kuukausi siitä, että projekti menee oikeaan suuntaan ja laadusta ei tingitä. Toimittajan mahdollisesta vaihtamisesta toki aiheutuu hieman hidastumista, mutta jos ohjelmisto on tehty hyvin sen tekijän voi aina vaihtaa. Tämä olisi varmasti myös tilaajan etu.

Hää- ja juhlatilat yhdessä paikassa

Hää- ja juhlatilat yhdessä paikassa juhlat.net

juhlat.net etusivu

Ensivuoden puolella pitäisi järjestää häät ja niitä varten pitäisi löytää sopiva tila. Tämä ei kuitenkaan ole ihan simppeliä, koska kaikki juhlatiloja koskeva informaatio on hajallaan eri vuokraajien sivuilla. Insinöörin aivoillani sitten pusersin perjantain ja lauantain aikana kasaan palvelun, josta juhlatiloja voi etsiä ja suodattaa. Tähän saattoi mennä aavistuksen enemmän aikaa kuin vastaavan excelin pyöräyttämiseen, mutta näin tämä oli kiinnostavampaa. Lista tiloista löytyy siis osoitteesta http://juhlat.net.

Poliittinen kompassi

Parin viimepäivän aikana olen työskennellyt saadakseni aikaan suomalaisen version www.politicalcompass.org:sta. Poliittinen kompassi esittää yleisiä väittämiä monista talouteen ja yleensä vain elämään liittyvistä asioista. Lopputuloksena poliittinen kompassi muodostaa nelikentän, johon henkilö sijoittuu poliittisilta näkemyksiltään. Hienointa tässä on se, että kompassi ei kysele päivän polttavia kysymyksiä, joihin kansanedustajat vastailevat mitä luulevat äänestäjien haluavan kuulla vaan kysymykset kuvastavat enemmänkin henkilön yleistä maailmankuvaa.

Poliittisen kompassin akselit ovat taloudellinen vasemmisto-oikeisto ja sosiaalinen suvaitseva-määräysvaltainen.

Tällähetkellä tilanne on se, että oma versioni pystyy tuottamaan vertailukelpoisia tuloksia yhdysvaltalaisen version kanssa. Kuitenkaan minä en ole politiikan tutkija enkä ole täysin varma kaikista käännöksistä ja käsitteistä. Parhaana esimerkkinä käänsin Liberal-Authoritarian-akselin suvaitseva-määräysvaltaiseksi ilman mitään parempaa tieta. Toivon, että jos tiedät parempia käännöksiä tai sinulla on muita parannusideoita voisit jakaa niitä tämän blogin kommenteissa. Myös kysymysten käännöksissä voi olla asia tai kirjoitusvirheitä, myös näistä toivoisin palautetta ennenkuin alan levittää kompassin facebook versiota ympäriins ja pyydän kansanedustajaehdokkaita vastaamaan kysymyksiin.

Poliittisen kompassin tämän hetkiseen testiversioon voi käydä tutustumassa osoitteessa: http://www.poliittinenkartta.com

Ja koska tämä on pääosin tekniikkablogi niin kerrotakoon vielä, että kyseessä on ensimmäinen Microsoftin pilveen, Azureen, rakentamani sivusto. Kokemuksia tästä tulen varmasti jakamaan kanssanne lähiviikkojen aikana.

EDIT 7.3.2011: Päivitetty linkki uuteen osoitteeseen.

Working with RDLC Reports and object data sources

Yesterday I had to build RDLC report to report stuff based on business objects. I builded a data source that would open session to database, fetch objects, build data contracts and pass them to report as IEnumerable data source. Seemed simple enough I started hacking and soon got the data source ready. Next I created new Report in Visual Studio 2010 and clicked Add dataset… Blam, Visual Studio opens me wizard to create connection to database.

After hours of googling I found out that Visual Studio has a long-lived bug in it. If the project is web project where RDLC file is located, then report data sources  are not refreshed always. There is a work around though. Data sources are often refreshed if you open one .aspx file in the project. More of this bug and its work around can be found from https://connect.microsoft.com/VisualStudio/feedback/details/114670/business-object-website-data-sources-vanish-when-working-with-rdlc?wa=wsignin1.0.

After creating one aspx page to project and opening it I managed to get pass create database connection wizard. At this point next problem appeared. I couldn’t find my method from Available datasets.  My method had simple signature IEnumerable GetData(). After a while thinking and reading MSDN, I realized that the report designer is actually instantiating my class and calling the method to see what types it returns. That would of course fail because SessionFactory wouldn’t exists. To work around that I added try…catch block to the GetData() method and in case of exception returned array with one item. After that and building the project,  data source appeared to report designer.