Home » Arbeider » System for idrett

System for idrett

Se https://oponentus.wordpress.com

Jeg fikk lån på litt i underkant av 100000 kroner til å starte prosjektet mitt i andre halvår 2005 der idéen var å skape et enkelt nettsted som gjorde at deltakere selv kunne gjennomføre og delta i egne turneringer ved hjelp av epost og et single eliminerings turneringsskjema. Det begynte med at jeg ringte rundt til forskjellige programmeringsselskaper i Oslo og jeg kom etterhvert frem til en dame i 50-60 årene som drev et firma som lå på Vålerenga i Oslo. Vi avtalte et møte og gikk gjennom grunnidéen min. Vi hadde mange møter i perioden 2005-2011: Jeg laget planer, vi diskuterte planene mine, jeg dro hjem og arbeidet videre med dem, hun sendte dem over til programmering i Pakistan, jeg arbeidet med nye planer, vi diskuterte planene, jeg gjorde endringer, hun sendte på nytt til programmering osv. Etter noen år fikk jeg også direkte kontakt med de som satt og programmerte i Pakistan og fra 2010 eller 2011 hadde vi Skype-samtaler der vi diskuterte noen av planene jeg sendte over. Jeg husker ikke nøyaktig når vi fikk direkte kontakt. En av programmererne deres flyttet på et tidspunkt til Norge og bosatte seg i Asker før han senere flyttet til en annen by, og meningen var at han skulle få mer arbeide med prosjektet når tiden var moden. At han kom til Norge var ikke min avgjørelse men jeg godtok at navnet mitt ble brukt som referanse. Det var for tidlig for meg å påta meg noe ansvar utover det jeg hadde.

Prosjektet var først organisert som enkeltpersonforetaket Borge Idrettssystemer som senere ble omdannet til aksjeselskapet Playacup As som etterhvert endret navn til Oponentus As. Det ble inngått avtaler både ved starten av prosjektet, ved støtten fra Innovasjon Norge og senere. Beskrivelsen av systemet i avtalene var ikke helt presis i forhold til slik det utviklet seg men det var uvesentlig. Alle planer innlevert i patentsøknaden var laget av meg og det kan bevises.

Tidlig i prosjektets fase gjorde jeg søk etter forskjellige rating formler vi kunne bruke. Tanken var at spillernes rating skulle oppdateres direkte i det resultatene ble lagt inn. Andre cup management løsninger gjorde det ikke slik. Normalt hadde man gjerne egne rating programmer som måtte oppdateres separat. Jeg tenkte først vi kunne lage en enkel rating metode selv men etter et møte ble vi enige om at vi trengte en anerkjent metode som dekket behovet. Hjemme søkte jeg opp metoder som Elo, Glicko og et par andre formler og vi ble enige om å bruke Glicko i et nytt møte. Dette var krevende programmeringsarbeide som jeg var usikker på om programmererne behersket. Hun mente de gjorde det og de gjorde det.

Jeg var arbeidsledig en periode før 2006 og i 2005 deltok jeg på et etablererkurs gjennom Nav der jeg presenterte grunnidéen min. Det sendte meg videre til et firma i Oslo der jeg fikk en Næringsfaglig vurdering. Prosjektet var lite i utgangspunktet. Meningen var ikke at det skulle bli så stort som det ble. I 2006 eller 2007 sendte jeg inn en søknad til Innovasjon Norge og etter at søknaden ble innvilget mottok prosjektet støtte på 200000 kroner. Dette ga meg både litt angst for å feile og mot og kapasitet til å legge til funksjonalitet. Jeg arvet også noe penger i midten av 2007. Etterhvert som tiden gikk ble systemet mer og mer omfattende. Vi la til funksjonalitet som gjorde det mulig for brukere å ha flere roller som spiller og dommer, og etterhvert en oppgaveliste etter min inspirasjon fra Altinn slik at brukere fikk tildelt forskjellige rapporter ved opprettelse og gjennomføring av turneringer. -Slik at deltagere kunne formidle resultater selv. I tillegg ble det lagt til dommerrapporter og rapporter for å rapportere dommer- og spillerfravær. Jeg la også til funksjonalitet i planene som lot den som opprettet turneringen velge hvilken rolle som skulle formidle resultater.

I begynnelsen var det en enkel turneringsoversikt på forsiden av nettstedet som trengte flere forbedringer før løsningen var brukbar. Det tok meg flere år å komme frem til en oversikt som viste data på en tilfredsstillende måte. Med tiden ble det lagt til funksjonalitet som en aktiv klokke og tidssoner i systemet slik at turneringer kunne registreres uavhengig av sted og tid. Planene inkluderte etterhvert også forskjellige kategorier grupper som bedrifter, klubber, skoler osv. Dette var en del av løsningen som ikke ble 100% ferdig planlagt. Utviklingen og testingen foregikk i en av kategoriene.

