[일간 애자일#649](2/16) 애자일 적용 전략 등

  • 매일 애자일, 린, 조직문화, 협업, 리더십, 자기계발 등과 관련된 새로운 소식을 공유드립니다.
  • 소감, 동의, 반론 등을 댓글로 남겨주세요. 활발한 소통을 기대합니다.
  • 지난 기사는 [여기]에서 보실 수 있습니다

애자일 적용 전략

프로젝트 단위로 애자일 적용 방식에 대해 고민하는 것도 중요하나, 전사의 관점에서 애자일 적절한 적용 대상을 찾아야 할때도 있다. 이 경우 애자일 적용을 한다고 하면 이러한 반응을 보이는 경우가 대부분이다.

“명확한 적용 기준을 제시해주세요.”

이러한 반응을 보이는 사람들은 보통 애자일을 누군가에게 설득해야 하는 위치에 있거나, 스스로가 새로운 프로세스의 적용에 대해 부정적인 경우들일 가능성이 높다. 둘 중 어느 경우에나, 전략은 필요하다. 상황을 보다 객관적으로 판단하여 어떠한 방식으로 애자일을 적용할 지를 선택할 수 있는 체계가 필요하다. 천편일률적으로 기법 중심의 스크럼이나 XP를 적용할 수는 없다.

이러한 경험 때문에, 애자일을 상황에 맞게 적합하기 위해 우리는 3단계로 나누어 접근했다. 먼저 프로젝트의 특성을 분석했다. 프로젝트의 성격에 따라 이 프로젝트가 SI 구축형인가, 유지보수형인가에 따라 프로젝트 특성을 분리했다.

애자일 적용전략

두 가지를 비교해보면, SI 구축형은 일반적으로 납기, 업무 범위, 리소스 중 납기가 가장 중요하다. 그 다움으로 업무 범위, 리소스가 중요하다. SI 구축형은 약속한 날짜에 약속한 업무 범위를 구현하여 고객에게 전달해야만 성공한 프로젝트로 인지가 된다. 반면에 유지보수형은 정해진 리소스 안에서 할 수 있는 일의 양을 고객과 협상하여, 개별 건마다 정해진 리소스 기반으로 기간을 정하기에, 리소스 > 업무 범위 > 납기 순으로 중요도가 정리된다.

이 중요도를 먼저 파악하고 다음으로 프로젝트에 애자일 적용성을 평가했다. 애자일 적용성은 크게 7가지를 가지고 기준을 잡았다.

• 애자일 적용의지: 프로젝트 애자일 스폰서십을 본다.
• 고객 특성: 고객이 프로젝트 현장에 고객이 상주할 수 있는지, 쇼케이스에 대한 관심도가 높은지 또는 실제 만드는 기능과 비즈니스 시나리오에 대해 가진 도메인 지식의 깊이 등을 본다.
• 프로젝트 인력 특성: 전체 투입과 지원 형태, 풀 타임 인력 비율 등을 본다.
• 프로젝트 제약사항: 업무 범위에 대한 최초에 정해진 업무 범위를 무조건 다 만들라고 고객이 주장하는 상황인지, 상황에 따라 기존의 업무를 다른 것으로 변경 대체하는 것이 가능한지 여부 확인한다. 또한 무조건 기간을 맞춰 딜리버리 해야 하는지 고객과의 협상을 통해 계획의 변경이 가능하고, 고객이 추가 금액을 지불할 용의가 있는지 확인한다.
• 프로젝트 복잡도: 이해관계자의 복잡도 정도를 살피고, 타 시스템과의 의존성 정도, 프로젝트 투입 인력 규모를 12명 이하/50명 이하/50명 이상으로 나누어 프로젝트 규모를 파악한다.
• 아키텍처의 복잡도: 개발 시작 전 표준 아키텍처 수립이 가능한지, 개발을 지원하는 아키텍트의 역량을 본다.
• 프로젝트 수행환경: 단계를 합쳐 이터레이션이 가능한지 여부를 확인한다. 또한 조기부터 테스터를 투입하여 함께 일할 수 있는 정도를 확인한다.

이 7가지 항목을 기반으로 5점 척도화 하고, 이를 기반으로 점수가 높은 경우에는 순수 애자일 방식을, 점수가 중간인 경우는 워터폴과 애자일의 중간 정도를 제안하는 하이브리드 타입을, 점수가 낮은 경우는 애자일을 적용하 할 수 없다고 결론 지을 수 있게 했다.

원문: https://bit.ly/3pgDti8


좋은 PM은 “현재 진행 학습형”이다

“좋은 프로덕트/프로그램 매니저가 되기 위한 덕목이 무엇인가요?” 라는 질문을 구글창이나 초록창에 넣어보면 많은 전문가들의 대답은 이렇습니다. ‘커뮤니케이션 능력’, ‘리더십’, ‘우선순위 정하기’, ‘의견청취와 공감능력’, ‘프로세스 만들기’ 등 모두 중요한 귀한 덕목들입니다. 하지만 이런 덕목들은 새로운 것들도 아니고, 갖고 태어나는 능력은 더더욱 아닙니다. 오늘은 제 경험상 이런 덕목들보다 훨씬 중요한 것 한가지를 이야기해 볼까 합니다. 이 덕목은 훌륭한 PM이 될 뿐만 아니라 중요하고도 영향력 있는 차이를 만들 수 있습니다. 좋은 PM이 되기 위한 가장 확실한 한가지 덕목은 “좋은 PM은 늘 현재 진행 학습형”이어야 한다입니다.

‘현재 진행형’’이란 전통적인 방법은 매우 간단하지만 매우 파워풀 합니다. 즉각적이진 않지만, 무엇보다 효과적인 결과를 보여줍니다. 지루하게 보이지만, 경험한 이에게는 이만한 마법이 더 이상 없다는 것을 잘 압니다. 오늘의 ‘현재 진행 학습형’은 바로 꾸준함에 대한 이야기입니다. 그 꾸준함에도 ‘새로운 것을 배움’에 대한 꾸준함을 이야기할 것입니다.

제가 직무 타이틀을 프로덕트/프로그램 매니저로 바꿔 달고 업무를 시작한 것이 2006년이니 벌써 15년이나 흘렀습니다. 개발자-매니저를 거쳐 처음 이 새로운 역할을 시작하면서 저는 이 일이 지금까지 해 오던 일과 비교해서 쉽지 않을 것이라고 생각했지만 그만큼 배울 것이 많을 것으로 예상했습니다. 15년이 지난 지금, 훌륭한 프로덕트/프로그램 매니저(오너)가 되려면 지속적으로 무엇이던 간에 꾸준히 배우는 것을 두려워 하거나 거북해 하면 안된다는 것이 유일한 확신입니다. 매일 쏟아지는 새로운 기술, 뉴스, 경쟁업체의 동향 뿐만 아니라, 어느 경우엔 내가 평생 모르고 살았던 고객의 업무도 이해하고 공감해야 하는 경우가 있습니다.

내가 모르는 상황과 마주칠 때마다 좋은PM이라면 늘 솔직하게 “잘 모르겠습니다.”라는 겸손한 태도를 가져야 합니다. 하지만 중요한 사실은 같은 사실에 대해서 내일도 “잘 모르겠습니다”라는 대답은 허용될 수 없다는 사실입니다.

저에게는 부끄러운 일이나 중요하게 나누고 싶은 사실은, 제가 너무 자신 만만했던 순간마다 제품/서비스의 결과가 좋지 않았다는 것입니다. 자신감이라고 생각하며, 이 제품에 대한 모든 해답을 내 손안에 갖고 있다고 확신했을 때 저의 태도는 중요한 한가지를 건 무시하고 건너뛴것이 그 주 이유였습니다. 바로 그것은 제가 자신감이 없었고, 주위가 모두 깜깜하다고 느꼈던 때 불안감으로 매우 꼼꼼하게 행했던 ‘가정을 검증하는 프로세스’ 였습니다. 자신만만하던 저는 더 많은 의문을 갖지도 않았고, 질문을 하지도 않았습니다. 중요한 사실은 이런 경험은 저에게만 일어나는 것이 아니라 다른 PM에게도 일어나는 공통된 패턴이라는 사실을 알게 되었습니다. 지나치게 자신만만한 프로덕트/프로그램 매니저(오너)는 팀과 그 제품/서비스를 좋지 않은 결과로 이끌게 되는 경우를 너무나 많이 보고 경험하게 되었습니다.

성공적인 제품/서비스를 만들기 위해서는 많고도 꾸준한 배움이 필요합니다. 우리는 모든 해답을 가지고 있지 않다는 것을 매우 정상적으로 받아들일 필요가 있습니다. 하지만 그 해답을 가지고 않은 상황에서의 올바른 태도는 가만히 무슨 일이 일어나기를 기다리지 말고, 우리는 궁금해서 답을 찾고 학습을 시작해야 하는 것입니다. 매일 우리는 새로운 것을 배워야 하고, 하루가 끝날 무렵에 스스로에게 “오늘 나는 무엇을 배웠지?”라고 물어야 합니다. 만약 여러분이 그것에 대한 답을 쉽게 할 수 없다면. 당신은 어제의 PM보다 더 좋은 PM이 되지 못한 것입니다.

원문: https://bit.ly/3bd7Rom


PM이 ‘기술 부채’ 감소에 기여하는 방법

기술 부채 해결 및 예방을 위한 7가지 팁

원문: How Product Manager Can Help Reduce Technical Debt

프로덕트 매니저가 기술 부채(Technical Debt) 감소 및 예방을 위해 정리된 글이 있어 요약해보았습니다. 글을 정리해보니 원문 저자가 비슷한 말을 반복하는 인상이 일부 들었습니다.

하지만 제가 인상적이었던 내용은 PM이 된다는 것은 task와 timeline 사이에서 콘텍스트 전환에 대한 끊임없는 싸움이란 내용이었습니다. 기술 부채도 미리 타임라인을 계획하여 하나 하나 쳐나가면 좋지만, 현실은 그렇지 못하고 새롭게 우선순위가 부여되는 혹은 운영성 이슈로 인해 발생하는 task의 연속입니다.

저자는 이와 같은 상황에서 열린 질문(open questions)을 통해 문제점에 대하여 화두를 던지고, 구성원과 함께 솔직하게 문제의 본질에 대해 접근할 것을 제안하고 있습니다.

원문: https://bit.ly/3apwGP7


PM) 부실한 제품의 10가지 이유

