🫒 '스쿼드에 "다재다능한 개인"도 필요합니다' 등

'OLIVE LAB'는 오늘도 성장을 갈망하는 일잘러들을 위한 뉴스레터 입니다.
올리브영의 조직 성과와 조직 건강의 지속 성장을 연구합니다.

한 주간 인상깊게 읽은 비즈니스, 리더십, 매니지먼트, 조직문화 관련 아티클을
요약 정리해서 정성껏 담아 보내드립니다:D (마음에 드는 글에 '👍좋아요'도 눌러주세요)

✍️응원, 소감, 궁금하신 내용 그리고 함께 나누고 싶은 내용은 댓글로 남겨주세요.

스쿼드에 '다재다능한 개인'도 필요합니다 (Eddy's Pick)

"스쿼드 인원을 구성할때 참고하면 좋은 글입니다. 각자의 영역의 전문가로만 구성하는게 좋을까요? 모든 팀원이 팀에 필요한 모든일에 배우도록 하는게 좋을까요? 스쿼드 업무의 원할한 흐름을 만들어주는 다재다능한 개인을 적절하게 구성원으로 배치하는게 필요합니다."

스크럼, 스쿼드와 같은 애자일팀은 필요한 목적을 달성하기 위해 여러 역할자가 함께 한다. 이러한 팀을 '교차 기능(Cross-functional)팀' 이라고 한다.
'교차 기능팀은 팀원 모두가 서로의 일을 할 수 있어야 한다' 라는 말을 들어봤을 것이다. 그러나 이것은 사실이 아니다.
샌드위치 가게에서 주문을 처리하는 모습을 살펴보자. 한 두 명의 전담자(요리만 하는 사람, 계산만 하는 사람)를 볼 수 있고, 이어서 여러 일을 하는 사람들도 볼 수 있다. (고기를 썰다가 장갑을 벗고 전화 주문을 받는 등)
애자일 팀, 교차기능팀이 협업할 때도 다르지 않다. 즉, '모든 팀원이 업무를 완료하는 데 필요한 모든 기술을 보유해야 한다'는 말은 사실인냥 널리 전해져온 오해다.
애자일팀에 하나의 역할만 전담하는 전문가를 배치하는 것은 당연히 가능하다. 사실 각 구성원이 필요한 모든 기술을 모두가 갖춘 팀을 찾아 보기 힘들다. 그리고 팀원이 모든 것을 다 잘 할 수 있도록 하는 노력으로 오히려 생산성이 떨어질 수 있기도 한다.
그러나 반대로, 전문가에 대한 지나친 의존도 팀에 문제를 일으킬 수 있다. 하나의 역할만 전담하는 전문가가 너무 많으면 스프린트에 가져올 수 있는 업무 유형의 균형을 맞추기 어렵다.
몇 가지 사례를 살펴보자. 각 사람이 전문가인 4인의 전문가팀(예를들면, 개발자2명, 테스터2명)이다. 한 스프린트에서 전문가 수를 초과한 작업(개발 3건, 테스터 3건)은 이 팀에서 완료할 수 없다.
다음으로, 동일한 4명인데 2명은 전문가(개발), 다른 2명은 둘다(개발, 테스트)할 수 있는 경우를 살펴보자. 이렇게 여러가지를 할 수 있는 팀원을 다재다능한 개인이라고 부른다. 개발 전문가 2명은 개발만 수행할 수 있다. 그러나 다른 2명은 개발과 테스트를 모두 할 수 있다. 첫번째 전문가 팀보다 더 많은 업무를 완료할 수 있다. 즉, 다재다능한 개인이 포함된 팀은 전문가 팀보다 더 많은 업무를 완료할 수 있다.
팀에 매우 재능 있는 전문가를 두는 것은 잘못된 것이 아니며 실제로 그러한 전문가를 높이 평가해야 할 타당한 이유가 많이 있다.
그러나 훌륭한 애자일 팀에는 다재다능한 개인도 포함된다. 이러한 개인은 업무가 원할히 흐르도록 도움을 준다. 또한 각 전문 영역에 대한 토론시 균형 잡힌 관점을 제공하는데 도움을 준다.

'👍도움이 되었어요' 누르고, 원문 보러가기

PM이 사용자를 '영웅' 대우해야 하는 이유-스토리텔링 (Woody's Pick)

"Product의 특징을 만들어가는 과정에서 만들어지는 가설이 실제 Product 고객 또는 사용자가 원하는 것과 간극이 벌어져 결국 사용자가 원하지 않는 프로덕트가 만들어질수 있다는 본문의 글에 공감하여 이 글을 공유하게 되었습니다 :)"

PM으로 일하면서 제품 사용자의 입장이 되어 사용자 여정을 통해 그들이 왜 그와 같은 문제를 반복해서 겪는지 이해하려고 노력합니다. 이 문제가 제대로 이해가 된 후에야 PM은 비로소 사용자의 잠재의식 수준에서 참여를 유도하고 안내하는 제품을 기획할 수 있습니다.
영웅이 여정과 고객 여정의 유사점은 너무나 많습니다. 더 많은 사용 사례에 적합한 모델을 만들기 위해 12단계를 8단계로 단축한 댄 하몬의 '스토리 서클'을 고객 여정에 적용할 수 있습니다.
당신은 필요성이 있을 때, 어딘가로 가서 그것을 탐색하고 찾아내어 획득한 후 다시 돌아와서 바꿉니다.
스토리 서클은 사용자 여정을 맞추는 데도 적합합니다.
1) 당신 - 사용자 페르소나를 설명합니다.
2) 필요성 - 고객의 문제는 무엇인가요?
3) 출발 - 문제를 해결하기 위해 새로운 것을 시도해 봅니다.
4) 탐색 - 적합한 도구를 찾습니다.
5) 찾기 - 사용자는 자신의 문제에 적합한 도구를 찾아 실제 문제 해결에 접근합니다.
6) 획득 - 사용자는 가치를 발견하였기에, 시간이나 비용의 '투자'를 제공할 수도 있습니다.
7) 귀환 - 사용자는 이 기능에 익숙해지기 시작하고 점점 그 기능을 높이 평가하게 됩니다.
8) 일상의 변화 - 사용자/고객에게 제품은 삶의 필수적인 부분이 되었습니다.
좋은 서비스/제품을 만드는 요소는 많습니다. 그러나 사용자의 목표와 '스토리 아크'를 이해한다면 사용자의 스토리에 집중하고 하나씩 목표에 도달하도록 유도할 수 있습니다.

