Day 28. 나의 일을 잘하기 위해 갖춰야 할 세 가지 역량

 

일이라고 해서 회사 업무가 떠올랐지만 앞으로의 목표는 홀로서기이기 때문에 회사에서의 일과 나의 일을 구분지어서 역량을 생각해보기로 했다.

 

---

# 나의 일

 

1) 목적의식

나의 모든 생각과 행동의 기반이 되는 것으로, 삶에 대한 태도 및 방향성이라고 할 수 있다. 삶에 목적이 없으면 어떠한 일을 하면서도 왜 해야하는지, 내가 지금 잘 살고 있는 것인지 계속 의심이 들며 집중을 할 수 없게 된다. 무기력에 빠지는 것이다. 회사는 돈을 벌어야하니 다니는 것이고 삶은 태어났으니 사는 것이 된다. 나만의 기준이 없기 때문에 남들이 좋다는 것을 따라하게 되지만 결국 큰 의미는 느낄 수 없다. 그렇게 이리저리 휘둘리는 삶을 살게 된다.

 

반면 목적이 생기면 삶을 바라보는 시선이 달라진다. 만나는 사람들과 있어야 할 환경, 하는 일을 나의 목적에 맞게 선택할 수 있게 된다. 또한 그 과정에서 무엇을 배우고 그만둬야 할지 내가 정한 방향성에 맞춰 결정할 수 있다. 중요하지 않은 일에 시간을 낭비하지 않을 수도 있고, 어쩔 수 없는 경험들에서도 어떻게든 나에게 도움이 되는 포인트를 찾아낼 수도 있다. 주변에 휘둘리지 않고 내가 '나'로 살며 '나의 일'을 잘하기 위해서는 가장 먼저 목적 의식을 가져야 한다. 종종 찾아오는 무의미함과 무기력에서 각오를 다시 잡고 앞으로 나아갈 수 있는 그런 기준을 갖는 것이 중요하다.

 

회사에서 예전부터 리더를 맡으라는 이야기를 들었다. 리더가 된다면 사람들을 관리해야하고 나의 전문성을 학습할 시간을 뺏기는 것 같아서 내키지 않았다. 계속 거부해왔지만 신규 직원들이 들어오면서 어쩔 수 없이 리더를 맡게 되었다. 어차피 해야한다면 그래도 리더십을 연습하는 거라고, 최대한 긍정적인 합리화를 해보았다. 그럼에도 불구하고 계속 고민되긴 했다. 그러다가 자기 발견을 하면서 나의 정체성과 목적을 타인에게 좋은 영향을 주는 삶으로 정한 후에 사람과 환경을 바라보는 시선이 조금 달라졌다. 동료들에게 좋은 피드백을 제공하는 것도 결국 나를 성장시키는 일임을 깨달은 것이다. 꼭 혼자 학습하여 정보나 스킬을 쌓는 것만이 성장은 아니었다. 다른 동료들과 소통하며 커뮤니케이션을 연습하고 건설적인 피드백을 제공하여 디렉팅을 해보는 것도 결국 나중에 홀로서기를 했을 때 좋은 자양분이 될 것이다. 그렇게 신규 직원들에게 잘 가이드를 해주고 실력을 끌어올리는 것도 나의 목표로 삼을 수 있었다. 이제는 혼자가 아니라 같이 잘하고 싶다.

 

목적을 가지면 80%는 성공한 것 같다. 프로덕트 디자이너의 역량에서 가장 중요한 것은 '문제 정의'라고 보았는데, 삶의 목적을 갖는 것도 문제 정의와 비슷하다. 무엇이 문제인지, 무엇을 해결해야 하는지 정확히 파악한다면 해결 방법은 자연스레 떠오르고 작게작게 실행하면서 발전시켜 나갈 수 있다. 반대로 문제 정의가 잘못된다면 아무리 문제를 잘 해결한다고 해도 무의미한 결과가 나올 것이다. 그것은 애초에 필요한 것이 아니었을테니까. 아인슈타인이 말했다. '만약 나에게 문제를 해결하기 위해 한 시간이 주어진다면, 문제를 정의하는 데 55분을 쓰고, 나머지 5분 만을 해법을 찾는 데 쓰겠다.'

 

 

