Scope Creepin ja Gold Platingin käsittely ohjelmistoprojekteissa

Tietotekniikkahankkeissa Scope Creep (joka tulee omistajan puolelta) ja Gold Plating (joka tulee PM:ltä, Scrum Master:ltä tai kehittäjiltä) ovat suosittuja uhkia. Hallitsemattomat muutokset projekti, uusien toimintojen lisääminen tai muutosten tekeminen kuuluvat epäilemättä uhkiin, jotka vaikuttavat sekä hankkeiden tehokkuuteen että nopeuteen. Aiemmin meillä on ollut tilaisuus tehdä yhteistyötä startup-yritysten ja suurten yritysten, kuten Livenationin / Ticketmasterin, Stroerin tai Agoran (Euroopan suurin mediakonserni) kanssa. Tänä aikana koordinoin monia tietotekniikkahankkeita - erityisesti niitä, jotka liittyivät seuraaviin asioihin ohjelmistokehitys. Tämän kokemuksen ansiosta ymmärsin, että ei ole väliä, työskenteletkö pienessä vai suuressa yrityksessä: jos haluat menestyä, sinun on oltava askeleen edellä kilpailijoitasi.

Haluaisin jakaa näkemykseni siitä, miten tehokkaasti kehitetään ohjelmistokehitysprojektit. Codestin CCO:na toteutamme päivittäin projekteja globaaleille yrityksille ympäri maailmaa. Oikea lähestymistapa johtamiseen on ensimmäinen tärkeä vaihe, joka vaikuttaa myöhemmin projektin onnistumiseen. Erottelen neljä perusperiaatetta, joiden ylläpitämisen avulla olemme voineet kehittää todella tehokkaan hallintamallin. Niiden ansiosta vältämme myöhemmät ongelmat - myös ne, jotka liittyvät "laajuuteen" (creep and gold planting). Tässä ne ovat:

1. Metodologi. Riippumatta hankkeen koosta tai sen etenemisasteesta, otamme aina käyttöön asianmukaisen menetelmän, jonka avulla voimme hallita hanketta tavalla, joka on yhdenmukainen seuraavien vaatimusten kanssa Ketterä lähestymistapa. Tässä tapauksessa Scrum-metodologi auttaa meitä. Ja sen ansiosta meillä on kaikki projektin vaiheet hallinnassa. Jokainen jäsen keskittyy tarkasti määriteltyihin tehtäviin. Näin vältämme turhia häiriötekijöitä ja säilytämme työn maksimaalisen tehokkuuden.

2. MVP. Sitä voidaan kutsua pääperiaatteeksemme. Jos haluat luoda sovelluksen, tee se, mutta hyvin perustasolla. Säästät aikaa ja vältät budjetin loppuunpalamisen riskit. Alkuperäinen visio tuote tarkistetaan ja muutetaan usein myöhemmin. Asiakas saattaa ajan mittaan muuttaa mieltään sovelluksen vaadittavista ominaisuuksista, mikä puolestaan aiheuttaa tarpeettomia kustannuksia ja pidentää työtä.

MVP-lähestymistapa toimii melko hyvin. Luomme sovelluksen, jossa on esimerkiksi 20% kaikista toiminnallisuuksista, mutta joka pystyy jo nyt tarkistamaan arvonsa päälle markkinat. Näin asiakas saa palautetta käyttäjiltä ja tietää, mitä ominaisuuksia hänen tuotteessaan pitäisi olla, jotta se olisi tehokas. Sitten keskitytään näiden elementtien kehittämiseen. Tämän prosessin hieno kuvaus on oheinen grafiikka:

3. Testaus. Yksittäisten sovellustoimintojen testaus liittyy suoraan MVP:hen. Jos käy ilmi, että jokin asia ei toimi niin kuin pitäisi, se on parempi hylätä ja etsiä vaihtoehtoinen ratkaisu. Codestilla olemme tavanneet asiakkaita, jotka alusta alkaen määräsivät sovelluksen lopullisen muodon ja olivat varmoja, että tämä on ainoa oikea näkemys. En haluaisi käsitellä tarkemmin tämän lähestymistavan jatkovaikutuksia. Siksi pidänkin tarpeellisena korostaa vielä kerran, että yksinkertaisuus on avain menestykseen.

4. Kehitys. Sovelluksen rakentaminen olisi aloitettava UX:stä, suunnittelusta, backendistä ja frontendistä. Lyhyesti sanottuna kaikki alkaa yksinkertaisista "must have" -tehtävistä, jotka muodostavat MVP-tuotteen. Kun tämä kehitysvaihe on saavutettu, voit keskittyä "nice to have" -nimellä kutsuttujen toimintojen kehittämiseen.

Yhteenveto

Mielestäni nämä neljä perusperiaatetta sopivat erinomaisesti ohjelmistokehitysprojektien hallintaan. Tämä lähestymistapa vähentää tarpeettomien häiriötekijöiden, pidempien työaikojen ja kustannustehottomuuden riskejä.

Lopuksi annan vielä yhden esimerkin. Jokin aika sitten saimme eräältä asiakkaalta erään projektin eritelmän. Liityimme välittömästi joukkue arvioida sitä. Asiakas odotti, että saisimme aikaan tuotteen kahdentoista kuukauden kuluessa. Lähestymistapamme mukaisesti ehdotimme MVP-lähestymistapaa ja kolmen kuukauden kehitysaikaa. Lopulta onnistuimme vakuuttamaan asiakkaan. Muutaman kuukauden kuluttua he olivat vaikuttuneita ratkaisusta. Asiakas sai toimivan tuotteensa suhteellisen lyhyessä ajassa. Useiden toiminnallisuuksien osalta he päättivät muuttaa projektin oletettua alusta alkaen.

Tässä artikkelissa kuvaamani malli on meidän tapamme toteuttaa ohjelmistokehitysprojekteja menestyksekkäästi. Uskokaa minua, tämä ratkaisu ei ainoastaan paranna työtä ja tee siitä tehokasta, vaan auttaa sen seurauksena välttämään hiipimisen ja kultaamisen laajuutta.