[PGF 1기-김재환] 인스파이어드 사전 과제
작성자
- 김재환김
과제
제출
모임
참석
1.
PO/PM의 R&R
: 현재 자신이 속한 조직에서 부여된 PO/PM의 역할과 책임을(R&R) 설명해 주세요. 그리고 인스파이어드에서 정의한 이상적인 PO/PM의 R&R과는 어떤 차이가 있나요? 이 차이가 발생하는 원인이 무엇 때문이라 생각하는지 의견을 남겨주세요
→ 의견:
현재 제가 조직 내에서 수행하고 있는 역할은 개발하고 있는 묘원플랫폼 추모365에 대한 PM역활뿐만 아니라, 우즈벡 사마르칸트 글로벌 아웃소싱, 뷰티샵 및 일본 오사카 벌초 관련 유통산업 진출을 위한 비즈니스 전략 수립, 3월 묘원협회 세미나 준비 및 기존 거래 묘원 대응 등 대외 협력 및 영업까지 바운더리가 넓은 상황입니다.
책에서 정의하는 이상적인 PM은 제품이 '가치 있고, 사용 가능하며, 실현 가능한지'를 확인하는 '제품 발견(Discovery)' 활동에 집중해야 한다고 내용으로 봤을 때, 현재 제가 맡은 역활과 책이 제시하는 모델 사이에는 '비즈니스 관리와 제품 관리의 혼재'라는 부분에서 간극이 발생합니다. 이러한 간극이 발생하는 원인은 하기와 같이 나열해봤습니다.
첫째, 도메인의 복합성 때문입니다. '추모365'는 소프트웨어뿐 아니라 키오스크, 길찾기 앱에서의 지리 정보 정합성 확인 등 하드웨어와 현장 인프라가 긴밀히 결합된 서비스이기에 기획자가 하드웨어적인 부분까지 예측해야 합니다.
둘째, 조직의 성장 단계에 따른 특성입니다. 현재는 핵심 인력이 다각도의 역할을 분담해야 하는 스타트업형 연구 조직이기에 전문화된 분업보다는 속도감 있는 통합 관리가 우선시되고 있습니다.
셋째, 글로벌 신시장 개척 업무가 병행되고 있기 때문입니다. 우즈벡, 일본 지사 진출과 같은 전략 업무는 IT제품 개발 외 다른 제품(하드웨어 또는 소프트웨어) 개발 기획을 상황에 맞게 유동적으로 변화시켜야 하므로 PM이 다양한 업무 구축에 많은 리소스를 할애할 수밖에 없는 구조입니다. 엄밀히 말하면 PM 업무 외 업무가 매우 많은 상황입니다.
2.
PMF 검증을 위한 MVP
: 진행했던 프로젝트 중 아이디어 검증 과정을 통해 PMF를 목표로 MVP를 정의해 구축 출시 후 단계별로 제품을 성장시켜 본 적이 있다면 그 과정과 결과를 공유해 주세요. 만약 PMF와 MVP를 적용해 본 적이 없다면, 어떻게 아이디어를 검증하고, 출시 스펙을 결정했는지, 그리고 그 결과는 어떠했는지 공유해 주세요.
→ 의견:
지금 속해있는 회사는 제가 25년 8월달부터 합류하고 개발자 1명이 5월부터 입사하여 혼자 개발을 진행하던 상황이기에 실상은 MVP 모델이 만들어지고, 저 또한 IT 업계는 PM경력이 전무하기에 배워가며 산출물을 만들어나가야하는 상황이었습니다. 데이먼님의 코칭을 받으면서도, 주위 IT PM 경력자에게 실제 산출물을 보며 조언을 들음에도, 실제 사수가 없는 상황에서는 신입이나 마찬가지인 상황이기에 산출물을 만들려고 모니터 앞에 앉으면 머리가 하애지는 경험이 앞서게 되었습니다.
다만 '추모365' 프로젝트 내 길찾기 앱을 개발하며 지리데이터를 수집하는 업무에 대해서는 위 주제에 비슷한 아이디어를 검증하는 단계를 거치고 있습니다. 단순히 사무실에서 기획하는 대신, 직접 거래하고 있는 묘원 현장을 방문하여 GPS 4꼭지점 좌표를 측정하고 QGIS 프로그램을 통해 수집 테스트를 진행했습니다. 이는 산악 지형이라는 특수한 환경에서 서비스가 기술적으로 실현 가능한지를 사전에 검증하여 MVP의 핵심 기능을 정리하는 과정이었습니다. 다만 이것 또한 향후 지리 정보를 오버레이 시키는 과정 중 오류가 확인되어, 계속 다른 가정을 설정하고 있는 단계입니다.
3.
프로덕트 구축/개선 프로세스
: 현재 조직의 프로덕트를 구축/개선하는 과정과 인스파이어드에서 소개하는 이상적인 과정과 어떤 차이가 있나요? 애자일 방법론을 경험해 보신적이 있다면 어떤 장점과 단점이 있었는지 공유해 주세요.
+(옵션) 회사의 제품 구축 프로세스와 체계를 구축하는 시점은 언제부터 필요할까요?
→ 의견:
먼저 저희 회사의 사업 시작은 석재 제조, 무역이라는 1차산업 중에서도 원초적인 사업을 모토로 운영하는 부분에서 일반적인 IT회사가 사용하는 툴을 구독하는 것조차 결재받기가 매우 힘들고, 겨우겨우 Notion, Figma 등을 결제하여 협업 시스템을 운영하고 있습니다. 그것마저도 노션 계정 한 개, 피그마 계정 한 개로 운영하고 있는 실정이고, Flow 같은 저렴한 협업시스템도 도입하는데 C레벨을 납득시키기가 매우 힘든 상황입니다.
게다가 본저에서 언급하는 '엔지니어링 리소스 투입 전 사용자 테스트를 통한 가치 검증' 단계가 명시적으로 분리되어 있지 않다는 점은 이상적인 프로세스와 간극이 많이 발생하는 상황입니다. 현재는 기획을 먼저 하기보다는 개발자가 바로 개발로 들어가는 실정이라, 실제 배포 후에야 수정을 필요로 하는 리스크를 안고 있습니다.
그러기에 저희 회사는 애자일 방법론은 실정이 맞지가 않고, Damon님과 코칭 과정 중 들었던 내용대로 워터폴 방식이 맞는 상황입니다. 애자일 방법론을 적용시키기 위해서는 먼저 C레벨의 임원진하고 개발 방향이 협의가 되어야 하는데 사실상 연구소 자체적으로 업무를 하고 있는 상황이라, 이 부분에서 다른 조직과의 협업 또한 많은 애로사항이 있는 상황입니다.
+(옵션) 프로세스도 물론 필요하나, 무엇보다 먼저 실제 커리어를 보유한 기획자, PM담당자가 필요한 상황입니다. 그 다음 프로세스를 도입한다면, 최소한 Flow 같은 최소한의 툴은 필요한 것으로 예상합니다.