Sovellusprojektin tarjouspyyntö: mitä sisällyttää?

Sovellusprojektin tarjouspyyntö on dokumentti, joka ratkaisee projektin onnistumisen jo ennen kuin yhtään koodiriviä on kirjoitettu. Hyvin laadittu tarjouspyyntö auttaa löytämään oikean kehityskumppanin, pitämään budjetin hallinnassa ja välttämään kalliita väärinkäsityksiä.

Tässä artikkelissa käymme läpi, mitä hyvä tarjouspyyntö sisältää ja miten ohjelmistoprojektin kilpailutus kannattaa hoitaa käytännössä.

Miksi tarjouspyynnöllä on väliä?

Epämääräinen tarjouspyyntö tuottaa epämääräisiä tarjouksia. Jos toimittajat eivät ymmärrä mitä haluat, he joko hinnoittelevat riskivaralla ylöspäin tai tarjoavat jotain aivan muuta kuin tarvitset. Kummassakin tapauksessa häviät.

Selkeä tarjouspyyntö tekee tarjousten vertailusta helppoa. Kun jokainen toimittaja vastaa samoihin kysymyksiin, näet nopeasti kuka ymmärtää tarpeesi ja kuka ei. Samalla säästät omaa aikaasi, koska jatkokysymyksiä tulee vähemmän.

Tarjouspyyntö on myös työkalu sinulle itsellemäsi. Sen kirjoittaminen pakottaa miettimään, mitä projektilta oikeasti halutaan. Moni epäselvyys selviää jo tässä vaiheessa.

Projektin tausta ja tavoitteet

Aloita kertomalla kuka olette ja miksi projekti on ajankohtainen. Toimittajan on helpompi tarjota oikeanlaista ratkaisua, kun hän ymmärtää liiketoimintanne kontekstin.

Kuvaile selkeästi projektin tavoitteet. Älä kirjoita pelkästään "tarvitsemme sovelluksen", vaan kerro mitä ongelmaa sovellus ratkaisee ja miten onnistumista mitataan. Konkreettiset tavoitteet ohjaavat kehitystyötä oikeaan suuntaan.

Määrittele myös kohdekäyttäjät. Kuka sovellusta käyttää? Minkälaisissa tilanteissa? Kuinka usein? Käyttäjien ymmärtäminen vaikuttaa suoraan teknisiin ratkaisuihin ja käyttöliittymäsuunnitteluun.

Toiminnalliset ja tekniset vaatimukset

Listaa sovelluksen keskeiset toiminnot ja ominaisuudet. Priorisoi ne kolmeen kategoriaan: välttämättömät, tärkeät ja toivotut. Tämä auttaa toimittajia ehdottamaan vaiheistusta ja MVP-lähestymistapaa.

Tekniset vaatimukset kannattaa kuvata sillä tarkkuudella, joka on relevanttia. Kerro esimerkiksi:

• Tukeeko sovelluksen mobiili, desktop vai molemmat?
• Onko olemassa olevia järjestelmiä, joihin pitää integroitua?
• Millaisia tietoturva- tai tietosuojavaatimuksia on (GDPR, autentikaatio)?
• Onko suorituskykyvaatimuksia (käyttäjämäärät, vasteajat)?
• Pitääkö noudattaa tiettyä teknologiapinoa vai onko toimittaja vapaa valitsemaan?

Älä silti yritä kirjoittaa teknistä spesifikaatiota itse, jos et ole tekninen. Kerro mieluummin mitä sovelluksen pitää tehdä. Hyvä toimittaja osaa kääntää liiketoimintavaatimukset teknisiksi ratkaisuiksi.

Budjetti ja aikataulu

Budjetin kertominen tarjouspyynnössä on usein kiistanalainen aihe. Monet pelkäävät, että toimittajat käyttävät koko budjetin. Käytännössä budjettihaarukan ilmoittaminen on kuitenkin kaikkien etu. Se karsii pois toimittajat, joiden hintataso ei sovi, ja auttaa jäljelle jääviä ehdottamaan realistisia ratkaisuja.

Jos et tiedä paljonko sovellus maksaa, tutustu ensin ohjelmistokehityksen tyypillisiin kustannuksiin. Se antaa pohjan keskustelulle.

