260318 TIL

휘·2026년 3월 18일

🏃TIL

목록 보기

20/27

쥐깍쥐깍 사라져버린 시간 ... 내 시간 어디로?

직무스터디 3일차

만만하게 볼 날이 하루도 없다. 여유롭게 끝낼 수 있을거라 생각했던 스터디를 끝내고 나니 저녁시간이었다 (...)
오늘은 3일간의 리서치와 자료 정리를 모두 갈무리 한 날.
오늘도 역시나 양질의 리서치를 가득 들고 추려서 정리해준 팀원들 덕에 협업이 수월하게 진행됐다.
오늘의 큰 목표는 선정한 서비스에서 발생할 수 있는 문제를 정의하고 해결방안을 구상해보는 것 !

이전 2일 간의 스터디를 열심히 진행했기 때문에 큰 줄기의 흐름이 짜임새 있게 구성되어 있었고, 오늘은 그 마무리를 하는 날이었다.

문제정의를 하기 앞서, 어떤 식으로 문제 정의를 할 것인지에 대한 방향성을 먼저 잡아보았다.

Jira의 문제가 단순히 ‘사용하기 어렵다’일까? 그럼 왜 많은 기업이 그럼에도 불구하고 jira를 쓰고 있는가.→ 온보딩이 철저한 기업들.
jira의 기능과 강점은 차고 넘친다.
이러한 강점이 사용자에게 제대로 전달되지 않고 활용되지 못하기에 사용자는 ‘어려움’을 느끼는 것이 아닐까?
그 어려움은 구조적 문제로 볼 수 있지 않나?
사용자 여정 전반에서 지라를 사용하는 기준이 숨겨져 있다는 것.
온보딩이나 교육 없이는 알 수 없는 기준의 부족에서 발생하는 거 아닌가?
무슨 온보딩 전문 기업도 있던데. 그건 지라랑 사용자 사이에서 중개무역을 하는 거잖아, 그게 필요할 정도의 복잡한 사용성이라고 … 
해결방향을 새로운 기능을 추가하는 것 대신에 기존 구조의 기준을 세우고 구조와 데이터를 사용자가 이해하고 활용할 수 있도록 돕는 방향으로.

지라라는 서비스는 강점과 약점이 명확하게 나뉘어 있는 협업 툴. 그렇다면 새로운 기능에 대한 추가보다는 약점을 보완하는 것이 더 명확하게 사용자의 불만을 보완할 수 있을 것이라고 생각했다. 이 흐름을 바탕으로 이전 과제에서 설정했던 사용자 페르소나에 맞춰 문제정의를 진행했다.

이후 11시에 팀원들과 모여서 방향성 공유와 중간회의를 진행, 너무 세분화 되어있는 여정을 단순화 시키기로 결정하고 총 7단계의 여정을 4단계로 압축할 수 있었다. (유빈님의 아이디어 ㅎ.ㅎ)

시작 = 인식 + 유입
온보딩 = 초기 설정 + 프로젝트 생성
적응 = 할 일 등록 + 프로젝트 관리
운영 = 할 일 완료

하단에 내가 작성한 리서치를 공유한다.

문제정의

설정한 페르소나의 사용자 여정 단계와 페인포인트에 맞춰서 정의한다.

사용자 여정 단계

💡 인식 → 유입 → 프로젝트 생성 → 할 일 등록 → 프로젝트 관리 → 할 일 완료

💊 공통 pain point

초보 협업팀에게 jira는. 구조와 데이터를 제공하지만 그 구조를 어떻게 선택, 사용, 해석해야 하는지에 대한 기준을 제공하지 않아 업무 정의부터 실행, 개선까지 전 과정에서 비효율이 발생함

인식

⇒ 협업 경험이 없는 사용자에게 협업툴의 필요성과 선택 기준이 명확하지 않다

사용자 관점

협업툴이 왜 필요한 지 명확히 체감하지 못함

“좋다니까 써보는거지 뭐”

비즈니스 관점

jira의 강점이 초보 사용자에게는 직관적으로 전달되지 않음
→ 초기 인식 실패 시 부적합 사용자 유입 또는 이탈

데이터 관점
유입 채널 기능 페이지 조회 가입 전 이탈률

해결방안

사용자 유형별 가치 메시지 분리 : 신입 PM / 소규모 팀 타겟팅 메세지

실제 사용 시나리오 기반 콘텐츠 : “첫 프로젝트 이렇게 관리하세요”

유입

⇒ 다양한 기능이 있으나 초보 사용자에게는 어떤 기능이 핵심인지 판단하기 어렵다

사용자 관점

