Valmis tuote vai räätälöity ohjelmisto: milloin kumpikin

Ostat CRM:n, koska myyntipäällikkö ei enää selviä muistiinpanoista, ja kolmen kuukauden kuluttua järjestelmän vieressä seisoo Excel, jossa on kolme hinnastoa, ja kansio laskuja, jotka joku kopioi kirjanpitoon. Tuote ei ole huonompi kuin se, joksi se myytiin, koska se tuntee asiakkaan, kaupan ja seuraavan puhelun, mutta se ei tunne prosessiasi, koska tämä prosessi ei ollut se, jota valmistaja rakensi sadoille yrityksille, ja juuri tämä väli on koko tämän artikkelin aihe: ostatko työkalun prosessillesi vai prosessin työkalullesi, et ominaisuustaulukon reikää, jonka voisi paikata yhdellä räätälöinnillä. Jos reikä on liitäntä järjestelmien välillä, jotka jo tekevät työnsä, se ei ole argumentti rakentamiselle: ensin kytkemme sen, mitä jo on.

Valmis tuote vai räätälöity ohjelmisto ei ole kysymys siitä, kumpi nappi näyttää nykyaikaisemmalta, eikä myöskään kysymys siitä, oletko ”tarpeeksi suuri rakentamaan itse”. Vastauksemme on sama, jonka olemme kirjoittaneet palvelusivulle: jos prosessisi mahtuu valmiiseen työkaluun, ota valmis työkalu, se tulee halvemmaksi, ja räätälöity järjestelmä on perusteltu silloin, kun prosessi on osa kilpailuetuasi tai valmisratkaisut vaativat liikaa kompromisseja, eikä tämä lause ole myyntikikka, jotta sen jälkeen kuitenkin myytäisiin rakentaminen, vaan testi, jolla häviämme rivit, joissa pitäisi kirjoittaa vielä yksi CRM, ja pidämme ne, joissa prosessi on osa kilpailuetua tai valmiit työkalut vaativat liikaa kompromisseja.

Tämä artikkeli ei ole verkkokauppa-alustojen vertailu, koska sen olemme jo kirjoittaneet toisaalle, eikä se ole myöskään räätälöidyn ohjelmiston hinnasto, koska sellaista artikkelia meillä ei ole eikä tule, sillä emme keksi hintoja päästämme, eikä se myöskään ole lupaus siitä, että oma järjestelmä aina voittaa. Myymme sekä valmiin tuotteen käyttöönottoa että rakentamista tyhjästä, ja rehellinen teksti alkaa siitä, että kallein palvelu, jonka voimme sinulle myydä, on joskus se, jota et tarvitse, siksi jäljempänä on raja, jonka jälkeen tämän valinnan voi tehdä, ennen kuin joku myy sinulle sprintin.

Valmis tuote vai räätälöity ohjelmisto: milloin kumpikin

Ota valmis tuote, jos prosessi mahtuu siihen, ja tilaa ohjelmisto, jos prosessi on kilpailuetusi tai valmiit työkalut vaativat liikaa kompromisseja: se on koko vastaus, ja muu tässä artikkelissa on sitä, miten tämä lause tarkistetaan tiettyä työtä vastaan, ei esitystä vastaan. Vertailu, joka alkaa ominaisuustaulukosta, päättyy ennen kuin se alkaa, koska taulukko näyttää sen, minkä valmistaja on nimennyt, ei sen, kuka vuoden päästä päättää seuraavasta muutoksestasi.

