Miten Discovery ja 5 syytä varmistavat, että rakennat sitä, mitä asiakkaat todella tarvitsevat - etkä vain sitä, mitä he pyytävät.

Ohjelmistoinsinöörit tietävät, että tietokoneet tekevät juuri niin kuin käsketään – ei välttämättä sitä, mitä me aiomme. Tämä kuilu kasvaa, kun vaatimukset tulevat muilta kuin teknisiltä sidosryhmiltä tai kun pyyntö kohdistuu pikemminkin oireisiin kuin taustalla oleviin ongelmiin.

Miten siis vähennetään riskiä siitä, että otetaan käyttöön väärä asia? Kaksi yksinkertaista käytäntöä auttavat paljon:

• Discovery ymmärtää asiayhteys ja haluttu lopputulos
• 5 syytä perimmäisen syyn selvittämiseksi (jotta ongelma ei palaisi uudessa muodossa).

Notas IT:ssä käytämme molempia jo varhaisessa vaiheessa, yleensä heti ensimmäisessä tapaamisessa sen jälkeen, kun saamme vaatimuksen.

Löytäminen: aloita kontekstista, älä koodista

Aina kun asiakas lähettää pyynnön, kuten "rakenna X" tai "lisää Y", pidämme sitä lähtökohtana – emme lopullisena vaatimuksena.Discovery-keskustelussa pyrimme vastaamaan:

• Kuka kokee ongelman (roolit, tiimit, asiakkaat)?
• Milloin se tapahtuu (tiheys, ruuhka-ajat, erityiset skenaariot)?
• Mitkä ovat vaikutukset (raha, aika, virheet, vaihtuvuus, sääntöjen noudattamiseen liittyvä riski)?
• Missä se näkyy (järjestelmärajat, integraatiot, prosessin vaiheet)?
• Miltä menestys näyttäisi (mitattavissa oleva tulos, ei toimitettu ominaisuus)?

Vasta kun olemme ymmärtäneet ne, käytämme 5 miksi -menetelmää testataksemme, ratkaisemmeko todellisen ongelman.

5 syytä: muuta "pyyntö" "syyksi".

Viisi syytä on yksinkertaista: ota ongelman selitys ja kysy "miksi?", kunnes löydät syyn, jonka perusteella voit toimia.Kyse ei ole asiakkaan kuulustelusta, vaan yhteisen selkeyden rakentamisesta. Usein ei tarvita täsmälleen viittä syytä. Joskus tarvitaan kolme. Joskus tarvitaan seitsemän. Pointtina on, että älä pysähdy ensimmäiseen uskottavaan selitykseen.Ohjelmistoprojekteissa on vielä yksi yksityiskohta: vaikka oire näkyisi yhdessä paikassa, syy voi olla aivan eri kerroksessa.

"Viisi kerrosta", joissa ongelmat piileskelevät (ja miksi tämä sopii Discovery + 5 Whys -toimintamalliin).

Useimmissa tapauksissa käyttäjä huomaa virheen tai epäjohdonmukaisen käyttäytymisen käyttöliittymässä. Järjestelmät ovat kuitenkin monimutkaisempia. Tyypillisessä liiketoimintajärjestelmässä on useita kerroksia, ja jokainen kerros voi aiheuttaa oireita, jotka näkyvät muualla. Siksi kun tutkimme ongelmaa ja pyrimme löytämään ratkaisun, käymme yleensä läpi viisi kerrosta:

1. Käyttöliittymäkoodi
2. Backend-logiikka ja kehykset
3. Tietokannan rakenne ja tietokokonaisuudet
4. Käyttöliittymä-, backend- ja tietokantapalvelimet
5. Käyttöjärjestelmä (ja ympäristön käyttöaika)

