Saavutettavuus jää usein epämukavasti tuotekehityksen tiekarttakeskustelujen marginaaliin. Monet organisaatiot asettavat etusijalle ominaisuudet, joilla on suurin vaikutus, ja jättävät taka-alalle ne, joista hyötyy pienempi osuus käyttäjistä. Saavutettavuudesta käytävä keskustelu ei kuitenkaan liity vain osallisuuteen, vaan se kytkeytyy myös liiketoimintaetiikkaan ja markkinoiden laajentamiseen.
Tässä jaksossa Hannah Clarkin vieraana on Prerna Ramachandra — Yahoon johtava tuotepäällikkö. He perehtyvät saavutettavuuden liiketoimintaperusteluihin ja tehokkaisiin strategioihin, joiden avulla se voidaan integroida saumattomasti osaksi tuotekehitystä.
Haastattelun kohokohdat
- Tutustu Prerna Ramachandraan [01:06]
- Prerna työskentelee tällä hetkellä Yahoon pääasiallisena tuotepäällikkönä.
- Aiemmin hän työskenteli Slackilla johtaen saavutettavuutta, suunnittelujärjestelmiä ja keskeisiä työpöytäkokemuksia, myös Salesforce-yrityskaupan aikana.
- Hän työskenteli The Washington Postilla uudistaen etusivun ja siirtäen artikkelisivukokemukset uudelle alustalle.
- Hänen taustansa ulottuu media- ja suurten teknologiayritysten toimialoille.
- Hänen intohimonsa kohdistuu tuotteen, teknologian ja tarinankerronnan leikkauspisteeseen, jotta viestintää voidaan parantaa teknologian avulla.
- Saavutettavuuden liiketoimintaperustelut [02:22]
- Teknologia ei ole enää ylellisyyttä; olennaiset palvelut on digitalisoitu, ja niiden on oltava kaikkien saavutettavissa.
- Saavutettavuus jää usein huomiotta, koska sen liiketoiminta-arvoa ei ymmärretä ja sen koetaan olevan teknisesti monimutkaista.
- Yritykset käsittelevät saavutettavuutta yleensä reaktiivisesti, usein välttääkseen oikeusjutut tai täyttääkseen tiettyjen asiakkaiden tarpeet.
- Saavutettavuuden priorisointi lisää tuotteen käyttöä, tavoittaa enemmän käyttäjiä ja kasvattaa liikevaihtoa.
- Saavutettavuus vähentää oikeudellisia riskejä ja niihin liittyviä kustannuksia.
- Saavutettavuuden tulisi ulottua ruudunlukijoita ja näppäimistönavigointia laajemmalle ja kattaa myös tilanteiset tarpeet (esimerkiksi äänikomennot kuljettajille tai näkövammaisille käyttäjille).
- Saavutettavuuden laajentaminen hyödyttää laajempaa käyttäjäkuntaa, parantaa inklusiivisuutta ja liiketoiminnan tuloksia.
- Prernan matka Slackilla [06:49]
- Prernan ensimmäinen projekti Slackilla keskittyi tuotteen saavutettavuuden nykytilan arviointiin.
- Hän kehitti Slackin sisäiset saavutettavuusstandardit yhdistämällä WCAG-ohjeistukset Slackia koskeviin erityisnäkökohtiin.
- Hän loi viitekehyksen ominaisuuksien arviointiin sellaisten kriteerien perusteella kuin näppäimistö- ja ruudunlukijasaavutettavuus sekä laadulliset tekijät, kuten neuroepätyypillisten henkilöiden käyttäjäkokemus.
- Ominaisuudet luokiteltiin (A, B tai C), jotta ongelmat voitiin priorisoida kiireellisyyden ja vaikutuksen perusteella.
- Viitekehystä käytettiin sekä olemassa olevan tuotteen arviointiin että tulevaan tuotekehitykseen.
- Hän työskenteli yhteistyössä yksittäisten tiimien kanssa saavutettavuuskorjausten integroimiseksi tiekarttoja häiritsemättä ja esitteli johdolle selkeät kompromissit sekä vaikutusarviot.
- Slackin johto tuki työtä, mutta tarvitsi selkeää tietoa työmäärästä, aikatauluista ja kompromisseista saavutettavuustyön tehokasta priorisointia varten.
- Hän korosti teknisen analyysin, ihmisten johtamisen ja johdon sitoutumisen tasapainottamista saavutettavuuden parantamiseksi.
- Kompromissit ja saavutettavuuden priorisointi [11:49]
- Slackin ydinviestintätiimi käsitteli kriittisimmät saavutettavuusongelmat laajan vaikutusalueensa ja suuren vaikutuksensa vuoksi.
- Saavutettavuusongelmat priorisoitiin yhteistyöprosessilla, johon osallistui tuotepäälliköitä, insinöörejä ja johtoa.
- Alkuperäisiä ongelmalistoja supistettiin kuulemalla tuotepäälliköitä, jotta vähemmän kriittiset kohdat voitiin poistaa; samalla rajattiin pois alueet, jotka oli tarkoitus suunnitella uudelleen tai poistaa käytöstä.
- Insinöörit tekivät työmääräanalyyseja selvittääkseen, mitkä tehtävät voitiin sisällyttää olemassa oleviin sprintteihin tiekarttoja häiritsemättä.
- Jäljelle jääneet, kompromisseja vaatineet korkean prioriteetin ongelmat vietiin johdolle ohjeistusta varten.
- Johdon päätöksissä tasapainotettiin asiakkaiden vaatimuksia saavutettavuuskorjauksista ja uusien ominaisuuksien julkaisemisesta.
- Myöhemmin otettiin käyttöön saavutettavuuteen keskittyvät sprinttiviikot, jotka ajoitettiin esimerkiksi kansainvälisen saavutettavuustietoisuuspäivän yhteyteen ongelmien ratkaisemiseksi eri tiimeissä ja yhteistyön edistämiseksi.
- Työpajat ja yhteisötoiminta auttoivat lisäämään organisaation tietoisuutta saavutettavuudesta ja sitoutumista siihen.
- Yhteistyö tiimien välillä saavutettavuuden edistämiseksi [18:12]
- Saavutettavuutta koskeva yhteistyö edellyttää rakenteellista yhteensovittamista ja selkeää viestintää keskitettyjen saavutettavuustiimien ja ominaisuustiimien välillä.
- Keskitetyn saavutettavuusorganisaation asema tulisi määritellä siten, että siiloutuminen vältetään ja tiimien välistä yhteistyötä helpotetaan.
- Jatkuva viestintä tiekarttojen suunnittelun, suunnittelutyön ja kehityksen aikana on ratkaisevan tärkeää saavutettavuuden integroimiseksi.
- Saavutettavuus alkaa suunnitteluvaiheesta; Figma-työkalut voivat auttaa suunnittelijoita luomaan saavutettavia suunnitelmia jo varhaisessa vaiheessa.
- Keskitetyt viitekehykset ja standardit antavat tiimeille mahdollisuuden priorisoida saavutettavuusongelmia tukeutumatta yksinomaan asiantuntijoihin.
- Viitekehykset auttavat luokittelemaan ongelmat tärkeysjärjestyksen mukaan (kriittiset, keskitasoiset, vähäiset) ja varmistamaan yhdenmukaisuuden tiimien välillä.
- Ominaisuustiimien varustaminen työkaluilla ja ohjeistuksella vähentää riippuvuutta keskitetyistä tiimeistä ja varmistaa jaetun vastuun.
- Saavutettavuuden ennakoiva sisällyttäminen suunnitteluprosessiin ehkäisee tulevia saavutettavuusvirheitä ja reaktiivisia korjauksia.
Sinun on varmistettava, että tiimisi on sijoitettu oikeaan paikkaan. Ja jos näin ei ole, sinun tuotepäällikkönä on tehtävä töitä ottaaksesi yhteyttä kaikkiin näihin muihin tiimeihin, ymmärtääksesi niiden tiekartat ja tutustuaksesi niihin, jotta voitte työskennellä hyvin yhdessä.
Prerna Ramachandra
- Tulevan saavutettavuuden varmistaminen [22:57]
- Saavutettavuus on integroitava tiekarttasuunnitteluun ja suunnitteluun alusta alkaen.
- Käyttäjätutkimus on ratkaisevan tärkeää; ota vammaiset käyttäjät mukaan varhaisessa vaiheessa ymmärtääksesi saavutettavuustarpeet.
- Tee yhteistyötä saavutettavuusasiantuntijoiden kanssa suurten projektien aikana varmistaaksesi saavutettavat suunnitelmat ja työnkulut.
- Käytä Figma-kaltaisia työkaluja saavutettavuusmäärittelyjen luomiseen suunnittelun kehittämisen rinnalla.
- Suunnittele saavutettavuuteen perehdyttämisen kokemukset ennakoivasti Applen kaltaisten esimerkkien innoittamana ohjataksesi käyttäjiä tehokkaasti.
- Kerää ja analysoi käyttäjäpalautetta puutteiden tunnistamiseksi ja saavutettavuusominaisuuksien parantamiseksi.
- Hyödynnä erikoistuneita resursseja, kuten Fablea, saavutettavuuteen keskittyvään käyttäjätestaukseen ja palautteeseen.
- Kouluta suunnittelijoita saavutettavuudessa tai ota asiantuntijat mukaan koko suunnittelu- ja testausvaiheen ajan.
- Vältä jälkikäteen tehtäviä korjauksia sisällyttämällä saavutettavuusnäkökohdat kehityksen alkuvaiheisiin.
Kun rakennat uutta tuotetta, varmista, että otat yhteyttä ihmisiin, joilla on oikeanlaista asiantuntemusta, ja sisällytä saavutettavuus suunnitteluprosessiin heti alusta alkaen. Tämä auttaa välttämään ongelman, jossa virheitä alkaa ilmetä myöhemmin ja joudut kiireessä asettamaan niitä tärkeysjärjestykseen.
Prerna Ramachandra
- Saavutettavuuden onnistumisen mittaaminen [29:20]
- Pelkkä määrällinen data ei voi mitata luotettavasti saavutettavuusominaisuuksien onnistumista käyttäjien segmentoinnin eettisten ja käytännöllisten rajoitusten vuoksi.
- Saavutettavuutta mitataan parhaiten laadullisen tutkimuksen avulla, mukaan lukien suorat keskustelut käyttäjien kanssa heidän kokemuksistaan.
- Saavutettavuuden ohjelmointirajapintojen kaltaisten työkalujen käyttöä voidaan mitata sisäisesti kehitystiimien käyttöönottoprosenttien avulla.
- Laadullisen palautteen yhdistäminen joihinkin määrällisiin mittareihin (esimerkiksi saavutettavuuteen perehdyttämisen hyväksymisprosentteihin) antaa kattavamman kuvan.
- Onnistuminen edellyttää, että käyttäjät pystyvät suorittamaan tehtäviä tehokkaasti, ei vain sitä, että ominaisuudet ovat olemassa.
- Saavutettavuuteen liittyvät toimet eivät ole koskaan täydellisiä; jatkuva käyttäjien osallistaminen ja palaute ovat välttämättömiä.
- Saavutettavuusominaisuuksiin tukeutuvat käyttäjät antavat usein aktiivisesti arvokkaita näkemyksiä tarpeidensa kriittisyyden vuoksi.
- Tuotepäälliköiden on hyväksyttävä epävarmuus ja asetettava ihmisten välinen yhteys etusijalle ymmärtääkseen ja parantaakseen saavutettavuuden tuloksia.
Tutustu vieraaseemme
Prerna Ramachandra toimii Yahoolla johtavana tuotepäällikkönä ja johtaa uuden Yahoo Creators -sisällöntuottajaohjelman taustalla olevan teknologian kehittämistä. Ennen Yahoo’lle siirtymistään hän toimi Slackin vanhempana tuotepäällikkönä Salesforce-yrityskaupan aikana. Prerna oli keskeisessä roolissa työpöytäsovelluksen uudelleensuunnittelussa ja alustan saavutettavuuden laajentamisessa kaikille käyttäjille. Hän johti pilottihanketta, jossa otettiin käyttöön uusia työkaluja ja standardeja, jotka on sittemmin otettu käyttöön kaikissa Slackin tuotetiimeissä.
Hän toimi myös tuotepäällikkönä The Washington Postissa pian sen jälkeen, kun Jeff Bezos oli ostanut sen. Siellä hän ja hänen tiiminsä olivat edelläkävijöitä Arc Publications -teknologiassa ja sisällönhallintajärjestelmässä, jonka avulla Boston Globen ja Popular Sciencen kaltaiset mediayhtiöt voivat nykyaikaistaa verkkosivustojaan, mobiilisovelluksiaan ja digitaalisia työkalujaan.
Uransa alkuvaiheessa Prerna toimi tuotepäällikkönä NGP VANilla, joka tarjoaa teknologiaa edistyksellisille poliittisille kampanjoille ja voittoa tavoittelemattomille järjestöille. Hän aloitti teknologiauransa Intuitilla tuotepäällikkönä työskennellen QuickBooks Onlinen parissa.
Prerna on myös innokas kirjoittaja ja riippumaton elokuvantekijä. Hän suoritti tietojenkäsittelytieteen kandidaatin tutkinnon Princetonin yliopistossa.
Et voi luottaa pelkästään määrälliseen dataan ymmärtääksesi, toimivatko saavutettavuusominaisuutesi ja onko tuotteesi saavutettava.
Prerna Ramachandra
Tämän jakson resurssit:
- Tilaa CPO Clubin uutiskirje
- Verkostoidu Prernan kanssa LinkedInissä
Aiheeseen liittyvät artikkelit ja podcastit:
Lue litterointi:
Kokeilemme podcastiemme litterointia ohjelmiston avulla. Antakaa anteeksi mahdolliset kirjoitusvirheet, sillä botti ei ole sataprosenttisen tarkka.
Hannah Clark: Luulen, että meidän on aika myöntää, että saavutettavuudesta puhuminen tekee meidät usein epämukaviksi. Tuotekontekstissa asetamme yleensä etusijalle ominaisuudet, joilla on suurin vaikutus ja joita käyttää suurin osa käyttäjistä. Kun puhumme saavutettavuuden huomioimisesta, aihe tuntuu siksi latautuneelta. Mihin kohtaan tiekarttaa sijoitamme ominaisuudet, joilla on suuri vaikutus suhteellisen pieneen käyttäjäryhmään? Mistä tiedämme, miltä saavutettavuuden pitäisi tuotteessamme näyttää, kun saavutettavuus tarkoittaa eri ihmisille eri asioita? Ja miten teemme kaiken tämän tekemättä oletuksia tai loukkaamatta tahattomasti käyttäjiä, joita yritämme tukea?
Vieraana on tänään Prerna Ramachandra, Yahoon Principal Product Manager. Ennen Yahooa Prerna työskenteli Slackin Senior Product Managerina, jossa hänellä oli keskeinen rooli tuotteen monipuoliselle käyttäjäkunnalle tarkoitettujen saavutettavien ominaisuuksien kartoittamisessa ja kehittämisessä. Seuraavassa kuulette osittain tapaustutkimuksen ja osittain toimintaohjeen saavutettavuuden liiketoimintaperusteista sekä tehokkaimmista ja eettisimmistä tavoista tehdä tuotteesta kaikille vastaanottavaisempi. Aloitetaan.
Tervetuloa takaisin The CPO Club -podcastiin. Olemme tänään täällä Prerna Ramachandranin kanssa.
Prerna, kiitos paljon, että löysit kiireisestä aikataulustasi aikaa liittyä seuraamme.
Prerna Ramachandra: Kiitos paljon kutsusta. On hienoa olla täällä.
Hannah Clark: Voitko kertoa hieman taustastasi ja siitä, miten päädyit nykyiseen tilanteeseesi?
Prerna Ramachandra: Toimin tällä hetkellä Yahoon Principal Product Managerina. Olen ollut täällä noin puolitoista vuotta. Ennen Yahooa työskentelin Slackilla. Olin siellä juuri ennen kuin Salesforce osti yrityksen ja jatkoin myös yrityskaupan jälkeen. Slackilla johdin pääasiassa saavutettavuus- ja suunnittelujärjestelmätiimiä, ennen kuin siirryin työskentelemään heidän keskeisen työpöytäkokemuksensa sovelluksen parissa.
Työni siirtyminen tiimistä toiseen liittyi tavallaan molempiin alueisiin, ja haluaisin perehtyä siihen myöhemmin tänään. Ennen Slackia työskentelin Washington Postilla, jossa johdin etusivun uudelleensuunnittelua ja artikkelisivukokemuksen siirtämistä uudelle alustalle. Minulla on siis kokemusta mediasta ja suurista teknologiayrityksistä.
Sanon mielelläni, että kiinnostukseni tuotteisiin liittyy erityisesti tuotteen, teknologian ja tarinankerronnan leikkauspisteeseen: siihen, miten ihmiset käyttävät tarinoita viestimiseen ja miten teknologia voi olla tehokas väline tähän.
Hannah Clark: Mikä sopii täydellisesti siihen, että olet täällä tänään kertomassa tarinaasi.
Olemme molemmat selvästi intohimoisia tarinankerronnan suhteen. Tänään keskitymme ehkä hieman rajatumpaan aiheeseen, mutta ehdottomasti asiaan, josta emme mielestäni puhu tarpeeksi: saavutettavuuteen ja erityisesti saavutettavuuden sekä käyttäjän käyttöönoton väliseen yhteyteen.
Aloitetaan siis tästä: miksi saavutettavuus kokemuksesi mukaan usein jää jälkikäteen mietittäväksi? Ja mikä on sen sisällyttämisen liiketoimintaperuste heti alusta alkaen?
Prerna Ramachandra: Ehdottomasti. Haluan aloittaa lauseesta, johon todella uskon: elämme aikaa, jolloin teknologia ei mielestäni enää ole ylellisyyttä.
Kasvoin 1990-luvulla, joten paljastan tässä hieman ikäni. Tuolloin teknologia oli vielä uutuus, samoin internet. Kaikilla ei ollut siihen pääsyä, eikä kaikkien tarvinnutkaan käyttää sitä. Elämme kuitenkin nyt aikaa, jolloin jokainen välttämätön palvelumme on tavalla tai toisella digitalisoitu. Tämä tarkoittaa, että jokaisen maailman ihmisen pitäisi voida käyttää niitä helposti.
Yhteiskunnassamme vammaisia ihmisiä kohdellaan yleensä jälkikäteen huomioitavana ryhmänä. Monet palveluistamme eivät ole riittävän saavutettavia, mutta teknologia on erityisessä asemassa, koska saavutettavuus voidaan sisällyttää siihen melko helposti. Teknologia voi myös tehdä kaikkien ihmisten, mukaan lukien vammaisten, elämästä paljon helpompaa.
Siksi tämä on yksi tärkeimmistä syistä priorisoida saavutettavuutta moraalisesta ja eettisestä näkökulmasta. Miksi se jää usein jälkikäteen mietittäväksi? Suoraan sanottuna siksi, etteivät useimmat organisaatiot täysin ymmärrä sen liiketoimintaperustetta. Ensinnäkin. Toiseksi ihmiset ajattelevat, että saavutettavuus vaatii syvällistä teknistä asiantuntemusta.
He eivät aina koe omaavansa tällaista asiantuntemusta tai muista ajatella asiaa. Saavutettavuus ei ole sisällytetty prosesseihimme. Tämän seurauksena jätämme sen huomiotta, kunnes joku pelkää oikeusjuttua tai saavutettavuusvaatimuksia omaavan asiakkaan menettämistä.
Sitten tiimit joutuvat yhtäkkiä kiireellä selvittämään, mikä on vialla ja miten saavutettavuus rakennetaan tuotteeseen. Vastatakseni kysymyksesi toiseen osaan eli saavutettavuuden liiketoimintaperusteeseen: teknologian menestyksen kannalta haluat enemmän käyttäjiä, eikö niin? Useimmille meistä maksetaan sitä enemmän, mitä enemmän tuotetta käytetään.
Mitä useampi ihminen voi käyttää tuotetta, sitä useampi sitä käyttää. Perustasolla saavutettavuus on tärkeää siksi, että useammat ihmiset voivat käyttää tuotteitasi, ja kun useammat käyttävät niitä, ansaitset enemmän rahaa. Kääntöpuolena et halua joutua oikeuteen, sillä silloin saatat joutua maksamaan paljon rahaa.
Molemmista näkökulmista saavutettavuudelle voidaan siis esittää liiketoimintaperuste. Haluan lisätä vielä yhden asian, johon palaan tarkemmin. Olen henkilökohtaisesti hyvin intohimoinen saavutettavuuden alalla siitä, että rajoitamme saavutettavuuden ajatuksen usein näytönlukijoiden käytettävyyteen tai näppäimistönavigoinnin mahdollistamiseen.
Mielestäni meidän on mentävä tätä määritelmää pidemmälle ja pohdittava, miten varmistamme, että kaikki käyttäjät voivat kaikissa tilanteissa käyttää tuotetta. Emme usein ajattele, että saavutettavuus voi olla tilannekohtaista ja ehdollista.
Yksi esimerkki on äänikomennot tai tuotteen käyttäminen äänellä. Ajattelemme usein, että ääniohjaus on helpompaa, jos näkö on heikko. Isäni on paljon vanhempi eikä ehkä näe näytön pientä tekstiä, joten hän käyttää mielellään ääntään puhelimen hallintaan.
Jos kuitenkin ajat autoa, et voi käyttää käsiäsi etkä silmiäsi samalla tavalla, joten voit silti käyttää äänikomentoja. Saavutettavuutta kannattaa siis ajatella tilanteen, ei vain yksilön tai yksittäisen ongelman, kattavana ominaisuutena. Tämä laajentaa määritelmää ja saa ymmärtämään, että jätät pöydälle valtavan käyttötapauksen ja suuren käyttäjäkunnan.
Se ei todennäköisesti ole liiketoiminnallesi hyväksi. Saavutettavuuden priorisoinnille alusta alkaen on siis käytännöllinen liiketoimintaperuste.
Hannah Clark: Tuo resonoi vahvasti. Se koskee sekä digitaalisia että fyysisiä tuotteita ja tiloja. Pidän todella paljon ajatuksesta, että saavutettavuus liittyy tilanteeseen eikä tiettyyn käyttötapaukseen. Koin tämän itse työnnellessäni lastenvaunuja ja huomatessani, kuinka monet tilat oli suunniteltu yhdelle jalankulkijalle, ikään kuin kulkemaan yksin jonossa.
Silloin ymmärtää, että on lukemattomia tilanteita, joissa joku voi tarvita saavutettavuusominaisuutta tai mukautusta tai joissa suunnittelussa pitäisi huomioida saavutettavuus. Tämä koskee monia eri ikiä ja elämänvaiheita. Pidän siis todella tästä ajattelutavasta ja haluaisin perehtyä siihen hetken kuluttua syvemmin.
Mainitsit haluavasi puhua lisää kokemuksestasi Slackilla. Haluaisin perehtyä joihinkin projekteihin, joiden parissa työskentelit tuolloin, erityisesti saavutettavuuden näkökulmasta toteutettuihin käyttöönoton työnkulkuihin.
Kerro hieman, miten lähestyit nykytilan analyysia arvioidaksesi tuotteen senhetkistä saavutettavuutta ja miten etenit sen jälkeen.
Prerna Ramachandra: Kun aloitin Slackilla, yksi ensimmäisistä projekteistani oli selvittää, kuinka saavutettava tuote oli ja mitä voisimme tehdä. Kuten sanoit: millaisia viitekehyksiä meillä oli tuotteen nykytilan analyysiin?
Kun tulin Slackille, meillä ei ollut mitään tällaista. Slack tavoitteli tuolloin suuria yritysasiakkaita sen jälkeen, kun se oli menestynyt pienille ja keskisuurille yrityksille suunnatuilla markkinoilla. Suuryrityksiä tavoitellessaan Slack huomasi, että niiden toimittajiin sovellettiin tiukkoja saavutettavuussäädöksiä.
Ensimmäiseksi kehitin sisäiset standardit, joita kutsuimme Slackin saavutettavuusstandardeiksi. Niissä hyödynnettiin olemassa olevia standardeja, kuten WCAG-ohjeistoa, mutta huomioitiin myös Slackin tuotteiden erityispiirteet ja se, mitä saavutettavuus niissä tarkoittaa. Loimme viitekehyksen, jonka avulla tuotteen läpi voitiin käydä ja analysoida, täyttikö se tietyt kriteerit.
Analyysin perusteella tuotteen eri ominaisuuksille annettiin arvosana, esimerkiksi A, B tai C, niiden saavutettavuuden mukaan. Kyseessä oli määrällisen ja laadullisen analyysin yhdistelmä. Meillä oli kriteeriluettelo. Osa perustui hyvin yksinkertaisiin tehtävähallinnan kysymyksiin: ovatko kaikki toiminnot käytettävissä näppäimistöllä ja ovatko ne kaikki näytönlukijan käytettävissä?
Toiset asiat olivat hieman vaikeammin mitattavia. Slack on viestintätuote, ja yksi sen vahvuuksista ovat ilmoitukset. Ilmoituksia tarvitaan, mutta tämä tapahtui pandemian aikana, jolloin monet työskentelivät kotoa ja etätyössä. Asiakkaat kertoivat ilmoitustulvasta, joka vaikutti erityisesti neuroepätyypillisiksi itsensä kokeviin ihmisiin. He tunsivat olonsa kuormittuneiksi eivätkä pystyneet hoitamaan tehtäviään kunnolla.
Tällaista asiaa ei yleensä löydy saavutettavuusohjeistoista, joten sisällytimme sen viitekehykseen. Viitekehystä käytettiin ominaisuusalueiden arvosanojen antamiseen. Arvosanat perustuivat yksinkertaisesti siihen, pystyikö käyttäjä suorittamaan tehtävän ja kuinka nopeasti.
Tämä auttoi määrittämään ongelmien kiireellisyyden sekä sen, mikä oli tärkeää ja mikä ei. Seuraavaksi teimme tuotteen nykytilan analyysin ja menimme johdon luo: tässä on koko tuote, tähän vaihteluväliin eri osa-alueet sijoittuvat ja nämä ongelmat on mielestämme korjattava välittömästi, koska tuote on niiden vuoksi perustavanlaatuisesti rikki tietylle asiakasryhmälle.
Viitekehyksen hyvä puoli oli myös se, ettei sitä sovellettu vain olemassa oleviin tuotteisiin. Uusia tuotteita kehittäessä sitä voitiin käyttää sen ymmärtämiseen, mitä pitäisi tarkistaa ennen julkaisua. Sitä voitiin käyttää myös tulevaisuuden tuotteissa.
Tämän jälkeen tein paljon työtä yksittäisten tiimien kanssa, jotta ne tiesivät, mitä tämän viitekehyksen perusteella pitäisi priorisoida. Kaikilla on tiekartta. Kukaan ei halua räjäyttää tiekarttaansa uuden asian vuoksi, koska kaikilla on jo sovittu joukko asioita.
Työskentelin tiimien kanssa, jotta ne tiesivät tarkalleen omat kriittiset kohtansa. Kun menimme yhdessä johdon luo sanomaan, mitä pitää priorisoida ja mitä korjata, meillä oli selkeä suunnitelma. Pystyimme myös kertomaan kompromisseista: paljonko kunkin asian korjaaminen vaatisi työtä, mitä tiekartalta siirtyisi ja mikä vaikutus sillä olisi.
Uskon, että saavutettavuudessa, kuten monissa muissakin tuoteasioissa, on ymmärrettävä yksittäisestä ominaisuusalueesta vastaavan tiimin kanssa työskentelyn ja johdon tuen saamisen välinen tasapaino.
Olin onnekas, sillä Slackin johto oli sitoutunut priorisoimaan työn ja tekemään sen oikein. He tarvitsivat meiltä selkeää tietoa: kuinka paljon työtä tarvitaan, mikä on aikataulu, mitä kompromisseja tehdään ja mikä on vaikutus.
Työssä oli siis paljon ihmisten johtamista ja paljon teknistä yhteistyötä insinöörien kanssa, jotta he saivat tarvitsemansa analyysin.
Hannah Clark: Tämä on erittäin tärkeää. Mikään ei ole kriittisempää ominaisuuksien julkaisemisen varmistamisessa kuin tuen saaminen ja asian tekeminen oikein.
Haluaisin tarkentaa hieman mainitsemaasi kompromissia. Miltä kompromissi käytännössä näyttäisi? Jos antaisit esimerkin siitä, miten tällainen tilanne esitettäisiin, miten muotoilisit asian asettaaksesi kaiken kontekstiin ja selittäisit projektin laajuuden sekä sen, miten se sijoittuu kriittisten asioiden listalle?
Prerna Ramachandra: Eniten työmme vaikutti tiimiin, joka työskenteli projektin keskeisen viestintäosan parissa. He omistivat suurimman pinta-alan: viestin kirjoittamisesta ja lähettämisestä viestin vastaanottamiseen koko viestintäportaalissa.
Heidän tiimissään oli myös kanavista vastaavia jäseniä. Slackia käyttävät tietävät, että tämä on Slack-kokemuksen ydin. Oli siis loogista, että heillä oli eniten käsiteltäviä asioita. He omistivat suurimman pinta-alan, joka oli myös kaikkein kriittisin, koska Slack on olemassa viestien lähettämistä ja vastaanottamista varten.
Sillä oli eniten korkean vaikutuksen saavutettavuusongelmia. Kun veimme heille ongelmalistan, käytän tässä hypoteettisia lukuja. Sanotaan, että listalla oli 100 ongelmaa. Sanoimme, että nämä kaikki on käsiteltävä, jotta tuote olisi vähintään käyttökelpoinen jokaiselle näytönlukijaa tai näppäimistönavigointia käyttävälle ja jokaiselle vammaiselle käyttäjälle.
Ensimmäiseksi istuin PM:n kanssa alas ja kävimme läpi viitekehyksen perusteella tunnistetut ongelmat. Tämä oli kriittinen vaihe. PM sanoi ymmärtävänsä, miksi pidimme kaikkia sataa asiaa kriittisinä, mutta hänen käyttäjä- ja käyttötapatietonsa perusteella vain 80 prosenttia oli todella kriittisiä. Joihinkin työnkulkuihin oli vaihtoehtoisia tapoja ja kiertoratkaisuja.
Näin lista pieneni sadasta kahdeksaankymmeneen. Jos organisaatiolla on keskitetty saavutettavuustiimi, on erittäin tärkeää keskustella tuotteen PM:n kanssa, koska hän tuntee käyttäjät parhaiten.
Seuraavaksi tarkastelimme, mitkä ongelmat liittyivät tuote- tai ominaisuusalueisiin, jotka oltiin pian suunnittelemassa uudelleen tai poistamassa. Jos alue suunniteltiin uudelleen, varmistimme saavutettavuuden uudessa versiossa eikä ongelmaa tarvinnut korjata heti. Jos alue poistettaisiin, sitä ei myöskään tarvinnut korjata. Näin jäljelle jäi esimerkiksi 70 ongelmaa.
Istuimme insinöörien kanssa alas. Tässä vähintään yksi organisaation oma saavutettavuusasiantuntija on erittäin tärkeä. Meillä oli onneksi todella hyvä insinööri, jolla oli tarvittava asiantuntemus. Hän auttoi tiimiä tekemään työmääräarvion jokaisesta 70 ongelmasta.
Kysyimme PM:ltä, kuinka monta niistä voitaisiin priorisoida nykyiseen tai tulevaan sprinttiin saman vuosineljänneksen aikana ilman tiekartan merkittävää vaikutusta. Tiimeillä on yleensä jonkin verran puskuria, etenkin jos ne ylläpitävät jo julkaistua tuotetta ja käsittelevät saapuvia virheitä. Ongelmat voitiin sisällyttää tähän työnkulkuun.
Tiimi arvioi, että noin 20 asiaa voitaisiin toteuttaa ilman vakavia vaikutuksia tiekarttaan. Niistä ei tarvinnut keskustella johdon kanssa. Jäljelle jäi ehkä 50 ongelmaa. Silloin kysyimme, mitä suuria tuotealueita voitaisiin siirtää tai viivästyttää, jos kaikki ongelmat priorisoitaisiin.
Tässä vaiheessa tarvitsimme johdon apua neuvotteluun ja navigointiin. Tiimillä oli julkaistavaksi suunniteltu ominaisuus, joka oli tärkeä suurelle asiakkaalle. Sama asiakas kuitenkin pyysi myös saavutettavuusongelmien korjaamista tietyssä aikataulussa.
Pystyimme menemään johdon luo ja sanomaan: tässä on kompromissi. Sen jälkeen työskentelimme asiakkuustiimin kanssa ja kysyimme asiakkaalta, mitä he haluaisivat nähdä ensin. Tärkeintä on tehdä omalla tasolla, yksittäisen osallistujan, Senior PM:n, Principal PM:n tai Group PM:n tasolla, kaikki mahdollinen työ ja priorisoida asiat luovasti ennen johdon mukaan ottamista.
Tässä tapauksessa sama asiakas kärsi molemmista ongelmaryhmistä. Pystyimme neuvottelemaan, kumpi haluttiin ensin ja mitkä voitiin toteuttaa myöhemmin. Päätimme esimerkiksi korjata kymmenen ongelmaa tämän vuosineljänneksen aikana niin, etteivät ne viivästyttäisi ominaisuutta liikaa, ja kymmenen seuraavan vuosineljänneksen aikana.
Ensimmäisen neljänneksen jälkeen pystyimme sisällyttämään saavutettavuuden suoraan neljännesvuosittaiseen suunnitteluun. Tiimien kanssa varattiin erillistä aikaa saavutettavuustyölle.
Saimme koko organisaation mukaan järjestämällä saavutettavuussprinttiviikkoja. Sijoitimme ne maailmanlaajuisen saavutettavuustietoisuuspäivän yhteyteen aina, kun se sopi neljännekseen. Kaikki eri tekniset ryhmät työskentelivät yhdessä saavutettavuusongelmien parissa. Se loi myös hyvän yhteisöllisen ympäristön.
Järjestimme lisäksi työpajoja, joissa tiimeille kerrottiin saavutettavuudesta. Alussa oli paljon kovaa työtä, erityisesti silloin, kun ominaisuuksien välillä oli suuria kompromisseja. Silloin johto on otettava mukaan auttamaan priorisoinnissa ja ajoituksessa.
Hannah Clark: On hienoa kuulla, miten koko organisaatio kokoontui yhteen priorisoimaan saavutettavuutta ja varaamaan sille aikaa. Lisäksi siitä muodostui positiivinen työkokemus.
Kun puhumme yhteistyöstä ja tiimien välisestä työstä, miten tämä toimii organisaatiossa, jolla on useita tuotteita ja useita tiimejä ratkaisemassa saavutettavuusongelmia eri tuotteissa ja ominaisuuksissa? Miten tuotetiimit tekevät yhteistyötä työskennelläkseen samassa tahdissa ja minimoidakseen tuotteiden julkaisemiseen tarvittavan työn ja viestinnän?
Prerna Ramachandra: Näen tähän kaksi eri lähestymistapaa eli kaksi pilaria.
Ensimmäinen on rakenteellinen. Jos organisaatiolla on keskitetty saavutettavuusorganisaatio, kuten useimmilla nykyään jossain muodossa on, on tärkeää miettiä, missä se sijaitsee organisaatiossa. Jos se on yhden liiketoiminta-alueen sisällä, siilojen ylittäminen ja yhteistyö muiden tiimien kanssa on vaikeaa.
Tiimi on siis sijoitettava oikeaan paikkaan. Jos näin ei ole, PM:n on itse tavoitettava muut tiimit, ymmärrettävä niiden tiekartat ja tutustuttava niihin, jotta yhteistyö toimii.
Toinen asia on jatkuva viestintä tiekartoista. Tämä koskee sekä keskitetyn saavutettavuusorganisaation johtajaa että yksittäisten ominaisuustiimien PM:iä. Molempien on oltava jatkuvasti yhteydessä toistensa tiekartoista.
Suurin haaste ja samalla suurin mahdollisuus Slackin saavutettavuustyössä oli varmistaa, että saavutettavuusasiantuntijat otetaan mukaan jo tiekartan suunnittelun alussa. Työ alkaa suunnitteluprosessista ja jatkuu suunnitteluun sekä toteutukseen.
Saavutettavuus ei ala insinööreistä, vaikka se vaatii teknistä asiantuntemusta. Joskus se alkaa suunnittelijasta. Esimerkiksi Figma tarjoaa hyviä välineitä saavutettavien suunnitelmien tekemiseen ja saavutettavuuteen keskittyvään työnkulkuun.
Suunnittelijamme osallistui tuotekehitys- ja suunnitteluprosessiin heti alusta alkaen. Hän kysyi, ovatko suunnitelmat saavutettavia, mikä toimii ja mikä ei.
Keskitetty viitekehys oli tässä erittäin hyödyllinen. Keskitetyn tiimin jäsenenä en olisi pystynyt seuraamaan jokaista muutosta, tiekartan muutosta ja tiimien tekemistä. Koska kaikilla oli sama viitekehys, PM pystyi antamaan sen suunnittelijalle ja insinöörille ja tarkistamaan itse, oliko saavutettavuusvirhe kriittinen, keskitasoinen vai matalan prioriteetin asia.
Näin hän pystyi päättämään, pitikö asia priorisoida heti vai myöhemmin. Keskitetyt standardit auttoivat myös siksi, että asiantuntemusta vailla olevalla henkilöllä oli jotain, johon tukeutua. Lisäksi yhden ihmisen ei tarvinnut yrittää jatkuvasti paimentaa kaikkia muita.
En halunnut olla kuin koulun rehtori, joka kertoo muille, mitä heidän pitää tehdä. Olemme kaikki aikuisia, ja uskon, että jokainen mukana oleva välittää tästä. Kukaan ei sanonut, ettei halua tehdä työtä. Ihmiset sanoivat välittävänsä saavutettavuudesta, mutta eivät tienneet miten, eivät tienneet saisivatko he priorisoida sitä tai olisiko siihen aikaa.
Jos olet ominaisuuden PM ja yrität tehdä tuotteestasi saavutettavan, kehitä viitekehys tai työskentele organisaatiossasi jonkun kanssa sen kehittämiseksi. Silloin sinun ei tarvitse jatkuvasti odottaa jonkun muun arviota asian tärkeydestä.
Kun luot uutta tuotetta, varmista, että tavoitat oikean asiantuntemuksen omaavat ihmiset ja sisällytät saavutettavuuden suunnitteluprosessiin alusta alkaen. Silloin tulevat virheet vältetään ja tuote on saavutettava heti julkaisusta lähtien.
Hannah Clark: Tämä on kiinnostavaa. Haluaisin puhua vielä toteutuksen ja iteroinnin tasosta. On eri asia analysoida nykyisiä ominaisuuksia, priorisoida niitä ja toteuttaa muutoksia kuin varmistaa, että uudet ominaisuudet ovat saavutettavia ensimmäisestä päivästä lähtien. Miten varmistatte tämän tulevaisuudessa?
Prerna Ramachandra: Annan konkreettisen esimerkin käyttäjän käyttöönotosta. Kun tiekarttaa luodaan, jokainen ominaisuus ja jokainen uusi asia on tarkasteltava saavutettavuuden näkökulmasta. PM:n on pidettävä tämä mielessä joka kerta.
On myös opittava tunnistamaan, ketkä asiakaskunnasta voivat auttaa arvioimaan saavutettavuutta. PM:t luottavat paljon käyttäjätutkimukseen, mutta usein unohtavat, että asiakkaat käyttävät tuotetta saavutettavuusominaisuuksien avulla. Heidät on otettava mukaan käyttäjätutkimukseen heti alusta alkaen.
Kun teimme Slackissa ensimmäistä analyysia, havaitsimme, että käyttöönoton kokemuksessa oli saavutettavuusaukkoja. Samalla tiesimme, että käyttöönotosta vastaava tiimi oli tekemässä suurta uudelleensuunnittelua tuotteen kehityksen vuoksi. Pystyimme työskentelemään tiimin kanssa heti alusta alkaen ja varmistamaan, että uudistettu käyttöönoton ydinpolku oli saavutettava.
Olimme mukana tiekartan suunnittelussa heti alusta asti. Suunnittelijamme osallistui koko suunnitteluprosessiin: käyttäjätutkimukseen, käyttäjätestaukseen ja Figma-suunnitelmiin. Hän laati saavutettavuusmääritykset rinnakkain muun suunnittelun kanssa.
Sama prosessi oli käytössä Slackin työpöytäsovelluksen uudelleensuunnittelussa. Lisäksi huomasimme mahdollisuuden rakentaa erityisesti saavutettavuuteen keskittyvän käyttöönoton käyttäjille, jotka tarvitsivat sitä.
Applen tuotteet ovat mielestäni erittäin vahvoja saavutettavuuden suhteen. Kun ostat uuden Macin, voit valita käyttöönoton työnkulun, jossa näytetään eri saavutettavuusominaisuudet ja niiden käyttö.
Rakensimme saavutettavuustiimissä vastaavan käyttöönoton. Kun käyttäjä saapui sovellukseen ja tavalliseen käyttöönottoon, kysyimme, oliko saavutettavuus hänelle tärkeää. Jos vastaus oli kyllä, käyttäjä ohjattiin vaiheittaiseen työnkulkuun, jossa näytettiin työkalujen sijainnit, näppäimistönavigointi ja eri komennot.
Käytimme myös tietoa jatkopolun rakentamiseen. Kun käyttäjä ilmoitti olevansa kiinnostunut saavutettavuudesta, näytimme hänelle tuotteen sisällä harkittuja työkaluvihjeitä, jotka jatkoivat saavutettavuuteen tutustumista.
Tämä oli mahdollista, koska havaitsimme olemassa olevassa työnkulussa suuren aukon: saavutettavuuteen keskittyvää käyttöönottoa ei ollut. Keskustelimme myös asiakkaiden kanssa, jotka lähettivät saavutettavuusvirheitä ja auttoivat meitä ymmärtämään tuotteen käytettävyyttä. Monet sanoivat, ettei mikään auttanut heitä oppimaan Slackin käyttöä, vaan heidän piti selvittää kaikki itse.
Kun mietit tulevaisuuden tuotteita, puhu käyttäjillesi. Mikään ei korvaa sitä. Tekoäly ei kerro, mitä pitäisi rakentaa; tuotetta käyttävät ihmiset kertovat sen.
Suurten yritysasiakkaiden omilla organisaatioilla on usein vammaisten työntekijöiden henkilöstöverkostoja, joihin voi ottaa yhteyttä. Lisäksi työskentelimme Fable-nimisen yrityksen kanssa. Se rekrytoi erityisesti vammaisia käyttäjiä saavutettavuuden käyttäjätestaukseen. Se on tavallaan usertesting.com, mutta saavutettavuuteen keskittyen.
Suunnitteluvaiheessa ota mukaan henkilö, jolla on saavutettavuusosaamista, tai huolehdi siitä, että suunnittelija suorittaa saavutettavaa suunnittelua käsittelevän kurssin. Suunnitelmissa on oltava saavutettavuusmääritykset, joihin insinöörit voivat tukeutua. Saavutettavuusasiantuntijoiden ja suunnittelijoiden on osallistuttava myös testaukseen. Näin varmistetaan, että kaikki rakennettava pysyy saavutettavana.
Hannah Clark: Pitkäaikaiset kuulijamme tietävät, että pidän ohjeista, jotka ovat hyvin konkreettisia. Kiitos siis näistä suosituksista. Haluaisin vielä käsitellä analytiikkaa. Miten saavutettavuusominaisuuksien ja niiden eteen tehdyn työn onnistumista mitataan?
Kun mittaamme aktivointiastetta tai muita käyttöönoton mittareita koko väestön osalta, saavutettavuusominaisuuksien tehokkuuden segmentointi voi olla erilaista. Miten mittaus rajataan niin, että mitataan saavutettavuusominaisuuksien onnistumista eikä vain tuotetta yleisesti? Käytättekö tähän työkaluja? Onko muita vinkkejä datan hyödyntämiseen tulevissa iteraatioissa?
Prerna Ramachandra: Annan vastauksen, joka saattaa tehdä monet PM:t epämukaviksi. Määrälliseen dataan ei voi luottaa sen ymmärtämisessä, toimivatko saavutettavuusominaisuudet ja onko tuote saavutettava.
Moraalisesti ja eettisesti käyttäjiä ei voi aina segmentoida saavutettavuuden perusteella, koska silloin tehdään oletuksia siitä, onko jollakulla vamma. Vaikka mitattaisiin näppäimistönavigointia käyttäviä tai näytönlukijan käyttöön ottaneita käyttäjiä, suuri osa väestöstä voi jäädä ulkopuolelle.
Neuroepätyypillisyyttä on vaikea mitata. Onko tuote heille liian kuormittava? Animaatiot voivat aiheuttaa joillekin ihmisille kohtauksia, joten niiden poistaminen käytöstä on tärkeä ominaisuus, mutta senkin vaikutusta on vaikea mitata.
Määrällinen mittaus antaa siis vain rajallisen kuvan. Käyttäjien segmentointi tavalliseen tapaan sisältää oletuksia, joita ei yleensä pitäisi tehdä. Se ei myöskään huomioi piileviä vammoja tai alussa mainitsemaani tilannekohtaista saavutettavuutta.
Parhaiten saavutettavuuden onnistumista mitataan palaamalla käyttäjien luo ja kysymällä heiltä. Laadullinen tutkimus on mielestäni paras tapa mitata saavutettavuutta.
Slackissa rakensimme saavutettavuusominaisuuden, joka oli ohjelmointirajapinta. Eri tiimit pystyivät sen avulla lisäämään näppäimistönavigoinnin tuotteisiinsa. Koska näppäimistönavigointi vaatii erityisosaamista, rajapinnan tarkoitus oli helpottaa työtä.
Mittasimme onnistumista tarkastelemalla, kuinka moni tiimi käytti rajapintaa. Koska käyttö ei ollut pakollista, tiimit olisivat voineet rakentaa toiminnon itse. Jos ne käyttivät rajapintaa, tiesimme saavutettavuustiimin onnistuneen rakentamaan jotain hyödyllistä.
Käyttäjien kohdalla onnistuimme ennen kaikkea kysymällä heiltä. Kun julkaisimme käyttöönoton työnkulun, saimme määrällistä tietoa siitä, kuinka moni käyttäjä valitsi saavutettavuuteen keskittyvän käyttöönoton. Olimme kuitenkin koonneet käyttäjäryhmiä, joiden kanssa keskustelimme saavutettavuudesta. Mukana oli käyttäjiä, jotka olivat pyytäneet saavutettavuusominaisuuksia tai käyttivät niitä.
On tärkeää tietää paitsi se, käyttääkö joku tuotetta, myös pystyykö hän käyttämään sitä asianmukaisesti haluamiensa tehtävien suorittamiseen. Jos tuote toimii hyvin enemmistölle, se antaa suuntaa, mutta saavutettavuudesta kiinnostuneiden käyttäjien kanssa on tehtävä erillinen laadullinen tutkimus.
Tiedän, ettei tämä ole PM:n näkökulmasta täydellinen vastaus, koska PM:t haluavat lukuja ja dataa. Osa työtä on kuitenkin hyväksyä epävarmuus. Mikään tuote ei koskaan rastita täydellisesti kaikkia saavutettavuuskohtia, koska monet asiat ovat tilannekohtaisia. Siksi käyttäjien kanssa on jatkettava keskustelua.
Saavutettavuudesta välittävät käyttäjät ovat usein hyvin äänekkäitä, koska he eivät ole tottuneet saamaan tarvitsemiaan asioita työnsä tekemiseen. Heidän on puhuttava selviytyäkseen ja voidakseen työskennellä kunnolla. Tämä on valtava resurssi.
Uramme aikana opimme erityisesti saavutettavuustyössä, kuinka tärkeää on puhua käyttäjille ja kuunnella heitä. He antavat parhaan tiedon siitä, miten tuote toimii. Laadullisen tutkimuksen ja ihmisten välisen yhteyden merkityksestä ei puhuta tarpeeksi. Saavutettavuuden kohdalla ihmisten kanssa on todella tärkeää keskustella.
Hannah Clark: Olen täysin samaa mieltä. Tämä on hyvin käyttäjätutkimusmyönteinen ohjelma. Teimme aiemmin Steve Portigalin kanssa jakson käyttäjien haastattelemisesta. Se on yksi kaikkien aikojen suosikeistamme, koska siinä puhutaan ihmisille, annetaan heidän kertoa aito kokemuksensa eikä ohjata keskustelua tai anneta omien ennakkoluulojen vaikuttaa. Se on tuotekehityksessä erittäin tärkeää.
Kiitos paljon. Tämä on ollut todella kiinnostava keskustelu. Arvostan näkökulmaasi ja yksityiskohtaisia tarinoitasi tunnetusta tuotteesta. Nyt kaikki voivat ymmärtää, miten nämä ominaisuudet syntyvät.
Mistä ihmiset voivat seurata työtäsi verkossa tai ottaa sinuun yhteyttä?
Prerna Ramachandra: Minut löytää LinkedInistä nimelläni Prerna Ramachandra. Minuun voi ottaa yhteyttä myös verkkosivuni kautta: PrernaRamachandra.me.
Hannah Clark: Hienoa. Kiitos paljon, että olit mukana.
Prerna Ramachandra: Kiitos, Hannah. Tämä oli hienoa.
Hannah Clark: Kiitos kuuntelusta. Lisää oivalluksia, käytännön oppaita ja työkaluarvioita saat tilaamalla uutiskirjeemme osoitteessa theproductmanager.com/subscribe. Voit kuunnella lisää tämän kaltaisia keskusteluja tilaamalla The CPO Clubin kaikissa podcastipalveluissa.