개발자 추천으로 선택했는데 왜 좋은지, 어떻게 설정해야하는지에 대해 이해하지 못함
→ 제품 강점에 대한 이해 부족

비즈니스 관점

제품 강점이 이해되지 않은 상태 유입 → 잘못된 기대 형성 → 초기 이탈 가능성 증가

데이터 관점
가입 완료율 초기 진입 후 이탈률

해결방안

가입 직후 사용자 유형 선택 → 역할 기반 온보딩 가이드 제공

초기 설정

“어떻게 시작하지?”
⇒ 어떤 구조를 선택해 활용해야 하는지에 대한 기준이 없다

사용자 관점

scrum / kanban 선택 기준 없음

설정이 부담되어 시작이 지연됨

비즈니스 관점

초기 설정 단계에서 막히면 activation의 실패로 이어짐

데이터 관점
프로젝트 생성 완료율 첫 이슈 생성까지의 시간

해결방안

질문 기반 온보딩 → 팀 유형, 프로젝트 성격 기반 자동 템플릿

유사 팀 추천 → “비슷한 팀은 이렇게 시작했어요”

설정 변경 가능성 명확히 안내 → 처음에 잘못 설정해도 변경할 수 있다는 안심

프로젝트 생성

“무엇을 해야하지?”
⇒ 프로젝트 생성 이후 사용자가 직접 다음 행동을 정의해야한다. (초기 사용의 어려움)

사용자 관점

보드는 있지만 무엇을 해야할 지 모름

협업 흐름을 직접 설계해야 하는 부담

비즈니스 관점

프로젝트 생성 이후 실제 사용으로 이어지지 않으면 activation의 실패로 이어짐

데이터 관점
프로젝트 생성 후 비활성 비율 첫 이슈 생성까지의 시간

해결방안

첫 액션 가이드 제공
이슈 생성 → 담당자 지정 → 상태 변경 등의 순서 안내

기본 구조 자동 생성
epic + 예시 task 자동 생성

할 일 등록

“업무를 어떻게 정의하지?”
⇒ 업무를 어떤 단위로 정의해야 하는지 기준이 없어 형식적으로 입력하게 된다.

사용자 관점

task / story 구분 기준 없음

필드 의미를 이해하지 못함

비즈니스 관점

이슈 생성은 단순입력이 아니라 제품 가치가 시작되는 핵심 행동

핵심 행동의 모호한 입력은 핵심 가치의 저하로 이어짐

데이터 관점
이슈 생성 수 필드 입력률 수정률

해결방안

이슈 생성 전 유형 선택
→ 작업 유형별 필드 자동 구성

이슈 템플릿 제공
→ 문제 / 목표 / 완료 조건 자동 삽입

이슈 쪼개기 가이드
→ 긴 작업 자동 감지 후 분할 제안

프로젝트 관리

“흐름이 어떻게 되는거지?”
⇒ 상태 사용 기준이 명확하지 않아 시간이 지나면서 의미가 불일치한다.

사용자 관점

워크플로우를 기본 3개 구조 이외에도 자유롭게 커스터마이징 가능함

그러나 각 상태에 대한 기준이 모호하거나, 상태 변경을 까먹는다면 시간이 지나면서 팀원마다 상태를 다르게 사용하게 됨

→ 동일한 상태라도 의미가 일관되지 않음

여러 이슈로 나뉘어져 있어 흐름 파악이 어렵고, 전체 흐름을 한눈에 바라보기 힘듦

비즈니스 관점

jira는 상태를 기반으로 구조화된 업무를 추적하고 협업 효율을 높이는 것이 핵심 가치
일관되지 않은 상태는 업무 추적의 신뢰도를 저하시킴

→ 워크플로우의 자유도가 높지만, 사용품질을 보장하지 못하면 핵심가치(추적, 관리)가 훼손됨

협업 데이터를 기반으로 흐름 추적이 가능한 도구여야하는데 제품의 기능이 사용자에게 제대로 전달되지 않고 있음

데이터 관점
상태 체류 시간 상태 전이 패턴 장기 정체 이슈
상태 변경 로그 이슈 연결 구조 업데이트 주기

해결방안

상태 정의 필수화
→ 언제 사용하는 상태인지 입력

비정상 상태 사용 감지
→ 장기 정체 / 상태 스킵 알림

상태 사용 리포트
→ 팀 단위 패턴 분석 제공

epic 단위 자동 요약
→ 진행률, 지연, 주요 변화

맥락 요약 (AI)
→ 현재 문제 상황 자동 정리

할 일 완료

“무엇을 개선해야되지?”
⇒ 리포트가 제공되지만 데이터가 실제 개선 행동으로 연결되지 않는다.

