IT 부서에서 일하지 않더라도 스프레드 시트 만들기, 웹 페이지 업데이트, 데이터베이스에서 고객 정보 확인 또는 전자 메일 읽기와 같은 방식으로 기술을 사용합니다. 그리고 이미 알고 있듯이, 기술이 항상 원하는 방식으로 작동하지 않거나, 더 나쁜 방식으로 작동하지는 않습니다. 즉, 때로는 문제를 해결하기 위해 기술 팀과 협력해야합니다.
그러나이 상호 작용 중 하나에 있었던 사람이 알고 있듯이 항상 원활하게 진행되는 것은 아닙니다. 필요한 도움을 받고 기술 전문가가 항상 귀하를 도와 줄 수 있도록하기 위해 양 당사자에게 잘 작동하는 방식으로 팀과 의사 소통하기위한 실질적인 팁이 있습니다.
1. 비상
예 : “사이트가 다운되었습니다!”
디지털 세상이 무너 지거나 회사의 서버가 무너질 수 있습니다. 위기가 어떻든간에 당황하지 않고 당황하고 책상을 뒤집지 않고도 기술 팀과 즉시 연락해야합니다. 아니요, 이 방법은 매우 중요하므로 올바른 방법으로 수행해야합니다. 즉, 가능한 한 신속하고 명확하게 기술 팀에 사실을 전달해야합니다.
그러나 모든 대문자로 해당 전자 메일을 보내거나 일요일 아침에 개발자에게 전화하기 전에 경고의 말이 있습니다. 상황이 실제로 "인명 또는 사망"인지 확인하십시오. 대부분의 회사에서 "인명 및 사망"은 결론과 관련이 있습니다. . 다시 말해, 귀하, 동료 또는 회사가 고객에게 제대로 서비스를 제공 할 수 없게하는 문제가 있습니까? 예? 계속하십시오. 아니? 심호흡하십시오.
긴급 상황이 무엇인지 잘 모르시겠습니까? 정책이 있는지 상사에게 문의하고, 그렇다면 정책이 최악의 경우에 따라 확립 된 절차를 따르십시오. 이 두 가지 중 어느 것도 존재하지 않으면 기술 관리자 나 개발자에게 시스템 설정 가능성에 대해 빠른 대화를 예약하십시오. 문제는 IT 팀이 귀하의 관심에 감사 할뿐만 아니라 향후 잘못된 경보가 줄어든다는 사실에 만족할 것입니다. (기술 애호가들도 오후 11시 서버 긴급 상황을 두려워합니다.)
2. 내부 버그
예 : " '다음'버튼을 클릭하면 다음 페이지로 이동하지 않습니다."
이번에는 문제가 비즈니스에 위협이되지 않지만 작업을 완료하는 데 어려움을 겪는 자극적 인 결함입니다. 버그를 해결하여 하루를 보낼 수 있지만 무시해서는 안됩니다.
다시, 보고를 위해 설정된 프로토콜을 따라야합니다. (1로 돌아가서 현재 존재하지 않는 경우보고 시스템을 설정하는 데 도움을 줄 수 있습니다.) 보고서를 제출할 때는 가능한 한 많은 관련 정보를 포함해야합니다.
꿈의 보고서에는 다음이 포함됩니다.
- 당신이하려고하는 것
- 당신이 그것을했을 때 일어난 일
- 사용중인 장치 및 운영 체제
- 관련된 모든 소프트웨어
- 문제의 스크린 샷
이 정보를 작성하는 데 지루한 느낌이 들지만 기술 팀은 문제를 더 빨리 진단하는 데 도움이됩니다. 보너스 포인트를 원하십니까? 기술 용어를 정리하여 버그에 대해 이야기하십시오. 그것은 많은 추측과 관련된 모든 사람을 구할 것입니다.
3. 긴급 업데이트
예 : “고객은 자신의 홈페이지를 업데이트 한 EOD가 필요합니다.”
위기 중심으로 돌아갑니다. 그러나 이번에는 서두르는 사람입니다. 즉, IT 직원에게 특히 민감해야합니다. 해야 할 일에 대해 매우 명확하게하십시오. 여러 항목에 대한 도움이 필요한 경우 동시에 모든 작업을 수행 할 수없는 경우를 대비하여 팀에 각 항목의 우선 순위를 알리십시오.
또한 기술 팀이 서비스를 제공하기 위해 모든 것을 포기하도록 요구하는 대신, 변경을 수행하는 데 얼마나 많은 시간이 필요한지 물어보십시오. 원하는만큼 빨리 수행 할 수없는 경우 작업이 왜 긴급한지 강화해야합니다 (요점을 기억하십니까?) 최대한 빨리 완료하도록 도와야합니다.
무언가가 필요하기 때문에 항상 가능하지는 않다는 것을 기억하는 것이 중요합니다. 긴급한 업무를 수행하기 전에 기술 팀이 마감일이있는 다른 프로젝트 (또는 2-3 개)를 작업하고 있다고 항상 가정하십시오.
그렇습니다. 아마도 합법적으로 즉시해야 할 일이 필요하지만, 오타를 수정하고 링크를 끊는 것과 같은 일시적 또는 빠른 수정이 있습니까? 그렇다면 그렇게하십시오. 그런 다음, 관련된 모든 사람에게 적합한 나머지 프로젝트 일정을 설정하십시오.
4. 작은 제안
예 : "독서가 Facebook 프로필을 사용하여 블로그에 댓글을 달 수있는 방법을 만들어야합니다."
회사의 앱이나 웹 사이트를 개선 할 것이라고 생각하는 영리한 아이디어가 있습니까? 당신은 뭔가에있을 수 있습니다. 그렇다고 기술 팀으로 달려 가서 아이디어에 대한 칭찬을 기대해야하는 것은 아닙니다. 대신, 접근 방식에 대해 현명하고 존중해야합니다.
개발자 또는 디자이너에게 아이디어를 구현할 가치가 있다고 생각하는 이유를 알려주십시오 ( "Google 마케팅 팀은 Facebook에서 고객의 활동 수준에 대한 통계를 공유했으며, 이를 통해 사이트 참여도를 높일 수 있다고 생각합니다"). 그러나 동시에 모든 사람이 직면하는 시간과 돈의 한계를 명심하십시오. 또한 IT 전문가의 지식과 의견을 존중해야합니다. 이미 모든 정답을 알고있는 것처럼 소리가 나지 않게하려면“should”대신“could”를 사용하십시오.
또한 이런 종류의 아이디어를 생각해내는 것이 직업의 일부라면 개발이나 디자인에 대해 배우십시오. 약간의 기본 지식조차도 더 유용하고 현실적인 제안을하는 데 도움이됩니다.
5. 큰 아이디어
예 : “전체 홈페이지를 다시 디자인하는 것은 어떻습니까?”
때때로 당신은 물건을 흔들고 싶어합니다. 또한 외부인으로서의 통찰력은 회사의 전략이나 브랜드를 새롭게하기 위해 필요한 것일 수도 있습니다.
그러나 혁명적 인 충동에 휩쓸 리지 마십시오. 다시 한 번, 설계 또는 개발 팀에 변경이 필요하다고 생각하는 이유를 알려야합니다. 그리고 이것은 당신이 이야기하고있는 대대적 인 점검이기 때문에, 그것이 일어나기 위해 필요한 비용과 시간을 정당화 할 준비가되어 있어야합니다.
도움이되는 방법을 찾을 수 있다면 아이디어가 더 매력적으로 들릴 수 있습니다. 베타 테스터가 될 수도 있습니다. 또는 사본을 쓸 수 있습니다. 또는 기술 팀에게 인턴을 빌려 프로세스의 몇 가지 (더 간단한) 측면을 연구하는 데 도움을 줄 수 있습니다. 당신이 투구 할 수있는 방법은 짐을 덜어 주므로 큰 아이디어가 더 빨리 현실이 될 수 있습니다.
필요한 작업은 시간에 민감한 작업이든, 개선을위한 창의적인 제안이든 관계없이 기술 팀에 도움을 요청하는 방법을 아는 것은 작업을보다 쉽게하고 모두가 더 잘 협력 할 수 있도록 도와줍니다. 모든 사람을 스트레스.
