Anna kollegoillesi parempaa palautetta (Ryan Schaefer Vigetistä)

Lue litterointi:

Kokeilemme podcastiemme litterointia ohjelmiston avulla. Pahoittelemme mahdollisia kirjoitusvirheitä, sillä automaattinen litterointi ei ole aina täysin virheetön.

Ben Aston:

Tervetuloa DPM-podcastiin, jossa menemme teoriaa pidemmälle ja annamme käytännössä toimivia neuvoja parempien digitaalisten projektien johtamiseen. Kiitos, että kuuntelet. Olen Ben Aston, The Digital Project Managerin perustaja.

Miten toimit, kun sinun täytyy antaa palautetta tiimisi jäsenille? Suhtaudutko siihen luontevasti, koska olet projektipäällikkö ja tiedät olevasi oikeassa, vai vältätkö sitä, koska pelkäät, ettei sinua oteta vakavasti? Ehkä saat itse palautetta ja ajattelet, ettei kukaan oikeastaan ymmärtänyt tai edes kuullut, mitä sanoit. Projektipäällikköinä vastaamme kuitenkin onnistumisesta, ja se on vaikeaa silloin, kun tiimimme tuntuu niin usein olevan väärillä jäljillä.

Tämän päivän podcastissa saat selville yksinkertaisia tapoja antaa palautetta, joka auttaa tiimejäsi tekemään parempaa työtä ja pitää projektisi oikealla kurssilla.

Tänään vieraakseni tulee Ryan Schaefer. Ryan on siirtynyt verkkosivustojen suunnittelusta ja rakentamisesta niiden kehityksen johtamiseen, ja hän työskentelee Washingtonissa Viget-nimisessä toimistossa. Hei, Ryan.

Ryan Schaefer:

Hei Ben. Kiitos kutsusta.

Ben Aston:

Kerro hieman nykyisestä roolistasi. Erityisesti minua kiinnostaa, miten siirryit suunnittelu- ja kehitystehtävistä projektipäälliköksi. Se on kysymys, jota meiltä kysytään usein. Mitä siis teet tällä hetkellä? Onko työsi täysin projektinhallintaa vai osallistutko edelleen myös käytännön tekemiseen?

Ryan Schaefer:

Sanoisin, että työni painottuu enemmän varsinaiseen projektinhallintaan. Yksi asia, joka helpotti siirtymistäni käytännön suunnittelu- ja kehitystyöstä projektinhallintaan, oli ymmärrys ajatuksista ja prosesseista, joita suunnittelu- ja kehitystyöhön liittyy.

Sen ansiosta pystyn keskustelemaan täällä työskentelevien erittäin taitavien suunnittelijoiden ja kehittäjien kanssa melko tasavertaisesti. Minun ei tarvitse kysyä, mitä lyhenteet tarkoittavat tai mitä työkaluja käytetään.

Aiemmassa PR-toimistossa työskentelin sekä asiakkuuksien että käytännön toteutuksen parissa. Se valmensi minua ajattelemaan, miten välittäisin asioita asiakkaalle ja miten työskentelisimme muiden tiimin jäsenten kanssa. Siirtyminen laaja-alaiseen projektinhallintaan oli onneksi melko luontevaa.

Ben Aston:

Miten se tapahtui? Mikä oli se hetki, jolloin päätit: ”Selvä, minusta tulee projektipäällikkö”?

Ryan Schaefer:

Halusin hallita kokonaisuuksia lintuperspektiivistä sen sijaan, että työskentelisin siilossa. Pääsyy oli kuitenkin halu liittyä yritykseen, jossa kaikki suhtautuvat intohimoisesti digitaaliseen tekemiseen ja ajattelevat tulevaisuuteen suuntautuneesti. Digitaalisuus muuttaa ilmeisellä tavalla sitä, miten elämme yhteiskuntana ja maana. Halusin kuulua joukkoon, jossa ihmiset ymmärtävät tämän, arvostavat sitä ja ovat erittäin taitavia omilla digitaalisen työn osa-alueillaan. Se auttaisi minua myös kehittymään ammatillisesti.

Ben Aston:

Kerro hieman, mitä teet tällä hetkellä. Millainen projektipäällikön rooli Vigetissä on?

Ryan Schaefer:

Ensinnäkin yrityksen nimi on Viget. Sitä kysytään usein.

Ben Aston:

Vid-get? Vig-et?

Ryan Schaefer:

Viget, aivan.

Ben Aston:

Kävin jopa verkkosivustolla ja napsautin kissaa, joka sanoi nimen olevan Viget.

Ryan Schaefer:

