Även om du inte arbetar inom IT arbetar du nästan säkert med teknik på ett eller annat sätt - att skapa kalkylblad, uppdatera webbsidor, kontrollera kundinformation från databaser eller bara läsa e-post. Och som du säkert har lagt märke till fungerar teknik inte alltid som du vill ha det, eller ännu värre, som det borde. Det betyder att du ibland måste arbeta med ditt tekniska team för att lösa problem.
Men som alla som varit med på någon av dessa interaktioner vet, går det inte alltid smidigt. För att säkerställa att du får den hjälp du behöver och att de tekniska experterna alltid är glada att hjälpa dig, här är praktiska tips för att kommunicera med teamet på ett sätt som fungerar bra för båda parter.
1. En nödsituation
Exempel: "Webbplatsen är nere!"
Din digitala värld kraschar ner, eller kanske bara ditt företags server kraschar. Oavsett vilken kris det är, måste du kontakta ditt tekniska team omedelbart - men utan att få panik, freaking och vända skrivbord. Nej, du måste göra detta på rätt sätt eftersom det är så kritiskt. Det betyder att du måste ta med fakta till teknikgruppen så snabbt och tydligt du kan.
Men ett varningsord innan du skickar bort det e-postmeddelandet i alla mössor eller ringer en utvecklare på en söndagsmorgon: Se till att situationen verkligen är "liv eller död." För de flesta företag innebär "liv och död" i slutändan . Med andra ord, är det ett problem som stoppar eller allvarligt hindrar dig, dina kollegor eller ditt företag från att kunna betjäna kunder ordentligt? Ja? Fortsätt. Nej? Ta ett djupt andetag.
Är du inte säker på vad som betraktas som en kris? Fråga din chef om det finns en policy, och i så fall, det fastställda förfarandet att följa om det värsta skulle hända. Om ingen av dessa saker finns, schemalägg en snabb chatt med din tekniska chef eller lead-utvecklare om möjligheten att installera ett system. Oddsen är att IT-teamet inte bara kommer att uppskatta ditt intresse, utan de kommer också att vara glada över att det kommer att leda till färre falska larm i framtiden. (Till och med teknikentusiaster fruktar en nödsituation på 11 PM.)
2. Interna buggar
Exempel: "När jag klickar på knappen" Nästa "kommer jag inte till nästa sida."
Den här gången är problemet inte ett hot mot företaget, men det är en irriterande problem som gör att uppgifterna avslutas utmanande. Du kanske kan fortsätta med din dag genom att arbeta runt felet, men du borde inte bara ignorera det.
Återigen bör du följa alla inställda protokoll för rapportering. (Och när du går tillbaka till nummer ett kan du hjälpa till att skapa ett rapporteringssystem om inget existerar.) När du arkiverar din rapport, kom ihåg att ta med så mycket relevant information som du kan.
En drömrapport skulle innehålla följande:
- Vad du försökte göra
- Vad hände när du gjorde det
- Enheten och operativsystemet du använde
- All programvara inblandad
- En skärmdump av problemet
Även om denna information kan kännas tråkig att skriva ut, hjälper den teknikgruppen att diagnostisera problemet snabbare. Vill du ha bonuspoäng (och dina problem tas upp snabbare)? Borsta upp dina tekniska villkor för att prata om felet. Det sparar alla involverade mycket gissningar.
3. En brådskande uppdatering
Exempel: "Klienten behöver sin hemsida uppdaterad EOD."
Återgå till kriscentralen. Men den här gången är du den som inleder rusningen. Det betyder att du måste vara särskilt känslig för din IT-personal. Var mycket tydlig på vad som måste göras. Och om du behöver hjälp med flera artiklar, låt teamet veta prioriteten för var och en för att allt inte kan göras samtidigt.
I stället för att kräva att teknikgruppen tappar allt för att tjäna dig, fråga hur mycket tid de tror behövs för att göra förändringen. Om det inte går att göra så snabbt du vill, bör du förstärka varför uppgiften är så brådskande (kom ihåg den nedersta raden?) Och göra det klart att du är här för att hjälpa till att slutföra den ASAP.
Det är också nyckeln att komma ihåg att bara för att du behöver något gör det inte alltid möjligt. Antag alltid att teknikgruppen arbetade på ett annat projekt (eller två eller tre) med en tidsfrist innan du kom med din brådskande uppgift.
Ja, du behöver förmodligen legitimt att något ska göras direkt, men finns det en tillfällig eller snabb åtgärd (som att bara korrigera skrivfiler och trasiga länkar) som skulle fungera för nu? Om så är fallet, gå med det. Sätt sedan upp en tidslinje för resten av projektet som fungerar för alla inblandade.
4. Ett (litet) förslag
Exempel: "Vi bör skapa ett sätt för läsarna att kommentera vår blogg med sina Facebook-profiler."
Har du en smart idé som du tror skulle förbättra ditt företags app eller webbplats? Du kanske är på något. Men det betyder inte att du ska skynda dig till teknikgruppen och förvänta beröm för din idé. Istället måste du vara smart och respektfull med hur du närmar dig det.
Låt utvecklarna eller designarna veta varför du tycker att din idé är värd att implementera ("Vårt marknadsföringsteam delade bara statistik om hur aktiva våra kunder är på Facebook, och jag tror att det kan hjälpa oss att förbättra engagemanget på webbplatsen"). Men samtidigt, tänk på de tids- och pengarbegränsningar som alla står inför. Och kom ihåg att respektera dina IT-proffs kunskaper och åsikter. Överväg att använda "kunde" istället för "borde" för att undvika att låta som om du redan vet alla rätt svar.
Om du hittar den här typen av idéer är en regelbunden del av ditt jobb kan du försöka lära dig om utveckling eller design. Även viss grundläggande kunskap hjälper dig att göra mer användbara och realistiska förslag.
5. En stor idé
Exempel: "Vad sägs om att göra om hela hemsidan?"
Ibland vill du skaka upp saker. Och dina insikter som utomstående kan (ibland) vara precis det som behövs för att uppdatera ditt företags strategi eller varumärke.
Men bli inte sopad av dina revolutionära krav. Återigen måste du berätta för ditt design- eller utvecklingsteam varför du tror att förändringen är nödvändig. Och eftersom det här är en stor översyn som du pratar om bör du vara beredd att rättfärdiga utgifterna och tiden som krävs för att det ska hända.
Du kan få idén att låta mer tilltalande om du kan hitta ett sätt att hjälpa till. Du kanske kan vara en betatestare. Eller så kan du skriva kopia. Eller kanske kan du låna teknikgruppen din praktikant för att hjälpa till att forska några (enklare) aspekter av processen. Varje sätt du kan slå dig in kommer att underlätta belastningen, vilket innebär att din stora idé kan bli verklighet snabbare.
Oavsett om det du behöver är en tidskänslig uppgift eller bara ett kreativt förslag till förbättring, att veta hur du kan komma till ditt tekniska team när du behöver deras hjälp kommer att göra både dina jobb enklare och hjälpa alla att arbeta bättre tillsammans - vilket idealiskt leder till färre förvirrande e-postmeddelanden som stressa alla ut.
