Kuinka arvioida ohjelmiston kustannusarvio (muille kuin teknisille henkilöille)

On melko vaikea arvioida ohjelmistoprojektia ja laittaa siihen hintalappu.

Artikkelissa joitain haasteita ja miten arvioida ohjelmistojen kustannusarvioita.

Johdanto

Usein mainittavan kaaosraportin mukaan noin 30 prosenttia kaikista ohjelmistoprojekteista epäonnistuu. Tämä tarkoittaa, että joko hankkeen kesto on liian pitkä tai budjettia ei pidetä.

Tässä joitain haasteita ohjelmistoprojekteissa:

1) Tarkkoja tarkkoja vaatimuksia on vaikea tarkistaa

Jos haluat rakentaa mittatilaustyönä suuren talon, hinta voidaan vahvistaa vain, jos jokainen työn osa on arvioitu asianmukaisesti. Viimeiseen käytettyyn ruuviin asti.

Arkkitehti luo tarkan suunnitelman, jossa koko talo kopioidaan joko paperille tai nykyään usein 3D-mallina. Ja näissä ohjelmissa voidaan laskea, kuinka monta ruuvia jne. Tarvitaan talon rakentamiseen.

Näiden tietojen avulla on mahdollista antaa tarkka arvio talonrakennushankkeesta.

Mutta tiedämme myös: Hyvin suurissa rakennusprojekteissa hinta-arviot eivät yleensä ole oikein. Ja sen, jonka piti maksaa 500 miljoonaa euroa, maksaa lopulta vähintään 5 miljardia euroa. Berliinin lentokenttä, Hampurin Elbphilharmonie ja Saksan Stuttgartin päärautatieasema ovat kolme esimerkkiä, useimmissa tapauksissa kustannukset alenivat vähintään miljardilla eurolla.

Stuttgartin päärautatieaseman kohdalla arkkitehdin palkkio oli noin 36 miljoonaa euroa. Vaikka arkkitehdille maksettiin niin suuri summa. Projektin kustannusarvio oli noin miljardi euroa.

Samanlaisia haasteita voidaan nähdä ohjelmistoprojekteissa.

Varsinkin kun ei-tekniset ihmiset ovat mukana ohjelmiston tai verkkoprojektin vaatimusten siirtämisessä. Yleensä projektin kuvaukset sisältävät vain muutaman rivin sähköpostin sisällä. Tai puhelinsoitto, jossa vaadittu ratkaisu on hahmoteltu.

Joitakin esimerkkisivustoja annetaan viitteeksi. Harvoin näitä esimerkkisivustoja on rakennettu monien vuosien ajan, ja ne maksavat satoja tuhansia euroja, joskus miljoonia.

Mutta verkkosovelluksen tai ohjelmistoratkaisun budjetti on noin 4 000 – 40 000 euroa, ja se tulisi rakentaa kahden kuukauden kuluessa, enintään 3 kuukaudessa. (Tämä on tavallisesti ei-IT-henkilön toive, joka kysyy hintaa).

Todellisuus on tämä: Ilman asiakkaan yksityiskohtaista tiedusteluasiakirjaa, joka on noin 10-50 sivua, ja IT-yrityksen laatiman yksityiskohtaisen ehdotuksen, joka perustuu kysyttyyn asiakirjaan, projektin hintaa ei voida määrittää.

Ja vaikka ehdotusasiakirja on tarkka. Yleensä vaatimukset muuttuvat projektin aikana, mikä tekee ehdotusten luomisesta, joka voi kestää viikkoja, tarpeetonta tehtävää.

2) Vaatimusten muuttuminen projektin aikana

IT-projektia ei ole melkein, missä alun perin noteerattu ohjelmistoprojekti pysyy samana projektin aikana.

Syynä on, että vasta kun ohjelmisto on alkamassa muotoilla, asiakas tunnistaa, että puuttuu joitain tärkeitä asioita, joita ilman projekti ei voi onnistua eikä ohjelmisto auta liiketoimintaprosesseja.

Mutta entä jos kiinteä hinta on sovittu? Kuinka IT-palveluntarjoaja voi sallia muutokset projektin aikana. Tämä on melkein mahdotonta, koska silloin IT-palveluntarjoaja ei tuota ollenkaan voittoa.