* 현재 상태 : 😀

자기 발견 글쓰기를 진행하면서 나의 정체성과 목적 ver 1.0을 정할 수 있었다. '시간을 내가 계획한 대로 보내며 지속적으로 성장하고 타인에게 긍정적인 영향을 주는 삶을 사는 것' 아직 초안이기는 하지만 목적이 있는 것과 없는 것의 큰 차이는 지금 크게 느끼고 있다. 물론 완벽한 목적이라고 생각하지는 않는다. 앞으로 당연히 발전시켜 나갈 것이다.

 

* 어떻게 개발할까?

• 지속적인 회고를 통하여 내가 하는 말과 행동들이 목적과 정체성에 적합한지 체크한다. (주 1회/
• 내가 살고 싶은 삶을 사는 사람들은 어떤 목적으로 살아가는지 찾아보기

 

 

2) 실행력

목적을 달성하기 위해서는 행동해야한다. 모든 것은 실행했을 때 의미가 있다. 고민과 생각, 계획만 주구장창 세운다고 목적을 달성할 수 없다. 새로운 도전은 두려움과 걱정을 수반한다. 준비성이 좋은 것은 좋지만 완벽한 계획을 세우고 실행하려는 생각은 오히려 아무것도 하지 않게 만든다. 세상에 완벽한 것은 없기 때문이다. 

 

애자일 문화라는 것이 있다. 상품 또는 서비스의 MVP(Minimum Viable Product, 최소 기능 제품)을 정하여 빠르게 시장에 선보인 후 고객의 피드백을 받아 지속해서 개선해나가는 방법이다. 반대로 철저한 계획을 세우고 완벽하다고 생각하는 상품과 서비스를 최종적으로 제공하는 것은 워터풀이라고 한다. 예를 들어 이동수단을 만든다고 했을 때 킥보드를 만들어 제공하고 그 다음은 자전거, 오토바이, 자동차로 개선해 나가는 것이 애자일 방식이다. 다소 느리지만 킥보드를 타고 걸음보다는 빠르게 이동할 수 있다. 고객이 프로덕트를 이용하는 과정에서 얻은 피드백은 다음 프로덕트를 개선하는데 참고할 수 있다. 워터풀 방식에서 고객은 자동차가 나올 때까지 아무 효용도 얻을 수 없다. 심지어 완성된 자동차의 상태도 고객의 피드백을 반영한 애자일 자동차와 아무런 피드백도 받지 못한 워터풀 자동차는 차이가 있을 것이다.

 

상 : 워터풀 / 아래 : 애자일

 

지금 만큼 많은 것이 빠르게 바뀌는 시대는 없었다. 하루가 멀다하고 새로운 기술과 정보들이 생겨난다. 따라서 특정 시기의 고객의 니즈에 맞춰 철저한 계획을 세우더라도 그것을 실행할 때는 결국 고객의 니즈는 달라져있을 것이고 의미 없는 상품과 서비스로 전락해버리고 만다.

 

나도 그렇다. 어제의 나와 오늘의 나는 다르다. 몇 년 전의 나와 비교하면 훨씬 심하다. 당연히 목적과 계획도 조금씩 바뀐다. 따라서 계획만 계속 세우다 보면 아무것도 해보지 않고 결국 흐지부지될 확률이 높으며, 고객의 피드백을 받아서 개선할 기회도 놓치게 된다. 다른 사람들에게 긍정적인 경험을 제공하고 싶다는 것이 나의 목표인 이상 당연히 사람들에게 많은 것을 제공하고 피드백을 받아 개선해나가야 한다. 고민만 하며 많은 시간을 소요한다면 그것은 계획을 세우며 시간을 보낸 것이 아니라 사람들과 소통하며 발전할 수 있는 시간을 버리고 있는 것일 수도 있다.

 

