기획 쪽에서 스펙이 변경되면 디자인 수정이 따라오는 건 당연한데요. 문제는 JIRA에 해당 태스크가 '디자인 수정'으로 로깅된다는 겁니다. 커밋 히스토리 보면 분명 요구사항 자체가 바뀐 건데, 결과적으로 디자인팀이 리소스를 비효율적으로 쓴 것처럼 리포트에 찍혀요. 분기마다 팀 퍼포먼스 리뷰할 때 이게 꽤 불리하게 작용하거든요. PM한테 태스크 분류 기준을 바꿔달라고 했는데요 그냥 원래 그렇게 하는 거라는 답만 돌아오네요. 비슷한 경험 있으신 분 어떻게 해결하셨는지 궁금합니다.
기획 변경인데 디자인 수정으로 찍히는 거 저만 그런가요?
8.4 16:27조회수 0댓글 8
입사하고 얼마 안 됐을 때 선배가 JIRA 티켓 정리하는 거 옆에서 본 적 있는데요, 기획 변경 건이랑 디자인 자체 수정 건이 구분 없이 다 같은 라벨로 쌓여있더라고요 😥 그때는 그냥 그런가보다 했는데요.. 그게 분기 퍼포먼스 리뷰에까지 영향을 준다는 건 생각도 못 했어요. 신입이라 아직 리뷰를 직접 겪어보진 않았지만 솔직히 이 글 읽으니까 좀 무섭네요 ㅠㅠ 저도 지금부터 신경 써야 하는 부분인 건지.. 혹시 성훈님은 태스크 로깅할 때 기획 변경이라는 걸 별도로 메모라도 남겨두시는 편인가요? 나중에 소급해서라도 증빙할 수 있는 방법이 있는지 궁금합니다 🙏
아 이런 일이 실제로 있군요... 저는 아직 입사한 지 얼마 안 돼서 JIRA 티켓 분류까지 신경 쓸 여유가 없었는데요, 분기 퍼포먼스 리뷰에 그렇게 반영된다는 거 읽고 좀 무서워졌어요 ㅠㅠ 저도 편집 쪽이라 직접적으로 같은 상황은 아니지만, 원고 내용이 바뀌어서 레이아웃 다시 잡는 건데 그게 제 작업 실수처럼 기록되면 억울할 것 같거든요. 근데 성훈님처럼 경력이 있으신 분도 PM한테 말했는데요 안 통한다면 신입인 저는 어떻게 해야 하는 건지 막막하네요. 혹시 태스크 로깅 기준을 바꾼 팀이 있다면 어떤 식으로 설득하셨는지 저도 너무 궁금합니다 ㅠㅠ
반론처럼 들릴 수 있는데요, PM한테 분류 기준 바꿔달라고 요청하는 것 자체가 좀 수동적인 접근일 수 있어요. 에이전시에서 오래 일하다 보니 클라이언트 스펙 변경이 밥 먹듯이 일어나는데요, 저는 아예 기획 변경 발생 시점에 별도 티켓을 제가 직접 생성합니다. 기획변경대응이라고 라벨 붙이고 원본 기획 티켓 링크 걸어두면 분기 리뷰 때 필터링이 돼요. PM이 안 해주면 내가 하는 수밖에 없더라고요. 본질적 해결은 아닌데 최소한 숫자 싸움에서 밀리진 않습니다. 다만 인하우스는 티켓 운영 구조가 다를 수 있어서 그대로 적용되실지는 모르겠네요.
솔직히 말하면 인하우스에서 태스크 분류가 어떻게 찍히느냐는 결국 돈 문제예요. 프리랜서로 10년 하면서 느낀 건데, 클라이언트 쪽 기획 변경이 내 작업 수정으로 처리되는 순간 추가 비용 청구 근거가 사라집니다. 성훈님 상황이랑 본질은 같아요. PM한테 분류 기준 바꿔달라고 말로 하는 건 솔직히 한계가 있고, 저는 기획 변경 발생 시점마다 슬랙이든 메일이든 텍스트로 남겨요. "OO 스펙 변경으로 인한 디자인 반영"이라고 제가 먼저 써서 보내는 거죠. 그러면 나중에 리포트에 뭐라고 찍히든 원본 기록이 남아 있으니까 반박 근거가 됩니다. JIRA 분류 체계를 바꾸는 건 조직 문화 싸움이라 오래 걸리는데요, 내 기록을 내가 먼저 남기는 건 오늘부터 가능하거든요. 결국 퍼포먼스 리뷰에서 불이익 받는 건 숫자로 방어해야 합니다.
저희 팀 기준으로 작년 3분기 디자인 수정 티켓을 역추적해봤더니 약 43%가 기획 스펙 변경에서 기인한 건이었어요. 그 데이터를 근거로 팀 리드와 함께 PO에게 태스크 분류 체계 재정의를 제안했고, 결국 기획변경 기인 수정이라는 하위 카테고리가 신설됐습니다. 성훈님 글 읽으면서 느낀 건데, PM 개인한테 분류 기준을 바꿔달라고 요청하면 그 사람 입장에서는 자기 업무 프로세스를 부정당하는 느낌이라 방어적으로 나올 수밖에 없어요. 접근을 바꿔서 한 분기치 티켓을 직접 분류해보시고 숫자로 정리한 리포트를 만들어보세요. 개인 간 요청이 아니라 조직 프로세스 개선 어젠다로 올라가는 순간 대화의 결이 완전히 달라집니다. 감정이 아니라 팩트가 테이블 위에 올라가야 움직이더라고요.
저번 분기에 제 티켓 한번 세어봤는데요 디자인 수정으로 잡힌 18건 중 11건이 기획 변경 기반이었거든요ㅋㅋ 근데 저는 3년차라 퍼포먼스 리뷰에서 이게 얼마나 크게 작용하는지는 솔직히 체감을 잘 못하고 있어요. 성훈님처럼 7년차면 분기 리포트 누적이 꽤 되셨을 텐데 실제로 연봉 협상이나 승진 평가에서 이 수치가 직접적으로 언급된 적도 있나요? 저는 아직까지는 그냥 찝찝한 정도인데요 나중에 연차 쌓이면 진짜 문제가 될 것 같아서 지금부터 좀 신경 써야 하나 고민 중이에요. 일단 저는 기획 변경 들어올 때마다 슬랙 스레드 캡처해서 노션에 따로 모아두긴 하는데요 이게 맞는 방법인지도 모르겠고ㅋㅋ
생각지도 못한 부분이네요... 저는 프로덕트 디자이너로 갓 입사한 입장이라 수정 요청 들어오면 원인 따지기보다 빨리 반영하는 데만 급급했거든요. 기획 변경이든 디자인 퀄리티 문제든 그냥 다 똑같은 수정 작업이라고만 생각했는데요, 그게 분기 리뷰에서 팀 퍼포먼스를 깎는 근거가 된다니 솔직히 좀 무섭습니다. 한 가지 궁금한 게, 성훈님처럼 연차가 있으신 분도 PM 설득이 쉽지 않으시면 신입이 이 문제를 인지하고 있다 한들 현실적으로 할 수 있는 게 거의 없는 걸까요?
저번 달에 모션 작업 하나 갈아엎은 적 있는데요, 기획에서 플로우 자체를 바꿔버려서 트랜지션 전부 새로 짠 건데 JIRA엔 그냥 "모션 수정"으로 딱 한 줄 찍혀있더라고요. 작업 시간만 이틀인데요 로그상으론 자잘한 수정 하나 한 사람이 돼버림ㅋㅋ 근데 성훈님 글 보면서 든 생각이, 분기 퍼포먼스 리뷰에까지 영향 간다는 건 좀 무섭네요. 3년차라 아직 그런 리뷰를 크게 의식할 상황은 아니었는데요 지금부터 티켓 히스토리 좀 챙겨놔야 하나 싶어서요. 혹시 기획 변경 기반이라는 걸 증빙할 때 슬랙 로그 같은 거 따로 캡처해두시는 편인지 궁금합니다.