> 오늘은 협업에 대해서 이야기 하고 싶어요. 애자일이든 워터폴이든 어떤 조직이든 프로덕트 기획단계에서 개발팀과의 논의는 필수적입니다. 그런데 제가 일을 하다 보니 이 말이 담고 있는 의미가 생각

> 오늘은 협업에 대해서 이야기 하고 싶어요. 애자일이든 워터폴이든 어떤 조직이든 프로덕트 기획단계에서 개발팀과의 논의는 필수적입니다. 그런데 제가 일을 하다 보니 이 말이 담고 있는 의미가 생각보다 다양한데, ‘기획에 참여한다’라는 하나의 단어로 통용되고 있다는 사실을 알게 되었습니다. 카테고라이징을 해보자면, 크게 4개의 타입으로 분류할 수 있습니다. 1번. 문제 정의부터 같이 수행한다. 2번. 문제 정의 리뷰 단계부터 참여한다. 3번. 요구사항이 확정되기 전 리뷰단계부터 참여한다. 4번. 와이어프레임 리뷰 단계부터 참여한다. 보통 애자일 조직에서는 1번의 의미로 많이 쓰입니다. PO가 만들어온 어떤 산출물을 보고 개발자가 그걸 리뷰하는 게 아니라 같이 기획 업무를 수행한다는 점에서 2-4번 타입과 다릅니다. 그렇지만 실제로 이렇게 일하는 조직은 극소수예요. 제가 이제껏 경험해본 바로는 개발자가 기획에 참여한다는 의미는 보통 4단계를 의미했습니다. 사실 이 단계에서는 논의가 굉장히 비효율적이고(되나요 안되나요? 식의 논의) 산발적으로 진행되는 사례(정의한 문제를 문제 삼는 것에서부터 세세한 인터랙션까지)를 많이 봐서 개인적으로는 좀 더 일찍 논의를 같이 하고자 하는 생각이 있었는데요. 저희 조직의 개발팀도 일찍 기획단계에서 참여하기를 희망하였기에 요구사항이 확정되지 않은 상태에서 개발팀과 함께 논의를 시작했는데요. 회의가 끝나고, 한 개발자분께서 저에게 지나가는 말로 한마디를 하셨는데요. 핵심은 빨리 요구사항이 나왔으면 좋겠다는 내용이었습니다. 그 말을 듣고 순간 어떻게 해야하나 고민이 되었습니다. 논의 과정을 생략하고 요구사항을 빨리 확정해달라는 의미일까, 논의는 필요하지만 빠르게 진행해서 확정된 요구사항 문서를 빨리 만들어 달라고 하는것인지요. 그런데 어떤 맥락에서 그런 말을 하셨을지 찬찬히 생각해보니, 기획 단계에 적극적으로 참여하고 싶은 마음이 굴뚝같지만, 데드라인이 정해진 프로젝트에서 기획과정이 길어지면 마음이 초조해지는 마음에서 하신 말씀인 것 같다는 생각이 들었어요. 그래서 제가 택한 방법은 개발자가 초조하지 않게, 논의가 상대적으로 덜 필요한 부분의 와이어프레임은 빨리 드려서 일정이 밀리지 않게 일감을 제공하고, 병렬적으로 나머지 부분의 기획에 참여할 수 있게 하는 방법입니다. 결과는 어떻게 될지 모르겠지만, 이 경험을 계기로 또 하나 배울 수 있었습니다. 협업은 생각보다 쉽지 않습니다. 아무리 같은 팀이라 할지라도 서로 하는 역할이 다르고, 데드라인에 쫓기는 것은 항상 개발자입니다. 원활한 협업을 하려면 어떻게 해야할까? 기획에 참여하고 싶다는 말의 행간의 의미를 어떻게 받아들여야 할까? 일정에 대한 초조함 없이 기획에 원활히 참여할 수 있는 조직은 어떻게 만들 수 있을까? 이 수많은 질문에 정답은 없고 단지 연습이 필요합니다. 상대의 의견을 듣고, 끊임없이 시도하고 피드백을 받는 과정을 반복하면서 점점 그 조직만의 문화가 생기는게 아닐까 하는 생각이 들었습니다.