Nämä kerrokset pakottavat sinut luonnollisesti kysymään "miksi?" monta kertaa. Käyttöliittymävirhe saattaa itse asiassa johtua backendin validoinnista, tietokantaindeksistä, palvelimen resurssirajoituksista tai käyttöjärjestelmätason ongelmasta. Viisi syytä tarjoavat rakenteen, jonka avulla voit välttää liian varhaista pysähtymistä – ja Discovery auttaa sinua valitsemaan oikean polun näiden kerrosten kautta liiketoiminnan vaikutusten, todellisten työnkulkujen ja rajoitusten perusteella. Käytännössä Discovery antaa siis suunnan ja 5 Whys antaa syvyyttä.

Esimerkki 1: "Tarvitsemme Vie Exceliin -painikkeen."

Asiakkaan pyyntö: "Lisää tilaussivulle Vie Exceliin -painike."

Löytökysymykset:

• Kuka tarvitsee vientitoimintoja, rahoitusta ja myyntiä?
• Mitä he tekevät Excel-tiedostolle sen jälkeen?
• Kuinka usein ne siirtävät tietoja, ja kuinka suuri tietomäärä on kyseessä?
• Mikä menee nykyään pieleen, jos ne eivät vie?

5 syytä: perimmäinen syy ja kerroskartoitus

1. Miksi tarvitset vientiä?
2. "Tarvitsemme viikoittaiset tilausnumerot johtoa varten." (Käyttöliittymän oire / raportointitarve)
3. Miksi sinun on lähetettävä ne manuaalisesti?
4. "Ei ole luotettavaa mittaristoa." (käyttöliittymä/tuotteen ominaisuudet)
5. Miksi ei ole luotettavaa kojelautaa?
6. "Tilaustilat ovat epäjohdonmukaisia ja raportointi katkeaa." (backend + tietokanta)
7. Miksi statukset ovat epäjohdonmukaisia?
8. "Eri tiimit käyttävät eri statuksia ja joskus ohittavat vaiheita." "Eri tiimit käyttävät eri statuksia ja joskus ohittavat vaiheita." (käyttöliittymä + backend)
9. Miksi he jättävät vaiheita väliin?
10. "Työnkulkua ei ole pakotettu, eikä käyttöliittymä ohjaa heitä." (käyttöliittymä + backend)

Mitä me sen sijaan toteutamme

Sen sijaan, että lisättäisiin pelkkä vientipainike, voitaisiin toteuttaa:

• Yksinkertainen viikoittainen KPI-näkymä (tilaukset, peruutukset, viivästykset).
• Tilamallin puhdistus ja validointi (vähentää "roskan sisäänajoa").
• Ohjattu työnkulku käyttöliittymässä tilojen yhdenmukaisuuden varmistamiseksi.
• Ja jos vienti on edelleen tarpeen: aikataulutettu raportointi manuaalisen viennin sijaan.

Tulos: vähemmän manuaalista työtä, luotettavampia lukuja, vähemmän "Excel-totuuksia".

Esimerkki 2: "Järjestelmä on hidas – tarvitsemme nopeamman palvelimen."

Asiakkaan pyyntö: "Järjestelmä on hidas. Voimmeko päivittää palvelimen?"

Löytökysymykset:

• Milloin se on hidas (koko päivän vai vain ruuhka-aikoina)?
• Mitä toimintoja varten (haku, tallennus, kirjautuminen, raportit)?
• Kuinka monta käyttäjää on aktiivisia silloin, kun se tapahtuu?
• Mikä on "hidas" numeroina (2s vs 20s)?

5 syytä: perimmäinen syy ja kerroskartoitus

1. Miksi se on hidas?
2. "Asiakkaiden haku kestää 10-15 sekuntia." (käyttöliittymäoire)
3. Miksi haku kestää niin kauan?
4. "Backend odottaa tietokantakyselyä." (backend)
5. Miksi kysely on hidas?
6. "Se skannaa valtavan pöydän." (tietokanta)
7. Miksi se skannaa koko taulukon?
8. "Suodattimia vastaavaa indeksiä ei ole." (tietokannan suunnittelu)
9. Miksei tätä havaittu aiemmin?
10. "Suorituskyvyn perustasoa ei ollut + tietojen kasvattaminen ei ollut osa tarkastelua." (prosessi - ja usein palvelinmittaukset)

