Kiinteän hinnan ohjelmistokehitysprojektit: 3 tärkeää muistettavaa kohtaa

Ohjelmistokehitysprojekti voidaan toteuttaa eri tavoin. Nämä ovat pääasiassa:

  1. Dedikoitu kehittäjä: Saat kehittäjän, joka toimii vain sinulle ja organisaatiollesi. Yleensä kuukausihinnasta sovitaan palveluntarjoajan ja asiakkaan välillä. Kehittäjä työskentelee asiakkaalle kokopäiväisesti (noin 160 tuntia kuukaudessa).
  2. Ihminen ja materiaali / aika ja materiaali / ketterä / kehitystiimi: Tässä projektissa sovitaan, mutta toteutuksen tekee monitieteinen tiimi, joka koostuu projektipäälliköistä, scrum-mestareista, liike-analyytikoista, liiketoiminnan kehittäjistä, ohjelmisto- / web-kehittäjistä, ohjelmistojen testaajista jne. Tässä käytetään usein ketterää metodologiaa ja jokaisen kevään (noin kuukauden kestävä kehitysjakso) jälkeen kehitysajat mukautetaan. Se ei ole kiinteä hinta, vaan karkea budjetti, jonka mukaan se kehitetään. Se voi olla karkea luku, mutta se voi olla myös moninkertainen budjettiluku. Suurissa organisaatioissa tämä lähestymistapa on yleensä suositeltava.
  3. Kiinteä hinta: Tätä käytetään yleensä pienemmissä projekteissa, joissa hinta JA vaatimukset ovat kiinteät. Tämä artikkeli kertoo tämäntyyppisestä projektista ja siitä, mitä on otettava huomioon tällaisen kiinteän hinnan projektia toteutettaessa.

Johdanto

Monilla pienillä ja keskisuurilla yrityksillä on budjetti ohjelmistoprojektien toteuttamiseen. Erityisesti muissa kuin IT-yrityksissä tieto ohjelmistoprojekteista on rajallinen. He haluavat mieluummin kiinteän hinnan, jossa näiden yritysten projektipäällikkö voidaan helposti välittää yrityksen toimitusjohtajalle tai johdolle.

Olisi melko vaikeaa sanoa: “Kehittäminen kestää noin 2–8 kuukautta, ja jokainen tunti maksaa 100 Yhdysvaltain dollaria. Se voi myös olla 14 kuukautta”.

Jos IT-palveluyritys kertoo asiakkaalle, Se vie 4 kuukautta ja budjetti on 30 000 Yhdysvaltain dollaria ”, Asiakkaan tiimi voi tehdä päätöksen siitä.

Suuri asia on -> Ohjelmistoprojekti ei toimi näin. Seuraavat syyt ovat:

  1. Vaatimukset muuttuvat projektin aikana: Kukaan ei tiedä, edes asiakas, mitä kaikkien on oltava ohjelmisto- / verkkoratkaisussa, jotta se onnistuu. Yleensä vasta muutaman viikon kuluttua ensimmäinen versio tai ensimmäiset web-käyttöliittymät tulevat näkyviin. Silloin asiakas yleensä tietääHups, tämä toiminto on erittäin tärkeää. Ilman tätä toimintoa projekti ei onnistu”. Mutta projektikustannukset ja projektin toteutus on jo ”korjattu” molemmilta osapuolilta, asiakkaalta ja IT-palveluyritykseltä. Tämä voi olla näyttelytulppa.
  2. Kukaan ei tiedä tarkalleen, kuinka kauan toiminnallisuuden kehittäminen kestää: Vaikka ohjelmistokehittäjä voi antaa likimääräisen kuvan siitä, kuinka kauan toiminnallisuuden kehittäminen kestää. Hän ei tiedä sitä tarkalleen. Tämä pätee myös kokeneimpiin kehittäjiin. Siksi: Mitä suurempi projekti, sitä suurempi riski, että arvio on väärä. Silti suuremmalla puskurilla projektiennusteessa ohjelmistokehitysyritys yrittää jotenkin vähentää tätä riskiä.

Tämä tarkoittaa, että IT-palveluntarjoajalla on jo riski olla tietämättä, onko kehittäjän arvio oikea, ja sen lisäksi asiakas saattaa pyytää muutoksia projektissa.

Tämä on myös syy, miksi paljon siteeratun Chaos-raportin mukaan suuri osa (noin 40-60 prosenttia) kaikista IT-projekteista epäonnistuu.

Koska kiinteän hinnan projektissa kukaan ei halua antaa periksi. Asiakas ei halua maksaa yhtä Yhdysvaltain dollaria enemmän, koska ”sovittiin kiinteästä hinnasta”, ja IT-palveluntarjoaja vaatii rakentamaan vain sen, mistä sovittiin ”Koska vaatimukset vahvistettiin projektin alussa”.

Tässä on joitain huomioitavia asioita, jotta kiinteähintaiset projektit toimisivat

1) Vaatimukset ovat kiinteät (ja vasta näiden vaatimusten täyttämisen jälkeen lisätään uusia toimintoja)

Ohjelmistokehityksen ei tarvitse pysähtyä, kun alun perin sovitut toiminnot on kehitetty. Kun alkuperäinen projekti on valmis, seuraava vaihe voidaan keskustella ja suorittaa.

Vinkki 1: Asiakkaan on tehtävä seuraavat toimet: Vastusta kehotusta asettaa uusia vaatimuksia käynnissä olevaan projektiin. Vaikka sinulla on vahva tunne, että projekti ei kannata asiakkaitasi.