Väärän puolen seuraukset eivät ole symmetrisiä, koska valmis työkalu, johon olet tunkenut prosessisi väkisin, muuttuu tilaukseksi plus Exceliksi plus ihmiseksi, joka pitää molemmat koossa, ja tämä ihminen on vuoden kuluttua kalliimpi kuin mikään lisenssi, mutta räätälöity järjestelmä prosessille, joka jo elää kirjanpidossa, sähköpostiohjelmassa ja tavallisessa CRM:ssä, on rakennus, jota ylläpidät itse, vaikka markkinoilla sitä ylläpitää jo joku muu. Ensimmäisessä tapauksessa olet ostanut tuotteen ja sitten kirjoittanut toisen järjestelmän sen viereen, toisessa olet kirjoittanut järjestelmän sinne, missä lisenssi olisi riittänyt, ja molemmat virheet maksavat pidempään kuin miltä tarjouksessa näyttää.

Nimeämme tämän rajan, koska olemme nähneet molemmat päät samalla viikolla: yrityksen, joka halusi ”oman HubSpotinsa”, vaikka se tarvitsi HubSpotin, ja yrityksen, joka kolme vuotta väänteli valmista ERP:tä hintataulunsa ympärille ja tuli lopulta saman taulun kanssa uuden projektin luo, ei siksi että ”ERP ei osaa”, vaan siksi että kompromisseja oli jo enemmän kuin konfigurointia. Kumpikaan näistä tiloista ei ole pahan tahdon tulos, koska molemmat alkavat lauseesta ”tarvitsemme järjestelmän”, joka ei vielä ole testi, ja testi alkaa vasta sitten, kun kirjoitat prosessin yhdelle sivulle ilman työkalun nimeä ja etsit sen jälkeen, mikä työkalu tekee tämän sivun jo.

Ennen hankintaa kirjoita, mitä järjestelmän on tehtävä ensimmäisenä päivänä, mitä se ei saa unohtaa toisena vuonna, ja kuka saa muuttaa tätä toista vuotta ilman vierasta julkaisua, koska jos vastaukset mahtuvat tuotteeseen, jonka voi konfiguroida, ota tuote. Jos kysymys on luettelo, hinnat, tilaus ja toimitus verkkokaupassa, se on verkkokaupan testi, emmekä kirjoita sitä uudestaan; jos vastaukset ovat prosessi, jota kilpailija ei saa ostaa valmiina työkaluna, vasta sitten on järkeä puhua sprintistä. Tämä artikkeli myy tästä eteenpäin tätä järjestystä, ei työkalua.

Mitä valmis tuote on ja mitä räätälöity ohjelmisto on

Valmis tuote on ohjelmisto, jonka joku on jo kirjoittanut monille ja jonka ostat tai tilaat käyttääksesi sitä ilman olennaista uudelleenrakentamista. Julkisen hallinnon IT-hankintojen yleiset sopimusehdot (JIT 2025) erottavat valmisohjelmiston tilaajan sovelluksesta ja käsittelevät myös tietoverkon kautta käytettäviä palveluja. COTS on tässä valmis kaupallinen ohjelmisto ilman olennaista räätälöintiä, SaaS sovellus, joka on saatavilla internetissä tilattavana palveluna. Nämä ovat määritelmiä suunnitteluun, eivät velvollisuus yksityiselle yritykselle, ja otamme ne tässä sanoina, jotka on jo nimetty, emme lakina, joka vaatisi sinulta valtionhallinnon hyväksynnän.

Räätälöity ohjelmisto on järjestelmä, joka kirjoitetaan prosessillesi, ja samoissa ohjeissa erityisohjelmistoksi kutsutaan yksilöllisesti kehitettyä ohjelmistoa tietyn viranomaisen tai toimialan tarpeisiin. Kutsumme sitä myös räätälöidyksi järjestelmäksi, palvelusivulla epätyypilliseksi järjestelmäksi ja otsikossa räätälöidyksi ohjelmistoksi, eivätkä nämä ole kolme tuotetta vaan yksi työ: koodi, joka alkaa prosessistasi, ei valmistajan oletuksesta siitä, mikä on asiakas, tilaus tai lasku, siksi ero ei ole ”parempi” vastaan ”huonompi”, vaan se, kuka saa sen jälkeen muuttaa tätä oletusta.