아는 것이 힘이라는 말은 틀린 말이다. 바르게 말하면, 아는 것은 실제로 적용될 때만 힘이 된다. 그러므로 지금 당장 강력한 목표를 세우고 실천해라.

- 보도섀퍼 <돈>

 

* 현재 상태 : 😥

작은 것들은 다름 실행하는 편이지만 큰 이슈들은 여전시 도전 정신이 좀 부족하다. 왜 쉽게 실행하고 도전하지 못할까. 아마 아직 능력이 부족하다는 것과 실패할 것 같은 두려움 때문인 것 같다. 능력을 충분히 쌓고 무언가 하겠다는 것은 완벽한 계획을 세우고 하겠다는 것과 비슷하다. (워터풀...) 따라서 해결해야 할 것은 '완벽하게 하려는 강박 버리기'과 '실패에 대한 두려움'인 것 같다.

 

* 어떻게 개발할까?

• 빠르게 실패하기를 목표로 삼기
• 나는 부족하고 불완전한 사람이라는 것을 인지하기
• 도전과 실패, 개선의 과정을 하나의 컨텐츠로 만들어보기 (사람들은 완벽을 바라는 것이 아니다.)
• 챌린지 프로그램에 계속 도전하기
• 하고 싶은 것이 있다면 루틴으로 등록하고 꼭 지키기 

 

 

3) 지속력

목적을 향해 꾸준하게 실행하고 성장할 수 있어야 한다. 인생은 단거리 달리기가 아니라 장거리 마라톤이라고 했다. 사람은 몇 달, 몇 년을 반짝 살고 끝나지 않는다. 별거 아니라고 생각하는 하루들이 모여서 내 인생을 만든다. 물론 하루가 별거라는 말은 아니고. 여하튼 목적을 위하여 계획한 하루하루가 쌓이면서 내가 원하는 방향성과 정체성에 맞게 살 수 있다.

 

목적을 향해 조금씩 나아간다는 것 외에 꾸준함의 장점은 여러가지가 있다. 무기력에서 빠르게 빠져 나올 수 있는 것, 꾸준히 하면 분명 이전보다 나아진다는 확신, 새로운 도전에 진입장벽 낮추기 등. 특히 꾸준히 했을 때 발전할 수 있다는 확신이 가장 큰 이점인 것 같다.

 

예전부터 글쓰기를 잘 하고 싶었다. 글을 써보자고 다짐을 하고 컴퓨터를 켰다. 머리는 백지장이었고 화면도 백지였다. 아직 준비가 되지 않았다며 책을 더 많이 읽고 어휘력이 쌓이면 글을 써야 겠다고 생각했다. 그리고 나는 왜 이렇게 무능력한 인간일까 자기비하를 하면서 시간을 보냈던 적이 있다. 참 아이러니 한 것이 글을 잘 쓰고 싶다면 글을 계속 쓰면서 실력을 늘려야 했는데 글을 잘 쓰게 되면 글을 쓰겠다고 생각한 것이다. 영어를 잘하게 되면 영어 공부를 하겠다는 것과 뭐가 다를까. 그렇게 다짐만 하고 실행하지는 않으며 많은 시간을 허비했다.

 

그러다 그림 그리기 습관을 연습한 이후에 꾸준히 한다는 것에 살짝 자신감이 생겨서 일기를 꾸준히 쓰는 것을 목표로 잡았다. 쓸 것이 없으면 그냥 눈 앞에 보이는 사물이라도 나열해보자고. 물론 초반에는 꾸준히 하다가 다시 흐지부지 되었다. 그래도 이렇게 여러번 시도한 끝에 지금은 티스토리에 약 150일간 글쓰기를 지속하고 있다. (초반에는 그냥 포스팅 느낌이 강했지만...) 이전과 확실히 달라지는 것은 이제 글을 쓰는 것 자체가 그리 어렵지 않다는 것이다. 의식의 흐름 기법으로 막 쓸 수 있는 정도까지는 발전했다. 앞으로의 목표는 '잘' 쓰는 것이다. 이는 또 많은 시행착오를 겪어야하겠지. 그래도 이 과정이 성장통이라는 말을 들어서 위안이 되었다. 발전하지 않으면 힘들지도 않을 거라고.

 

