WIKILOG

항상 "내 걸 해보자" 라는 생각만 가지고 있었다가 올해도 8개월이나 지나서 이러다 아무것도 못하게 될 것 같단 불안감이 엄습했습니다. 그래서 9월부터 working day로 5일 안에 무엇이든 만들어보자(5 Day Product Project)는 결심했고 별 것 아니고 빈약하지만 첫 번째 결과물이 나와 회고의 글을 작성하고자 합니다. 우선 혼자 기획과 개발을 모두 해야 하기 때문에 아이템 선정이 매우 중요했습니다. 과거 이미 몇 번이나 생각보다 큰 프로젝트를 개발하려했다 포기했던 기억이 있기 때문에 더욱 신중하게 고민했습니다. 또한 아무도 안 쓰더라도 나는 꼭 쓸 것을 만들기로 하였습니다. 그래서 2가지 기준을 세웠습니다. 내가 일상에서 필요로 했던 것을 찾아보자. working day로 5일 안에 만..

23년 9월 1주차 회고 Tech Spec‎을 작성해야 하는 이유 여러 IT 회사를 다니면서 회고 때 항상 언급되는 이슈가 있는데 바로 기획에서 개발로 넘어가는 그 중간 애매한 부분에 대해 고충을 토로하는 분들이 많다는 것입니다. 예를 들면 PO/PM/서비스 기획자들이 기획안을 다 설명했는데 개발팀이 개발을 안하고 있어서 일정이 미뤄진다는 이야기 혹은 기획안을 보았는데 이건 뭐를 만들어 달라는 것인지 모르겠다는 개발팀 이야기, 검증을 해야하는데 이걸 어떻게 개발하겠다는건지 모르겠다는 검증팀 이야기 등입니다. 정말 많은 회사를 다녀보았지만 딱 한 군데 빼고는 이 이슈가 없었던 회사는 없었습니다. 왜 이러한 이슈가 발생하는 것일까요? 개발자 출신의 PM/PO인 제가 보았을 때는 바로 명확한 기획안 리뷰가 진..

23년 8월 5주차 회고 - ‎PRD (‎Product Requirement Document)를 작성해야 하는 이유 처음 Product Management로 일할 때만 하더라도 기능 위주의 기획을 중심으로 업무했던 것 같습니다. 그 때만 하더라도 데이터를 수집할 수 있는 방법이 많이 부족했기 때문에 고객 중심으로, 고객의 패턴을 통해 해결책을 찾는 방식보다는 우리가 할 수 있는 것들 중 해결책을 찾았습니다. 하지만 요즘은 데이터를 쉽게 수집할 수 있게 되면서 고객과 문제점을 중심으로 어떻게 해결할지 진행하는 방식으로 많이 바뀌고 있습니다. 또한 과거에는 완성도 있는 제품을 한 번에 만들어 시장에 내보내는 전략을 많이 취했는데 요즘은 불완전하더라도 빠르게 출시하고 지속적으로 수정해나가는 전략을 취합니다. ..

23년 8월 4주차 회고 * 제품을 만들어야 하는 이유 저는 현재 로봇 AI 비전 회사에서 유일한 PO로 근무 중입니다. 제조업 계열로 하드웨어와 소프트웨어를 모두 다뤄야 하고 로봇이라는 시장이 아직 성숙되지 않다보니 지금까지 모두 PoC를 통해서만 매출에 의존하고 있습니다. PoC 만으로 매출을 내기에는 어렵기 때문에 현재 제품을 만들기 위해 노력하고 있습니다. 기본적인 업무들은 이전 회사에서의 PM/PO의 업무와 동일하지만 이번 회사에서 조금 다른 경험을 하고 있어서 해당 내용을 소개해보고자 합니다. SI로 매출이 잘나오고 있다면 굳이 제품을 만들어야하는 이유가 있을까요? 회사에서 제품을 만들어야 하는 이유는 무엇일까요? 매출이 잘 나오는데 굳이 제품을 위한 투자를 한다는 것은 쉽지 않습니다. 여러 ..

* 중요한 것 외에는 챙기지 않는다는 말 회사에서 홈페이지 개편을 하고자 합니다. 이 업무를 A팀에서 하기로 진행하였고 A팀 팀장은 그 동안 홈페이지 개편 때 했던 일들을 모아서 확인해봅니다. 과거 진행했던 일들을 모아보니 중요해 보이는 것들만 팀원들에게 업무를 분배하여 진행합니다. 위 업무의 마무리는 어떻게 되었을까요? 팀원들은 팀장이 시키는대로 업무를 진행하던 중 유관부서로부터 x, y, z는 왜 안챙기고 있는지 듣습니다. 그 사실을 몰랐던 팀원들은 정해진 일정 내에 황급히 x, y, z를 챙기기 시작합니다. 유관부서에서는 급작스런 요청 때문에 고생 고생하며 어쨌던간 업무를 마무리 합니다. 팀장은 고생한 팀원들에게 중요한 것이 아닌데 다른 부서에서 비효율적으로 일한다고 이야기합니다. 사례는 다르지만 ..

