<div id="readability-page-1" class="page"><article id="mainContent">
              <div>
                <p><a href="/m/category/TIL/%EC%84%B8%EB%AF%B8%EB%82%98"><span>TIL/세미나</span></a></p><h3>[우아한 PM의 밤] 개발자가 생각하는 좋은 PM 나쁜 PM</h3>
              </div>
              <p><cite>Seyun(Marco)</cite>
                <span> 2024. 1. 19. 22:07</span>
              </p>
              

<ins data-ad-client="ca-pub-9527582522912841" data-ad-slot="8674651030" data-ad-format="auto" data-full-width-responsive="true" data-ad-type="inventory" data-ad-adfit-unit="DAN-we6apVVPwuoDAazb"></ins>



                <div>
                                <p data-ke-size="size16">💡 원본 영상 : <a href="https://www.youtube.com/watch?v=WVvFRh1vGv8">https://www.youtube.com/watch?v=WVvFRh1vGv8</a></p>
<figure data-ke-type="video" data-ke-style="alignCenter" data-video-host="youtube" data-video-url="https://www.youtube.com/watch?v=WVvFRh1vGv8" data-video-thumbnail="https://scrap.kakaocdn.net/dn/bQxnnU/hyU5IqfnfB/V4shDPU5cyuy6p6pY5TCg0/img.jpg?width=1280&amp;height=720&amp;face=900_262_1010_382" data-video-width="860" data-video-height="484" data-video-origin-width="860" data-video-origin-height="484" data-ke-mobilestyle="widthContent" data-original-url="" data-video-title=""><iframe src="https://www.youtube.com/embed/WVvFRh1vGv8" width="860" height="484" frameborder="" allowfullscreen=""></iframe>

<img src="https://scrap.kakaocdn.net/dn/bQxnnU/hyU5IqfnfB/V4shDPU5cyuy6p6pY5TCg0/img.jpg?width=1280&amp;height=720&amp;face=900_262_1010_382"></figure>
<h2>세미나 내용</h2>
<h2 data-ke-size="size26">동기유발</h2>
<ul data-ke-list-type="disc">
<li>인간이 어떤 목표의 달성을 위해 노력하게 하는 계기를 마련해주는 것, 그것을 PM이 어느정도 해줘야 한다.</li>
<li>왜냐하면 PM은 개발자에게 업무를 요청하는 일을 많이 하게 됩니다. 이때, 개발자의 능력을 100% 끌어내는것. 이게 바로 PM에게 되게 중요한 역량이라고 한다.</li>
<li>그렇다면 나쁜 PM은 이 과정에서 어떻게 행동할까요?</li>
</ul>
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="496" data-origin-height="318">
    <span data-url="https://blog.kakaocdn.net/dn/dAF7ko/btsDGqN9KAU/EkX1yCqoDh51UQEXQh80k0/img.png" data-lightbox="lightbox">
        <img src="https://blog.kakaocdn.net/dn/dAF7ko/btsDGqN9KAU/EkX1yCqoDh51UQEXQh80k0/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="496" data-origin-height="318">
    </span>
    