notion

일기 쓰기 습관을 만들자고 다짐하고 노션에 기록을 시작했다. 물론 반짝 꾸준히 한 날도 있지만 거의 흐지부지 되었다. 2년 간의 흐지부지 끝에 조금 꾸준한 글쓰기 습관을 만들어낼 수 있었던 것 같다. 습관은 앞으로도 계속 발전시킬 것이다.

 

성공한 것 같아 보이는 사람들도 자신의 성공에 대하여 이야기를 할 때 많은 도전과 실패를 했다고 했다. 우리가 보기에 성공한 모습만 바로 봤기 때문에 그 사람은 능력이 출중하고 운이 좋다고 생각할 수도 있다. 하지만 그 아래에는 수많은 노력의 시간이 견고하게 받쳐주고 있다. 종종 유투브에서 노력도 재능이라는 말을 보게 된다. 내가 가장 싫어하는 댓글 중 하나다. 이는 상대방의 노력과 인고의 시간을 무시하는 것이며 또다른 사람의 의지를 꺾는 말이다. 물론 그들이 그렇게 말하는 이유는 안다. 자신이 노력하지 않는 것을 합리화하고 싶기 때문에. 설사 실제로 노력도 재능이라고 해도 나는 그렇게 믿지 않은 생각이다. 그리고 꾸준히 노력할 것이다. 실패도 많이 하면서.

 

실수는 좋은 것이다.

우리는 실수에 대한 두려움 없이 행동해야 한다. 우리는 실수하지 않는 사람이 되고자 할 것이 아니라 포기하지 않는 사람이 되어야 한다.
 
전구를 발명한 토머스 에디슨이 9,000번 정도 실패를 거듭하고 있었다.
"나는 실수를 하고 있는 게 아니라 전구를 발명할 수 없는 새로운 방법을 계속 배우고 있는 거라네. 매번 실수는 나를 점점 더 발명에 가까워지게 하고 있다네."

- 보도섀퍼 <돈>

 

 

* 현재 상태 : 😊

* 어떻게 개발할까?

지금도 꾸준하게 하는 것은 루틴 프로젝트를 진행하여 어느 정도 잘 하고 있다고 생각한다. 그러나 이전까지는 안하는 것보다 하는 것이 나으니까 하고 있는 수준이었다. 다음 목표는 삶의 목적에 근거한 루틴을 만드는 것이어서 며칠 전에 루틴 항목을 개선하기도 했다. 그리고 실행하면서 계속 발전시켜 나갈 예정이다.

• 목표/정체성에 기반한 항목으로 구성한다.
• Key result를 정해본다. 목표를 향해 제대로 가고 있는지 수치적으로 확인할 수 있게 개선한다.
• 지속적인 회고를 통하여 잘한 점, 그만둘 점, 시도해볼 것을 체크하여 개선한다. (주/월 단위)

---

# 회사에서의 일

 

1) 문제 정의

직군과 상관없이 가장 중요하다고 생각하는 역량은 문제 정의다. 앞서 말했듯이 잘못된 문제를 탁월하게 해결하는 것은 의미가 없다. 애초에 그것은 문제가 아니었으니까. 시간과 자원을 낭비하고 결국 고객이 원하지 않는 서비스와 상품을 시장에 내놓는 격이다. 예쁜 쓰레기라고 해야할까. 문제만 잘 설정한다면 80%는 해결했다고 본다. 진짜 문제는 뭐가 문제인지도 모르는 것이다. 

 