Toisaalta asiakas vaatii kiinteää hintaa sanoen, että ”Tätä pientä muutosta varten ei ole tarvetta muuttaa budjettia. Tämä pieni muutospyyntö, jonka voit lisätä alkuperäiseen tarjoukseen ”.

Ja tässä yleensä dilemma alkaa. Tätä muutospyyntöjä koskevaa keskustelua jatketaan jatkuvasti. Ja projekti juuttuu.

Siksi on aina parempi pitää projektibudjetti sujuvana. Missä asiakas maksaa niin paljon kuin ohjelmistokehitys vaatii. -> Tietenkin tämä voi tuntua asiakkaalta ”taivaan ohjelmistoyritykselle”, koska hän ajattelee, että he tekevät enemmän tunteja kuin on tarpeen.

Mutta vertaa sitä ravintolaan. Jos tilaat ylimääräisen coca colan tai ylimääräisen pihvin, joudut maksamaan myös ylimääräisestä asiasta. Miksi sen pitäisi olla erilainen ohjelmistokehityksessä? Varsinkin tietotekniikassa, jossa tuntihinnat ovat yleensä paljon korkeammat.

3) Vaikeus ymmärtää ei-IT-henkilön ohjelmistokehityksen monimutkaisuutta

Ei-IT-henkilön on yleensä hyvin vaikea ymmärtää ohjelmistokehityksen monimutkaisuutta.

”Ystäväni rakensi tämän yhden verkkosivuston yhdessä päivässä ja sillä on paljon ominaisuuksia. Miksi tarvitset asiantuntijana yli 6 kuukautta näiden ominaisuuksien kehittämiseen?”

Todennäköisesti ystävä käytti jotain sisällönhallintajärjestelmää, kuten WordPress tai Drupal, ja käytti joitain vakiolaajennuksia, jotka tuovat yleensä paljon toimintoja. Mutta nämä eivät ole ystävälle tehtyjä mukautettuja ohjelmistoratkaisuja. Nämä ovat järjestelmiä ja laajennuksia, joita yleensä tuhat ja sata tuhatta ihmistä käyttää, ja joilla on samanlaiset vaatimukset. Ne eivät ole räätälöityjä ratkaisuja.

Mutta: Näiden laajennusten rakentaminen vaati todennäköisesti noin 2–5 tai enemmän kehittäjiä kokopäiväisesti useita kuukausia tai jopa vuosia. Joten vaikka ystävä käyttää näennäisesti yksinkertaisia ratkaisuja. Ne on luotu erittäin monimutkaisessa ohjelmistokehityksessä.

Joten jos asiakkaalla on jokin vaatimus, jonka nämä lisäosat ja ”valmiit ratkaisut” voivat täyttää. Sitten on parempi käyttää niitä. Mutta useimmissa tapauksissa nämä valmiit ohjelmistojärjestelmät eivät ole asiakkaan vaatimia.

Paras esimerkki on Google-hakukone. Käyttöliittymässä (mitä käyttäjä näkee) on vain hakupalkki ja kaksi painiketta. Joten ei-IT-henkilö sanoisi ”tämän kehittäminen voi kestää vain yhden viikon. On vain hakupalkki ja kaksi painiketta. Todellisuudessa on monia ”piilotettuja” taustajärjestelmän toimintoja, jotka ovat kehittäneet tuhannet ja tuhannet kehittäjät ja jotka vuosien ajan.

Asiakasprojektin monimutkaisuudesta, skaalautuvuustarpeista jne. Riippuen ohjelmistokehitys voi viedä odotettua enemmän aikaa.

Mahdolliset ratkaisut

On joitain ratkaisuja siihen, miten muu kuin tietotekniikan edustaja voisi kääntyä kyselyn puoleen IT-palveluntarjoajalta.

1) Ota mukaan ohjelmistokehittäjä

Ihannetapauksessa olisi oma ohjelmistokehittäjä tai IT-asiantuntija, joka voisi tarkistaa IT-palveluyrityksen arvion.

Yleensä ohjelmistokehittäjä neuvoo pitämään projektin laajuuden joustavana, jotta muutokset voidaan hyväksyä.

Jos ohjelmistoyrityksen arvio on uskottava, ohjelmistokehittäjä antaa vihreän valon.

Tällä tavalla, kun yrityksen sisäinen työntekijä arvioi projektia, myös muu kuin tietotekniikan edustaja on vakuuttunut kehitykseen liittyvistä ponnisteluista.

