Vaatimusten onnistunut määrittely (Kelly Suter BI Worldwidesta)

Lue litterointi:

Kokeilemme podcastiemme litterointia ohjelmiston avulla. Annathan anteeksi mahdolliset kirjoitusvirheet, sillä robotti ei ole sataprosenttisen tarkka.

Ben Aston:

Tervetuloa DPM Podcastiin, jossa menemme teoriaa pidemmälle ja tarjoamme asiantuntevia projektinhallinnan neuvoja parempien digitaalisten projektien johtamiseen. Kiitos, että kuuntelet. Olen Ben Aston, The Digital Project Managerin perustaja. Ole rehellinen: onko asiakkaasi koskaan projektin lopussa kääntynyt puoleesi ja sanonut: ”Hei, onnistuitte tässä täydellisesti. Tämä on juuri sitä, mitä halusimme, ja täsmälleen sitä, mitä sanoitte tekevänne projektin alussa. On hämmästyttävää, miten onnistuitte ottamaan kaiken huomioon ettekä pudottaneet mitään matkasta.”

No, epäilen, ettei näin ole tapahtunut. Se johtuu luultavasti siitä, ettei vaatimuksiasi määritelty kunnolla. Miten siis hallitset vaatimuksia niin, ettet joudu myöhemmin projektissa täydelliseen kaaokseen, mutta annat asiakkaalle ja kehittäjälle kaiken työn tekemiseen tarvittavan tiedon? Siitä tämän päivän podcastissa on kyse: projektivaatimuksista.

Määrittelemme niiden avulla projektin ja asiakkaalle toimitettavat toiminnot niin, että kaikki tietävät, mitä toimitetaan. Vaatimukset ovat mielestäni pohjimmiltaan viestintäväline, mutta niiden määrittely oikein on erittäin vaikeaa. Jos määrittelemme vaatimukset liian väljästi, saamme kyllä enemmän joustavuutta, mutta emme välttämättä saa lopputuloksena juuri sitä, mitä halusimme. Jos taas määrittelemme ne liian tiukasti, monia asioita saattaa jäädä puuttumaan. Miten löydämme oikean tasapainon?

Tänään keskustelen Kelly Suterin kanssa. Kelly on tekninen projektipäällikkö BI Worldwidella ja yksi Digital Project Managerin Deakin asiantuntijoista. Tervetuloa, Kelly.

Kelly Suter:

Hei, kiitos kutsusta, Ben.

Ben Aston:

On hienoa saada sinut mukaan. Tämä taitaa olla toinen podcastimme, eikö?

Kelly Suter:

Kyllä on.

Ben Aston:

Teimme podcastin jo kauan sitten. Niille, jotka ovat unohtaneet, kuka olet, haluatko kertoa lyhyesti, miten päädyit projektinhallintaan? Olet kulkenut kiinnostavaa reittiä, kuten useimmat projektipäälliköt. Harva meistä aikoi lapsena projektipäälliköksi, joten kerro hieman tarinastasi. Miten sinusta tuli digitaalinen projektipäällikkö?

Kelly Suter:

Aloitin työurani oikeastaan urheilutoimittajana. Opiskelin viestintää, painottaen suhdetoimintaa ja mediaa. Kun ymmärsin, etteivät sanomalehdet enää olleet kasvava ala, siirryin viestintä- ja julkisuusalalle. Työskentelin noin kolme vuotta tiedottajana Sesame Street Live -brändille. Sen jälkeen tuttavani, joka työskenteli räätälöityjä sähköisen kaupankäynnin ratkaisuja toteuttavassa digitoimistossa, kysyi, haluaisinko ryhtyä projektipäälliköksi.