문제 정의는 책임감 및 성장과도 연관되어 있는 것 같다. 회사에서 시킨다고, 기획자가 만든 기획이라고, 디자이너가 만든 디자인이라고 비판적인 의식 없이 그저 받아들이기만 한다면 스스로를 도구처럼 여기는 것과 다름없다. 경영자의 선택이나 기획자, 디자이너, 개발자, 마케터가 아무리 자기 직군의 전문가라고 하더라도 실수를 할 수 있으며 때로는 직급, 직군과 상관없이 더 좋은 생각을 가지고 있을 수 있는 것이다. 상대가 의견을 받아들이는 태도와는 별개로 스스로 지금 해결해야하는 문제가 정말 문제있지, 고객과 세상에 가치를 전달할 수 있는 것인지 생각을 꼭 해봐야한다. 그리고 역으로 제안을 할 수 있어야한다. 문제가 잘못된 것 같다고. 고객은 이것을 원하는 것이 아니라고. (나에게 하는 말)

 

회사를 다니더라도 도구가 아니라 인간으로서 일을 하고 성장하려면 문제 정의를 잘 해야한다. 무언가 주어졌을 때 어떻게(How) 할지 보다는 왜(Why) 해야 하는 지에 생각해보자.

 

사이먼 시넥의 골든 서클

 

예전에 주문 플로우에 새로운 서비스를 제안하는 프로젝트를 진행한 적이 있다. 주문에 기능이 추가되면 플로우가 복잡해지며 구조도 많이 손봐야하기 때문에 공수가 커진다. 팀장님은 타팀과 다 동의한 기능이라고 말했다. 다들 동의를 했고 나도 언뜻 봤을 때는 있으면 괜찮을 것 같다고 생각했다. 그렇게 기획과 디자인을 하며 관련 부서와 수차례 피드백을 주고 받으며 프로젝트를 완료했다. 나는 대략 3-4주가 걸린 것 같고 개발은 1분기가 소요된 것 같다. 기획까지 나왔을 때 거의 모두가 좋다고 했었다.

 

그렇게 배포된 신규 서비스는 지금 아무도 사용하지 않는 고물 서비스가 되었다. 고객이 정말 원하는 서비스도 아니었고, 고객의 이용이 적어 담당 부서에서도 많은 비용을 쓸 수 없다며 대응을 하지 않았다. 뭐하러 그렇게 플로우를 고민하고 스트레스를 받았는지 허무해졌다. 시간과 감정을 소비했지만 결과적으로는 성과도 없는 완전 실패 프로젝트였다. 시간 낭비하지 않으려면 시키는 것을 그대로 하면 안된다고 느끼게 되었다. 아무리 돈을 받고 일을 한다고 하지만 진행한 프로젝트의 성과가 있어야 몰두한 내 시간과 자원에 보람이 있는 법이었다. 월급을 받으니까 상관없다고 생각한다면 정말 시간을 팔고 있는 것이다. 물경력이 되지 않으려면 주도적으로 업무에 임해야 한다. 시간은 버리고 성과는 안났지만 이렇게 느낀 것 자체로 일종의 성과인 것 같기도 하다. 위에서 실패를 통해서 배운다고 했으니까. 

 

최근 고객의 니즈 관련하여 좋은 글을 보게 되었다. 니즈는 크게 3가지가 있으며 직접적으로 드러나는 표현 니즈, 속으로 숨이고 있는 내면 니즈, 본인이 원하는지도 모르는 잠재 니즈가 있다고 했다. 

03화 '니즈'의 3가지 종류(UX)

앞으로 누군가 A를 요청하면 A를 제공하는 것이 아니라 진짜 니즈가 무엇인지 한 번 더 체크해봐야겠다. A를 요구하는 것이 꼭 A로 해결하는 것이 정답이 아니며 더 좋은 해결 방법이 있을 수도 있다. 또는 자신도 뭐가 문제인지 몰라서 그냥 바로 생각나는 A로 요청을 할 수도 있으니. '어머님은 짜장면이 싫다고 하셨어'와 같은.

 

 

* 현재 상태 : 🤔

중요성은 알지만 아직 잘 하고 있는지는 모르겠다. 

 

* 어떻게 개발할까?

