2020.07.07

칼럼ㅣ백로그 관리부터 정렬까지··· 프론트라인 관리자가 알아야 할 것

Dave Mangot | CIO
프론트라인 관리자가 되기란 쉽지 않다. 특히 ‘엔지니어’에서 ‘프론트라인 관리자’로 승진한 경우라면 깨닫는 사실이 있다. 사실상 승진한 것이 아니라 완전히 다른 업무를 맡게 됐다는 것이다. 이 전환에서 가장 어려운 과제는 엔지니어들의 요구를 수용하면서도 기업을 대표하는 역할을 해내야 한다는 점이다. 
 
ⓒGetty Images

백로그(Backlog)
조직 구성원이라면 누구나 기업의 니즈를 이해해야 한다. 프론트라인 관리자가 기업을 대표하는 역할이라고 생각할지도 모른다. 하지만 프론트라인 관리자만 ‘그런 사고방식’을 가져서는 안 된다. 엔지니어의 임무는 단순히 코드 작성이 아니다. 바로 기업의 니즈 해결이다. 2019 데브옵스 현황(State of DevOps) 보고서에 따르면 소프트웨어를 잘 전달하는 조직은 목표를 달성할 가능성이 2배 이상 높다. 

즉 기업의 니즈에 부응하고자 하는 사고방식이 조직 전반에 스며들어 있어야 한다. 그러나 만약 비즈니스 요구가 많다면? 해야 할 일이 많다면? 무엇부터 먼저 해야 하는지 어떻게 알 수 있을까? 

애자일 소프트웨어 개발을 하고 있는 팀이라면 그 해답은 백로그에서 찾을 수 있다. ‘백로그’란 한 팀이 일정 기간 또는 일정 시간 안에 해야 할 모든 업무를 작성한 문서이다. 이를테면 업무 개선 아이디어부터 제품 개발 관련 업무, 회고, 학습 리뷰, 사후 분석까지 모두 백로그에 들어간다. 이로 인해 백로그가 엄청나게 길어질 수 있다. 그렇다면 어떻게 해야 할까?

포기(Give up)
여기서의 ‘포기’는 두 손 들고 패배를 선언하면서 물러나라는 뜻이 아니다. 백로그 내의 모든 업무를 완수하겠다는 생각을 팀 차원에서 포기해야 한다는 뜻이다. 모든 아이디어, 모든 프로젝트가 백로그에 포함되기 마련이다. 그러나 우선순위를 비롯해 기술, 계획은 모두 변화한다. 무한한 자원과 시간이 있지 않는 한, 결코 백로그에 있는 모든 업무를 완료할 수 없다. 즉 첫 번째 단계는 모든 업무를 해내겠다는 생각을 포기하는 대신 기업과 팀에 가장 중요한 업무에 집중하는 것이다. 그러한 업무는 대체로 동일하다. 

우선순위
‘IBM 제품을 구매해서 해고된 사람은 아무도 없었다(No one ever got fired for buying IBM)’라는 말이 있다. 이처럼 중요한 업무를 한다고 해고될 사람은 아무도 없다. 프론트라인 관리자는 종종 백로그 우선순위를 설정하는 업무를 맡는다. 비즈니스 요구 사항을 파악하고 그에 따라 백로그 내 업무의 우선순위를 설정하는 것이다. 이를 통해 엔지니어는 다음에 할 작업이 무엇인지 문의하지 않아도 된다. 우선순위가 설정된 백로그가 투명하게 공개돼 있기 때문이다. 투명성(transparency)에 초점을 두는 것은 애자일 개발의 기본적인 부분이다. 

한편 중요한 업무를 처리하는 도중에 더 많은 업무를 수행해야 한다면? 더 많은 인력을 고용해야 하는지 아니면 업무와 관련해 뭔가 바꿔야 하는지를 스프레드시트를 통해 확인할 수 있다. 필자의 ‘스프레드시트를 문제로 만들어라(Make it a spreadsheet problem)’라는 이전 기사에서 논의한 것처럼 말이다. 

우선순위는 여러 가지 이유로 바뀔 수 있다. 미크 커스텐 박사는 저서 ‘프로젝트 투 프로덕트(Project to Product)’에서 4가지 다른 종류의 업무에 대해 이야기했다.

• 기능(feature)
• 결함(defect)
• 위험(risk)
• 채무(debt)

만약 주요 제품 및 서비스 출시를 준비 중이라면 기능에 우선순위를 둘 가능성이 크다. 중요한 감사나 인증을 준비하고 있다면 아마도 위험을 우선시할 것이다. 웹사이트 안정성에 문제가 있다면 결함과 채무를 우선순위로 설정할 확률이 높다. 기업의 우선순위는 주 또는 해마다 달라질 수 있지만 소속 팀과 기업의 우선순위가 정렬될 수 있도록 하는 것은 프론트라인 관리자의 책임이다. 