Se on tarpeeksi kova, jotta alkuperäiset vaatimukset toimisivat. Älä lisää siihen.

2) Asiakkaan saatavuus kehitysvaiheessa

Kiinteähintaisessa projektissa IT-palveluyritys varaa (pienemmissä hankkeissa) yhdelle kolmelle kehittäjälle, tiiminvetäjälle, projektipäällikölle ja suunnittelijalle.

Kun projekti alkaa, asiat etenevät nopeasti, eikä aikaa pidä hukata.

Erityisen tärkeää: Jos IT-tiimillä on kysyttävää tehtävästä tai tarvitsee palautetta, asiakkaan tulisi asettaa se saataville mahdollisimman pian. Pahin asia, mitä voi tapahtua, on se, että kehitystiimin on odotettava 2 päivää asiakaspalautetta ja se on käyttämättömänä tuohon aikaan.

Jos kehitystiimi istuu käyttämättömänä, se aika yleensä vähennetään kiinteän ajan budjetista ja joukkue yrittää suorittaa tehtävät jäljellä olevan ajan kuluessa. Mikä ei yleensä ole hyvä idea, mutta ehkä ainoa tie eteenpäin.

Siksi voidakseen hyötyä kehitystiimistä ja heidän ajastaan asiakkaan on oltava helposti käytettävissä IT-palveluntarjoajan kysymyksiin.

Vinkki 2: Paras ratkaisu tähän olisi: Asiakas tarjoaa erillisen yhteyspisteen, joka on käytettävissä kehitystunteina koko kehitysjakson ajan. Esimerkiksi asiakkaan John Smith on saatavana 01: stä lähtien. 30. heinäkuuta. Elokuu. Tänä aikana John Smith on käytettävissä Skypen tai Slack Chatin kautta ja voi vastata kehitystiimin kysymyksiin.

3) Tarjoa sisältöä ajoissa

Joissakin tapauksissa asiakkaan on toimitettava tekstejä, videoita, kuvia ja muuta sisältöä tai materiaalia.

Tämä ennalta sovittu sisältö tulisi toimittaa ajoissa.

Joissakin tapauksissa kehitysyhtiöllä on toistaiseksi mahdollisuus käyttää nuken tekstejä tai nuken sisältöä.

Mutta oikeaan tulokseen sisältö tarvitaan joissakin tapauksissa.

Vinkki 3: Varmista, että sisältö (kuten tekstit tai kuvat) on valmis, kun kehitystiimi sitä pyytää.

Huomaa: Se voi liittyä myös hyväksynnän antamiseen, jonkin tehtävän suorittamiseen tai johonkin projektiasiakirjaan, joka on allekirjoitettava.

4) Vältä: ”Mutta tämä oli osa vaatimusta” Argumentit (tärkeä tärkeä vinkki)

Todellisuudessa vaatimuksia ei voida koskaan täysin ymmärtää tai kirjoittaa ylös projektin alkaessa.

Ohjelmistokehitystiimi työskentelee yleensä joidenkin asiakkaiden lähettämien URL-osoitteiden kanssa, yhden tai kahden online-kokouksen ja jonkin verran kirjallista materiaalia, kuten sähköpostit tai PDF-tiedostot.

Päätoiminnoista on yleensä yleinen käsitys, mutta ei 100 prosentin selkeää kuvaa.

Tätä voivat molemmat käyttää kehitysyhtiö sanomaan “ Mutta tämä ei ollut osa vaatimusta, tämä maksaa lisäkustannuksia ”Tai asiakas sanoa” Mutta tämä oli osa alkuperäistä vaatimusta, haluamme ehdottomasti tämän ilmaiseksi ”.

Vinkki 4: Molemmilla puolilla on oltava yleinen oikeudenmukaisuus. Vastinetta rahalle pitäisi olla. Mutta toisaalta sen ei pitäisi olla tehtävän saavuttamaton, niin että kehitysyhtiöllä ei ole lainkaan voittoa projekteista.

Huomautus: Yleensä asiakkaan (jos hän ei ole IT-asiantuntija) tulisi luottaa IT-yrityksen ehdottamaan kehitystoimintaan.

Johtopäätös

Parempi tapa edetä ohjelmistoprojekteissa on omistettu kehittäjä tai oma kehittäjä / ketterä lähestymistapa. Mutta tämä ei ole mahdollista joillekin yrityksille budjettirajoitusten vuoksi.

Siksi monet IT-palveluyritykset tarjoavat vaihtoehdon kiinteähintaisiin projekteihin.

Asiakkaan kannalta on tärkeää huomata, että kun hinta on kiinteä, myös vaatimukset ovat kiinteät. Usein kiinteä hinta on väärässä ”kaikki, mitä voit syödä” -buffetilla, jossa maksat kerran ja voit syödä (kehittää) niin paljon kuin haluat. Päinvastoin, se on pikemminkin ”A-La-Carte” -valikkovaihtoehto, jossa tilaat pihvin 5 dollaria, jos haluat perunoita, sinun on maksettava 2 dollaria ylimääräistä.

Mutta myös: Ohjelmistokehitys ja aterian valmistelu ovat erilaisia. Koska pihveä luodessa tulos on melko selkeä. Ohjelmistokehityksessä näin ei ole aina.

Tämän artikkelin vinkit auttavat tekemään kiinteähintaisista projekteista menestyksen.

Mielenkiintoisia artikkeleita:

Kuinka saada kiinteähintaiset projektit toimimaan sinulle

Kiinteän hinnan ohjelmistokehityksen haasteet

Kuvat: Canva


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.