Ruma totuus ohjelmistokehitysprosessista

kuvan lähde: perfectdigital.com

Tunnet tämän kuvan, eikö niin?

Mielestäni se osoittaa hyvin, että suuria eroja ja näkemyksen puutetta voi esiintyä seuraavissa asioissa. ohjelmistokehitysprojektit kaikkien osallistujien ja asianosaisten välillä. Ongelmia syntyy usein heti alusta alkaen, kun asiakas tulee (teoreettisesti) lopullisen tuote visio ja esittelee sen joukkue. Sitten tulee lisää väärinkäsityksiä, väärintulkintoja ja lopulta projekti menee nopeasti väärälle kehityspolulle.

Analysoidessani edellä olevaa kuvaajaa esittelen vaiheittain kaikki mahdolliset uhat ja ehdotan, miten niitä vastaan taistellaan. Mennään suoraan asiaan!

1. Miten asiakas selitti idean?

Tuotevisiossa on ristiriitaisuuksia alusta alkaen. Miksi? Syy on hyvin yksinkertainen - jokainen tulkitsee todellisuuden omalla tavallaan, hänellä on mielessään käsitys jostakin asiasta, eikä hän välttämättä esitä tätä visiota tarkasti toiselle osapuolelle. Jos kuvaat sanoin tuotteen, jonka haluaisit rakentaa, on erittäin todennäköistä, että kehitystiimi ymmärtää visiosi eri tavalla kuin sinä tarkoitit.

Tämä on tietenkin mahdollista välttää. Visualisointi kannattaa aloittaa mahdollisimman pian ja keskustella tuotteen toiminnallisuuden yksittäisistä elementeistä luonnosten pohjalta. Mielenkiintoista on, että ensimmäisillä luonnoksilla ei yleensä ole mitään yhteistä lopullisen tuotteen kanssa. Tässä vaiheessa tärkeintä on kuitenkin saada visio yhtenäiseksi.

2. Miten hankkeen johtaja ymmärsi sen?

Ihmetteletkö, miksi ensimmäinen ja toinen kuva ovat niin erilaisia? Projektipäällikkö tarkastelee aina tarkemmin tuotevisiota. Kuitenkin, on tärkeää, että tällainen henkilö, joka on olennaisesti vastuussa koko toiminnasta. ohjelmistokehitys prosessi, ymmärtää täysin tuotteeseen liittyvän ongelman ja tarpeet.. Hankkeen johtajalla on oltava selkeä "kokonaiskuva". Kuten näet, molemmat kuvat eivät eroa toisistaan toiminnallisuuden suhteen. Ne vain näyttävät erilaisilta. Jotta ymmärtäisimme tämän kohdan paremmin, palataanpa kuvaan numero yksi. Projektin alussa ei ollut luonnoksia, ja jo se johti väärinkäsitykseen. Tuotteen toiminnallisuus on oikea, mutta muotoilu on täysin erilainen.

3. Miten analyytikko suunnitteli sen? ja 4. Miten ohjelmoija kirjoitti sen?

Joskus analyytikot ja kehittäjät eivät tunne käyttäjien tarpeita tai vahvistettuja liiketoimintatavoitteita. He näkevät vain pienen palan koko projektista, joka vangitsee heidän päähuomionsa. He eivät kykene tarkastelemaan asiaa laajemmasta näkökulmasta, ja tämä koskee erityisesti suuria hankkeita, joissa työskentelee paljon kehittäjiä samanaikaisesti.

Voimme käyttää myös toista esimerkkiä. Voi käydä niin, että esimerkiksi tuotteen omistaja on kuvannut ratkaistavan ongelman väärin. Tällöin annetaan epätäydellistä tietoa, jonka pohjalta kehittäjä tai suunnittelija luo omia tulkintojaan, ja tuote poikkeaa yhä enemmän suunnitellusta kehityspolusta.

Miten se voidaan muuttaa? Mielestäni hyvä ratkaisu on varmistaa, että hankkeen kannalta keskeisillä henkilöillä on yksityiskohtaista tietoa hankkeesta - niin sanottu "kokonaiskuva". Väärinkäsitysten sattuessa heidän on helpompi tuoda esiin ohjelmistokehitysprosessi takaisin oikealle tielle. Muista siis, että jos jokainen näkee vain oman pienen palasen kehitetystä toiminnallisuudesta, väärinkäsityksistä visiossa tulee todennäköinen uhka.

5. Miten yritysneuvoja kuvasi sitä?

Tässä tapauksessa asia on yksinkertainen. Tuotteen on myytävä. Sinun on jotenkin erotuttava, jotta esimerkiksi yksinkertainen keinu puutarhaan saa poikkeuksellisia elementtejä. Ideana on vakuuttaa potentiaalinen ostaja. Markkinointi- ja myyntiosasto tekee varmasti kaikkensa osoittaakseen, että tuote on ainutlaatuinen.