Isälläni oli graafisen suunnittelun toimisto, joten tunsin toimistotyön prosessit riittävästi tietääkseni, että työ oli kiireistä ja jatkuvaa. Luin ensimmäisenä Meghan McInernyn kirjan People, Pixels, and Process ja sovelsin sen oppeja toimistoon. Tuolloin meitä oli kaksitoista, ja rakensimme räätälöityjä verkkokauppoja. Noin neljä vuotta myöhemmin olin kasvattanut seitsemän projektipäällikön tiimin. Prosessi kehittyi jatkuvasti, ja aloin tuntea oloni mukavaksi Magento-, Drupal-, Cantego- ja WordPress-projektien parissa. Halusin kuitenkin laajentaa teknistä osaamistani, joten siirryin nykyiseen tehtävääni BI Worldwideen tekniseksi projektipäälliköksi.

Ben Aston:

Mikä olisi unelmatyösi?

Kelly Suter:

Pidän eniten tilanteista, joissa prosessia ei vielä ole tai se on vasta kehittymässä. Nautin siitä, että saan tarttua haasteisiin ja rakentaa toimintatapoja, joiden avulla tiimi voi tuntea helpotusta: meillä on nyt jotain, jonka varaan voimme rakentaa. Unelmatyöni olisi toimia tällaisena ”palomiehenä” kasvavissa yrityksissä ja auttaa niitä luomaan toimivat prosessit. Rakastan haastavia tilanteita.

Ben Aston:

Mitä haasteita kohtaat tällä hetkellä?

Kelly Suter:

Suurin haasteeni on saada tiimi sitoutumaan dokumentointiin tavalla, joka ei tunnu tylsältä. Kun asiakas ja tiimi ovat innostuneita, on vaikeaa saada heidät ymmärtämään, ettei vauhtia tarvitse hidastaa, mutta asiat täytyy silti dokumentoida. Dokumentointi pitää myös mallintaa ja sen on katettava olennaiset asiat. Jos siirryt toiseen tiimiin, saat ylennyksen tai vaihdat tehtävää, kaiken logiikan ja prosessin ei pitäisi kadota mukanasi. Olen nähnyt tiimien keksivän jatkuvasti pyörän uudelleen sekä tuotteen rakentamisessa että dokumentoinnissa, vaikka monet asiat voitaisiin mallintaa tai tehdä tehokkaammin.

Ben Aston:

Mitä työkaluja käytät dokumentointiin?

Kelly Suter:

Käytän Google Suitea ja Google Docsia, jos asiakkaalla ei ole tietoturva- tai tietosuojaongelmia. Jaettu työtila ja käyttöoikeuksien määrittely helpottavat yhteistyötä. Versiohallinnasta ei tarvitse huolehtia, ja dokumentin voi myöhemmin viedä PDF-muotoon allekirjoitettavaksi. Luovien ratkaisujen tarkistamiseen ja kommentointiin käytän InVisionia. Jos budjetti ei riitä InVisioniin, käytän Sketchiä. En halua tehdä asiasta liian monimutkaista: tarvitsen vain tavan tuoda suunnitelmat sisään, merkitä ne, lisätä ne dokumentaatioon ja kirjoittaa tarvittavat tekstit.

Ben Aston:

Miten tekninen projektipäällikkö eroaa digitaalisesta projektipäälliköstä?

Kelly Suter:

Suurin ero on digitaalisen työn teknisen ymmärryksen taso. Digitaalisena projektipäällikkönä hallitsin kaikkia liikkuvia osia hieman ylemmältä tasolta. Teknisenä projektipäällikkönä olen paljon syvemmällä kehitystyössä. Hallitsen edelleen luovan työn, digitaalisen strategian ja laadunvarmistuksen toimituksia, mutta kehityksessä olen lähempänä koodikatselmointeja ja julkaisuja. Kirjoitan myös tekniset vaatimukset. Mitä lähempänä vaatimuksia olet, sitä enemmän vastuuta sinulla on, kun kysymykset nousevat myöhemmin esiin.

Ben Aston:

Miten jaat vastuut projektipäällikön, liiketoiminta-analyytikon ja kehittäjän välillä?

