7 virhettä, joita pienyritykset tekevät hankkiessaan räätälöityä ohjelmistoa

Useimmat pienyritykset, jotka polttavat näppinsä räätälöidyssä ohjelmistoprojektissa, eivät polta niitä huonoihin ohjelmoijiin. Ne polttavat näppinsä viikkoja ennen kuin ohjelmointia on edes aloitettu — aloituspalaverissa, sähköpostiketjussa, kädenpuristuksessa — päätökseen, joka tuntui silloin pieneltä. Siihen mennessä kun koodi saapuu, virhe on jo leivottu sisään. Hyvä uutinen on, että nämä virheet ovat tylsän toistuvia, mikä tarkoittaa, että ne ovat vältettävissä, jos tietää miltä ne näyttävät.

Olen seurannut monia tällaisia projekteja sisältä, pöydän molemmilta puolilta. Joistakin tuli työkaluja, joita ilman yritys ei voi kuvitella toimivansa. Toisista tuli puolivalmis kirjautumisnäkymä, kireä laskuriita ja yrittäjä, joka vannoo ettei enää koskaan tee räätälöityä. Turhauttavaa on se, kuinka vähän nämä kaksi lopputulosta erotti toisistaan. Teknologia ei ollut juuri koskaan ongelma. Teknologiaa ympäröivät päätökset olivat lähes aina.

Tässä siis seitsemän virhettä, jotka näen yhä uudelleen, kun pienyritys tilaa räätälöityä ohjelmistoa. Yhdenkään välttäminen ei vaadi teknistä taustaa. Ne vaativat vain sen tietämistä, että ne ovat olemassa, ennen kuin allekirjoitat mitään.

Virhe 1: Ratkaisun ostaminen ennen kuin ymmärtää ongelman

Kallein virhe tapahtuu ensimmäisenä, ja se kuulostaa vaarattomalta: ”Tarvitsemme sovelluksen, joka tekee X:n.” Siihen mennessä kun joku sanoo sen ääneen, hän on yleensä jo päättänyt ratkaisun muodon — koontinäytön, portaalin, mobiilisovelluksen — ilman että kukaan on kirjoittanut todellista ongelmaa selkokielellä. Toteutus toimittaa sitten uskollisesti väärän asian, ja kauniisti.

Hyvä ohjelmisto lähtee ongelman määrittelystä, ei ominaisuuslistasta. ”Toimistotiimimme näppäilee jokaisen tilauksen sähköpostista kirjanpitojärjestelmään, ja siihen menee kahdelta ihmiseltä puoli päivää” on ongelma. ”Tarvitsemme räätälöidyn CRM:n” on arvaus ratkaisuksi ongelmaan, jota kukaan ei vaivautunut nimeämään. Ensimmäinen voidaan ratkaista halvalla ja mitata. Jälkimmäinen on avoin kutsu kuluttaa rahaa.

Virhe 2: Yrittää rakentaa kaikki kerralla

Räätälöity ohjelmisto tuntuu kerran vuosikymmenessä tehtävältä hankinnalta, joten ihmiset yrittävät ahtaa vuosikymmenen verran toiveita ensimmäiseen versioon. Jokainen osasto lisää pyyntönsä. Jokainen ”kun nyt kerran olemme tässä” saa kyllä-vastauksen. Laajuus paisuu, aikataulu kolminkertaistuu, ja projekti romahtaa oman kunnianhimonsa alle kauan ennen kuin kukaan pääsee käyttämään sitä.

Onnistuvat yritykset tekevät päinvastoin. Ne valitsevat ongelman yksittäisen kivuliaimman siivun ja rakentavat sen ensin — todellisen, toimivan asian tuotantoon parissa kuukaudessa. Sitten ne antavat todellisen käytön kertoa, mitä seuraavaksi. Tämä ei ole vain halvempaa; se on turvallisempaa. Opit, toimiiko idea, kun panos on vielä pieni, sen sijaan että huomaisit puolen vuoden ja ison laskun jälkeen suunnitelleesi väärän asian.

Tämän alla on karu totuus: et oikeastaan vielä tiedä, mitä tarvitset. Kukaan ei tiedä alussa. Ymmärryksesi ongelmasta muuttuu sillä hetkellä, kun todelliset ihmiset koskettavat todellista työkalua. Kaiken rakentaminen etukäteen lukitsee varhaisimmat, vähiten tietoon perustuvat arvauksesi. Siivuittain rakentaminen pitää sinut joustavana — ja pitää budjetin hallinnassa, kun vielä opettelet.