'👍도움이 되었어요' 누르고, 원문 보러가기

효과적인 코드리뷰를 위한 리뷰어의 자세 (Chad's Pick)

"오늘은 코드리뷰에 대한 글을 소개해드립니다. 코드리뷰는 일상적 활동이 되어 누구나 리뷰어가 되실 수 있습니다. 그중에는 리뷰에 대한 철학이나 태도에 대한 고민을 하시는 분이 계실 수도 있습니다. 우리 동료 개발자들은 어떤 리뷰 철학이나 태도로 임하시는 한번 살펴보시기 바랍니다. 그리고 코드 리뷰할때 어떤 점을 주의하시는지 동료와 함께 나눠보고 그라운드룰을 만들어 보는 것도 좋을 것 같네요. 마지막에는 저의 의견도 두개 덧붙혀 봤습니다. 원글은 예제나 더 많은 내용을 담고 있으니 궁금하다면 클릭!클릭!"

리뷰의 5가지 규칙을 토대로 리뷰어가 어떤 자세로 임하면 좋은지 알아보도록 하겠습니다
왜 개선이 필요한지 이유를 충분히 설명해주세요.
답을 알려주기보다는 스스로 고민하고 개선 방법을 선택할 수 있게 해주세요.
코드를 클린하게 유지하고, 일관되게 구현하도록 안내해주세요.
리뷰과정이 숙제검사가 아닌 학습과정으로 느낄수 있게 리뷰해주세요.
리뷰를 위한 리뷰를 하지 마세요. 피드백 할 게 없다면 칭찬해주세요.
추가팁-작은 커밋 단위만을 보지 말고, 전체 코드의 맥락을 살피면서 리뷰를 해주세요.
채드의 의견1 - 리뷰 대상은 코드입니다. 코드를 작성한 사람이 아닙니다.
채드의 의견2 - 리뷰어가 대상 코드의 의도를 찾지 못했을 수도 있다는 점을 항상 기억하세요.

'👍도움이 되었어요' 누르고, 원문 보러가기

🫒 '스쿼드에 "다재다능한 개인"도 필요합니다' 등

스쿼드 업무의 원할한 흐름을 만들어주는 다재다능한 개인을 적절하게 구성원으로 배치하는게 필요합니다.

스쿼드에 '다재다능한 개인'도 필요합니다 (Eddy's Pick)

PM이 사용자를 '영웅' 대우해야 하는 이유-스토리텔링 (Woody's Pick)

효과적인 코드리뷰를 위한 리뷰어의 자세 (Chad's Pick)

다가올 뉴스레터가 궁금하신가요?

이번 뉴스레터 어떠셨나요?

댓글

이전 뉴스레터

다음 뉴스레터

다른 뉴스레터