Mitä me sen sijaan toteutamme

Palvelimien päivittämisen (väliaikainen korjaus) sijaan parempia ratkaisuja ovat:

• Oikeat indeksit ja kyselyjen optimointi (tietokanta)
• Todellista käyttöä vastaavat sivukuvaukset/rajoitukset (käyttöliittymä + backend).
• Suorituskyvyn perustaso ja hälytykset (palvelimien ja käyttöjärjestelmän seuranta).

Tulos: nopeampi käyttöliittymä ja yleensä alhaisemmat infrastruktuurikustannukset.

Esimerkki 3: "Tarvitsemme hyväksymisvaiheen ennen laskujen lähettämistä."

Asiakkaan pyyntö: "Lisää hyväksymisvaihe ennen laskujen lähettämistä." Löytökysymykset (asiayhteys)

• Mitä riskiä yrität vähentää?
• Onko kyse vääristä laskuista, vääristä vastaanottajista, vääristä summista vai ajoituksesta?
• Kuinka usein se tapahtuu ja mitä se maksaa?

5 syytä (perimmäinen syy) + kerroskartoitus

1. Miksi tarvitset hyväksynnän?
2. "Joskus laskuissa on virheellinen hinnoittelu." (käyttöliittymäoire)
3. Miksi hinnoittelu on virheellinen?
4. "Alennussääntöjä ei sovelleta johdonmukaisesti." (backend-logiikka)
5. Miksi sääntöjä ei sovelleta johdonmukaisesti?
6. "Myynti syöttää alennukset manuaalisesti vapaatekstikenttiin." (käyttöliittymäsuunnittelu)
7. Miksi se on manuaalinen/vapaateksti?
8. "Järjestelmä ei tue alennustyyppejä kunnolla." (tietomalli + backend)
9. Miksi se ei tue niitä?
10. "Se kasvoi orgaanisesti ilman hinnoittelumallia." (tietokanta + tuotesuunnittelu)

Mitä toteutamme sen sijaan Sen sijaan, että lisättäisiin hyväksymisvaihe jokaiselle laskulle (kitka), voisimme:

• Otetaan käyttöön jäsennelty hinnoittelu-/alennusmalli (tietokanta).
• Lisää validointisääntöjä ja selkeytä käyttöliittymän ohjaimia (käyttöliittymä + backend).
• Lisää poikkeusten työnkulku vain riskialttiisiin tapauksiin (käyttöliittymään ja backendiin).

Tulos: vähemmän virheitä ja pienemmät operatiiviset kustannukset.

Käytännöllinen tarkistuslista, jota voit käyttää seuraavassa asiakastapaamisessasi.

Kun asiakas tuo ratkaisun, kokeile seuraavaa järjestystä:

1. Esitä pyyntö uudelleen yhdellä lauseella.
2. Kysy: "Mitä tapahtuu, jos emme tee mitään?" (vaikutus)
3. Kysy: "(kiertotiet paljastavat todellisen tarpeen).
4. Kysy: "Miltä menestys näyttää?" (mitattavissa oleva tulos).
5. Suorita 5 syytä ja testaa tietoisesti, millä tasolla olet:
   • KÄYTTÖLIITTYMÄ
   • backend
   • tietokanta
   • palvelimet
   • Käyttöjärjestelmä/ympäristö

Löytäminen antaa sinulle suunnan. Viisi syytä antaa sinulle syvyyttä. Viisikerroksinen mentaalimalli auttaa sinua välttämään juuttumista väärään kerrokseen.

Loppuajatus

Discovery ja 5 Whys eivät hidasta toimitusta – ne vähentävät jälkitöitä. Toimitat edelleen ratkaisuja, mutta ne, jotka todella edistävät asiakasta.