PM이 ‘기술 부채’ 감소에 기여하는 방법
기술 부채 해결 및 예방을 위한 7가지 팁
원문: How Product Manager Can Help Reduce Technical Debt
프로덕트 매니저가 기술 부채(Technical Debt) 감소 및 예방을 위해 정리된 글이 있어 요약해보았습니다. 글을 정리해보니 원문 저자가 비슷한 말을 반복하는 인상이 일부 들었습니다.
하지만 제가 인상적이었던 내용은 PM이 된다는 것은 task와 timeline 사이에서 콘텍스트 전환에 대한 끊임없는 싸움이란 내용이었습니다. 기술 부채도 미리 타임라인을 계획하여 하나 하나 쳐나가면 좋지만, 현실은 그렇지 못하고 새롭게 우선순위가 부여되는 혹은 운영성 이슈로 인해 발생하는 task의 연속입니다.
저자는 이와 같은 상황에서 열린 질문(open questions)을 통해 문제점에 대하여 화두를 던지고, 구성원과 함께 솔직하게 문제의 본질에 대해 접근할 것을 제안하고 있습니다.
가트너(Gartner)의 2019년 프로덕트 매니저 대상 설문조사에 따르면 제품이 일정대로 출시하는 경우는 55% 임. 45%에 해당하는 출시가 연기된 제품의 20%가 프로덕트의 내부 목표를 달성하지 못함
제품 출시 연기(on-time delivery)에 영향을 미치는 다양한 변수가 존재함(예: 런치 프로세스 부재, 버그·오류 등으로 인한 제품 개발 지연, 고객 요구사항 부합 실패, 제품 품질).
이러한 변수 외에 제품 출시 연기에 영향을 미치는 요소는 기술 부채(Technical Debt)도 있음. 기술 부채는 개발자의 사기를 떨어뜨리고, 업데이트되지 않은 각종 오류는 고객 불만족으로 이어짐. 고객은 부정적 리뷰를 남기고, 이로 인해 마케팅팀은 어려움을 겪음. 불안정한 시스템 아키텍처는 새로운 기능 출시를 지연시키고, 이는 세일즈 사이클에 영향을 미침.
아래는 기술 부채 감소 및 예방을 위한 7가지 전략을 담고 있음
Create alliances
프로덕트 매니저의 중요한 역할 중에 하나는 기술 리더, CTO, 부서 리더들과 강력한 관계 구축
가트너 설문조사에 따르면 내부 이해관계자와 협업 개선을 중요하게 보는 프로덕트 매니저의 78%가 제품 실패 비율(product failure rates)이 낮은 것으로 확인
테크 리드(tech lead)와 정기적으로 대화를 나누고, 회사 내의 기술 부채 현황을 공유하고, 이를 해결하기 위한 약속을 얻어내도록 노력 필요함
기술 부채 해결과 관련된 핵심 이해관계자가 기술 부채에 대하여 부담을 느끼지 않도록 해야 함. 기술 부채 해결이 제품, 회사 및 고객 모두에게 긍정적인 의미를 가진다는 점을 강조함
경영진에게 기술 부채 해결에 대하여 휴가 등과 같은 인센티브를 제공할 수 있도록 협의함
Bring technical debt out of the shadows
기술 부채는 피할 수 없음. 제품의 일부일 수밖에 없음
기술 부채를 정기적으로 업데이트할 수 있는 액션 아이템 계획해야 함
개발자를 문제 해결에 참여시키고 기술 부채 해결을 위한 우선순위 설정해야 함
코드 스프린트 내에서 작업하는 것을 선호하는가? 관련하여 긴 시간을 부여하는 것을 선호하는가? 누가 기술 부채의 관련해서 무엇을 책임질 것인가? 개발 담당자의 workload는 어떤가? 추가 멤버가 필요하가?(임시적이라도?)
Ask the hard questions
솔루션 사용을 보류할 전략적 이유가 있습니까? (현재 사용 중인 특정 소프트웨어의 업그레이드 관련)
당장 수정할 필요가 없는 기술적 부채가 존재하나요? (오래된 버전의 제품)
이 코드를 수정하려면 얼마나 많은 작업이 필요한가요?
추후에 이 코드를 수정할 수 있나요?
해당 기술 부채 수정 담당자는 누구며, 관련 일정은 어떻게 되나요?
기술 부채와 관련된 일정이 다른 제품 출시 계획 및 기능 업데이트에 영향을 미칠 수 있나요?
이 기술 부채를 수정하지 않으면 현재 고객 및 이후 버전에 어떤 영향이 있나요?
향후 리팩토리 작업 관련해서 필요한 것이 무엇인가요?
제품 관리자가 된다는 것은 task와 timeline 간의 콘텍스트 전환에 대한 끊임없는 싸움임. 기술 부채 해결은 strategy와 commitment 관점에 볼 수 있지만, 먼저 문제의 현실을 확인해야 함. 제품 출시를 지연시키는 코드를 예로 든다면, 이상적인 세상에선 당신의 조직은 기술 부채의 액션 아이템을 정리하고 점진적으로 해결할 것임. 하지만 이와 같이 대응할 수 없는 현실에선 열린 질문(open questions)을 한다면 문제의 범위, 영향 범위에 대해 정직하고 집요하게 이해할 수 있고 한 단계 나아가기 위한 대화를 시작할 수 있음.
Embed technical debt remediation into your roadmap
로드맵 타임라인에 기술 부채 해결을 포함해라
태스크, 버그 수정, 코드 리뷰, 유지보수와 같이 기술 부채 관련 작업과 시간을 할당하여 강력하고 회복탄력성을 갖춘 제품을 구축함
개발자와 팀 멤버들이 product loop의 일부라고 느낄 수 있도록 로드맵을 최대한 공개하고 가시적으로 만들어라
로드맵은 유연하고 변경 가능해야하 함. 하지만 기술 부채에 대응할 수 있는 hard deadline도 포함해야 함
모든 것이 리팩토링이 필요한 것이 아님. 목표는 이번 스프린트, 월별, 분기 단위로 향후 작업할 코드 베이스에 있어 기술 부채와 향후 작업의 교차로(기술 부채 대응 범위)를 확인하는 것임
교차로에서 빚을 갚아야 한다, 교차로 밖이 아닌...(Pay off the debt in that intersection, but not outside of it.)
Make KPIs that reference technical debt
기술 부채 해결을 조직의 목표로 삼아야 함
기술 부채 관련 제품 성능 및 제품 개발 속도 KPI를 설정해야 함
만일 회사가 Net Promoter Score(NPS)로 고객의 충성도를 측정한다면, 이 지표에 제품 수정 지연, 버그 등과 관련된 고객 피드백이 포함될 수 있음.
Consider how to prevent technical debt
테크 리드(tech lead)와 향후 기술 부채를 줄이기 위해 어떤 전략을 프로젝트 개발 프로세스에 포함시킬 수 있는지 검토함
멘토링, 팀 교육(team training), pair programming 포함될 수 있음
Be scrupulous about documentation
일부 팀은 언제든지 필요할 때 코드 수정을 진행할 수 있는 기회주의적 리팩토링(opportunistic refactoring) 개발 문화를 보유하고 있으나, 이는 워크로드가 많은 피크 타임에 현실적이지 못한 방식으로 보임
기술 부채 관련 문서화 필요 - 정기적으로 참조하여 액션을 취할 수 있는 살아있는 문서여야 함(living doucument)
팀 구성원 변경에 따른 인수인계를 고려하여 중요함
Giphy제가 발행하는 뉴스레터입니다. 패션 서비스에 관심 있으신 분들께서는 아래 뉴스레터 링크에서 구독 부탁드립니다 :)