Siellä on sellainen ”sano hei” -painike. Se on Viget.

Ben Aston:

Sellaista tapahtuu, kun nimi on erikoinen. Mitä se edes tarkoittaa?

Ryan Schaefer:

”Yhdessä kukoistamme” latinaksi.

Ben Aston:

Tietenkin.

Ryan Schaefer:

Jotain sen tapaista.

Ben Aston:

Äitini häpeäisi minua. Äiti, olen pahoillani. Hän opettaa latinaa. Minun pitäisi tietää tuollaisia asioita.

Ryan Schaefer:

Latina oli lukiossa vähiten suosikkiaineeni. Meidän oli pakko opiskella sitä. En voi uskoa, että meidän oli pakko, mutta niin vain oli.

Ben Aston:

Se on siis valmentanut sinut hyvin kaikkiin nykyään puhu­miisi kieliin, vai mitä?

Ryan Schaefer:

Aivan. Roolini Vigetissä projektipäällikkönä sisältää monia asioita. Siihen kuuluvat tietenkin projektipäällikön keskeiset vastuut, kuten aikataulut, budjetti, suunnittelu, henkilöstö ja resurssit. Lisäksi tehtäviini kuuluu asioita, jotka liittyvät enemmän tuotehallintaan. Meillä ei ole erillisiä tuotepäälliköitä, joten projektipäälliköt vastaavat käyttäjäpoluista, ominaisuuksien määrittelystä, laadunvarmistustestauksesta sekä työskentelevien yritysten ja rakennettavien tuotteiden perusteellisesta ymmärtämisestä.

Ben Aston:

Eli projektinhallintaa ja tuotehallintaa?

Ryan Schaefer:

Kyllä, se on niiden yhdistelmä.

Ben Aston:

Vähän molempia.

Ryan Schaefer:

Niin. Ne kulkevat käsi kädessä, ja niiden tekemisestä yhdessä on hyötyä. Toisaalta ne ovat riittävän erilaisia, joten työskentelytapaa on mukava vaihtaa: välillä työskentelet projektin parissa ja välillä johdat projektia.

Ben Aston:

Voitko kertoa hieman projekteista, joiden parissa työskentelet tällä hetkellä?

Ryan Schaefer:

Vaihdoimme pari viikkoa sitten tilanteeseen, jossa työskentelen kokopäiväisesti yhden projektin parissa. Se on minulle ensimmäinen kerta. Rakennamme suurta markkinointisivustoa ja eräänlaista portaalia eri yleisöryhmille. Käyttäjät voivat kirjautua sisään, ja kullekin ryhmälle haetaan erilaista dataa.

Uudistamme siis koko digitaalisen kokonaisuuden, päivitämme kaikkien julkisten digitaalisten materiaalien ulkoasun ja laadimme tiekarttaa tuleville tuotteille, kuten mahdolliselle sovellukselle. Projekti on hyvin laaja, ja olen innostunut siitä, että voin perehtyä yhteen hankkeeseen kunnolla.

Ben Aston:

Tiedän, että pidät DPM Summitissa tulevan Lightning Talk -esityksen natiivisovelluksen rakentamisen hallinnasta. Voitko antaa meille lyhyen version puheestasi? Mitä olet oppinut natiivisovellusten rakentamisesta?

Ryan Schaefer:

Puheeni perustuu siihen, mitä opin suurimmassa projektissani täällä: Android-sovelluksen suunnittelu- ja kehitysprojektissa. Kerron erityisesti natiivisovelluksen ja tavallisemman verkkosivuston rakentamisen hallinnan eroista, parhaista käytännöistä sekä teknisistä vaatimuksista, jotka projektipäällikön on tunnettava.

Esimerkiksi sovelluksen virheen hinta on suuri, koska sovellus voi kaatua. Verkkosivuston virhe voidaan yleensä korjata lataamalla sivu uudelleen. Natiivisovelluksissa käytettävät kielet eivät myöskään toimi kuten JavaScript verkkosovelluksissa. Sovellusta varten ratkaisu on usein suunniteltava lähes kokonaan itse, kun taas verkkosovelluksissa JavaScript voi hoitaa suuren osan työstä.

Lisäksi sovelluksiin liittyy järjestelmän ohjaimia ja muita rajoitteita, kuten verkkoyhteydettömän tilan vaatimuksia. Miten sovellus toimii ilman verkkoyhteyttä? Miten puhelimen valikkopainikkeet toimivat sovelluksen kanssa ja mihin ne ohjaavat käyttäjän? Tällaiset asiat on otettava huomioon.

Ben Aston:

