Дори и да не работите в ИТ, почти сигурно работите с технологиите по един или друг начин - създавате електронни таблици, актуализирате уеб страници, проверявате информация на клиентите от бази данни или просто четете имейли. И както вероятно сте забелязали, технологията не винаги работи по начина, по който бихте искали, или по-лошо, по начина, по който трябва. Това означава, че понякога трябва да работите с вашия екип за технологични решения, за да решите проблеми.
Въпреки това, както всеки, който е участвал в някое от това взаимодействие, не винаги върви гладко. За да сте сигурни, че получавате помощта, от която се нуждаете, и че техническите експерти винаги се радват да ви помогнат, ето практически съвети за комуникация с екипа по начин, който ще работи добре и за двете страни.
1. Спешна ситуация
Пример: „Сайтът е свален!“
Вашият дигитален свят се срива или може би просто сървърът на вашата компания се срива. Каквато и криза да е, трябва незабавно да се свържете с вашия технологичен екип - но без да се паникьосвате, да изплувате и да прелиствате бюра. Не, трябва да направите това по правилния начин, защото е толкова критично. Това означава, че трябва да предадете фактите на екипа на технологиите възможно най-бързо и ясно.
Но, предупредителна дума, преди да изпратите този имейл с всички шапки или да се обадите на програмист в неделя сутрин: Уверете се, че ситуацията наистина е „живот или смърт.“ За повечето компании „животът и смъртта“ включват най-долния ред, С други думи, проблем ли е, който спира или сериозно пречи на вас, вашите колеги или вашата компания да можете да обслужвате правилно клиентите? Да? Продължи. Не? Поеми си дълбоко въздух.
Не сте сигурни какво се счита за спешен случай? Попитайте шефа си дали има политика и ако е така, установената процедура, която да следвате, в случай че се случи най-лошото. Ако нито едно от тези неща не съществува, насрочете бърз чат със своя технически ръководител или водещ разработчик относно възможността за настройка на система. Коефициентите са, че ИТ екипът не само ще оцени интереса ви, но и ще се радва, че това ще доведе до по-малко фалшиви аларми в бъдеще. (Дори технологичните ентусиасти се страхуват от спешни случаи в 11 PM сървъра.)
2. Вътрешни грешки
Пример: „Когато кликнете върху бутона„ Напред “, не се пренасям на следващата страница.“
Този път проблемът не представлява заплаха за бизнеса, но е дразнещ проблем, който прави изпълнението на задачите предизвикателство. Може да успеете да продължите с деня си, като обходите грешката, но не трябва просто да я игнорирате.
Отново трябва да следвате всеки зададен протокол за отчитане. (И като се върнете към номер едно, можете да помогнете за създаването на система за отчитане, ако няма такава в момента.) Когато подавате своя отчет, не забравяйте да включите възможно най-подходяща информация.
Докладът за сънища ще включва следното:
- Какво се опитвахте да направите
- Какво се случи, когато го направи
- Устройството и операционната система, които използвате
- Всеки софтуер, който участва
- Екранна снимка на проблема
Въпреки че тази информация може да се почувства досадна да се изпише, тя ще помогне на техния екип да диагностицира проблема по-бързо. Искате бонус точки (и проблемите ви се адресират по-бързо)? Нагласете своите технологични условия, за да говорите за бъга. Това ще спести на всички участващи много предположения.
3. Спешна актуализация
Пример: „Клиентът се нуждае от актуализираната му EOD за началната страница.“
Връщане към централната криза. Но този път вие сте този, който инициира прибързаността. Това означава, че трябва да бъдете особено чувствителни към вашия IT персонал. Бъдете много ясни какво трябва да се направи. И ако имате нужда от помощ с няколко предмета, уведомете екипа за приоритета на всеки, само в случай, че всичко не може да бъде направено едновременно.
Освен това, вместо да изисквате от екипа на технологиите да изпусне всичко, което да ви обслужва, попитайте колко време смятат, че е необходимо за извършване на промяната. Ако тя не може да бъде извършена толкова бързо, колкото искате, трябва да подсилите защо задачата е толкова неотложна (спомняте ли си този долен ред?) И да поясните, че сте тук, за да помогнете за нейното завършване.
Също така е важно да запомните, че само защото имате нужда от нещо, това не винаги прави възможно. Винаги приемайте, че преди да пристигнете с неотложната си задача, екипът по технически въпроси е работил по друг проект (или два или три) с краен срок.
Да, вероятно законно се нуждаете от нещо, което трябва да се направи веднага, но има ли временно или бързо поправяне (като просто коригиране на печатни грешки и прекъснати връзки), което би работило засега? Ако е така, продължете с това. След това задайте времева линия за останалата част от проекта, която работи за всички участващи.
4. (Малко) предложение
Пример: „Трябва да създадем начин читателите да коментират нашия блог, използвайки техните профили във Facebook.“
Имате умна идея, която смятате, че ще подобри приложението или уебсайта на вашата компания? Може да сте на нещо. Но това не означава, че трябва да бързате с екипа на технологиите и да очаквате похвала за вашата идея. Вместо това трябва да бъдете умни и уважителни към начина, по който подхождате към него.
Уведомете разработчиците или дизайнерите защо смятате, че вашата идея си струва да се приложи („Нашият маркетингов екип просто сподели някои статистики за това колко активни са нашите клиенти във Facebook и мисля, че това може да ни помогне да подобрим ангажираността в сайта“). И все пак имайте предвид ограниченията за време и пари, пред които са изправени всички. И не забравяйте да уважавате знанията и мненията на вашите ИТ специалисти. Помислете да използвате „би могло“ вместо „би трябвало“, за да избегнете звученето, като че ли вече знаете правилните отговори.
Освен това, ако измислянето на този вид идеи е редовна част от вашата работа, опитайте се да научите за развитието или дизайна. Дори някои основни знания ще ви помогнат да направите по-полезни и реалистични предложения.
5. Голяма идея
Пример: „Какво ще кажете за редизайн на цялата начална страница?“
Понякога искате да разклатите нещата. А представите ви като външен човек могат (понякога) да са точно това, което е необходимо за обновяване на стратегията или марката на вашата компания.
Но не се подмивайте от революционните си призиви. Отново трябва да кажете на вашия дизайнерски или разработващ екип защо смятате, че промяната е необходима. И тъй като това е основен ремонт, за който говорите, трябва да сте готови да оправдаете разходите и времето, необходимо за осъществяването му.
Можете да направите идеята да звучи по-привлекателно, ако можете да намерите начин да помогнете. Може би можете да сте бета тестер. Или можете да напишете копие. Или може би можете да дадете заем на техния екип на стажа си, за да помогнете да изследвате няколко (по-прости) аспекта на процеса. Всеки начин, по който можете да влезете, ще облекчи натоварването, което означава, че голямата ви идея може да стане реалност по-бързо.
Независимо дали това, от което се нуждаете, е чувствителна към времето задача или просто креативно предложение за усъвършенстване, тъй като знанието как да се обърнете към техния екип, когато имате нужда от тяхната помощ, ще улесни и двете ви задачи и ще помогне на всички да работят заедно по-добре - в идеалния случай ще доведе до по-малко объркващи имейли, които стресирайте всички навън.
