선릉 D.camp에서 진행한 프로그라피 IT 네트워킹 세미나에 다녀왔다. 크게 오전엔 비개발 세션, 오후에는 개발세션으로 이루어져 있었고 나는 마케팅을 제외한 PO/디자이너 세션을 참석했다. 작년 하반기 이전까지는 사적인 환경의 제약?으로 대외적인 활동을 거의 할 수 없었던 상황이 굉장한 스트레스였다. 작년말부터 급변한 나의 거취에 새로운 도전을 해야겠다고 마음을 먹었고, 1년간 미뤄왔던 사이드 프로젝트(를 빙자한 사업의 기회)를 시작하기로 했다. 마침 네트워킹 세미나 행사와 사이드 프로젝트 모집내용을 보게 되었고 들뜬 마음으로 신청했다. 이전에도 동아리나 네트워킹 없이 개인적으로 프로젝트를 진행해봤지만 결국 주위에서 함께하거나 강제성이 없었기 때문에 괄목한 결과를 내기는 쉽지 않았다. 그만큼 끈기가 있는 사람은 아닌게 확실해졌다. 그래서 이번 기회로 새로운 사람들과의 만남과 함께 나의 의지를 묶어놓을 만한 수단을 만들어야 겠다 생각하며 프로그라피를 선택하게 되었다. 사이드 프로젝트를 시작한다면 디자이너보단 PO로서의 경험을 한 번 해보고 싶었기 때문에 PO 세션에 대한 이야기를 중점적으로 해보려고 한다. 지속가능한 사이드 프로젝트 만들기 네이버 PO인 James의 여러 차례 경험한 사이드 프로젝트와 지속가능한 프로젝트를 만들기 위한 고민을 들어볼 수 있었다. 유의미한 제품을 출시하는 것 뿐만 아니라 이후 운영에 대한 경험과 보상까지 함께 있다면 좋겠다는 이야기를 해줬다. 사이드 프로젝트를 해서 제품을 '만들었다'까지가 아니라 마케팅하여 유입도 시켜보고, 유저를 늘려가는 시점에 생기는 또다른 이슈에 대응도 해보는 것, 이것까지가 프로젝트의 한 사이클이 아닐까 싶다. 추가로 팀원들이 동기부여할 수 있는 금전적, 사회적 영향력 등의 보상까지 있다면 더할 나위 없을 것이다. 이전에 '흡연구역지도' 프로젝트를 했었는데 동일한 문제로 흐지부지 됐었다. 직접 발로 뛰며 흡연구역을 찾기도, 지자체에서 제공하는 흡연구역 데이터를 확인하기도 하면서 흡연구역 지도를 만들었다. 근데 이후 사람들에게 어떻게 알리고 운영할지에 대해서는 크게 고민하지 않았다. 마케팅, 운영의 경험이 없었기 때문에 자신도 없었다. 결론적으로 그냥 '만들기'로만 끝난 프로젝트가 되어버렸다. (사이드 프로젝트에서) PO의 역할 프로젝트를 시작하기에 앞서 가장 먼저 맞닥뜨리는 것은 바로 팀빌딩이다. 단순히 팀을 모으는 것에 그치지 않고 그 과정을 '팀이 가까워 지는 시간'이라고 강조한다. 맞다. 함께 오랜시간 일해야 하는 사이에서 라포가 형성되지 않은 상태에서 일을 하게되면 상대방을 '이해'할 수 없게 된다. 또한 PO로서 비전과 전략, 목적과 목표를 Align해야하는 시간으로도 만들 수 있을 것이다. 제품을 만드는 기간이 줄어들 수 있지만 팀원끼리 가까워진 만큼 더 효율적으로 임펙트있게 제품을 만들 수 있는 중요한 기간일 것이다. 제품을 리딩하는 입장에서 커뮤니케이션이 중요하다. 다양한 직군의 이해뿐만 아니라 프로젝트를 성공리에 릴리즈하기 위해서는 업과 사람 둘다 관리해야하는 책임이 있다. 사람과 사람사이의 소통, 일과 사람 사이의 소통 둘다 챙겨야 하기 때문에 디자인이나 개발처럼 눈에 보이는 성과가 없어보이더라도 그것들을 연결을 하는 입장으로써 중요할 수 밖에 없겠다.

직장생활을 6~7년 정도 했다. 나도 대단한 사람은 아니지만 아직 1년도 안 된 주니어에게 몇가지 조언한 것들을 스스로도 다시 한 번 새기며 기록해보려 한다. '네!'가 능사는 아니다. 알아들었다는 것에 확신을 주자 팀원에게 간간히 업무를 지시할 때가 있다. 그럴때마다 당차게 "네!'하며 일을 시작하는데 느낌적인 느낌으로 '이해를 못한거 같은데?' 싶을 때가 있다. 예상은 틀리지 않았다. 데드라인에 겨우 맞춰서 엉성한 결과물을 보여줬다. "내가 말한 것은 A인데 결과가 다른데요? 그때 했던 말 이해한 거 맞아요?" 말이 없다. 이런 상황이 두어번 되니까 나중엔 업무지시 후 바로 "내가 한 말 진짜 이해했어요? 이해한 내용을 나한테 다시 말해봐요."라고 할 정도로 집착하게 되더라. 또는 '내가 말을 못 하나?' 생각들기도 한다. 사람에 따라 이해력이 다르다는 것은 충분히 이해가 된다. 근데 이해하지 못한 상태로 업무를 시작하거나 중간에 다시 묻거나 하지 않으면 일은 결국 딜레이되고 차질이 생겨버린다. 일이 밀린 상태에서 또다른 일이 들어오고 업무가 복리처럼 늘어나 버린다. 결국 그게 본인의 성과가 된다. 나중엔 그 일을 어느 것 하나 끝맺지 못해 포기해 버린다. 남들이 이해한 것 같아서 본인도 이해한 척하려하면 안 된다. 이해를 못한 것은 잘못이 아니다. 이해를 못한 채로 일을 하는 것이 잘못이다. 알잘딱깔센이 되기 전까지는 집요하게 이해하려고 해야한다. '전달 받는 사람'이 편하도록 전달하자 또 다른 누군가가 팀원에게 데이터중 제외해야 할 부분을 체크해달라는 업무를 요청했다. 팀원은 내용을 대댓글로 전달했다. 뭔가 길게 적어 놓긴 했는데 눈에 들어오지 않았다. 요청내용 : 블라블라~ 리스트 중 제외할 것 확인 필요. 남은 것은 다른 업체에 전달 예정. 답변 : 0개월 내에 000사유로 제외할 건 1. 카테고리 → 블라블라블라 2. 카테고리 → 블라블라블라 000 때문에 제외할 건 1. 카테고리 → 블라블라블라 총 n개 제외하면 되고 나머지는 000에 포함해도 문제없을 것 같습니다! 그 사람이 받고 나서도 같은 생각이었을 것이다. 받은 데이터도 본인이 한 번 더 찾아서 체크까지 해야하는 상황이었다. 내가 다시 대댓글로 적었다. 제외 항목 3개 (표 기준) ID 32 - 블라블라블라 ID 56 - 블라블라블라 ID 79 - 블라블라블라 제외 사유 32, 56은 000 사유, 79는 000 사유 (@00님 보는 사람이 후에 처리가 편하게 전달해주세요)