실패하거나 취약한 제품에 대한 공통점

Table of Contents >

01 제품의 비전

02 고객이 주도하지 못하는 로드맵

03 지속적인 학습환경

04 사용자 경험에 대한 이해

05 시장과 고객에 대한 전문지식

06 기술 수준에 대한 고려

07 유기적인 협업

08 결과보다 데드라인에 집중

09 두려움 & 용기 부족

10 취약한 리더

성공하는 수많은 서비스들에 대한 분석은 많습니다. 그러나 실패하거나 약한 제품에 대한 분석은 쉽사리 찾기가 어렵기도 하고 분석을 하기에도 애매한 측면이 존재합니다. 모두가 다 아는 이야기들일 수 있으니까요. 오늘 글은 제품이 약한 이유에 대해 나름의 정리를 하는 시간입니다 약한 제품의 정의는 목표를 달성하지 못하고, 새로운 수익원 창출에 실패 성장을 이끌어 내는 데 있어 정해진 기간 내에 허용되는 리소스 범위 내에서의 달성 실패하는 경우입니다. 현재 만들고 계시는 제품이 약한 측면이 무엇일지 살펴보며 읽어 보시기를 권장드립니다. 시작합니다.

원문: https://bit.ly/3b81pPK


글쓴이: 정의의소

Agile Coach, Organizational Change Coach @Samsung Electronics 팟캐스트 MC : 새꿈사 (새로운 조직문화를 꿈꾸는 사람들)

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google photo

Google의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중