Virhe 3: Valinta pelkän hinnan perusteella

Saat kolme tarjousta. Yksi on dramaattisesti halvempi kuin muut. Helpotus — otat sen. Tämä on yksi luotettavimmista tavoista muuttaa pieni projekti kalliiksi, koska halpa tarjous ei juuri koskaan tarkoita, että työ olisi halvempaa. Se tarkoittaa yleensä, että osapuolet ymmärsivät tehtävän eri tavalla.

Matala luku usein viestii yhdestä muutamasta asiasta: toimittaja aliarvioi laajuuden, koska ei kysynyt tarpeeksi, hän aikoo tehdä katteensa myöhemmin muutospyynnöillä, tai hän on kokematon eikä vielä tiedä, mitä ei tiedä. Mikään näistä ei pääty hyvin sinun kannaltasi. Otsikkohinta on tarjouksen vähiten hyödyllinen luku. Tärkeää on, ymmärtääkö toimittaja selvästi ongelmasi, kysyykö epämukavia kysymyksiä ja onko rehellinen siitä, mitä ei sisälly.

Virhe 4: Unohtaa, ettei ohjelmisto ole kertaostos

Räätälöityä ohjelmistoa myydään ja ostetaan usein kuin huonekalua: maksat kerran, omistat sen ikuisesti. Niin ei ole. Ohjelmisto elää liikkuvassa maailmassa — käyttöjärjestelmät päivittyvät, selaimet muuttuvat, tietoturvapäivitykset saapuvat, yrityksesi muuttuu, työkalut joihin liityt muuttavat sääntöjään. Työkalu, jota kukaan ei ylläpidä, lakkaa hiljalleen toimimasta ja hajoaa sitten pahimpana mahdollisena hetkenä.

Tämä kolahtaa pienyrityksiin pahasti, koska ylläpitokustannus on näkymätön allekirjoitushetkellä. Vertaat kahta tarjousta toteutushinnan perusteella etkä koskaan kysy kysymystä, jolla on enemmän merkitystä: mitä maksaa pitää tämä hengissä ja kunnossa vuosittain? Hosting, päivitykset, pienet korjaukset, satunnainen muutos yrityksesi kehittyessä — varaudu siihen normaalina, jatkuvana kulueränä, kuten teet vakuutusten tai kirjanpidon kanssa. Se on yleensä maltillinen, mutta vain jos osaat odottaa sitä.

Virhe 5: Jättää vaatimukset epämääräisiksi ja vaille omistajaa

”Te olette asiantuntijoita, rakentakaa vain jotain hyvää” kuulostaa anteliaalta. Itse asiassa juuri näin projektit ajautuvat sivuun. Ne, jotka ymmärtävät liiketoimintaasi parhaiten, olette te ja tiiminne — eivät kehittäjät. Jos luovutat sumean briiffin ja katoat, toimittaja täyttää aukot parhailla arvauksillaan, ja huomaat ne arvaukset pahimpaan aikaan: toimituksessa, jolloin niiden muuttaminen on kalleinta.

Kaksi roolia on täytettävä teidän puolellanne, ja pienyritykset jättävät rutiininomaisesti kummankin täyttämättä. Ensimmäinen on yksi päättäjä — yksi henkilö, joka voi sanoa kyllä, ratkaista erimielisyydet osastojen välillä eikä ole liian kiireinen vastaamaan kysymyksiin viikkokausiin. Toinen on halu olla täsmällinen niistä osista, joilla on merkitystä: reunatapaukset, se outo poikkeus, jonka yrityksenne on aina hoitanut käsin, sääntö jonka kaikki tietävät mutta jota kukaan ei ole kirjannut. Juuri sen ohjelmiston on saatava oikein.

Virhe 6: Olla kysymättä, kuka omistaa koodin ja datan

Tämä on se hiljainen, ja se sattuu eniten vuosia myöhemmin. Maksat räätälöidystä ohjelmistosta ja oletat sen olevan sinun. Sitten suhde toimittajaan happanee, tai hän nostaa hintoja, tai hän yksinkertaisesti katoaa — ja huomaat, ettet pääse mihinkään. Sinulla ei ole lähdekoodia. Data asuu järjestelmässä, johon vain hänellä on pääsy. Koko toimintasi riippuu nyt yrityksestä, johon et enää luota, eikä sinulla ole mitään neuvotteluvoimaa.

