Asiakaskokemus on niin tärkeä asia, että sitä ei kannata antaa ulkopuolisille.
Toimiva tai valmis tuote ei enää yksin riitä. Tarvitaan positiivinen asiakaskokemus, koska päätöksen
tuotteen tai palvelun erinomaisuudesta tekee käyttäjä tai asiakas. Jotta asiakkaan kokemus myötäilisi
mahdollisimman paljon yrityksen tavoitteita, tarvitaan palvelumuotoilua.
Työkalut toimivat juuri niin hyvin kuin käytetyt toimintamallit niitä tukevat. Jotta lisäosista saisi kaiken hyödyn irti, pitää perustekemisen olla kunnossa. Ikävä kyllä monesti näin ei ole. Tähän saattaa törmätä jopa pitkään JIRAa käyttävien organisaatioiden kanssa.
Palvelumuotoilulla varmistetaan arvon tuottaminen asiakkaalle ja asiakkaan asiakkaalle. Palvelumuotoilu katsoo tuotekehitystäkin asiakkaan näkökulmasta. Se tuo asiakkaan keskiöön parhaimmillaan jo tuotekehityksen alkumetreillä. Sillä varmistetaan, että tuotetta ja palvelua kehitetään käyttäjille ja ostavalle asiakasryhmälle.
Muutoksesta puhutaan paljon, koska niihin sopeutumisesta on tullut yritysten elinehto. Ei siksi, että se on trendikästä, vaan siksi, että muutosten vauhti markkinoilla kiihtyy ja asiakasymmärryksessä on vaikea pysyä perässä. Muutos on raskas, mutta muuntautuvuus on mille tahansa organisaatiolle mahdollinen. Jotta siihen päästään, pitää olla valmis muuntautumaan: se puolestaan edellyttää sekä johdon esimerkkiä että aitoa tahtoa ja sitoutumista.
Usein vastaan tuleva ongelma on se, että tiimillä on kertynyt ”verifiointivelka”, eli bugeja on fiksattu nopeammin kuin testaus pystyy niitä verifioimaan. Tässä onkin sellainen piilevä vaara, että jos tuo verifioitavana olevien bugien määrä kasvaa kovin isoksi, siitä tuleekin aikamoinen suo, kun sitä aletaan sitten myöhemmin kahlaamaan läpi. Tämä on todennäköisempää bugeille kuin tarinoille, koska agile-metodit pitävät huolen siitä, että aloitettavat tarinat ovat aika korkealla backlogilla. Lisäksi tarinat ovat usein hitaampia implementoida kuin bugifiksit.
Oletteko joskus työporukalla miettineet, olisiko parempi luottaa IBM Jazziin vaiko Atlassian Stackiin? Meillä Contribytellä on kokemusta molemmista, joten päätimme tarjota tietämyksemme myös blogimme lukijoiden hyödyksi.
Monissa organisaatioissa tuotepäällikön sekä Product Ownerin vastuualueet menevät iloisesti päällekkäin. Kun vastuut ovat samankaltaiset, riskinä on, että tehtävät muodostuvat niin epäselviksi, että jotain oleellista jää tekemättä.
Ketterien menetelmien yksi ultimatum on tehdä projektit tarpeettomiksi. Jatkuva työskentely on väliaikaisia projekteja tehokkaampaa, kun aikaa ei kulu turhaan joutokäyntiin ja odotteluun.
Atlassian JIRAlla on kolme puolta: se toimii työkaluna sekä ohjelmistokehitykseen, projektityöskentelyyn että asiakastukeen. Ohjelmistokehityksen tueksi alun perin suunniteltu Atlassian JIRA on noussut lyhyessä ajassa yhdeksi käytetyimmäksi työkaluksi ohjelmiston...
Eipä juuri enää tule vastaan tuotekehitystiimejä, joilla ei olisi käytössä jonkin sortin online-bugityökalu. JIRA on ehkä suosituin, mutta bugeja voidaan hallita myös muillakin työkaluilla. Oli tiimi sitten miten kokenut tai laatutyötä tekevä tahansa,...
Nykyään töissä tuntuu aina olevan kiire. Tuotekehitysprojektit eivät ole tästä mikään poikkeus. Ketterillä toimintatavoilla voidaan tiimiläisten kiireen tuntua vähentää, mutta toimintaa ohjaaville henkilöille, tuotteen omistajalle tai projektin vetäjälle kasautuu...
Suosituimmat ketterät toiminnanohjauskeinot ovat Scrum ja Kanban. Näistä Scrum on tuotekehityksessä yleisemmin käytössä. Scrummin pääetu Kanbaniin verrattuna on se, että fiksatun mittaisissa iteraatioissa on helpompi mitata tiimin nopeutta, velocityä, ja sitä kautta ulottaa ennustettavuutta pitemmälle tulevaisuuteen. Scrummin iteraatiot myös pakottavat tiimin tekemään suunnitelmia ja retrospektiivejä. Jo käynnissä olevaan Scrum – sprinttiin ei kuitenkaan yleensä ole hyvä lisätä mitään, joten tyypillisesti Scrum-tiimi voi reagoida kiireellisiin asioihin vasta seuraavassa sprintissä.