GitLab ja infrakustannukset

Yrityksemme on ollut olemassa jo yli 8 vuotta, tänä aikana kaikki ohjelmistokehityksen ja projektinhallinnan työkalut ovat kehittyneet huimasti. Varsinkin alussa vertailimme ja etsimme parhaita (sopivimpia) työkaluja juuri meidän toimintatapaamme pitäen mielessä kasvun myötä tulevat muuttuvat vaatimukset. Kaiken pitäisi kuitenkin sujua mahdollisimman ketterästi ja toisaalta työkalujen on koko ajan pitänyt mahdollistaa läpinäkyvyys asiakkaalle asti.

Olemme - kuten moni muukin ohjelmistotalo - rakentaneet tärkeimpiä järjestelmiä itse ja investoineet näihin tuhansia ja taas tuhansia tunteja työaikaa. Päädyimme rakentamaan tärkeimmän osan työkalupakistamme itse koska toisistaan irrallisia työkaluja löytyi, mutta selkeää kokonaisuutta niistä oli vaikea rakentaa, eikä yksikään niistä sopinut, tai riittänyt, sellaisenaan.

Tärkein työkaluistamme on Seepra -niminen toiminnanohjaustyökalu, jossa hallitaan projekteja, asiakkaita sekä kirjataan tunnit - aina työtehtäväkohtaisesti ja siten, että ylimääräistä aikaa ei kulu eri järjestelmien käyttöön.

Toiseksi tärkein työkalu meidän toimintamme kannalta on nykyään ehdottomasti GitLab, joka yhdistää ihanasti versiohallinnan, tehtävähallinnan sekä projektinhallinnan ja CI:n (Continuous integration). Käytimme pitkään sisäisesti Mercurialia versionhallintaan ja rakensimme sen ympärille omat työkalut. Meillä oli periaattessa kaikki Gitlabin tuomat ominaisuudet rakennettuna Mercurialin ympärille. Mutta ylläpitokustannukset vain kasvoivat vuosi vuodelta. Siirtymään Mercurialista Git:iin suurin syy olikin se, että Git:n päälle rakennettu työkaluvalikoima on moninkertaisesti kattavampi ja niiden ympärillä on aktiivinen kehittäjäyhteisö.

Ylläpidämme Gitlabista omaa instanssia, koska se on keskeisessä roolissa kaikissa meidän prosesseissa henkilöhallinnosta projektinhallintaan. Gitlabin ylläpito itse ei sinänsä ole valtava kustannus. Jopa päinvastoin. Gitlabin käyttöönoton jälkeen meidän sisäisen työkaluvalikoiman ylläpitokustannukset putosivat murto-osaan entisestä kun pystyimme luopumaan suuresta määrästä itse rakennetuista ja ylläpidetyistä työkaluista. Olemme harkinneet maksullisten lisenssien hankkimista, mutta vielä se ei ole tullut aiheelliseksi. Kasvun myötä tosin se päivä lähenee jatkuvasti.

Ylläpidämme vastaavanlaista ympäristöä myös muutamalle asiakkaallemme ja useilla asiakkailla on pääsy meidän GitLabiin heidän projekteihin. GitLab onkin teknologiastartupille mahtava työkalu sillä se sisältää kaiken tarvittavan yhdessä paketissa. Siitä on helppo lähteä laajentumaan kun vaatimukset kasvavat. Gitlabin ylläpitoon ei välttämättä kannata itse lähteä - varsinkin koska mm. meiltä löytyy intressi pitää omat ympäristömme ajantasalla - samalla pystymme tekemään sen myös asiakkaillemme - järkevällä hinnalla.Kustannustehokkuus ja takaisinmaksuaika Gitlabin käyttöönotolle on ollut selvä: Gitlab on vähentänyt meiltä kehittämisen työkalujen kustannuksia niin selkeästi että emme enää halua takaisin entiseen aikaan ja kymmeniin eri työkaluihin ja niiden ylläpitoon. Olemme jo aloittaneet purkutyöt, ja pala kerrallaan siirrymme tukeutumaan Gitlabiin.

Konteksti vaikuttaa oleellisesti käyttäjäkokemukseen