Mikään tästä ei vaadi lakimiestä estettäväksi. Se vaatii kolme yksinkertaista kysymystä, jotka esitetään ennen kuin aloitat, kun sinulla on vielä kaikki neuvotteluvoima: Kuka omistaa lähdekoodin, kun tämä on valmis? Voinko viedä kaiken datani käyttökelpoisessa muodossa milloin tahansa haluan? Ja jos tiet eroavat, mitä tarkalleen otan mukaani? Maineikas kumppani vastaa näihin värähtämättä. Epäröinti tässä on koko prosessin suurin varoitusmerkki.

• Sovi kirjallisesti, että omistat lähdekoodin tai sinulla on siihen selkeä, reilu lisenssi.
• Varmista, että voit viedä oman datasi standardimuodossa pyynnöstä, ilman lupaa.
• Varmista, että työ on dokumentoitu riittävän hyvin, jotta toinen kehittäjä voisi jatkaa siitä.
• Vältä omistajakohtaista lukkiutumista siellä, missä yksinkertainen, tunnettu teknologia tekisi saman työn.
• Sovi etukäteen, mitä hostingille ja tileille tapahtuu, jos joskus vaihdat toimittajaa.

Virhe 7: Kohdella käyttöönottoa maaliviivana

Ohjelmisto on toimitettu, se toimii, kaikki ovat helpottuneita. Projekti julistetaan valmiiksi. Puoli vuotta myöhemmin puolet tiimistä on hiljaa luisunut takaisin vanhaan taulukkoon, ja kallis uusi työkalu on kahden ihmisen käytössä yhteen asiaan. Toteutus onnistui. Käyttöönotto epäonnistui — ja nämä ovat täysin eri ongelmia.

Ihmiset eivät vastusta uusia työkaluja siksi, että ovat tyhmiä tai itsepäisiä. He vastustavat, koska uusi tapa on tuntematon ja vanha tapa toimii vielä, jotenkuten. Sen voittaminen vaatii tarkoituksellista ponnistelua, jota kukaan ei budjetoinut: hieman koulutusta, selkeä syy miksi muutos auttaa juuri heitä, joku joka vastaa tyhmiin kysymyksiin tuomitsematta ensimmäisinä viikkoina, ja luja päätös jättää vanha tapa pois käytöstä, jotta ei ole turvasatamaa, johon livahtaa takaisin.

1. 1
   Ota käyttöön ensin pienelle ryhmälle

   Lanseeraa työkalu muutamalle halukkaalle ennen koko tiimiä. He löytävät karkeat reunat ja muuttuvat sisäisiksi puolestapuhujiksesi.
2. 2
   Näytä henkilökohtainen hyöty, ei yrityksen hyöty

   ”Tämä säästää yritykseltä rahaa” ei motivoi ketään. ”Tämä tarkoittaa, ettet enää näppäile osoitteita kahdesti” saa ihmiset mukaan.
3. 3
   Nimeä henkilö, jolta kysyä

   Ensimmäisen kuukauden ajan joku omistaa tyhmät kysymykset. Kitka ensimmäisellä viikolla on se, mikä tappaa käyttöönoton lopullisesti.
4. 4
   Sammuta vanha tapa oikeasti

   Niin kauan kuin vanha taulukko on olemassa, ihmiset käyttävät sitä jatkossakin. Kun uusi toimii, poista varavaihtoehto käytöstä — lempeästi mutta selkeästi.

Kokonaiskuva: ostajan ajattelutapa

Lue nuo seitsemän uudelleen, ja niiden läpi kulkee yksi punainen lanka. Lähes mikään ei ole teknistä. Ne koskevat selkeyttä, omistajuutta ja maltillisuutta — ongelmasi tuntemista ennen ostoksille lähtöä, pienin askelin rakentamista, toimittajien arvioimista ymmärryksen eikä hinnan perusteella, työkalun koko elinkaaren huomioimista eikä vain sen syntymää, mukana pysymistä, oman ulospääsysi suojaamista ja käyttöönoton kohtelemista todellisen työn alkuna.

Räätälöity ohjelmisto on aidosti yksi parhaista sijoituksista, jonka pienyritys voi tehdä, kun se on kasvanut ulos kaikkien jakamista valmisohjelmistoista. Järjestelmä, joka on muotoiltu tarkalleen sen mukaan, miten te työskentelette, sen sijaan että se pakottaisi yrityksenne vääntäytymään jonkun toisen tuotteen ympärille, on todellinen ja kestävä etu. Yritykset, jotka pääsevät sinne, eivät ole niitä, joilla on suurimmat budjetit. Ne ovat niitä, jotka välttivät yllä olevat seitsemän virhettä — ja se on harkinnan, ei rahan asia.

Yleisiä kysymyksiä