디버깅 시간을 줄이는 PM의 티켓 작성법

명확한 문제 정의

디버깅 과정에서 가장 중요한 첫 번째 단계는 문제를 정확히 정의하는 것입니다.
모호한 문제 정의는 디버깅을 복잡하게 만들고, 문제 해결 시간을 크게 늘릴 수 있습니다. 
따라서 티켓에는 버그를 재현할 수 있는 명확한 단계와 기대 결과, 그리고 실제 결과가 포함되어야 합니다.

버그 재현 방법
버그를 명확히 설명하고, 재현 가능한 단계를 포함해야 합니다.

🟢 Good Case: "로그인 페이지에서 로그인 버튼을 클릭한 후, 페이지가 로드되지 않고 500 에러가 발생함. 콘솔에 'null pointer exception'이 출력됨."

🔴 Bad Case: "버튼을 클릭했을 때 오류가 발생함."

기대 결과와 실제 결과
티켓에는 버그가 없었을 때 기대되었던 결과와 실제로 발생한 결과를 명확히 기술해야 합니다.

🟢 Good Case: "로그인 시 대시보드로 리다이렉트되어야 하지만, 로그인 페이지에서 벗어나지 않음."

🔴 Bad Case: "로그인이 안 됨."

환경 정보와 조건 명시

버그가 발생하는 환경과 조건을 명확히 하는 것은 문제 해결을 위한 중요한 단서가 됩니다.
 동일한 코드가 다양한 환경에서 다르게 동작할 수 있기 때문에, 환경 정보와 특수 조건을 명확히 기록하는 것이 중요합니다.

시스템 정보

버그가 발생한 환경을 상세히 기록합니다. 이는 운영체제, 브라우저 버전, API 버전 등 중요한 시스템 정보를 포함해야 합니다.

🟢 Good Case: "Windows 10, Chrome 85.0.4183.102 에서 발생."

🔴 Bad Case: "PC에서 버그 발생."

특수 조건

문제를 발생시킬 수 있는 특수 조건이나 전제조건을 명확히 명시합니다.

🟢 Good Case: "이 버그는 신규 가입자(가입 후 24시간 이내)에만 발생하며, 기존 사용자에게서는 재현되지 않음."

🔴 Bad Case: "가끔 발생함."

 

관련 로그와 스크린샷 제공

문제 해결에 있어 관련 로그와 스크린샷, 혹은 동영상은 매우 유용한 자료입니다. 

이러한 자료들은 문제의 원인을 파악하는 데 결정적인 단서를 제공할 수 있습니다.

로그 첨부

버그와 관련된 로그 파일이나 콘솔 출력을 티켓에 첨부합니다. 로그 파일에는 에러 메시지나 예외 상황에 대한 정보가 포함되어 있어, 문제의 원인을 보다 쉽게 파악할 수 있습니다.

🟢 Good Case: "에러 로그 첨부 (파일명: error_log_2024-08-27.txt)."

🔴 Bad Case: "에러 로그 없음"

스크린샷 및 동영상

버그가 발생한 상황을 시각적으로 보여주는 스크린샷이나 동영상을 포함하면, 개발자가 문제를 더 빨리 이해할 수 있습니다.

 🟢 Good Case: "오류 발생 시의 화면 스크린샷 첨부."

 🔴 Bad Case: "스크린샷 없음.""

우선순위 및 비즈니스 영향도 명시

버그의 우선순위를 설정하고, 비즈니스에 미치는 영향을 명확히 하는 것은 티켓 작성에서 중요한 요소입니다. 이를 통해 팀이 어떤 문제를 먼저 해결해야 하는지, 그리고 그 문제의 해결이 얼마나 중요한지를 파악할 수 있습니다.

우선순위 설정

버그가 시스템이나 사용자에게 미치는 영향을 기준으로 우선순위를 설정합니다.

🟢 Good Case: "전체 서비스가 중단되며, 사용자 경험에 심각한 영향을 미침. 우선순위: P1."

🔴 Bad Case: "버그가 있음. 확인 필요."

비즈니스 영향
버그가 비즈니스에 미치는 영향을 기술하는 것도 매우 중요합니다.

🟢 Good Case: "신규 가입자들이 첫 구매 시 20% 할인 혜택을 받을 수 없으며, 이로 인해 전환율이 급격히 하락할 가능성이 큽니다."

🔴 Bad Case: "사용자에게 불편함."

 

팀 내 일관된 네이밍 사용

효과적인 티켓 작성은 팀 내에서 일관된 용어와 네이밍을 사용하는 것에서 시작됩니다. 

같은 기능이나 개념을 지칭할 때 팀 내에서 모두가 동일한 용어를 사용하는 것은 커뮤니케이션의 명확성과 효율성을 높이는 데 필수적입니다. 

혼란을 줄이고, 개발자들이 문제를 빠르게 이해하고 대응할 수 있도록 일관된 네이밍 사용이 중요합니다.

일관된 용어 사용

🟢 Good Case: "유저 프로필 화면에서 '최근 활동 리스트(recentActivityList)'가 로드되지 않음."

🔴 Bad Case: "유저 페이지에서 'activity 리스트'가 안 보임."

표준 네이밍 가이드라인 마련 및 공유

🟢 Good Case: 매니저가 팀 내 표준 네이밍 가이드라인을 문서화하고, 이를 모든 팀원이 쉽게 접근할 수 있도록 공유. 예를 들어, "최근 활동 리스트"는 모든 문서와 코드에서 'recentActivityList'로 통일.

🔴 Bad Case: 네이밍 규칙이 존재하지 않거나, 팀원들 간에 서로 다른 용어를 사용하는 것을 방치함. 예를 들어, 같은 기능을 'recentActivities', 'activityList' 등으로 제각각 부르는 상황.

https://www.product201.com/blog/%EB%B2%84%EA%B7%B8%EB%8A%94%20%EB%94%94%ED%85%8C%EC%9D%BC%EC%97%90%20%EC%9E%88%EB%8B%A4