절충
프론트라인 관리자가 기업 전반에서 일어나는 모든 일을 안다면 좋겠지만 그도 인간이다. 개인이 유지할 수 있는 사회적 관계의 수가 한정된다는 ‘던바의 숫자(Dunbar's number)’에서 알 수 있듯 프론트라인 관리자가 모든 것을 알기란 불가능하다. 

게다가 시드니 요시다 컨설팅이 제시한 '정보 빙산 이론(information iceberg theory)'에 따르면 팀 리더는 프론트라인 관련 문제의 74% 밖에 인지하지 못한다. 더 위로 올라갈 경우 누락되는 정보가 많다.

그 때문에 팀 회의에서 관리자가 제대로 우선순위가 정립된 백로그는 어떤 모습일지 의견을 듣고, 논의하고, 절충하는 과정이 필요하다. 그렇다고 해서 관리자가 미팅 전에 모든 업무를 검토하고, 이를 다른 관리자에게 확인하는 등의 일을 하라는 것은 아니다. 질문에 답변할 수 있고 회의가 원활하게 진행될 수 있도록 필요한 정보를 준비해서 회의에 참여해야 한다. 엔지니어들은 회의로 시간 보내는 것을 선호하지 않기 때문이다. 

‘스크럼 애자일 소프트웨어 개발(Agile Software Development with Scrum)’이라는 책에서 인용된 닭과 돼지 이야기처럼 (여기서 돼지는 팀원, 닭은 비 팀원을 의미한다.) 오직 ‘돼지’만이 시스템의 진정한 상태를 알고 있기 때문에 관리자는 이러한 회의에 유연하게 접근할 필요가 있다. 

정렬 
지금까지 엔지니어와 관리자 양쪽 모두 비즈니스 요구를 이해하고 그에 따라 의사결정을 내리는 것이 얼마나 중요한지 이야기했다. 그렇다면 이러한 사고방식이 자연스럽게 정착된 업무 환경은 어떻게 조성할 수 있을까? 

많은 기업이 어떤 방식으로든 ‘정렬’을 한다. 명칭은 OKR부터 V2MOM, MBO에 이르기까지 매우 다양한데, 그 목적은 기업의 목표와 구성원의 목표를 정렬하는 것이다. 

이를테면 필자가 재직했던 세일즈포스에는 ‘V2MOM’이란 목표 정렬 툴이 있다. V2MOM은 비전(Viosion), 가치(Value), 방법(Methods), 장애물(Obstacles), 생산성 지표(Metrics)를 의미한다. 매년 세일즈포스 CEO 마크 베니오프가 본인의 V2MOM을 발표하면, 경영진이 베니오프의 목표 달성을 지원하는 자신들의 V2MOM을 공개했다. 그리고 그 아래 직원들이 이런 식으로 계속 V2MOM을 정해서 말단 직원까지 도달하면 모든 구성원의 비전을 기업이 나아가고자 하는 방향에 부응하도록 정렬할 수 있다. 

어떤 방법을 선택하든 혹은 기업 규모가 어떻든 ‘정렬’은 경영진으로 하여금 방향 설정은 물론 직원들이 한마음으로 전진하는 조직을 구성할 수 있도록 지원한다. 따라서 팀원들과 이러한 계획을 진행하는 것이 프론트라인 관리자의 일이다. 본인의 목표를 공개할 뿐만 아니라 팀원들과 목표가 일치되는지 확인해야 한다. 또한 우선순위를 파악하여 목표와 관련해 최대한 적절한 의사결정을 내릴 수 있도록 해야 한다. 

결론
프론트라인 관리자가 되기란 쉽지 않다. 관리자 역할을 수행하는 동시에 실제 업무가 진행되는 곳과 가까이 있기 때문이다. 기업의 명확한 방향성이 없다면 프론트라인 관리자가 우선순위 설정부터 목표 수정, 신규 계획까지 모든 것을 조율해 나가기가 어려울 수 있다. 만약 프론트라인 관리자들이 현업의 가장 중요한 니즈를 전달하는 데 초점을 맞춘다면 그들은 항상 옳은 일을 하고 있을 것이고 본인의 역할에서 성공할 확률이 높아질 것이다. 

* Dave Mangot는 컨설팅 업체 망고테크(Mangoteque)의 수장으로, 세일즈포스, 케이블앤와이어리스, 솔라윈즈와 같은 기업에서 데브옵스 전환과 운영 효율화 달성을 성공적으로 이끌었다. ciokr@idg.co.kr



2020.07.07

칼럼ㅣ백로그 관리부터 정렬까지··· 프론트라인 관리자가 알아야 할 것

Dave Mangot | CIO
프론트라인 관리자가 되기란 쉽지 않다. 특히 ‘엔지니어’에서 ‘프론트라인 관리자’로 승진한 경우라면 깨닫는 사실이 있다. 사실상 승진한 것이 아니라 완전히 다른 업무를 맡게 됐다는 것이다. 이 전환에서 가장 어려운 과제는 엔지니어들의 요구를 수용하면서도 기업을 대표하는 역할을 해내야 한다는 점이다. 
 
ⓒGetty Images

백로그(Backlog)
조직 구성원이라면 누구나 기업의 니즈를 이해해야 한다. 프론트라인 관리자가 기업을 대표하는 역할이라고 생각할지도 모른다. 하지만 프론트라인 관리자만 ‘그런 사고방식’을 가져서는 안 된다. 엔지니어의 임무는 단순히 코드 작성이 아니다. 바로 기업의 니즈 해결이다. 2019 데브옵스 현황(State of DevOps) 보고서에 따르면 소프트웨어를 잘 전달하는 조직은 목표를 달성할 가능성이 2배 이상 높다. 

즉 기업의 니즈에 부응하고자 하는 사고방식이 조직 전반에 스며들어 있어야 한다. 그러나 만약 비즈니스 요구가 많다면? 해야 할 일이 많다면? 무엇부터 먼저 해야 하는지 어떻게 알 수 있을까? 

애자일 소프트웨어 개발을 하고 있는 팀이라면 그 해답은 백로그에서 찾을 수 있다. ‘백로그’란 한 팀이 일정 기간 또는 일정 시간 안에 해야 할 모든 업무를 작성한 문서이다. 이를테면 업무 개선 아이디어부터 제품 개발 관련 업무, 회고, 학습 리뷰, 사후 분석까지 모두 백로그에 들어간다. 이로 인해 백로그가 엄청나게 길어질 수 있다. 그렇다면 어떻게 해야 할까?

포기(Give up)
여기서의 ‘포기’는 두 손 들고 패배를 선언하면서 물러나라는 뜻이 아니다. 백로그 내의 모든 업무를 완수하겠다는 생각을 팀 차원에서 포기해야 한다는 뜻이다. 모든 아이디어, 모든 프로젝트가 백로그에 포함되기 마련이다. 그러나 우선순위를 비롯해 기술, 계획은 모두 변화한다. 무한한 자원과 시간이 있지 않는 한, 결코 백로그에 있는 모든 업무를 완료할 수 없다. 즉 첫 번째 단계는 모든 업무를 해내겠다는 생각을 포기하는 대신 기업과 팀에 가장 중요한 업무에 집중하는 것이다. 그러한 업무는 대체로 동일하다. 

우선순위
‘IBM 제품을 구매해서 해고된 사람은 아무도 없었다(No one ever got fired for buying IBM)’라는 말이 있다. 이처럼 중요한 업무를 한다고 해고될 사람은 아무도 없다. 프론트라인 관리자는 종종 백로그 우선순위를 설정하는 업무를 맡는다. 비즈니스 요구 사항을 파악하고 그에 따라 백로그 내 업무의 우선순위를 설정하는 것이다. 이를 통해 엔지니어는 다음에 할 작업이 무엇인지 문의하지 않아도 된다. 우선순위가 설정된 백로그가 투명하게 공개돼 있기 때문이다. 투명성(transparency)에 초점을 두는 것은 애자일 개발의 기본적인 부분이다. 

한편 중요한 업무를 처리하는 도중에 더 많은 업무를 수행해야 한다면? 더 많은 인력을 고용해야 하는지 아니면 업무와 관련해 뭔가 바꿔야 하는지를 스프레드시트를 통해 확인할 수 있다. 필자의 ‘스프레드시트를 문제로 만들어라(Make it a spreadsheet problem)’라는 이전 기사에서 논의한 것처럼 말이다. 

우선순위는 여러 가지 이유로 바뀔 수 있다. 미크 커스텐 박사는 저서 ‘프로젝트 투 프로덕트(Project to Product)’에서 4가지 다른 종류의 업무에 대해 이야기했다.

• 기능(feature)
• 결함(defect)
• 위험(risk)
• 채무(debt)

만약 주요 제품 및 서비스 출시를 준비 중이라면 기능에 우선순위를 둘 가능성이 크다. 중요한 감사나 인증을 준비하고 있다면 아마도 위험을 우선시할 것이다. 웹사이트 안정성에 문제가 있다면 결함과 채무를 우선순위로 설정할 확률이 높다. 기업의 우선순위는 주 또는 해마다 달라질 수 있지만 소속 팀과 기업의 우선순위가 정렬될 수 있도록 하는 것은 프론트라인 관리자의 책임이다. 

절충
프론트라인 관리자가 기업 전반에서 일어나는 모든 일을 안다면 좋겠지만 그도 인간이다. 개인이 유지할 수 있는 사회적 관계의 수가 한정된다는 ‘던바의 숫자(Dunbar's number)’에서 알 수 있듯 프론트라인 관리자가 모든 것을 알기란 불가능하다. 

게다가 시드니 요시다 컨설팅이 제시한 '정보 빙산 이론(information iceberg theory)'에 따르면 팀 리더는 프론트라인 관련 문제의 74% 밖에 인지하지 못한다. 더 위로 올라갈 경우 누락되는 정보가 많다.

그 때문에 팀 회의에서 관리자가 제대로 우선순위가 정립된 백로그는 어떤 모습일지 의견을 듣고, 논의하고, 절충하는 과정이 필요하다. 그렇다고 해서 관리자가 미팅 전에 모든 업무를 검토하고, 이를 다른 관리자에게 확인하는 등의 일을 하라는 것은 아니다. 질문에 답변할 수 있고 회의가 원활하게 진행될 수 있도록 필요한 정보를 준비해서 회의에 참여해야 한다. 엔지니어들은 회의로 시간 보내는 것을 선호하지 않기 때문이다. 

‘스크럼 애자일 소프트웨어 개발(Agile Software Development with Scrum)’이라는 책에서 인용된 닭과 돼지 이야기처럼 (여기서 돼지는 팀원, 닭은 비 팀원을 의미한다.) 오직 ‘돼지’만이 시스템의 진정한 상태를 알고 있기 때문에 관리자는 이러한 회의에 유연하게 접근할 필요가 있다. 

정렬 
지금까지 엔지니어와 관리자 양쪽 모두 비즈니스 요구를 이해하고 그에 따라 의사결정을 내리는 것이 얼마나 중요한지 이야기했다. 그렇다면 이러한 사고방식이 자연스럽게 정착된 업무 환경은 어떻게 조성할 수 있을까? 

많은 기업이 어떤 방식으로든 ‘정렬’을 한다. 명칭은 OKR부터 V2MOM, MBO에 이르기까지 매우 다양한데, 그 목적은 기업의 목표와 구성원의 목표를 정렬하는 것이다. 

이를테면 필자가 재직했던 세일즈포스에는 ‘V2MOM’이란 목표 정렬 툴이 있다. V2MOM은 비전(Viosion), 가치(Value), 방법(Methods), 장애물(Obstacles), 생산성 지표(Metrics)를 의미한다. 매년 세일즈포스 CEO 마크 베니오프가 본인의 V2MOM을 발표하면, 경영진이 베니오프의 목표 달성을 지원하는 자신들의 V2MOM을 공개했다. 그리고 그 아래 직원들이 이런 식으로 계속 V2MOM을 정해서 말단 직원까지 도달하면 모든 구성원의 비전을 기업이 나아가고자 하는 방향에 부응하도록 정렬할 수 있다. 

어떤 방법을 선택하든 혹은 기업 규모가 어떻든 ‘정렬’은 경영진으로 하여금 방향 설정은 물론 직원들이 한마음으로 전진하는 조직을 구성할 수 있도록 지원한다. 따라서 팀원들과 이러한 계획을 진행하는 것이 프론트라인 관리자의 일이다. 본인의 목표를 공개할 뿐만 아니라 팀원들과 목표가 일치되는지 확인해야 한다. 또한 우선순위를 파악하여 목표와 관련해 최대한 적절한 의사결정을 내릴 수 있도록 해야 한다. 

결론
프론트라인 관리자가 되기란 쉽지 않다. 관리자 역할을 수행하는 동시에 실제 업무가 진행되는 곳과 가까이 있기 때문이다. 기업의 명확한 방향성이 없다면 프론트라인 관리자가 우선순위 설정부터 목표 수정, 신규 계획까지 모든 것을 조율해 나가기가 어려울 수 있다. 만약 프론트라인 관리자들이 현업의 가장 중요한 니즈를 전달하는 데 초점을 맞춘다면 그들은 항상 옳은 일을 하고 있을 것이고 본인의 역할에서 성공할 확률이 높아질 것이다. 

* Dave Mangot는 컨설팅 업체 망고테크(Mangoteque)의 수장으로, 세일즈포스, 케이블앤와이어리스, 솔라윈즈와 같은 기업에서 데브옵스 전환과 운영 효율화 달성을 성공적으로 이끌었다. ciokr@idg.co.kr

X