‘인싸’가 되려 하는 ‘아싸’처럼 굴다간... '어설픈 IT 관리' 에 대한 7가지 지적

수많은 조언을 읽고 듣고 있지만 IT 부서를 제대로 운영하고 있는지 불안한가? 여기 현대 IT 리더들이 종종 저지르는 7가지 실수를 정리했다. 

오늘날 CIO는 수많은 소스에서 보다 효율적인 IT 부서 관리 방법에 대한 조언을 얻을 수 있다. CIO닷컴을 비롯해 수많은 시장 조사 기관이 도움을 주려 한다. CIO의 최우선 사항이 무엇이 되어야 하는지를 목록화한 수많은 콘텐츠가 있다. 보통 너무 뻔한 내용인 경우도 흔하지만, 딱히 손해볼 것도 없는 자료들이다. 

흔하지 않은 조언을 제공하기 위한 시도로, 이 글에서는 IT 관리 측면의 7가지 중요한 잘못을 살펴보고자 한다. 뻔한 글로 읽히지 않기를 바란다.
 
1. ‘리드’는 부족하고 ‘관리’만 많이 함 
흔하지 않은 조언이라는 앞서의 약속이 벌써부터 위태롭다. 관리 대신 리드하라는 조언을 많이 접해봤을 것이다. 

다리가 없는 개(a dog with no legs)에 대한 오래된 농담이 있다. ‘다리 없는 개를 어떻게 불러야 하나?’라는 질문과 ‘중요하지 않다. 어쨌든 그 개는 오지 않을테니’라는 답변이다.  매일 아침 개의 주인은 개를 질질 끌어내게 된다.
직원들을 질질 끌고 가는 것과 그들이 스스로 올바른 방향으로 나아가도록 하는 것 사이에 차이를 만드는 것이 바로 리더십이다.

2. '그러나' 리드는 너무 많이 하고 관리는 충분히 하지 않음
당신은 업무에 대해 돈을 받는다. 그것이 바로 관리과 관련을 가진다. 즉, 당신이 책임지고 있는 기업의 업무를 확실히 수행하는 것이다.

리더십은 그러한 목표를 달성하는 데 유용한 도구이다(위의 ‘개’를 참조할 것). 하지만 그것은 유일한 도구는 아니다. 정보 기술이 명백한 예이다. 비즈니스 프로세스 최적화 이니셔티브도 마찬가지이다. 그리고 종종 리더십에 너무 중점을 두고 있기 때문에 관리자들은 자신이 무엇 때문에 월급을 받는지 놓치곤 한다.

3. 차지백을 다투기
차지백은 ‘위대한 이론이지만…’이라고 표현할 수 있겠다. ‘위대한 이론’ 부분은 IT 리소스에 대해 비용을 지불하게 함으로써 (현업) 이용자가 IT에 무엇을 요청해야 하는지에 대한 결정을 보다 신중하게 내릴 수 있도록 한다는 것이다.

‘이지만’ 부분은 IT가 얼마나 청구하는지 설명할 때 발생한다. IT가 차지백을 계산하는 2가지 방법이 있다. 먼저 단순한 방법으로 IT 예산을 현업 관리자에게 할당할 수 있는데, 예를 들어, 기업의 총 인원의 백분율 또는 관리자가 통제하는 총 기업 예산의 백분율과 같은 이해하기 쉬운 지표를 기준으로 한다.

아니면 IT는 각 IT 리소스 유형별로 세분화된 단위 비용을 계산하고, 해당 리소스의 소비를 모니터링하며, 단위 비용으로 제시할 수 있다.

단순한 접근 방식은 잊어버려라. 그것을 매력적이게 하는 그 단순성이 문제가 된다. 현업 관리자가 IT 소비를 줄임으로써 차지백 비용을 절감할 수 있는 방법이 없기 때문에 전제와 어긋난다.

세분화되고 정확한 접근 방식의 경우, 청구값에 대한 논쟁으로 인해 전체 시간과 예산이 낭비되기 쉽다. 즉 이 접근 방식은 복잡하기 때문에 입증할 수 없는 수많은 가정의 결과로 이어진다. 게다가, 누가 논쟁에서 이기든, 양측이 잃어버린 시간은 그들의 시간의 비용으로 환산하면, 같은 돈이 어느 주머니에서 나올 것인지 결정하는 것과 같다.

포기하라. 

4. 기술자가 아닌 사업가(business person)가 되기 위한 노력
CIO라면 이 충고를 반복해서 읽었다. 오늘날 명함에 ‘기술’이 적힌 최고 경영자가 기술자여서는 안 된다는 독특한 주장이 제기되고 있다.

그러나 선후를 혼동해서는 안 된다. 우선, 둘을 비교해보면 사업가가 되는 것이 더 쉽다. 둘째로, 회사의 CFO가 재무 전문가가 아닌 사업가여야 하며 최고 마케팅 책임자가 마케팅 전문가가 아니라 사업가여야 한다고 생각하는가? 

어쨌든 당신의 관심을 끌었으니 비유를 더해본다. 기술자가 아닌 사업가가 되려고 노력하는 CIO들은 ‘인싸’가 되려고 필사적으로 노력하는 ‘아싸’ 고등학생들과 같다. 그래봤자 그들은 여전히 소외될 것이다. 쿨하지 못할 뿐더러 한심함까지 더해지게 되었다.

5.  ‘아키텍트’를 동사로 사용하기
이것은 단지 필자의 의견일 뿐이다. 하지만 나는 동사로서의 아키텍트가 앞으로 당신이 할 일에 대해 ‘엔지니어’를 동사로 대체하는 것과 비슷하다고 생각한다. 종종 “우리는 해결책을 아키텍트 해야 한다”는 말을 들으면 비즈니스 인싸 모임에 가입하는 데 실패한 누군가가 대신 기술 인싸 모임에 가입하기로 결정한 것처럼 들린다.

6. ‘베스트 프랙티스’ 활용하기
지는 싸움이다. 어떤 것이 ‘모범관행’이라고 주장하는 사람에게 반박하기는 어렵다. 그저 좋은 관행, 검증된 관행, 또는 기본적인 전문성의 최소 기준을 의미하는 경우가 태반이다. 이에 반박한다는 것은 그저 불평처럼 들리기 십상이며 명분을 잃기도 쉽다. 현실은 그저 희망사항을 나열하는 것에 그친다. 
. 
싸움에 졌을테니 행운의 숫자 7로 넘어가겠다. 

7. 프로젝트 관리에서 제품 관리로 초점 전환
프로젝트 관리는 조직이 계획적이고 의도적인 방식으로 미래를 어제와 다르게 만드는 방법이다. 제품 관리는 기업의 제품 또는 제품군 중 하나의 발전을 관리하여 시장의 매력을 유지하고 강화하는 접근법이다.

IT 제품 관리는 애자일 세계에서 벗어나 비즈니스 제품 관리와 느슨하게 연결되어 있다. 비즈니스 기술 또는 애플리케이션 포트폴리오의 일부 부분의 매력을 향상시키는 데는 한계가 있지만, IT 제품 관리는 그렇지 않다. 그것은 책임과 의사결정 권한을 확립하는 것에 관한 것이다.

제품 관리가 프로젝트 관리보다 더 나은 것은 말할 것도 없고 흥미롭게 만들 만큼 충분히 다른가?

아마 아닐 것이다. 그것은 잘못된 이분법에 가깝다.

원문보기:
https://www.ciokorea.com/news/288847#csidx9ea78b9d0422939b0ce345a4e40be9e