제품 요구사항을 정의하는 단계에 대해 궁금한 점이 있어서 질문드립니다. A라는 새로운 기능을 만들자는 목표가 생겼다고 가정했을 때, 프로젝트화 하기 위해 배경, 목적, 문제 정의 단계가 진행되고, 그다음 요구사항을 정의한다고 알고 있는데요. 궁금한 점은 이 요구사항은 무엇을 토대로 구체화해서 적을 수 있는지 궁금해요. 막연히 A라는 기능을 만들자는 목표만 있을 때, 적을 수 있는 내용이 단순한 내용이 되지 않을까 하는 생각입니다. 아니면, 단순 러프하게 작성 후에 개발자와 논의하여 내용을 구체화하는 걸까요?? 데이먼 님은 어떤 방식으로 요구사항을 정의하고, 개발자랑 커뮤니케이션하는지 궁금합니다. 요구사항을 무엇을 토대로 구체화해서 적을 수 있는지에 대한 질문입니다. 온라인에서 요구사항 정의서로 검색해보면..

현직 주니어 기획자이며, 진로 관련해서 데이먼 님의 조언받고자 글 남깁니다. "혹시, 앞으로 워터폴 방식 / 애자일 중 어떤 방식이 대세가 될지 여쭤드려 봅니다." 저의 배경은 디자인 (UX+시각) 학사 전공 뒤, UX 석사 전공을 한 기획자입니다. 현재 전형적인 워터폴 방식으로 기획일을 하고 있습니다. 기획일은 어렵고도 재미있지만, 사업팀의 영향력으로 기획자로서 많은 의사 결정권은 없는 상태입니다. 최근 애자일 방식으로 바꾸려는 팀에서 디자인으로 이동에 대해 고민 중입니다.... 계속 기획자로서의 커리어를 이어가야 할지, 좀 더 폭넓은 경력으로서 디자인에 도전해야 할지 고민 중입니다. 앞으로의 대세가 될 업무 방식을 확인하고 최종 결정을 하고 싶은데, 이 부분 데이먼 님께서는 어떻게 생각하시는지 궁금합..

꽤 오랜 시간 동안 국내 기획자들은 스토리보드를 중심으로 업무를 진행해왔습니다. 화면 좌측에는 UI를 그리고 우측에는 기능 명세를 작성하는 방식의 문서인데요. 기획자는 설계를 진행하며 UX를 고민하고 기능 구현 방식도 함께 고민합니다. 그런데 조금 더 생각해보면 UX는 디자이너가 보다 더 전문적이고, 기술은 개발자가 훨씬 전문적인 영역인데 기획자가 도맡아 설계하는 게 아이러니하기도 합니다. (UX는 별도 영역으로 분류되기도 하지만 편의상 디자이너와 가깝다고 표현했습니다) 그래서 기획 리뷰 시간이 되면, 디자이너는 디자이너의 입장에서 이슈를 체크하고, 개발자는 기술 관점에서 이슈를 체크하다 보니 당연하게도 경험치가 부족한 주니어 기획자들은 리뷰 시간마다 엄청 까이고 자신의 부족함을 자책하게 됩니다. 선배 ..

애자일 조직에서 많은 회사들이 JIRA로 Task를 관리하고 Confluence를 wiki로 이용하지만, 저희는 Asana로 Task를 관리하고 Notion을 wiki로 사용하고 있습니다. 오늘은 저희 팀이 아사나로 Task 관리하는 방법을 소개해보겠습니다. 애자일 조직에서 PO/PM의 가장 중요한 역할 중 하나는 업무 우선순위 결정입니다. 업무가 만들어지는 경로는 크게 3가지로 구분할 수 있는데요. ① 고객 피드백을 통한 유입 ② 팀에서 발생하는 내부 이슈 및 기술 부채 ③ 제품 로드맵에 따른 신규 기능 추가 ①번은 고객과 관련이 있고 ②번은 내부 팀과 관련이 있고 ③번은 경영진과 관련이 있습니다. 그렇다 보니 무게중심이 한쪽으로 쏠리면 제품의 방향성도 흔들리게 되는데요. PO는 제품이 올바른 방향으로..

, , 이 중 여러분은 어떤 직함을 가지고 계신가요? 세 직무 간 교집합은 많지만 구분이 명확하지는 않습니다. 제가 그동안 읽어본 아티클로 간단히 정리해보면, 해외에서는 를 의 상위 직군으로 분류합니다. 프로덕트 매니저 아래 여러 프로덕트 오너가 있는 구조이죠. 국내에서는 반대로 가 의 상위 개념으로 분류하고 있는 것 같습니다. 어감상 매니저보다는 오너가 더 윗 직급으로 느껴져서 그런 것 같기도 합니다 ^^;; 와 가 조금 더 비슷한 역할을 수행하는데, 는 일정관리와 의사결정에 포커스가 되어있고, 와 는 실무 기획까지 포함하고 있습니다. 이 개념이 완전히 정착된 건 아니고 자리를 잡아가고 있는 과정이라고 보면 될 것 같습니다. 사실 우리가 용어를 정의하기 어려운 이유는 세 직무 간 공통점이 너무나 많기 ..