사용자 관점

수치를 봐도 무엇을 해야 할 지 모름

비즈니스 관점

단순한 task tool 로만 사용하게 되면 강점보다는 약점이 두드러져 retention이 저하됨

데이터 관점
cycle time lead time 완료율

해결방안

지표 해석 자동화
→ 병목 원인 분석 제공

액션 추천
→ 개선 방향 제시

역할별 리포트 맞춤 제공

각자 리서치를 마친 이후 오늘 자료 조사를 축약할 큰 틀을 짰다.
사용자관점에서 유저저니 맵에 추가할 페인포인트와 사용자 관점 + 비즈니스 관점 + 해결방안을 다 담을 문제정의로 나누었다.

그렇게 해서 완성된 최종 발표자료 정돈은 따로 링크로 기입하겠다!

https://velog.io/@minimalhwi_st/직무스터디-자료-정리-최종

이후 스크럼에서 언급했던 내용대로 발표 역할 분배를 진행했는데, 발표(스크립) + 자료조사로 순조롭게 나누어졌다. 나는 발표팀 ! 그렇지만 리더까지 맡고 있기 때문에 기회를 나누고 싶어 발표는 다른 분께 맡겼다 ㅎ.ㅎ

우리 팀 정말 좋다 ... 모두 적극적이고 유의미한 인사이트를 많이 내주시고, 내가 진행하면서 놓치는 디테일한 포인트들을 정말 잘 집어주신다. 매일매일 정말 많이 배우는 기분.

오늘도 1차토의 ,2차토의, 3차토의 .... 에서 (끝없이 반복되는 회의...) 이런저런 의견의 갈림길이 있었는데,
우리 팀이 고민했던 내용에 대해서도 짧게 기록해두는 것이 좋을 것 같다.
정리는 준하님께서 맡아주셨음 !

[고민 지점 정리 - 직무스터디 1차 논의]

Pain Point 분석: 페르소나 기반 vs Jira 서비스 기반

근거: 페르소나 기반으로 분석하는 것이 흐름상 더 자연스러울 듯.

+) 페르소나 설정의 이점(연경님): 의사 결정할 때 도움이 많이 된다.

“왜 이 기능을 넣어야 할까?” / “우리가 설정한 페르소나는 어떤 Pain Point를 가지고 있나?”

비즈니스 관점: 출시하는 회사 vs 고객 회사

근거: 고객 회사의 Pain Point는 ‘사용자 관점’에 포함되는 것이 자연스러울 듯.

[직무스터디 2차 논의]

데이터 지표, 얼마나 깊이 설정해야 할까?

의견: 너무 데이터가 세밀하게 들어가면 정보 과부하 있을 수도. 과하게 디테일해지면 역효과 있을 수 있음. / 다른 팀 발표에서 간단하게 서술한 편.
결론: 너무 깊게 들어가지 않아도 될 듯.

사용자 여정 추릴지, 말지?

결론: 유저 저니맵은 유빈님의 정리 참고. [시작 - 온보딩 - 적응 - 운영] 4단계로 추리기.
(시작 단계: 많은 툴 중에 특정 솔루션을 선택하는 단계)

슬라이드 구성 제안

의견: 유저 저니맵 슬라이드에서 각각의 Pain Point 서술. 문제 정의 슬라이드에서는 공통적으로 ~한 구조와 가이드가 부족하다고 서술.

플러그인 문제

의견: 플러그인 도입은 개별 사용자에게는 별 문제 안 됨. 그러나 전사적으로 도입할 때에는 큰 비용 만들어질 수 있다.
미해결: 이걸 Pain Point로 포함할지 정해야 함.

추가 의견

발표 목차 중 ‘PM의 역할’과 ‘문제 정의 및 해결’ 위치 바꾸기.
슬라이드에서 친근한 말투(연경님 정리) 사용해서 서술해도 좋을 듯.

[직무스터디 3차 논의]

사용자 관점 Pain Point 정리

시작 단계
결론: ‘협업 방식 선택의 피로도’
근거 1: 페르소나(박피엠)은 개발자 2명, 디자이너 1명과 일하는 입장에서 애자일한 방식의 Jira를 택할지 다른 툴을 쓸 것인지 고민할 것.
근거 2: ’도구 선택의 피로도’보다 적합한 워딩

온보딩 단계
결론: 초기설정의 복잡함 / 협업 흐름 설계 필요성에 대한 부담
근거 1: 가이드 부재, 템플릿의 역설을 포괄하는 워딩 선택
근거 2: 기능적인 요인과 심리적인 요인을 모두 다뤄보기.

