프로덕트 리더가 반드시 피해야 할 5가지 실수

Posted in 일상 // Posted at 2023. 10. 10. 10:07
728x90

오랜만에 공감가는 읽을거리 하나 공유 합니다.
오전에 출근해서 메일링으로 온 것인데, 프로젝트를 리딩하는 입장에서 도음이 될 만한 내용이네요.


프로덕트 리더가 반드시 피해야 할 5가지 실수

 

프로덕트 리더가 반드시 피해야 할 5가지 실수

오늘은 프로덕트 리더가 범하기 쉬운 5가지 실수들에 대해 알아보고, 배달의 민족과 카카오를 거쳐 지금은 개발 이사로 일하고 있는 손현태 리더님의 인사이트까지 함께 확인해 보겠습니다.

www.grownbetter.com

 

특히 2번 내용에 적잖이 공감을 하는데...


2. 품질보다 양을 우선시한다.

빠른 성장을 추구하다 보면 제품 로드맵에 수많은 기능들을 가득 채우고 싶은 유혹에 빠지기 쉽습니다. 하지만 한 번에 모든 것을 처리하려고 하면 집중력이 흐려지고 팀에 부담을 줄 수 있습니다.

정확하고 단호하게 우선순위를 정하여 이러한 실수를 피하세요. 그리고 제품의 핵심 가치 제안에 집중하여 각 기능이 중요한 목표에 부합하는지 확인하세요. 변화하는 시장 상황과 사용자 피드백에 적응하기 위해 로드맵을 지속해서 검토하고 조정하는 것도 잊어서는 안 됩니다.


개인적으로 같은 맥락에서 조금 덧 붙이고 싶은 내용이 있다.

개발 스펙을 잡을 때,
무엇을 개발할 것인가? 를 정의하는 것 못지않게 중요한 것이 무엇을 개발하지 않을 것인가? 를 정의하는 것도 아주 중요하다.

소프트웨어 개발 현장에서 자주 목격되는 현상이다.
비즈니스의 전략과 그 전략을 실현하기 위한 본질만을 기능으로 정의(스펙인)하는 것을 넘어, 자기 자신이 이 기능에 대해 깊고 다양하게 생각할 수 있음을 피력하는 수단으로 스펙을 정의하는 실수말이다.

사실 이런 것들 중 대부분은 치장하기 기능으로 스펙아웃의 대상이 되어야 하거나 지금 당장은 필요치 않은 부가기능(핵심 기능을 런칭한 후 개발해도 되는 기능)들이 대부분이다. 즉 오버스펙이거나 좋은 기능이지만 지금 당장은 필요하지 않은 기능!

특히 스타트업은 시간과 자원이 한정되어 있다.
본질적인 기능을 시장에 빠르게 런칭하고 데이터와 고객의 반응을 보면서 점진적으로 개선해 나가는 것이 중요하다고 생각한다.

국제적인 프로젝트 관리 협회인 PMI 프로젝트의 3대 제약사항을 '일정/원가/범위'로 정의했다.
앞서 언급한 치장하기 기능들은 이 3가지 요소 모두에 영향을 미친다.
더불어 프로덕트의 품질에도 영향을 미친다. 더 많은 기능은 필연적으롸 더 많은 검증이 필요하고 더 많은 버그 가능성을 내포한다.

이것은 린스타트업, 린소프트웨어개발방법론의 철학에도 깔려 있는 원칙이다.
린 방법론의 핵심은 생산에 있어 낭비요소를 제거(or 최소화)하는 것이다.

소프트웨어 개발과정에서 불필요한 기능, 오버 스펙된 기능, 나중에 필요한 기능 등은 모두 (현재 시점에서는) 낭비요소이다.
핵심 기능만을 오류 없이 고품질로 런칭하여 프로덕트의 성장성과 기회를 빠르게 증명하는 것이 무엇보다 중요하다고 생각한다.

린 방법론에 대해서는 아래의 글이 핵심을 잘 정리해 놓은 듯 하니, 참고하면 좋겠다.
https://brunch.co.kr/@kbhpmp/22

 

'일상' 카테고리의 다른 글

