Puhuttaessa ohjelmistoprojekteista, oletko koskaan nähnyt, miten eri ohjelmistokehitysyhtiöt tai ohjelmistopalvelusuunnitteluyritykset kuvaavat projektiaan? Voitko heidän kuvauksensa perusteella nopeasti ymmärtää projektin konkreettiset vaatimukset ja taustan?

Yleinen tapa kuvata ohjelmistoprojekteja sisältää yleensä seuraavat neljä kohtaa:

Asiakkaan toimialan esittely

Ohjelmistoprojektin asiakkaat ovat eri toimialoilta. Kun esittelemme projektia eri alojen ihmisille, on aloitettava toimialan taustasta. Toimialan taustakuvaukseen kuuluu, miten ala liittyy ihmisten elämään, ketkä ovat markkinoilla myynnin tai palvelun kohteita, mikä rooli asiakkaan yrityksellä tai yksityishenkilöllä on alalla, mitkä ovat heidän uskomuksensa tai erityispiirteensä, ja mikä on yrityksen tulevaisuuden visio. Näiden tietojen avulla ohjelmistokehittäjät voivat paremmin ymmärtää asiakkaan näkökulman.

Liiketoimintaprosessissa kohdatut ongelmat (tarpeet)

Tämä on asiakkaan suurin motiivi. Mikä tilanne työympäristössä aiheuttaa asiakkaalle ongelmia? Onko nykyinen työprosessi digitalisoitava, tai tarvitseeko nykyinen tietojärjestelmä uudelleenjärjestelyä vuosien käytön jälkeen, vai onko tarvetta digitaalisiin toimenpiteisiin alan uusien trendien vuoksi? Tässä on tärkeää ymmärtää asiakkaan kohtaama tilanne objektiivisesti ja empaattisesti.

Ehdotettu ratkaisu

Kun yhteisymmärrys on saavutettu asiakkaan kanssa, ohjelmistoyritys esittää räätälöidyn suunnitelman ja toteutuksen, joka voidaan onnistuneesti soveltaa asiakkaan työprosessiin.

Tulokset

Uuden ratkaisun soveltamisen jälkeen, miten se eroaa vanhasta ratkaisusta ja mitä muutoksia se tuo asiakkaalle? Esimerkiksi tuotantoprosessin tehokkuuden parantaminen, tiedon yhdistämiseen kuluvan ajan vähentäminen, uusien asiakaskontaktikanavien tarjoaminen...

Yhteenvetona näistä neljästä ohjelmistoprojektin kuvauksesta, ne auttavat meitä saamaan alustavan käsityksen projektista. Projektipäällikön on myös varmistettava, että nämä kuvaukset ovat selkeitä mielessämme keskusteltaessa asiakkaan kanssa. Ohjelmistoprojektin kuvaus on joustava; se voi olla lyhyt lause, joka kertoo, mitä projekti tekee, tai pitkä raportti, joka kuvaa projektin sisältöä. Tässä vaiheessa voi kokeilla:

Luo "ydinarvo", joka määrittää projektin laajuuden

Projekti on projekti, koska se saavuttaa tietyn tavoitteen rajallisilla resursseilla. Kuitenkin, jos laajuutta ei rajoiteta, prosessissa voi syntyä "liittyviä" toimintoja. Näiden liittyvien toimintojen esiintyminen voi merkittävästi parantaa koko ratkaisua, mutta se voi myös pidentää kehitysaikaa ja viivästyttää julkaisua. Toisaalta, ne eivät välttämättä tuo konkreettista hyötyä koko ratkaisulle.

Esimerkki:

Asiakas haluaa luoda yrityksen tietojärjestelmään toiminnon, jossa "painamalla käynnistyspainiketta, aikataulutettu työ suoritetaan automaattisesti". Intuitiivisesti tämä saattaa vaatia vain seuraavien työprosessien yhdistämistä peräkkäin, mutta todellisuudessa kehitystilanne voi vaatia lisäyksiä, kuten käyttöoikeuksien hallintaa, edellisen suorituksen tilaa ja järjestelmän vakaata yhteyttä. Tässä vaiheessa asiakas saattaa sanoa keskusteluryhmässä: "Haluan, että painettaessa käynnistyspainiketta tulee elävä ja dynaaminen tunne."

Ohjelmistokehityksen aikana, kun suunnittelemme toimintoja yksittäisen käyttäjätarinan perusteella, meidän on usein lisättävä tilannearviointi ja otettava huomioon erilaiset liiketoimintalogiikat. Kun asiakkaalla ei ole muita erimielisyyksiä toiminnallisuudesta, huomio voi siirtyä käyttöliittymän väreihin, asetteluun, painikkeiden käyttäytymiseen ja sivunvaihtojen siirtymiin, jolloin syntyy erilaisia vaatimuksia, ja toivotaan, että käyttöliittymä olisi elävämpi.

Mitä tehdä, kun kehitystoimintojen ja asiakkaan odottaman järjestelmäkäyttöliittymän välillä on ristiriita rajallisessa kehitysajassa?

Tässä vaiheessa on palattava perus "ydinarvoon" varmistaakseen nykyisen ajan ja resurssien riittävyyden sekä näiden liittyvien toimintojen tarpeellisuuden ja prioriteetin. Ydinarvo on usein lyhyt ja ytimekäs iskulause, joka toimii kuin voimakas loitsu, auttaen meitä harkitsemaan käyttäjätarinoiden lisäämistä tai poistamista. Kun asiakas on itsepäinen, voimme ohjata keskustelua pohtimaan "Mitä hyötyä elävämmästä käyttöliittymästä on yrityksen tietojärjestelmän käytössä?" "Jos haluamme tehdä käyttöliittymästä elävämmän, meidän on aloitettava suunnittelusta, mikä voi lisätä suunnitteluaikaa ja viivästyttää julkaisuaikataulua. Onko tämä hyvä?" Sitten ehdotamme "Suosittelemme, että 'ydinarvon' perusteella muokataan esitettyjä vaatimuksia ja priorisoidaan ne, jotta ne voidaan julkaista aikataulussa."

Määritä jokaiselle projektille asiakkaan kanssa keskustellessa sopivin "ydinarvo"

Projektin ydinarvo toimii kuin majakka, joka ohjaa meitä keskustelun meressä, jotta emme poikkea aiheesta ja pysymme projektin päälinjassa. Jos olet tänään lukemassa tätä artikkelia ja kamppailet asiakkaan esittämien vaatimusten kanssa, miksi et listaisi projektin ydinarvoja vakuuttaaksesi itsesi ja asiakkaasi?