Olet tehnyt verkkosovelluksia ja natiivisovelluksia. Aiemmin sanoin, että kaikki tekevät verkkosovelluksia, koska ne ovat helpompia ja nopeampia rakentaa. Miten näet verkkosovellusten ja natiivisovellusten tulevaisuuden?

Ryan Schaefer:

Yksi kiinnostava asia on esimerkiksi Squarespacen, WordPressin Beamsin ja Weeblyn kaltaisten palveluiden yleistyminen. Ne ovat käytännöllisiä palveluita, joiden avulla vähäisellä teknisellä osaamisella voi tehdä hyvännäköisen verkkosivuston.

Niiden edullisuuden ja helppokäyttöisyyden vuoksi perinteisiä markkinointisivustoja on vaikeampi löytää. Natiivisovellukset eivät ole vielä avautuneet samalla tavalla, joten näemme siinä paljon mahdollisuuksia. On myös yksinkertaisesti hienoa voida sanoa, että meillä on sovellus.

Ben Aston:

Mitä projektinhallinnan työkalupakistasi löytyy? Miten hallitset tuotteita ja projekteja? Mitä haluat saada käyttöön projektin alussa?

Ryan Schaefer:

On tärkeää aloittaa vahvasti. Järjestän mielelläni keskusteluun perustuvia asiakkaan aloitustapaamisia. Myös visiopuhelu on hyödyllinen: siinä keskustellaan organisaation nykytilasta, tuotteen nykyisistä ja puuttuvista ominaisuuksista sekä tavoitteista. Lisäksi järjestän ongelmia, tavoitteita ja päämääriä käsitteleviä työpajoja sekä sidosryhmähaastatteluja.

Myyntiprosessissa ei voi selvittää kaikkea, vaikka siihen käytettäisiin kuinka paljon aikaa. Kun nämä asiat ymmärtää, projektin käynnistämiseen on käytettävissä kaikki tarvittava tieto. Se nopeuttaa aloittamista, tehostaa rakentamista ja johtaa parempaan lopputuotteeseen.

Kaiken tämän hallintaan voi käyttää monia työkaluja. Airtable on hyvä, samoin GitHub Projects, ZenHub, jota voi käyttää GitHubin kanssa, sekä Trello. Olemme käyttäneet niitä asiakkaiden mieltymysten ja omien suositustemme mukaan.

Ben Aston:

Onko jokin projektinhallinnan työkalu tai oikotie, jonka olet hiljattain löytänyt ja joka helpottaa työtäsi?

Ryan Schaefer:

Kaksi asiaa. Ensimmäinen on tietokoneeni pikanäppäimet. Niiden opetteluun kannattaa käyttää aikaa, koska sekunnit säästyvät päivän aikana satoja kertoja.

Ben Aston:

Mikä on viimeisin suosikkipikanäppäimesi?

Ryan Schaefer:

Komento-vaihto-T avaa viimeksi suljetun välilehden.

Ben Aston:

Hyvä.

Ryan Schaefer:

Se on hyödyllinen.

Ben Aston:

Minun suosikkini on Windows-V. Windows 10:ssä se näyttää leikehistorian, johon sisältyvät myös kuvat. Se on hyödyllistä, jos kopioin jotain ja unohdan liittää sen.

Ryan Schaefer:

Uusi käyttämäni työkalu on Notion. Oletko kuullut siitä?

Ben Aston:

Olen.

Ryan Schaefer:

Se on eräänlainen työtila. Sitä voi käyttää muistiinpanoihin ja yhteistyöhön, siinä on verkkoyhteydettömän tilan toimintoja ja selkeä käyttöliittymä. Sivuille voi upottaa sisältöä, lisätä avattavia osioita ja sisäkkäisiä alasivuja. Se toimii verkossa ja mobiilissa ja on hyvin mukautettava.

Ben Aston:

Mikä on vaikeinta projekteissasi ja työkaluissasi? Mitkä ovat arjen suurimmat haasteet?

Ryan Schaefer:

Asioita on paljon. Yksi niistä on ajan puute. Vaikeinta on kuitenkin asiayhteyden vaihtaminen. Projektipäälliköllä on usein useita projekteja ja paljon kokouksia. Siirryt kokouksesta toiseen ja joudut palauttamaan mieleesi projektin tiedot matkalla seuraavaan huoneeseen.

Selviän siitä tekemällä huolellisia muistiinpanoja, joihin voin palata nopeasti. Laadin myös esityslistan jokaiseen kokoukseen. Lisäksi käytän päivän alussa aikaa siihen, että mietin kahvikupin ääressä jokaisen projektin tilannetta sekä sitä, missä niiden pitäisi olla päivän lopussa.