Kelly Suter:

Projektin alussa on tärkeää ymmärtää roolit ja vastuut. Voin kertoa kehittäjälle, mitä haluan tapahtuvan: esimerkiksi että varastotietojen pitää päivittyä päivittäin ja näyttää tuotteiden määrät kokojen mukaan. Kehittäjä voi kuitenkin joutua menemään tasolle, jota en itse ymmärrä. En halua teeskennellä osaavani jotain, mitä en osaa. Voin määritellä vaatimukset tiettyyn pisteeseen asti ja pyytää kehittäjää auttamaan loppuosan määrittelyssä. Tärkeintä on tunnistaa etukäteen, mitä pystyt tekemään itse ja missä tarvitset muiden asiantuntemusta.

Ben Aston:

Mitä liiketoimintavaatimusten ja toiminnallisten vaatimusten dokumentointi tarkoittaa?

Kelly Suter:

Liiketoimintavaatimusten dokumentti on korkean tason kuvaus siitä, mitä tarvitaan: sisältö pitää kääntää espanjaksi ja mandariinikiinaksi, kursseja tarvitaan kymmenen, niiden pitää olla valmiina huhtikuussa ja järjestelmän pitää tukea 6 000 käyttäjän tietokantaa. Se toimii tarkistuspisteenä, jossa kaikki varmistavat olevansa samalla sivulla. Samalla todetaan, että yksityiskohtia tarkennetaan myöhemmin ja että laajuuden tai budjetin muutoksista sovitaan erikseen.

Toiminnallisten vaatimusten dokumentti menee paljon yksityiskohtaisemmalle tasolle. Siinä määritellään, toteutetaanko käännökset kolmannen osapuolen palvelulla, automatisoidulla toiminnolla vai syötetäänkö kielet sisällönhallintajärjestelmään käsin. Liiketoimintavaatimukset ovat siis tarkistuspiste, kun taas toiminnalliset vaatimukset ovat rakennettavan ratkaisun suunnitelma.

Ben Aston:

Miten yhdistät dokumentoinnin ketterään työskentelyyn?

Kelly Suter:

Tasapaino syntyy siitä, että prosessi sovitaan etukäteen. Kaikkea ei tarvitse dokumentoida ennen työn aloittamista. On tärkeää tietää lopputavoite ja edetä viikoittain. Päivittäisissä tilannekatsauksissa sovitaan, kuka työskentelee merkkien, todistusten, tulostaulukon tai ostokokemuksen parissa. Asiakkaalle esitellään toteutusta kahden viikon välein. Sen ei tarvitse olla viimeisteltyä, vaan tarkoitus on saada toiminnallisuus paikalleen ja oppia yhdessä.

Projektipäällikkö voi dokumentoida tilannekatsaukset: mitä tänään näytetään, mitä viime viikolla tehtiin ja mitä kysymyksiä asiakkaalle on. Kun asiakas huomaa jotain odottamatonta, asia voidaan käsitellä ja seuraavan viikon suunnitelmaa muuttaa. Olennaista on jatkuva viestintä, dokumentointi työn edetessä ja luottamus.

Ben Aston:

Miten dokumentoit vaatimukset käytännössä?

Kelly Suter:

Kun toiminnallisten vaatimusten dokumentti on viimeistelty, kaikki ovat tarkistaneet sen ja asiakas on hyväksynyt sen, käytän JIRAa tehtävienhallintaan. Teen yleensä tehtävän jokaista vaatimuskohtaa varten. Jaan tarinat sivutyypeittäin, kuten rekisteröitymiseen, etusivuun ja tuotesivuun, ja teen sivutyypin jokaisesta kohdasta alitehtävän. Kehittäjien kannattaa arvioida itse oma työmääränsä, mieluiten niiden kehittäjien, jotka työn myös toteuttavat. Jos laadunvarmistus kuuluu prosessiin, jokaiseen tehtävään lisätään myös tapa testata, onnistuuko toiminto vai ei.

