WIKILOG

필터 생성을 완료했다면 대시보드 생성해보도록 합니다. 필터까지 만들었는데 대시보드를 만들어야 하는 이유는 차트 형태로 진행상황을 한 눈에 파악하기 쉽기 때문입니다. 1. 상단 메뉴에서 대시보드 - 대시보드 만들기 선택합니다. 2. 대시보드 이름 및 권한 설정해줍니다. 3. 모든 대시보드 보기에서 생성된 대시보드 확인해봅니다. 4. 대시보드 구성하기 4-1. 대시보드 페이지에서 편집 버튼 클릭합니다. 4-2. 필요한 가젯 추가합니다. 파이 차트 통계 유형 : 우선순위로 설정하는 것을 권장합니다. 2차원 필터 통계 (우선 순위 대비 작업자 할당량 확인 용도) x축 : 우선순위 y축 : 담당자 생성 대비 해결 차트 (일간 이슈 발생량 확인) 미해결 이슈의 유형 표시하도록 설정하는 것을 권장합니다. 모든 버전 ..

버그 관련해서 진행상황을 확인하고 이슈를 트래킹하고자 할 때 필터를 사용하면 유용합니다. 필터를 생성하는 방법은 아래와 같습니다. 1. 상단 필터 - 고급 이슈 검색 클릭합니다. 2. 프로젝트, 유형, 상태 등 원하는 필터 조건을 선택합니다. 만약 버그일 경우 영향 받는 버전, 해결 버전 등 버전 정보와 언제 해결이 가능한지 필수적으로 표시해둡니다. 3. 상단 다른 이름으로 저장 버튼을 눌러 생성한 조건을 바탕으로 필터를 저장합니다. 저장할 경우 권한에 대해서도 설정을 해줍니다. 4. 만들어진 필터를 공유합니다. 필터 공유 시 https://xxxxxxx.atlassian.net/issues/?filter=xxxxxx 형식인지 확인합니다. 간혹가다가 이슈 하나에 필터 링크가 걸릴 수 있어서 공유하기 전 ..

Jira 티켓은 일반적으로 회사의 기획 & 디자인 → 개발 → 검증 → 릴리즈 과정에 맞춰 구성하는 것이 좋습니다. 또한 티켓의 사용법 뿐만 아니라 각 티켓의 워크플로까지 고민하여 티켓을 구성해야 티켓 설정이 완료되었다 할 수 있습니다. 티켓 구성을 쉽게 설명하기 위해 아래와 같은 프로젝트가 있다 가정하겠습니다. [모니터링 시스템 구축] * 배경 및 문제점 - 가나라다라마바사 * 해결방안 및 가치 - 가나라다라마바사 * concept - 가나라다라마바사 * 상세 기능 - 가나라다라마바사 * 구현 범위 및 Task - 가나라다라마바사 * 세부 일정 - 가나라다라마바사 1. Epic Epic은 여러 Story/Subtask들의 집합으로 하나의 버전 혹은 프로젝트 단위입니다. Epic 티켓의 이름은 모니터링시..

🧐 참여 동기 PO/PM 이라는 직군으로 일하기 시작하면서 1등 제품을 만들고 싶단 생각이 들었습니다. 왜 이 제품에 열광하는 거지? 이 제품은 뭐가 다른 걸까? 어떻게 고민했을까? 등등 제품에 대한 고민이 깊어질수록 혼자 해결할 수 없는 문제라는 것, 내가 직접 소비자가 되지 않으면 느끼지 못하는 것들이 있다는 것을 알게 되었습니다. 그래서 정말 단순하게 인기가 있는 것들을 최대한 많이 사용해보면 공통점을 찾아보자라는 생각으로 새로 출시한 제품들을 많이 사용해보고자 노력했습니다. 그러면서 Product Hunt 라는 사이트를 알게 되었고 더불어 Typed 라는 제품도 알게 되었습니다. Typed 라는 제품을 일주일 정도 사용해보면서 '오 재밌는 제품이네?'란 생각이 들었습니다. 하지만 그 때 당시 회사..

우리가 회사를 이직하는 이유를 살펴보면 결국 4가지 이유 때문입니다. 돈, 사람, 시간, 경력 1. 돈 돈은 우리가 일하는 근본적인 이유입니다. 그렇기 때문에 일반적으로 회사에서는 나를 얼마나 인정해주는지 돈과 직급으로 말해줍니다. 내가 쏟은 시간 혹은 업무 강도에 따라 적절한 보상이라 생각된다면 굳이 돈 때문에 이직할 이유는 없습니다. 하지만 회사에서 나를 생각하는 정도와 내가 회사에 기여한 바는 거의 다르기 때문에 우리는 연봉을 올릴려면 이직해야한다는 말을 합니다. 2. 사람 사실 우리가 제일 많이 이직하는 이유가 사람이 아닐까 합니다. 하지만 사람 때문에 이직을 고민한다면 정말 신중히 고민해봐야 합니다. 어떤 그룹에서든 돌아이는 존재하기 때문입니다. 저 또한 사람 때문에 이직한 적이 있는데 실제 돌..