Vastavirta podcast-sarjan avausjaksossa keskustelimme Haltun UX-suunnittelijan Henri Viitasen kanssa palvelumuotoilusta, käyttöliittymistä sekä käyttäjäkokemuksen suunnittelusta. Keskustelun teemana oli Kirves Sateessa mutta miten se liittyy käyttäjäkokemuksen suunnitteluun ja käyttöliittymiin?

Koodari ja samurai-koodi – kohti koodia parantavaa koodarikoodia

Maailmaa Suomesta käsin tarkastelevan nykykoodarin vinkkelistä satojen vuosien takainen Japani ja sen silloiset soturiyläluokan edustajat saattavat äkkiseltään tuntua kaukaisilta. Tämä on aivan luonnollista, ja aluksi tässä kirjoituksessakin mainitaan joitakin eroja samuraiden ja nykyohjelmistoihmisten välillä.Tämän jälkeen kuitenkin päästään ehkä siihen mielenkiintoisempaan osuuteen – yhtäläisyyksiin. Niitä löytyy melko runsaasti, ja ne luovat pohjaa pohdinnalle siitä, voisiko (länsimainenkin) ohjelmistoteollisuus hyötyä esimerkiksi bushidōn keskeisten ihanteiden soveltamisesta.

Samurai vs. koodiapina: ilmeisiä eroja

Faktana voitaneen pitää, että entisaikojen samuraiden toimintaympäristö ja elämäntapa eittämättä erosivat melkoisesti nykykoodarin oloista. Tässä joitakin esimerkkejä:

  • Ohjelmistoliiketoiminnassa – niin kuin liiketoiminnassa yleisemminkin – raha on melko keskeinen vaikutin, ja samurait tunnetusti halveksivat rahaa eivätkä käsitelleet sitä mielellään. Nykyään ohjelmistotyötä pidetään yleisesti melko hyvin palkattuna, ja osalle koodareista tämä voi toimia motivaattorina hakeutua alalle.
  • Samuraiden elämään epäilemättä kuului stressi siinä kuin koodiorjankin elämään, mutta se syntyi suurelta osin varsin erilaisten vaikuttimien johdosta.
  • Yleensä samurailuokka – kasteista selvästi arvostetuin – mielletään säädyksi, johon ei hevin astuttu ilman asianmukaista syntymäoikeutta (vaikka kaikkina aikoina tämä ei tiukasti pätenytkään). Jonkinlaiseksi koodariksi taas voi nykyään ryhtyä liki kuka tahansa suhteellisen pieninkin ponnistuksin. Osittain tämä saattaa vaikuttaa alentavasti myös ohjelmistoammattilaisten arvostukseen muun yhteiskunnan silmissä, vaikka maailmaa hallitsevia ohjelmistoyrityksiä katsotaankin toisinaan ihaillen.

Niin haluttaessa toimenkuvien yksityiskohtia voisi tietysti kaivella ja tonkia eroavaisuuksien metsästämiseksi melko raa'asti, ja  luonnollisesti jo ajan kulumisesta sekä (etenkin länsimaista koodaria japanilaiseen bushiin vertailtaessa) kulttuurillisista eroista johtuen kaikenlaisia eroja voisi osoitella lisää varsin helposti. Jätettäköön tämä kuitenkin kotitehtäväksi asiasta kiinnostuneille ja pyyhällettäköön eteenpäin.

Yhtäläisyyksiä

Erojen lisäksi tosiaan yhteisiäkin piirteitä löytyy varsin runsaasti. Joitakin tällaisia – ensimmäiseksi mieleen juolahtaneita – avataan lyhyesti seuraavissa kappaleissa, jotka eivät millään muotoa muodosta aiheesta mitenkään kattavaa esitystä, mutta luovat silti pohjaa jatkotarkastelulle.(Tekstin luonteesta johtuen asioita yleistetään ja oiotaan jossain määrin sekä käytetään sanoja melko vapaasti. Blogikirjoituksen tarkoitus tässä tapauksessa on ennemminkin välittää ajatuksia tiettyyn viitekehykseen sitoen kuin kirjoittaa täsmällisesti ja hyvin määritellyillä termeillä tai toimia historiallisena kuvauksena.)

Ammatillinen monipuolisuus