2) Dedikoidun kehittäjän käyttö

Omistettu kehittäjä on kehittäjä, joka toimitetaan asiakkaalle kokopäiväisesti.

Tämän etuna on, että kehittäjä tekee tiivistä yhteistyötä asiakkaan ja myös asiakkaan tiimin kanssa. Tämä lisää läpinäkyvyyttä. Ja asiakas tai tiimi voi esittää kysymyksiä ja saada reaaliaikaisia vastauksia.

Tämä malli toimii eri tavoin:

  • Sivulla: IT-palveluyritys pyytää kehittäjää menemään asiakkaiden paikalle ja työskentelemään asiakkaan tiloissa.
  • IT-ulkoistaminen: Kehittäjäryhmä työskentelee IT-palveluyrityksen tiloissa.
  • Länsirannan ulkoistaminen: Omistautunut kehittäjä työskentelee tietotekniikkapalvelujen tarjoajan tiloissa läheisessä maassa. Ruotsille se olisi Puola tai Ukraina. Japanille tämä olisi Malesia tai Kiina.
  • Offshore-ulkoistaminen: Täällä kehittäjä istuu ohjelmistoyrityksen tiloissa kaukaisessa maassa. Esimerkkejä ovat Intia, Pakistan jne. Mutta sanoja Nearshore tai Offshore voidaan käyttää keskenään. Se riippuu asiakkaan sijainnista. Jos asiakas on Japanissa, Intia on Nearshore Outsourcing -kohde.

Asiakas voi käyttää omistautunutta kehittäjää niin kauan kuin hän haluaa. Kunnes projekti on valmis. Jos projekti kestää liian kauan. Asiakas ja tiimi voivat keskustella kehittäjän kanssa siitä, mihin suuntaan mennä tavoitteiden saavuttamiseksi nopeammin.

3) Vältä jäykkiä kiinteähintaisia hankkeita

Kiinteä hinta ei yleensä ole hyvä idea. Vain jos projekti on hyvin pieni. Kuten yhden sivun verkkosivusto tai vastaava.

Kiinteät hinnat voivat johtaa väärään toivoon, että kaikki tehdään hinnan sisällä. (Jopa All-You-Can-Eat ei toimi tällä tavalla. Voit syödä niin paljon kuin haluat, mutta vain yhden aterian. Ei päivien ajan. Mutta sitä asiakkaat odottavat, kun he saavat kiinteän hinnan ohjelmistokehitys)

Parempi valita ketterä hinnoittelu, jossa ohjelmistotoimittajan aika ja vaivaa korvataan sen mukaan, kuinka paljon työtä kehitykseen kuluu.

Tai käytä omistettua kehittäjää tai omistettujen ohjelmistoammattilaisten tiimiä työskennellessäsi projektissasi.

Johtopäätös

Monet ohjelmistoprojektit epäonnistuvat, koska ei ole ymmärrystä siitä, mitä mukautettujen ohjelmistojen kehittäminen merkitsee. Näennäisesti helpot projektit voivat viedä viikkoja ja kuukausia.

Siksi asiakkaan on tehtävä arvio. Mikä on ohjelmistokehityksen kustannusalue ja mikä on siitä syntyvä liiketoiminnan arvo. Onko yrityksen arvo luotu paljon suurempi kuin ohjelmistokehitykseen tarvittava budjetti? Hyvä, niin on hyvä mennä. Aloita projekti.

Jos luotu liiketoiminnan arvo ja kustannukset eivät täsmää. Silloin on ehkä parempi jatkaa manuaalisten ratkaisujen, Excel-tiedostojen tai tilattavien vakio-ohjelmistojen tai verkkoratkaisujen käyttöä maksamalla alhainen kuukausimaksu.

Odotan mielenkiintoista keskustelua.

Mielenkiintoisia linkkejä:
Miksi arviot eivät ehkä ole hyvä idea
Myytti ohjelmisto-arvioista selitetty


Kirjoittaja: Sascha Thattil työskentelee Software-Developer-India.com -sivustolla, joka on osa YUHIRO-ryhmää. YUHIRO on intialainen saksalainen yritys, joka tarjoaa ohjelmoijia IT-yrityksille, virastoille ja IT-osastoille.

Vastaa

This site uses Akismet to reduce spam. Learn how your comment data is processed.