• 이슈 진행하기 전 목적에 대하여 심사숙고하기
• 표현 니즈, 내면 니즈, 잠재 니즈 구분지어서 생각해보기
• 문제 정의를 잘해서 가치 있는 서비스를 만들어 낸 프로젝트 찾아보기
• 고객분석방법 배우기
• 기존에 배포된 서비스 데이터 분석 요청해서 고객 이용 체크해보고 개선해보기
• 어쩔 수 없이 진행해야 하는 이슈인 경우 스스로 의미 부여해보기

 

 

2) 전문성

문제가 잘 정의되었다면 이제 각자의 전문성을 살려서 문제를 잘 해결해야한다. 전문성에는 정보와 기술, 사고력이 중요하다. 직군마다 요구되는 정보와 기술은 다르다. 그래서 직군이 나뉘는 것이고. 전문성을 기르기 위해서는 내가 무엇을 알고 모르는지 메타인지가 중요한 것 같다. 그래야 부족한 부분을 채워가며 뾰족한 전문가로 성장할 수 있다. 사실 직장에서 일을 하면서 전문성이 부족하다는 것은 직무유기가 아닐까? 따라서 자신의 능력을 객관적으로 파악하고 키울 필요가 있다. 사수가 있으면 좋겠지만 사수가 있다고 해도 좋은 사수가 아닐 수 있기 때문에 스스로 자신을 파악하고 꾸준히 학습하는 능력이 중요한 것 같다.

 

최근에 꽉막힌 사람은 전문성을 기르기 어려울 것 같다는 생각이 드는 영상을 보았다. 포트폴리오를 첨삭해주는 유투버가 있다. 10년차 디자이너분이 시청자를 몇몇 선택하여 그들의 작업물을 컨펌해주며 직접 개선 작업을 해주는 것이다. 요청자는 거의 신입 또는 1-3년가 주니어가 많았던 것 같다. 한 영상에서 주니어가 자신이 직접 컨펌을 요청했으면서 시니어 분이 피드백을 주고 개선 작업을 하는 내내 이상하다고 따박따박 메시지를 보냈다. 사실 누가 봐도 주니어 디자인은 투박했고 시니어 디자인은 깔끔했다. 시니어 분이 글로벌 사이트의 레퍼런스를 보여주며 디자인의 논리에 대해 설명해도 받아들이지 못했다. 이런 주니어가 우리팀 팀원이 아니어서 다행이었다. 자신이 무조건 옳다는 편협함은 성장을 가로 막는다. 배우려는 의지와 상대방 의견을 수용하는 능력이 성장과 전문성 강화에 중요한 것 같다. 역시 뭐든지 태도가 중요하다.

 

 

* 현재 상태 : 😗

중간 정도. 얼마전에 프로덕트 디자이너의 역량을 구체화 시켰다. 이제 발전시켜 나가야 한다.

 

* 어떻게 개발할까?

• 매일 프로덕트 디자이너 컨텐츠 보고 기록 남기기
• 매일 새로운 서비스 살펴보고 기록하기
• 보다 어려운 이슈 맡아서 진행해보기
• 내 서비스를 기획하며 전문적인 글 작성해보기
• 글로벌 서비스의 프로덕트 디자인 아티클 보기

 

 

3) 협업 / 커뮤니케이션

탁월한 문제 정의와 전문성을 갖췄다면 그 다음으로는 동료와 협업하여 목표를 달성해야 한다. 모든 것을 완벽하게 잘 하는 사람은 없다. 있다고 하더라도 사람에게 주어진 하루는 24시간이 동일하다. 직장은 다양한 사람들이 자신의 전문성을 살려서 빠르게 하나의 목표를 향해 나아가는 조직이다. 철저히 분업화 되어서 맡은 바 자신이 일에 집중하면 뛰어난 프로덕트가 만들어지게 된다. 당연히 서로 간의 협업이 중요하다. 디자이너, 개발자, 마케터, CS 등등.

 

