by
Nov 26. 2023
#25 불확실성과 실패 가능성에 대한 인정
2023년 47주 차 회고
이전 회고 ☞ https://brunch.co.kr/@327roy/73
다음 회고 ☞ https://brunch.co.kr/@327roy/75
노트
#1 불확실성과 실패 가능성에 대한 인정
#불확실성 #실패가능성 #애자일
쏘카에 계신 분이 쓴 글을 읽었다. 전체적으로 이 글의 내용은 애자일 철학에 뿌리를 두고 있었는데, 공감되고 과거의 내 경험을 돌아보게 하는 좋은 계기가 되어 주어서 언급하게 되었다. (애자일은 일종의 소프트웨어 개발 방법론이자 하나의 철학이라고 말할 수 있다.)
1.
'서비스, 제품을 만든다'는 것은 머릿속에 있던 것들을 개념화하고 세상에 실체화시키는 것을 의미한다. 이 과정에서 추상적으로 상상해 왔던 두리뭉실하고 방대한 것들이 뾰족하게 다듬어지고 무거워진다.
이 과정이 금방 이루어지지 않는다는 것은 무엇인가를 만들어본 사람이라면 다들 공감할 것이다. 추상적인 것을 실체화시킨다는 것은 수많은 합의와 정의의 과정을 거쳐야 하기 때문이다.
그리고 제작의 과정은 제작자가 정의한 명제가 전달하고자 하는 가치가 많고 무거울수록 실체화를 위한 시간이 더 많이 소요하게 되며, 그것이 완성되기 전까지 그것에 대해 완벽하게 알 수 없다는 문제가 있다.
그렇기 때문에 뚝딱! 뭔가를 만들어 내는 것은 흔하지 않고 아주 어려운 일이며, 이 맥락으로 생각해 보면 긴 호흡으로 처음부터 제품을 실수 없이 완전하게 만든다는 것 또한 아주 힘든 일이다. 즉, 무엇인가를 만드는 과정에서 불확실성을 배제할 수 없으며, 실패 가능성을 안고 갈 수밖에 없다.
그래서 우리는 점진적으로 제품을 만들며 반복적으로 개선하는 방법론들을 채택하곤 한다. 대표적으로 애자일Agile 같은 것들. (소프트웨어 공학을 전공하다 보면 '나선형 모델' 등 다양한 개발 방법론을 함께 배운다고 한다. 나는 잘 모름)
아래 사진은 애자일하게 제품을 개발하기 위해 사용되는 대표적인 프레임워크, 스크럼의 프로젝트 수행 과정을 도식화한 것이다. 요구사항 수집으로 시작해서, 백로그 그루밍을 통한 백로그화, 그리고 스프린트 후 리뷰와 회고 과정을 확인할 수 있다.
조대협의 소프웨어 개발과 테스트 그림 1-5 스크럼 방법론 개념 ⓒ 조대협 님 블로그2.
IT 씬에 발을 처음 들일 때 나의 주 무대는 스타트업이었다. 배포를 하루 이틀 단위로 진행하며 무자비한 반복도 해보고, 1년 정도 걸린 리뉴얼 프로젝트를 진행하며 거대한 폭포를 함께 거치기도 했다.
두 개발 방식으로 모두 프로젝트를 진행해 봤을 때 기억에 남는 공통적인 어려움은 역시 리스크 관리였다.
배포 주기가 짧고 무규칙에 가까워질수록 동료들의 멘탈 케어가 문제였고, 한 번에 개발하는 범위가 커질수록 일정과 기획부채에 대한 해소가 문제였다. 아마 그때부터 적절한 주기, 업무의 리듬감에 대해서 고민하게 된 듯하다.
현재는 스프린트를 통해 업무를 리듬감있게 운영하는 조직으로 넘어와서 그런지 글에 더 공감되는 내용이 많았다. 가장 공감된 것들은 본문에 나오는 1) 서비스 개발 파이프라인(보편적으로 말하는 개발 프로세스)의 필요성이나 2) 콘텍스트 스위칭으로 인해 발생하는 업무 비효율 같은 것들.
3.
위에서 애자일에 대한 장점을 많이 말하긴 했지만 유의해야 하는 것은, 언제나 점진적이고 반복적인 개발 방법론이 회사에게 적합할 수는 없다는 것이다. 어떤 곳에서는 폭포수 형태로 개발하는 것이 더 효율적이고, 효과적일 수 있다. 예를 들어 SI와 같은 에이전시들. 항상 환경에 맞춰 적합하고, 효율적인 방법을 사용할 수 있을 정도의 지식이 필요하다고 생각한다.
http://www.chidoo.me/index.php/2023/09/23/rythmical-collaboration-sprint/
#2 협업을 위한 좋은 커뮤니케이션 파이프라인
#커뮤니케이션 #의사소통
협업은 대부분의 일을 하기 위해서 필수적인 행위이다.
특히 '기획자'라는 직군에 속해있는 만큼 타인과의 협업은 필수적일 수밖에 없으며, 이 때문에 나는 항상 타인과 관계를 잘 형성하고, 커뮤니케이션을 잘하는 것에 관심을 가진다.
올해 이직을 하며 조직의 규모가 커졌는데, 조직의 규모가 커질수록 가장 신경 쓰이는 부분 또한 역시 커뮤니케이션이었다. 함께 얘기를 하거나 얼라인을 맞춰야 하는 사람이 늘어나면 늘어날수록 커뮤니케이션의 비용의 수확체증이 발생하기 때문이다.
이해하고 설득해야 하는 사람, 의견을 주는 사람 등 다양한 사람과 커뮤니케이션을 해야 하는데, 사람들의 성격은 모두 다르고, 그들마다 가지고 있는 가치관과 말투, 받아들이는 태도 등 많은 것이 다르다. 이로 인해서 항상 커뮤니케이션을 위해 적지 않은 노력과 시간 등 비용을 소모하게 된다.
그래서 나부터 먼저 실천하고 있는 것은 명문화하고, 시각화하는 것이다. 빠르게 확인하고 싶거나 구두로 얘기했을 때 더 수월한 것들(텍스트로 맥락을 설명하는데 시간이 오래 걸리는 것들)은 관계자에게 양해를 구하고 구두로 소통하곤 한다.
단, 얘기가 끝나면 꼭 내용을 텍스트로 정리해서 공유한다. 1) 내가 이해한 것이 정확한지 확인하는 것과 2) 기록을 남기는 것이 두 가지 이유다. 그리고 되도록 공개적인 곳에 올린다. 컨플루언스에 문서를 남기든, 팀즈의 팀 채팅방에 내용을 올리든 커뮤니케이션이 둘 사이에서만 일어난 일이 아니게 만들어 정당성과 투명성을 챙긴다.
장점은 1) 잘못된 이해로 발생할 수 있는 리스크를 줄일 수 있는 것과 2) 신뢰 있는 이미지를 줄 수 있다는 것. 하지만 단점으로는 1) 이해한 내용을 텍스트화하는 것에서 발생하는 시간 비용이 존재하고, 2) '틀리면 어떡하지'하는 불안감이 생길 수 있다.
그래도 꾸준히 실천하려고 하려고 한다. 이것들이 모여 좋은 커뮤니케이션 파이프라인의 첫 단계를 만들 수 있을 것이라고 생각하기 때문이다.
#3 우선순위는 매겼는데, 그래서 어떻게 해야 하지?
#우선순위 #규칙
우선순위에 대한 프레임워크를 학습하고, 몇 개를 돌려서 사용해 보면서도 항상 드는 고민은 '그래서 우선순위는 매겼는데, 그래서 어떻게 해야 하지?'에 대한 것이다.
생각해 보면 ICE, RICE, BRICE, MosCow 등의 프레임워크는 '우선순위를 잘 세우기 위한' 프레임워크다. 근데 그 우선순위가 어떤 업무에 매겨지는가에 따라서 우선순위만으로는 해결 안 되는 것들이 존재한다. 예를 들어서 우선순위를 실무자가 진행해야 하는 업무 스케줄에 부여한 경우가 있다. (우선순위와 종료기한이 동시에 존재하는 것들)
나 또한 실무를 하며 우선순위와 종료기한이 혼재할 때 우선순위의 존재가 희미해지는 경험을 몇 번 했는데, 이 때문에 개인적으로 우선순위를 매긴 이후 활용하기 위해 규칙을 세웠다.
우선 전제는 아래와 같다.
1. 각 작업에는 종료기한이 정해져 있어야 한다.
2. 종료기한과 우선순위는 별개로 취급한다.
당연히 우선순위를 설정하는 순간에는 해당 시점에 예상한 종료기한(공수)을 고려해서 설정한다. 하지만 종료기한과 우선순위를 별개로 취급하는 이유는 우선순위가 종료기한에 끌려다니는 것을 막기 위함이다.
종료기한이 촉박한 업무는 우선순위가 낮더라도 종료기한이 여유로운 업무보다 빨리 해야 한다고 생각하기 때문이다. 이때 종료기한과 우선순위를 별개로 취급하지 않으면, 종료기한에 가까워질수록 우선순위를 격상시키는 현상이 발생할 수 있기 때문이다.
그러면 종료기한과 우선순위가 별개로 취급한다고 할 때, 우선순위가 우선순위로써의 의미를 가지는 순간은 언제일까? 우선순위가 매겨졌을 때? 혹은 종료기한이 겹친 업무가 2개 이상일 때? 고려할 수 있는 경우가 많을 것이다.
그래서 이를 여러 개의 케이스로 나눠봤다.
1. '우선순위 높은 업무'가 '우선순위가 낮은 업무'보다 종료기한이 촉박한 경우
- '우선순위가 높은 업무'를 먼저 처리한다.
2. '우선순위 낮은 업무'가 '우선순위가 높은 업무'보다 종료기한이 촉박한 경우
- 종료기한까지의 여유일자에 따라 다르게 처리한다.
- 예시 1) '우선순위 낮은 업무'의 종료기한이 오늘이고, '높은 업무의 종료기한'이 내일일 때 → 우선순위가 낮은 업무부터 처리한다.
- 예시 2) '우선순위 낮은 업무'의 종료기한이 내일이고, '높은 업무의 종료기한'이 하루 이상 남았을 때 → 우선순위 낮은 업무의 예상 공수에 따라 다르게 처리한다.
3. '우선순위가 높은 업무'와 '우선순위가 낮은 업무'의 종료기한이 동일한 경우
- '우선순위가 높은 업무'를 먼저 처리한다.
4. 종료기한인 오늘인 업무가 여러 개인 경우
- 종료기한이 오늘인 업무들 중에서 '우선순위가 높은 업무'를 먼저 처리한다.
- 종료기한은 동일하지만, 종료 시간이 다른 경우 다른 경우 → 더 일찍 끝내야 하는 업무 먼저 처리한다.
- 우선순위가 모두 동일한 경우 → 자신이 더 효율적으로 처리할 수 있는 업무부터 처리한다. (빨리 끝나는 일부터 처리하든, 집중을 요구하는 일부터 처리하든..)
이를 기준으로 역으로 우선순위를 매기는 순간을 생각해 보면, 우선순위를 매길 때는 1) 작업 공수, 2) 난이도, 3) 작업의 중요도가 함께 고려되어야 한다는 것을 알 수 있다.
그리고 이 프레임워크가 잘 동작하기 위해서는 1) 작업 공수 파악이 잘 되어야 하고, 2) 변동되는 작업에 대해서 빠르게 업무 관리 시트와 동기화 작업이 필요하다.
현재 나는 업무를 진행할 때 우선순위를 세운 이후 위의 기준을 통해서 할 일들을 진행하고 있다. 사용해 보며 느끼는 장점은 종료기한이나 실제 진행 중인 업무에 따라 우선순위를 변경(동기화)할 필요가 줄어드는 것. 즉, 일관된 우선순위의 기준을 쭉 가지고 갈 수 있다.
지금은 내 업무 관리에 있어서 저 기준이 잘 동작하고는 있는데, 고려하지 못한 상황이 언제든 튀어나올 수 있기 때문에 주의가 필요하다.
#4 디자이너스 토픽
#디자이너스 #A/B
나는 예쁜 디자인, 사용하기 편한 디자인을 되게 좋아한다. 그래서 보다가 꽂히거나, 나중에 화면 설계 시 사용할 수 있을 것이라고 판단한 레퍼런스를 꾸준히 수집하고 있다.
평상시 디자인을 구경하는 사이트는 아래 정도가 있다.
https://refero.design/
https://wwit.design/
https://designus.io/
https://designcompass.org/magazine/
https://www.behance.net/
https://www.pinterest.co.kr/
이번 주제는 저 중에 디자이너스에 대한 것이다.
디자이너스는 디자이너들을 위한 커뮤니티다. 그중 재밌는 공간은 '토픽’이라는 공간이다.
디자이너스의 토픽 ⓒ 디자이너스세상에는 같은 목표를 달성하기 위한 여러 형태의 디자인이 존재한다. 글을 포스팅할 수 있는 서비스를 예로 들자면, 글을 포스팅할 수 있는 기능을 1) 플로팅 액션 버튼으로 만들 수도 있고, 2) 아예 기능을 메뉴로 뺄 수도 있고, 3) 혹은 상단에 따로 버튼을 만들 수도 있다.
순서대로 Starva, 네이버 블로그, 브런치 ⓒ 327roy이처럼 화면의 모든 요소들은 1) 사용자가 해당 화면에 진입하게 된 흐름과 2) 화면에서 제공하고자 하는 목적의 우선순위에 따라서 어느 정도로 기능을 강조할 것인지, 어떻게 배치할 것인지가 달라진다. 하지만 다시 생각해 보면, 이 모두 '글쓰기'라는 동일한 목표를 달성하기 위한 기능이다. (단 모두 각각의 목적은 다를 것이다. 목표와 목적은 다르다는 것을 유의하자.)
디자이너스 '토픽'은 이처럼 비슷한 목표를 달성하기 위한 다양한 종류의 기능들을 가볍게 확인할 수 있는 곳이다.
아래 사진처럼 비슷하지만 다른 UX를 줄 수 있는 것들을 가지고 A/B 테스트를 유저 투표로 진행하는 형태인데, 보통 500명 이상이 투표에 참여하기 때문에 나중에 화면을 설계할 때 꽤나 참고할만한 내용들을 확인할 수 있어서 좋다.
디자이너스의 토픽 '주민번호 입력 입력창' ⓒ 디자이너스다만 투표의 성격이나, 댓글에 작성된 내용들을 보면 알 수 있듯이 깊은 고민이 바탕이 되어 투표가 되었거나 작성되었다는 느낌보다는, 딱 보고 난 직후 직관과 경험에 의해서 판단한 느낌이 많이 든다.
위에서 작성한 것처럼 서비스의 특징과 상황에 따라 적합하게 적용할 수 있는 것이 달라지기 때문에 항상 각자의 기준을 정해놓고 참가하는 것을 추천한다. 나의 경우에는 '다양한 경우에서 사용할 수 있는 레퍼런스 확보'라는 기준을 가지고 내용을 확인한다. (그냥 '이런 것도 있구나~' 한 지식을 쌓아두는 것)
이런 레퍼런스가 머릿속과 아카이브에 하나, 둘씩 쌓이면 화면을 설계하며 어떤 기능을 추가하고자 할 때 사용자의 멘탈모델을 어림짐작하여 사용할 수 있다는 장점이 있다.
https://designus.io/topic
#5 이번 주의 아티클:
받아야 하는가, 받지 말아야 하는가
#아티클 #세일즈클루 #게이트컨텐츠
저번 컴업 행사 때 인상 깊었던 기업, 세일즈클루의 대표님이 운영하는 뉴스레터가 재밌어서 가져왔다.
이번 뉴스레터의 주제는 ‘Gated Content’. 그리고 이의 반대 관점에 대한 이야기다. Gated Content는 특정 폼을 제출해야만 내용을 읽어볼 수 있도록 문을 걸어 잠근gate 콘텐츠를 의미한다.
appboy의 게이트 컨텐츠 ⓒ appboy