6. Miten hanke dokumentoitiin?

Puuttuvat asiakirjat ovat hyvin yleinen ongelma. Joskus dokumentaation luominen aikana tuotekehitys tuntuu tarpeettomalta ajanhukalta. Tämä on virhe. Sanon hyvin usein, että muutokset tehdään nopeammin paperilla kuin todellisuudessa. koodi, ja siinä on jotain perää. Lisäksi on helpompi viitata dokumentaatioon mahdollisten muutosten seuraamiseksi. Uskokaa minua, projektissa, jossa ei ole dokumentaatiota, on erittäin suuri vaara, että visio jää saavuttamatta.

7. Mitkä toiminnot asennettiin?

Tässä vaiheessa ympäristö sijoitetaan palvelimelle. Kuten ohjelmoijia ja analyytikoita koskevassa kohdassa, ilman täydellisiä tietoja ja viestintäkatkoksia voi käydä ilmi, että vain osa tarvittavasta ympäristöstä on luotu.

8. Miten asiakasta laskutettiin?

Se on seurausta huonosta viestinnästä, UX:n puutteesta ja niin edelleen. Virheiden ilmaantuminen lisää kehitysaikaa. Ja aika on rahaa, eikö niin? Vinkkini on, että projekti on toteutettava ketterästi., ylläpitää korkeimpia viestintästandardeja ja pitää kiinni selkeistä budjettiohjeista. En epäile yhtään, etteikö näin toimimalla vältettäisi tällaisia ongelmia.

9. Miten sitä tuettiin?

Asiakkaat keskittyvät usein vain tuotteen rakentamiseen ja sen loppuunsaattamiseen. Elämme kuitenkin monien muutosten ja teknisten innovaatioiden aikaa, minkä vuoksi on välttämätöntä ylläpitää jatkuvaa teknistä tukea. Tarkoituksena on välttää tilanne, jossa jokin lakkaa yhtäkkiä toimimasta, koska se vanhentuu ja tuote menettää arvonsa. Myöskään tätä näkökohtaa ei pidä unohtaa.

10. Mitä asiakas todella tarvitsi?

Olemme saavuttaneet viimeisen pisteen. Katso ensimmäisen ja viimeisen kuvaajan välistä eroa. Loppujen lopuksi molemmat liittyvät asiakkaan näkökulmaan. Miksi näin tapahtuu? Kaikki valehtelevat, että se on niin yksinkertaista 🙂 Kyselytutkimusten tulokset poikkeavat aina vastaajien todellisista tarpeista. Vastatessaan tutkijan kysymykseen käyttäjät haluavat näyttää parhaan puolensa. Siksi, HE EIVÄT USEINKAAN VASTAA TOTUUDENMUKAISESTIvaan pikemminkin tavalla, johon heidän mielestään pitäisi vastata. Periaatteessa he eivät halua altistua muiden negatiiviselle arvioinnille. Pieni vinkki: mainitse ohjeissa, ettei ole olemassa hyviä eikä huonoja vastauksia.

Missä muualla erot näkyvät? Ihmiset eivät useinkaan tiedä, mitä he todella haluavat. Usein käyttäjät sanovat aluksi tarvitsevansa tuotteeseen 10 toimintoa, mutta myöhemmin he käyttävätkin vain esimerkiksi 3 toimintoa.

Miten tämä ongelma ratkaistaan? Sen lisäksi, että kysyt käyttäjiltä, mitä he haluavat ja tarvitsevat, anna heidän testata tuotetta, mieluiten aidoilla tuotteilla, jotta uskottavuus säilyy. Mitä enemmän testejä tuotteiden luomisen aikana tehdään, sitä suurempi mahdollisuus on, että tulos on tarkka.

Yhteenveto

Jos sinusta tulee joskus jäsen ohjelmistokehitys hanke, muistakaa esimerkkini ja tehkää johtopäätökset, jotta ette kopioi edellä mainittuja virheitä. Ja muista, että nämä käsitteet ovat erittäin tärkeitä rakennettaessa tuotetta (sovellusta) tyhjästä:

- hyvä UX ja testit, jotta saat selville, mitä käyttäjät todella tarvitsevat,

- projektin sisäinen viestintä, jotta projektin avainhenkilöt ymmärtävät ongelman ja tarpeet syvällisesti,

- kehittää tuotetta Ketterä,

- älä unohda teknistä tukea.

Lue lisää:

– Miten hallita tehokkaasti etäkehittäjiä? Opas teknologiajohtajille

– Python vs. Ruby? Mitä teknologiaa kannattaa käyttää tuotekehityksessä?

– Nopea opas oman markkinapaikan rakentamiseen ja kehittämiseen. Mitä kannattaa tietää?