Miksi rajoitteet tekevät teknologiasta inhimillisempää
Lomake, joka pelasti iltapäivän
Eräs opiskelija näytti minulle kerran vastaanottolomakkeen, jota koko organisaatio vihasi. Siinä oli tiukkoja kenttiä, pakollisia päivämääriä, rajattuja vaihtoehtoja ja kieltäytyminen, kun lähdeasiakirja puuttui. Ihmiset kutsuivat sitä byrokraattiseksi, luonnollisesti. Byrokraattinen on se sana, jota käytämme, kun järjestelmä kieltäytyy yhteistyöstä halumme improvisoida kanssa. Sitten tiimi vertasi sitä vanhaan vapaamuotoiseen vastaanottoon. Vihattu lomake oli ruma. Vanha vastaanotto oli suo.
Vanhassa prosessissa ihmiset kirjoittivat muistiinpanoja omalla tyylillään. Päivämäärät vaihtelivat muodosta toiseen. Suostumus oletettiin toiveikkuuden perusteella. Kriittiset kentät olivat piilossa kappaleiden sisällä. Seuraavan osaston piti lukea, tulkita, jäljittää ja arvailla. Kun jotain meni pieleen, organisaatio ei voinut sanoa, johtuiko epäonnistuminen puuttuvasta tiedosta, väärästä tulkinnasta vai siitä, että kaikki olivat hiljaa sopineet kohtelevansa toivoa tietokantakenttänä.
Rajoitettu lomake ei tehnyt työstä runollisempaa. Se teki siitä ystävällisempää. Se kertoi käyttäjälle, mitä tarvittiin. Se kieltäytyi jatkamasta, kun prosessista olisi tullut turvatonta. Se teki vastuista näkyviä. Se vähensi seuraavan henkilön tarvitseman tulkinnan määrää. Se ei korvannut harkintaa. Se lakkasi teeskentelemästä, että harkinnan pitäisi siivota kaikki ylävirran sotkut.
Tämä on rajoitteiden unohdettu inhimillinen arvo. Ne eivät ole vain rajoja. Ne ovat julistuksia. Rajoitettu järjestelmä kertoo, mitä se voi hyväksyä, mitä se ei voi hyväksyä, mihin vastuu siirtyy ja missä ihmisen on oltava mukana. Epämääräinen automaatio tuntuu usein ystävälliseltä, koska se hyväksyy mitä tahansa. Sitten kustannus ilmestyy myöhemmin, yleensä jonkun vähemmän valtaa omaavan käsiin.
Rajoittamattomat järjestelmät työntävät työtä alavirtaan
Monet digitaaliset järjestelmät saavat kiitosta joustavuudestaan. Joustava tarkoittaa usein sitä, että järjestelmä päästää huonon syötteen matkaan, kunnes ihminen joutuu korjaamaan sen. Chatbotti hyväksyy mahdottoman pyynnön ja tuottaa itsevarmaa sumua. Työnkulku hyväksyy asiakirjan ilman suostumusta ja antaa vaatimustenmukaisuuden löytää aukon myöhemmin. Dataputki hyväksyy tuntemattomia kenttiä ja jättää analyysin ihmettelemään, miksi kaavio näyttää siltä kuin se olisi koottu sähkökatkon aikana.
Tämä alavirran työ ei ole neutraalia. Se lankeaa tukipalvelun, käsittelijöiden, datavastaavien, sairaanhoitajien, opettajien, virkamiesten, asiakkaiden ja kaikkien muiden harteille, jotka seisovat lähellä kohtaa, jossa automaatio kohtaa todellisuuden. Käyttäjä voi kokea ensimmäisen näytön sujuvana. Laitos kokee loput uudelleentyönä. Sujuvuus sisäänkäynnillä voi olla julmuutta uloskäynnillä.
Rajoitteet kääntävät tuon kaavan toisin päin. Ne tekevät järjestelmästä vastuullisen jo siinä pisteessä, jossa tieto syötetään. Ne sanovat, että lähde on nimettävä, suostumuksen on oltava nimenomainen, päivämäärän on oltava voimassa, toiminnon on oltava sallittu, luottamuksen on oltava riittävä, käytännön on oltava ajantasainen ja kieltäytyminen on kirjattava. Tämä on vähemmän hohdokasta kuin keskusteleva käyttöliittymä. Niin on myös turvavyö. Olemme näemmä hyväksyneet ne.
Tekniset ihmiset pelkäävät joskus, että rajoitteet tekevät järjestelmistä hauraita. Huonot rajoitteet tekevät niin. Hyvät rajoitteet nimeävät ne ehdot, joiden vallitessa järjestelmä saa toimia. On ero sen välillä, että kieltäydytään, koska maailma on hankala, ja sen välillä, että kieltäydytään, koska järjestelmältä puuttuu toimivalta. Ensimmäinen on laiskaa. Jälkimmäinen on rehellistä.
Kieltäytyminen on ominaisuus, ei epäonnistuminen
Inhimillisen teknologian on osattava sanoa ei. Tuo lause kuulostaa ankaralta vain siksi, että ohjelmistot ovat vuosia teeskennelleet, että jokaiseen pyyntöön kuuluu vastata. Vakavassa järjestelmässä ei voi tarkoittaa, että tieto puuttuu, käyttäjällä ei ole oikeuksia, malli ei ole riittävän varma, tarkoitus on toimivallan ulkopuolella, käytäntö on vanhentunut tai toiminto loukkaisi oikeutta. Ei perusteluineen on paljon kunnioittavampi kuin kyllä, joka aiheuttaa ongelman kolme askelta myöhemmin.
Kieltäytyminen suojaa myös järjestelmää siltä, että siitä tulisi tekaistun osaamisen teatteri. Generatiiviset käyttöliittymät ovat erityisen alttiita tälle. Ne pystyvät tuottamaan lauseen melkein mistä tahansa. Lause ei ole toimivaltaa. Sujuva vastaus toimivallan ulkopuoliseen kysymykseen ei ole palvelua; se on koristeellista riskiä. Inhimillinen rajoite on se, joka sanoo, että tämä kysymys vaatii ammattilaisen, tätä tietoa ei saa käyttää tuohon tarkoitukseen tai tätä vastausta ei voida tuottaa käytettävissä olevan näytön perusteella.
Ihmiset harvoin vastustavat kieltäytymistä, kun se on selkeää, johdonmukaista ja siihen liittyy jatkopolku. He vastustavat arvoituksellista kieltäytymistä. He vastustavat kieltäytymistä, joka piiloutuu järjestelmä sanoo ei -ilmaisun taakse. He vastustavat kieltäytymistä, johon ei voi hakea muutosta. He vastustavat epätasaisesti sovellettua kieltäytymistä, koska säännöt elävät sen pään sisällä, joka määritti työnkulun pitkän palaverin jälkeen. Niinpä rajoitteeseen on liityttävä selitys, kirjaus ja omistajuus.
Rajoitteet tekevät vastuusta näkyvää
Vastuu teknologiassa katoaa usein abstraktioihin. Malli päätti. Alusta suositteli. Työnkulku reititti. Koostemittari näytti. Nämä lauseet ovat mukavia, koska ne poistavat ihmiset verbistä. Rajoitteet tuovat ihmiset takaisin. Joku valitsi kynnysarvon. Joku hyväksyi käytännön. Joku määritteli sallitun tarkoituksen. Joku päätti, mikä näyttö riittää. Joku omistaa poikkeukset.
Tämä näkyvyys on käyttäjille tärkeää, koska haitat syntyvät yleensä rajoilla. Henkilöltä evätään etuus, potilasta ei ohjata jatkohoitoon, työntekijä merkitään lipulla, asiakas lukitaan ulos, kansalaiselta pyydetään lisää asiakirjoja. Järjestelmä voi sisältää monia älykkäitä osia, mutta käyttäjä kokee rajan. Jos kukaan ei omista sitä rajaa, käyttäjällä ei ole tahoa, jolle esittää kysymys. Se ei ole tehokasta. Se on sokkelo, jossa on kirjautumisnäyttö.
Rajoitettu järjestelmä voi näyttää säännön omistajan, käytännön version, käytetyn näytön, puuttuvan näytön ja korjausreitin. Se ei tee jokaisesta päätöksestä miellyttävää. Se tekee siitä hallittavan. Vaihtoehto on järjestelmä, joka tuntuu mukautuvalta, kunnes jokin menee pieleen, minkä jälkeen kaikki huomaavat, että mukautuvuus on huono korvike vastuullisuudelle.
Organisaatiot pelkäävät joskus, että vastuun tekeminen näkyväksi luo vastuun. Totuus on yleensä päinvastainen. Piilotettu vastuu ei poista vastuuta. Se viivästyttää sitä, lisää hämmennystä ja saa lopullisen selityksen näyttämään improvisoidulta. Julkilausuttu rajoite on ainakin tarkastettavissa. Piilotettu oletus on vahinkoilmoitus, joka odottaa hiljaista perjantaita.
Rajoitusten käyttökokemus
Tässä on suunnitteluopetus. Rajoitteiden on oltava näkyvissä ennen kuin ne satuttavat. Jos käyttäjä huomaa rajan vasta pitkän prosessin jälkeen, rajoite tuntuu rankaisevalta. Jos järjestelmä selittää vaatimuksen varhain, käyttäjä voi toimia. Inhimillinen käyttöliittymä ei pelkästään estä virheellistä toimintaa. Se auttaa käyttäjää ymmärtämään, mitä kelvollinen toiminta edellyttäisi.
Siksi rajoitetut järjestelmät tarvitsevat hyvää kieltä. Viesti, joka sanoo virheellinen syöte, ei ole ohjausta. Viesti, joka sanoo, että asiakirjan päivämäärän on oltava viimeisen kolmen kuukauden sisällä, koska päätös riippuu nykyisistä tuloista, on parempi. Viesti, joka sanoo, että tätä pyyntöä ei voida käsitellä automaattisesti, koska suostumus puuttuu, ja joka näyttää, miten suostumuksen voi lisätä tai miten voi pyytää manuaalista käsittelyä, on vielä parempi. Rajoitteesta tulee osa palvelua.
Suunnittelutiimit yrittävät joskus piilottaa rajoitteita, koska pelkäävät kitkaa. Mutta kitka ei ole aina vihollinen. On haitallista kitkaa, kuten saman tiedon kysymistä kolmesti, koska järjestelmät eivät keskustele keskenään. On suojaavaa kitkaa, kuten vahvistuksen pyytämistä ennen tietueiden poistamista tai arkaluonteisen päätöksen lähettämistä. Inhimillinen teknologia erottaa nämä kaksi toisistaan. Se poistaa hukkaa ja säilyttää varovaisuuden.
Rajoitteen on sovittava työhön
Rajoite ei ole inhimillinen pelkästään siksi, että se on tiukka. Huono rajoite voi olla yhtä laiska kuin ei rajoitetta lainkaan. Se voi vaatia asiakirjan, jota jotkut käyttäjät eivät kohtuudella voi hankkia. Se voi koodata vanhentuneen käytännön. Se voi tehdä helposta tapauksesta kauniin ja vaikeasta tapauksesta nöyryyttävän. Se voi pakottaa sairaanhoitajan, opettajan tai asiakaspalvelijan valehtelemaan järjestelmälle, koska todellinen maailma ei saapunut hyväksytyssä muodossa. Siinä vaiheessa rajoite ei ole parantanut työnkulkua. Se on luonut pienen rehellisyysveron.
Hyvät rajoitteet suunnitellaan työstä käsin. Ne kysyvät, mitkä tosiasiat ovat välttämättömiä ennen toimintaa, mikä epävarmuus voi kulkea turvallisesti, minkä epävarmuuden on pysähdyttävä ja millä ihmisen roolilla on valtuudet päättää poikkeuksesta. Ne ovat tiukkoja silloin, kun seuraus on vakava, ja kevyempiä silloin, kun virheen hinta on pieni. Ne jättävät tilaa selityksille, kun ihmiset kohtaavat epätavallisia olosuhteita. Ne eivät sekoita siistiä syötettä totuudenmukaiseen syötteeseen.
Siksi kenttätutkimus on tärkeää. Työnkulun lähellä olevat ihmiset tietävät yleensä, mitkä säännöt suojaavat ja mitkä vain rankaisevat. He tietävät, mitkä kentät ovat aidosti tarpeellisia ja mitkä lisättiin kokouksen jälkeen, koska joku halusi tuntea olevansa perusteellinen. He tietävät, missä käyttäjät juuttuvat, missä henkilökunta keksii sivukanavia ja missä järjestelmä muuttaa normaalin poikkeuksen menettelylliseksi esteradaksi. Ilman näitä ihmisiä suunniteltu rajoite näyttää yleensä siistiltä ylhäältä katsottuna ja käyttäytyy huonosti tiskillä.
Tekninen versio on sama. Tyypijärjestelmän, skeeman, käytäntömoottorin tai validointikerroksen tulisi ilmaista todellinen sopimus. Siitä ei tulisi tulla teoreettisen täydellisyyden pyhäkköä. Paras rajoite on usein pieni, nimetty ja testattu. Se sanoo tarkalleen, minkä on oltava totta ennen kuin järjestelmä toimii, ja jättää lopun kontekstista tarkasteltavaksi. Näin rajasta tulee huolenpitoa paperisodan sijaan.
Rajoitteet ennen automaatiota
Huonoin hetki keksiä rajoitteita on sen jälkeen, kun automaatio jo toimii. Siihen mennessä järjestelmä on muodostanut tapoja. Dataa on virrannut paikkoihin, joihin sen ei olisi pitänyt. Ihmiset ovat rakentaneet kiertoteitä. Raportit riippuvat kentistä, joita kukaan ei omista. Malli on oppinut historioista, joita ei koskaan ollut tarkoitettu harjoitus- tai hakumateriaaliksi. Sitten hallinto saapuu leikepöydän kanssa, ja kaikki esittävät yllättynyttä, ikään kuin syy ja seuraus olisivat niche-tutkimusaihe.
Rajoitteet tulisi suunnitella ennen automaatiota, koska ne määrittelevät turvallisen toiminta-alueen. Mitkä tarkoitukset ovat sallittuja. Mitä dataa saa käyttää. Mitkä lähteet vaativat suostumuksen. Mitkä tulokset vaativat ihmisen tarkistuksen. Mitkä päätökset on kirjattava. Mitkä käyttäjät saavat ohittaa. Mitkä tietueet on vanhennettava. Nämä eivät ole koristeita mallin ympärillä. Ne ovat järjestelmän muoto.
Kun rajoitteet tulevat ensin, automaatio voi olla hyödyllisempää, koska sillä on pienempi ja selkeämpi tehtävä. Sen ei tarvitse päätellä institutionaalisia rajoja tunnelmasta. Se voi toimia määritellyn alueen sisällä, kieltäytyä sen ulkopuolella ja jättää jälkeensä todisteita. Se on helpotus, rehellisesti sanottuna. Koneet ovat erinomaisia nopeudessa. Niitä ei paranneta pyytämällä niitä arvaamaan hallintoa, koska aikuiset eivät halunneet vaikeaa kokousta.
On myös oppimishyöty. Rajoitteet tuottavat parempaa palautetta. Jos monet tapaukset epäonnistuvat, koska todisteet puuttuvat, paranna tiedonkeruuta. Jos monet kieltäytymiset kumotaan valituksessa, tarkista sääntö. Jos monet käyttäjät pysähtyvät samaan vaatimukseen, suunnittele selitys uudelleen. Rajoittamaton järjestelmä voi näyttää tehokkaalta, koska se ei koskaan pysähdy. Se vain lykkää epäonnistumisen mittaamista.
Instituutiot tarvitsevat myös rajoja
Rajoitteet eivät suojaa käyttäjiä vain teknologialta. Ne suojaavat käyttäjiä instituutioilta, jotka käyttävät teknologiaa tekosyynä. Ilman rajoitteita automaatiosta voi tulla tapa tehdä päätöksiä nimeämättä päättäjää. Rajoitteiden kanssa instituution on kirjattava rajansa. Sen on sanottava, mitä järjestelmä ei saa tehdä. Se on tervettä epämukavuutta.
Koulun, joka käyttää analytiikkaa, tulee ilmoittaa, mitkä signaalit voivat vaikuttaa tukeen ja mitkä eivät. Kunnan, joka käyttää automaatiota, tulee ilmoittaa, milloin asia siirtyy ihmiselle. Pankin, joka käyttää riskimalleja, tulee ilmoittaa, millä näytöllä on merkitystä ja miten asiakas voi riitauttaa tuloksen. Sairaalan, joka käyttää päätöksenteon tukea, tulee ilmoittaa, milloin neuvo on neuvoa-antavaa ja milloin kliininen vastuu säilyy ammattilaisella. Nämä ilmoitukset eivät ole innovaation vastaisia. Ne ovat sen perusta.
Sanasta inhimillinen tulee helposti tunteellinen, jos sitä ei sidota koneisiin. Teknologiassa inhimillinen tarkoittaa usein sitä, että tylsät asiat on tehty: käyttötarkoituksen rajat, tietolähteiden säännöt, säilytysajat, roolien käyttöoikeudet, auditointilokit, kieltäytymispolut, valitusreitit, versioitu politiikka ja testatut luovutukset. Ei kovin elokuvallista. Hyvä niin. Ihmiset tarvitsevat hallintojärjestelmiä harvoin elokuvamaisuuden vuoksi. He tarvitsevat, etteivät ne kadota juonta.
Ohituksen politiikka
Jokainen rajoitettu järjestelmä kohtaa lopulta tapauksen, joka ei sovi muottiin. Kysymys ei ole siitä, onko ohitusta olemassa. Sitä on aina, vaikka se olisi piilotettu pääkäyttäjätileihin, tietokantamuokkauksiin, epävirallisiin puheluihin tai henkilöön, joka tietää, mikä painike ohittaa säännön. Inhimillinen kysymys on, onko ohitus nimetty, rajattu, kirjattu ja tarkastettavissa. Salainen joustavuus ei ole myötätuntoa. Se on etuoikeus näppäimistön kanssa.
Ohituspolun tulisi kertoa, kuka sitä saa käyttää, mistä syistä, minkä näytön perusteella, kenen toisena silmäparina ja kuinka kauan poikkeus pysyy voimassa. Sen tulisi luoda kirjaus, joka voidaan auditoida ilman, että henkilökunnasta tehdään epäiltyjä vaikean työn tekemisestä. Sen tulisi myös ruokkia parannusta. Jos sama ohitus toistuu, rajoite voi olla väärä, politiikka voi olla puutteellinen tai maailma on voinut muuttua sillä välin, kun järjestelmä oli kiireinen näyttämään siistiltä.
Tässä ihmisen valvonnasta tulee todellista. Valvonta ei ole komitean nimi. Se on suunniteltu suhde säännön, poikkeuksen, näytön ja vastuun välillä. Ihminen, joka leimaa koneen tuotoksen hyväksytyksi, ei harjoita valvontaa. Ihminen, joka näkee säännön, ymmärtää puuttuvan ehdon, kirjaa syyn ja käynnistää politiikan tarkistuksen, on paljon lähempänä. Vähemmän dramaattista, hyödyllisempää. Suurin osa hyvästä hallinnosta muistuttaa lavaläsnäololtaan hyvin hoidettua tarkistuslistaa.
Tarkoitus ei ole tehdä teknologiasta arkaa. Tarkoitus on tehdä siitä kunnollista paineen alla. Järjestelmä, joka osaa sanoa kyllä, sanoa ei, pyytää näyttöä, eskaloida, selittää, kirjata ja oppia, ei ole vähemmän kehittynyt kuin järjestelmä, joka vastaa kaikkeen. Se on aikuismaisempi. Sillä on rajat, ja rajat ovat tapa, jolla järjestelmät jakavat maailman ihmisten kanssa, joilla ei ole varaa ryhtyä ohjelmistooptimismin siivousväeksi.
Sama logiikka pätee tiimien sisällä. Rajoitteet antavat kollegoille yhteisen kohteen, jota vastaan väitellä. Sen sijaan, että väiteltäisiin siitä, oliko joku tarpeeksi huolellinen, tiimi voi tarkastella sääntöä, todisteita, poikkeusta ja omistajaa. Tämä siirtää erimielisyyden persoonasta järjestelmäsuunnitteluun, mikä on inhimillisempää ja paljon helpommin parannettavissa. Sen taakse on myös vaikeampi piiloutua. Epämääräinen prosessi antaa jokaisen olla oikeassa yksityisesti. Julkilausuttu rajoite pyytää organisaatiota olemaan väärässä julkisesti ja sitten korjaamaan asian.
Opetus
Teknologiasta tulee vähemmän inhimillistä, kun se hyväksyy jokaisen pyynnön, piilottaa kaiken epävarmuuden ja jättää ihmiset huomaamaan rajat vasta, kun haitta on jo ehtinyt tapahtua. Siitä tulee inhimillisempää, kun se ilmoittaa rajansa varhain. Voin tehdä tämän. En voi tehdä tuota. Tarvitsen tämän todisteen. Minun on kieltäydyttävä tässä. Tämä henkilö on vastuussa. Näin valitat.
Rajoitteet eivät ole innovaation vastakohta. Ne ovat keino, jolla vakava innovaatio pääsee instituutioihin muuttamatta käyttäjiä testiaineistoksi. Ne suojaavat ihmisiä epämääräiseltä automatisoinnilta tekemällä rajoista näkyviä, kieltäytymisistä täsmällisiä ja vastuusta läpinäkyvää. Järjestelmään, joka tietää, missä se loppuu, on helpompi luottaa kuin järjestelmään, joka kohteliaasti sanoo kyllä, kunnes todellisuus lähettää laskun.