* 우리는 회사에서 동료를 통해 성장합니다. 이 과정에서 어떻게 성장하는지가 중요합니다. 회사는 여러 경험을 가진 사람들이 모여서 일하는 곳입니다. 그러다보니 나와 같이 일하는 동료들의 성향과 생각이 이직 여부에 영향을 미칠 정도로 매우 중요해집니다. 특히 나와 같이 일하는 리더의 경우 아무리 강조해도 지나치지 않을 정도로 회사 전반적인 만족도에 영향을 받습니다. 저 또한 제 리더가 저에게 얼마나 영향을 주는지 생각해보고 반대로 제가 사람들에게 얼마만큼의 영향을 주고 있는지 생각합니다. 이러한 과정 속에서 한 가지 배운 것이 있다면 사람은 과거의 경험 기반으로 행동하게 된다는 것입니다. 예를 들어 A라는 프로젝트를 시작한다고 할 때 모든 것을 혼자 고민하고 혼자 계획을 세워 필요한 사람들만 불러서 진행하..

* 0에서 1로 제품을 처음 만들 때 고려해야 할 것 현재 저는 B2B 로봇 제조회사에서 PoC 단계로만 진행되는 프로젝트들로부터 제품을 만드는 과정에 참여하고 있습니다. 업무를 진행하면 할수록 제품이란 무엇일까라는 근본적인 질문에 마주서고 있습니다. 그 이유는 일반 IT B2C/B2B 제품과 달리 고객을 쉽게 만날 수 없고, 산업 도메인으로 인해 기업이 큰 비용을 지출해야만 제품을 구매할 수 있기 때문입니다. 또한 내부적으로는 여러 부서가 있어 절대 린하게 업무를 할 수가 없기 때문에 한 번 만들 때 잘 만들어야 합니다. 이러한 경우에는 어떻게 제품을 만들어야 할까요? 고전적으로 제품을 만드는 2가지 방식이 있습니다. 시장에서 필요로 한 것을 만들어 제공하는 market-in 방식과 우리가 잘하는 것을..

* 체계는 결국 기준이다. 제가 대학생일 때만 하더라도 대부분의 학생들은 창업하기 보다는 대기업과 중소기업으로 취직을 하였습니다. 그러다가 어느 순간부터 창업하는 사람들이 늘어나기 시작했고 창업자들은 기존 유능한 인재를 모셔오기 위해 수평적인 조직 문화, 하고 싶은 것을 다 할 수 있는 문화를 강조했습니다. 지금은 스타트업의 수가 굉장히 많이 늘어나면서 첫 직장을 스타트업으로 가는 사람들이 대부분이게 되었습니다. 그러면서 발생한 부작용이 체계가 사라진 것입니다. 단순히 자유롭고 누구나 말할 수 있어서 체계가 사라진 것은 아닐 것입니다. 자유로워도 체계가 있을 수 있습니다. 하지만 대부분 스타트업은 잃을 것이 없는 또한 도전 정신이 가장 강한 대학생 때 많이 시도하다보니 회사 경험을 해보지 않은 창업자들이..

오늘 본 내용

* 피하고 막는다고 해결되진 않는다. 유관부서와 일하다보면 매번 좋은 상황만 있는 것은 아닙니다. 예를 들면 A팀에서 요청하는 것이 B팀에게 너무 여러 번 노이지하게 전달이 된다던가, A팀의 개개인들이 B팀의 팀원들에게 각각 메세지를 하여 B팀 업무에 부하가 걸린던가, A팀과 B팀의 업무 성향이 너무 달라 회의만 했다하면 싸운다던가 하는 경우가 발생할 수 있습니다. 이러한 경우 팀 리더와 경영진은 어떻게 이 문제를 해결해야 할까요? 만약 두 팀 사이에 협업을 해야 하는 상황이 생기면 경영진 대부분은 '두 팀의 성향이 다르다', '업무 요청할 때 리더 혹은 경영진을 통해서 해야 한다' 라는 말을 하면서 통제를 먼저 할 것입니다. 실제 대부분의 회사에서 그랬습니다. 하지만 이는 두 팀 사이의 단절을 더 초래..