Jeg laget planer for registrering av forskjellige kategorier medlemskap som aldersklasser og andre typer medlemskap og inndeling av medlemskap etter tid slik at grupper kunne selge medlemskap med varighet per måned, kvartal og år. Det tok tid å planlegge dette og var mye frem og tilbake før løsningen ble god. Idéen om å gjennomføre turneringer etter tidsskjema ved hjelp av klokken tok flere år å komme frem til og var et resultat av de erfaringene jeg selv hadde gjort meg fra mitt arbeide på et callsenter fra 2006-2008. Og de andre planene jeg hadde laget. Det krevde en aktiv klokke for hver gruppe og forskjellige tidssoner om man skulle gjennomføre turneringer i flere land innenfor samme system. Ikke noe annet turneringssystem hadde noen tilsvarende tilnærming til gjennomføring av turneringer.

I stedet for å fastsette dommere manuelt for turneringer som man gjorde i andre løsninger, ved ringe rundt eller kontakte dommere på andre måter for så å registrere deres påmeldinger manuelt, kom jeg frem til at man heller skulle definere roller av turneringspersonell som skulle delta i turneringen. I tillegg la jeg til et tidsskjema som jeg kalte «turneringsplan» i turneringens registreringsdel: Om en turnering skulle ha dommere bestod turneringsplanen av en påmeldingperiode for dommere, deretter en påmeldingsperiode for spillere (evt. lag) og deretter en spillerperiode. Etter registrering av turneringen var meningen at turneringen skulle gjennomføre seg selv ved hjelp av turneringsplanen (tournament time-schedule som jeg kalte det i den amerikanske patentsøknaden), klokken og deltagerne. Først ved at dommerne fikk tilsendt invitasjoner automatisk, så at dommere logget seg inn med brukernavn og passord for å melde seg på, deretter at påmeldingsperioden for dommere lukket seg, så at påmelding for spillere åpnet seg og at invitasjoner ble sendt ut automatisk til spillere, deretter at spillerne logget seg inn og meldte seg på, så at turneringsskjema ble generert automatisk når påmeldingsperioden for spillere eller maksimalt antall spillere var påmeldt, så at rapporter ble generert til deltageres oppgavelister, og deretter at spillerne eller dommerne selv formidlet resultatene ved hjelp av tildelte rapporter gjennom turneringen. Ingen andre løsninger gjennomførte turneringer på denne måten. Om en turnering skulle gjennomføres uten dommere tilpasset turneringsplanen seg og åpnet påmelding direkte for spillere etter registrering av turneringen.

I begynnelsen hadde systemet en enkel løsning for valg av baner til turneringer som alle andre cup management programmer hadde der man valgte bane fra en nedtrekksmeny. Etterhvert fikk jeg også idéer om å legge legge til baneadministrasjon i samme system noe andre løsninger heller ikke hadde. Det krevde mye planlegging å komme frem til en måte å gjøre det på. Det var ingen andre løsninger jeg kunne hente inspirasjon fra. Etter mye frem og tilbake kom jeg etterhvert frem til at det måtte legges til en egen arenadatabase der man registrerte baner per arena, der hver bane hadde en tilknyttet booking tabell. For at online banebooking skulle fungere i samme system uavhengig av hvor man var i verden var det også behov for å knytte arenaer til klokken og tidssoner. Slik at man kunne være i Norge og booke en bane i et hvilket som helst annet land. Noen land har også flere tidssoner så det var fornuftig å gjøre det sånn. Det tok også en del planlegging å komme frem til at hver arena måtte knyttes til en gruppe, og at gruppeadministrator eller «community manager» som jeg kalte det i løsningen skulle få tildelt forskjellige verktøy for arena administrasjon. I planene la jeg etterhvert til funksjonalitet slik at man kunne se bilder per arena og bane slik at de som skulle reservere bane kunne få opp beskrivende informasjon før de booket.

Det var også behov for funksjonalitet til reservering av baner. Det kunne hende brukere ønsket å reservere strøtimer eller at en gruppe ønsket å reservere baner til en turnering. Jeg kom etterhvert frem til at det burde være forskjellige måter å reservere baner til turneringer på med de tre alternativene «online booking», «request an offer» eller «manuell registrering av banetider». Førstnevnte alternativ var online booking, andre alternativ var for arenaer som ikke hadde en administrator og ikke brukte online banebooking innenfor løsningen, og tredje alternativ var for arenaer som hadde en administrator som ikke hadde aktivert online banebooking der turneringsleder kunne legge til tider for en turnering manuelt. «Request an offer» alternativet gikk ut på at en «tournament director» skulle kunne reservere baner til en turnering uavhengig av om banene benyttet seg av vår løsning. Tanken var at arena-eiere skulle kunne registrere seg i løsningen og bruke vår banebooking løsning, men også at vi skulle kunne registrere arenaer og baner i vår backoffice. Slik at turneringsleder kunne booke baner direkte eller sende en forespørsel til arenaens administrasjon ved hjelp av et eget skjema og epost basert på ønskede spilleperiode i «Tournament plan». Alt hang sammen med alt og det tok lang tid å komme frem til de forskjellige idéene i løsningen som gjerne bygget på hverandre.

