Még akkor is, ha nem dolgozik az informatikában, szinte minden bizonnyal valamilyen módon dolgozik a technológiával - táblázatokat készít, weboldalakat frissít, az ügyfelek adatait adatbázisokból ellenőrzi, vagy csak e-maileket olvas. És amint valószínűleg észrevette, a tech nem mindig úgy működik, ahogy szeretné, vagy ami még rosszabb, ahogy kellene. Ez azt jelenti, hogy néha a problémák megoldása érdekében együtt kell működnie a tech-csapattal.
Mint azonban bárki, aki ezen interakció egyikén részt vesz, nem mindig megy zavartalanul. Annak érdekében, hogy megkapja a szükséges segítséget, és hogy a műszaki szakemberek mindig szívesen segítsenek, itt találunk gyakorlati tippeket a csapattal való kommunikációhoz, amely mindkét fél számára jól működik.
1. Vészhelyzet
Példa: “A webhely nem működik!”
A digitális világ összeomlik, vagy esetleg csak a vállalati kiszolgáló összeomlik. Bármi legyen is a válság, azonnal kapcsolatba kell lépnie a tech csapattal - pánik nélkül, kiborulva és az asztalok megfordítása nélkül. Nem, ezt helyesen kell tennie, mert annyira kritikus. Ez azt jelenti, hogy a tényeket a lehető leggyorsabban és világosabban kell eljuttatnia a tech csapathoz.
De egy figyelmeztető szó, mielőtt elküldné ezt az e-mailt minden sapkával vagy hívna egy fejlesztőt vasárnap reggel: Győződjön meg arról, hogy a helyzet valóban „élet vagy halál”. A legtöbb vállalatnál az „élet és halál” magában foglalja az alsó sorot. . Más szavakkal: ez egy olyan probléma, amely megállítja vagy súlyosan akadályozza meg Önt, kollégáit vagy cégét abban, hogy megfelelő kiszolgálást tudjon nyújtani az ügyfeleknek? Igen? Folytasd. Nem? Vegyünk egy mély lélegzetet.
Nem biztos benne, hogy mi vészhelyzet? Kérdezze meg a főnököt, ha van-e irányelv, és ha igen, a bevezetett eljárást, amelyet követni kell, ha a legrosszabb is bekövetkezik. Ha egyik sem létezik, ütemezzen egy gyors csevegést műszaki vezetőjével vagy vezető fejlesztőjével a rendszer felállításának lehetőségéről. Az esély az, hogy az informatikai csapat nem csak értékelni fogja érdeklődését, hanem örül is, hogy ez a jövőben kevesebb téves riasztást eredményez. (Még a tech rajongók is félnek egy 11 PM szerver vészhelyzetetől.)
2. Belső hibák
Példa: “Amikor rákattint a“ Következő ”gombra, nem kerül a következő oldalra.”
Ezúttal a probléma nem fenyegeti az üzletet, hanem egy bosszantó rés, ami a feladatok elvégzésének kihívást jelent. Előfordulhat, hogy a hibával körülveszi a napját, de nem szabad csak figyelmen kívül hagynia.
A jelentésekhez ismét be kell tartania minden beállított protokollt. (És visszatérve az első számhoz, segíthet egy jelentéskészítő rendszer felállításában, ha jelenleg nem létezik.) A jelentés elkészítésekor ne felejtse el annyi releváns információt megadni, amennyit csak tud.
Az álomjelentés a következőket tartalmazza:
- Mit próbáltál csinálni
- Mi történt, amikor megcsináltad?
- Az Ön által használt eszköz és operációs rendszer
- Bármely érintett szoftver
- A kérdés képernyőképe
Noha ez az információ unalmasnak tűnik kiírni, ez segít a műszaki csapatnak a probléma gyorsabb diagnosztizálásában. Bónusz pontokat szeretne (és problémáit gyorsabban kezeli)? Keresse fel technikai feltételeit, hogy beszéljen a hibáról. Ez sok mindenesetre kitalál minden résztvevőt.
3. Sürgős frissítés
Példa: “Az ügyfélnek szüksége van a honlapjára frissített EOD-re.”
Vissza a válság központjához. De ezúttal Ön kezdeményezi a rohanást. Ez azt jelenti, hogy különösen érzékenynek kell lennie az informatikai személyzettel szemben. Légy nagyon világos, hogy mit kell tennie. És ha több elemhez segítségre van szüksége, tudassa a csapattal mindegyik prioritását, csak arra az esetre, ha mindent nem lehet egyszerre megtenni.
Ahelyett, hogy azt követelné, hogy a tech csapata mindent eldobjon az Ön kiszolgálása érdekében, kérdezze meg, mennyi időre van szükségük a változás végrehajtásához. Ha azt nem lehet elvégezni olyan gyorsan, ahogy szeretné, akkor meg kell erősítenie, hogy miért olyan sürgető a feladat (emlékszel erre a lényegre?), És világossá kell tennie, hogy itt vagy, hogy segítsen az ASAP teljesítésében.
Az is fontos, hogy emlékezzünk erre, csak azért, mert szüksége van valamire, ami nem mindig teszi lehetővé. Mindig tegyük fel, hogy mielőtt megérkezett a sürgős feladathoz, a tech csapata egy másik (két vagy három) projekten dolgozott egy határidővel.
Igen, valószínűleg jogszerűen meg kell tenni valamit azonnal, de van-e ideiglenes vagy gyors javítás (például csak a helyesírás és a megszakadt hivatkozások javítása), amely most működne? Ha igen, vegye fel. Ezután állítson be egy ütemtervet a projekt többi részére, amely minden érintett számára működik.
4. Egy (kicsi) javaslat
Példa: „Meg kell teremtenünk egy módot az olvasóknak, hogy a Facebook-profiljuk segítségével kommentálhassák blogunkat.”
Van egy okos elképzelésed, hogy Ön szerint javítaná vállalatának alkalmazását vagy webhelyét? Lehet, hogy valami van. De ez nem azt jelenti, hogy oda kellene rohannia a tech csapathoz, és dicséretet kellene várnia az ötleteért. Ehelyett okosnak és tiszteletteljesnek kell lennie hozzáállásához.
Mondja meg a fejlesztőknek vagy a tervezőknek, hogy Ön szerint miért érdemes ötletét megvalósítani („Marketing csapatunk csak néhány statisztikát osztott meg arról, hogy mennyire aktívak az ügyfelek a Facebook-on, és azt hiszem, ez segíthetne javítani a webhely elkötelezettségét”). Ugyanakkor tartsa szem előtt az idő- és pénzkorlátozásokat, amelyekkel mindenki szembesül. És ne felejtse el tiszteletben tartani informatikai szakembereinek tudását és véleményét. Fontolja meg a „lehet” helyett a „kellene” helyet, hogy elkerülje azt a hangot, mintha már ismeri az összes helyes választ.
Ezenkívül, ha az ilyen típusú ötletek rendszeres része a munkádnak, próbálj meg tanulni a fejlesztésről vagy a formatervezésről. Még néhány alapvető ismeret is segít hasznosabb és reálisabb javaslatok megfogalmazásában.
5. Nagy ötlet
Példa: “Mi lenne a teljes honlap újratervezésével?”
Néha meg akarja rázni a dolgokat. És kívülálló betekintésetek (néha) éppen azok lehetnek, amelyekre szükség van a vállalat stratégiájának vagy márkájának frissítéséhez.
De ne szabaduljon meg forradalmi ösztönzéseidtől. Még egyszer el kell mondania a tervező vagy fejlesztő csapatának, miért gondolja úgy, hogy a változás szükséges. És mivel ez egy jelentős újjáépítés, amiről beszéltél, fel kell készülnie arra, hogy igazolja a ráfordításokhoz és időhöz szükséges időt.
Az ötlet vonzóbbá teheti, ha talál valamit a segítségére. Lehet, hogy béta tesztelő lehet. Vagy írhat másolatot. Vagy esetleg kölcsönözheti a technikai csapatot az gyakornokának, hogy segítsen a folyamat néhány (egyszerűbb) szempontjának kutatásában. Bármely módon be tud lépni, megkönnyíti a terhelést, ami azt jelenti, hogy nagyszerű ötlete gyorsabban valósággá válhat.
Függetlenül attól, hogy időigényes feladat, vagy csak kreatív fejlesztési javaslat, ha tudod, hogyan kell felkeresni a tech csapatadat, amikor segítségre van szüksége, megkönnyíti mind a munkádat, mind pedig mindenki jobb együttműködését - ideális esetben kevesebb zavaró e-mailt eredményez stressz mindenkit ki.
