Miksi ohjelmistokehitystehtävien estimointi on säännöllisesti pois päältä kertoimella 2-3?

Tämä on vastaus Quoran kysymykseen: Miksi arviot eivät ole tarkkoja?

Tähän on useita tekijöitä. Tässä joitain yleisiä:

1) Asiakas ei ole tekninen ja tuntee ”kaikki on helppoa”

Ohjelmiston kehittäminen ei ole niin helppoa kuin miltä se näyttää.

Vaikka se näyttää helpolta, on joskus parempi jättää pois tietyt tehtävät.

  • Analogia:

Siellä on valtava mäki, ja meidän on rakennettava rautatie. Kehittäjät neuvovat: ”Vältä paremmin mäkeä ja rakenna raita mäen ympärille. Näin säästämme 5 kuukautta lisätyötä ”.

Tällöin olisi ilmeistä, että tunnelin poraaminen mäen läpi vie paljon enemmän aikaa ja asiakas suostuisi ”työhön”.

  • Katsotaan nyt ohjelmistokehitystä:

Kehittäjä sanoo: ”Olisi parempi, että sinulla olisi vain yksi mobiiliversio yhdellä näyttökoolla ja yksi työpöytäversio yhdellä näyttökoolla. Meidän tulisi välttää mobiilisovelluksen käyttöä ja myös täysin reagoivaa suunnittelua, koska se ei näytä hyvältä ”.

Täällä asiakas todennäköisesti sanoo: “Miksi? Muut verkkosivustot ovat myös reagoivia ja voivat vaihtaa kaikkia näyttökokoja. Se on helppo tehtävä. ”

Mutta: Kehittäjä voi ehdottaa tätä monista hyvistä syistä. Ehkä herkkä muotoilu ei näytä hyvältä tai ammattimaiselta. Varsinkin jotkut painikkeet voivat helposti pahanlaatuisia jne.
Joten nyt tapahtuu, että kehittäjä tekee 1) rakenna sivu reagoivaksi ja 2) lisää tuntia.

  • Tunnin korotusta asiakas ei hyväksy: ”Miksi enemmän tunteja? Onko se helppoa? ”
  • Kun tehtävä on valmis, asiakas tarkastelee verkkosivustoa matkapuhelimellaan ja sanoo: ”Kaikki on väärin, kun tarkistan sivuston mobiililaitteella. Miksi? Maksoin paljon enemmän ja nyt tämä? ”.

Jos asiakas olisi suostunut aikaisempaan tapaan tehdä se (ei reagoiva, vain kahdella versiolla), niin verkkosivusto olisi ollut halvempi (vähemmän tunteja) ja se toimisi täydellisesti melkein jokaisella mobiilinäytöllä ja työpöydän selaimella.

Tärkein asia tässä on myös: Ei ole hyvä kiistellä kenenkään kanssa. Erityisesti riitauttaminen asiakkaan kanssa ei ole hyvä idea. Joten kehittäjä / palveluntarjoaja sanoo aina ”Kyllä, olet oikeassa, teemme sen tuolla tavalla”.

Ja kun asiakas ei todellakaan ole tyytyväinen, kehittäjän tulisi jälleen ottaa syyllisyys (vaikka hän tietää, ettei se ollut hänen syynsä, vaan että vaatimus oli sellaisella tavalla).

2) Tarkkaan arvioimiseen ei ole mahdollista käyttää paljon aikaa

Todellisessa maailmassa ohjelmistoyritys vastaanottaa ohjelmistosovelluksia päivittäin tai viikoittain.

Jos jokainen pyyntö arvioidaan tarkasti, kehittäjillä ei ole muuta tekemistä kuin luoda tarkkoja arvioita. He eivät pystyisi työskentelemään todellisissa projekteissa, koska näiden tarkkojen arvioiden luominen on erittäin aikaa vievää.

Joten mitä todellisuudessa tapahtuu, on: He tarkastelevat projektia ja ”arvioivat” tarvittavan ajan. Siksi sitä kutsutaan ”arvioiksi”, koska se ei ole tarkka.

Lisäksi: Asiakas itse ei ole kiinnostunut odottamaan yhden tai useamman viikon määrittelemään vaatimuksen. Luo enintään 5 sivun asiakirja, joka on kehityksen perusta.

3) Jokainen vaatimus muuttuu projektin aikana

Haluan lainata Andrew Rose Quora-säikeestä / linkistä tämän artikkelin alusta:

”Riippumatta siitä, kuinka suuri tai pieni projekti on, aina tulee jotain esiin projektin aloittamisen jälkeen. Todennäköisemmin paljon asioita tulee esiin. Se on vain pedon luonne. Tuotepäällikkönä sinun tehtäväsi on työskennellä asiakkaidesi kanssa keksimällä mitä he tarvitsevat ja ovat valmiita maksamaan. Sinun on myös keksittävä, mitä voit kohtuullisesti toimittaa kehittäjien avulla. Kun työskentelet näiden tavoitteiden saavuttamiseksi, törmäät laajuuteen, virheellisiin aika-arvioihin ja joskus muutoksiin ihmisissä, jotka työskentelevät projektin loppuun saattamiseksi. ”

Monet asiat muuttuvat projektin aikana. Kuten Andrew mainitsi, paitsi vaatimukset eivät muutu. Jopa ihmiset saattavat mennä muihin projekteihin ennen nykyisen projektin valmistumista.

Tässä analogia:

100 metrin pikajuoksija harjoittaa 10 vuotta juoksemaan 100 metriä alle 10 sekunnissa.

Sprintin päivänä asiakas sanoo, tarvitsemme myös viisi estettä matkan varrella.

