Selv hvis du ikke arbejder inden for it, arbejder du næsten helt sikkert med teknologi på en eller anden måde - at lave regneark, opdatere websider, kontrollere kundeoplysninger fra databaser eller bare læse e-mails. Og som du sandsynligvis har bemærket, fungerer teknik ikke altid, som du gerne vil have det, eller værre, som det skal. Det betyder undertiden, at du er nødt til at arbejde sammen med dit teknologiteam for at løse problemer.
Som enhver, der har været på en af disse interaktioner, ved, går det ikke altid glat. For at sikre dig, at du får den hjælp, du har brug for, og at de tekniske eksperter altid er glade for at hjælpe dig, her er praktiske tip til at kommunikere med teamet på en måde, der fungerer godt for begge parter.
1. En nødsituation
Eksempel: "Webstedet er nede!"
Din digitale verden går ned, eller måske bare din virksomheds server går ned. Uanset hvilken krise det er, er du nødt til at komme i kontakt med dit tech-team straks - men uden at få panik, freaking og vende skriveborde. Nej, du er nødt til at gøre det på den rigtige måde, fordi det er så kritisk. Det betyder, at du skal bringe fakta til tech-teamet så hurtigt og klart, som du kan.
Men et advarselsord, før du sender den e-mail i alle kasketter eller ringer til en udvikler en søndag formiddag: Sørg for, at situationen virkelig er "liv eller død." For de fleste virksomheder indebærer "liv og død" bundlinjen . Med andre ord, er det et problem, der stopper eller alvorligt forhindrer dig, dine kolleger eller din virksomhed i at være i stand til at betjene kunder ordentligt? Ja? Fortsæt. Ingen? Tag en dyb indånding.
Ikke sikker på, hvad der betragtes som en nødsituation? Spørg din chef, om der er en politik, og i bekræftende fald den fastlagte procedure, der skal følges, hvis det værste sker. Hvis ingen af disse ting findes, skal du planlægge en hurtig chat med din tekniske manager eller hovedudvikler om muligheden for at oprette et system. Oddserne er, at it-teamet ikke kun vil sætte pris på din interesse, men de vil også være glade for, at det vil føre til færre falske alarmer i fremtiden. (Selv techentusiaster frygter en nødsituation på 11 PM-serveren.)
2. Interne fejl
Eksempel: "Når jeg klikker på knappen 'Næste', føres jeg ikke til næste side."
Denne gang er problemet ikke en trussel mod erhvervslivet, men det er en irriterende fejl, der får udfordrende opgaver til at få afsluttet opgaver. Du kan muligvis komme videre med din dag ved at arbejde omkring fejlen, men du skal ikke bare ignorere den.
Igen, skal du følge enhver sæt protokol til rapportering. (Og når du går tilbage til nummer et, kan du hjælpe med at oprette et rapporteringssystem, hvis der ikke findes noget i øjeblikket.) Når du arkiverer din rapport, skal du huske at medtage så meget relevant information som du kan.
En drømrapport vil omfatte følgende:
- Hvad du prøvede at gøre
- Hvad skete der, da du gjorde det
- Enheden og operativsystemet, du brugte
- Enhver involveret software
- Et skærmbillede af problemet
Selvom disse oplysninger kan føles kedelige at skrive ud, hjælper de det tekniske team med at diagnosticere problemet hurtigere. Vil du have bonuspoint (og dine problemer adresseres hurtigere)? Børst op på dine tekniske vilkår for at tale om fejlen. Det sparer alle involverede mange gætterier.
3. En presserende opdatering
Eksempel: "Klienten har brug for sin opdaterede hjemmeside EOD."
Vend tilbage til krisecentralen. Men denne gang er det du, der starter skyndet. Det betyder, at du skal være særlig følsom over for dit it-personale. Vær meget klar over, hvad der skal gøres. Og hvis du har brug for hjælp til flere genstande, skal du fortælle teamet om, hvor vigtigt det er for hver enkelt, i tilfælde af at alt ikke kan gøres på samme tid.
I stedet for at kræve, at tech-teamet dropper alt for at tjene dig, skal du spørge, hvor lang tid de mener er nødvendigt for at foretage ændringen. Hvis det ikke kan udføres så hurtigt, som du vil, skal du styrke, hvorfor opgaven er så presserende (husker du den nederste linje?), Og gør det klart, at du er her for at hjælpe med at udføre den ASAP.
Det er også nøglen til at huske, at bare fordi du har brug for noget, gør det ikke altid det muligt. Antag altid, at før du ankom med din presserende opgave, arbejdede tech-teamet på et andet projekt (eller to eller tre) med en frist.
Ja, du har sandsynligvis legitimt brug for, at der skal gøres noget med det samme, men er der en midlertidig eller hurtig løsning (som bare at korrigere skrivefejl og ødelagte links), der ville fungere for nu? Hvis ja, gå med det. Opret derefter en tidslinje for resten af projektet, der fungerer for alle involverede.
4. Et (lille) forslag
Eksempel: "Vi bør skabe en måde for læsere at kommentere på vores blog ved hjælp af deres Facebook-profiler."
Har du en smart idé, som du tror ville forbedre din virksomheds app eller websted? Du er måske ved noget. Men det betyder ikke, at du skal skynde dig over til tech-teamet og forvente ros for din idé. I stedet skal du være smart og respektfuld med, hvordan du nærmer dig det.
Lad udviklerne eller designerne vide, hvorfor du synes, at din idé er værd at implementere (“Vores marketingteam delte lige nogle statistikker om, hvor aktive vores kunder er på Facebook, og jeg tror, det kan hjælpe os med at forbedre engagementet på webstedet”). Samtidig skal du huske den tids- og pengebegrænsning, som alle står overfor. Og husk at respektere dine it-fagfolk 'viden og meninger. Overvej at bruge “kunne” i stedet for “skal” for at undgå at lyde, som om du allerede ved alle de rigtige svar.
Hvis det at komme med disse slags ideer er en regelmæssig del af dit job, kan du prøve at lære om udvikling eller design. Selv nogle grundlæggende viden hjælper dig med at komme med mere nyttige og realistiske forslag.
5. En stor idé
Eksempel: "Hvad med at redesigne hele startsiden?"
Nogle gange vil du ryste tingene op. Og din indsigt som en outsider kan (undertiden) være lige det, der er nødvendigt for at opdatere din virksomheds strategi eller brand.
Men bliv ikke fejet af dine revolutionære trang. Igen, skal du fortælle dit design- eller udviklingsteam, hvorfor du mener, at ændringen er nødvendig. Og da dette er en større revision, du taler om, skal du være parat til at retfærdiggøre de udgifter og den tid, der er nødvendig for at få det til at ske.
Du kan få ideen til at lyde mere tiltalende, hvis du kan finde en måde at hjælpe på. Måske kan du være en beta-tester. Eller du kan skrive kopi. Eller måske kan du låne det tekniske team din praktikant til at hjælpe med at undersøge et par (enklere) aspekter af processen. Enhver måde du kan slå i vil lette belastningen, hvilket betyder, at din store idé kan blive en realitet hurtigere.
Uanset om det, du har brug for, er en tidsfølsom opgave eller bare et kreativt forslag til forbedring. At vide, hvordan man henvender sig til dit teknologiteam, når du har brug for deres hjælp, vil gøre både dine job lettere og hjælpe alle med at arbejde bedre sammen - hvilket ideelt fører til færre forvirrende e-mails, stress alle ud.