Aikataulusta kannattaa kertoa vähintään toivottu julkaisuajankohta ja mahdolliset kiinteät deadlinet. Onko esimerkiksi tapahtuma, sesonki tai lakimuutos, joka määrittää aikataulun? Kerro se avoimesti.

Arviointikriteerit

Kerro tarjouspyynnössä, millä perusteella valitset toimittajan. Tämä tekee prosessista läpinäkyvän ja ohjaa toimittajia korostamaan oikeita asioita tarjouksissaan.

Tyypillisiä arviointikriteereitä ovat:

• Osaaminen ja referenssit – Onko toimittaja tehnyt vastaavia projekteja?
• Tekninen lähestymistapa – Miten toimittaja ratkaisisi ongelman?
• Hinta-laatusuhde – Ei välttämättä halvin, vaan paras vastine rahalle
• Kommunikaatio – Miten sujuvasti yhteistyö toimii jo tarjousvaiheessa?
• Ylläpito ja jatkokehitys – Mitä tapahtuu julkaisun jälkeen?

Kehityskumppanin valinta pelkän hinnan perusteella on riskialtista. Halvimman tarjouksen taustalla voi olla liian optimistinen arvio, jonka kustannukset nousevat myöhemmin.

Yleisimmät virheet tarjouspyynnöissä

Liian laaja scope ilman priorisointia. Jos kaikki on "pakollista", mikään ei ole priorisoitu. Toimittaja ei voi ehdottaa järkevää vaiheistusta, ja hinta-arviot paisuvat.

Puuttuvat liiketoimintatavoitteet. Tarjouspyynnössä kuvataan ominaisuuksia, mutta ei kerrota miksi ne ovat tärkeitä. Toimittaja ei voi arvioida, onko ehdotettu ratkaisu oikeasti paras.

Epärealistinen aikataulu. "Tarvitaan kolmen viikon päästä" monimutkaisen sovelluksen kohdalla karkottaa ammattimaiset toimittajat. Jäljelle jäävät ne, jotka lupaavat liikaa.

Liian tarkka tekninen määrittely. Jos päätät etukäteen jokaisen teknisen yksityiskohdan, et anna toimittajalle mahdollisuutta tuoda omaa osaamistaan peliin. Kerro mitä tarvitset, älä miten se pitää toteuttaa.

Tarjousten vertailu

Kun tarjoukset saapuvat, vertaile niitä systemaattisesti. Tee taulukko, jossa arvioit jokaisen tarjouksen samoilla kriteereillä.

Kiinnitä huomiota siihen, miten toimittaja on ymmärtänyt tarpeesi. Hyvä tarjous ei ole kopio tarjouspyynnöstäsi vaan osoittaa, että toimittaja on ajatellut ongelmaa itsenäisesti. Se voi sisältää ehdotuksia, joita et itse ollut huomannut.

Pyydä kärkiehdokkailta esittely tai workshop ennen päätöstä. Tunnin keskustelu kertoo yhteistyön sujuvuudesta enemmän kuin kymmenen sivua dokumentaatiota.

Varoitusmerkit tarjouksissa

Ole varuillasi, jos tarjous sisältää näitä piirteitä:

• Epämääräinen hinnoittelu – "Arvioidaan projektin edetessä" ilman mitään raameja
• Liian halpa hinta – Jos yksi tarjous on puolet muiden hinnasta, kysy miksi
• Ei kysymyksiä – Toimittaja, joka ei kysy mitään, ei todennäköisesti ole perehtynyt tarjouspyyntöösi
• Geneerinen tarjous – Kopioidulta vaikuttava teksti ilman viittauksia sinun projektiisi
• Epäselvä projektinhallinta – Ei mainintaa sprinteistä, raportoinnista tai kommunikaatiokäytännöistä
• Koodin omistajuus epäselvä – Varmista aina, että sinä omistat lähdekoodin

Yhteenveto

Hyvä sovellusprojektin tarjouspyyntö on investointi, joka maksaa itsensä takaisin projektin jokaisessa vaiheessa. Se ei tarvitse olla satasivuinen dokumentti. Selkeä kuvaus tavoitteista, käyttäjistä, vaatimuksista ja reunaehdoista riittää.

Ohjelmistoprojektin kilpailutus onnistuu parhaiten, kun tarjouspyyntö on kirjoitettu toimittajan näkökulmasta ymmärrettäväksi. Kerro mitä haluat saavuttaa. Anna toimittajien kertoa, miten he sen tekisivät.