IT 조직을 실패로 이끄는 요인은 무엇인가? 흔히, 실패는 더 잘 알아야 하지만 그렇지 않은 사람들이 이른바 업계에서 금과옥조처럼 여겨지는 조언들을 무작정 도입할 때 벌어진다. 이를 제대로 실천할 수 없기 때문이다.
이를테면 내부 고객을 확보하라는 것부터 차지백(charge back; 비용 분담 정책)을 도입하거나 ROI를 주장하라는 등의 조언들은 멀리서 보면 그럴듯해 보인다. 그러나 잘 살펴보면 IT 조직의 성공을 이끈다는 이 확실한 방법들이 빈번한 실패 공식이라는 사실을 알게 될 것이다.
1. 모든 사람이 IT의 고객이라고 생각하라
실패를 원하는가? IT 조직의 모든 사람이 IT 외부의 모든 사람에게 ‘당신은 나의 고객입니다. 나의 일은 당신의 기대를 충족하는 것입니다(또는 더 최악으로 ‘당신을 행복하게 하는 것입니다’가 있다)’라고 말하도록 하라.
IT 외부의 직원들은 IT의 고객이 아니다. 회사의 이익을 위해 동등하게 협력하는 IT의 동료다. 이들을 내부 고객이라 상정한다면 IT는 ‘복종하는’ 위치로 밀려난다. IT 조직의 모든 사람은 그게 타당하든 그렇지 않든 동료를 행복하게 해줘야 한다. 그러면서도 실제 고객이 더 많은 제품과 서비스를 구매하도록 해야 한다.
2. ‘서비스수준협약(SLA)’을 만들고 ‘계약’처럼 취급하라
회사에 피해를 주고 싶은가? 서비스수준협약(SLA)을 만들고 내부 고객이 서명하도록 하라. 그리고 SLA를 계약처럼 취급하면 된다. 여기에 더해 IT가 실패하길 진심으로 원한다면? IT가 해야 할 일을 하지 않고 있다고 내부 고객이 말할 때마다 SLA를 충족했다고 주장하라. 이는 내부 고객과의 관계를 냉각시키는 아주 좋은 방법이다.
성공을 원한다면? 관계에는 신뢰가 필요하고 신뢰는 동료를 인격체로서 인정하지 않는 한 형성될 수 없음을 기억해야 한다. 더 나아가 신뢰가 있다면 문제를 해결하고자 서로 협력할 것이다. 계약의 목적은 관계를 정의하는 게 아니라 신뢰가 없고 무엇인가 심각하게 잘못됐을 때 이를 누가 책임질 것인지를 정의하는 것이다.
3. 솔직하게 이야기하라
IT는 이른바 바보 같은 상황들을 잘 알고 있다. 예를 들면, ‘간단하게 설명할게. 정전이 됐어. 그런데도 PC가 부팅되지 않는 걸 이해할 수 없니?’, ‘프린터 플러그를 돌려 끼워보라고 했는데, 알고 보니 그게 3핀 플러그였어(웃음)’과 같은 말을 하는 상황이다. 다른 IT 직원이 이들의 이름까지 거론하며 피드백을 공지할 때 함께 웃어라. 그리고 IT의 실패를 원한다면 이를 직접 하라. 실패가 보장될 것이다.
4. 차지백을 도입하라
IT 자원 사용을 막는 훌륭한 방법이 있다. 차지백(charge-backs; 비용 분담 정책)을 도입하는 것이다. 단순한 차지백이 아니라 각 비용센터가 발생시킨 모든 비용 범주를 상세하게 나열한 인보이스를 발행하는 것이다.
예를 들면 CPU 주기, SAN 및 NAS스토리지(물론 이들을 분리해야 한다), 개발자 시간, 10분 단위로 청구되는 헬프 데스크 통화 등이다. 돈을 받아야 할 곳이 어디인지 결정하는 청구서의 정확성에 대한 논쟁처럼 회사 내 협력을 촉진하는(?) 것은 없다.
5. ROI를 주장하라
중요한 프로젝트에 자금이 투입되지 않도록 하고 싶은가? IT 거버넌스 프로세스에 분명하고 가시적인 ROI가 필요하다고 주장하라. 그렇게 하면 일이 흐지부지되기 쉽다. 이를테면 현업 부서가 더 우수한 성과를 더 빨리 달성하는 데 도움을 두는 기술에는 자금이 투입되지 않고, 고객 만족을 확보하는 데 도움이 되는 프로젝트는 (누가 제안했는지를 떠나) 한쪽 구석에서 조롱을 받을 것이다.
6. IT 프로젝트를 독점하라
IT와 현업 간 간극을 더 키우고 싶은가? 프로젝트를 소프트웨어 딜리버리 측면에서 정의하라. IT의 책임은 소프트웨어가 요구사항을 충족하고 사양을 만족시키기만 하면 끝나게 된다.
그리고 만약 현업 부문에서 소프트웨어가 필요한 작업을 수행하지 못한다고 불평한다면 소프트웨어는 사양을 만족하기 때문에 해야 할 일을 정확하게 수행하고 있다고 주장할 완벽한 위치에 있게 된다. 그렇지 않은가? 그게 여의치 않다면 요구사항이 잘못됐다고 주장할 수도 있다. 그렇다면 이는 누구의 잘못인가? 물론 이를 승인한 현업 관리자다.
또는 다른 좋은 방법도 있다. 프로젝트를 소프트웨어(예: ‘세일즈포스닷컴 구축’)가 아닌 비즈니스 성과 측면(예: ‘판매 효율성 향상’)에서 정의하라.
7. 프로젝트 후원자를 배정하라
현업 부문의 후원자가 없다면 프로젝트 성공 확률이 거의 없다는 말은 프로젝트 관리 세계에서 잘 알려져 있다. 하지만 프로젝트가 실패하는지 확인하고 싶은가? 후원자를 배정하라.
후원자(이름만 있는 후원자가 아닌 진짜 후원자)는 프로젝트가 성공하길 진심으로 바라고, 프로젝트가 성공하는 데 필요하다면 기꺼이 위험을 감수한다. 그리고 프로젝트의 비즈니스적 이점과 관련해 자신의 이름과 평판을 건다. 후원자로 배정된 누군가가 이런 일을 할 거라고 생각하는가? 물론 아니다.
8. 클라우드 컴퓨팅 전략을 수립하라
IT가 실패하는 멋진 방법이 하나 있다. 클라우드 컴퓨팅 전략을 수립하는 것이다. 그렇다면 결론을 추정할 수 있다. 클라우드가 필수임을 알기 때문에 전략의 목적은 당연히 클라우드로 가는 것이다.
무엇을 하든 그보다 더 넓게 생각하지 마라. 서비스 측면에서 정의되는 관리형 기술 아키텍처를 고려하지 마라. 그렇게 한다면 진짜 필요한 건 서비스이고, 클라우드는 일부를 프로비저닝하는 방식이라고 믿게 될 수 있다.
한 가지 오래된 규칙이 있다. 형태는 기능을 따른다는 것이다. 서비스는 기능이다. 클라우드는 서비스의 일부가 필요로 하는 형태 가운데 하나다. IT가 성공하길 원치 않는다면 이런 식으로 생각하지 마라. 그렇다면 클라우드는 불가피해진다.
9. 애자일을 추종하라. 해외로 가라. 그리고 이를 동시에 이행하라
애자일 방법론은 많은 이점이 있다. 성공을 위한 한 가지 전제조건은 비공식적 사용자가 높은 수준으로 참여하는 것이다. 따라서 경로 수정이 빈번하고 소소하게 일어난다. 개발자는 매일 진행 상황을 확인하고 UAT(User Acceptance test)를 시행한다.
해외로 가는 것은 한 가지 이점이 있다. 시간당 인건비를 절감할 수 있기 때문이다. 문제가 있다면 애자일 방법론에서 필수적인 높은 수준의 비공식적 사용자 참여가 없을 가능성이다. 이를테면 12시간의 시차, 언어 장벽, 문화적 차이, 온라인 회의 등으로 인해 제한되는 상호작용을 감안한다면 애자일은 상당히 어려워진다.
물론 이를 실현할 순 있지만 겁쟁이들이 할 수 있는 일은 아니고 더군다나 애자일을 이제 막 시작한 IT 조직이라면 더욱더 아니다. 애자일을 하든지, 해외로 가든지, 어느 하나를 선택하라.
10. 멀티태스킹 역량을 갖춰라
IT 실패를 확고히 하는 다음 단계는 바로 모든 사람에게 멀티태스킹을 강요하는 것이다. ‘멀티태스킹은 매우 좋은 역량이 아닌가?’라고 생각할 수 있다. 하지만 이것이 진정으로 의미하는 바는 작업량을 늘리기 위해 생산성과 질을 줄이고 스트레스를 증가시키는 것이다.
누군가에게 하고 있는 일을 중단하고 다른 일을 하라고 말하고 싶은 충동이 들 때 이를 기억하라. 인간은 멀티태스킹을 하지 않는다. 단지 한 작업에서 다른 작업으로 왔다 갔다 하는 것이다. 그리고 그렇게 할 때마다 정신적 기어를 변환하면서 시간을 낭비한다. 집중을 요하는 작업일수록 시간 낭비는 심해진다. 그렇다면 어떻게 해야 할까? 사람들이 현재 하는 작업을 마무리하고, 그다음 다른 일로 이동하도록 하라.
11. 수많은 프로젝트를 가동하라
IT 조직에는 모든 사람이 원하는 모든 것을 처리할 수 있는 인력이 없다. 따라서 일단 많은 프로젝트를 시작하고 이를 달성하기 위해 모든 인력을 동원하는 것은 타당하다. 직원들은 프로젝트 사이를 왕래하며 작업을 한다. 물론 그렇다면 프로젝트는 훨씬 더 오랜 시간이 걸릴 것이고, 훨씬 더 큰 비용이 들 것이며, 수준 이하의 결과를 전달할 것이다.
IT의 평판을 높이려면 다음의 규칙을 수립하라. 모든 프로젝트는 인력을 완전하게 갖춘 다음 시작해야 한다는 것이다. 여기서 완전한 인력이란 팀원이 프로젝트에 참여해 작업할 수 있을 때까지 기다리지 않는다는 뜻이다. 이렇게 하면 수많은 프로젝트 사이에서 허둥거리지 않으면서 프로젝트를 하나하나 완수할 수 있다.
12. 섀도우 IT를 제거하라
현업 부문에서 IT를 자체적으로 운영한다면 문제가 생길 수 있다. 의심의 여지가 없는 사실이지만 동시에 이게 전부는 아니다.
현업 부문에서 이런 DIY를 하는 이유는 IT 인력이 충분하지 않기 때문이다. 섀도우 IT가 처리할 수 있을 만큼 사소한 문제마저도 말이다. 그래서 IT는 이러한 좋은 대안이 있음에도 현업 부문으로 하여금 엑셀로 모든 것을 하도록 하는 어색한 상황에 놓이게 된다.
또 다른 문제는 섀도우 IT를 아예 제거하는 것이다. 클라우드 기반의 애플리케이션을 어떻게 사용하고 있는지 파악하는 것만도 어려운 일이다. IT가 섀도우 IT를 제거해버리면 어떻게 될까? IT 영역의 효율적인 솔루션을 IT가 스스로 배제하는 셈이다.
13. 요청에 상관없이 ‘예’ 또는 ‘아니요’로 대답하라
IT 실패를 보장하는 마지막이자 최고의 방법은 요청에 상관없이 ‘예’ 또는 ‘아니요’로 대답하는 것이다. ‘아니요’라고 말하면 관계를 망친다. 그렇다고 ‘예’라고 말하면 지킬 수 없는 약속을 하는 것이다. 다른 사람들에게도 그러한 약속을 해서 시간이 없기 때문이다.
적절한 대답은 “그것을 할 수 있다. 다만 필요한 것을 말해주겠다”라는 것이다. 요청 관리에는 불변의 규칙이 하나 있다. 요청이 프로젝트 범위 변경이든, 소프트웨어 보강이든, 예정 없이 누군가에게 노트북을 제공하는 것이든, 반드시 돈이 필요하다는 것이다. 공짜는 없다.
‘아니요’라고도, ‘예’라고도 말하지 마라. 요청을 만족시키는 데 필요한 것들을 설명하라. 그렇다면 논쟁이 아닌 대화를 할 수 있을 것이다. 훨씬 낫지 않은가?
