데이터 팀을 위한 제품 사고

조직에서 어떤 상황에 직면한 적이 있습니까?

• C 레벨 또는 고위 경영진은 비즈니스 크리티컬 대시보드가 ​​중요한 회의에서 한동안 업데이트되지 않음을 발견했습니다.
• 제품 관리자인 데이터 소비자는 데이터 분석 팀인 데이터 생산자에게 지난 n일 동안 데이터 마트가 업데이트되지 않았음을 알립니다.
• 소프트웨어 엔지니어링 팀은 프로덕션 데이터베이스 스키마를 변경했으며 중요한 Growth Hacker 실험에 대한 소비자 이벤트를 업데이트하도록 데이터 엔지니어링 팀에 알리는 것을 잊었습니다.

불쾌한 현실

이전 기사( this 및 this )에서 데이터 제품의 기반을 구축하려고 했습니다. 이러한 제품은 데이터 생산자 팀(중앙 데이터 팀 및 도메인 데이터 생산자 팀)에서 만들고 다양한 소비자(마케팅 및 데이터 과학 팀 또는 최종 사용자)가 소비합니다. 서류상으로는 모든 것이 잘 진행되고 있습니다, 그렇죠?

에휴 현실은 좀 다릅니다. 우리 주변의 모든 사용 사례에 대해 "데이터 제품"이라는 용어를 사용하고 싶겠지만 현실은 대부분의 사용 사례가 "데이터 프로젝트"입니다.

그러나 데이터 제품과 데이터 프로젝트의 차이점은 무엇입니까? 이 질문에 답하려면 제품과 프로젝트의 차이점을 이해해야 합니다!

제품 대 프로젝트

저는 Futurice 가 만든 설명을 정말 좋아합니다 .

제품 ; 소프트웨어 또는 서비스일 수 있지만 특정 요구 사항을 충족하는 것을 목표로 하며 지속적인 유지 관리 및 업그레이드가 필요합니다. 따라서 제품 팀은 장기적으로 함께 제품을 구상, 구축 및 실행합니다. 결과에 관한 프로젝트와 달리 제품은 여정에 관한 것입니다. 알려진 끝점은 없으며 참가자는 진행하면서 학습합니다. 제품을 사용하면 각 수명 주기 단계가 언제 끝날지 알 수 없습니다. 예를 들어 언제 실험에서 성장으로 넘어갈지 알 수 없습니다. 성숙 단계에서 모든 것이 예측 가능해 보이더라도 언제 중단될지 알 수 없습니다. 제품 수명 주기를 제어할 수 없습니다. 당신이 할 수 있는 일은 변화에 대비하는 것뿐입니다.

프로젝트 ; 반면에 아이디어를 실행하는 방법입니다. 실질적으로 프로젝트를 시작하기 전에 많은 것을 이해해야 합니다. 시간, 돈, 가용 인력, 예상 품질, 프로젝트 실행 전반에 걸친 기타 모든 제약 조건 및 동인. 이것들은 모두 범위에 요약되어 있어야 합니다. 프로젝트는 실행에 중점을 둡니다. 지연되거나 예산을 초과하는 경우 스토리가 그렇지 않더라도 일반적으로 성공하지 못합니다. 프로젝트는 정의된 시작, 하나 이상의 이정표 및 고정 기한이 있는 임시 프로젝트입니다. 프로젝트가 끝나면 팀원들은 떠나고 새로운 프로젝트를 시작합니다. 프로젝트는 시작하고 성공하기 위한 예측 가능한 환경을 가정하며 계획은 프로세스의 필수 부분입니다.

이러한 설명을 바탕으로 데이터 프로젝트 및 데이터 제품의 예를 들어 보겠습니다.

• 데이터 제품: 전자상거래 웹 사이트를 위한 추천 엔진 시스템을 구축하여 고객 개인화 및 참여를 개선합니다. 고객은 권장 사항에 참여하고 데이터 포인트를 수집하며 모델을 개선합니다. 이것은 끝나지 않습니다.
• 데이터 프로젝트: C 레벨을 위한 명확한 설명과 목표가 있는 임시 보고서를 개발하고 이것이 미래에 다시 반복되지 않을 것이라는 것을 알고 있습니다! 밤 9시에 보고서를 전달하면 프로젝트가 종료됩니다!

초보자를 위한 제품 사고

그의 기사 "제품 사고 101" 에서 Naren Katakam은 제품 사고에 대한 훌륭한 설명과 예를 제공합니다 . 나렌에 따르면;

제품 사고는 사용자의 문제 공간에서 비즈니스의 솔루션 공간으로의 여정입니다. 이 여정의 목표는 사용자와 비즈니스 간의 격차를 줄이는 것입니다.