Eri aikakausina samurai-säädyn edustajilta edellytettiin jossain määrin erilaisia asioita, mutta hallittavien taitojen kirjo oli joka tapauksessa suuri. Jo pelkästään toimenkuvan taistelullinen aspekti edellytti jonkinasteista monipuolisuutta. Hallittava asevalikoima oli laaja, ja sōgō bujutsu -koulukunnat (monet varhaiset ryūhat olivat tällaisia) opettivat kamppailua ”kokonaisvaltaisesti”. Taistelutaitojen lisäksi herrasmiessotureilta luonnollisesti edellytettiin esimerkiksi etiketin tuntemista ja taiteiden harrastamista. Edo-kaudella erilaiset byrokraattiset velvollisuudet luonnollisesti toivat omat lisämausteensa vaadittuun osaamiseen.Tyypilliselle liikeyritykselle on tärkeää pitää toiminnan kustannukset siedettävinä, mutta saada silti toimitettua asiakkaille riittävän laadukkaita tuotteita järkevässä aikataulussa pysyen. Lisäksi nykyään softatalolta kuin softatalolta odotetaan varsin laaja-alaista osaamista. Ohjelmistoammattilaisiltakin siis edellytetään monipuolisia taitoja. Matemaattisen logiikan tai yksittäisten ohjelmointikielten tai työkalujen hallinta ei tavanomaisissa olosuhteissa vielä riitä kovinkaan pitkälle, vaan menestyksekkäässä toiminnassa tarvitaan melkoisen ohjelmistotyökaluarsenaalin hallinnan lisäksi myös sosiaalisia taitoja, markkinointikykyä, lakiteknistä osaamista, ympäristön ja trendien seurantaa sekä jatkuvaa mukautumis- ja muuntautumiskykyä.

Harjoitus tekee mestarin?

Kyetäkseen täyttämään velvollisuutensa samurait harjoittelivat ankarasti lapsesta asti asemansa edellyttämiä taitoja. Sen lisäksi, että mestarillisia taitoja arvostettiin, säännöllinen harjoittelu ja taitojen jatkuva hiominen saattoivat myös selkeästi ja konkreettisesti pidentää elinikää.Koodarin on luonnollisesti opeteltava tietyt perustaidot alalle päästäkseen, mutta se ei yleensä riitä, vaan hänenkin on ohjelmistoalan muuttuessa ja kehittyessä huimaa vauhtia jatkuvasti kehitettävä itseään ja opeteltava uusia taitoja pysyäkseen menossa mukana. Toisaalta myös mestarit, jotka ovat hioneet taitonsa yksittäisen aseen – vaikkapa tietyn (enemmän tai vähemmän antiikkisen) ohjelmointikielen – osalta ”täydellisiksi”, saattavat olosuhteiden salliessa löytää paikkansa ja saavuttaa arvostetun aseman.

Vastuu omista ja muiden teoista keskeistä

Samurai vastasi toimistaan feodaaliherralleen ja klaanilleen. Vastuun kantaminen konkretisoitui siten, että virheillä saattoi olla hyvinkin dramaattisia seurauksia niin yksilölle itselleen kuin esimerkiksi sukulaisillekin. Sen lisäksi, että itse pyrki toimimaan asianmukaisesti, oli tärkeää, että myös kaikki, joiden käytöksestä oli vastuussa, tekivät niin.Nykyään ohjelmistotyössä seppukut eivät ole tavanomaisia, mutta kasvojen perinpohjaiseen menettämiseen on kuitenkin hyvät mahdollisuudet, jos tekee työnsä huonosti. Ohjelmistoja rakennetaan monenlaisiin tarpeisiin, ja poikkeamat virheettömästä, spesifikaation mukaisesta toiminnasta saattavat toisinaan olla vaikutuksiltaan hyvinkin kriittisiä. Vaikka koodia ei tuotettaisikaan järjestelmiin, joilla voi laukoa ydinohjuksia, on koodin korkea laatu aina valttikortti.Tuotantoprosessissa ei siis ole suotavaa oikoa, ja jokaisen kontribuoijan tulee asennoitua tuotokseensa asiaankuuluvalla vakavuudella ja olla valmis kantamaan toteutuksestaan implikoituva henkilökohtainen vastuunsa. Kliseisesti tässäkin tapauksessa ketju (järjestelmä) on yhtä vahva kuin sen heikoin lenkki, ja yksittäisten koodarien vastuuntuntoisen suhtautumisen lisäksi laadunvarmistukseen esimerkiksi katselmoinnillisilla menetelmillä, testauksella sekä tarvittaessa ohjelmien oikeiksi todistamisen keinoin tulisi panostaa riittävästi, jotta vastuun kantamisesta yhtiötasolla ei tulisi ongelmaa ja jotta asiakkaille ei aiheutuisi turhaa harmia.