적응 단계
결론: 업무 정의 기준의 모호함 / 업무 흐름에 대한 파악이 어려움
근거 1: 같은 유형의 작업이라도 ‘이슈’, ‘버그’, ‘스토리’로 정의될 수 있음.
근거 2: ‘업무 흐름’에 진행 사항, 병목현상 여부 등이 포함됨.

운영 단계
결론: 업무 완료 후 소통이 어려움 / 리포트를 봐도 다음 액션을 정하기 어렵다

‘가치 체감의 지연’은 어디에 포함해야 할까?
결론: 비즈니스 관점 Pain Point의 ‘온보딩 단계’에서 친숙한 말투로 정리.
근거 1: 아틀라시안은 이 문제를 매우 중시한다.
근거 2: 실제로 사용자들은 온보딩 단계에서 이탈하는 경우가 있다.

최종 정리표 구성 아이디어
결론: 사용자 관점 + 비즈니스 관점에서의 Pain Point를 친숙한 말투로 정리 + 데이터 및 해결방안까지 통합
근거 1: 두 관점 모두에서 분석하는 것이 의미 있을 것. 두 Pain Point의 접점을 찾는 것이 PM의 역할.
근거 2: Pain Point와 직접 연관되는 해결방안을 논리적으로 제시(겹치거나 관련성이 부족하면 수정했음)

Ping 기능 도입 및 개선
결론: 소통이 원활하지 않다는 Pain Point에 대한 해결 방안
근거: 알림 누락이 굉장히 많다는 의견들 있음

추가 의견
Q. 왜 Jira는 수많은 문제점들을 안 고칠까?
A. 분명 알고는 있겠지만 고칠 때마다의 비용이 매우 클 것.
+ 복잡하지만 효율적인 툴로서의 포지셔닝일 수도?

내가 당연하다고 생각하고 넘겼던 지점들에서 의견이 갈리는 게 신기했고 또 다른 관점에서 문장을 이해하고 새롭게 정의해보고, 문제점을 파악해볼 수 있어서 팀 스터디는 늘 좋고 집중하게 된다 ! 팀원들과 함께 공유하는 인사이트들을 꼭꼭 씹어먹어야지.

곧 튜터님과의 팀 면담이 기다리고 있는데, 추후 작성해서 덧붙이도록 하겠다.
이상 !

자경 튜터님의 피드백

틀린 내용 없음. 구성 좋음.
B2B PM이 가져야 할 고유한 역량이라기에는 다른 도메인과 겹쳐 보임. "B2B, "협업 툴 PM은 이런 게 다르구나"를 느낄 수 있도록 해야 함.
지금 PM의 역량으로 정리한 건 비직관적. (무슨 의미인지 잘 모르겠다는 뜻인듯)
발표를 하는 의미 두 가지

관심 있는 도메인을 파보면서 사이클을 익히고 향후에 다른 도메인에 적용해보기
다른 캠프 참여자들에게 참고할 자료 제공하기

지금 내용은 가볍다. 제공되는 정보량이 많지 않아 보인다.
추천 자료들

플렉스
레몬베이스
링크드인

리서치를 깊이있고 다양하게 진행했음에도, 발표자료로 추리고 생략하는 과정 중에 깊이감을 좀 잃은 것이 아닌가 생각하게 됐다.
여담이지만 AI활용을 당연히 했는데, 한 부분이 아니라 안 한 부분에서 AI로 정돈했냐고 물어보셔서 약간 당황 (...)

아무래도 우리 팀이 의식적으로 매끈하고 결함없게 정돈하려고 한 것이 오히려 배우는 입장에서의 인사이트를 담기에는 부족했던건가 싶기도 하고 !

튜터님의 피드백을 바탕으로 PM의 역할과 역량, 이 도메인을 다루는 PM의 차별성에 대해서 국내 아티클들을 기반으로 자료를 찾아보고 디벨롭하는 시간을 가진 결과로 최종 정리본이 완성됐다. 열심히 아티클을 헤집고 정돈하고 우리 언어로 작성하느라 힘써준 준하님, 유빈님, 나에게 자축을 ....
덕분에 팀 개성도 살고, 우리가 하고자 하는 말의 본질을 찾을 수 있었던 것 같다.

이렇게 또 매일매일 성장하는구나. 우리 팀이 지금 주목하고 집중해야하는 부분이 무엇인지, 살리고 싶은 부분이 무엇인지를 좀 더 생각하며 팀을 이끌어 볼 수 있을 것 같다 !

팀 에이스 ♠️ 드가자 사랑해 !!

휘

내일배움캠프 PM 6기

이전 포스트

260317 TIL

다음 포스트