예전에 입사 초기에 개발자와 소통하는 것이 힘들었다. Api, 데이터, 어드민, 알 수 없는 영어들. 질문을 하면 난해한 답변이 따라왔다. 그래서 회사 문화로 '비개발자 언어로 소통하기'라는 것도 생기기도 했다. 타팀과 소통할 때는 자기 직군에서만 알 수 있는 단어는 최대한 지양하고 일반적인 언어를 쓰는 것이 중요하다. 특히 경력이 많을 수록 조심해야 한다. 내가 당연하게 알고 있는 것을 다른 사람도 당연하게 알고 있다고 생각하는 것을. 항상 상대방의 입장을 생가하며 소통하는 능력을 키워야한다. 

 

커뮤니케이션을 PM의 권한이라고 생각하면 안 된다. 자기 할 일만 완료 했다고 일을 잘 하는 것이 아니다. 내 일만 한다고 프로덕트가 나오는 것은 아니기 때문에. 실제로 고객이 좋은 서비스를 접할 수 있는 단계까지를 내 일로 생각해야한다. 이 부분에서는 반성하는 프로젝트가 있었다. 알림 시스템에 관한 프로젝트를 진행하고 있었는데 기획과 디자인을 완료한 후 프론트, 백엔드 리더와 모여서 회의를 진행했다. 각 팀에서 해야할 것들을 정리하고 회의를 끝냈다. 각 리더는 담당자에서 해당 이슈를 설명하며 부여했다. 한동안 아무 질문도 없어서 알아서 잘 하고 있겠거니 생각을 했다. 그러나 결론적으로 총제적 난국인 프로젝트가 되었다. 백엔드는 최근에 입사한 외국인 개발자가 맡게 되었는데, 한국어가 서툴러서 계정 관련하여 전혀 의도하지 않은 구조를 만들었고 프론트 개발자는 백엔드에서 처리를 안해줘서 못하고 있었다고 했다. 그렇게 계속 수정하고 수정했다. 나도 기획 초기에 생각하지 못한 케이스가 나중에 나와서 배포가 된 후에도 UX가 불편한 서비스가 되었다. 별거 아니라고 생각했던 기능이 몇개월이 걸렸지만 엉망인 결과로 나온 것이다. 

 

나는 개발을 잘 모르기 때문에 프론트 작업자가 필요한 것이 있으면 백엔드에 잘 요청하여 처리하여 진행될 줄 알았다. 처음 회의 했을 때 리더들이 담당자에게 해야할 것들을 잘 설명한 줄 알았고. 주기적으로 체크하지 못한 나도 잘못한 것이 많았지만 커뮤니케이션은 뒤로 하고 내 일만 한다는 수동적인 태도의 개발자 분들도 협업하지 좋은 동료는 아니었던 것 같다. 여기에는 일만 있었고 고객은 없었다. 

 

반면 최근에 진행한 프로젝트는 협업이 잘 됐다고 생각한다. 개발자 분이 먼저 나서서 정기 회의를 갖자고 했다. 주마다 기술 스펙과 현재 진행된 단계를 논의하자고. 프론트, 백엔드 분 모두 적극적이었다. 문제를 스스로 찾으면서 개발적으로 필요한 부분이 있으면 별다른 요청을 하지 않아도 알아서 개발해주었다. 문제 정의도 잘 하고 전문성도 좋으신 분들이었다. 각자 중간중간에 논의 사항이 있으면 슬랙을 통하여 바로바로 공유를 했다. 그 덕에 나도 내가 할 일에만 집중할 수 있었다. 수동적인 개발자였다면 또 했는지 안 했는지, 안되었으면 왜 안되었지 등등 불필요한 커뮤니케이션 비용이 증가되었을 것 같다. 나는 앞으로도 이런 분들하고만 일하고 싶다. (불가능 하겠지만 빌어봐야지...)

 

 

* 현재 상태 : 😥

많이 부족하다고 생각한다. 리더 역할을 잘 수행하고 동료 개발자들과 최대한 소통하면서 앞으로 커뮤니케이션 스킬을 올려봐야겠다.

 

* 어떻게 개발할까?

• 이슈 적극적으로 공유하기
• 긴 프로젝트면 먼저 정기 회의 만들고 진행하기
• 스터디 꾸준히 운영하기

 

---

# 기타 이것저것