IT 프로젝트 중심적 접근법 대신 제품 기반적 접근법(product-based approach)에 주목하는 CIO들이 늘고 있다. 하지만 이는
2년 전, 스티븐 펄미즈는 프레시디오(Presidio)의 CIO로 임명됐다. 이후 그는 IT 부서가 일부 작업에는 워터폴(Waterfall) 개발 방법을 사용하고 다른 것들에는 애자일(Agile) 중심적 프로젝트 기반 접근방식을 적용하고 있음을 파악했다.
펄미즈는 이러한 양태가 걸림돌이 된다고 판단했다. 그는 “신속한 대응이 불가능했다. 솔루션을 개발할 즈음에는 관련성이 없을 수 있다. 현업 부문에서 필요로 하는 것을 더 신속하게 제공하기 위해 새로운 방법을 찾아야 했다”라고 말했다.
그 이후로 그는 IT 부서와 회사의 나머지 부서들이 일하는 방식을 바꾸려 시도했다. 먼저 CFO가 같은 시각을 갖고 있다는 사실을 알게 된 후 CFO와 우선적으로 협력했다. 그는 IT 인력 중 일부를 금융 부서 도구 또는 제품을 중심으로 하는 팀들로 재구성했고 금융 배경지식과 기술적 각각이 있는 제품 관리자를 고용했다.
그리고 새로운 팀이 재무 부서와 협업하여 신기능을 신속하게 반복적으로 제공하도록 하여 각종 요구를 신속하게 충족할 수 있도록 했다.
많은 CIO들이 비즈니스 요구를 해결하는 기술을 신속하게 개발하는 방법을 찾아나서고 있다. 그리고 해법으로 프로젝트가 아닌 제품 단위에 인력을 할당하는 시도에 주목하고 있다. 두 사고방식 사이의 차이점은 크며, 전환을 위해서는 많은 노력이 필요하다.
그럼에도 불구하고 여러 임원 컨설턴트, 비즈니스 자문가, 선두 CIO들은 조직이 경쟁력을 유지하기 위해서는 이런 변화가 필요하다고 주문하고 있다.
베인앤컴퍼니(Bain & Company)의 파트너이자 ‘올바른 애자일 방법론: 혼란 없는 전환(Doing Agile Right: Transformation Without Chaos)’의 공동 저자 스티브 베레즈는 “궁극적으로 생존하기 위해 필수적인 변화다. 왜냐하면 모든 산업의 기업들이 경쟁에서 살아남기 위해 기술 기반 혁신을 더 많이 추구해야 하기 때문이다”라고 말했다.
프로젝트가 아닌 제품 단위로 구분
제품 중심적 전달 경험이 있는 다른 기술 책임자들은 대개 프로젝트와 제품을 명확히 구분한다. DCL(Data Conversion Laboratory)의 CIO 티미 빌리츠키는 “프로젝트의 경우 어제의 아이디어를 실현하는 것이다”라고 설명했다.
그녀는 “고유한 프로젝트 서비스 또는 성과를 만들기 위해 하는 일시적인 노력”이라는 PMI(Project Management Institute)의 프로젝트에 대한 정의를 인용했다. 프로젝트는 시작과 끝이 명확하다고 말하면서 그녀는 프로젝트에 있어서 성공은 제 때에 예산 범위 내에서 완료되는 것이라고 덧붙였다.
하지만 프로젝트 중심적 접근은 IT와 비즈니스의 성공을 제한할 수 있다고 그녀는 지적했다. 빌리츠키는 “일정 및 예산 범위를 성공적으로 관리하더라도 결과가 이해관계자에게 유용하거나 유용하지 않을 수 있다. 이를 위해 여러 후속 프로젝트에서 유용한 결과물을 다시 제공해야 할 수 있다”라고 말했다.
그녀는 이어 “더 이상 프로젝트가 필요 없다는 뜻이 아니다. 프로젝트에 대한 마음가짐, 정의된 기간과 일시적인 팀 배정, 성공이 사전에 정의된 범위와 예산의 준수에 기초한다는 생각 등의 기준이 더 이상 성공의 요소가 아닐 뿐이다”라고 덧붙였다.
반면에 제품은 물품이나 서비스이며, IT의 경우 경계가 명확히 정의된 기능, 애플리케이션, 역량이다. 구체적인 사용자(이해관계자)가 있다. 그리고 지속적인 개선 기회가 있다. 쉽게 말해, 프로젝트는 끝이 있지만 제품은 지속적이다.
‘비즈니스 지향적 IT’
PCC(Plains Capital Company)의 프라임렌딩(PrimeLending) 부문 수석 기술 부사장 크리스 윌리엄스는 제품 중심적 방향성이 이런 이점을 어떻게 제공했는지 목격했다고 말했다.
윌리엄스가 2020년 8월 IT 책임자가 되었을 때 IT 부서는 이미 제품 접근방식으로의 변화를 시작한 상태였으며, 그는 이에 더해 제품 사고방식을 발전시켰다. 이제 그의 인력 중 상당수가 제품 팀(각각 특정 제품을 개발) 또는 단기 이니셔티브를 위해 협력하기 위해 유지되는 팀으로 조직화되어 있다.
그는 제품팀이 자급자족할 수 있으며 제품 소유자가 지휘하고 비즈니스 요구에 따라 새로운 기능을 지속적으로 제공하는 진정한 애자일 팀이라고 설명했다. 그는 “항상 제품을 위해 할 일이 있다”라고 밝혔다.
윌리엄스는 이런 제품팀의 사고방식이 프로젝트에 집중했던 IT 부서에서 보았던 것과는 다르다고 전했다. 제품팀의 경우 개인이 아니라 팀 전체가 제품의 성공 또는 실패를 좌우한다는 사실을 알고 있기 때문에 시너지 효과와 집단 정체성이 있다는 설명이다.
그는 “그들은 테스트 담당자, 개발자, 제품 소유자들 사이에서 질문하고 [부서의] 업무가 시작되기도 전에 이런 대화를 통해 사용자 스토리가 발전한다. 그래서 개발을 시작할 즈음에는 모두가 합심하게 된다”라고 말했다.
그는 “서로 손발이 척척 맞는다. 흐름에 따라 리듬을 타게 된다. 프로젝트처럼 한 동안 존재하다가 해체되는 과도기적인 구조에서는 훨씬 힘들다”라고 덧붙였다.
제품 접근방식 지지자와 사용자들은 윌리엄스의 관찰결과를 당연하게 받아들이곤 한다. 핀테크 기업 브로드릿지(Broadridge)의 기술 전문가이자 전 CIO 마크 쉘싱어는 “인프라 또는 아키텍처 또는 네트워크가 무엇인지보다는 사람들이 필요로 하는 것이 무엇인지 묻는 것이 중요하다. 내부 및 외부 고객들이 필요한 것을 얻도록 하는 것이 중요하다. 비즈니스에 적절한 시기에 적절한 제품을 개발하면 결국 고객과 사용자 모두 만족하게 된다. 이것이 비즈니스 지향적인 IT이다”라고 말했다.
제품 중심적 환경 구성하기
많은 CIO는 제품 사고방식의 가치를 알고 있으며 이 접근방식을 도입하고 있다고 컨설팅 기업 웨스트 먼로(West Monroe)의 제품 및 경험 연구소 상무이사 매트 존슨이 말했다. 하지만 소수만이 이 새로운 업무 방식으로 완전하게 전환하는 데 성공하며, 여전히 진행 중인 사람들이 훨씬 많다.
존슨은 “계획을 발표하고 스위치를 켠다고 되는 일이 아니다. 행동, 문화, 제품팀의 환경, 재정 지원의 변화가 중요하다”라고 말했다.
실제로, 이미 자리를 잡은 IT 부서에서 제품 중심적 환경을 새롭게 구성하기란 상당히 어렵다. CIO는 부서를 재구성하고 직원들이 새로운 방식으로 근무하도록 교육하면서 중단 없이 IT 서비스를 유지해야 한다고 전문 서비스 기업 가이드하우스(Guidehouse)의 IT 전략 활동을 주도하고 있는 파트너 로버트 맥나마라가 말했다.
또한 IT 부서와 역할을 재정의하고 팀들이 포트폴리오 안에서 필요한 모든 업무를 수행하기 위해 자급자족할 수 있는 스킬을 갖추도록 해야 한다고 그는 덧붙였다.
아울러 IT 부문 내에서 레거시 인프라 등이 존재하는 경우 융통성이 없어 팀에 할당할 제품을 분류하기가 더 어려워지기 마련이다. 이런 상황에서 추가적인 문제들이 출현할 수 있다.
맥나마라는 “새로운 거버넌스 구조가 필요하며 IT 운영 모델 전체를 다시 생각해야 한다. 그리고 IT와 고객이 협력하는 방식에 대한 고객의 기대치를 조정해야 한다. 따라서 운영 모델/거버넌스 및 의사결정과 조직화 방식이 중요한 것이다. 이 3가지 영역을 변화해야 한다”라고 말했다.
또한 팀에게는 업무의 우선순위를 설정하고 의사를 결정할 권한이 있고, 빠르게 실패하고 교훈을 얻는 한 실패에 대한 두려움이 없어야 한다.
베레즈는 제품 기반 접근방식으로 전환 시 성공의 가장 어려운 문제점은 IT 외부에 있기 때문에 CIO의 직접적인 통제를 벗어난다는 점이라고 지적했다. “해당 모델에 대한 임원진의 지원을 확보하기가 쉽지 않다”라고 그는 덧붙였다.
이 밖에 예산 책정 방식이 달라지는 점도 곤란한 지점이다. 프로젝트 범위를 벗어나지 않는 것이 아니라 일정 기간 동안 제품을 유지하도록 예산이 배정된다. 이로 인해 총 비용을 계산하는 방식이 달라진다.
결과적으로 비즈니스 리더뿐 아니라 보안, 법무, 준법감시 부서가 제품팀에 협력해야 하며, 인사 부서와도 협력하여 관리자보다는 팀 기여자와 팀 자체에 보상하는 인센티브를 구조화할 필요가 있다.
프로젝트와 프로덕트의 균형 맞추기
IT제품팀이 사업부에 신속하고 일정하며 지속적으로 가치를 제공하는 능력을 입증하면 임원에게 제품 사고방식의 중요성을 설득시키기가 더 쉬워질 것이다.
베레즈는 “특정 시점의 요구 또는 일시적인 요구가 아니라 고객 또는 비즈니스 부문의 지속적인 요구를 해결하는 효율적인 IT 조직이 출현하게 된다”라고 말했다.
하지만 프로젝트의 개념 전체를 무시해서는 안 된다고 그와 다른 전문가들이 말했다. 여전히 프로젝트 접근방식이 유효한 업무가 존재한다. ERP시스템을 교체하거나 인수한 회사를 통합하는 것 등이 그 예이다.
빌리츠키는 “[제품과 프로젝트] 사고방식과 각각의 장단점을 이해하고 현명하게 선택하는 것이 중요하다. 모든 것이 제품이거나 제품처럼 취급해서는 안 되지만, 그 결론에 도달하기 전에 잠재력을 신중하게 평가해야 한다”라고 말했다.
dl-ciokorea@foundryco.com
