Ihmisten menoa ja arkea tarkaillessa tuli mieleen eräs hyvin käytännöllinen appsi-idea, jota käytettäisiin puhelimissa (ja miksi ei tableteissakin).
Ainakaan toistaiseksi en vastaavaa ole missään nähnyt.
Nähdäkseni se ei astu millään alueella minkään tekijänoikeuksien alueelle, eli sen suhteen se on vapaa ko. lisärasitteista.
Idean perusraamit ovat karkeissa linjoissaan mielessä, mutta en itse omaa kompetenssiä ohjelman toteutukseen.
Varsinainen appsin ansaintamalli pitäisi vielä saada selkeytettyä potentiaalisti toimivaiksi, latausmaksu vai muutoin rahoitettuna.
Appsin alue koskee liki kaikkien arkea. Kyse on konkeettisesta hyötyappsista, ei hupisellaisesta.
Mitenköhän idean kanssa voisi edetä turvallisesti niin, ettei ideaa puhalleta?
Ainakaan toistaiseksi en vastaavaa ole missään nähnyt.
Nähdäkseni se ei astu millään alueella minkään tekijänoikeuksien alueelle, eli sen suhteen se on vapaa ko. lisärasitteista.
Idean perusraamit ovat karkeissa linjoissaan mielessä, mutta en itse omaa kompetenssiä ohjelman toteutukseen.
Varsinainen appsin ansaintamalli pitäisi vielä saada selkeytettyä potentiaalisti toimivaiksi, latausmaksu vai muutoin rahoitettuna.
Appsin alue koskee liki kaikkien arkea. Kyse on konkeettisesta hyötyappsista, ei hupisellaisesta.
Mitenköhän idean kanssa voisi edetä turvallisesti niin, ettei ideaa puhalleta?
Vastaukset 14
Vanhimmat
https://www.theseus.fi/bitstream/handle/10024/63500/Mobiilisovelluksen kehittamisen vaihtoehdot.pdf?sequence=1
Tuon tyyppisiä juttuja kannattaa lukea.
Aika teknistä ja epäoleellista.
Oleellinen asia tilaajalle on se, että minkälaisia henkilöitä tarvitsee ostaa tekemään ja miten se homma määritellään.
Ainoa oleellisesti huomioitava asia on se, että tekemällä standardilla selaintekniikalla, homma toimii ilman sovelluskauppoja selaimen kautta. Hybridisovellus lähinnä on selainsovellus kääräistynä natiivisovelluksen sisään ja sen voi jakaa sovelluskaupassa, siirtämiset eri laitteille on helppoa.
Natiivisovellus sitten tehdään käyttöliittymä eri alustoille erikseen.
Mutta tämä on vain murto-osa sitä sovellusta. Yleensä sovelluksissa on se palvelinpuoli mihin tietoa tallennetaan, sekä sitten voi olla joku käyttöliittymä esim. raportoinnille tai mitä sovelluksesta saadaan pihalle, ja voi olla hallintapaneeli ohjelmiston ylläpitoon. Esim. jos sovellusta myydään 10000 asiakkaalle ja on sovellus mahdollistaa vaikka jonkun hölmöilyn, voi tarvita hallintapaneelin mistä voi klikata tämän käyttäjän estetyksi vaikka viikoksi.
Tämä on myös sovellus ja se pitää määritellä vaikka se ei asiakkaalle näy.
Yksi olennainen juttu on myös käyttäjän todentaminen. Esim. tämä Suomi24 on sovellus mikä toimii selaintekniikalla, ja tänne kirjaudutaan sisään tunnuksilla. Sovellusta määriteltäessä pitää määrittää miten se todennus tapahtuu. Käytetäänkö esim. Facebook tunnuksia, Gmailia, Microsoft passportia, TUPAS pankkitunnukset vai joku oma todennus kuten Suomi24:ssä on. Ja tälle todennukselle tarvitsee oman palikan sinne palvelimeen mikä pitää määritellä, että mitä halutaan.
Nämä nyt riippuu tietysti ihan siitä, että mitä ollaan tekemässä ja mitä halutaan, ja se on sitä määrittelytyötä mikä pitää tehdä ennen kuin hommia aloitetaan tekemään. Pitää tietää mitä halutaan, se on se olennaisin asia.
1. Tee salassapitosopimus ja hahmottele projektisuunnitelma
Ideointi kun on valmis niin sitten teet salassapitosopimuksen ja hahmottele projektisuunnitelmaa missä järjestyksessä asioita tehdään, hankitaan rahoitusta jne. Tähän voi liittyä yrityksen perustaminen jos ei sellaista ole. Asianajaja auttaa salassapitosopimuksen kanssa.
2. Määrittele sovellus ja sen prosessi tarkkaan.
- Käyttöliittymä pitää piirtää, jokainen nappi ja toiminto pitää esittää siinä mitä tapahtuu mistäkin ja miten näkymä muuttuu
- Sovellus yleensä tallentaa tietoa johonkin. Tee tästä tallennetusta tiedosta esimerkkiä vaikka taulukkolaskentaohjelmalla, sarakkeisiin kentät mitä tietoa ja riveille sitä tietoa. Ja MIHIN se tieto menee (laitteeseen, palvelimeen jne.)
- Sovellus yleensä tulostaa tietoa johonkin tai tekee jotain raporttia. Tee mallikappale minkälainen tieto siitä tulee ulos. Ja MIHIN se tieto sitten lähtee (sähköposti, mobiililaitteen ruudulle, tulostin jne.)
Näitä tallennettavia tietoja, käyttöliittymän näkymiä ja tulostuskohteita voi olla monta ja prosessi voi olla monivaiheinen. Kuvaa tämä käyttöliittymä -> tallennus -> tuloste prosessointi
Jos välissä tulee joku laskettava juttu, että miten jokin numero tai teksti johonkin olisi tarkoitus tallentaa tai tulostaa, tee vaikka taulukkolaskentaohjelmalla mallia. Eli tee sellainen prototyyppi ideallesi (kynä, paperi, taulukkolaskenta, piirrustusohjelma jne.), että onko se mahdollista.
3. Määrittele hyväksymistestit
Määrittele KAIKKI vaatimukset mahdollisimman yksiselitteisesti ja tarkkaan mitä vaaditaan jotta homma toimii (toimintoon kuluva maksimiaika, laitteet joissa pitää toimia, käyttötilanteita, julkaistun version käyttöikä.. ÄLÄ OLETA MITÄÄN. Oletusarvo on se, että se mitä ei ole määritelty, ei vaadita tai sitä ei tule.
Tee kaikesta kirjallinen hyväksymis testi, että kun nappia X painaa niin tulosteeseen pitää tulla Y.
Tai, kun kentässä on A numero enemmän kuin 10 ja painaa nappia X, ohjelma ilmoittaa virheen nönnönnöö.
Tällaisia testejä tulee paljon, ja ohjelman tekeminen kun alkaa, sinun pitää vaatia että ne kirjoitetaan automatisoiduksi testiohjelmaksi jota ajetaan joka välissä.
Ohjelmistokehittäjälle, ohjelma on valmis sitten kun hyväksymis testit menee läpi.
Jos jokin toiminto ei ole tässä huomioitu, siitä tulee lisää laskutettavaa työtä kun kirjoitetaan se testi ja toteutetaan se toiminto mitä tilaaja ei ole muistanut kuvata. Ylimääräistä työtä ei yleensä tehdä, ja jos vähemmän työtä on tehty niin ohjelma ei ole valmis.
4. Etsi tekijöitä (käyttöliittymäohjelmoija, palvelinohjelmoija, graafikko, projektipäällikkö). Kun salassapitosopimus on allekirjoitettu, voit sitten jutella yksityiskohdista. Huomioi se, että jos sovellus on ns. natiivisovellus josta tarvitsee tehdä alustakohtaisesti versiot Android, iOS ja Windows laitteille, tarvitsee helposti varata kolme käyttöliittymäohjelmoijaa.
Avainasemassa on kommunikointi, sen pitää olla tehokasta ja yksiselitteistä eikä ympäripyöreää selittämistä mitä olisi kiva olla. Kaikki pitää olla kirjallista. Kommunikoinnin tehostamisessa voi auttaa se, että ostat sen sovelluksen tekemisen palveluna yritykseltä jossa on tarvittavat osaajat jossa ne voivat sitten keskenään sumplia asioita miten tekee.
Jos ei itse osaa, halvin tapa hoitaa homma on ns. ketterä tapa joka menee pääpiirteissään niin, että vastuu on suurimmaksi osaksi tilaajalla. Tilaaja tekee mahdollisimman paljon siitä määrittelystä, etsii sopivat henkilöt jotka sitten tekee. Ketterästi tehtäessä sitä käytännössä ostetaan työntekijät jotka tekee päivä/viikko/kuukausi laskutuksella. Niitä hyväksymistestejä kannattaa muotoilla järjestykseen jossa tärkeimmät vaatimukset ovat ensimmäiseksi ja vähemmän tärkeät viimeiseksi. Tätä kutsutaan backlogiksi.
Tätä listaa aletaan sitten tekemään ja se kasvaa tekemisen aikana. Tekemistä jatketaan kunnes rahat loppuu tai se ohjelma on muotoutunut sellaiseksi kuin halutaan.
5. Tekemisen aloitus
Toimittajaorganisaatio tai kehittäjät sitten käy sitä määrittelyä läpi, ja noin 20% ajasta se tulee bumerangina takaisin kun sinulla on joku ranskalainen viiva siellä kertomassa jonkun asian ja kysyvät sitten, että mitä tämä nyt ihan oikeasti tarkoittaa ja antavat aika-arvioita jotka kasvavat joka kerta kun määrittely tarkentuu.
Sitten alkaa se tekeminen ja hommia tehdään eteenpäin määrittelyn mukaisesti mahdollisimman nopeasti.
Koska ketterässä kehittämisessä vastuuta on paljon tilaajalla, sinun kannattaa tehdä se määrittely huolella ja mahdollisuuksien mukaan kirjoittaa
sopimus niin, että aika-arviot mitä antavat ovat sitovia. Jos tekevät pidempään, maksavat omasta pussista. Tämä ei aina onnistu koska se määrittely elää ja vaatimukset tarkentuvat tekemisen aikana. Riippuu täysin määrittelyn tarkkuudesta.
Virheitä jää joka tapauksessa joten sellainen pykälä kannattaa tehdä, että jos löytyy virhe 3kk tai vuoden sisällä siitä kun tuotantoon menevä versio on tehty, kehittäjät korjaa virheen ilman eri kustannuksia.
Ylläoleva ei onnistu ellei määrittely ole yksiselitteistä. Jos ei tarkkaan tiedä mitä pitää tehdä, hyväksymistestit puuttuu jne. kukaan ei voi antaa sitovaa lupausta milloin se on valmis. Se voi myös tarkoittaa sitä, että jos ohjelmassa on virheitä joiden korjaaminen vie viikon niin tilaaja maksaa siitä. Mitä tarkemmin määrittelee, sitä enemmän saa vastuuta ohjelmiston tekijöille. Sinä kuitenkin ensisijaisesti ostat ihmisiä töihin aikaperusteella ja jos heikosti määritelty juttu jää puolitiehen, se jää tilaajan maksettavaksi.
Mikäli ohjelmiston tekijät lupaavat korjata virheitä sopimuksen mukaisesti tuotantoon viemisen jälkeen, kannattaa myös hankkia joku ihan ulkopuolinen testaaja (ja kannattaa usein muutenkin) joka etsii niitä virheitä jotta ne ohjelmistokehittäjät sitten korjaa ne.
Ohjelmaksi kirjoitetut hyväksymistestit ovat äärimmäisen hieno juttu, nappia painamalla voi tarkistaa, että sovitut asiat toimivat ja toimii sen jälkeenkin kun tekevät muutoksia.
M-Karilla paljon hyviä huomioita. Harmi lukijoiden kannalta, että asian selkeyden ja hahmottamisen kannalta en tässä voi lainkaan valottaa millaisesta ja mihin käyttöön tarkoitetusta ohjelmasta on kyse, eli komentoijien on vaikea tehdä yksilöidymmin huomioita.
1) Aivan ensimmäinen prioroteetti olisi tulevan ohjelman ja itse idean suojaaminen, joka on oma haasteensa ja joka tuossa hahmotuksessa olikin hyvin ykkösenä. En ole perehtynyt siihen miten ohjelmia ja ohjelmaideoita suojataan ja yleensähän kopiointi alalla on varsin villiä ja nopeaakin.
Samoin tuo ohjelman toteutuksen kehys, eli saattaisi vaatia jossakin vaiheessa yrityksen perustamista.
Myös ohjelman tuottomuoto on toistaiseksi avoin kysymys.
Pitäisi myös jossakin vaiheessa kunhan ehtii hiehaman perehtyä siihen miten eri ohjelmien tekijät ja / tai varsinkin sellaisen ideoineet (ilman omamaa sen toteutamisen kompetenssia) ovat kukin kohdallaan edenneet.
Helpompi asia on silloin kun koodaaja-ohjelmanrakenaja itse saa jonkin hyvän idean (tai luotettavien ystäviensä kanssa kimpassa) ja alkaa sitten toteuttaa sitä omatoimisesti "omassa kammioissaan" kohti valmista lopputulosta.
4) Lähtökohtaisesti ohjelma olisi selainriippumaton, eikä se toimiakseen tarvitse nettiä, joskin se tulisi istuttaa eri käyttöliittymille erikseen, eli markkinaosuuden perusteella Androidista tulisi aloittaa.
Poikkeus on se, että jos sen rahoitusmuoto edes osittain perustuisi ko. toimialaan kohdistettuun mainontaan. Itse olen varauksellinen mainoksien suhteen ja niiden tulisi olla maltillisia ja käyttäjiä kiusaamattomia muodoltaan. Parhaillilaan maltillista hyötymanontaa tyylin win-win.
Ohjelma on myös luonteeltaan sellainen, ettei se tule travitsemaan kovinkaan paljoa päivityksiä (toki pohjalla oleva käyttödata kasvaisi pikku hiljaa), ellei sitä sitten muutoin ajan kuluessa hioisi paremaksi.
Appsi-ideani ei itsessään ole toiminnoiltaan erityisen vaativa (suht' simppelit pelitkin varmasti moninkerroin moninmutkaisempia), joskin tokihan se silti tulisi hioa ergonomiseksi ja helpon selkeän mielyttäväksi käyttää.
Samalla tässä pohdin tulevaisuuden tekniikoita (IoT jne.), eli miten ko. ohjelma (ja sen käyttökohde-alue) voisi kehittyä pitkällä aikavälillä ja millaisia parantavia ominaisuuksia / toimntatapoja siihen voisi liittää.
Joka tapauksessa ojelman toteuttamiseksi tulisin tarvitsemaan sille tekijät.
Avoin kysymys on miten nuo tekijät valitsee, projektin realistinen budjetointi, sekä ohjelman tuleva tuottomuoto.
"1) Aivan ensimmäinen prioroteetti olisi tulevan ohjelman ja itse idean suojaaminen, joka on oma haasteensa ja joka tuossa hahmotuksessa olikin hyvin ykkösenä. "
Salassapitosopimus, tavaramerkki, tekijänoikeus.
Ideaa ei oikein voi suojata mielekkäästi muuten kuin olemalla nopea ja ensimmäinen. Samoille markkinoille on vaikeata tunkeutua.
"Pitäisi myös jossakin vaiheessa kunhan ehtii hiehaman perehtyä siihen miten eri ohjelmien tekijät ja / tai varsinkin sellaisen ideoineet (ilman omamaa sen toteutamisen kompetenssia) ovat kukin kohdallaan edenneet."
Olen nähnyt näitä. Suurimmat ongelmat seuraavia:
-Puutteellinen määrittely
-Oletetaan asioita. Ei niillä ohjelmoijilla ole kristallipalloa ajatusten lukemiseen.
-Aliarvioidaan tarvittavat resurssit. Ohjelmointi yleisesti ottaen on hidasta työtä. Pitää varata runsaasti aikaa ja rahaa. Aikaa menee helposti 4x enemmän kuin miltä aluksi vaikutti.
Käytännössä homma kehittyy kaiken aikaa ja tarvitsee budjetoida henkilöresurssit. Jos se tekeminen vaatii vaikka kolmen henkilön porukan, se on käytännössä kolmen henkilön palkkaus kunnes on valmis. Homma ei myöskään nopeudu jos kesken kaiken lisää väkeä, päinvastoin se kestää silloin kauemmin. Joten vaadittavat henkilöresurssit pitää tietää kun hommia alkaa tehdä. Sitten kun se on valmis, tarvitaan se ylläpito. Kokoajan tulee uusia Android, iOS, Windows versioita ja pitää testata, että homma toimii ja vikoja pitää korjata ja voi olla että halutaan toimivan myös edellisellä versiolla.
"4) Lähtökohtaisesti ohjelma olisi selainriippumaton, eikä se toimiakseen tarvitse nettiä, joskin se tulisi istuttaa eri käyttöliittymille erikseen, eli markkinaosuuden perusteella Androidista tulisi aloittaa."
Selaintekniikassa voi tulla vastaan rajoitteita tiedon paikalliselle tallentamiselle mutta riippuu taas sovelluksesta.
"Avoin kysymys on miten nuo tekijät valitsee, projektin realistinen budjetointi, sekä ohjelman tuleva tuottomuoto."
Jos aikataulujen tarvitsee pitää niin tarvitsee kokeneita tekijöitä. Budjetti alkaa tarkentua sitten kun on määritelty se projekti. Tuottomuoto taas on sitä yrityksen perustamista eikä liity itse sovellukseen.
"4) Lähtökohtaisesti ohjelma olisi selainriippumaton, eikä se toimiakseen tarvitse nettiä, joskin se tulisi istuttaa eri käyttöliittymille erikseen, eli markkinaosuuden perusteella Androidista tulisi aloittaa."
Sellainen huomio sitten liittyen ohjelman suojaamiseen kopioijilta, että selaimessa ajettavaa koodia ei käytännössä voi järkevästi suojata vaan se koodi näkyy sitten niille kilpailijoille jotka haluavat tutkia miten se on tehty.
Tarvitsee tehdä natiivia jos haluaa piilottaa toteutusta, ja mielellään ajaa salassa pidettävä koodi palvelimella mutta se ei nyt tainnut käydä jos tarkoitus oli toimia puhtaasti ilman nettiyhteyttä.
Hyvä Matti, hukuta meidät faktoihin...
Toivottavasti aloittajalla on rahaa ja toisilla kokemusta.
Kun prosessi on ohitse toisillaon rahaa ja aloittajalla kokemusta.
>> Salassapitosopimus, tavaramerkki, tekijänoikeus.
Teknologiapatentit ovat suoraviivaisempia, mutta ohjelien ja niihin littyvien perusideoiden tilanne on vaikeampi.
Softa pitäis saada loppuun saakka hiotuksi tärkeimmillä markkina-alueilla, eli kielillä ja saada tehokkaasti markkinoille. Kopiojat tulevat melkoisella varmuudella kuitenkin vanavedessä.
>> -Puutteellinen määrittely
Eli softaa ideoivalla itsellään ei ole selkeätä kuvaa haluamastaan asiasta ja kokonaisudesta. Ei koske ideaani.
>> -Oletetaan asioita. Ei niillä ohjelmoijilla ole kristallipalloa ajatusten lukemiseen.
Liittyy tiiviisti edelliseen profiiliin.
>> -Aliarvioidaan tarvittavat resurssit. Ohjelmointi yleisesti ottaen on hidasta työtä. Pitää varata runsaasti aikaa ja rahaa. Aikaa menee helposti 4x enemmän kuin miltä aluksi vaikutti. "
Tuo on juurikin keskeinen osa projektia jossa tulee olla relaistinen ja sen kartoittaminen yksi perusasia.
Itse olen lähinnä kinnostunut (tutustumaan) edellisessä viestissäni manitsemistani hyvin läpiviedyistä projekteista ja niiden toteutustavasta tilanteessa jossa idean isällä tai äidillä ei itsellä ole kompetenssia itse softan valmistukseen.
Totta. Valmiin softan yläpito on yksi elementti varsinkin kunse on alustariippuvainen ja käyttikset kehittyvät ja muttuvat, eli yhteensopivuuksista tulee huolehtia.
>> Selaintekniikassa voi tulla vastaan rajoitteita tiedon paikalliselle tallentamiselle mutta riippuu taas sovelluksesta.
Kyseinen softa on luonteeltaan selainriippumaton, eikä edes tarvitse nettiä toimiakseen. Toki mahdolliset ohjelman päivitykset tulee sitten hoitaa netissä.
>> Budjetti alkaa tarkentua sitten kun on määritelty se projekti.
Ajattelemani softa on melko lailla perusraameissaan ideana jo paketissa. Toki mieli on avoin josko olen jättänyt jotakin sen potentiaalia havaistematta.
>> Tuottomuoto taas on sitä yrityksen perustamista eikä liity itse sovellukseen.
Väärin. Yritys on vain tuottomuodon välikappale, työkalu, eli softan (tuottamisen) yläpidon ja mahdollisten muiden kulujen kustantaja ja mahdollisten / toivottavien rahavirtojen vastaanottaja. Lopputuleman tavoitteena viivan alla vuositainen plusmerkki. Tässä puolestaan astuu kuvaan mukaan myös verotuksellisten tekijöiden ennalta huomioiminen ja kartoittaminen businesmuotoa suunnitellessa.
Itse ohjelman tuottomuoto, eli businesidea on oltava kartoitettuna mahdollisimman realistisesti ja optimaalisti jo ennen itse projektiin lähtemistä, eli se miten softan suunnitellaan tuottavan taloudellista tulosta. Latausmaksuna vai manoksilla vai sekä että vai jollakin muilla kombinaatioilla.
"Teknologiapatentit ovat suoraviivaisempia, mutta ohjelien ja niihin littyvien perusideoiden tilanne on vaikeampi."
Patenttien ja ohjelmistojen sotkeminen keskenään ei oikein toimi. Patentti on lähinnä pelote mutta ei käytännössä merkitse koska ei tarvitse olla ihmeellinen lakimies mitätöidäkseen sen tai miettimällä ratkaisu jolla sama asia tehdään hieman eri tavalla, patentti kiertäen.
"Eli softaa ideoivalla itsellään ei ole selkeätä kuvaa haluamastaan asiasta ja kokonaisudesta. Ei koske ideaani."
Jokseenkin varmasti koskee. Itseasiassa tämä on niin merkittävä asia, että mielestäni suunnillen jokaisen joka teettää ohjelmistoa toisella, pitäisi itse käyttää se muutama tunti aikaa siihen että opettelee ohjelmoinnin alkeisperusteet mitä lapsetkin osaavat.
Syynä tähän on se, että se pakottaa ihmisen ilmaisemaan itseään yksiselitteisesti, eli se mitä tietokoneohjelman tilaajalta vaaditaan että määrittely ei ole löperöä.
Idea ei vaan riitä, pitää määritellä se toiminta tarkasti.
"Tuo on juurikin keskeinen osa projektia jossa tulee olla relaistinen ja sen kartoittaminen yksi perusasia."
Laskukaava menee suunnileen näin, että lähtökohtana on aika-arvio mikä menee homman tekemiseen ideaalitilanteessa.
Todellinen aika mikä vaaditaan: x4
Jos tehdään viimeistelty tuote, manuaalit ja muut materiaalit kaikki kiillotettuna, valmis kuluttajalle, vähän vikoja: x3
Jos tehdään uudelleen käytettävää ohjelmistokomponenttia, mitä voidaan käyttää eri projekteissa: x3
Jos tehdään korkealaatuista koodia, lähes virheetöntä: x2
Eli aika arvio miltä yksinkertainen juttu ensi silmäykseltä vaikuttaa kun nopeasti rykäistään kasaan, on todellisuudessa x4 mutta aikaa voi myös mennä 72x enemmän, tapauksesta riippuen. Siinä vaiheessa on ohjelmistoa oikeasti tarvitsee purkaa komponentteihin ja tarvitaan jotain omaa frameworkkia, hyviä rajapintoja jne. niin pitää suosiolla käyttää vain senior ohjelmoijia joilla on kokemusta 7-10v.
"Kyseinen softa on luonteeltaan selainriippumaton, eikä edes tarvitse nettiä toimiakseen. "
Niin mutta tallentaako se tietoa? Esimerkiksi jos projekti olisi peli, kuten vaikka tetris ja siinä on pistetaulu, niin se pistetaulu on tallennettavaa tietoa jos halutaan että ne pisteet säilyy sen jälkeen kun ohjelma suljetaan.
Jos projekti vaikka laskee kolmion pinta-alan niin se ei tallenna mitään.
Selainsovellus tallentaa lähinnä 4Kt keksejä ja sitten on paikallista tallennustilaa tyylin 2.5 megatavua. Se on rajoite jos halutaan pärjätä ilman nettiä.
Hybridit ja natiivisovellukset eivät tee tällaista rajoitetta offlinessa. Niitä sitten jaellaan sovelluskauppojen kautta.
"Yritys on vain tuottomuodon välikappale, työkalu, eli softan (tuottamisen) yläpidon ja mahdollisten muiden kulujen kustantaja ja mahdollisten / toivottavien rahavirtojen vastaanottaja."
Yleensä se menee niin, että on bisnesidea jossa softa voi olla osallinen, mutta softa on alisteinen sille bisneslogiikalle.
>> Patenttien ja ohjelmistojen sotkeminen keskenään ei oikein toimi.
Miksi koetat vääristää kirjoittamaani? Totesin ainoastaan, että teknologiapatenttien tekeminen ja suojaminen on suoraviivaisempaa kuin koettaa suojata softaa ja siihen liittyvää ideaa.
>> Patentti on lähinnä pelote mutta ei käytännössä merkitse koska ei tarvitse olla ihmeellinen lakimies mitätöidäkseen sen tai miettimällä ratkaisu jolla sama asia tehdään hieman eri tavalla, patentti kiertäen.
Tokihan patentteja rikotaan ja sitten pelataan aikaa eri oikeusasteissa, sekä niitä koetetaan kiertää. Tämän estämättä monien yrityksien patenttitulot ovat merkittävät kuten vaikkapa Qualcomin ja jopa Ericssoninkin.
Nokia omalta osaltaan on tehostamassa patenttiportofolionsa monetisointia nyt päätelaitteiden MS:lle myynnin jälkeen ristiinlisensiointien loputtua ja sen olematta esteenä patenttitulojen optimoinnille. Parhaillaan olemassa olevia sopimuksia ollaan neuvottelemassa uusiksi uudelta pohjalta.
Vasta hiljattain se rekrytoi yhden alan raskassarjalaisista, joka on jo kannuksensa toisaalla näyttänyt.
"Teknologiayhtiö Nokia on nimittänyt Ramzi Haidamuksen patenttiliiketoimintansa eli Nokia Technologiesin johtajaksi ja Nokian johtokunnan jäseneksi."
"Nokian mukaan hänen aikanaan Dolby kasvoi 72 miljoonan dollarin yhtiöstä lähes miljardin dollarin pörssiyhtiöksi."
- http://www.taloussanomat.fi/porssi/2014/07/24/nokian-patenttiyksikko-saa-uuden-johtajan/201410309/170?n=1
Tällä hetkellä Nokia tekee noin 600 miljoonaa patentti- ja lisenssituloa vuosittain ja jatkossa patenttitulot tulevat kasvamaan, vaikka nyt niiden tehostaminen tulee myös aiheuttamaan lisäkuluja.
"Puhelintoimintonsa Microsoftille myynyt Nokia saattaa tehdä pian vuosittain 1,4 miljardia euroa patentoimalla kehittämiänsä tekniikoita muille firmoille."
- https://www.taloussanomat.fi/informaatioteknologia/2014/10/10/kova-nokia-luku-patenteista-pian-38-miljoonaa-paiva/201414102/12?pos=tuoreimmat
Koreassa alan teollisuus on jo vakavasti huolissaan (paniikissa hallitustaan apuun pyytäen), että helpot päivät ovat takana ja patenttioikeuksien käytöstä joutuu myös maksamaan käyvän markkinahinnan.
"Korean Industry Demanding Measures against Patent Offensives by Nokia, Microsoft"
- http://www.businesskorea.co.kr/article/6044/defensive-stance-korean-industry-demanding-measures-against-patent-offensives-nokia
Alla olevan on arvioitu olevan suuntaa-antavaa siitä mitä Samsung tulee maksamaan Nokialle tulevaisuudessa.
"Samsung paid Microsoft over $1 billion in Android patent royalties in 12-month period: court filing"
- http://www.fosspatents.com/2014/10/samsung-paid-microsoft-over-1-billion.html
"Samsung jatkaa Nokian ja Samsungin välistä patenttilisenssisopimusta viidellä vuodella; lisäkorvausten suuruus määräytyy sitovassa välimiesmenettelyssä"
"Sopimuksen mukaan Samsung maksaa lisäkorvauksia Nokialle 1.1.2014 alkavasta ajanjaksosta, ja korvausten suuruus määräytyy sitovassa välimiesmenettelyssä, johon odotetaan ratkaisua vuoden 2015 kuluessa."
- http://company.nokia.com/fi/uutiset/lehdistotiedotteet/2013/11/04/samsung-jatkaa-nokian-ja-samsungin-valista-patenttilisenssisopimusta-viidella-vuodella-lisakorvausten-suuruus-maaraytyy-sitovassa-valimiesmenettelyssa
Alla oleva tulee olemaan todella suuri keissi mikäli Nokia tulee kiistan voittamaan.
"Google Maps and Navigation under patent fire from Nokia: lawsuit revealed by Google itself"
- http://www.fosspatents.com/2013/12/google-maps-and-navigation-under-patent.html
Tulevaisuudessa liki kaikki alan tekijät tulevat maksamaan patentti- ja lisenssikorvauksia Nokialle. Keskipitällä aikajänteellä kokonaisuus ja sen mittakava alkaa täsmentyä lisää.
Nytkin joka ainoa myyty iPhone ja monen muun valmistajan myymä matkapuhelin tuo rahaa Nokian kassaan.
Myös Nokia Networks puolen patentit tuovat sille tuloa alan eri tahoilta.
>> Yleensä se menee niin, että on bisnesidea jossa softa voi olla osallinen, mutta softa on alisteinen sille bisneslogiikalle.
Aivan turhaa sanoilla leikittelyä vs. aiempi väittämä siitä, että yritys on yhtä kuin ansaintamalli.
Toistetaan.
Yritys on vain tuottomuodon välikappale, työkalu, eli softan (tuottamisen) ylläpidon ja mahdollisten muiden kulujen kustantaja ja mahdollisten / toivottavien rahavirtojen vastaanottaja.
Itse ohjelman tuottomuoto, eli businessidea on oltava kartoitettuna mahdollisimman realistisesti ja optimaalisesti jo ennen itse projektiin lähtemistä, eli se miten softan suunnitellaan tuottavan taloudellista tulosta.
Ps. Jotkut rakentavat ja suorastaan tehtailevat ongelmaillisuuksia ja kompleksisuutta (jopa simppeliin kotikoneen perusylläpitoon), toiset ratkaisevat erilaisia haasteita kompleksisuutta välttäen.
"Ps. Jotkut rakentavat ja suorastaan tehtailevat ongelmaillisuuksia ja kompleksisuutta (jopa simppeliin kotikoneen perusylläpitoon), toiset ratkaisevat erilaisia haasteita kompleksisuutta välttäen. "
Ohjelmiston suunnittelu on nimenomaan kompeksisuuden välttämistä. Abstrakteja malleja tarvitaan ja silloin tehdään jotain väärin jos samaa tietoa muokataan useassa paikassa.
Pyöräily on mukava laji, melkein yhtä mukava kuin tietokoneiden ja puhelimien hakkerointi.
http://www.valkeakoskensanomat.fi/cs/Satellite?blobcol=urldata&blobkey=id&blobtable=MungoBlobs&blobwhere=1196034641333&ssbinary=true