</figure>
<ul data-ke-list-type="disc">
<li>일반적으로 PM은 다른 분들과 다르게 가장 먼저 시작하게 되고 고민하고 정리하기 시작합니다. 그러면서 자연스럽게 나의 일이 되는데, 그 다음에 잘 정리한뒤에 그냥 개발자에게 툭 던지게 됩니다.</li>
<li>이때, 툭 던지는 과정에서 단순히 PM은 개발자들에게 시키게 되고, 개발자들은 그걸 단순히 시킨일이라고 느끼게 되면서 재미 없는 일이 되는 과정이라고 생각합니다.</li>
<li>여기서 누군가가 다 정리해주고, 이대로 하라고 하는 부분을 느끼게 되면 재미없다라는 의미입니다.</li>
</ul>
<h3 data-ke-size="size23">OWN(나의 일)</h3>
<ul data-ke-list-type="disc">
<li>결국 OWN(나의 일)이라는 개념이 중요하다고 생각합니다.</li>
</ul>
<ol data-ke-list-type="decimal">
<li>내 마음을 쓰는 진짜 나의 일 (이거 진짜 재미있는데, 내가 진심을 담아 하고 싶은 일)</li>
<li>어떤 일을 더 많이 신경쓰고 고민할 때 더욱 OWN</li>
<li>기획자는 스스로 업무를 준비하면서 OWN</li>
<li>누구든지 단순히 시키는 업무를 나의 일로 받아들이기는 쉽지 않다.</li>
<li>개발자도 마찬가지다.</li>
</ol>
<h3 data-ke-size="size23">따라서 좋은 PM들은 어떨까?</h3>
<ul data-ke-list-type="disc">
<li>PM이 나의 일이 되는것까지는 동일하다. 이때 “<b>이걸 해주세요.</b>”라는 말이 아니라, 이걸 왜 해야 하는지 집요하게 생각하고 그것을 데이터와 고객관점, 회사의 가치라는 관점에서 설명을 집요하게 해준다. 개발자가 납득할수 있게 충분히 이 프로젝트에 대해서 이야기를 해준다.</li>
<li>이 과정에서 피드백을 받을 수 있는 창구를 열어준다. 기획서 리뷰를 할때 개발자가 피드백을 해줘야 하는 느낌을 잘 만들어 준다. 개발자가 이 기획에 참여하는 느낌을 만드는 경우를 만들어 준다. 즉, 피드백 사이클을 잘 만들어서 반영한다.</li>
<li>이러한 과정을 통해 개발자는 어느 순간 OWN(나의 일)이 되어 있다.</li>
</ul>
<h3 data-ke-size="size23">이걸 왜 하는가?</h3>
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="1024" data-origin-height="370">
    <span data-url="https://blog.kakaocdn.net/dn/bJYTSO/btsDGuQKYjg/FmvFRTEqmq9K8oKUguMIt0/img.png" data-lightbox="lightbox">
        <img src="https://blog.kakaocdn.net/dn/bJYTSO/btsDGuQKYjg/FmvFRTEqmq9K8oKUguMIt0/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="1024" data-origin-height="370">
    </span>
    
</figure>
<ul data-ke-list-type="disc">
<li>개발자는 문제를 듣는 순간 이걸 내가 해결해야 한다고 느낀다.</li>
<li>즉, 기획자뿐만 아니라 개발자도 나의 일로 만들어야 함.</li>
<li>그렇다면 어떻게? 개발자가 적극적으로 개입하게 상황을 만들어야 함.
<ul data-ke-list-type="disc">
<li>WHY, 피드백, 개선점, 질문하기 등등</li>
</ul>
</li>
<li>기획자가 보기에 기술적으로 어려워 보여도 기획을 조금만 틀면 더 적은 개발 리소스로 더 효과적인 것을 만들수 있음. 좋은 개발자는 이런 것을 잘 안다.</li>
<li>개발자가 더 많이 개입할 수록, 개발자 본인의 일이 된다고 느껴지고, 의견을 내고 개선할 수 있다는 느낌을 받아 적극적으로 대처한다.</li>
</ul>
<h3 data-ke-size="size23">인간적인 유대</h3>
<ul data-ke-list-type="disc">
<li>이것은 삶의 기본</li>
<li>너를 믿는다. 서로 신뢰가 있어야 함.</li>
<li>이런 인간적인 유대가 중요한 이유?</li>
<li>상호 커뮤니케이션의 벽이 낮아짐</li>
<li>개발자 스스로 더 쉽게 피드백을 이야기 함.</li>
<li>스스로 더 많이 참여하게 됨</li>
<li>개발자가 업무를 OWN 할 가능성이 높아짐.</li>
</ul>
<h3 data-ke-size="size23">개발자를 움직이는 마법의단어</h3>
<blockquote data-ke-style="style1">
<p data-ke-size="size16">Solving problems is the core of compute sicence (컴퓨터 과학의 핵심은 문제를 해결하는 것이다.)</p>
</blockquote>
<ul data-ke-list-type="disc">
<li>프로그래머는 문제를 해결하는 , 컴퓨터로 세상의 문제를 해결하는 것을 배운다.</li>
<li>따라서 프로그래머의 뇌에는 문제를 풀어야 한다라는 생각이 있다.</li>
</ul>
<blockquote data-ke-style="style1">
<p data-ke-size="size16"><b>개발자를 움직이는 단어는 “고민이 있어요…”<br></b></p>
</blockquote>
<figure data-ke-mobilestyle="widthOrigin" data-origin-width="896" data-origin-height="408">
    <span data-url="https://blog.kakaocdn.net/dn/dOe1Y5/btsDGuDgPrF/rDKRl0jHNX0GRuB6Rmmnl1/img.png" data-lightbox="lightbox">
        <img src="https://blog.kakaocdn.net/dn/dOe1Y5/btsDGuDgPrF/rDKRl0jHNX0GRuB6Rmmnl1/img.png" onerror="this.onerror=null; this.src='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png'; this.srcset='//t1.daumcdn.net/tistory_admin/static/images/no-image-v1.png';" data-origin-width="896" data-origin-height="408">
    </span>
    