Valmis tuote ei ole epäonnistunut räätälöity rakennus, eikä räätälöity rakennus ole parempi CRM, koska WooCommerce on valmis verkkokauppatuote, Moodle on valmis oppimisalusta, WordPress on valmis sisältöalusta, ja myymme kaikki kolme käyttöönottona, emme piilotettuna rakennuksena toisen nimen alla. Laravel ei ole tuote tässä mielessä: se on kehys, jolla kirjoitamme räätälöityjä järjestelmiä versiosta 4.0 vuodesta 2013 alkaen, eikä se anna luetteloa, ostoskoria eikä CRM:ää, ennen kuin joku on ne kirjoittanut, siksi kehyksen sekoittaminen tuotteeseen merkitsee kuvitelmaa, että ”Laravelilla” olisi jo vastaus, vaikka se on vain tapa kirjoittaa vastaus.

Kolmas asia, joka tässä kohdassa yleensä sekoitetaan, on tilaus vastaan omistus, koska SaaS merkitsee, että maksat käytöstä ja data on toimittajalla, pysyvä lisenssi merkitsee, että olet maksanut oikeudesta käyttää versiota ja päivitykset ovat usein erillinen rivi, mutta räätälöity koodi, jonka luovutamme, merkitsee, että lähdekoodi, dokumentaatio ja infrastruktuurin konfiguraatio ovat sinun. Millään näistä riveistä ei ole automaattista voittoa, on vain selvyys siitä, mitä ostat, koska muuten vuoden päästä kiistelet siitä, onko ”järjestelmä meidän”, kun kyseessä on tilaus, jonka voi irtisanoa.

Testi, jolla me teemme tämän valinnan

Testi ei ole ”pidämmekö tästä näytöstä”, vaan se, mahtuuko prosessi, jota et saa luovuttaa kilpailijalle, työkaluun, jonka kilpailija voi ostaa samasta kaupasta: jos mahtuu, työkalu on oikea vastaus, koska se tulee halvemmaksi ja sitä ylläpitää joku, jonka ainoa työ on tämä työkalu, mutta jos ei mahdu, koska hintataulu, tilauksen hyväksyntä tai toimitusehdot ovat se, millä erotut, valmis tuote muuttuu kompromissiksi, ja kompromissi merkitsee tässä, että prosessi alkaa elää Excelissä järjestelmän vieressä.

Saman testin toinen puoli unohtuu liian usein, koska tarpeet ovat useammin yhteisiä kuin ainutlaatuisia, eikä sähköpostiohjelmaa rakenneta, kirjanpitoa, joka jo tekee sen mitä laki vaatii, ei rakenneta, eikä myöskään tavallista myyntisuppiloa, jossa kauppa on kauppa. Viranomaiset, jotka käyttävät rahansa kirjattujen kriteerien mukaan, ovat nimenneet saman muodon toisin: ensin kysytään, onko markkinoilla jo asia, ja rakennetaan sitten, kun saatavilla olevat tuotteet eivät kata ydintä tai kun asiaa on hallittava itse, eikä tämä ole yksityisen yrityksen velvollisuus, emmekä me tee siitä sellaista, mutta se on sama muoto, jolla sanomme ei rakennukselle, jonka voi ostaa.

Kolmas virhe on tuotteen uudelleenrakentaminen, kunnes se ei enää ole tuote, koska konfigurointi pysyy tuetuissa rajoissa (kentät, roolit, työnkulut, jotka valmistaja on suunnitellut), mutta räätälöinti, joka kirjoittaa ytimen uudelleen, jotta prosessi ”vihdoin sopisi”, kuluttaa juuri sen edun, jonka takia tuote ostettiin: päivitykset, dokumentaation, sen että virheen löytää joku muu. Olemme nähneet sen Moodlen käyttöönotoissa, joissa ensin tarkistamme, onko lisäosa jo olemassa, ja vasta sitten kirjoitamme omamme, ja WordPress-sivustoilla, joille emme aseta valmista teemaa, koska se tuo kymmeniä toimintoja, joita et tarvitse ja joista tulee tietoturvariski, siksi tuote, jolla on vieras ydin, ei ole räätälöity järjestelmä vaan tuote, jolta olet poistanut valmistajan ytimen.

