Hyvä ohjelmistoprojektin kuvaus kertoo ongelman, käyttäjät, mukana olevat järjestelmät ja sen, miltä onnistuminen näyttää, ja jättää ratkaisun kumppanien ehdotettavaksi. Lähetä jokaiselle kumppanille sama kuvaus budjettihaarukan ja selkeän luettelon kanssa siitä, mikä on kiinteää, niin saamasi tarjoukset ovat riittävän tarkkoja vertailtaviksi.
Projektikuvauksen tehtävä on tehdä vastauksista vertailukelpoisia
Projektikuvauksella on yksi tehtävä: antaa usean kumppanin ymmärtää ongelmasi niin hyvin, että ne voivat ehdottaa tavan ratkaista se ja arvion, johon voit luottaa. Jos kukin kumppani täyttää aukot omilla oletuksillaan, tarjoukset eroavat laajuudeltaan eivätkä laadultaan, ja halvin on usein se, joka oletti vähiten.
Kuvauksen pitää siis olla tarkka ongelmasta ja vaatimaton ratkaisusta. Kuvaa, minkä pitää olla totta, kun projekti on valmis, ja anna kumppanien selittää, miten ne pääsisivät sinne. Niiden vastaukset tähän avoimeen osaan ovat hyödyllisintä, mitä tulet lukemaan.
Aloita liiketoimintaongelmasta ja siitä, miten arvioit onnistumisen
Aloita syystä, jonka vuoksi projekti on olemassa: mikä ei toimi nyt, keihin se vaikuttaa ja mitä sen jättäminen ennalleen maksaa sinulle. Kun kerrot, että toimintatiimisi näppäilee jokaisen sähköpostilla tulleen tilauksen käsin ERP-järjestelmään, kumppani saa paljon enemmän tietoa kuin pyynnöstä saada tilaustenhallintaportaali.
Kerro sitten, miten arvioit onnistumisen. Valitse muutama havaittava tulos, kuten säästetty aika tilausta kohden, virheet, jotka eivät enää päädy asiakkaille, tai päivämäärä, johon mennessä vanha järjestelmä voidaan sammuttaa. Näistä kriteereistä tulee myöhemmin välitavoitteiden hyväksymiskriteerit, joten kirjoita ne muotoon, jonka joku voi tarkistaa.
Kuvaa käyttäjät, järjestelmät ja data ennen ominaisuuksia
Integraatio- ja datatyö on helppo aliarvioida, kun kumppani ei näe sitä. Ennen kuin luettelet ominaisuuksia, kuvaa, kuka ohjelmistoa käyttää, minkä järjestelmien kanssa sen on toimittava ja mitä tietoja se käsittelee. Tämän osan aukot palaavat myöhemmin muutospyyntöinä.
- Käyttäjät: keitä he ovat, suunnilleen kuinka monta heitä on sekä missä ja millä laitteilla he työskentelevät.
- Nykyiset järjestelmät: mitä ne ovat, kuka ne omistaa ja tarjoavatko ne dokumentoidun API:n vai vain tietokannan ja tiedostovientejä.
- Data: mikä on henkilötietoa, luottamuksellista tai säänneltyä, missä se on nyt ja kuinka paljon siitä on siirrettävä.
- Ylläpito: kuka ylläpitää ohjelmistoa julkaisun jälkeen ja mitä palvelin- tai pilvisääntöjä yritykselläsi jo on.
- Rajoitteet: kielet, saavutettavuustarpeet, tietoturvastandardit ja mahdollinen määräaika, joka ei voi joustaa, perusteluineen.
Kerro budjettihaarukka ja määräaika, jolla on oikeasti merkitystä
Monet ostajat pidättävät budjetin nähdäkseen, mitä kumppanit ehdottavat. Tuloksena on tarjouksia eri projekteista: yksi kumppani suunnittelee minimin, toinen kaiken, mitä mainitsit. Haarukka, laajakin, antaa jokaisen kumppanin ehdottaa parasta siihen mahtuvaa projektia ja kertoa suoraan, jos se ei riitä.
Tee sama ajan suhteen. Kerro, mikä päivämäärä on kiinteä ja miksi, kuten päättyvä sopimus tai viranomaisen määräaika, ja mitkä päivämäärät ovat vain toiveita. Kumppani voi suunnitella ehdottoman päivämäärän mukaan vain, jos se tietää, mikä se on.
Merkitse, mikä on kiinteää, ja jätä loput avoimiksi
Merkitse jokainen vaatimus kiinteäksi, toivotuksi tai avoimeksi. Kiinteä tarkoittaa, että tarjous ei ole pätevä ilman sitä, kuten tietojen säilytys EU:ssa tai kirjautuminen nykyisen identiteetintarjoajasi kautta. Toivottu tarkoittaa, että sinulla on syy, mutta harkitsisit vaihtoehtoa. Avoin tarkoittaa, että haluat kumppanin suosituksen.
Jätä teknologia avoimeksi, ellei sinulla ole todellista syytä lukita sitä, kuten oma tiimi, joka ylläpitää koodia, tai alusta, johon yrityksesi on standardoinut. Kun lukitset valinnan, kerro miksi, jotta kumppanit eivät käytä tarjoustaan sen kyseenalaistamiseen.
Pyydä lopuksi jokaista kumppania vastaamaan samalla rakenteella: sen käsitys ongelmasta, lähestymistapa, vaiheet ja välitavoitteet, oletukset, riskit, tiimi ja kaupallinen malli. Yhteinen rakenne tekee tarjouksista käytännössä vertailukelpoisia.
Virheet, jotka tekevät tarjouksista mahdottomia vertailla
Moni käyttökelvoton tarjous on vastaus kuvaukseen, joka kutsui sen esiin. Poista nämä mallit ennen kuin lähetät omasi.
- Ominaisuusluettelo ilman ongelmakuvausta, jolloin jokainen kumppani arvailee prioriteettejasi.
- Pitkä määrittely, joka lukitsee ratkaisun ennen kuin kukaan on tutkinut ongelmaa.
- Ei mainintaa nykyisistä järjestelmistä tai tietojen siirrosta, jotka palaavat sitten muutospyyntöinä.
- Lisätietoja annettu vain osalle kumppaneista puheluissa, jolloin niiden tarjoukset vastaavat eri kysymyksiin.
- Sanat kuten yksinkertainen, vakio tai kuten tunnettu sovellus, jotka tarkoittavat jokaiselle lukijalle eri asiaa.
- Ei määräaikaa kysymyksille, tai vastaukset jaetaan vain kysyneelle kumppanille.
Kutsu kysymyksiä ja lue ne osana arviointia
Anna kumppaneille määräaika kysymyksille, vastaa kirjallisesti ja lähetä jokainen vastaus kaikille. Kysymykset kertovat jo itsessään jotain: kumppani, joka kysyy datastasi, käyttäjistäsi ja hyväksymiskriteereistäsi, ajattelee jo toimitusta.
Jos ongelma on vielä liian epävarma kuvattavaksi hyvin, kerro se ja pyydä täyden tarjouksen sijaan lyhyttä, maksullista esiselvitysvaihetta. Arvauksiin perustuva kiinteä tarjous kätkee tuntemattomat riskimarginaaliinsa; esiselvitys korvaa arvaukset tosiasioilla. Jos haluat kehittäjien lukevan kuvauksesi tai vastaavan siihen, voit lähettää sen Aloita projekti -lomakkeellamme.
Tärkeimmät havainnot
- Kuvaa ongelma, käyttäjät ja se, miltä onnistuminen näyttää, ja jätä ratkaisu avoimeksi.
- Integraatio- ja datatyö on helppo aliarvioida, joten luettele jokainen mukana oleva järjestelmä ja tietoaineisto.
- Kerro budjettihaarukka ja se, mikä määräaika on kiinteä ja miksi.
- Merkitse jokainen vaatimus kiinteäksi, toivotuksi tai avoimeksi ja pyydä tarjoukset yhdellä yhteisellä rakenteella.
- Vastaa kysymyksiin kirjallisesti ja jaa jokainen vastaus jokaiselle kumppanille.
UKK
Kuinka pitkä ohjelmistoprojektin kuvauksen pitäisi olla?
Niin pitkä, että se kattaa ongelman, käyttäjät, järjestelmät, datan, rajoitteet, budjettihaarukan ja aikataulun, mikä useimmissa projekteissa mahtuu muutamalle sivulle. Jos se kasvaa paljon pidemmäksi, se luultavasti kuvaa ratkaisua eikä ongelmaa.
Kannattaako budjetti kertoa ohjelmistokumppaneille?
Kyllä, haarukkana. Ilman sitä kumppanit ehdottavat hyvin erikokoisia projekteja, etkä voi verrata niitä. Haarukka antaa jokaisen kumppanin näyttää, mitä se tekisi sen puitteissa, ja kertoa rehellisesti, jos se ei riitä.
Kannattaako kuvauksen perusteella pyytää kiinteää hintaa?
Vain jos kuvaus kertoo työstä niin yksityiskohtaisesti, että sen voi arvioida. Jos keskeisiä kysymyksiä on vielä avoinna, pyydä kiinteähintaista esiselvitysvaihetta tai arviohaarukkaa kirjattuine oletuksineen, ja lukitse toteutuksen hinta, kun tuntemattomat on ratkaistu.