[일간 애자일#642](2/3) 전통적인 PRD 접근법을 피하고 제품을 만드는 방법 등

  • 매일 애자일, 린, 조직문화, 협업, 리더십, 자기계발 등과 관련된 새로운 소식을 공유드립니다.
  • 소감, 동의, 반론 등을 댓글로 남겨주세요. 활발한 소통을 기대합니다.
  • 지난 기사는 [여기]에서 보실 수 있습니다

전통적인 PRD 접근법을 피하고 제품을 만드는 방법

문제점 해결을 위해 프로덕트가 다룰 비즈니스 케이스, 기능 등을 포괄적으로 요구사항이라 부를 수 있다. 제품에 대한 이와 같은 요구 사항의 모음을 PRD라고 함.

PRD(Product requirements document)의 목표는 디자인, 분석, 엔지니어링, 데브 옵스, QA, 마케팅, 영업과 같은 cross-functional team이 효율적인 협업을 지원하는 것이 목표임

전통적인 PRD는 요구사항을 바탕으로 기능 목록을 나열하는 형태로 구성됨. PRD가 설명하는 기능 및 사양에 따라 Jira와 같은 툴을 통해 세분화되어 개발 담당자에게 배정되는 형태임. 전통적인 PRD는 제품에 대한 비전을 구성원에 팔지 못하며, 구성원에게 자극시킬 동기부여를 제공하지 못하며 아래에 대한 답을 제공하지 못함.

  • 프로덕트가 중요한 이유는?
  • 우리의 고객은 누군가?
  • 고객의 문제점을 어떻게 해결할 것인가?
  • 프로덕트 출시 이후 회사에 미치는 영향은?

결국 PRD는 고객의 목소리를 담는 것이 아닌 PM의 의견만을 담는 수단이 됨. 저자는 PRD가 what뿐만 아니라 why를 담아야 내야 한다고 설명.

  • 고객의 pain point는 무엇인가?
  • 이 제품에 적합한 고객은 존재하는가?
  • 지금 이 제품을 출시하기 적기인가?
  • 회사의 비전과 일치하는가?

PM은 문제점을 정의하지 않고 바로 솔루션을 정의하려는 유혹(또는 실수)에 빠짐. 이를 피하기 위해 Concept Note, User Stories를 PRD에 담을 것을 제안함

Concept Note는 제품 개발의 당위성, 풀려는 문제점 등을 담아 구성원의 공감대를 이루기 위한 것이 목적임. 솔루션을 하이 레벨로 풀어낸 사업계획서 같은 형태로 생각하면 됨.

User Stories는 에픽과 스토리로 구성되며, cross-functional team 담당자가 사용자에게 전달되는 기능 레벨로 상세하게 정의 필요. 스토리가 상세할수록 제품 개발 관련 스프린트 플래닝 단계에 도움이 됨.

원문: https://bit.ly/3oGRpBL


[DBR] 디지털 주도권을 위한 리더의 5가지 과제

새로운 디지털의 변혁에 맞서 리더십의 모습도 바뀌어야 한다.

첫째, 다양성을 진심으로 포용하고, 배경에 관계없이 직원들이 소외감을 느끼지 않도록 리더의 언어를 점검해야 한다.

둘째, 폭넓은 지식을 학습하면서 협소한 전문 영역에서 벗어나 세계관을 계속 확대해야 한다.

셋째, 팀원들과의 신뢰를 구축하고 효과적인 협업을 지속적으로, 더 철저히 추구해야 한다.

넷째, 사람들이 자유롭게 목소리를 내고 도움을 요청할 수 있도록 생산성을 넘어 창의성을 육성해야 한다.

다섯째, 디지털 기술이 실현 가능한지, 조직에 가치가 있는지, 인간과 사회에 유용한지 살펴본 뒤 이 기술이 가지는 놀라운 힘을 잘 활용해야 한다.

원문: https://bit.ly/3assigT


스타트업에서 성장하기 위해 필요한 3가지 태도

“일을 잘 하는 법에는 정답이 없더라고요. 회사 분야, 동료, 타이밍에 따라 달라질 뿐이죠. 그렇기 때문에 자기주도적인 자세, 문제 해결력, 자신이 필요한 스킬이나 역량을 잘 습득하는 러닝 커브 (learning curve)가 빠른 것, 3가지가 중요하다는 걸 스타트업에서 일하면서 알게 되었어요.”

여성 중심 스타트업 커뮤니티 ‘스여일삶 – 스타트업 여성들의 일과 삶‘에는 스타트업 여성이라는 공통점을 중심으로 다채로운 분야에서, 다양한 일을 하는 사람들이 모여 있습니다. 그런 스여일삶 멤버들의 목소리를 담는 인터뷰 시리즈 – 스여일담 (談)!

첫 번째 인터뷰에서는 스타트업 특유의 무질서와 혼란을 사랑하며 자신의 일과 삶을 꾸려가는 ‘어니스트펀드’ 최보금 님의 이야기를 들어봤다면 (최보금 님 인터뷰 글 참고) 오늘은 공유 오피스 ‘스파크플러스’에서 대외 커뮤니케이션과 커뮤니티 웹/앱 서비스를 기획하는 이혜원 님을 만나보겠습니다.

원문: https://bit.ly/2YAD92V


[HBR Korea] 새 동료가 당신을 싫어할때

새 직장으로 이직 후 몇 달 동안은 새로운 모험에 흥분되면서도 여기가 나와 잘 맞을지 걱정이 될 겁니다. 그러니 나를 반기지 않거나 심지어 깎아내리는 동료가 있다면 당황스럽겠죠. 그런 행동은 당신이 최고의 성과를 내는 데 방해가 될 뿐 아니라 당신의 평판에 위협이 될 수도 있습니다. 그가 회사에서 영향력 있는 사람이라면 더 그렇겠죠.

새 직장 동료와 잘 어울리지 못하는 건 흔하게 일어나는 문제입니다. 외부에서 고용된 임원 중 절반은 18개월 안에 실패하는데 주로 회사 문화에 동화되지 못하거나 조직 적응에 실패하기 때문이죠. 새로 임명된 리더들에게 동료들과 잘 지내는 건 너무나 중요한 문제여서 남성의 58%와 여성의 74%가 고소득 일자리를 거절하기도 합니다. 그게 동료들과 잘 지낼 수 없는 자리라면 말이죠.

새로운 조직에 합류한 초기에는 동료들이 여러 가지 방면에서 당신을 뒤흔들 겁니다. 그중 대부분은 당신이 통제할 수 없는 것들이죠. 하지만 그들이 어떻게 생각하든 당신이 의욕을 잃거나 성공에 방해받지 않을 수 있는 방법도 있습니다. 여기 그 전략을 몇 가지 소개합니다.

  • 그들이 분개하는 건 당신이 아니라 당신이 대변하는 어떤 것입니다
  • 당신만의 자문단을 만드세요
  • 적들을 포섭하세요
  • 당신 책임은 인정하세요

원문: https://bit.ly/3rmsdlT


화를 진정시키는 대화법

원문: https://bit.ly/3pHEZL3


[일간 애자일#566](10/5) 애자일-디자인씽킹-린 스타트업, 이거 정말 좋은건가요? 등

  • 매일 애자일, 린, 조직문화, 협업, 리더십, 자기계발 등과 관련된 새로운 소식을 공유드립니다.
  • 소감, 동의, 반론 등을 댓글로 남겨주세요. 활발한 소통을 기대합니다.
  • 지난 기사는 [여기]에서 보실 수 있습니다.

애자일-디자인씽킹-린 스타트업, 이거 정말 좋은건가요?

코로나 기간을 거치면서 평소보다 훨씬 더 많은 기업과 조직들이 디지털 혁신 계획을 발표하고 실행하면서 요즈음 애자일 agile, 디자인씽킹 design thinking, 린 스타트업 lean startup 이라는 단어가 소위 유행어 buzzword처럼 세상에 소개되어지고 생활로 내려 오고 있습니다. 이런 유행처럼 소문과 권위를 동반하여 소개되고 조직에 도입되는 방법론과 프로세스는 도입 전에 올바르게 이해하고 그룹의 상황에 맞도록 사용하지 않으면, 과정에서 생성되는 최고의 결과물인 베스트 프랙티스를 기대하기 어렵게 되고, 또한 이 방법론만이 현재의 상황을 해결 할 수 있는 만능 해결책이 될것이라는 위험한 믿음을 갖게 됩니다. 예를 들어 하루짜리 디자인 씽킹 워크샵을 다녀와서는 현재 엔지니어링 그룹의 모든 문제, 이슈, 계획을 디자인씽킹을 통해 해결하려 하는 시도를 할 수 있다는 것입니다. (주로 상위 레벨의 매니저들 행동에서 쉽게 보여집니다.) 이 경우 지속가능하고 성공적인 제품/서비스의 릴리즈는 어려워 질 수 밖에 없을겁니다. 제 경험상 무엇보다도 애자일, 디자인씽킹, 린스타트업 이 세가지를 학습하고 구별한 후에 나름대로 적용하고 발전시키는 반복적인 과정이 중요하다고 판단해서 오늘은


• 애자일/디자인씽킹/린스타트업을 간단히 설명하고, ( 각각의 방법론-프로세스 자체를 설명하지는 않고, 글의 전개상, 이 세가지 프로세스가 현실에서는 어떤 상황을 만들어 내는지 이야기를 진행 하기 위한 소재에 필요한 부분만을 설명합니다.)
• 훌륭한 디지털 프로덕트/서비스를 만들기 위해 반드시 알아야 하는 것에 대해서 이야기 하면서
• 그 과정서 이들 방법론, 프로세스를 어떻게 이용하는 것이 현명하고 지혜로운것인지에 대해서 이야기를 나누어 볼까 합니다.

원문: https://bit.ly/3irsMGa


구글의 PM이 말하는 PRD 작성 과정 (PRD, Product Requirement Document) 작성 팁

애자일 개발 방식이 스타트업을 중심으로 인기를 얻게 되면서 제품 요구사항 정의서(PRD, Product Requirement Document)를 작성하는 데 시간을 소비하는 것이 맞는지 궁금해하는 기획자가 늘었습니다.

구글의 프로덕트 매니저(PM, Product Manager)인 Omar Eduardo는 그의 블로그 글을 통해 PRD가 여전히 다양한 분야에서 그 힘을 입증하고 있다고 말합니다.

PRD에는 다음과 같은 내용이 담겨져 있습니다.

PRD는 제품 혹은 그 제품이 가진 기능이 가진 문제를 요약합니다. 또한 PRD는 그 안에서 다룬 해결책이 사용자에게 어떤 이로움을 줄 수 있는지 기술합니다.

PM은 제품이 가진 문제가 사용자 여정(User Journey) 가운데 어떤 마찰(Churn)을 일으키는지 파악해야 합니다. 또한 문제가 해소된 상황에서 사용자가 누리게 될 이점에 초점을 두고 제품의 특징을 구체화시켜야 합니다.

PRD 작성에는 정해진 규칙이 없습니다. 하지만 분명한 것은 이 과정을 통해 프로젝트는 보다 뚜렷한 목표를 갖게 되고, 이해관계자들의 시각도 하나의 점으로 수렴된다는 점입니다.

제품 요구사항 정의서 PRD 작성 과정

1 단계: 사용자들이 겪고 있는 문제와 비즈니스가 우선시 해야 할 사안에 대해 기술하고, 왜 그렇게 정했는지 근거를 제시합니다.

​2 단계: 1 단계를 거치면서 보다 윤곽이 뚜렷해진 사용자의 문제에 대한 해결방안(Solution)을 보다 구체화할 수 있는 세부 정보를 더해 나가야 합니다.

3 단계: UX디자이너, 개발자 등과의 PRD 리뷰 과정을 통해 사용자 관점에서 기능적 요구사항(Functional Requirement)을 보다 명확하게 해야 합니다.

4 단계: 위 과정에서 발생하는 다양한 이슈들을 기록해 두어야 합니다.

​5 단계: 개발중에 발생하는 변경사항들을 놓치지 않고 지속적으로 업데이트해야 합니다.

원문: https://bit.ly/333YHrK


피드백의 수용도를 올리는 방법

리더마다 타고난 솔직함을 가지고 있는 사람이 있습니다.

어떤 상황에서든 솔직함을 무기로 대화를 시도하죠.

반대로 어떤 리더는 배려와 공감이라는 무기를 가지고 있습니다.

가능한 상대방을 이해하고 그의 관점에서 솔직함 보다는 공감을 무기로 대화를 합니다.

둘 중에 누가 더 탁월한 리더인지는 모릅니다.

구성원들이 판단해 주겠죠.

나에게 이익을 준 리더를 말이죠.

그런데 피드백을 배우고, 피드백을 단계별로 사용할 수 있다면

강점은 강점대로 약점은 조금 개선되는 모습으로 리더십을 발휘할 수 있습니다.

저는 ‘피드백은 스킬’이라고 이야기 합니다.

물론 피드백을 하는 이유에 대해서는 그 상대를 위하는 마음으로 시작해야 겠지만요.

‘아는 만큼 사용할 수 있다.’

이는 제가 HRD를 할 때 자주 사용하는 문장 입니다.

스킬은 관심을 가지고, 시간을 투자해서 배우면 되거든요.

그리고 그렇게 배운 피드백 스킬은 사람을 성장시키는 도구가 됩니다.

그의 성장과 성공을 위한 마음을 먼저 생각해 보세요.

원문: https://bit.ly/3iAbzKp