</figure>
<h3 data-ke-size="size23">예시</h3>
<ul data-ke-list-type="disc">
<li>나쁜 PM
<ul data-ke-list-type="disc">
<li>혼자서 일정을 다 정리해옴. (일정을 박아옴)</li>
<li>우선순위를 혼자 결정한다.</li>
<li>대안을 다 만들어 오는 것이 본인이 좋은줄 안다.</li>
</ul>
</li>
<li>좋은 PM
<ul data-ke-list-type="disc">
<li>개발자와 일정을 같이 논의하고 같이 일을 만들어 나간다는 느낌이 중요하다.</li>
<li>개발자가 참여하게 한다.</li>
<li>우리가 다 같이 이 일을 한다는 느낌을 만들어 준다.</li>
<li>고민거리를 주는것이 중요하다.</li>
<li>고민이 있습니다.</li>
</ul>
</li>
</ul>
<h3 data-ke-size="size23">좋은 PM의 끝판왕</h3>
<blockquote data-ke-style="style1">
<p data-ke-size="size16">고수는 이미 답을 알고 있어도 물어본다.</p>
</blockquote>
<h3 data-ke-size="size23">깊이 있는 정책 이해</h3>
<ul data-ke-list-type="disc">
<li>개발자 입장에서는 개발하려는 정책이 어떻게 되는지 정리해서 물어 봐야 합니다.</li>
<li>나쁜 PM
<ul data-ke-list-type="disc">
<li>레거시라 잘 모르겠어요. 코드보면 안되나요?</li>
<li>UI화면 기반의 기획서만 만들고 끝</li>
<li>개발자가 코드를 안짜는것과 동일한거 아닌가? 직무유기가 아닐까?</li>
</ul>
</li>
<li>좋은 PM
<ul data-ke-list-type="disc">
<li>본인 도메인에 대해 술술 이야기 한다.</li>
<li>업무 프로세스랑 주요한 데이터흐름에 대해서 정리해서 머릿속에 가지고 있다.</li>
<li>본인이 온전하게 본인에 대한 서비스 정책을 알고 있어야 깊이 있는 개선이 있다.</li>
<li>UI만 만지는 것으로만 큰 변화를 만들지 못한다.</li>
<li>본인이 담당하는 업무 도메인은 매우 깊게 이해해야 한다.</li>
<li>회사가 커질수록 나머지 전체에 대해서도 얇고 넓게 이해</li>
</ul>
</li>
</ul>
<h3 data-ke-size="size23">개발 시스템을 대충 이해해야 한다.</h3>
<ul data-ke-list-type="disc">
<li>나쁜 PM
<ul data-ke-list-type="disc">
<li>개발자가 알아서 하는 영역이라고 생각한다.</li>
</ul>
</li>
<li>좋은 PM
<ul data-ke-list-type="disc">
<li>전체 조직과 R&amp;R, 큰 시스템 관점에서 프로세스와 데이터 흐름을 이해한다.</li>
<li>그냥 네모 박스를 그리고 각 시스템들이 어떤 역할을 담당하는지 이해하자
<ul data-ke-list-type="disc">
<li>개발 이해 X</li>
<li>업무 프로세스와 데이터가 시스템들과 어떻게 엮어서 돌아가는지 이해 필요</li>
</ul>
</li>
<li>개발자의 도움을 받아서 이런 지도를 완성한다.</li>
</ul>
</li>
</ul>
<h2 data-ke-size="size26">감상평</h2>
<ul data-ke-list-type="disc">
<li>프로그래머는 “<b>문제를 해결하는 사람</b>”이다 라고 한줄로 정리한 부분이 가장 인상깊었던거 같습니다. 개인적으로 개발자로써 살아가면서 가장 중요한 능력은 문제 해결 능력이라고 생각합니다. 그게 개발이 아니더라도, 문제를 명확히 인지하고 해결책을 찾아 해결해 나가는 역량이 굉장히 중요하다고 생각합니다.</li>
<li>우리는 프로젝트라는 범위내에서 문제를 찾아, 해결책을 찾고 해결해 나가게 됩니다. 그 과정에서 많은 분들과 같이 협업을 하죠. 그 과정에서 결국 전체적으로 보는 매니징을 할 사람이 필요합니다. 요즘엔 문제를 찾아서 해결책을 고민하고 리서치를 하는 영역에서 PO / PM 이라는 직군의 영역의 경험을 하고 싶다는 생각이 들어서 최근 책도 읽고 혼자 프로젝트를 진행하면서 단순히 개발을 진행하는게 아니라 문서 정리와 리서치, 데이터 관점에서 어떻게 하면 바라볼수 있을지 고민해보고 있다.</li>
<li>그 과정에서 유튜브 알고리즘을 통해 이 영상을 봤는데, 내가 생각하는 내가 되고 싶은 PM이라는 역량을 딱 이야기 한거 같다. 난 여기서 가장 중요한건 “동기부여”라고 생각한다. 나와 같이 일하는 사람들에게 어떻게 동기부여를, 아니 나와 같은 동기부여를 가질수 있을지 항상 고민한다. 나 혼자만 동기부여가 있다는 것은 협업할때 도움이 되지 않는다고 생각한다. 가장 최고의 팀은 같은 길을 바라보는것인데, 그의 시작인 동기부여가 될거라고 생각한다.</li>
<li>유튜브 알고리즘으로 얻어 걸린것이지만, 이 짧다면 짧은 세미나를 보면서 많은걸 배웠고 많은 생각을 가지게 하는 세미나 내용이였다.</li>
</ul>
            
            
                </div>
            

                          
            
            </article></div>