Sitten pikajuoksija sanoo: ”Mutta sitten en pysty ajamaan sitä alle 10 sekunnissa” ja asiakas sanoo ”mitä harjoittelet viimeisten 10 vuoden aikana, tee se ystävällisesti alle 10 sekunnissa”.

Sama asia myös ohjelmistoprojekteissa. Asiakkaat ja projektipäälliköt tuovat uusia vaatimuksia, koska ”Voi, unohdin tämän erittäin tärkeän toiminnon. Sen on oltava ohjelmistossa, muuten siitä ei ole hyötyä meille.

Nämä vaatimusmuutokset tapahtuvat yleensä koko projektin aikana. Se on kuin lisäämään lampi, muuri, tikkaat jne. Sprinterin tielle odottaen hänen tekevän sen vielä alle 10 sekunnissa.

4) Arkkitehtuuria ei ole tarkistettu oikein

Varsinkin kun asioita ei tehdä tyhjästä ja käytetään kolmannen osapuolen työkaluja (WordPress, TYPO3, Drupal, Magento, Shopware ja monet muut), ja ne tulisi räätälöidä tekemään jotain erityistä, mihin se voi tulla väärät arviot .

Näissä kolmansien osapuolien työkaluissa emme voi vain muuttaa kaikkea mitä haluamme. Yksinkertaisia asioita, kuten URL-rakentetta tai muita asioita, on noudatettava.

Kuten tämän tekstin kohdassa 1), kaikkea ei ole helppo toteuttaa. Kun on saatu selville, että kolmannen osapuolen järjestelmän nykyinen arkkitehtuuri ei tue tiettyä toimintoa, on aina parempi välttää kyseistä toimintoa ja käyttää työtä, joka tekee saman työn, mutta käyttää olemassa olevaa arkkitehtuuria.

Huomaa: Tämä ongelma / ongelma ilmenee myös, jos projekti tehdään tyhjästä työkaluilla, kuten PHP, ASP.NET, Laravel, Zend, Symfony, Java, Ruby on Rails, Node.Js jne. tehtiin järjestelmän arkkitehtuurista.

5) Yhden lauseen tai yhden sanan tulppa

Olin jo maininnut esimerkin 5-sivuisesta asiakirjasta, jonka asiakas toimittaa. Kun kehitys on melkein valmis tai käynnissä, asiakas sanoo: ”Tärkeä toiminto puuttuu. Sivulla 3 rivillä 22 mainitaan, että tarvitsemme – raportointityökalun – ”.

Mutta raportointityökalun rakentaminen, joka mainitaan vasta asiakirjassa pian, vie sinänsä saman summan kuin koko projekti. Ja koska ”raportointityökalu” mainitaan asiakirjassa, asiakas tietysti vaatii sen toteuttamista.

6) Projektin voittaminen

Oletetaan, että sinulla on tunne, että monet yritykset tekevät tarjouksia samasta projektista. Nyt et todellakaan halua olla ehdotus, joka veloittaa eniten tunteja. Haluat olla se, joka näyttää pienimmän tuntimäärän. Jos asiakas voi valita 100 tunnista 500 tuntiin, ehdottomasti kaikki valitsevat 100 tuntia.

Todellisuudessa ihanteellisessa maailmassa kaikki tarvitsevat saman määrän tunteja. Joten vaikka tarjottiin 100 tuntia, se loppujen lopuksi on 500 tuntia.

7) Tuntematon / odotusajat

Ohjelmistoprojekteissa on useita tuntemattomia:

  • a) Teknologian muutos: Jos jokin kehitystyökaluista (esim. Android) saa merkittävän päivityksen, on tehtävä enemmän työtä näiden tekniikan muutosten sisällyttämiseksi.
  • b) Tiimin jäsenten kokemus: Jos vanhempi kehittäjä työskentelee projektissa, se vie vähemmän aikaa, jos se on nuorempi kehittäjä, se vie todennäköisesti enemmän aikaa.
  • c) Palaute tulee myöhään: Asiakkaat eivät yleensä ole kovin kiinnostuneita projektista, he haluavat hyviä tuloksia. Joten kun asiakasta lähestytään projektin aikana, hän ei ehkä ole halukas antamaan vastausta tunnin kuluessa. Se voi kestää useita päiviä. Tuona aikana projekti seisoo käyttämättömänä ja palveluntarjoaja saattaa jopa veloittaa tuntikausia tuona aikana, jos kehittäjät istuvat käyttämättömänä vastausten viivästymisen vuoksi.

8) Projekti on liian suuri, jotta sitä ei voida arvioida oikein

Oletetaan, että tehtävä on yksi, joka tarvitsee useita kehittäjiä useiden kuukausien aikana.

On melkein mahdotonta hajottaa tehtäviä niin pienissä paloissa, jotta saat oikean arvion.

Muilla tässä artikkelissa mainituilla asioilla on tietysti myös rooli.

Johtopäätös

Paras tapa on:

  • Tee likimääräinen arvio
  • Mainitse, että on parasta vähentää toimintoja, jos projekti kestää liian kauan ja kestää useita tunteja (esim. Luo prioriteettiluettelo toiminnoista, tee vain tärkeimmät)
  • Käytä ketterää metodologiaa kehitykseen ja laskutukseen

Jos haluat tarkan hinnan / tunti, se on yleensä mahdollista vain pienemmissä projekteissa, jotka kestävät muutaman viikon.

Muita mielenkiintoisia artikkeleita aiheesta:
Kuinka arvioida ohjelmistokehitysprojekti realistisesti ihmiskunnassa
Miksi ohjelmistokehityksen aika-arvio ei toimi ja vaihtoehtoiset lähestymistavat

Kuvalähde: Flickr.com/ Michael Kappel / Judit Klein / Markus Spiske


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.