Selv om du ikke jobber i IT, jobber du nesten helt sikkert med teknologi på en eller annen måte - lage regneark, oppdatere websider, sjekke kundeinformasjon fra databaser eller bare lese e-post. Og som du sikkert har lagt merke til, fungerer ikke alltid teknikk slik du ønsker det, eller enda verre, slik det skal. Det betyr at du noen ganger må samarbeide med teknologiteamet ditt for å løse problemer.
Imidlertid, som alle som har vært på et av disse samhandlingene, vet det ikke alltid. For å sikre at du får den hjelpen du trenger, og at de tekniske ekspertene alltid er glade for å hjelpe deg, her er praktiske tips for å kommunisere med teamet på en måte som vil fungere bra for begge parter.
1. En nødsituasjon
Eksempel: "Nettstedet er nede!"
Din digitale verden krasjer, eller kanskje bare bedriftens server krasjer. Uansett hvilken krise det er, må du ta kontakt med teknologteamet ditt umiddelbart - men uten å få panikk, lure og vende pulter. Nei, du trenger å gjøre dette på riktig måte fordi det er så kritisk. Det betyr at du må bringe fakta til teknologiteamet så raskt og tydelig som du kan.
Men et ord om advarsel før du sender den e-posten i alle caps eller ringer en utvikler på en søndag morgen: Forsikre deg om at situasjonen virkelig er "liv eller død." For de fleste selskaper innebærer "liv og død" poenget. . Er det med andre ord et problem som stopper eller hindrer deg, kollegaene eller selskapet ditt i å være i stand til å betjene kunder ordentlig? Ja? Fortsett. Nei? Pust dypt inn.
Er du usikker på hva som anses som en nødsituasjon? Spør sjefen din om det er en policy, og i så fall den etablerte prosedyren som skal følges i tilfelle det verste skulle skje. Hvis ingen av disse tingene eksisterer, kan du planlegge en rask prat med teknisk sjef eller lederutvikler om muligheten for å sette opp et system. Oddsen er at IT-teamet ikke bare vil sette pris på interessen din, men de vil også være glade for at det vil føre til færre falske alarmer i fremtiden. (Selv tech-entusiaster frykter en nødsituasjon på 11 PM.)
2. Interne feil
Eksempel: "Når jeg klikker på 'Neste' -knappen, blir jeg ikke tatt med til neste side."
Denne gangen er ikke problemet en trussel for virksomheten, men det er en irriterende feil som gjør det vanskelig å få oppgavene fullført. Du kan kanskje fortsette med dagen ved å jobbe rundt feilen, men du bør ikke bare ignorere den.
Igjen, bør du følge en hvilken som helst angitt protokoll for rapportering. (Og når du går tilbake til nummer én, kan du hjelpe deg med å sette opp et rapporteringssystem hvis det ikke eksisterer noe.) Når du arkiverer rapporten, husk å ta med så mye relevant informasjon som du kan.
En drømrapport vil omfatte følgende:
- Hva du prøvde å gjøre
- Hva skjedde da du gjorde det
- Enheten og operativsystemet du brukte
- Eventuell programvare involvert
- Et skjermbilde av problemet
Selv om denne informasjonen kan føles slitsom å skrive ut, vil det hjelpe teknologteamet med å diagnostisere problemet raskere. Vil du ha bonuspoeng (og problemene dine blir adressert raskere)? Pensle med dine teknologiske vilkår for å snakke om feilen. Det vil spare alle involverte mye gjetting.
3. En presserende oppdatering
Eksempel: "Klienten trenger hjemmesiden sin oppdatert EOD."
Gå tilbake til krisesentralen. Men denne gangen er det du som setter i gang hastverket. Det betyr at du må være spesielt følsom for IT-ansatte. Vær veldig tydelig på hva som må gjøres. Og hvis du trenger hjelp med flere elementer, la teamet vite hvilken prioritering det er for hvert, for i tilfelle at alt ikke kan gjøres samtidig.
I stedet for å kreve at teknologiteamet slipper alt for å tjene deg, kan du spørre hvor mye tid de tror trengs for å gjøre endringen. Hvis det ikke kan gjøres så raskt du vil, bør du forsterke hvorfor oppgaven er så presserende (husker du at bunnlinjen?), Og gjør det klart at du er her for å hjelpe deg med å fullføre den ASAP.
Det er også nøkkelen å huske at bare fordi du trenger noe, gjør det ikke alltid mulig. Gå alltid ut fra at før du kom med den presserende oppgaven, jobbet teknikkteamet på et annet prosjekt (eller to eller tre) med en frist.
Ja, du har sannsynligvis legitimt behov for at noe skal gjøres med en gang, men er det en midlertidig eller rask løsning (som bare å rette skrivefeilene og ødelagte koblinger) som ville fungere for nå? Gå i så fall med det. Deretter kan du sette opp en tidslinje for resten av prosjektet som fungerer for alle involverte.
4. Et (lite) forslag
Eksempel: "Vi bør lage en måte for leserne å kommentere på bloggen vår ved hjelp av Facebook-profilene deres."
Har du en smart idé som du tror vil forbedre bedriftens app eller nettsted? Du kan være på noe. Men det betyr ikke at du bør skynde deg over til teknologiteamet og forvente ros for ideen din. I stedet må du være smart og respektfull med hvordan du nærmer deg det.
La utviklerne eller designerne vite hvorfor du synes ideen din er verdt å implementere ("Markedsføringsteamet vårt delte bare statistikker om hvor aktive kundene våre er på Facebook, og jeg tror det kan hjelpe oss med å forbedre engasjementet på nettstedet"). Samtidig, husk samtidig tids- og pengebegrensningene som alle står overfor. Og husk å respektere IT-fagpersoners kunnskap og meninger. Vurder å bruke “kunne” i stedet for “bør” for å unngå å høres ut som om du allerede vet alle de riktige svarene.
Hvis du kommer til denne typen ideer er en vanlig del av jobben din, kan du prøve å lære om utvikling eller design. Til og med litt grunnleggende kunnskap vil hjelpe deg med å komme med mer nyttige og realistiske forslag.
5. En stor ide
Eksempel: "Hva med å redesigne hele hjemmesiden?"
Noen ganger vil du riste opp ting. Og din innsikt som utenforstående kan (noen ganger) være akkurat det som trengs for å oppdatere bedriftens strategi eller merke.
Men ikke bli feid av dine revolusjonerende trang. Igjen, må du fortelle design- eller utviklingsteamet ditt hvorfor du tror endringen er nødvendig. Og siden dette er en større overhaling du snakker om, bør du være forberedt på å rettferdiggjøre utgiftene og tiden som trengs for å få det til.
Du kan få ideen til å lyde mer tiltalende hvis du finner en måte å hjelpe deg på. Kanskje du kan være en beta-tester. Eller du kan skrive kopi. Eller kanskje du kan låne teknikerteamet din praktikant for å hjelpe deg med å forske på noen (enklere) aspekter av prosessen. Enhver måte du kan slå inn vil lette belastningen, noe som betyr at den store ideen din kan bli en realitet raskere.
Enten det du trenger er en tidssensitiv oppgave eller bare et kreativt forslag til forbedring. Å vite hvordan du kan henvende deg til teknologiteamet ditt når du trenger deres hjelp, vil gjøre begge jobbene dine enklere og hjelpe alle til å jobbe bedre - ideelt sett fører til færre forvirrende e-poster som stress alle ute.
