<div id="readability-page-1" class="page"><div id="kakaoContent">

                <div>
                                            <p><a href="/m/category/%EA%B8%B0%EB%A1%9D">기록</a></p><h2>플랫폼에서의 MVP</h2>
                    <p><cite>
                        <span>Specialsooksook</span>
                    </cite>
                </p></div>
                <p><time>2020. 5. 14. 17:57</time>
                    <span>
                        
                                                    <a href="#comment" onclick="Utils.smoothScroll(this);return false">
                                
                            </a>
                        
                                                    <span id="title_daumlike">
                                
                                <span id="mobile-reaction"></span>
                                
                            </span>
                                            </span>
                </p>

                
                <div>
                    
<blockquote data-ke-style="style2">최소 기능 제품(Minimum Viable Product, MVP)은 고객의 피드백을 받아 최소한의 기능(features)을 구현한 제품이다.</blockquote>
<p>이 글은 플랫폼에서의 MVP를 말한다. 서비스에서의 MVP와는 시각이 다를 수 있다.</p>

<figure data-origin-width="0" data-origin-height="0"><span data-url="https://blog.kakaocdn.net/dn/br4PNX/btqD9O1ZB1b/mNHZHJ7SXQiNfphfwFcqOK/img.jpg" data-lightbox="lightbox" data-alt=""><img src="https://blog.kakaocdn.net/dn/br4PNX/btqD9O1ZB1b/mNHZHJ7SXQiNfphfwFcqOK/img.jpg" data-origin-width="0" data-origin-height="0"></span></figure>
<p>필수 요소에 대한 판단과 우선순위 결정은 상대적으로 경험이 많은 시니어분들이한다.(불만 없음) 큰 규모의 플랫폼의 서비스 일부를 MVP로 진행할 경우, 시니어분들은 기존 플랫폼의 히스토리와 스파게티처럼 꼬여있는 레거시들을 알고 있기 때문에 주니어들이 믿고 더블로 갈 수 있다. MVP로 가는 건 좋다. 하지만 권한과 책임이 명확한 상태에서 해야된다.. ^^(권한 없이 책임만 지라고 하는 곳이 많다...)</p>

<p>플랫폼에서 MVP는 관리자급들의 엄청난 결심이 필요하다. 이 광활한 시스템 상황을 다 알고 있으면서 마음먹을 수 있는 용기랄까....?? 엄두가 안 날 수 있다... 광활함 속에서 정말 필요한걸 아주 찰떡같이 골라야한다. 그렇게 우당탕탕하여 기준이 생기면 그 이후는 신뢰의 시간이다. 분석의 디테일.. 플랫폼에서 사양 정의는 진짜 꼼꼼해야 된다. 왜냐면.. 의사결정자가 모든 상황을 직접 분석할 시간이 없기 때문이다.(내용 공유 필수)</p>

<p>결론.</p>
<p>플랫폼에서의 MVP를 위해서는 해당 시스템을 적어도 7년 이상 경험한 시니어가 필요하며, 꼼꼼한 기획자가 필요하며, 권한과 책임이 명확한 조직이어야 한다.(아니라면 하면 안 된다)</p>

                                                            
                    
											
					
                    
                    
                </div>

                                    
                
                
                                    
                
                


                

                                    
                
                
            </div></div>

기획자 쑥쑥이

최소 기능 제품(Minimum Viable Product, MVP)은 고객의 피드백을 받아 최소한의 기능(features)을 구현한 제품이다.
이 글은 플랫폼에서의 MVP를 말한다. 서비스에서의 MVP와는 시각이 다를 수 있다.
 
필수 요소에 대한 판단과 우선순위 결정은 상대적으로 경험이 많은 시니어분들이한다.(불만 없음) 큰 규모의 플랫폼의 서비스 일부를 MVP로 진행할 경우, 시니어분들은 기존 플랫폼의 히스토리와 스파게티처럼 꼬여있는 레거시들을 알고 있기 때문에 주니어들이 믿고 더블로 갈 수 있다. MVP로 가는 건 좋다. 하지만 권한과 책임이 명확한 상태에서 해야된다.. ^^(권한 없이 책임만 지라고 하는 곳이 많다...)
 
플랫폼에서 MVP는 관리자급들의 엄청난 결심이 필요하다. 이 광활한 시스템 상황을 다 알고 있으면서 마음먹을 수 있는 용기랄까....?? 엄두가 안 날 수 있다... 광활함 속에서 정말 필요한걸 아주 찰떡같이 골라야한다. 그렇게 우당탕탕하여 기준이 생기면 그 이후는 신뢰의 시간이다. 분석의 디테일.. 플랫폼에서 사양 정의는 진짜 꼼꼼해야 된다. 왜냐면.. 의사결정자가 모든 상황을 직접 분석할 시간이 없기 때문이다.(내용 공유 필수)
 
결론.
플랫폼에서의 MVP를 위해서는 해당 시스템을 적어도 7년 이상 경험한 시니어가 필요하며, 꼼꼼한 기획자가 필요하며, 권한과 책임이 명확한 조직이어야 한다.(아니라면 하면 안 된다)

플랫폼에서의 MVP

댓글