Toinen haaste on yhteistyön ja aloituksen järjestäminen suunnittelijoiden ja kehittäjien välisessä siirtymässä. Suunnittelija voi tehdä kauniin mallin, mutta staattisesta kuvasta ei aina ole selvää, miten kaikki käyttöliittymän ominaisuudet ja hallintanäkymän ohjaukset pitäisi dokumentoida.

Siksi tutkimme Airtablen kaltaisia tapoja jäsentää sisältö siten, että mallin eri elementit voidaan yhdistää toisiinsa. Kehittäjä näkee silloin, miten kukin osa toimii ja mitä se vaatii ajallisesti ja budjetin kannalta.

Ben Aston:

Miten Airtable toimii tässä käytännössä?

Ryan Schaefer:

Jos aloitamme käyttöliittymän tutkimisen, dokumentoimme sivustokartan avulla, mihin jokainen navigointielementti johtaa. Sen jälkeen voimme tehdä uusia näkymiä, verrata niitä nykyiseen tilanteeseen ja lisätä uusia alueita. Niitä voi erotella tunnisteilla, luokilla, lohkoilla, otsikoilla ja väreillä.

Näin syntyy selkeä ja helposti ymmärrettävä kokonaisuus, jota kaikki voivat tarkastella projektin aikana ja joka toimii kaiken yhteisenä totuuden lähteenä.

Ben Aston:

Puhutaan kirjoittamastasi artikkelista. Se käsittelee palautteen antamista tavalla, joka hyödyttää projektia ja johtaa parempaan tuotteeseen tai projektiin.

Miksi ihmiset pidättäytyvät palautteen antamisesta?

Ryan Schaefer:

Ensimmäinen syy on inhimillinen: emme halua loukata työtovereitamme tai vähätellä heidän tekemäänsä työtä. Toinen syy on se, ettemme ehkä luota omaan mielipiteeseemme, kun annamme palautetta alan asiantuntijoille, suunnittelijoille ja kehittäjille.

Nämä ovat ymmärrettäviä huolia, mutta projektipäällikkönä olet usein lähimpänä asiakasta. Näet työn tuorein silmin ja pystyt parhaiten jäljittelemään loppukäyttäjän näkökulmaa. Tarjoat siis erilaisen näkökulman kuin henkilö, joka on itse rakentanut työn.

Voit luottaa tähän osaamiseen ja näkökulmaan. Kun näet työn ensimmäistä kertaa, voit kysyä: välittääkö se selkeästi, mitä organisaatio tekee? Puhuuko se kohderyhmille? Onko selvää, että kyseessä on avattava valikko? Tällaiset reaktiot auttavat tiimiä vertaamaan työtä käyttäjien odotettuun toimintaan ja liiketoiminnan tavoitteisiin.

Ben Aston:

Artikkelissa annat kymmenen ohjetta hyvän palautteen antamiseen. Ensimmäinen on itsesi valmistaminen ja riittävän tiedon hankkiminen liiketoiminnan onnistumisen näkökulmasta. Miten tiedät, milloin olet riittävän hyvin perillä asioista?

Ryan Schaefer:

Et oikeastaan koskaan tiedä olevasi täysin perillä, eikä se haittaa. Visiopuhelut ovat hyvä lähtökohta, koska niissä selviää, miten yritys näkee itsensä ja mihin se haluaa mennä. Keskustelut johtoryhmän sidosryhmien kanssa auttavat ymmärtämään, miten tavoitteet aiotaan toteuttaa.

Kun aloitat keskusteluun perustuvan aloitustapaamisen projektin suorien osallistujien kanssa, ymmärrät, miten projekti liittyy johdon suunnitelmiin ja liiketoiminnan tavoitteisiin.

Kyseessä on kehittyvä prosessi, joka vaatii paljon panostusta alussa. Löytämisvaiheiden tarkoitus on vastata juuri näihin kysymyksiin. Se tehostaa prosessia ja johtaa parempaan lopputulokseen.

Ben Aston:

Miten tutustut osa-alueisiin, jotka eivät ole sinulle entuudestaan tuttuja, kuten laadunvarmistukseen tai käyttäjäkokemukseen?

Ryan Schaefer:

Toivottavasti palaute annetaan diplomaattisesti ja objektiivisesti, ei subjektiivisesti. Opit puhumalla mahdollisimman monien tiimin jäsenten kanssa ja olemalla avoin oman osaamisesi aukoista. Jos olen kehitystaustainen enkä tunne käyttäjäkokemusta yhtä hyvin, minun ei pidä pelätä seurata käyttäjäkokemussuunnittelijan työtä.

