타부서와 일하는 방식

새로운 회사는 언제나

회사 마다 일하는 방식이 다르다. 일하는 방식이란 광범위한 정의다. 예를 들면, 매니저에게 얼마나 업무상황을 공유해야하는지, 기획자/데이터 과학자와 어떻게 소통해야하는지, 프로젝트 매니저(PM)가 있는지, PM 이 있다면 업무 진척상황을 얼마나 자주 공유해야는지 등등, 익숙해질게 많다.

> 기획자/데이터 과학자는 요구사항을 들고 오는 사람들이다. 기획자/데이터 과학자, 개발자는 "초기 요구사항"을 "실현가능하고 고객에게 유효한 아이디어" 으로 바꿔야한다. "초기 요구사항"은 현실적으로 구현 불가능한 아이디어, 구현 가능하되 시간/금전 비용을 많이 지불해야하는 아이디어, 의미없는 아이디어 등등 변수가 가득하다.

> 프로젝트 매니저(PM)는 크고 작은 프로젝트들이 구현/운영 계획을 관리하여, 우선순위에 맞추어서 고객에게 전달할 수 있도록 기획자/데이터 과학자/개발자와 협업한다.

예를 들어, 회사 A 는 프로젝트 매니저(PM)가 없다. 일정 관리 책임은 개발자(나)에게 있으며, 개발자(나)는 타 부서와 상사에게 업무 진척상황을 소통하며 "프로젝트 전달 계획"을 수립/수정/변경해야한다.

예를 들어, 회사 B 와 회사 C는 프로젝트 매니저(PM)가 있다. 회사 B 에선 PM에게 우선순위를 물어보면 알아서 정해주었다. 예를 들어, "새로운 일은 3주 걸릴 거 같아요. 제가 사과나무 베는 일하고, 씨 뿌리는 일이 있는데 새로운 일이 들어오면 어느걸 먼저 해야하죠?" 물어보면, PM 들끼리 중요도를 결정해서 개발자(내)가 할 일을 정해주었다.

회사 C 에선 개발자(내)는 성과를 내는 주체로써 우선순위에 어떤 업무를 진행해야할지 강하게 주장가능했다. 예를 들어, "새로운 일이 3주 걸릴 거 같아요. 새로운 일이 중요도가 높아서, 이걸 우선 처리하고 나머진 미루어야해요"

이곳, 개발자(나)는 여기서 어떻게 일하는가? 위에 같은 종류의 경험을 아직해보진 못했다. 다만 이번 1월 초부터 새로운 모듈을 담당하기 시작했고, 그 내용을 요약해본다.

1. 개발자(나)는 데이터 과학자가 제시한 요구사항 문서 기반으로 부서 시니어 엔지니어들과 함께 요구사항을 검토하고 있다.

시간 순으로 회의/대화를 요약해보면

회의1. 참석자, 데이터 과학자 & 나

데이터 과학자: 요구사항이 XXXX야

데이터 과학자: 요구사항이 YYYY야

나: 아, 그래? 이건 뭐야? 저건 뭐야? 저건 저거야? 아 고마워.

나: 요구사항을 어느 정도 이해했어. 근데 내가 이 회사에선 처음이라서 회의를 이끌어가줄 수 있어?

데이터 과학자: 그래그래, 그럼 이 회의가 끝나고, 너가 해야할 TODO List 는 요거, 우리가 해야할 TODO List 는 요거. 다음에 보자!

개인 채팅. 시니어 엔지니어 & 나

나: 저쪽부서에서 이런 걸 요구했었어. 내가 회의내용을 간단히 정리했고, 질문사항을 X문서에 정리했는데 답해줄 수 있어?

시니어 SW 엔지니어: 오케이, 음... 이대로 하면 1) 고객 입장에서 불편할거 같아. 2) 우리 금전 비용이 많이 늘어날거 같아. 그런데 XXX가 맞아?

나: 오, 진짜 1) 맞는 말이다. 생각을 못했어. 2) 는 더 설명해줄 수 있어? 그리고 데이터 과학자가 XXX가 아니고, YYY라고 하네. 그런데 저쪽에서 내일 회의하재. 참석가능해?

시니어 SW 엔지니어: 2)는 X라서 Y야. 오케이. 그럼 내일 보자.

회의2. 참석자, 시니어 엔지니어 & 데이터 과학자 & 나

시니어 SW 엔지니어: "기능을 단순화시켜서 개발 기간을 단축시키자"

시니어 SW 엔지니어: "비용이 많이 들어서, 요구사항을 받아들이기 힘들다"

데이터 과학자: "왜? 그게 어려워" "아, 그렇구나."

데이터 과학자: "그럼 요렇게 바꾸는 건 어때?" "그래도 힘들어?" "왜?"

데이터 과학자: "음, 알았어. 너네 제안에 따라 한번 검토해볼께, 시간을 줘"

(회의 중) 나: 어..? 일하는 방식은 이전 회사들하고 똑같네. 시간 비용, 금전 비용이 많이 드니까 기능을 변경/축소하자고 제안하고. 아이디어 제시자는 제안내용을 재검토하네.

(회의 끝) 나: 다음에 혼자 미팅 참여할때, 이전에 하던 그대로 혹은 이전 회사에서 시니어들이 하던 대로 하면 되겠네

<... 그 외 Direct Message 로 요구사항 구체화 중>

2. 우린 프로젝트 매니저가 있다.

프로젝트 매니저: 이 프로젝트, 너가 담당하기 시작했다며? 계획을 들어볼 수 있을까?

나: 음, 나 질문이 있어. 1) 이미 매니저가 정해놓은 스케줄이 있던데 바꿀 수 있어? 2) 나와 데이터 과학자들이 요구사항을 구체화하고 있는데, 얼마나 자주 너한테 알려야해? 3) 아직 요구사항이 안나왔는데, 구현에 대한 "기간 예측"을 해야해? 4) ....

프로젝트 매니저: 음, 너 시간 있니? 미팅 한번 해보자

나: Okay

프로젝트 매니저:

- 저건 나와 너의 매니저가 "임의로" 정해놓은 스케줄이야. 지금은 너가 첫번째 단계, 디자인 문서(요구사항 구체화), 에 대해서 "기간 예측"을 해주면 돼.

- 난 너네 부서의 업무를 3가지 방법으로 공유받아. 방법1, 방법2, 방법3. 너가 업무 내용에 따라 방법을 고르면 돼.

- 지금은 첫번째 단계 "기간 예측"이 중요하고, 나머진 나중에 해도 돼. 물론 상황에 따라 바뀔 수 있어. "기간 예측
에 너무 압박감 받지마.

지금까진 이정도 경험이었다. 더 많은 정보는 이 프로젝트를 진행해가면서, 더 적어나갈지도 모른다.

내 글의 마지막은 회사 자랑으로 마무리하고 싶다. 좋은 회사의 가장 큰 장점은 동료다. 좋은 동료들 특징들을 생각나는 대로 적어보았다.

- 좋은 동료는 동료의 불안감을 이해하고 동료를 안심시켜준다.

- 좋은 동료는 "의견 조율"이 가능하다.

- 좋은 동료는 "내가 내 일만 열심히 하면 된다"고 생각하게 만들어준다.

- 좋은 동료는 상대방의 시간이 소중한 것을 안다

새로운 프로젝트를 시작한지 얼마 안되었지만, 좋은 동료들이랑 일하는 거 같다.