Konventioiden tunteminen tärkeää

Bushien elämässä etiketin ja konventionaalisten toimintatapojen tuntemus oli varsin keskeistä. Hyvät tavat helpottivat elämää, ja etikettivirheet saattoivat hierarkkisessa feodaaliyhteiskunnassa osoittautua toisinaan kohtalokkaiksikin. Taistelukentilläkin totunnaisten menettelytapojen hallitseminen (ja toisinaan kyky poiketa niistä) antoi etua.Esimerkiksi protokollien standardoinnilla pyritään saavuttamaan mm. yhteensopivuusetuja, ja itse ohjelmistotyöhön liittyy runsaasti implisiittisiä oletuksia toimintatavoista, menetelmistä ja työkaluista. Ollakseen vakuuttava ja kyetäkseen toimimaan työssään kitkatta ohjelmistoammattilaisen tuleekin tuntea relevantit standardit, pystyä tarvittaessa noudattamaan niitä ja ”tietää, kuinka asiat tehdään” – tai vähintään kyetä ottamaan tarvittaessa selvää. Hyvät tavat helpottavat toimintaa niin työyhteisössä kuin asiakasrajapinnassakin.

Strategiset ja taktiset taidot

Usein liike-elämässä (softafirmoissakin) johtajistolla on tapana hakea oppia esimerkiksi Sunzin (Sun Tzu) kaltaisilta strategeilta, kuten joukkoja komentaneilla itämaisilla sotalordeillakin aikoinaan. Musashinkin näkemykset sisältynevät monien johtajien vakiolukemistoihin. Vaikka tavanomaisella riviohjelmistokehittäjällä ei usein olekaan valtaisia joukkoja komennettavina, hänkin toki voi hyötyä työssään strategisesta ja taktisesta pelisilmästä sompaillessaan projektinhallinnallisten haasteiden ja asiakassuhteiden hoitamisen parissa – luonnollisesti ottaen etiketin ja moraaliset näkökohdat huomioon.

Koodarin tie