Teemme tämän testin määrittelytyöpajassa, emme tarjouksen kalvolla, koska kalvolla voittaa aina rakennus, joka näyttää sinusta huolehtimiselta, mutta työpajassa voittaa prosessi, jonka voi nimetä. Jos kahden päivän jälkeen käy ilmi, että prosessi mahtuu valmiiseen työkaluun, sanomme sen, myös silloin kun se merkitsee, ettei tämän viikon kauppa ole meidän epätyypillinen järjestelmämme, koska artikkeli, joka aina päättyy ”rakennamme sinulle oman”, ei ole testi vaan tarjous, joka piiloutuu kysymyksen taakse.

Milloin valmis tuote on oikea vastaus

Valmis tuote on oikea vastaus siellä, missä prosessi on jo nimetty toimialalla etkä ole se, joka tämän nimen keksi, koska sähköposti, kirjanpito, joka kirjoittaa laskun niin kuin laki vaatii, tavallinen myynnin CRM, oppimisalusta, joka kirjaa kurssin ja suorituksen, ja pieni kauppa, jossa on yksi hinta ja yksi varasto, ovat paikkoja, joissa rakentaminen ei anna mitään sellaista, mistä kannattaisi maksaa ero lisenssin ja sprintin välillä. Emme myy näitä rivejä ”väliaikaisena ratkaisuna, kunnes olet valmis oikeaan järjestelmään”, koska ne ovat näiden prosessien oikeat järjestelmät.

Myymme näitä tuotteita myös, eikä se ole piilotettu lupaus siitä, että vuoden päästä tulee rakennus: WordPress pysyy sisältöalustana teemalla, jonka kirjoitamme me, ei valmiilla teemalla kaupasta; pienelle kaupalle, jonka prosessit ovat vakiomuotoisia, sanomme itse WooCommerce; Moodle pysyy oppimisalustana, jonka konfiguroimme, siirrämme ja muotoilemme, emme keksi uudestaan. Näiden rivien hinnat seisovat palvelusivuilla ja yhdessä kohdassa alempana tässä artikkelissa, jossa pitää näyttää, ettei räätälöidyn järjestelmän lähtöhinta ole automaattisesti kallein rivi, ja tässä riittää sanoa, että tuote pysyy tuotteena.

Seuraus, jos tässä kohdassa silti tilaat rakennuksen, ei ole ”parempi hallinta” vaan ylläpito, jota et enää jaa tuhansien muiden kanssa, koska sähköpostiohjelman tietoturvakorjauksen joku julkaisee kaikille, mutta oman sähköpostiohjelman korjauksen julkaiset sinä, ja se kuulostaa vapaudelta, kunnes tulee toinen yö, jossa on korjattava se, minkä valmistaja on jo korjannut omassa tuotteessaan. Myymme tätä vapautta siellä, missä prosessi sen ansaitsee, emme siellä, missä lisenssi riittää, koska muuten myymme sinulle työtä, jota vuoden päästä vihaat kalliina kaksoiskappaleena.

Siksi rehellisin asia, jonka voimme sanoa ennen mitä tahansa epätyypillistä arviota, on luettelo tuotteista, joita suosittelisimme tilalle: jos prosessi on oppiminen, aloita Moodlella, jos prosessi on sisältö, aloita WordPressillä, jos prosessi on pieni kauppa, aloita WooCommercella, ja jos prosessi on laskut ja laissa määrätty kirjanpito, aloita kirjanpidosta, joka sinulla jo on, ja vasta sitten kysy, pitääkö jostain tästä tulla oma järjestelmä. Tämä luettelo ei ole kumppanisopimus, se on testi, jota käytämme itseämme vastaan.

