by
Nov 05. 2023
#22 기획 리뷰와 동료 피드백 수집
2023년 44주 차 회고
이전 회고 ☞ https://brunch.co.kr/@327roy/69
다음 회고 ☞ https://brunch.co.kr/@327roy/72
노트
#1 기획 리뷰와 동료 피드백 수집
#기획리뷰 #피드백 #성찰
이번 주에 스프린트 프로세스의 세팅이 어느 정도 완료가 되었다. 다음 주부터 스프린트를 달리는 것이 확정된 상황.
이 때문에 개발자들에게 ‘개발을 할 수 있는 명확한 기획 산출물’을 공유할 필요가 있어서 이번 주 목요일에 개발자분들과 기획을 리뷰하는 시간을 가졌다.
#1 오늘의 회의는 어땠나요?
리뷰 후, 같이 회의했던 개발자분들께 슬쩍 가서 오늘 회의를 진행한 것에 대한 피드백을 간략하게 요청했다. 1) 해당 회의의 방향을 중간에 다시 잡아주셨던 개발자분께는 ‘전체적인 회의에 대한 피드백’을, 2) 설명한 기획의 리뷰에 대해서 공감을 잘 못하셨다는 느낌을 받았던 개발자분께는 ‘어떤 점에서 그런 느낌을 받았는지'를 여쭤봤다.
새로운 조직에 온 만큼 구성원들과의 생각을 더 공유할 필요가 있었기에 요청한 피드백이었다.
#2 언제나 그렇듯, 회의의 목적은 뚜렷해야 한다.
앞서 기록했던 많은 회고들에서 자주 다뤘던 키워드 중 ‘효율적인 회의’가 있다. 효율적인 회의를 해야 하는 이유는 명백하다. 비용 절감과 더 좋은 방향으로 가는 미래를 확보하기 위함이다.
오늘의 회의는 영양가를 반 정도만 챙긴 것 같다. 원래 이번 회의의 목적은 ‘다음 주 개발을 하기 위한 기획 산출물을 리뷰하는 것’이었다.
보통 이때는 개발해야 할 스펙을 파악하고, 상세한 개발 계획을 짤 수 있을 정도의 산출물을 개발자들이 공유받는 것이 바람직하다.
예를 들어, 기능을 추가했을 때의 사용자 스토리와 플로우차트, 디자인이 완료된 화면, 각 화면의 요소에 대한 상세 정책 같은 것들.
다음 스프린트의 타임박스에 존재하는 작업량과 의존성 파악 등이 명확해야 기획자든 개발자든 관계자들이 스프린트를 더 효율적으로 사용할 수 있기 때문이다.
하지만 이번에는 그 정도의 퀄리티로 공유할 수 없었다. 백로그를 정제하며 리스트업 된 기능과 서비스가 가야 하는 방향, 그리고 관련 기능을 종합하고, 제품의 미래 형상을 그리는데 시간을 많이 썼기 때문에, 하나의 기능에 대해서 온전한 기획서 한 본을 공유할 수 없었다.
이 때문에 기획 리뷰의 수준이 기능 컨셉과 사용자 스토리를 공유하는 것 정도에 머물렀고, (특히 디자인이 확정되지 않았던 만큼) 이로 인해 개발자들에게는 꽤나 답답한 미팅이 되었던 것 같다.
느낀 것은 두 가지.
1. 회의의 목적에 충분히 맞는 퀄리티가 확보되지 않을 것으로 예상된다면 과감하게 회의를 뒤로 미룰 수 있어야 한다.
2. 혹은 회의에서 다뤄야 하는 내용을 축소하는 등 우회 방법을 찾고, 작아진 범위만큼 퀄리티를 보충한다.
#3 이해와 공감
이해와 공감은 다르다. ‘이해’란 그것이 나타내는 것을 잘 받아들인다는 뜻을 가지고 있고, ‘공감’은 다른 사람의 감정을 자신도 그렇게 느낀다는 뜻을 가지고 있다.
오늘 회의에서는 어떤 부분에서는 ‘빠른 이해’를 이끌어내지 못했고, 어떤 부분에서는 ‘공감’을 이끌어내지 못했다.
일단 나는 ‘이해’가 안된다는 것은 1) 내가 설명을 못하거나, 2) 상대방과 내가 생각하는 기반이 다른 것이 원인이라고 생각한다.
상대방이 이해를 잘 못했다고 느낄 때 보편적으로 가지려고 하는 마인드셋은 ‘내가 설명을 어렵게 했다는 것’. 아마 내가 지식의 저주에 빠진 상태로 설명을 해서 발생한 것이 아닐까 생각한다. 그래서 필요한 것은 그 사람의 맥락(배경)을 미리 이해할 필요가 있다는 것.
예를 들어 기능 기획 시 화면이 덜 완성된 상태로 리뷰를 가진다고 하자. 이때 "화면의 디자인은 보지 말고 목적을 위주로 봐주세요!"라고 요청하면 나는 알아들을 수 있다. (내 주위의 몇몇 기획자들도) 하지만 화면을 이미 회의실 티비에 띄워놓은 이상, 저렇게 요청하게 된다면 대부분 사람들은 화면의 디자인에 조금 더 매몰되게 된다.
예를 들어 1) 화면 설계서에서는 달력 아이콘으로 표현해 놓고, 2) 날짜 텍스트를 클릭하면 날짜가 선택되는 형태를 플로우로 설명하면 대부분 “엥, 화면에는 달력 아이콘 클릭했을 때 날짜 선택할 수 있어야 하는 거 아니에요?” 하는 것이 그 이유.
각자가 가지고 있는 맥락과 특성을 이해하고, 맞춰 설명할 필요가 있다고 느꼈다. 필요하면 차라리 화면 설계서의 품질을 확 낮추고 플로우차트를 주력으로 얘기를 하고, 혹은 화면 컨셉을 더 디테일하게 그리거나, 혹은 아예 둘 중 하나만 선택해서 공유하는 것이 바람직할 것이다.
그리고 ‘공감’을 얻기 위해서는 ‘공감을 유도해야 하는 대상과 공감을 얻어야 하는 것(혹은 사람) 간의 시간’이 필요하다고 생각했다.
그래서 생각한 것은 한 번에 많은 양의 기획 리뷰를 얕게 가지기보다는, 각 기능들이 명확하게 나올 수 있도록 ‘잘 설명한 기획서’를 만들 필요가 있다는 것.
아니면 공감이 필요 없어도 일이 빠르게 진행될 수 있는 환경을 만들던지 해야 한다. (하지만 이 경우 장기적으로 봤을 때 동료들의 동기부여가 안될 확률이 크다.)
#4 그리고
서비스 기획을 하다 보면 화면을 함께 설계하게 되는 경우가 많다. 이때 힘든 점은 화면에서 풀고자 하는 목적과 해결하려고 하는 것은 분명한데, 이를 해결하기 위한 UXUI를 고민하는데 시간이 충분히 필요하다는 점이다.
생각은 꼬리에 꼬리를 물고, 그것이 화면을 난잡하게 만들고. UI 쪽에 치중되다 보면 화면의 목적이 흐려지는 경우가 있다. 그러다 보면 내 의도를 찰떡같이 알아듣고 화면을 그려주는 사람이 필요함을 종종 느낀다.
예를 들어, ‘화면에서 어떤 동작을 할 수 있어야 하고, 어떤 결과를 확인할 수 있어야 한다.’가 정의되었을 때, 이 목적을 해치지 않는 선에서 화면을 이쁘게 그려주는 그런 역할.
하지만 실상은 그러기 힘들다. 항상 우리는 시간이 부족하고, 급하기 때문이다. 역할 간의 경계가 허물어지고, 모든 메이커들이 좋은 제품을 만들기 위한 문제 정의와 해결방법을 제안하는 것에 익숙해져야 한다고 생각하지만, 실무는 그러기 힘든 경우가 많다.
융통성 있게 어떤 역할에 비중을 더 두고 실무를 진행할지 항상 고민하고 많은 경험을 쌓아둘 필요가 있음을 느낀다.
#2 협업을 잘하기 위한 노력
#협업 #관계 #소통
*설득을 못한 것에 대한 고민이 아님을 먼저 밝힘
화요일에 저번 주에 정제한 (기능이 작성된) 백로그를 공유하기 위한 회의를 진행했다. 이때 공감을 잘 이끌어 내지 못했던 항목이 2개 도출되었다.
항상 모든 협업 관계자의 공감을 받을 수는 없는 것을 알고 있고, 당장 납득을 시킬 정도의 항목들은 아니었기 때문에 유야무야 넘어갔다.
하지만 만약 그 항목들이 공감을 불러일으키기는 힘들지만 밀고 나가야 하는 것에 확신이 드는 항목이었다면 나는 어떻게 해야 했을까?
아마 이번 같은 상황이었으면 레퍼런스로 삼을 만한 서비스들을 입으로만 말하며, 내가 그렇게 생각하는 이유를 근거로 설명하려고 반복되는 말을 했을 것이다.
그리고 이때부터는 설득이 아니라 납득을 시키기 위한 과정이 되고, 결국 목소리 큰 놈이 이기는 게임이 될 것이다. (보편적인 협업 상황에서는 지양해야 하는 패턴이라고 생각한다.)
느낀 것은 보여줄 수 있는 시각 자료를 충분히 만들어두고, 상황을 분석하며 필요할 때 끄집어낼 수 있도록 만들어야 할 필요가 있다는 것.
그래서 오늘 느낀 교훈은
1. '지식의 저주'에 빠지지 않도록 조심할 것
- 내가 충분히 공감한 것이더라도 남은 그렇지 않을 수 있다.
- 우리 모두에게는 맥락(정보, 기억)의 차이가 발생할 수 있음을 기억하자.
2. 그렇기 때문에 자료의 아카이빙이 필요하다.
- 레퍼런스를 꾸준히 수집하고 잘 분류해 둘 것
- 그리고 머릿속에 잘 정리해 둘 것
#3 공감과 확신
#공감
기획을 할 때 중요한 것은 문제를 정의하는 것도 있지만, 도출된 해결방안이 잘 개발될 수 있도록 이끌어 나가는 힘도 중요하다.
이를 위해서는 디자인과 개발을 담당하는 실무자를 이 방안에 공감시키고, 만들기까지의 길이 험난하더라도 그들을 잘 독려하며 산출물을 만들어낼 수 있어야 한다.
반대로 말하면, 디자인과 개발 담당자를 공감시키지 못하는 경우에는 프로젝트 전체가 힘들어진다.
이 경우에는 어떻게든 공감을 만들어 일을 잘 끌고 가거나, 혹은 권력과 힘으로 눌러서 산출물을 만들어 내거나 해야 한다. 후자의 경우에는 이후에 또 챙겨야 하는 것들이 많다. (예를 들어 구성원들의 동기, 반발심에 대한 케어 등)
여기서 말하는 ‘공감’을 일으킬 때 중요한 것은 뭘까? 맥락과 적절한 근거도 필요하지만, 담당자가 가지고 있는 ‘확신’이 필요하다.
이는 곧 협업하는 관계자들에게 심리적 펜스를 마련해 주고, 그들이 더 진취적으로 일할 수 있게 만들어 주기 때문이다. 그래서 기획자의 확신은 기획에 대한 책임을 본인이 진다는 의미도 있다.
하지만 과한 자기 확신은 독이 될 수 있으니 주의해야 할 필요가 있다. 가령 스스로 마이오피아에 빠진 경우.
따라서 적절히 외부 에너지를 유입시키고, 생각을 환기시킬 필요가 있다.
#4 Jira 프로젝트 관리
#Jira #프로젝트관리 #백로그
이번에 조직을 옮긴 후, 제품 제작에 몰입할 수 있는 환경을 만들기 위해 프로젝트 진행을 위해 필요한 프로세스를 빠르게 정리하고 있다.
크게 1) 프로젝트 관리에 대한 것과 2) 기획 산출물에 관한 것으로 나눌 수 있는데, 오늘 남길 내용은 1) 프로젝트 관리에 대한 내용이다.
현재 재직 중인 회사에서는 프로젝트를 아틀라시안의 Jira라는 툴을 써서 관리하고 있다. 노션과 엑셀 모두 사용해 봤지만 확실히 Jira가 프로젝트 관리 시에 더 편한 것을 느낄 수 있는데, 1) 애자일 철학을 기반으로 프로젝트 관리를 위해 만든 툴이고 2) Jira에서 컨설턴트로 지내다 오신 분이 회사에 계시기 때문이라고 생각한다.
즉 현재 회사에는 Jira에 대한 전문가가 계신다. 이분이 우리 조직에서 제품의 프로젝트를 관리하기 위한 프레임을 잡아주고 계신 상황인데, 확실히 활용 가능한 기능과 툴의 개념을 설명받는 것만으로도 느껴지는 효용감이 존재함이 존재한다.
예를 들어 1) 정제되지 않은 백로그를 개발이 진행되는 이슈들과 함께 관리하는 것에 대한 부분이나, 2) 애자일에서 말하는 Initiative, Epic, (User) Story와 Task 등의 위계를 이해하고 사용하는 것들. 3) 그리고 생성한 이슈들에 필드를 추가하여 훗날 적재적소의 필터를 만들어 확인하는 것을 말할 수 있다.
무엇보다 Jira를 잘 사용할 때 편한 것은 개인화된 대시보드를 만드는 것으로 버그와 릴리즈를 관리하고, 프로젝트의 병목을 확인하는 과정이 편하다(대부분 개발 업무에 대한 것).
Jira에서는 칸반, 스크럼, 간트 모두 제공하고 있지만, 가장 효용감을 느끼는 부분은 역시 스크럼을 통해 스프린트를 안정적으로 진행할 때가 아닐까.
어떻게 하면 더 조직에게 좋은 방향으로 프로젝트를 관리할 수 있을지 많이 배우고 있는 요즘이다.
#5 서비스 인터뷰
#인터뷰 #스타트업
ⓒ 몰리나저번 주 토요일 '몰리나'라는 서비스의 관계자와 인터뷰를 진행했다. 리써치를 도와주기 위해 만드는 제품이라고 하는데, 인스타에서 광고를 보고 사전 예약을 신청했다가 결국 인터뷰까지 진행하게 됐다.
시장에 새로 진입하는 도전자를 응원하는 마음과 제품에 대한 호기심을 가지고 인터뷰에 응했는데, 제품을 통해 어떤 문제를 해결하고 싶은지를 설명 들으며 여러모로 나도 동기부여가 되었다.
현재는 나 또한 어떤 시장에 진입하기 위한 제품을 새로 만들고 있는 상황이니 공감도 많이 되었고. 다음 주도 더 열심히 살아야겠다.
#6 44주 차 KPT
#회고 #성찰 #KPT
[KEEP]
1. 작은 도서관 자료 아카이빙을 진행했다.
- 이번 주 달성률 57.1%(4/7)
2. 업무를 목표한 것만큼 달성했다.
[PROBLEM]
시간이 부족했다는 합리화로 좋은 퀄리티의 기획서를 공유하지 않았다. 선택과 집중이 필요하다.
[TRY]
1. 작은 도서관에 자료를 하루에 최소 1개 채워 넣는다. (다음 주 목표: 7개)
2. 하루에 적어도 1시간을 사내 개인 프로젝트에 시간을 투자한다.
ⓒ 327roy