Samuraiden elämää ohjaili (enemmän tai vähemmän ja luonnollisesti aikakauden mukaan eläen) bushidō, mutta aloin miettiä, löytyisikö vastaavaa kunniakoodia ja ohjenuoraa koodareille. Tunnetusti samuraikoodi tiivistyi kasaan perushyveitä, joita on usein pyritty soveltamaan mm. liikkeenjohtoon. Päätin yrittää sovittaa näitä (vapaina käännöksinä ja merkityksiä varsin liberaalisti venyttäen) yhtäältä vielä spesifisemmin ohjelmistoyrityskontekstiin ja toisaalta laajentaa tarkastelua johdosta myös organisaation ruohonjuuritasolle.Julkisuuskuvastaan ja asiakkaidensa hyvinvoinnista kiinnostunut ohjelmistotalo tahtoo varmasti käyttäytyä sidosryhmiään (etenkin asiakkaitaan ja työntekijöitään) kohtaan oikeudenmukaisesti, ja tässä auttaa velvollisuudentunto. Toisinaan – jos ei nyt suoranaisesti kuolemaa uhmaava, niin ainakin lyhyen tähtäimen voitot vaarantava – rohkeus lähteä uusille urille ja tehdä asiat epäkonventionaalisesti saattaa olla ratkaiseva tekijä menestykseen pyrittäessä. Toisaalta myös itsekuria tarvitaan, jottei sorruta järjettömiin ylilyönteihin. Niin liikesuhteiden kukoistuksen kuin henkilöstön hyvinvoinnin kannalta kunnioitus, kohteliaisuus ja tarvittaessa myös myötätunto ja armeliaisuus ovat asiallisen toimijan ominaisuuksia, joiden kautta rakennetaan pohjaa lojaalisuudelle ja ruokitaan sitä. Edelleen rehellisyys ja kunniallisuus auttavat rakentamaan firmalle hyvää imagoa, mutta mikä vielä tärkeämpää, parantavat myös työntekijöiden oloja.Sen lisäksi, että tällaisia avainsanoja kirjataan yhtiön arvodokumentaatioon ja että yhtiötä pyritään johtamaan siten, että se näyttäisi ulkoisesti hyvältä, kaikessa käytännön toiminnassa organisaation kaikilla tasoilla tulisi toteuttaa sanojen henkeä. Yksittäinen koodarikin voi puntaroida toimintaansa melko hyvin mainittujen ominaisuuksien kautta ja näin osaltaan edistää yhtiön kulttuurin (ja lopulta myös ulkoisen imagon) muotoutumista mielekkääseen suuntaan. Osittain tulkinta voi erota yhtiön tasolla tapahtuvasta tulkinnasta – esimerkiksi rohkeutta yksittäinen työntekijä saattaa tarvita kyseenalaistaakseen firmansa huonoja tai kunniattomia käytäntöjä; ellei kissoja saada nostettua pöydille, lojaalisuus työnantajaa tai kanssatyöntekijöitä kohtaan saattaa kärsiä.Mainittuihin  bushidō-arvoihin voisi nykykoodareille – ja toki myös muille ohjelmistoyhtiön työntekijöille ml. johtoportaat – ehkäpä lisätä vielä ainakin informaation jakamisen ja läpinäkyvyyden, koska toimivan kommunikaation roolia ohjelmistotyössä on vaikea ylikorostaa. Lisäksi perinteisestä bushin mielenmaisemasta ja asennoitumisesta voisi koodarin tiehen vielä lainata ainakin tiettyä zenimäistä meditatiivista tyyneyttä ja yleisesti rauhallista tapaa suhtautua asioihin, vaikka yllätyksiä ilmeneekin koko ajan, deadlinet paukkuvat ja deploymentteja pitää suoltaa jatkuvasti. Tämä lienisi mielenterveydellisesti viisasta, vähentäisi huonojen paniikkiratkaisujen määrää  ja auttaisi koodaria panostamaan hyveisiin.Esimerkiksi Yamamoto Tsunetomon Hagakuressaan rummuttamaa näkemystä bushidōn olemuksesta kuoleman ehdottomana valitsemisena voidaan tulkita monella tavalla (ja siitä voidaan olla montaa mieltä). Tähän tarkasteluun saattaa sopia paremmin (musashimaisempi) painotus, jossa oleellista on hyväksyä kuoleman mahdollisuus päättäväisesti. Yritystasolla rohkeutta toimia voi edistää, jos yritys ”elää kuin kuollut”, mutta asia ei ole ihan yksioikoinen, ja yrityksen tulisi muistaa pysyä lojaalina esimerkiksi henkilöstölleen. Yksittäisen työntekijän osalta tilanne on ehkä selkeämpi – ainakin triviaalisti tulkiten; jos koodataan se aktiivisesti mielessä, että jokainen hetki voi olla viimeinen, saattaa huonoja väliaikaisvirityksiä tulla tehtyä vähemmän, dokumentoitua paremmin jne.Monilla reaalimaailman yhtiöillä saattaa olla perimmiltään hyvät tarkoitukset ja jalot päämäärät, mutta eräs jo mainittu seikka häiritsee usein keskeisten (enemmän tai vähemmän teoreettisiksi jäävien) arvojen heijastumista käytäntöön. Tämä seikka on suhtautuminen rahaan. Osittain johtuen toimintaympäristöstä ja yhteiskunnallisista rakenteista rahalla on ihan ymmärrettävästi ohjelmistoliiketoiminnassakin varsin keskeinen rooli. Voittoa ei kuitenkaan tulisi tahkota hinnalla millä hyvänsä, vaan tässäkin pitäisi muistaa itsekuri ja lojaalisuus kaikkia relevantteja sidosryhmiä kohtaan, jotta kunniallisuudesta ja oikeudenmukaisuudesta ei tarvitsisi luopua eikä lipsua.Yhteenvetona vielä todettakoon, että ainakin vapaasti tulkiten monet bushidōn keskeiset hyveet soveltuvat mainiosti ohjailemaan koodarinkin elämää. Toisinaan tällaisia ohjenuoria soisi käytettävän enemmän, koska ihmisten ja organisaatioiden toiminta ei aina ole parhaimmillaan luonnontilaisena.

