서비스 기획자의 아이디어 로그
가장 기본적인 아이디어 관리
아이디어 로깅 프로세스 ⓒ작가 편집IT 조직에서 제품을 관리하다 보면 상위 조직의 요구사항을 처리하면서 동시에 사용자 피드백과 데이터를 바탕으로 개선 아이디어를 도출한다. 하지만 많은 아이디어는 '발제된 시점'에만 유의미한 경우가 많다. 제품을 개선하는 과정에서 상황이 바뀌고, 그 아이디어가 더 이상 필요 없어질 때가 많기 때문이다. 그래서 나는 지라 같은 관리 툴에 바로 티켓을 발행하기보다, 1차적으로 엑셀로 관리하는 방식을 선호한다. 내가 직접 작성하거나, 이해관계자가 작성하게 만들거나.
엑셀에 정리한 아이디어는 스프린트 중간에 한 번씩 팀원들과 함께 검토한다. 이후 우선순위를 정해 지라에 티켓을 발행하고 '백로그'로써 관리한다. 백로그로 등록된 티켓은 우리가 다음에 해야 할 일을 손쉽게 파악하는 데 도움이 되고, 개발자가 다음 작업을 미리 예상할 수 있게 도와주는 장점이 있다.
이번 글에선 내가 사용하는 엑셀 아이디어 로그를 공유할 예정이다. 컴퓨터 한편에 엑셀을 켜두고 아이디어를 수집하면 그 이슈를 바로 고민하기보다 일단 이곳에 기록해 보자. 참고로 이 엑셀은 '티켓 트래킹 툴'과 사용할 때 시너지가 커진다. (티켓 트래킹 툴: 지라, 아사나, 먼데이, 노션, Height 등)
아이디어 로그
아이디어 로그 엑셀 ⓒ작가 편집실제로 아이디어를 기록하기 위해 사용하는 엑셀이다. '기능 개선 요구'나 '아이디어'를 접수할 때, 그 시점의 상황을 생생하게 작성하는 것을 목표한다. 그래서 이곳에 작성된 로그는 날 것 그대로인 경우가 많다.
엑셀은 이곳에서 다운로드할 수 있다.
컬럼별 의미
컬럼별로 아래 의미를 가진다.
1. 분류: 아이디어의 대분류를 의미한다. 현재는 '웹, 앱, 공통' 셋 중 하나를 선택하게 세팅한 상태다.
2. 관리 번호: 선택한 분류별 누적된 로그 수를 의미한다. '분류'를 선택하면 자동으로 채번 된다.
3. 니즈/아이디어: 인입된 아이디어, 니즈를 작성한다. 되도록 간단하고 명료하게 작성한다.
4. 설명: 니즈/아이디어의 배경을 작성한다. 추후에 로그를 보고 문제를 다시 정의할 수 있을 정도로 인입된 배경을 생생하게 작성한다.
5. 관련 화면: 관련된 화면을 표기한다. 만약 공통 정책(로그인, 인증 등)이라면 '공통'이라고 표기한다.
6. 관련 정보(사진 등): 추가로 작성할 수 있는 참고 정보, 사진이 있다면 첨부한다. 피그마에 따로 캡처 파일을 두고 링크를 걸어도 좋고, 채팅의 URL을 걸어도 좋다.
7. 메모: 나중에 이 로그를 분석할 때 참고할 수 있는 추가적인 내용이 있다면 작성한다. 보통 사이드 이펙트, 혹은 함께 고려해야 하는 점을 작성한다.
8. 작성일자: 작성일자를 표기한다.
9. 작성자: 작성자를 표기한다.
10. 수용 여부: 로그를 검토한 후, 해결하기 위한 액션을 취한다면 '예', 아니라면 '아니요'로 표기한다. 보통 '예'로 변경한 후 지라 백로그에 이슈 티켓을 발행한다.
11. 관련 티켓: 관련 작업을 추적할 수 있게 티켓의 URL을 첨부한다.
12. 처리일자: 해당 로그가 처리된 일자를 작성한다. 보통 나는 릴리즈일자를 작성하는 편이다.
13. 논의 사항: 기타 논의 사항이 있다면 작성한다.
사용 예시
1. 아이디어, 요구사항을 접수할 때
1~9번 컬럼을 먼저 작성한다.
나중에 봐도 이해할 수 있도록 설명을 생생하게 작성하자.
로그 수집 시 ⓒ작가 편집2. 내용을 검토할 때
내용을 가볍게 검토하며 메모를 보강하거나 논의 사항을 기록한다. 그것이 빠른 시일 내 개발되면 정말 의미를 가질 수 있을지 고민하고, 조직에서 요구하는 우선순위에 맞춰 수용할 것인지 판단하는 것을 목표한다.
로그 검토 시 ⓒ작가 편집3.1. 수용하는 경우
지라 등 관리 툴에 티켓을 발행한 후, 10번(수용 여부) 컬럼을 '예'로 변경하고 11번(관련 티켓)에 티켓 번호를 매핑한다. 릴리즈한 후에 처리일자까지 채워주면 깔끔하다. (나중에 요구한 당사자에게 어필할 때도 써먹을 수 있다.)
로그 수용 시 ⓒ작가 편집3.2. 수용하지 않는 경우
아이디어를 수용하지 않는 경우엔 10번 컬럼을 '아니요'로 변경하고 해당 로그를 종결한다. 행의 색은 수용 여부에 따라 알아서 바뀐다.
로그 수용 안 할 시 ⓒ작가 편집아이디어를 따로 관리하는 이유
지라, 노션, 아사나, Height 같은 프로젝트/이슈 관리 툴을 사용하고 있다면, 그곳에 바로 기록해도 괜찮다. 특히 지라는 이를 위한 환경을 잘 제공한다.
하지만 나는 아이디어나 니즈를 바로 티켓으로 만들지 않는 것을 선호한다. 불필요한 티켓을 생성했을 때 발생하는 관리 비용을 줄이기 위해서다.
미리 티켓으로 등록된 아이디어, 니즈는 변동이 심한 편이다. 보통 이런 요구사항은 요청받은 순간에 가장 큰 의미가 있기 때문이다. 대부분의 경우 서비스의 전체적인 프로세스, 시나리오를 고려하기보다 요청한 사람이 겪은 작은 불편함을 해결하는 미봉책일 때가 많다. (그래서 리프레이밍이 중요하다.)
CRM 프로그램이나 내부 서버에서 쓰레기 데이터(Garbage Data)가 쌓이지 않도록 관리하는 것처럼, 로그 관리도 같은 목적을 가지고 있다고 보면 이해가 쉽다.
주의사항
이 방법은 내가 몇 년 동안 서비스 기획을 하면서 가장 익숙하고 효율적이라고 생각하는 절차를 기반으로 구조화한 것이다. 그래서 도입하는 환경, 사용하는 사람의 성향, 조직 문화에 따라 비효율적일 수도 있다.
언제나 그렇듯, 도구를 사용할 땐 프레임에 매몰되지 않도록 주의하며 사용하기를 권장한다.
여담
이 엑셀은 여러 명의 이해관계자가 함께 쓰는 것을 고려해서 구조화했다. 아이디어를 작성하는 사람이 여럿 존재하고, 이를 정제하는 담당자가 따로 존재하는 형태다. 굳이 엑셀이 아니더라도 비슷한 방법으로 처리를 한다면, 설문폼을 운영하거나, 플러그인을 만들어서 워크플로우를 세팅해서 접근성을 높이는 것을 추천한다.
ⓒ327roy