Milloin räätälöity ohjelmisto on perusteltu

Räätälöity ohjelmisto on perusteltu silloin, kun prosessi on osa kilpailuetuasi tai valmisratkaisut vaativat liikaa kompromisseja, ja prosessi voi jäädä tavaran tukiprosessiksi ja silti olla tämän testin osa, koska testi on kompromissien määrä, ei se, myytkö ohjelmistoa. Jos valmis tuote alkaa vaatia, että sinusta tulee keskivertoasiakas, eikä keskivertoasiakas ole kilpailuetusi, rakentaminen on vihdoin testi, jonka prosessi on kestänyt, ei halu omasta näytöstä.

Integraatio ei ole tässä argumentti itsessään, koska tuotteillakin on rajapintoja, ja me kytkemme niitä, ja argumentti alkaa vasta sitten, kun rajapinta ei riitä ja prosessi vaatii, että totuus saldosta, hinnasta tai tilasta elää yhdessä paikassa, jota hallitset. Sadales tīkls -karttaportaali, jonka olemme rakentaneet Laravelilla ja Leafletillä, näyttää keskeytykset, vapaan kapasiteetin ja liittymismaksun, eikä se ole ”kartta plus lisäosa”, koska maksu ja kapasiteetti ovat operaattorin prosessi, eivät karttatuotteen kenttä; Elektrum-portaalissa SSO-istunto liittyy jokaiseen pyyntöön, ennen kuin Vue-konfiguraattori piirtää, eikä se ole ”energia-alan teema WordPressissä”, koska istunto on palvelun osa, ei koriste.

Väri, logo ja valikon järjestys eivät ole tämä testi, koska ne voi tehdä tuotteessa, ja me teemme ne tuotteessa: Moodle-teema paletillasi, WordPress-teema ilman ylimääräistä, WooCommerce-kauppa, joka näyttää sinulta. Jos ainoa, mitä valmiissa työkalussa ei voi tehdä, on ”että se näyttää meiltä”, et ole päätynyt räätälöityyn ohjelmistoon vaan teemaan, ja näiden kahden sekoittaminen merkitsee maksamista rakennuksesta siellä, missä muotoilu riittää, ja sen jälkeen ihmettelyä, miksi ylläpito on kallista järjestelmälle, jonka ainoa ero on väri.

Emme myöskään sano, että jokainen toimiala automaattisesti vaatisi oman alustansa, koska toimialan nimi ei ole testi, ja testi on, onko tämän toimialan prosessi yrityksessäsi sama, jonka valmistaja on jo pannut pakettiin, vai onko se tapasi, jolla toimiala työskentelee, eikä tätä tapaa saa ostaa vierestä. Jos voi ostaa, osta; jos ei voi, kyse on räätälöidystä liiketoimintajärjestelmästä, ja vasta sitten on syytä puhua määrittelytyöpajasta, ei teemasta.

Kolmas tie: tuote, jonka päälle tulee koodiamme

Valmiin tuotteen ja tyhjästä rakentamisen välissä on kolmas tie, jota mekin myymme ja jonka vertailut useimmin jättävät pois: tuote pysyy tuotteena, ja päälle kirjoitamme sen, mitä tuote ei tee, eikä se ole ”vähän räätälöityä ohjelmistoa” vaan päätös jättää ydin sinne, missä valmistaja sitä ylläpitää, ja kirjoittaa vain se kerros, joka on sinun. Sadales tīkls -palveluportaali seisoo October CMS:n päällä, ja laskurit, kalenterit ja vikailmoitus ovat työtä tuotteen päällä, eivät uusi sisältömoottori; Moodlen käyttöönotossa ensin tarkistamme, onko arvioinnin tai raportoinnin lisäosa jo olemassa, ja vasta sitten kirjoitamme omamme, koska muuten myymme sinulle kaksoiskappaleen.