Älä vaadi vääriä asioita

Näyttääkö käyttöliittymä vaikealta? Onko siinä kohtia, joista koulutuksessa tai käyttöohjeissa on kerrottu "Älä laita tähän mitään" tai "muista käyttää desimaalierottimena pistettä". Törmäsit juuri purkkaratkaisuun!

Purkka-liima-ratkaisut ovat usein sellaisia, että yrityksessä on otettu käyttöön iso (ja kallis) järjestelmä, johon onkin sitten jossain kohtaa haluttu haluamaan ominaisuuksia, joita tulevat käyttämään esim. yrityksen kaikki työntekijät - tai vielä pahempaa - yrityksen asiakkaat.

Oletko nähnyt koskaan varausjärjestelmää, joka tuntuu täysin mahdottomalta käyttää? Tai oletko joutunut merkkaamaan tuntejasi tai matkalaskujasi järjestelmään - ja teet tämän todella harvoin, koska joka kerta kun järjestelmää joudut käyttämään sinulta menee ensin 1-2 tuntia pelkästään järjestelmän käytön opiskelemiseen ja uudelleen täyttämisiin, kun tiedot "mystisesti" katoavat. Jepjep. Näitä riittää.

Miksi esim. varastonhallintasovelluksen pitäisi taipua yhtäkkiä verkkokaupaksi?

En ymmärrä, miksi esim. varastonhallintasovelluksen pitäisi taipua yhtäkkiä verkkokaupaksi? Tai miksi omaisuudenhallintajärjestelmästä tai infran hallintatyökalun pitäisi toimia myös varausjärjestelmänä loppuasiakkaille.Viime aikoina olemme päässeet tutustumaan aiheeseen, kun esimerkiksi venepaikkajärjestelmien puolella halutaan sekä satamien, laiturien ja rantojen 3D-mallit, huoltohistoriat sekä kaikki loppukäyttäjän kannalta tarpeeton.Itse kuvittelisin asiakkaana haluavani tietää (tärkeysjärjestyksessä):

  1. Onko minun veneelleni vapaata ja sopivan kokoista laituripaikkaa vapaana haluamallani alueella

  2. Mitä se maksaa ja voinko maksaa sen just nyt heti?

  3. Mitkä ovat sataman palvelut?

Tsekkaa aiheesta lisää Hämeenlinnan venepaikkaverkkokauppa-artikkelistamme. Mullahan ei tämmöisiä ongelmia veneettömänä miehenä ole, mutta en minä autopaikastakaan halua tietää, miten se on rakennettu ja millaista tekniikkaa lämpötolppa sisältää.Moni tilaaja kuvittelee, että järjestelmien pitää olla yhdestä paikasta hankittuna. Kuvitelma on kuitenkin täysin väärä, suurimmasta osasta järjestelmiä saa nykyisellään vietyä tietoja ulos ja palautettua päivitetyt tiedot takaisin. Suuressa osassa nämä tehdään ns. siirtoajoina. Siirtoajot ovat hyvä tapa viedä tietoa, varsinkin kun se tehdään vain yksisuuntaisesti, näin toimimme aiemmin mm. opiskelija-asuntosäätiöiden varausjärjestelmien kanssa, jolloin aina uuden sopimuksen tultua loimme automaattisesti uuden käyttäjän ja sopimuksen päätyttyä poistimme käyttöoikeudet automaattisesti. Helppoa ja käyttäjäystävällistä. :)

Hämeenlinnan venepaikkaverkkokauppa

Toteutimme Hämeenlinnan kaupungille venepaikkaverkkokaupan. Lue lisää toteutuksesta.

Laskutusta rahoituksella vai ilman?