금연 꿀팁(흡연의 욕구를 단박에 떨쳐버리기)  (0) 2023.10.26
다시 블로그  (0) 2023.09.27
성공한 후...  (0) 2022.07.13
기술사 면접 질문(2016년 4월 그때...)  (2) 2022.02.21
내가 취득한 자격증과 인증  (0) 2020.06.03

아무나 = 아무도 ?

Posted in 프로젝트관리 // Posted at 2012. 4. 12. 15:05
728x90

'아무나 하면 된다'에 아무나가 과연 누구일까?

 

프로젝트를 진행하다 보면 특정 그룹에 업무를 부여할 때가 있다.

근데 그 그룹에 특정 1인을 지목하기가 애매한 경우 그룹 전체에 부여하게 된다.

 

그러나 그 일은 한 사람이 맡아서 하면 될만한 일일 경우 간혹 다음 공식으로 귀결되는 경우가 있다

 

"아무나 = 아무도"

 

즉 아무나 하면 된다는 것은 아무도 하지 않는다는 씁쓸한 결과이다.

 

초등학교때 교과서에 이런 글이 기억날 것이다.

 

어느 화목한 가정에서 아버지가 가족이 모두 모인 저녁 시간에 바지 밑단을 좀 잘라 줬으면 하고 부탁했다. 그날 밤 엄마는 물론이고 자식들도 스스로 자신이 솔선수범하여 그 일(바지 밑단을 자르는 일)을 해 버리는 바람에 아침에 아버지는 반바지가 되어 버린 바지를 입어야 했다. 이 일을 자랑스럽게 여긴 아버지는 옆집 아저씨한테 이 말을 하자 그 옆집 아저씨도 자기도 한번 가족을 테스트(?) 해보 싶어졌다.

 

옆집 아저씨도 가족이 다 모인 저녁에 바지 밑단을 잘라 줬으면 하고 부탁했다.

다음날 아침, 설레이는(?) 맘으로 바지를 입어 봤더니 바지는 여전히 길게 축~ 늘어져 있던게 아닌가. 옆집 가족은 일종의 화목하지 않은 가정의 사례로 '누군가 하겠지' 하고는 다른사람에게 떠 넘긴 것이다.

 

이 이야기는 가족의 화목이라는 주제를 다룬 것이지만 여기서도 '아무나=아무도' 현상이 보이는 것이다.

 

프로젝트를 진행하다 보면 모든 팀이 한 가족처럼 화목(?)하지는 않다. 화목하지 않은 근원 이유를 제거하는 것이 가장 좋지만 여기서는 그러한 원론적인 해결을 논하려 하는 것이 아니다.

 

'아무나' 라는 애매한 설정이 결국 아무도 하지 않는 현상에 초점을 맞추려 한다.

 

심리학에 보면 '다수의 무지'라는 것이 있다.

수십명의 목격자가 지켜보는 가운데 처참하게 살해된 살인 사건에서의 교훈으로 '모두의 책임은 아무의 책임도 아닌 상태'가 되어버린다는 것이다. 그래서 위험한 상황이 발생하면 그냥 '도와 주세요'가 아닌 '그기 누구 나 좀 도와주쇼!'가 되어야 한다는 것이다.

 

특정 그룹이지만 특정인이 하면 되는 일은 그 일을 할 사람을 분명하게 지목해 주는 것이 좋다.

 

물론 위의 화목한 가정처럼 "아무나 = 전부다"의 공식이 성립하는 분위기라면 (바지 밑단이 과도하게 잘린 사소한 실수를 제외하고는) 더할 나위 없이 좋겠지만 우리네 프로젝트 환경이 꼭 그렇지는 않다는 것이다.

 

누구를 탓하기 이전에 좀더 정확하고 명확한 업무 부여가 필요하며 나아가 프로젝트에 참여하는 모든 구성원이 스스로 솔선수범하여 일을 척척 해 나가는 것이 중요하다.

 

그것이 프로젝트의 재미이지 않겠는가...

 

 

'프로젝트관리' 카테고리의 다른 글

조직의 비전 vs 개인의 가치  (1) 2013.04.02
Visual Studio 없는 소스관리  (0) 2013.03.13
경험 관리하기  (0) 2013.01.04
인수 요구 산출물  (0) 2013.01.03
그 사람을 대신 할 사람은 없다  (0) 2013.01.03