IT하는 사람들도 당신의 동료입니다
적이나 부려먹을 사람이 아니고요
비 IT회사에서의 가장 큰 문제점 중 또 하나는, IT 부서를 아랫사람 부리듯 한다는 거다. 보기에는 쉬워 보이는데 왜 이 정도도 못해주는지, 왜 맨날 시간이 없고 이건 이래서 안 되고 저래서 안 된다고 하는 건지. 당연히 IT를 잘 모르는 입장에서야 공수 산정이나 업무 진행 프로세스를 모르니까 할 수 있는 말이라고 생각한다. 모를 때까지는. 협업을 하다 보면 어느 정도 감안이 되는 부분이 있어야 하는데 아직도 탑다운 방식으로 찍어 내린다. 까라면 까는 거지 말이 많아. (진짜로 들은 적도 있다) 위에서 나열한 저런 이유들로 안 된다고 하면 핑계 대기는 쉽지. IT가 안 된다고 했어요. (IT회사로 이직하고 싶습니다 설마 IT 회사도 이런가요) 그래서 정리해 본, 오로지 IT 부서 입장에서 유관 부서가 알아주셨으면 하는 점들.
1. 업무 내용 사전 공유
우리 회사만의 문제인지 모르겠으나, 유독 업무 내용이 사전에 공유되지를 않는다. 온라인 운영을 총괄하는 팀은 우리 팀이고, 앱이든 웹이든 인프라든 뭔가 변경된다면 우리 팀이 업무를 진행해야 한다. 그런데 갑자기 일정과 예산, 괴상한 그림이 박힌 보고 자료가 하나 띡 오고 이미 저 윗분 어디까지 보고된 사항이니 무조건 해내라고 한다. 솔직히 제일 화가 나는 상황이다. 이미 기존에 진행되던 업무나 해당 건이 실제로 개발 가능한 상황인지 여부는 전혀 중요하지 않다. 본인들이 생각했을 때 하면 좋겠다, 하면 될 것 같은데 싶은 것들을 하겠다고 해버리고 던져주니까 문제인 거다.
심지어 던지고는 중간에 신경도 쓰지 않고 일정이 다가오면 오픈할 수 있는지만 확인한다. 어떻게 해서든 일정에 맞춰서 이거 이거 되게 해서 오픈해라, 왜냐면 상무님이- 사장님이- 하라고 했으니까. 이미 보고했으니까. 이유 참 간결해서 좋다. 회사에서 동료로 존중받는다는 느낌이 도무지 들지 않는다. 우리도 현업에서 어떤 업무를 하는지, 어떤 게 필요한지 모르니까 업무를 요청하면서 우리를 설득하고 협의해 나가는 과정이 마땅히 필요하지 않을까. 일언반구도 없이 일정이고 예산이고 정해서 해내라고 던지기 이전에.
2. 모르는 업무/기능은 문의하기
많은 유관부서들이 모르겠지만(왜죠), 회사에서 사용하는 FO든 BO든 모든 시스템에는 반드시 정책과 가이드 문서가 있다. 기능이 신규 배포되었을 때 IT팀에서 업무 연락을 돌리거나 가이드를 게재했을 것이고, 문서를 읽고 그에 따라 수행했다면 문제는 생기지 않는다. 대부분의 문제는 1) 문서를 읽지 않고 멋대로 사용했거나 2) 문서를 읽었으나 헷갈리는 부분이 있었는데 자의적으로 해석 후 사용하는데서 일어난다. 회사에서 진행하는 수많은 품의는 위임전결 규정이 하나만 어긋나도 반려되는데 의문을 가지지 않으면서, 왜 이렇게 전산 시스템은 멋대로 사용하고도 되려 적반하장인지 모르겠다.
1번의 경우는 말할 필요도 없고, 2번의 경우를 주의드리고 싶다. 별 것도 아닌데 미안해서 못 물어보고 이상한 걸 등록해서 장애가 나는 것보다는 애매한 건 다 물어봐주시는 게 낫다. 가이드를 꼼꼼하게 읽어주면 좋겠지만, 늘 가이드나 정책서를 작성하면서도 누군가 읽으리라는 기대는 없다. (sad) 그렇지만 잘 모르겠으면 꼭 먼저 가이드를 찾아보거나, 그것도 귀찮으면 물어봐주시기라도 했으면 한다. 그냥 잘못 등록하는 정도면 괜찮은데 뭔가 잘못된 걸 대량으로 등록한다던가 하는 불상사가 일어나면 사태를 돌이킬 수 없다.
3. 이해하려는 자세
업무 기본 매너 중의 하나인데, 이상하게 IT를 대할 때는 이 자세를 갖추려고조차 하지 않는 것 같다. 우리는 서로의 업무에 대해 잘 모른다. 비슷한 업무를 수행하는 다른 팀이어도 맡은 업무와 사람과 상황이 다르면 제대로 알 수 없다. 하물며 특수 직무에 속하는 IT는 오죽할까. 1번에서 잠깐 언급했듯이 IT팀에서도 아무 이유 없이 달랑 기능만 개발해내라- 하는 요청을 받고 나면 기분이 나쁜 건 차치하고서라도 왜 그걸 해야 하는지 알 수가 없다. 어떤 지점에서 이런 기능이 필요한지에 대한 설명이 있으면 수용하거나 더 나은 방향을 제시할 수도 있고, 이 화면에 있는 이 기능을 사용하면 된다고 가이드를 줄 수도 있다.
이 지점은 현업에서도 마찬가지다. 충분히 설명을 했는데도 IT에서 개발을 거절할 수 있다. 이유는 다양하다. 이미 있는 기능인데 활용하고 있지 않았거나, 현재 있는 개발 건보다 중요도가 떨어져서 우선순위가 뒤로 밀리거나, 프로젝트 요건으로 들어가 있어 당장 개발하기보다는 프로젝트 오픈 시점에 맞춰야 하거나, 기존 정책에 위배되어 개발할 수 없거나, OS나 단말기 이슈로 개발 자체가 불가능하거나, 비용 이슈가 있거나... 이유는 차고 넘친다.
이해하기 쉽게끔 설명해드리려고 하지만 거절 자체에 포인트를 두고 기분이 상해하시는 분들이 계신다. 하지만 입장을 한 번만 이해하려고 해 줬으면 좋겠다. 각 팀에서 요청한 개발 건이 하나씩만 들어와도 IT팀이 처리해야 할 업무는 수십 건이 되고, 우선순위를 정해서 짜 놓은 개발 일정에는 자꾸 더 높은 사람이 시켰다는 자칭 급한 건들이 자꾸만 치고 들어온다. 이런 과정에서 현업이 순수하게 업무 효율성을 위해서 제안하는 건들이 받아들여지기는 쉽지 않다. 회사의 체질, 업무 프로세스와 문화 자체를 개선하려고 해야 하지 않을까.
우리 회사는 카카오나 네이버, 쿠팡처럼 쇼핑몰 운영에 많은 투자를 하는 회사가 아니다. 인력풀부터 차이가 난다. 한 팀에서 전사에서 쏟아지는 모든 개발 건을 대응해야 하는 구조다. 관제 순으로는 맨 밑에서 2번째 팀이다. 솔직히, 도대체 왜 회사에서 이 정도 대우밖에 해주지 않는 건지 잘 모르겠다. 우리 일이 늘 그렇듯이 잘하면 서비스가 멀쩡히 잘 굴러가니 티가 안 나고 조금 삐끗하면 온갖 질타가 쏟아지는 직무다. 여기서 장애가 나서 쇼핑몰이 굴러가지 않으면 매출도 올 스탑이라는 소리다. 그러면 그만큼 중요하게 여겨주고 대우를 해줘도 모자랄 판에 왜 이렇게 막 다루는 걸까.
일하면서 만나는 사람들을 싫어하지 않을 수는 없는지, 늘 생각해왔다. 무난한 관계였던 사람들도 일하다 보면 그림자도 밟기 싫어질 때가 일쑤였으니까. 선배는 우리도 다른 팀에서 만났으면 서로 엄청 싫어하고 있을 수도 있다고 했지만. 나는 당장 내 울타리 안의 사람들을 사랑하고 지키는 게 더 급하다. 바깥사람들까지 다 지켜가면서 내 사람들도 지킬 수는 없다. 다만, 내 사람들을 최우선 하되 예의는 최대한 지키는 것. 늘 업무의 기준으로 잡고 있다.
그래도 좋은 말만 쓰고 싶어서 불만인 부분에 대한 글은 안 쓰려고 거르다 보니 글의 주기가 점점 늘어졌다. 마음에 안 드는 부분은 계속 얘기해나가야 언젠가는 개선이 될 거라고 믿으며 써보려고 한다. 나는 힘들어도 뒤에 올 사람들까지 계속 힘들지는 말아야지. 어떡하겠어, 그러니까 샌드위치지. 제발 친하게 지내고 싶어요. 제발. IT팀도 회사의 일원이며 동료라는 사실을 다시 한번 기억해주기를 바란다. 서로의 관점이 다를 뿐, 목표는 같은 사람들이라는 걸.