Isojen kelausten äärellä taas painitaan. Eilen oli hyvä keskustelu Padio Oy:n Jere Vuorion kanssa, aiheena laskurahoitus. Tähän asiaan päästiin teemasta, joka tuntuu nyt toistuvan kaikkien pk-yrittäjien kanssa käydyissä keskusteluissa. Eli kassavirtaongelmat ja kassakriisin välttely.

On ihan hemmetin väärin, että tällaiseen tilanteeseen joudutaan. Sopimukset on tehty, työt on tehty, lasku lähetetty, mutta rahoja ei kuulu. Yleensä syynä tähän ei ole se, etteikö asiakas haluaisi maksaa vaan se, että nämä viivästykset moninkertaistuvat matkalla aina sieltä viimeisimmältä taholta. Jos asiakkaan asiakas ei maksa ajoissa, niin ymmärtäähän sen, että yritykset pyrkivät optimoimaan kassaansa siten, että verot ja palkat saadaan hoidettua.

Miksi yhteiskunta on luonut tällaisen ansan ja mahdollistaa laskurahoitusliiketoiminnan? Miksei niitä laskuja voisi maksaa sopimusten mukaisesti ja järkevässä ajassa? Esim. meidän alalla 90 päivän maksuehto tarkoittaa sitä, että varsinainen työ on tehty joka 4kk ennen kuin rahat tulevat tilille. Välissä on maksettu palkat, alvit ja eläke- yms maksut siitä tehdystä työstä. Ja lyhyemmilläkin maksuehdoilla, esim. 30 päivää + 1-2 viikon myöhässämaksaminenkin on kustannustehokkaassa tekemisessä aika raskasta.

Eli minusta on vähintäänkin reilua, että rahat saadaan tilille eräpäivänä ja toisaalta jos olisi mahdollisuus saada rahat tilille vielä nopeammin, niin alkaahan se kiinnostamaan. Kustannukset näissä palveluissa ovat mielestäni vähintäänkin kohtuulliset, mutta ainoa asia mikä minua koko hommassa arveluttaa on se, miten asiakkaat tähän reagoivat?

Ilkan kanssa kun juteltiin, niin tultiin yhdessä siihen johtopäätökseen, että eihän tähän negatiivisesti voi reagoida, jos kaikki hoitavat tonttinsa, niin kuin on sovittu. Eli tulemme nyt ainakin testaamaan laskurahoitusta yhteistyökumppanimme Talenomin kanssa ja katsotaan miten homma lähtee rullaamaan.

Nämä työkalut raivaavat lisää aikaa oppimiselle

Microsoftin AD-käyttäjähallinnan ollessa suosituin ratkaisu, olemme suunnitelleet työkalumme tukemaan erityisesti Microsoftin-ympäristöjä. Esittelemme kolme eri tuoteratkaisua, jotka mahdollistavat salasanan nollaamisen itsepalveluna. Lue lisää!

Oppitunnin alku venyy ja syy on ihan hölmö

Opettajat ja oppilaat kerääntyvät luokkaan ja käynnistelevät ipadeja ja tietokoneitaan. Oppitunnilla on tarkoitus käyttää yhtä monista sähköisistä työkaluista.Kaikki sujuu hienosti, kunnes tabletti pyytää salasanaa. Kappas, oppilaan salasana on hukassa tai unohtunut. Mikä neuvoksi?

Mikset kehittäisi yhteistyössä?

Videon krediitit kuuluvat Hämeenlinnan kaupungin aktiivisille käyttäjille ja kehittäjille. Olemme vuodesta 2011 alkaen rakentaneet opetussektorille (ja sittemmin myös yritys-/hallintopuolelle) sähköistä työpöytää. Ei siis mitään mitä saisit huonekalukaupasta vaan sellaista pilvityöpöytää, joka yhdistää kaikki käyttämäsi sähköiset palvelut yhden kirjautumisen taakse.

Idea on erittäin yksinkertainen: Kaikki palvelut, joihin sinulla on käyttöoikeus on valittavana omaan räätälöitävissä olevaan näkymään eli työpöytään. Sieltä voi sitten poistaa työkaluja ja niitä voi myös järjestää tarpeen mukaan - ja aina tarvittaessa palata niihin.