Ben Aston:

Miten arvioit kustannuksia projektin alussa, jos kaikkia toiminnallisuuksia ei vielä tunneta?

Kelly Suter:

Aloitan selvittämällä, mitä vastaavaa on tehty aiemmin. Samankaltaiset projektit, käyttäjämäärät ja yrityksen koko auttavat muodostamaan vertailukohdan. Alkuvaiheen arviota ei pidä esittää tarkkana totuutena. On parempi antaa vaihteluväli aikaisempien projektien perusteella ja tarkentaa arviota, kun vaatimukset määritellään.

Käytän myös kahta harjoitusta. Ensimmäisessä asiakas asettaa tärkeysjärjestykseen laajuuden, aikataulun ja budjetin. Kaikkia ei voi asettaa tärkeimmäksi. Toisessa määritellään hyvä, parempi ja paras vaihtoehto. Jos asiakkaan budjetti ei riitä kaikkeen, hän voi päättää, mistä toiminnallisuudesta luovutaan tai mikä siirretään myöhempään vaiheeseen. Näin päätös tehdään yhteistyössä eikä projektipäällikkö vain ilmoita, ettei jokin onnistu.

Ben Aston:

Mikä on ensimmäinen askel henkilölle, joka alkaa kirjoittaa vaatimuksia?

Kelly Suter:

Älä aloita lataamalla teknistä dokumentointimallia ja yrittämällä täyttää sitä. Pysähdy ensin miettimään, mitä olet rakentamassa. Jos kyseessä on tapahtuman ilmoittautumissivu, jossa on etusivu ja lomake, käy läpi sivun jokainen elementti ja kysy, mitä se tekee mobiilissa ja tietokoneella. Selitä toiminta ääneen aivan kuin selittäisit sen ihmiselle, joka ei tunne tekniikkaa. Mene sen jälkeen kehittäjän luo ja varmista, että ymmärsit oikein.

Jaa rakennettava kokonaisuus pienempiin osiin, selitä jokainen osa ja kysy kysymyksiä. Vaatimukset kehittyvät ajan myötä, eikä ensimmäisen version tarvitse olla täydellinen. Digitaalinen projekti ei ole asiakkaalle jokapäiväinen asia, joten sinun tehtäväsi asiantuntijana on auttaa häntä ymmärtämään, mitä ollaan tekemässä.

Ben Aston:

Vaatimuksissa on ennen kaikkea kyse kysymysten esittämisestä ja vastausten löytämisestä. Mikään ei ole itsestään selvää. Kun kysyt itseltäsi, mitä sinun pitäisi kertoa tästä äidillesi tai isoäidillesi, löydät usein asiat, jotka on määriteltävä.

Vaatimukset ovat viestintäväline, joka auttaa kaikkia ymmärtämään, mitä todella tehdään. Selkeys vähentää hukkaan menevää työtä, hallitsee odotuksia ja ehkäisee uudelleentyötä ja pettymystä. Dokumentointi vie aikaa, mutta se maksaa itsensä takaisin moninkertaisesti.

Kelly, kiitos paljon osallistumisesta.

Kelly Suter:

Kiitos, oli ilo olla mukana.

Ben Aston:

Kelly esiintyy myös Digitaalisen projektinhallinnan mestarointi -kurssillamme. Jos tarvitset projektinhallinnan koulutusta, tutustu kurssiin. Seitsemän viikon kokonaisuus sisältää interaktiivisia videoluentoja, tehtäviä, ryhmäkeskusteluja ja webinaareja. Siirry osoitteeseen dpmschool.com ja ilmoittaudu mukaan. Jos haluat osallistua vaatimuksia käsittelevään keskusteluun, siirry resurssiosioon ja liity Slack-tiimiimme tai kommentoi tätä artikkelia. Kuullaan jälleen seuraavalla kerralla. Kiitos kuuntelusta.