구글폼에서 메일링 리스트 등록하시면 오프라인 세미나 일정이 있을 때 알려 드립니다! forms.gle/TAw8v4H7jLQb6rVL9 실제 업무 경험에서 나오는 생생한 강의를 보고 싶다면 멤버십에 가입하세요! www.youtube.com/@khanpm/join 회사에서 멘토를 찾을 수 없는 외로운 PM을 위한 온라인 코칭 세션이 필요하다면, iamthepm.kr/product/%ec%98%a8%eb%9d%bc%ec%9d%b8-%ec%9b%90%ec%98%a8%ec%9b%90-%ec%bd%94%ec%b9%ad-4%ed%9a%8c/
안녕하세요. 말씀하신 부분 많이 공감하면서 들었습니다. 다만 해당되는 IT조직의 팀이 프로젝트성이 아니라 운영성 업무를 띄거나 운영, 프로젝트를 같이 진행해야 한다면 가능할까요. 예를 들어 웹/앱에 대한 운영과 개선을 같이 진행하는 팀일 경우를 생각했습니다. 운영 업무는 시스템이 복잡할수록 오류/변경에 대한 부분이 지속적으로 있을 수 있는데, 그런 상황에서도 기획자를 제외하고, 디자인, 퍼블리싱, 개발에서 각자 본인의 영역이라 생각하고 해결을 위해 현업에 문의를 할 수 있는 구조가 되는것이 맞을까요. 제가 업무를 해보니, 현업에서 업무 요청을 할때 각 기술자의 영역으로 해석하는 일에 시간이 많이 드는 것 같습니다. 애자일 방식을 진행하고 싶은데, 급하게 진행되어야하는 부분에 대해서는 결국 기획자가 일을 해석하고, 각 파트에 워터폴 형태로 내려서 그 기능을 빨리 수행하게 하는 일에 익숙해지는 것 같습니다.
안녕하세요. 유튜브 컨텐츠의 특성상 복잡한 정황 얘기를 모두 고려할 수 없어 단편적으로 전달되는 부분이 어쩔 수 없이 있는 것 같습니다. 단기적인 프로젝트와 운영이 나누어지는 전통적 방식보다 프로젝트와 운영이 한 몸처럼 돌아가는 것이 프로덕트팀의 특성이긴 합니다. '나의 제품'을 만드는데 새로운 기능과 부족한 부분의 개선을 따로 떼어서 볼 수는 없는 일이죠. 하지만 말씀하신 현업의 명확한 요구사항을 수행하는 구조의 기업에서는 프로덕트팀이나 애자일 방식 등이 잘 작동하지 않는 것도 현실입니다. 그런 경우라면 오히려 현업과 커뮤니케이션 하는 한 명의 관리자가 있는 것이 더 효율적일 수도 있고요. 특히나 현업의 산발적이고 지속적인 요청을 백로그화 해서 개발중에 방해 받지 않는 것이 중요하기도 하죠. 더 많은 얘기를 나누고 싶으시면 아래 메일링 리스트에 등록해 주세요. 여러 정보나 오프라인 강의가 있을 때 메일로 알려 드립니다! forms.gle/cyDg9Hm46ZJfsts47
안녕하세요. 정말 좋은 영상 잘 봤습니다. 현재 진행중인 프로젝트에서 기획자는 아니지만 비슷한 업무를 하고 있습니다. 현재 워터폴과 애자일의 중간쯤..으로 프로세스를 진행하고 있는데 말씀 중간 중간 너무 공감 가는 말들이 많았습니다. 앞으로도 좋은 영상 많이 부탁드립니다!!
말씀하신 형태의 조직에 있다가, PM 자체를 난생 처음 만나는 팀에 왔는데 고민이 많네요. 디자이너분은 UI 그리는데에만 관심 있고.. 개발자분들은 제가 그걸 왜 정해요? 이런 태도고.. 😥 팀 관점에서 프로덕트팀이 워터폴팀보다 훨씬 좋고, 기획하는 사람이 몰매맞지 않는 구조라 또 좋은데. 이걸 이끌어내기가 쉽지 않습니다. 어떻게 말해야 좋을까요?
조직적으로 공감대가 있거나, 경영진 레벨에서 드라이브를 걸지 않는 한 쉽지가 않습니다. 왜냐하면 개발자나 디자이너 입장에서는 편하고 쉽게 생각안하고 잘하고 있는데 그걸 더 불편하게 만드는거라 설득할 수가 없죠. 그리고 PM이 설득하기 더 어려운 이유는 그들에게 일을 더 시키는게 구조적으로 옳더라도 동시에 PM의 이익을 대변하는 것처럼 보이기 때문입니다. 그래서 상위에서 경영진 레벨로 드라이브 걸지 않으면 어려운 일이에요. 그걸 PM이 혼자 설득하고 싸우기는 불가능에 가깝다고 봅니다...ㅠㅠ
그럴수도 있겠네요. 게임은 출시 후에 고객피드백으로 많은 부분을 기민하게 바꾸기 어렵다보니, 충분한 기획으로 완성도를 높여 출시하는게 일반적일 것 같습니다. 그럼에도 워터폴의 단점은 그대로 가지고 있기 때문에 게임의 성공에 운이 큰 요소로 작용하는 거겠죠. 흥미로운 관점 잘 봤습니다!
현 회사에서는 프로덕트팀으로 디자이너인 제가 기획도 겸해서 로그인/패스워드 정책을 만들었는데 물론 벤치마킹을 해서 참조를 많이 했어요. 여러 스터디를 할 수 있었는데 확실히 워터폴보다 같이 병렬로 진행하는게 훨씬 좋은것같아요 . 단 백엔드 디펜더시가 높아서 스케쥴이 늦어져요 .;;
좋은 내용이네요. 개발을 하면서도 기획자, 디자이너에게 이렇게 하면 어떨까요? 말할 때가 늘 있습니다. 문제는 그렇게 말을 했을 때 그 사람이 본인의 영역을 침범했다고 판단하거나 혹은 타 직군이 너무 강한 푸시를 줬을 때는 문제가 있다고 봅니다. 반대로 너무 보수적인 인물이라 타 직군이 제안을 했을 때 모든 제안을 거절하는 방식으로 가면 제안하는 영역이 점점 줄어들거나 어차피 제안해도 안되 라는 이식이 생길수 있는 문제도 있고요 언제나 느끼는 거지만 중도가 중요한듯 합니다.
그렇다면 프로덕트 팀에서 각 부서별 부서장들에게 워터폴보다 더 높은 수준의 인문학적 이해 능력이 필요한게 맞을까요?! 아무래도 이전 워터폴 방식의 기획자는 고객이라는 ‘신’의 뜻을 가장 잘 알고 가장 잘 이해할 수 있는 공부를 했던 사람들이었다는 생각이 들었어요. 기존 기획자는 고객은 사람이기에 사람에 대한 인문학적 관점과 고객의 흔적인 데이터를 해석할 수 있는 디지털 리터러시 능력을 가지고 있었던 것 같아요. 그것을 사람들의 언어로 바꿔주었던 것이라고 이해했습니다. 그렇다면 과거에는 기획자가 신탁을 받고 만들어주었던 인간의 언어만 알면 되었던 각 부서의 모습과는 달리, 현재의 프로덕트 팀에서 각 부서의 부장님들은 신탁의 의미를 해석할 수 있는 과거 기획자의 능력이 어느 정도는 있어야하는게 맞을까요????
인문학적 소양은 언제나 중요합니다. 프로덕트팀에는 부서장이라는 개념이 없어요. 프로덕트팀에 대해 이해를 높이시려면 '인스파이어드'라는 책을 읽어보시길 추천드립니다! 기획자와 프로덕트팀의 차이는 인문학적 소양 정도보다, 자신의 추측이나 고객의 지시만으로 제품을 만드는지 시장 피드백을 통한 실험으로 만드는지가 차이입니다.
@@khanpm 이제야 막 비즈니스 세계에 관심이 생기고 있는 지망생입니다. 질문의 수준이 사람의 수준을 드러낸다는 말처럼 부끄러운 질문이었지만, 그에 대한 구체적인 답변, 더 나아가 어떻게 발전적인 시각을 얻을 수 있는지에 대한 답변까지 해주셔서 감사드립니다. 오늘 하루도 행복한 하루가 되시길 바랍니다^__^
실제 업무 경험에서 나오는 생생한 강의를 보고 싶다면 멤버십에 가입하세요!
www.youtube.com/@khanpm/join
게임쪽에서 기획업무를 하고 있는데, 많은 생각이 들게 되는군요.
통찰력 있는 말씀 감사합니다.
가슴이 뻥 뚤리는 영상이었습니다 너무 공감되네요ㅠㅠ 오늘 처음 이 채널을 알게 되었는데, 영상 하나 하나 너무 감사한 마음으로 보고 있습니다ㅎㅎ 감사합니다!!!
현업에서 마음 고생이 심하셨군요. 좋은 프로덕트팀이 점차 생기는 추세입니다. 화이팅!
정확히 저희 조직의 업무 프로세스, 문제점을 관통하는 영상이네요. 퀄리티 좋은 영상 만들어주셔서 감사합니다!
좋은 말씀 감사합니다!
좋은 영상 감사드립니다. 저희 조직을 이해할 수 있게 되엇어요
감사합니다!
신입 프로덕트 매니저로 다음주 출근예정입니다! 알면 알수록 어려운 직무..공부를 많이 해야하고 회사의 주력 아이템에 대한 애정이 없으면 절대 못할 직무인것 같네요! 구독하고 앞으로도 자주 영상 챙겨볼게요ㅎㅎ
신입 PM으로 시작하시는군요. 화이팅 하세요!!!
와 내공이 엄청난 분이십니다!!!! 최고입니다 영상 만들어주셔서 고맙습니다!!
좋은 말씀 감사합니다!
구글폼에서 메일링 리스트 등록하시면 오프라인 세미나 일정이 있을 때 알려 드립니다!
forms.gle/TAw8v4H7jLQb6rVL9
실제 업무 경험에서 나오는 생생한 강의를 보고 싶다면 멤버십에 가입하세요!
www.youtube.com/@khanpm/join
회사에서 멘토를 찾을 수 없는 외로운 PM을 위한 온라인 코칭 세션이 필요하다면,
iamthepm.kr/product/%ec%98%a8%eb%9d%bc%ec%9d%b8-%ec%9b%90%ec%98%a8%ec%9b%90-%ec%bd%94%ec%b9%ad-4%ed%9a%8c/
안녕하세요. 말씀하신 부분 많이 공감하면서 들었습니다. 다만 해당되는 IT조직의 팀이 프로젝트성이 아니라 운영성 업무를 띄거나 운영, 프로젝트를 같이 진행해야 한다면 가능할까요. 예를 들어 웹/앱에 대한 운영과 개선을 같이 진행하는 팀일 경우를 생각했습니다. 운영 업무는 시스템이 복잡할수록 오류/변경에 대한 부분이 지속적으로 있을 수 있는데, 그런 상황에서도 기획자를 제외하고, 디자인, 퍼블리싱, 개발에서 각자 본인의 영역이라 생각하고 해결을 위해 현업에 문의를 할 수 있는 구조가 되는것이 맞을까요. 제가 업무를 해보니, 현업에서 업무 요청을 할때 각 기술자의 영역으로 해석하는 일에 시간이 많이 드는 것 같습니다. 애자일 방식을 진행하고 싶은데, 급하게 진행되어야하는 부분에 대해서는 결국 기획자가 일을 해석하고, 각 파트에 워터폴 형태로 내려서 그 기능을 빨리 수행하게 하는 일에 익숙해지는 것 같습니다.
안녕하세요. 유튜브 컨텐츠의 특성상 복잡한 정황 얘기를 모두 고려할 수 없어 단편적으로 전달되는 부분이 어쩔 수 없이 있는 것 같습니다. 단기적인 프로젝트와 운영이 나누어지는 전통적 방식보다 프로젝트와 운영이 한 몸처럼 돌아가는 것이 프로덕트팀의 특성이긴 합니다. '나의 제품'을 만드는데 새로운 기능과 부족한 부분의 개선을 따로 떼어서 볼 수는 없는 일이죠. 하지만 말씀하신 현업의 명확한 요구사항을 수행하는 구조의 기업에서는 프로덕트팀이나 애자일 방식 등이 잘 작동하지 않는 것도 현실입니다. 그런 경우라면 오히려 현업과 커뮤니케이션 하는 한 명의 관리자가 있는 것이 더 효율적일 수도 있고요. 특히나 현업의 산발적이고 지속적인 요청을 백로그화 해서 개발중에 방해 받지 않는 것이 중요하기도 하죠. 더 많은 얘기를 나누고 싶으시면 아래 메일링 리스트에 등록해 주세요. 여러 정보나 오프라인 강의가 있을 때 메일로 알려 드립니다!
forms.gle/cyDg9Hm46ZJfsts47
장기간 축적해온 경험에서 나오는 지식들을 이렇게 들을 수 있어서 너무 행운입니다 pm직무에 대해 알아보면서 혼란이 있었는데 올려주신 동영상들 보면서 정리하는데 정말 많은 도움이 되었습미다 진심으로 감사드립니다!
좋은 말씀 감사합니다!
애자일, 워터폴에 대해 어렴풋이 알던 내용들이 구체화되는 느낌입니다ㅎㅎ 개발자로서 많이 배웁니다 감사합니다!
도움이 되셨다니 좋군요! 감사합니다!
안녕하세요. 정말 좋은 영상 잘 봤습니다. 현재 진행중인 프로젝트에서 기획자는 아니지만 비슷한 업무를 하고 있습니다. 현재 워터폴과 애자일의 중간쯤..으로 프로세스를 진행하고 있는데 말씀 중간 중간 너무 공감 가는 말들이 많았습니다. 앞으로도 좋은 영상 많이 부탁드립니다!!
감사합니다!!
와 진짜 넘 공감.. 저는 그 모든 케이스를 처음부터 가급젇 최대한 고려하면서 정의하는퍈인데.. 그래서 넘 힘들고 바쁘죠..
프로덕트 팀 꾸리는게 좋긴 한데.. 추가로 필요한게 어느정도 마케팅 서비스기획 uxui등을 알고 커뮤니케이션이.원활해야한다는거죠.. 팀 구성원들이요.. 안그럼 걍 워터폴에서 미팅 소집해서 하는거랑 별 차이가 없을듯 해요
네 맞습니다. 프로덕트팀은 역량있고 능동적인 멤버가 필수적이죠.
말씀하신 형태의 조직에 있다가, PM 자체를 난생 처음 만나는 팀에 왔는데 고민이 많네요.
디자이너분은 UI 그리는데에만 관심 있고.. 개발자분들은 제가 그걸 왜 정해요? 이런 태도고.. 😥 팀 관점에서 프로덕트팀이 워터폴팀보다 훨씬 좋고, 기획하는 사람이 몰매맞지 않는 구조라 또 좋은데.
이걸 이끌어내기가 쉽지 않습니다. 어떻게 말해야 좋을까요?
조직적으로 공감대가 있거나, 경영진 레벨에서 드라이브를 걸지 않는 한 쉽지가 않습니다. 왜냐하면 개발자나 디자이너 입장에서는 편하고 쉽게 생각안하고 잘하고 있는데 그걸 더 불편하게 만드는거라 설득할 수가 없죠. 그리고 PM이 설득하기 더 어려운 이유는 그들에게 일을 더 시키는게 구조적으로 옳더라도 동시에 PM의 이익을 대변하는 것처럼 보이기 때문입니다. 그래서 상위에서 경영진 레벨로 드라이브 걸지 않으면 어려운 일이에요. 그걸 PM이 혼자 설득하고 싸우기는 불가능에 가깝다고 봅니다...ㅠㅠ
의외로 워터폴이 잘 통하거나 (혹은 불가피해 보이는) 곳이 있다면 게임 업계일 것 같습니다. 다만 정말 기민해야하는 서비스/플랫폼에서 워터폴은 문제를 많이 야기할 수 있겠다는 생각이 들었습니다
그럴수도 있겠네요. 게임은 출시 후에 고객피드백으로 많은 부분을 기민하게 바꾸기 어렵다보니, 충분한 기획으로 완성도를 높여 출시하는게 일반적일 것 같습니다. 그럼에도 워터폴의 단점은 그대로 가지고 있기 때문에 게임의 성공에 운이 큰 요소로 작용하는 거겠죠. 흥미로운 관점 잘 봤습니다!
현 회사에서는 프로덕트팀으로 디자이너인 제가 기획도 겸해서 로그인/패스워드 정책을 만들었는데 물론 벤치마킹을 해서 참조를 많이 했어요. 여러 스터디를 할 수 있었는데 확실히 워터폴보다 같이 병렬로 진행하는게 훨씬 좋은것같아요 . 단 백엔드 디펜더시가 높아서 스케쥴이 늦어져요 .;;
스스로의 발전에도 많이 도움이 되었을 겁니다!
좋은 영상 올려주셔서 고맙습니다 🙏 애자일팀 관리 실전 예시 같은 내용도 기대해도 될까요? PO/PM + 스크럼마스터 + QA테스터 등의 역할들 사이에서 균형을 잡는게 쉽지 않네요...
곧 R&R에 관한 영상을 하나 올릴 예정이에요 ^^
좋은 내용이네요. 개발을 하면서도 기획자, 디자이너에게 이렇게 하면 어떨까요? 말할 때가 늘 있습니다. 문제는 그렇게 말을 했을 때 그 사람이 본인의 영역을 침범했다고 판단하거나 혹은 타 직군이 너무 강한 푸시를 줬을 때는 문제가 있다고 봅니다. 반대로 너무 보수적인 인물이라 타 직군이 제안을 했을 때 모든 제안을 거절하는 방식으로 가면 제안하는 영역이 점점 줄어들거나 어차피 제안해도 안되 라는 이식이 생길수 있는 문제도 있고요 언제나 느끼는 거지만 중도가 중요한듯 합니다.
누구든 적극적으로 제안할 수 있는 분위기는 항상 좋습니다. 단 책임자가 그 의견을 듣고 결정할 수 있다는 합의가 되면 될 것 같습니다.
말씀하신 워터폴 조직에서 프로젝트를 진행한 적이 있습니다. 그때 우리가 왜이렇게 소통이 안될까, 왜 이렇게 딜레이가 되는지 몰랐는데 영상 보니까 알 것 같네요😂 이런 조직을 프로덕트 팀으로 바꾸기 위해서 어떤 변화가 필요한지 알고 싶습니다..!
프로덕트팀을 만들 수 있는 방법에 대한 영상도 기회되면 찍어볼께요!
저구조에서는 패스워드 길이 이런거 맘대로 그냥 하고싶어도 나중에 또 정의서에 정의되거나 바뀌면 또 수정해야되서 물어볼수밖에없죠 ㅎ
네 애초에 어디까지 자유롭게 할 수 있고 책임질 수 있느냐의 문제입니다.
워터폴 조직의 영업에서 애자일 조직의 pm을 준비하는 입장에서 좋은 인사이트를 얻을 수 있는 영상이었습니다. 감사합니다.
프로덕트 팀의 강점에 대해 공감해 주셔서 감사합니다.
좋은 영상 정말 감사합니다
앞으로도 관심 부탁 드립니다^^
좋은 말씀 감사합니다!
질문이 하나 있는데, 그럼 워터폴에서 프로덕트 팀으로 조직이 변경된다면, (물론 변화의 시간이 충분히 걸리겠지만..) 기획자들은 어떤 일을 맡게 되나요? 조직을 떠나야 하는 건가요?
PM이나 PO의 업무를 할 수 있다면, 성장할 것이고 그렇지 않다면 교체될 것 같습니다. 아래 영상도 참고해 보세요!
ruclips.net/video/_LFlriVlvc0/видео.html
@@khanpm 감사합니다! :)
오늘도 디펜던시에 답답함을 안고 이 영상을 다시 봅니다..
너무 좋은 내용이네요. 프로덕트팀이라는게 개발자, 디자이너도 포함되는 내용일까요?
맞습니다. 모든 역할이 포함되어 의사결정을 스스로 할 수 있는 싱글스레드 팀이에요.
신탁 비유 좋다 🤣🤣🤣
인디 게임도 일단 구성원들이 각자 일단 작업을 시작부터 하죠 그걸 한 방향으로 잡아주는게 PM 역활이니.
오... 게임도 그런 방식으로 할 수 있군요
좋은 내용 잘 들었습니다. 다만, 프레젠테이션 같은 시각 효과도 조금 사용 하시면 좀 더 잘 전달 될 것 같아요
좋은 피드백 감사합니다! 실무적인 내용의 영상에는 시각 자료들이 많이 등장합니다. 다른 영상도 시청 부탁 드립니다!!
그렇다면 프로덕트 팀에서 각 부서별 부서장들에게 워터폴보다 더 높은 수준의 인문학적 이해 능력이 필요한게 맞을까요?!
아무래도 이전 워터폴 방식의 기획자는 고객이라는 ‘신’의 뜻을 가장 잘 알고 가장 잘 이해할 수 있는 공부를 했던 사람들이었다는 생각이 들었어요.
기존 기획자는 고객은 사람이기에 사람에 대한 인문학적 관점과 고객의 흔적인 데이터를 해석할 수 있는 디지털 리터러시 능력을 가지고 있었던 것 같아요.
그것을 사람들의 언어로 바꿔주었던 것이라고 이해했습니다.
그렇다면 과거에는 기획자가 신탁을 받고 만들어주었던 인간의 언어만 알면 되었던 각 부서의 모습과는 달리, 현재의 프로덕트 팀에서 각 부서의 부장님들은 신탁의 의미를 해석할 수 있는 과거 기획자의 능력이 어느 정도는 있어야하는게 맞을까요????
인문학적 소양은 언제나 중요합니다. 프로덕트팀에는 부서장이라는 개념이 없어요. 프로덕트팀에 대해 이해를 높이시려면 '인스파이어드'라는 책을 읽어보시길 추천드립니다! 기획자와 프로덕트팀의 차이는 인문학적 소양 정도보다, 자신의 추측이나 고객의 지시만으로 제품을 만드는지 시장 피드백을 통한 실험으로 만드는지가 차이입니다.
@@khanpm 이제야 막 비즈니스 세계에 관심이 생기고 있는 지망생입니다.
질문의 수준이 사람의 수준을 드러낸다는 말처럼 부끄러운 질문이었지만, 그에 대한 구체적인 답변, 더 나아가 어떻게 발전적인 시각을 얻을 수 있는지에 대한 답변까지 해주셔서 감사드립니다.
오늘 하루도 행복한 하루가 되시길 바랍니다^__^
디자이너가 기획을 할 줄 알면 기획자라고도 합니다 ㅎㅎ
단어 그대로의 '기획'은 어디에나 있으니까요 ㅎㅎ