Jossain kohdassa käytin tästä vertausta, että tää on vähän niin kuin intranetti, sillä poikkeuksella, että löydät tarvitsemasi palvelut heti. Ajansäästö on merkittävä - ja kun oppitunnin alusta säästyy aikaa säätämiseltä niin jää enemmän aikaa oppimiselle. Se on tärkeintä.

Tämän tuotteen rakentaminen ei ole ollut helppoa - ja lopputulos muistuttaa linkkilistaa, kuten monet usein sanovat. On tarvittu useita ja taas useita uusia versioita, jotta olemme pystyneet vastaamaan käyttäjien tarpeeseen, kuunnelleet useiden satojen eri opettajien ja oppilaiden mielipiteitä ja ottaneet ne huomioon kehityksessä. Olemme lisäksi antaneet käyttäjille täyden vallan päättää, miltä järjestelmä näyttää ja miten se nimetään.

Sittemmin meille on syntynyt kilpailijoita - tai siis oikeammin meille on syntynyt verrokkeja, joita kutsutaan samalla nimellä, mutta joiden kehittämiseen on lähetty ylimalkaisesti juuri sillä "Miten vaikeeta muka tuollainen ruudukko/linkkilista voi olla tehdä". Se on ollut ilmeisen pitkä prosessi ja siitä kunnia ei missään nimessä kuulu meille. Kunnia kuuluu käyttäjille, aktiivisille opettajille ja tvt-asiantuntijoille sekä oppilaille.

Olemme tehneet valtavan pitkään yhteistyötä mm. Kauniaisten Kasavuoren koulun kanssa (täältä kaikki alkoi), Hämeenlinnan kaupungin kanssa (Airo), Kangasalan (Tori) sekä Kuntien Tieran (Edison-oppimisympäristö) kanssa. Ja viimeisimpinä lisäyksinä meillä on Parkano (Kampus) ja Tampere, jolle käyttöönotto on parhaillaan käynnissä. Koko tällä porukalla pitäisikin saada tehtyä entistä enemmän yhteistyötä ja pystyä jakamaan käytäntöjä. Käytäntöjen jakaminen sitten helpottaisi myös muita vastaavia tuotteita kehittäviä tahoja ottamaan huomioon ne hyvät puolet ja ennen kaikkia puutteet ja tarpeet, johon nykyinen toteutus ei vielä vastaa.

Yhdessä tekemiseen onkin jo hyvä alusta olemassa, katso mitä Digikilta tekee. Nykyinen toteutus on tosiaan avointa lähdekoodia ja eri versioita (kuten mm. MPASSid:n demo) on saatavilla suoraan Haltun github-tililtäHaluamme edistää avoimuutta, läpinäkyvyyttä ja yhteistyötä, koska en usko, että olemme paras kumppani jokaiselle asiakkaalle, koska hyvät ratkaisut ja toteutukset vaativat kuitenkin parempaa tuntemusta, luottamusta ja rohkeutta.

Jos olet softafirma ja tarvitse jeesiä palvelun pystyttämiseen, niin ota yhteyttä. Ja jos olet nykyinen tai mahdollisesti tuleva palvelun käyttäjä, niin sovitaan tarkempaa esittelyä. 

Vinkkejä Chatbotin suunnitteluun

Tästä artikkelista saat vinkkejä chatbotin suunnitteluun. Tarjoamme 6 vinkkiä, joita ottaa suunnittelussa huomioon.

Mitä käyttäjä haluaa Chatbotilta?

On helppoa tehdä botti itse. Siihen pystyy kuka tahansa, jolla on perustietämys tietotekniikasta. On vaikeampaa tehdä botti, jota on helppo käyttää, sillä se vaatii jo tietämystä käytettävyydestä, suunnittelutyötä ja toteutuksen.

Chatbotit haltuun

Tähän on varmasti useitakin ratkaisuja, mutta yksi tulevaisuuden suurista asioista on chatbotit. Ne ovat vallanneet maailmaa jo usean vuoden, eikä tällä nyt tarkoiteta mitään robottien vallankumousta, vaan keskustelevaa käyttöliittymää, jossa keskustelun ja vastausvaihtoehtojen avulla ohjataan järjestelmää.