AWS 내 Elastic Load Balancing을 활용해 서버 구동을 시키다가 502 Bad Gateway 오류를 받게 되었습니다. 우선 로드밸런서 리스너 상태부터 확인했는데 리스너의 상태가 UnHealthy로 되어 있어 발생한 것으로 파악했고 아래 코드를 추가하여 Healthy 상태로 변경해주었습니다. 코드를 추가했음에도 지속적으로 502 Bad Gateway 오류가 발생한다면 로드밸런서 내 Target Group 포트를 80, 443이 아닌 설정한 포트 번호와 동일하게 입력해주면 리스너의 상태가 Healthy로 변경되며 오류도 해결됨을 확인할 수 있습니다.

https://youtu.be/B26O0mjIsUE 우리가 일하다보면 다른 회사는 어떻게 일하는지 궁금할 때가 아주 많이 있습니다. 그러던 중 알게 된 토스 워크스토리 영상. 사실 개인적으로 토스는 이제 스타트업계의 역사를 쓰고 있다 생각하고 있었기 때문에 영상을 보고 더 많은 것이 와 닿았습니다. 또한 왜 토스가 데카콘이라 불리는지를 확실하게 느낄 수 있었습니다. 영상 중간 중간 나오는 대화를 통해 얼마나 치열하게 일하는지, 하지만 서로를 얼마나 존중하는지 느낄 수 있었고 프로가 무엇인가에 대해 다시 한 번 고민하게 되었습니다. 서로 일하면서 주고 받는 피드백을 감정없이 전달하고 이해할 수 있는 사람은 몇이나 있을지, 그리고 그 피드백을 성장 포인트로 삼고 극복하는 사람은 몇이나 될지... 영상 마지막..

이번 글은 회의에 대해 작성해보고자 합니다. 우연한 기회로 시리즈 A, B, C 과정의 스타트업을 모두 경험하면서 정말 많은 회의를 참여했습니다. 회의를 하면서도 "뭐하는거지?" 란 회사도 있었고, "이게 진짜 회의지!" 라는 곳도 있었습니다. 그리고 내린 결론은 회의는 회사의 문화를 반영하고 있다 입니다. 그렇기 때문에 회의 문화만 잘 만들어도 안 나갈 사람이 나가는 문제를 해결할 수 있다 생각합니다. 1. RSVP(Please Response)는 습관화하자. 회사에서 정말 바쁠 때는 화장실 갈 시간도 없이 일해본 적이 있습니다. 회사 자체가 중요한 시기였고 항상 논의해야 할 것들로 가득차 있다보니 하루에 거의 7시간은 회의였었고 일주일 내내 최소 36 ~ 40시간 가량을 회의를 했던 적도 있었습니다...

외부 api를 사용하다보면 CORS에러를 쉽게 만날 수 있습니다. 이러한 경우 보통은 Backend 개발자에게 수정 요청하거나 프록시 서버를 구축해서 해결을 하는 편인데 누군가의 도움이 필요하거나 의도하지 않게 서버 구성을 해야하기 때문에 많이 번거롭습니다. 이러한 문제를 쉽게 해결하는 방법 중 하나가 접속하고자 하는 사이트 주소 앞에 https://cors.sh/ 를 붙여주는 것입니다. https://cors.sh/{접속하고 싶은 사이트 주소}로 호출하면 정상적으로 접속가능함을 확인할 수 있습니다. CORS.SH DISCLAIMER1. This project's intend is to serve developers a reliable cors proxy service with fast response ..

Product Manager로 가장 중요한 일은 무엇일까요? 바로 제품에 대한 이해하는 일이 아닐까 싶습니다. PM으로 제품을 이해한다는 것은 말처럼 쉽지 않습니다. 사용자도 알아야 하고 전달하고자 하는 제품의 가치, 회사의 방향성 등을 모두 이해해서 앞으로 제품의 방향성 수립하고 개발자, 디자이너, 마케터, 스타트업의 경우 C level도 설득해야 합니다. 수많은 질문들이 오갈 것이고 하나라도 논리적이지 않으면 거절되는 살벌한 환경 속에서 시간이 너무 부족합니다... 시간이 너무 많아서 다 이해했다고 했더라도 로드맵을 수립하거나 기능 우선순위를 고민할 때 혹은 설득할 때 결국에는 항상 내가 하고 싶었던 것 혹은 내가 상상하는 것을 하자 요구하게 됩니다. 그래서 저의 경우 4단계로 제품을 이해하고자 노력..