비개발자 출신 대표/PM이 개발자와 소통하는법
개발자를 이해하고 싶은 비개발자 출신 스타트업 대표/기획자/PM이라면
이 글의 요지
요즘은 많은 비개발자 출신 IT 회사 대표들이 나타나고 있다. 나 또한 상당히 많은 수의 비개발자 출신 대표들과 비개발자 출신의 프로젝트 매니저, 기획자들을 만나보았다. 이들 중에는 개발자와의 협업 경험이 풍부하여 지식이 부족해도 올바른 커뮤니케이션을 통해 협업을 진행하는 훌륭한 분들도 많지만, 경험이 부족한 경우에는 개발자와 충돌이 많이 발생하고 서로가 서로를 탓하게 되는 상황이 발생한다. 때로는 심각한 경우에는 고소/소송으로까지 이어질 수도 있다.
솔직히 말하자면, 성공한 IT 계열 스타트업들의(NHN, 다음, 카카오, 구글, 애플, 트위터, 페이스북, 테슬라 등등) 회사 대표 대부분이 개발자 출신이기 때문에 기술 지식이 풍부하며 해당 회사의 핵심 자산인 개발자들을 충분히 이해하는 것이 큰 장점으로 작용한다고 생각한다. 그렇다고 해서 비개발자 출신의 대표들이 사업을 접어야 한다는 이야기를 하는 것은 아니다. 올바른 방법으로 소통하고 개발자를 이해하는 방법을 찾으면, 서로가 서로를 이해하는 원만한 환경 속에서 목표를 달성할 수 있을 것이라고 믿고있다.
그렇다면 어떻게 하면 저 외계어만 해대는것 같고 안된다고만 하고, 오래걸린다고만 하는 개발자와 효과적으로 소통하고 이해할 수 있을까? 이에 대해 조금이라도 가이드가 되었으면 하는 마음으로 비개발자출신 대표와 기획자가 할 수 있는 실수를 소개하고, 해결책을 말해보겠다.
(참고: 참고로 저는 마케터 출신 IT회사 PM이자 대표이며, PM 업무를 맡기전/맡는 동안 몇년동안 기획, UXUI디자인, 개발 전반적인 과정을 공부하고 배워왔습니다. 개발자의 입장과 비개발자의 입장에서 생길 수 있는 오해와 상황들을 많이 지켜봐왔습니다. 이러한 경험을 바탕으로 작성하였으나, 조금 더 개발자의 관점에치중하여 작성되었음을 미리 알려드립니다.)
비개발자 출신 대표 & PM, 기획자가 할 수 있는 실수
자꾸 자리로 와서 물어보고 질문 공세하기 (개발자 시간 낭비 초래)
일하는 도중에 별 중요하지 않은 이야기나 새로운 업무가 갑자기 들어올 때, 이를 처리하기 위해 원래 하던 일에서 다른 일로 넘어가야하는 상황은 많이 발생할 수 있다. 이러한 상황을 컨텍스트 스위칭이라는 개념이라고 하는데, 컨텍스트 스위칭은 한 작업에서 다른 작업으로 완전히 넘어가기 위해 머릿속에 필요한 정보들을 채우고 유기적으로 연결시키는 시간을 의미한다. 일하고 있는 사람을 방해할 때마다 컨텍스트 스위칭을 해야하므로 이로 인해 소요되는 시간은 상당히 크다.
특히나 개발자인 경우 컨텍스트 스위칭 비용이 더 높을 수 있다. 개발자들은 머릿속에서 수많은 변수명, API의 클래스명, 메서드명, 코딩 순서, 알고리즘, 시스템 구성 등의 정보들을 생성하고 코딩하는 동안 몰입한다. 갑자기 시덥잖에 질문공세를 하고 미팅을 하고자 하면 그 순간 이러한 정보들이 한순간에 날아가 버릴 수 있으며, 인간의 능력상 동시에 많은 것을 담을 수 없기에 이러한 컨텍스트 스위칭은 생산성을 크게 저해할 수 있다.
그렇다면 어떻게 해야하는가
따라서, 일하고 있는 사람들이나 개발자들을 방해하는 상황은 최대한 피해야 한다.
정말 필요한 경우가 아니라면 점심시간이나 스케쥴된 미팅 시간에 물어보는 것을 추천한다.
원활한 업무 진행을 위해서는 작업 중에 방해를 최소화하고, 효율적인 협업 환경을 조성하는 것이 중요하다.
궁금한 점이 있다면 슬랙이나 메모장에 저장해 놓고, 소통 시간에 묻는다.
요구사항을 제대로 전달하지 못함 (즉, 자기들이 뭘 원하는지를 모름)
대표나 기획자들이 개발자들에게 요구사항을 충분히 명확하게 전달하지 않으면, 개발자들은 기대하는 결과물을 정확히 이해하지 못한다. 너무나 당연한 이야기이지만 자기들이 원하는 요구사항을 리스팅하지도 못하고 자세히 설명을 못하는 경우가 많다. 이로 인해 개발자들은 여러 차례 수정을 해야 하거나 최종 결과물이 원하는 기능을 충족하지 못할 수 있다.
그냥 편하게 백화점에서 옷쇼핑하는데 점원에게 이거..저거.. 하는 식이다. 굳이 가져왔더니 이거말고 다른거! 하면서 혼을 쏙 빼놓는다.
예를 들어 디자이너에게 고객이 원하는 옷의 디자인을 말해야 하는데 그냥 퍼런색에 코트.. 이정도로만 말하고서는 막상 파란색 모직 코트를 만들어오면 원하는게 아니라고 하고 계속 다른것을 만들어서 가져오라고 윽박지르는 것과 같다. 이 과정에서 새로이 만들어야 하는 옷의 개수가 많아지기 때문에 당연히 일정이 딜레이가 되고 소모되는 금전적 손실도 많아지며 감정적으로는 디자이너는 스트레스를 받게 되는데, 막상 원하는 결과물을 만들어 줬더니 최종 옷 한벌값만 내겠다고 하는 것이다.
애초에 모두의 시간/에너지를 낭비하지 않기 위해서는 정확히 자기가 무엇을 원하는지 말할 수 있어야 한다.
즉 코랄빛 파란색의 양털로 만들어진 자잘한 체크무늬가 (1px)간격으로 들어간 길이가 60cm인 코트라고!!!!!!
그렇다면 어떻게 해야하는가
요구사항 정의 및 문서화: 대표나 기획자와 개발자들이 함께 요구사항을 충분히 논의하고 정의한 후 문서로 작성한다. 요구사항 문서를 통해 목표와 기대 결과물을 명확히 정의하여 오해와 혼동을 방지할 수 있음.
상세한 설명과 예시 제공: 요구사항을 전달할 때 충분히 자세하게 설명하고, 가능하다면 예시나 시나리오를 함께 제공하여 개발자들이 이해하기 쉽도록 돕는다.
프로토타입 및 시연: 개발 전에 프로토타입을 만들어 보거나 시연하여 실제 동작을 보여주는 것이 유용하다. 시각적인 표현을 통해 요구사항을 더욱 명확하게 전달할 수 있으며, 개발자들도 이해하기 쉬워진다.
지속적인 소통과 협업: 개발 프로젝트 동안 대표, 기획자, 디자이너, 개발자들 간에 지속적으로 소통하고 협업하는 것이 중요하다. 꾸준한 회의와 논의를 통해 요구사항을 업데이트하고 추가적인 조율이 필요한 경우에도 빠르게 대응할 수 있다.
비난 대신 협력적인 태도: 요구사항이 불명확하거나 변경이 필요한 경우에도 강요나 강압적인 태도 없이 협력적인 태도를 유지한다. 함께 문제를 해결하자는 태도로 개발자에게 도움을 청하거나 의견을 묻는다
개발 과정에 대한 이해 없이 비현실적인 기간 계획설정
대표나 기획자들이 개발 작업에 소요되는 시간과 노력을 과소평가하거나 무시하는 경우가 있는데,
보통 이러한 생각의 바탕에는 개발 과정에 대한 이해 없이 개발자는 밤새서 무리해서 일해도 되는 일꾼으로 생각한다는 점에 있다. 자기 자신들은 아이디어만 다다다 내면 되고, 개발 프로세스나 UXUI가 무엇인지, IT기획은 무엇인지는 관심조차 없다.
따라서 IT 기획이나 개발에 걸리는 시간을 무시한 채 개발자들에게 불합리한 기간 안에 작업을 해야 한다는 압박을 가하고, 개발자들이 자신들의 시간을 무리해서 희생하거나 스트레스를 받을 수 있는 환경을 조성한다.
이것은 마치 자라고 있는 아기 사냥개에게 왜이렇게 빨리 자라지 못하냐면서 윽박지르고 어서 자라나서 너구리를 잡아오라고 재촉하는 것과 같다. 강아지를 기르기 위한 가장 기본적인 지식인 강아지의 성장 속도에 대한 이해와 공부 없이 말이다.
그렇다면 어떻게 해야하는가
개발 프로세스의 이해와 교육: 대표나 기획자들은 개발 프로세스와 IT 기획, UX/UI의 중요성을 공부한다. 개발자들이 진행하는 일이 무엇인지 이해하는 것에 도움이 된다.
요구사항과 기간의 현실적인 평가: 개발에 필요한 요구사항과 기간은 프로젝트의 복잡성과 난이도에 따라 달라진다. 개발자에게 충분히 조언을 받아 기간을 설정하고, 너무 기간이 늘어났다고 생각이 들면 기간을 줄이기 위해 필요한 것이 무엇인지 묻는다.
작업 우선순위 설정: 모든 아이디어와 요구사항을 동시에 처리하기 어렵다. 우선순위를 설정하고, 핵심 기능과 필수 작업에 초점을 맞추는 것이 중요하다.
적절한 리소스 배정: 개발 프로젝트를 성공적으로 이끌기 위해서는 적절한 리소스(인력, 시간, 도구 등)를 배정하는 것이 중요하다.
피드백과 개선: 프로젝트 진행 중 발생하는 문제와 어려움을 공유하고, 이를 해결하는 방법을 함께 고민한다. 무조건 왜이렇게 늦냐고 윽박지르지 않는다. 지속적인 피드백과 개선을 통해 프로젝트의 효율성을 높이고, 팀원들의 의견을 존중하는 기업 문화를 형성한다.
너무 잦은 기획 변경 & 도대체가 이해가 안되는 기획 의도
이미 철근까지 올리고 콘크리트도 바르고 외벽 디자인까지 끝냈는데 건물 구조를 모조리 바꾸자고한다.
창문 위치도 모조리 바꾸자고 한다. 위치도 저기~ 냄새나는 강가로 다시 옮기자고 한다.
굳이 저 냄새나는 강가로 옮겨야하는 이유도 정확히 설명하지 못하고 그냥 자기들이 원해서라고 한다. (보통 유저 페르소나 정의도 제대로 되지 않은 경우 99.9%)
더불어 기획 변경이 자주 발생하면서도 일정은 변하지 않는 경우는 더욱 첩첩산중이다.
새로운 요구사항이 발생했고 기획이 변경되었는데 원 일정을 유지하려는 것은 현실적으로 정말 어려운 일이다.
기획 변경으로 인해 개발자들은 추가 작업을 처리해야 하고, 일정은 변하지 않기 때문에 작업량이 급증할 수 있다. 이로 인해 개발자들은 과도한 업무 부담과 스트레스를 겪을 수 있다.
더 심각한 것은 저기 맨날 컴퓨터만 두드리는 안경잡이 너드 개발자들은 응당 개미처럼 24시간 일해야 하며, 밤샘 작업을 해도 괜찮다고 여기는 태도이다.
그렇다면 어떻게 해야하는가
이러한 상황을 방지하고 팀 간의 원활한 협업을 위해서는 다음과 같은 조치가 필요하다.
기획 변경의 이유를 명확하게 설명하고, 개발자들의 의견을 듣는다.
일정과 기획의 일치를 고려하여 현실적인 일정을 수립한다.
개발자들과 기획자들 간의 효과적인 의사소통을 촉진한다.
변경사항에 대한 테스트와 QA 과정을 충분히 고려한다.
개발자들의 부담을 줄이기 위해 필요한 인력과 자원을 제공한다.
기술적 이해 부족과 기술적 결정 간섭
겨우 영상통화 하나 추가하는건데 왜안되는데? 너가 못하는거 아니야?
우리 블럭체인 기술 넣자! (이유도 모르고 아니 뭔지도모르고)
비전문적인 대표나 기획자들이 기술적인 결정에 개입하려고 할 때 문제가 발생할 수 있다. 기술적인 지식을 가진 개발자들이 더 적합한 결정을 내리기 어려워지고, 개발자들은 자신들의 지식과 노하우를 활용하지 못하는 상황이 발생한다.
대표나 기획자들이 기술적인 지식이 부족하면, 개발자들과의 소통에 어려움을 겪을 수 있고, 기획서나 요구사항이 기술적으로 현실적이지 않을 수 있으며, 이는 개발자들이 직면하는 기술적 제약을 무시하거나 이해하지 못하는 결과를 초래한다.
왜안되냐고만 한다. 설명해봤자 이해를 할 수 있는 기술적 지식이 없는데도 계속 설명하라고만 하면서 개발자의 시간을 낭비시킨다.
그렇다면 어떻게 해야하는가
기술 결정의 적절한 분담: 기술적인 결정은 개발자들이 주도적으로 내리는 것이 바람직하다. 대표나 기획자들이 기술적인 결정에 개입할 때에는 개발자들의 의견을 존중하고 적절한 방향으로 조율해야 한다.
얘네는 하는데 왜 우리는 못하냐고 부담감 주기/비교하기
이미 잘돌아가는 경쟁사 케이스를 들고와서 얘네 개발자는 하는데 왜 우리는 못하냐고 비교한다.
팀 내에서 비교하거나 외부 경쟁사와의 비교는 종종 부정적인 영향을 미칠 수 있다. 다른 회사나 팀이 어떻게 잘하는지 확인하는 것은 배울 점을 찾기 위해 유용한 방법이지만, 비교를 통해 우리 팀이 부족하다고 느끼게 되면 부담감과 의욕 감소를 가져올 수 있다.
(걔네는 기획이 애초에 매우 탄탄하고 개발 까지의 모든 업무가 탄탄하게 받쳐줬기 때문에 돌아가는 것이라고 말하고 싶지만 팩폭을 말하기는 쉽지 않다.)
그렇다면 어떻게 해야하는가
따라서 비교를 하기보다는 팀 내에서 함께 고민하고 조율하는 방향으로 가는 것이 좋다.
따라서 비교를 통해 의욕이 저하되는 것을 피하고, 경쟁사의 성공을 함께 고민하고 학습하는 방향으로 나아가는 것이 팀의 성과를 향상시키는 데 도움이 될 것이다.
테스트와 QA 과정의 간과
스타트업은 속도를 내야 하는 경쟁적인 환경에서 개발에 초점을 맞추기 쉽다. 이로 인해 테스트와 QA 과정이 제대로 이루어지지 않을 수 있으며, 이는 버그와 오류가 빈번하게 발생하는 원인이 된다. 보통 QA의 중요성과 절차 자체도 모르는 경우가 태반이기 때문에 제대로된 QA없이 오류에 대한 쓴소리만 듣는 개발자는 진이 빠진다.
실제로 모든 개발 과정에서는 버그와 오류가 발생하는 것은 당연한 일이고 특히 빠르게 개발해야 하는 상황에서는 더욱 그렇다. 하지만 QA 과정 없이 오류가 발생하면서 개발자의 능력을 의심하거나, 비난하는 경우가 발생할 수 있고 이는 QA의 중요성과 QA 절차를 제대로 이해하지 못하는 경우로 인한 문제라고 볼 수 있다.
그렇다면 어떻게 해야하는가
QA는 제품의 품질과 안정성을 확보하기 위해 필요한 프로세스로, 개발자와 QA 팀이 함께 협력하여 제품의 문제점을 발견하고 수정하는 과정이다.
따라서 스타트업에서는 테스트와 QA 과정의 중요성을 인식하고, 개발 단계에서부터 QA를 적절히 수행하는 것이 필요하다. 테스트 주도 개발(TDD)이나 지속적인 통합(CI)과 같은 개발 방법론을 도입하여 버그와 오류를 미리 발견하고 수정함으로써 개발 생산성을 향상시키는 것이 좋다.
또한 개발자와 QA 팀 간의 원활한 소통과 협력을 강조하여 문제를 공동으로 해결하고 품질을 향상시키는 데 노력해야 한다.
마지막으로, 사업의 실패를 개발자에게 떠넘겨서는 안된다. (+고소한다고 겁주기)
사업의 성패의 책임을 개발자에게 떠넘겨 심한 경우 고소, 소송을 한다고 겁을 주는 경우가 있다.
대부분 사업이 성공하면 자기의 공이고 사업이 망하면 개발자(가장 돈과 시간이 보통 많이 드는) 탓이라고 생각하는 경우이다.
보통은 개발자가 자기들 요구에 맞춰서 일만 하는 개미라고 생각하고 있다가 (심지어 뭐하는건지도 이해가 안되는데 돈도 많이 드는!!) 사업이 휘청거리거나 개발 시기가 늘어나서 제품 출시가 늦춰지면 개발자 탓을 하는 것이다. (심지어 지분도 없는데)
사업이 휘청거리는 동안 개발자가 냈던 의견들은 묵살하며 자기식대로 타임라인을 고집하고 QA 조차 실시하지 않고, 애초에 엉터리인 기획 사항으로 겨우겨우 완성했더니 당연히도 문제가 있는 완성품을 보고는 왜 애초에 의견을 제시하지 않았냐면서 실패의 책임을 전가한다. 이러한 마음가짐은 잠시만 내려놓자.
자신은 멋있는 창업자이기 때문에 신박하고 재밌는 아이디어를 일론 머스크처럼 내고 있고, 모든 머리아픈 일은 후줄그레한 응당 밤이슬을 먹으며 밤샘 일을 해야하는 개발자에게 몰아줘야 한다는 것에 너무 심취하면 안된다.
아이비리그 출신, 대기업 출신, 유학파 출신 등 자신의 배경을 내세우며 자기는 일론머스크이고, 그런 소일이나 공부는 안하겠다는 마인드의 대표분들도 있다. (대부분 소리소문없이 사라지신다.)
내가 보았던 적어도 망하지 않는 스타트업의 오너들은 자신의 배경과 전 직장에 상관 없이 개발자만큼 기술을 공부를 하고, 디자이너만큼 UXUI를 공부를 하고, PO라고 불리울만큼 프로덕트를 공부하고 분석한다. 동시에 기술자를 존중한다.
이 세계에서는 모두가 같은 위치이고 더 공부하고 더 노력하고 더 남을 존중하고 이해하려는 사람이 승자이다.
IT 프로젝트 프로세스의 맨 첫단계부터 차근차근 공부하고 배워나간다. 신기술이 나오면 자기 비즈니스 모델에 접목하는 아이디어를 낼 줄 안다.
때문에 기술자들도 그러한 대표를 존중하고 비즈니스 Path를 따른다. 개발자 뿐만 아니다. 대표, 기획자, 디자이너, PM, 마케터 등 모두 기술자이고 예술가이다. 그들이 현대 기술을 바탕으로 창조하는 예술적 행위를 존중하자.
최소 비전공자 기획자나 프로젝트 매니저가 프로젝트를 이끌기 위해 공부해야 할 것
IT 기획: IT 기획의 개념과 프로세스에 대해 학습하고, 요구사항 도출, 기획서 작성, 일정 관리, 리스크 관리 등의 핵심 역량을 익힌다.
IT 프로젝트 과정과 산출물: IT 프로젝트의 전체 과정과 각 단계별 산출물을 이해한다. 프로젝트의 목표, 범위, 요구사항, 설계서, 테스트 결과 등에 대한 이해가 중요하다.
UX와 UI: 사용자 경험 (User Experience)과 사용자 인터페이스 (User Interface)의 개념과 중요성을 정확히 이해한다.
프론트엔드, 백엔드, DevOps: 기본적인 개념과 역할을 이해하려 노력한다. (예:프론트엔드는 사용자가 직접 접하는 부분으로 인터페이스를 담당하고, 백엔드는 서버와 데이터 처리를 담당한다. DevOps는 개발과 운영을 통합하여 효율적인 배포와 관리를 지원한다.)
기술 지식: 비전공자이지만 기술적인 이해를 높이기 위해 IT 관련 용어와 개념을 학습하고, 최신 트렌드와 기술 동향을 익힌다.
프로젝트 관리 도구: 프로젝트를 효율적으로 관리하기 위해 일정 관리, 작업 추적, 커뮤니케이션 등을 지원하는 프로젝트 관리 도구의 활용 방법을 익히는 것이 유용하다. (Jira 등)
글을 마치며.
원활한 협업과 팀의 성공을 위해서는 상호간의 존중과 투명한 의사소통이 필수이다. 따라서 대표나 기획자와 개발자들은 서로를 이해하며 솔직하게 의견을 나누어야 한다.(상호 존중을 바탕으로) 특히 개발자들이 프로젝트의 어려움과 제안한 의견을 솔직하게 공유할 수 있는 환경을 조성한다.
또한 대표나 기획자들은 꾸준히 개발자를 이해하려고 노력해야 한다. 이를 위해 기술적인 공부를 꾸준히 하며, 항상 개발자들과 대화를 통해 서로의 의견을 이해하고 해결책을 찾아야 한다. 일방적인 통보나 으레 짐작은 피하며 (개발비가 많이 나왔다며 사기꾼이라고 매도하는 행위 등), 언제나 개발자들에게 먼저 물어보고 소통을 통해 협력해야 한다. 이러한 태도와 노력이 함께 있다면 프로젝트의 진행과 결과물에 큰 도움이 될 것이다.