I prototypen var det også en egen kolonne på området for valg av turneringspersonell som jeg mener jeg kalte «fee» for beregning av kostnad på turneringspersonell, slik at turneringspersonell som dommere kunne få betalt for kampene og turneringene de dømte i. Prisene på turneringspersonell ble i utgangspunktet satt i løsningens backoffice men dette kunne trengt noe mer arbeide. Dette var også helt unikt med systemet.
Det gjenstod også noe planlegging for hvordan oppgjør skulle håndteres, men det var også en mindre oppgave sammenliknet med arbeidet som allerede var gjort.

Etter at rating modellen ble implementert var tanken at spillerne skulle ha en rating for hver idrett/disiplin. Etterhvert kom jeg frem til at spillerne måtte ha forskjellige typer rating innen hver idrett: En rating per idrett/disiplin i hver gruppe, en nasjonal rating per idrett/disiplin og en internasjonal rating per idrett/disiplin. Årsaken til det var at noen spillere bare ville spille kamper med spillere fra samme gruppe, noen med spillere bare fra samme land og noen med spillere også fra andre land. Jeg er ingen ekspert på statistikk men jeg oppfattet det sånn at rating modellen ikke ville fungere riktig med bare en rating per idrett/disiplin fordi nivået på spillernes rating påvirker utregning av ny rating, og fordi nivå på spillere kan variere mye fra gruppe til gruppe og fra land til land selv om spillerne har samme rating. Å gi spillere flere ratinger innen en idrett/disiplin var også nytt med løsningen.

Tanken var også at spillerne skulle kunne delta i flere idretter i samme system så jeg laget derfor en egen rating oversikt der spillernes rating i flere idretter ble vist. Det skilte seg også fra andre løsninger.

Det tok også tid å utarbeide planer for at det skulle være forskjellige måter å oppnå medlemskap i grupper på: Enten ved betaling av medlemskap, ved søknad til gruppen eller betingelsesløst medlemskap. Under settings ble det lagt til forskjellige valgmuligheter for gruppens administrator som å vise gruppen i en åpen oversikt over grupper eller ikke.

Med tiden ble det også lagt planer slik at Internasjonale forbund skulle kunne administrere sine idretter og nasjonale forbund skulle kunne administrere sine idretter på nasjonalt nivå.
Det tok også tid å finne en god måte å sette pris på lisenser i løsningen. Det ble laget tabeller for inndeling av lisens etter antall medlemmer med mulighet til å sette forskjellige priser for forskjellige kategorier av grupper. Som klubber, bedrifter, hoteller, caféer osv. Tanken var at en klubb med 100 ansatte skulle betale mindre enn en klubb med 1000 ansatte og på tilsvarende måte med bedrifter og andre kategorier grupper.

Planer for lagadministrasjon ble ikke laget men det var også mindre arbeide i forhold til det som allerede var gjort. Et lag ville fungere i løsningen som en spiller bortsett fra at laget trengte funksjoner blant annet for å administrere spillerne. Tidssoner, klokken, baneadministrasjon, banebooking, medlemsadministrasjon, metoden for gjennomføring av turneringer og rating var allerede på plass.

Etterhvert ble det også lagt til en to-trinns innloggingsløsning levert av det kinesiske selskapet Feitian for å gjøre sikkerheten i løsningen bedre.

Nøyaktig rekkefølge på funksjonalitet som ble lagt til kan avvike fra denne beskrivelsen. Hovedpoenget mitt er at det tok mange år å planlegge og utvikle den. Jeg satt ofte lenge oppe på kvelden og sene nattetimer og stod opp tidlig og jobbet med planer i disse årene, droppet ferier og gikk lange turer der jeg ofte tenkte mye over hvordan problemer kunne løses. Selv da jeg gikk for å legge meg og sov gikk tankene av og til til disse planene.

Jeg fullførte ikke utdannelsen min den gang jeg studerte i St. Andrews i Skottland så jeg anså prosjektet mitt som en tilleggsutdannelse. Når jeg ser tilbake på det i dag opplever jeg at jeg lyktes: Det å ha planlagt et system med nye idéer som kan brukes i hele verden. Prosjektet fikk også støtte av Forskningsrådet gjennom Skattefunn-ordningen. Måten jeg ble stoppet på i 2011 var uakseptabel og de som har skapt problemer for meg etter 2011 har begått flere lovbrudd. Men det er lite jeg kan gjøre med det i dag.

Jeg ga bort prosjektet i midten av 2015 og inntil videre står jeg ved det.

( Nettstedet har vært tilknyttet domenenavn som idrettspartner.no, turneringer.no og playacup.com .)