데이터 세계에서 사용자, 고객 또는 이해 관계자는 자신이 가장 잘 알고 있다고 생각하고 원하는 것을 제공하도록 요청할 수 있습니다. 예: C 레벨 임시 보고서. 문제 공간 연구에 추가 투자를 할 필요가 없고 이미 마음속에 해결책이 있기 때문에 주어진 주제를 전달하고 싶은 유혹을 느낄 수 있습니다. 하지마! 데이터 티켓을 생성하기 위해 이해 관계자를 Jira로 안내하는 데이터 담당자가 되지 마십시오!

넘어질 수 있는 다른 많은 함정과 이를 피하는 방법이 있습니다.

해결책이 아닌 문제부터 시작하라

모든 제품 여정은 사용자 문제에 대한 명확한 이해에서 시작됩니다. 사용자 문제는 제품을 형성합니다. 더 많은 질문을 할수록 더 많은 데이터를 수집하고 경로가 더 명확하게 드러납니다.

일반적인 실수는 적절한 문제 정의 및 연결된 KPI 없이 중간 상태에서 최종 솔루션 및 제품에 대해 생각하는 것입니다. Ash가 자신의 기사 "해결책이 아니라 문제를 사랑하라" 에서 언급한 것처럼 .

기능 공장이 되는 것을 피하십시오

기능 공장이라는 용어는 소프트웨어 또는 제품의 기능을 일관되게 대량 생산하는 회사를 말합니다. 이 용어는 일반적으로 품질보다 수량을 중시하는 회사를 설명하기 위해 부정적으로 사용됩니다. 제품이 할 수 있는 일의 수를 늘리려고 하면 결국 제품은 초점이 맞지 않고 부풀어 오릅니다. 기능은 제품에 가치를 추가하기보다는 지속적으로 업데이트하고 제품에 대한 과대 광고를 생성하기 위해서만 추가됩니다.

하지만 어떻게 이런 일이 일어날까요? 어떻게 제품 팀이나 조직이 중요한 기능을 선택할 수 없었습니까?

• HIPPO 효과: HIPPO는 약어이며 Highest Paid Person 's O pinion 을 나타냅니다 . 그 효과는 가장 높은 급여를 받는 사람의 의견이 그 자체로 더 높은 가치를 갖기 때문에 의사결정에서 더 많이 고려된다는 것을 말합니다. 따라서 의견의 문제는 해당 의견을 표명한 사람의 급여와 연결되어 있습니다. 급여가 높을수록 의견이 더 비판적입니다.
• 모든 사람을 기쁘게 하려고 노력: 이니셔티브와 기능의 우선 순위를 지정하는 중앙 집중식 방법론이 없으면 데이터 팀 비전이 명확하지 않고 이해 관계자가 무언가를 제공하도록 압력을 가하면 사물을 제어하고 모든 사람을 기쁘게 할 수 있는 모든 권한을 잃을 수 있습니다. 결국 아무도 사용하지 않는 불필요한 것들을 구축하게 됩니다.

지속적인 발견은 제품 개발 라이프사이클 전체에서 소규모 의 빈번한 활동으로 연구가 수행되는 민첩한 팀에서 사용되는 사용자 연구에 대한 접근 방식입니다 . 이것은 프로젝트 초기에 일회성 연구 활동에 집중하는 대신 모든 제품 결정에 고객 피드백을 주입합니다. 이 방법론에 대한 자세한 내용은 Teresa Torres의 책을 읽어 보시기 바랍니다 .

지속적인 발견은 제품 개발에서 생명을 구하는 기술입니다. 우리는 테스트하고, 데이터를 수집하고, 결과를 평가하고, 로드맵을 반복합니다.

프로젝트를 개발하면 실패할 가능성이 높습니다.

데이터 프로젝트가 실패할 것이라는 통계에 둘러싸여 있습니다.

• 빅 데이터 프로젝트의 85%가 실패합니다( Gartner , 2017).
• 데이터 과학 프로젝트의 87%가 프로덕션에 도달하지 못함( VentureBeat , 2019)
• "2022년까지 분석 통찰력의 20%만이 비즈니스 결과를 제공할 것입니다"( Gartner , 2019)

결론

제품 사고는 데이터 팀에서 육성해야 하는 사고 방식이자 문화입니다. 모든 사고 방식의 변화와 마찬가지로 이것은 또한 모든 곳에서 수용하고 적용하는 데 시간이 필요합니다. 소규모로 시작하여 파일럿 팀 또는 프로젝트를 선택하고 제품 팀으로 취급하기 시작합니다. 학습 내용을 수집하고 개선하고 확장하십시오. 조직에 대한 제품 사고처럼 들립니다. 맞습니까? 어디서부터 시작해야 할지 막막하다면 엔지니어 친구들에게 커피를 권하세요. 그들은 지난 40년 동안 이것을 적용하고 있습니다!

읽어주셔서 감사합니다

이 기사에서는 데이터(생산자) 팀을 위한 제품 사고를 엿볼 수 있도록 노력했습니다. 다음 기사에서는 데이터 팀의 핵심 팀 플레이어인 데이터 제품 관리자를 소개하겠습니다!