Jos kysymys on luettelo, hinnat, tilaus ja toimitus, se on verkkokaupan testi, ja se on jo kirjoitettu artikkelissa WooCommerce- tai Laravel-valinnasta, siksi emme kirjoita sitä tässä uudestaan emmekä muuta sitä epätyypillisen järjestelmän oletukseksi. Jos kysymys koskee CRM:ää, ERP:tä, sisäistä paneelia tai toimialan prosessia, jää tähän, koska kauppa on yksi tapaus samasta testistä, ei koko valinnan sisältö.

WordPressin puolella kolmas tie näyttää kieltäytymiseltä, koska valmiita teemoja emme aseta, ne tuovat toimintoja, joista tulee tietoturvariski, ja rakennamme puhtaan teeman vain sillä, mitä tarvitaan, ja se on yhä tuote: sisällöntuottaja kirjoittaa WordPressissä, ei meidän keksimässämme editorissa, ja päivitykset tulevat WordPressistä, ei meidän yhdestä julkaisustamme. Ero tämän ja räätälöidyn järjestelmän välillä on se, että sisällön prosessi mahtuu tuotteeseen, mutta teeman prosessi ei mahdu ThemeForest-teemaan, ja niiden sekoittaminen merkitsee joko vieraan teeman asettamista ja sen jälkeen ihmettelyä lisäosista, tai oman CMS:n rakentamista sisällölle, jolle CMS jo on olemassa.

Tämä raja on myös kohta, jossa sanomme ei ”pienelle uudelleenrakentamiselle”, joka kolmannen kuukauden jälkeen on ydin, koska jos räätälöintejä tulee enemmän kuin konfigurointia, jos jokainen päivitys vaatii ensin meidän koodimme, jos valmistajan kenttä ei enää ole totuus, et ole enää kolmannella tiellä vaan rakennuksessa, joka piiloutuu tuotteen nimen taakse, ja silloin rehellisempää on nimetä rakennus ja laskea se rakennuksena, koska muuten maksat tuotteesta, jota ei enää voi päivittää, ja järjestelmästä, jota ei vielä voi ottaa haltuun.

Raha ja aika ovat muoto, eivät hinnasto

Räätälöity järjestelmä alkaa meillä 8 000 eurosta, ja koko kierto kestää tavallisesti 12–32 viikkoa, ja se on lähtöhinta, ei lasku, eikä 12 viikkoa ole samat ensimmäiset kolme kuukautta, joissa lupaamme käyttökelpoisen MVP:n: lähtöaikataulu on lyhin rakennus, MVP on askel, jonka jälkeen järjestelmää jo käytetään, ja 32 viikkoa on suuremman työn yläraja, joka mahtuu myös siihen, mitä yleisessä UKK:ssa kutsumme kuudeksi–kahdeksaksi kuukaudeksi suurelle räätälöidylle järjestelmälle. Laravel-sivu alkaa samoista 8 000 eurosta ja 6–24 viikosta, eikä se ole halvempaa räätälöityä ohjelmistoa: se on sivu ihmiselle, joka jo tietää, että työ on Laravelia, ei testi siitä, onko työ ylipäätään rakennus.

Näistä luvuista ei saa tulla lausetta ”räätälöity ohjelmisto on kallein valinta”, koska Moodlen käyttöönotto alkaa 15 000 eurosta, verkkokaupan Pro-versio maksaa 9 500 €, ja molemmat ovat räätälöidyn järjestelmän lähtöhinnan yläpuolella, koska toinen on suuren tuotteen käyttöönotto, toinen on kauppa varastolla ja B2B-hinnoilla. 8 000 euron lähtöhinnan vertaaminen Moodlen lähtöhintaan ”rakennuksena vastaan tuotteena” on väärää aritmetiikkaa, koska vertailtavissa ovat vain saman prosessin kaksi tietä, ja silloinkin molemmat puolet ovat lähtöhintoja, eivät loppusummia; suuremmissa epätyypillisissä töissä laskutamme tuntipohjaisesti viikoittaisella ylärajalla, koska kiinteä hinta merkitsee siellä yleensä riskilisää tai kiistaa laajuudesta, ja tuntihinta on 50 €.