Enthusiastically, Steady, Slowly

원본 영상 : https://www.youtube.com/watch?v=WVvFRh1vGv8
세미나 내용
동기유발
인간이 어떤 목표의 달성을 위해 노력하게 하는 계기를 마련해주는 것, 그것을 PM이 어느정도 해줘야 한다.
왜냐하면 PM은 개발자에게 업무를 요청하는 일을 많이 하게 됩니다. 이때, 개발자의 능력을 100% 끌어내는것. 이게 바로 PM에게 되게 중요한 역량이라고 한다.
그렇다면 나쁜 PM은 이 과정에서 어떻게 행동할까요?
일반적으로 PM은 다른 분들과 다르게 가장 먼저 시작하게 되고 고민하고 정리하기 시작합니다. 그러면서 자연스럽게 나의 일이 되는데, 그 다음에 잘 정리한뒤에 그냥 개발자에게 툭 던지게 됩니다.
이때, 툭 던지는 과정에서 단순히 PM은 개발자들에게 시키게 되고, 개발자들은 그걸 단순히 시킨일이라고 느끼게 되면서 재미 없는 일이 되는 과정이라고 생각합니다.
여기서 누군가가 다 정리해주고, 이대로 하라고 하는 부분을 느끼게 되면 재미없다라는 의미입니다.
OWN(나의 일)
결국 OWN(나의 일)이라는 개념이 중요하다고 생각합니다.
내 마음을 쓰는 진짜 나의 일 (이거 진짜 재미있는데, 내가 진심을 담아 하고 싶은 일)
어떤 일을 더 많이 신경쓰고 고민할 때 더욱 OWN
기획자는 스스로 업무를 준비하면서 OWN
누구든지 단순히 시키는 업무를 나의 일로 받아들이기는 쉽지 않다.
개발자도 마찬가지다.
따라서 좋은 PM들은 어떨까?
PM이 나의 일이 되는것까지는 동일하다. 이때 “이걸 해주세요.”라는 말이 아니라, 이걸 왜 해야 하는지 집요하게 생각하고 그것을 데이터와 고객관점, 회사의 가치라는 관점에서 설명을 집요하게 해준다. 개발자가 납득할수 있게 충분히 이 프로젝트에 대해서 이야기를 해준다.
이 과정에서 피드백을 받을 수 있는 창구를 열어준다. 기획서 리뷰를 할때 개발자가 피드백을 해줘야 하는 느낌을 잘 만들어 준다. 개발자가 이 기획에 참여하는 느낌을 만드는 경우를 만들어 준다. 즉, 피드백 사이클을 잘 만들어서 반영한다.
이러한 과정을 통해 개발자는 어느 순간 OWN(나의 일)이 되어 있다.
이걸 왜 하는가?
개발자는 문제를 듣는 순간 이걸 내가 해결해야 한다고 느낀다.
즉, 기획자뿐만 아니라 개발자도 나의 일로 만들어야 함.
그렇다면 어떻게? 개발자가 적극적으로 개입하게 상황을 만들어야 함.
WHY, 피드백, 개선점, 질문하기 등등
기획자가 보기에 기술적으로 어려워 보여도 기획을 조금만 틀면 더 적은 개발 리소스로 더 효과적인 것을 만들수 있음. 좋은 개발자는 이런 것을 잘 안다.
개발자가 더 많이 개입할 수록, 개발자 본인의 일이 된다고 느껴지고, 의견을 내고 개선할 수 있다는 느낌을 받아 적극적으로 대처한다.
인간적인 유대
이것은 삶의 기본
너를 믿는다. 서로 신뢰가 있어야 함.
이런 인간적인 유대가 중요한 이유?
상호 커뮤니케이션의 벽이 낮아짐
개발자 스스로 더 쉽게 피드백을 이야기 함.
스스로 더 많이 참여하게 됨
개발자가 업무를 OWN 할 가능성이 높아짐.
개발자를 움직이는 마법의단어
Solving problems is the core of compute sicence (컴퓨터 과학의 핵심은 문제를 해결하는 것이다.)
프로그래머는 문제를 해결하는 , 컴퓨터로 세상의 문제를 해결하는 것을 배운다.
따라서 프로그래머의 뇌에는 문제를 풀어야 한다라는 생각이 있다.
개발자를 움직이는 단어는 “고민이 있어요…”
예시
나쁜 PM
혼자서 일정을 다 정리해옴. (일정을 박아옴)
우선순위를 혼자 결정한다.
대안을 다 만들어 오는 것이 본인이 좋은줄 안다.
좋은 PM
개발자와 일정을 같이 논의하고 같이 일을 만들어 나간다는 느낌이 중요하다.
개발자가 참여하게 한다.
우리가 다 같이 이 일을 한다는 느낌을 만들어 준다.
고민거리를 주는것이 중요하다.
고민이 있습니다.
좋은 PM의 끝판왕
고수는 이미 답을 알고 있어도 물어본다.
깊이 있는 정책 이해
개발자 입장에서는 개발하려는 정책이 어떻게 되는지 정리해서 물어 봐야 합니다.
나쁜 PM
레거시라 잘 모르겠어요. 코드보면 안되나요?
UI화면 기반의 기획서만 만들고 끝
개발자가 코드를 안짜는것과 동일한거 아닌가? 직무유기가 아닐까?
좋은 PM
본인 도메인에 대해 술술 이야기 한다.
업무 프로세스랑 주요한 데이터흐름에 대해서 정리해서 머릿속에 가지고 있다.
본인이 온전하게 본인에 대한 서비스 정책을 알고 있어야 깊이 있는 개선이 있다.
UI만 만지는 것으로만 큰 변화를 만들지 못한다.
본인이 담당하는 업무 도메인은 매우 깊게 이해해야 한다.
회사가 커질수록 나머지 전체에 대해서도 얇고 넓게 이해
개발 시스템을 대충 이해해야 한다.
나쁜 PM
개발자가 알아서 하는 영역이라고 생각한다.
좋은 PM
전체 조직과 R&R, 큰 시스템 관점에서 프로세스와 데이터 흐름을 이해한다.
그냥 네모 박스를 그리고 각 시스템들이 어떤 역할을 담당하는지 이해하자
개발 이해 X
업무 프로세스와 데이터가 시스템들과 어떻게 엮어서 돌아가는지 이해 필요
개발자의 도움을 받아서 이런 지도를 완성한다.
감상평
프로그래머는 “문제를 해결하는 사람”이다 라고 한줄로 정리한 부분이 가장 인상깊었던거 같습니다. 개인적으로 개발자로써 살아가면서 가장 중요한 능력은 문제 해결 능력이라고 생각합니다. 그게 개발이 아니더라도, 문제를 명확히 인지하고 해결책을 찾아 해결해 나가는 역량이 굉장히 중요하다고 생각합니다.
우리는 프로젝트라는 범위내에서 문제를 찾아, 해결책을 찾고 해결해 나가게 됩니다. 그 과정에서 많은 분들과 같이 협업을 하죠. 그 과정에서 결국 전체적으로 보는 매니징을 할 사람이 필요합니다. 요즘엔 문제를 찾아서 해결책을 고민하고 리서치를 하는 영역에서 PO / PM 이라는 직군의 영역의 경험을 하고 싶다는 생각이 들어서 최근 책도 읽고 혼자 프로젝트를 진행하면서 단순히 개발을 진행하는게 아니라 문서 정리와 리서치, 데이터 관점에서 어떻게 하면 바라볼수 있을지 고민해보고 있다.
그 과정에서 유튜브 알고리즘을 통해 이 영상을 봤는데, 내가 생각하는 내가 되고 싶은 PM이라는 역량을 딱 이야기 한거 같다. 난 여기서 가장 중요한건 “동기부여”라고 생각한다. 나와 같이 일하는 사람들에게 어떻게 동기부여를, 아니 나와 같은 동기부여를 가질수 있을지 항상 고민한다. 나 혼자만 동기부여가 있다는 것은 협업할때 도움이 되지 않는다고 생각한다. 가장 최고의 팀은 같은 길을 바라보는것인데, 그의 시작인 동기부여가 될거라고 생각한다.
유튜브 알고리즘으로 얻어 걸린것이지만, 이 짧다면 짧은 세미나를 보면서 많은걸 배웠고 많은 생각을 가지게 하는 세미나 내용이였다.

[우아한 PM의 밤] 개발자가 생각하는 좋은 PM 나쁜 PM

댓글