같이 일하고 싶지 않은 개발자 특
앞으로도 쭉- 만나고 싶지 않은 개발자의 유형을 정의하고 경험을 공유한다
경력이 길어질수록 많은 협업자들을 만나는데, 그중 가장 많이 만나고 많은 커뮤니케이션을 하는 게 개발자다. 주니어 시절, 개발자와 커뮤니케이션하고 그들을 설득시키는 과정이 참 어렵게 느껴졌다. 당시에는 '내가 어리고, 연차도 낮아서'라고 생각했는데 미들, 시니어가 되어서도 힘든 때가 있는 것 보니 단순히 경력이 적은 기획자의 문제는 아니라는 생각이 들었다. 그래서 주니어 시절부터 시니어 시절까지 10년 넘게 일하며 만났던 개발자 중 어떤 개발자와 일할 때가 가장 힘들었는지 곱씹어보니 참 다양한 케이스를 많이도 만났다.
이번 편에선 기획자, PO로 일하면서 내가 만났던 '힘들었던' 그리고 '앞으로도 만나고 싶지 않은 개발자'들의 특징에 대해 이야기하고자 한다. 이 글은 그동안 업무를 하며 내가 직접 겪었던 '소수의 일부 개발자'들에 대해 기재한 글이고 특정 개발자를 저격하거나 폄훼하려는 글이 아니라는 점을 참고하길 바란다. (+이 글을 읽는 개발자 중엔 아래와 같은 유형이 없을 것이라고 생각한다)
"근거가 뭐예요? 저는 이해가 안 되는데요. 개발 진행 못 하겠어요"
본인이 개발자인지, 기획자인지, 관리자인지 헷갈려하는 'R&R 착각형'
출처 : Giphy가장 만나기 싫은 유형 남바완(No1)이다. 4년 차 주니어에서 미들급으로 넘어가는 시점에 그동안 내 글에서 많이 언급했던 '지독한 패션회사'에 있을 때 처음으로 만났던 유형이다. 그 당시 회사는 워터풀 방식으로 진행이 되어 기획팀과 개발팀이 쪼개어져 있었다. 업무 하는 프로세스는 기획 완료 후 상급자에게 컨펌받고 개발에 요청하는 방식이었다. 모든 팀원이 참석한 아이데이션 미팅 때 A라는 프로젝트를 하기로 합의가 되었고 방향성에 대해서도 결정이 되어 기획서를 꼼꼼하게 작성하고 상급자에게 컨펌을 받았다. 그리고 개발일정 산정을 위해 메이커스를 초대하여 미팅을 잡고 기획서 리뷰를 진행했다. 기획서 리뷰가 끝나자 한 개발자가 질문을 했다.
개발자: 기획 의도가 뭐예요?
나 : 기획 의도는 앞에서 설명드린 것처럼 ~~~ 입니다.
개발자 : 잘 이해가 안 되는데요
나 : 어떤 부분이 이해가 안 가세요?
개발자 : 그냥 전체적으로 납득이 안 되는데요.
나 : 어떤 부분이 납득이 안되세요?
개발자 : 저 기능을 굳이 만들어야 하는지 모르겠어요.
나 : 왜 그렇게 생각하세요? 저는 ~~ 이러한 근거로 이 기능이 꼭 필요하다고 생각하는데 과장님이 생각하시기엔 왜 이 기능이 필요 없다고 생각하시는지 말씀해 주실 수 있으실까요?
개발자 : 그냥 제가 보기에 필요 없는 기능 같아요. 동의가 안 돼서 개발 못 할 것 같아요
대충 이런 대화가 두세 번쯤 이어지면 속에서 열불 천불이 올라오기 시작한다. 기획 의도가 무엇인지, 근거가 무엇인지 등에 대한 질문? 충분히 할 수 있다. 근데 위 대화의 흐름을 보면 저 개발자는 그냥 '별 근거 없이, 그냥 본인이 하기 싫다'의 느낌으로 답을 한다. 그리고 대안을 물어보면 대안도 없다.
대안 없는 비판과 시비일 뿐이다. 또 '동의가 안 돼서 개발을 못하겠다'는 것은 내가 느꼈을 때 월권이었다.
이미 팀원 전체와 합의된 기능이었고, 상급자에게도 컨펌을 받았는데 본인이 뭔데 이래라 저래라인지 모르겠지만 그 당시 나는 '대리'였고 저 사람은 '과장'이었다. 나중에는 본인이 본인의 입으로 '나에게도 컨펌을 받아야 개발을 할 수 있다'라고 말을 했다. (속으로 '개소리하고 앉아있다'라고 생각했다)
처음 만나본 개발자고, 말이 안 통해서 상급자 도움 없이 프로젝트 리딩이 힘들어져서 결국 에스컬레이션 해서 프로젝트를 진행했던 기억이 난다. 웃긴 건 '본인이 보기에 필요 없는 기능이고, 동의가 안돼 개발 못 할 것 같다'라고 말할 땐 언제고 리더가 하라니까 바로 착수하더라. 1년 반 동안 매일 같이 만나고, 매번 저 사람이랑 프로젝트하는데 진지하게 정신과에 방문해볼까 싶을 정도로 스트레스가 심했다. 퇴근 후 집에 가면 너무 화가 나고 억울해서 천장에 대고 아는 욕이란 욕은 다 내뱉었다.
만약 프로젝트를 진행하며 이런 유형을 만난다면 직접 상대하려고 하지 말고 상급자에게 에스컬레이션 해서 일을 처리하는 것을 추천한다.
"이 버튼 누르면 어디로 랜딩 시켜요? 날짜 선택은 최대 며칠까지 가능해요?"
리뷰를 해줘도, 기획서를 아무리 자세히 써줘도, 설명을 아무리 해줘도 '아기새형'
아 어떤 형으로 정의할지 고민이 많이 됐다. 후보로는 핑프형, 아무고또 몰라요형, 내 시간은 아깝고 네 시간은 안 아까워 형, 물음표 살인마형 등이 있었다. 이런 유형은 생각보다 많은데 특징은 기획서를 안 보거나 대충 읽고 모든 것을 질문하여 개발하는 유형이다. 40명이 넘는 스택홀더와 메이커들이 포함된 대규모 프로젝트를 진행한 적이 있는데 이때 개발자만 10명 가까이 됐었고 기획안은 300장이 넘었다. 300장이 넘었다는 것은 프로젝트가 커서이기도 하지만 그만큼 '상세하게' 정리해 줬다는 말이기도 하다. 기획서 장수가 많은 만큼 글로만 읽었을 때 이해하기가 어려운 부분이 많다고 생각해 리뷰 미팅을 정-말 많이 진행했고 많은 시간 커뮤니케이션과 질의응답을 진행했다.
이해가 안 된다는 부분이 있으면 추가적인 설명을 해드리고 기획안에도 업데이트해 드렸다.
그럼에도 불구하고 기획안을 제. 대.로 읽지 않는 개발자는 기획서에 이미 다 정의해 놓은 기능을 나에게 다시 물어봤다.
개발자 : "버튼에 어떤 텍스트 노출시켜요?"
나 : "어떤 버튼이요?"
개발자 : "일정 선택하고 노출되는 버튼이요."
나 : "아~기획안 p.34에 정의해 두었는데요, 선택한 기간을 노출시켜 주시면 됩니다."
개발자 : "선택기간을 어떻게 노출해요?"
나 : "mm.dd(요일) - mm.dd(요일), N박, 선택완료로 노출시켜 주시면 됩니다.(기획안 캡처)"
개발자 : "최대 선택할 수 있는 기간이 며칠이에요?"
표로 모든 케이스를 정리해 뒀다. 읽고도 이해하기 어려워하는 질문이나 정의되어있지 않은 케이스에 대한 질문은 너무 x100 환영한다. 첨부 이미지처럼 '그냥 보기만 해도 알 수 있는 정보'를 기획안 페이지를 알려주고 캡처를 보내도 제대로 보지도 않고 읽지도 않고 같은 질문을 무한대로 한다. 이 유형은 문서를 찾아보기도, 꼼꼼하게 읽어보기도, 이해하기도 귀찮아한다. 본인이 직접 찾아보는 건 귀찮고 시간 아까운데 기획자에게 하나하나 물어보는 시간은 안 아까운가 보다. 하나하나 물어볼 시간에 좀.. 기획서를 제대로 읽어보고 서로에게 영양가 있는 질문을 한다면 훨씬 좋은 결과가 만들어질 거라고 생각한다. (양심이 있으면 질문하기 전 최소한 '기획서를 읽어봤다'의 느낌은 주길 바란다...)
기획자에게 부여된 시간도 당신에게 부여된 시간과 동일한 24시간이란 사실을 기억하자. 남의 시간을 막 쓸 권리는 그 누구에게도 없다. 만약 업계에서 이런 유형을 만난다면 매번 친절하게 답할 필요 없이 기획안 페이지를 알려주거나 기획안 캡처를 해서 전달한다.
그럼에도 불구하고 해결되지 않는 다면 답은 '상급자에게 알리는 것' 밖에 없다.
"(조---오----용) 개발 완료 다 되었습니다."
질문도 의견도 없이 개발 완료 해버린 '프랑켄슈타인 박사형'
출처: giphy다수의 프로젝트를 진행하면서 느낀 건 프로젝트를 진행하는 구성원 모두와의 '커뮤니케이션'이 정말 중요하다는 것이다. 근데 가끔 '정말 조용한' 개발자분들이 계시다. 처음에 이 유형을 만났을 땐 내 기획안을 100% 다 이해하고 개발한다고 생각했다. 근데 QA 시점에 테스트를 해보면 내가 생각한 방향성이나 기획에 전혀 맞지 않는 개발을 해놓는 경우가 많았다. 이들의 특징은 '기획안을 본인식대로 추측하고, 맞다고 생각하며 질문도 의견도 없이 본인이 의사결정을 내리고 프로젝트를 만들어간다'는 것이다. 결국 내가 만들려고 했던 모습과는 전혀 딴판인 프랑켄슈타인의 탄생을 볼 수 있다. (처음 만나곤 멘붕이 왔었음)
나 : (기획안 리뷰 후) 혹시 이해 안 되시거나 추가로 고려해야 할 사항이 있을까요?
개발자 : 조-용
나 : 없으신가요? 기획안 보시고 개발 진행하시면서 문의사항 생기면 언제든 말씀 주세요.
개발자 : 네네
-데일리 스크럼 진행 시-
나 : 개발 쪽은 이슈 없으실까요?
개발자 : 네 이슈 없습니다.
나 : 일정도 이슈 없으신가요?
개발자 : 네 없습니다. 일정 내 완료 가능합니다.
-2주 후 개발 완료시점-
나 : 테스트 언제부터 할 수 있나요?
개발자 : 개발 완료되어 오늘부터 가능합니다. xx버전으로 테스트해 주세요.
나 : (QA 환경 접속 후 기능 테스트를 해보며..)...????.....???????????ㅇ0ㅇ???????
나 : OO님, 제 기획안에 A 기능은 없는데 어떻게 추가된 걸까요? 제가 기획한 B 기능은 어떻게 확인할 수 있을까요?
개발자 : 네, 제가 필요할 것 같아서 넣었어요. 기획안에 있는 기능은 제가 넣은 A로 대체될 수 있을 것 같아 뺐어요.
나 : 혹시 중간에 저에게 공유를 한다거나 문의를 주셨는데 제가 놓친 걸까요?
개발자 : 아니요. 제가 알아서 개발했어요. 수정할까요?
나 : 말잇못... 또르르르....(???? 당장 내일이 배포인데...?????????)
생각보다 정말 무서운 유형이다. 기능 개발 시 고민되는 모든 지점을 기획자와 상의 없이 본인이 의사결정하고 중간에 공유조차 하지 않는다. 이러한 유형은 보통 미들급 이상 개발자들이었는데 자기중심적으로 생각하는 경향이 짙었다. 이렇게 프로젝트가 프랑켄슈타인이 되어버리면 배포일을 조정하고 다시 기획안대로 개발을 요청한다. 첫 번째 이유는 우선 처음 기획한 프로젝트의 배경과 목적에 맞지 않는 결과물이고, 두 번째 이유는 다른 개발자들은 다 기획안을 보고 개발했기 때문에 전체 싱크가 맞지 않기 때문이다.
혹시 이런 유형을 만나게 된다면 중간중간 기획 방향대로 개발이 잘 진행되고 있는지 최대한 디테일한 질문을 통해서 파악해야 한다. 또는 협업하는 다른 개발자들과 싱크를 잘 맞춰 가져가고 있는지 등 크로스 체크가 필요하다. 이런 유형은 '이슈가 없냐고 물으면 없다고 답한다' 그러니 이슈가 아예 없다는 개발자이거나 기획리뷰나 기획안을 보고도 질문이 없고, 심지어 개발을 하면서도 조용하다면 의심해 보자. 질문이 하나도 없는 건 기획안이 너무 잘 쓰여있고, 그것을 정말 잘 이해한 개발자인 경우도 있지만 내가 경험했을 땐 이 경우보다 그렇지 않은 경우가 훠얼-씬 많았다. 항상 체크체크! 크로스체크!! 명심하자!!! (+상급자에게 사전에 신경 써달라고 미리 말해놓는 것도 방법..)
이 외에도 기획자를 비둘기라고 생각하고 그 어떤 커뮤니케이션도 직접 하지 않으려는 유형, 본인 잘난 맛에 사는 유형, 개발 완료 후 내부 개발 테스트도 하지 않고 기획자에게 전달하는 유형, 일정 산정을 과하게 잡거나 계속 연기되는 유형, 덜렁거리는 유형, 중간 수정은 절대 안 하려는 유형등이 있는데 이들까지 모두 다 쓰면 글이 너무 길어질 것 같아 여기까지 쓰고 마치려고 한다.
같이 프로젝트를 진행하는 것은 한 배에 타고 그 배에서 각자의 역할을 하는 것이라고 생각하는데 위와 같은 유형들은 배를 가라앉혀 모두를 위험에 빠트리는 유형이라고 생각한다. 이러한 유형은 개발자뿐만 아니라 여러 직군에 다양한 형태로 나타날 수 있으니 주의하자. (사실 내가 주의한다고 만나지 않을 순 없으니 도를 닦는다고 생각하고 매일 명상을 하자.)
이런 유형을 만났을 때의 대처법은 '그때그때 다르다'이다. 좋게 이야기해서 그들을 내가 원하는 방향으로 잘 데려갈 수도 있고, 치열하게 싸울 수도 있고, 어떻게 해도 해결이 안 된다면 상급자에게 에스컬레이션 하는 방법도 있다. (어쨌든 안 만나는 게 최고)
이번 편에서는 만나기 싫은 유형들에 대해서만 언급했는데 사실 좋은 개발자도 엄청 많이 만났다.
기획자가 생각하지 못 한 케이스를 발견하거나, 기획의 오류를 짚어주시는 분들, 그리고 개발자에 비해 상대적으로 기술 지식이 낮은 기획자를 위해 쉽게 설명해 주시고 의사결정을 편하게 도와주시는 분들, 천재 개발자 등등. 내가 느꼈을 때 좋은 회사(성장하는 회사, 실력자가 많이 모인 회사) 일수록 좋은 개발자가 많았다.
이번 편에서는 만나기 싫은 개발자에 대해 다뤘으니, 다음 편에서는 '다시 만나고 싶은 개발자, 평생 함께하고 싶은 개발자'에 대해 다뤄볼까 한다. 그동안 만났던 좋은 개발자분들을 생각하며 직접 겪은 예시로 그들의 특징을 설명해야겠다. 그럼, 다음 편도 많관부!