Tilaus vastaan rakennus ei myöskään ole kaava, jossa N vuoden jälkeen toinen puoli voittaa automaattisesti, ja julkisen sektorin kulusuunnittelu nimeää sen, minkä näemme myös yksityisissä sopimuksissa: SaaS-maksu voi nousta käyttäjämäärän tai indeksoinnin mukana, integraatiot jäävät kustannuksiksesi, ja toimittajan vaihtoon tarvitaan poistumissuunnitelma, koska data on toimittajalla. Tämä ei ole prosentti rakennuksesta, jota tässä siteeraisimme, koska alaviite sellaisten lukujen takana vie toimittajien blogeihin, emmekä kirjoita sellaisia lukuja, mutta muoto jää: tilaus on rivi joka vuosi, rakennus on lähtöhinta plus ylläpito, eikä kumpikaan ole ilman riviä.

Datasäädös, jota unionissa sovelletaan 12. syyskuuta 2025 alkaen, auttaa viemään siirrettävissä olevan datan pilvipalvelusta ja kieltää toimittajaa asettamasta esteitä vaihdolle, mutta toiminnallista vastaavuutta se vaatii infrastruktuuripalvelulta, ei CRM:ltä, jonka vain ”siirrät”, eikä asetus 2023/2854 lupaa, että prosessi siirtyy tiedoston mukana. Yleisen tietosuoja-asetuksen 20 artikla siirtää henkilötiedot, jotka rekisteröity on toimittanut, ei sovellusta, ei konfiguraatiotasi eikä liiketoimintasääntöjä, siksi jos haluat järjestelmän, jonka voit siirtää toiselle kehittäjälle, se on lähdekoodi, jonka luovutamme, ei vienti vieraasta paneelista, ja tässä myös tämä jakso päättyy, koska seuraava lause olisi jo hinnasto, jota meillä ei tälle kysymykselle ole.

Mitä emme sano, kun puhumme räätälöidystä ohjelmistosta

Emme sano, että oma järjestelmä on aina viisaampi, että valmis tuote on niille, jotka ”eivät ole vielä kasvaneet”, tai että kolmen vuoden päästä rakennus on varmasti maksanut itsensä takaisin, koska sellainen käyrä ilman prosessiasi on keksintö. Artikkeli, joka rehellisen alun jälkeen kuitenkin päätyy siihen, että pitää ostaa rakennus, on mennyt liian pitkälle, ja olemme nähneet sen tarpeeksi usein, jotta pysähdymme tähän, koska rehellisyys on rajoite ja lyhyt testi on tavoite.

Emme myöskään sano, että Laravel on vastaus valmiin tuotteen kysymykseen, koska Laravel on tapa, jolla kirjoitamme, kun testi on jo antanut rakennuksen, ja kehyksen myyminen ihmiselle, joka tarvitsee Moodlen, merkitsee vasaran myymistä ihmiselle, joka tarvitsee hyllyn. Laravel-sivumme alkaa 8 000 eurosta ja puhuu rajapinnoista, jonoista ja testeistä, mutta tämä artikkeli puhuu siitä, tarvitsetko tätä sivua ylipäätään, ja niiden sekoittaminen merkitsee, että valitset työkalun ennen kuin olet valinnut työn.