Toinen tapa on tehdä itse. Saatavilla on paljon resursseja ohjelmoinnin ja suunnittelun opetteluun. Voit ammentaa inspiraatiota tiimisi projekteista, seurata trendejä ja lukea artikkeleita. Käytän noin viisi tuntia viikossa suunnittelun harjoitteluun, koodaustaitojeni ylläpitämiseen ja artikkeleiden lukemiseen.

Ben Aston:

Onko sinulla verkkosivustoja, joiden avulla pysyt ajan tasalla?

Ryan Schaefer:

Thedigitalprojectmanager.com on hyvä. Myös A Girl’s Guide to Project Management on hyödyllinen. Adweek kertoo luovan alan suunnasta. Kehitystyössä W3Schools tarjoaa resursseja CSS:ään, JavaScriptiin ja palvelinpuolen tekniikoihin.

Ben Aston:

Oletko koskaan saanut palautteesta kielteistä vastareaktiota?

Ryan Schaefer:

En onneksi vielä. Se johtuu osittain hienoista työtovereistani. Toinen syy on se, että kun tarkastelet asiaa aidosti asiakkaan näkökulmasta, tiimisi kunnioittaa sitä. Palaute ei silloin ole esimerkiksi ”en pidä tuosta väristä”, vaan ”tiedämme, että heidän brändiohjeissaan tämä on toissijainen väri. Se vie paljon tilaa. Voisiko se olla heille häiritsevä?”

Ben Aston:

Miten yhdistät rakentavan palautteen, tiukan rakkauden ja kannustamisen sotkematta viestiä?

Ryan Schaefer:

Siihen ei ole tarkkaa kaavaa. Projektipäällikön tunneäly auttaa lukemaan ihmisten reaktioita. Kielteisiä reaktioita ehkäisee parhaiten täsmällisyys. Älä aja subjektiivisia mieltymyksiä, vaan objektiivisia päätöksiä, jotka liittyvät projektin tavoitteisiin.

Kannattaa myös viestiä hienovaraisesti, että luotat henkilön kykyyn toteuttaa työnsä. Se kannustaa ihmisiä riippumatta siitä, ottavatko he kritiikin henkilökohtaisesti vai käyttävätkö he sitä kehittymiseen.

Ben Aston:

Mikä olisi ensimmäinen asia, joka kannattaa muistaa, jos oma ääni ei tunnu merkitsevän mitään?

Ryan Schaefer:

Kun näet ensimmäisen kerran jotain, joka näyttää väärältä, sinun ei tarvitse ilmaista mielipidettäsi heti. Palaa työpöytäsi ääreen, tarkastele asiaa ja tee muistiinpanoja. Kirjaa, missä suunnittelu tai muu tuotoksessa ei osu tavoitteeseen, ja ennen kaikkea ehdota parannuksia.

Näin saat aikaa ymmärtää harjoituksia, joita työn tekijä on tehnyt, ja voit valmistautua perustelemaan ehdotuksesi. Mitä perusteellisempi olet, sitä enemmän tiimisi jäsen kunnioittaa palautetta ja on valmis hyödyntämään sitä seuraavassa versiossa.

Ben Aston:

Hyvä neuvo. Ihmiset voivat puolustautua, jos sanomme vain, ettemme pidä jostakin. On parempi selittää, miksi ratkaisu vaikuttaa väärältä, yhdistää perustelu asiakkaan tarpeisiin ja kysyä tekijältä, miten hän ajatteli asian toimivan. Sen jälkeen voimme ehdottaa mahdollisia ratkaisuja.

Kiitos paljon, Ryan, että liityit seuraamme.

Ryan Schaefer:

Kiitos paljon. Arvostan sitä.

Ben Aston:

Mitä sinä ajattelet? Oletko koskaan yrittänyt antaa palautetta, ja miten siihen reagoitiin? Oliko tiimi ärsyyntynyt vai iloinen siitä, että toit esiin jotain, mitä he eivät olleet huomanneet?

Kerro mielipiteesi kommentoimalla artikkelia ja siirry osoitteeseen thedigitalprojectmanager.com liittyäksesi Slack-tiimiimme. Siellä käydään kiinnostavia keskusteluja kaikesta projektien toimittamiseen liittyvästä.

Jos pidit tämän päivän jaksosta, tilaa podcast ja käytä pari minuuttia rehellisen arvostelun jättämiseen DPM-podcastille Apple Podcastsissa. Arvostamme suuresti arvioitasi ja palautettasi.

Ensi kertaan asti, kiitos kuuntelusta.