Emme sano myöskään sitä, että määrittelytyöpaja on piilotettu tapa johdattaa sinut rakennukseen, koska työpajan tulos on suunnitelma, joka jää hyödylliseksi silloinkin, jos päätät olla käyttämättä meitä, ja joskus suunnitelma sanoo: ota tuote, jonka olet jo nimennyt, ja me otamme sen käyttöön, tai sen ottaa käyttöön joku muu. Jos tämä lause kuulostaa sinusta menetetyltä kaupalta, se johtuu siitä, että se on menetetty kauppa, ja häviämme mieluummin rakennuksen, jossa pitäisi kirjoittaa vielä yksi CRM, kuin saamme asiakkaan, joka vuoden päästä kysyy, miksi hän ylläpitää järjestelmää, jonka olisi voinut tilata.

Julkisissa hankinnoissa tämä testi ei toimi samalla tavalla kuin yksityisessä yrityksessä eikä siirry sinne sellaisenaan, koska valtion suunnittelussa JIT-ehdot erottavat valmisohjelmiston tilaajan sovelluksesta, ja se kuuluu hankintaan, ei tähän lauseeseen, mutta yksityisellä puolella kyse on prosessistasi ja hinnastostamme. Molemmat puolet voivat päätyä samaan vastaukseen, eivätkä ne päädy siihen siksi, että toinen olisi toisen laki.

Miten tämä päätös tehdään meillä

Työ alkaa kahden–kolmen päivän määrittelytyöpajalla, jossa käymme tiimisi kanssa läpi prosessit, käyttäjäroolit, riskit ja MVP:n laajuuden, eikä se ole kalvoaamu vaan työ, jonka jälkeen voimme sanoa, mahtuuko prosessi valmiiseen työkaluun, vaatiiko se kolmannen tien vai onko se rakennus. Jos vastaus on tuote, työpaja on maksanut itsensä tällä lauseella; jos vastaus on rakennus, seuraava askel ei ole koodi.

Ennen tuotantokoodia valmistelemme kahdessa–kolmessa viikossa klikattavan prototyypin, koska siinä mielen muuttaminen on halvempaa kuin valmiissa järjestelmässä, eikä prototyyppi ole ”jotta hallitukselle olisi jotain näytettävää” vaan paikka, jossa näet, että hintataulu, jonka eilen nimesit, on itse asiassa toinen taulu, ja jossa tämä oivallus maksaa päiviä, ei kuukausia. Vasta sitten alkaa kehitys: ensimmäisten kolmen kuukauden aikana rakennamme MVP:n, jota voi oikeasti käyttää, ja sen jälkeen laajennamme iteratiivisesti, kahden viikon sprinteissä, joista jokaisen jälkeen on demo.

Työn päättyessä saat lähdekoodin, dokumentaation ja infrastruktuurin konfiguraation ja voit siirtää ne toiselle kehittäjälle, eikä se ole lupaus siitä, että siirto on miellyttävä, vaan lupaus siitä, ettet ole sidottu meidän tiliimme. Suuremmissa projekteissa pysymme tuntipohjaisessa mallissa viikoittaisella ylärajalla, ja MVP:n rajan silti määrittelemme tarkasti, koska muuten ”agile” muuttuu sanaksi, jonka taakse laajuus katoaa, ja jos työpajan jälkeen menet toista tietä, suunnitelma jää sinulle, kuten olemme kirjoittaneet palvelusivulle, eikä tämä artikkeli muuta sitä.

Ennen kuin kirjoitat meille, kirjoita prosessi yhdelle sivulle ilman työkalun nimeä ja merkitse, mitä rivejä et saa luovuttaa vieraalle julkaisulle: jos sivu on tyhjä tai siinä on vain ”että olisi oma järjestelmä”, tarvitset tuotteen, ja sanomme sen myös, mutta jos sivulla on prosessi, jota kilpailija ei voi ostaa valmiina työkaluna, silloin on syytä puhua rakentamisesta. Kirjoita meille, jos haluat, että luemme tämän sivun kanssasi ja sanomme, kumpi puoli on sinun, myös silloin kun vastaus on ottaa tuote, jonka olet jo nimennyt.