[일간 애자일#645](2/8) 덜컥 리더가 된 이가 비즈니스에 고전하는 9가지 이유 등

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

덜컥 리더가 된 이가 비즈니스에 고전하는 9가지 이유

직장인은 조직의 비즈니스에 ‘참여자’로, 리더와 책임을 나눠 갖는다. 지분은 없다. 그럼 직장인은 어디까지 비즈니스를 알아야 할까. 어려운 부분이다. 책에 씌여있는 경영 경제 관련 지식만으로는 어렵고, 그렇다고 모두 경험할 수 없다. 그렇다고 포기도 안된다. 꾸역꾸역 Business Friendly 하는 방법밖에 없다. 그런데, “그게 뭔가?!” 말이다. 급하게 리더급으로 올라선 대다수가 이런 혼란 속에 맴돌고 있다.

비즈니스는 어렵다. 그럼에도, 불구하고 우리는 비즈니스를 위한 노력은 좀처럼 하지 않는다

우리네 직장인은 조직에서 여러 이유로 다툰다.

더 많이 일을 하기 위해, 또는 덜 하기 위해.

하지만, 늘 마음대로 되지 않는다. 왜? 비즈니스를 잘 모르기 때문이다. 비즈니스가 무엇으로 구성되어 있고, 그중에 내가 맡고 있는 책임 영역이 무엇이며, 이것이 누구의 어떤 영역과 연결 및 중첩되어 있으며, 이런 복잡한 상황에서도 주어진 책임을 적절히 수행하고 있다는 증거(KPI)를 무엇으로 제시해야 하는지 말이다.

‘직장인’ 만큼의 근시안적 접근이 한계다.

결국, 우리 조직의 비즈니스가 무엇이고, 그중에 맡고 있는 영역 속에서 자의 반 타의 반으로 발생시켜야 할 가치와 최적화된 방법론에 대한 개발 및 적용은 꿈도 꾸지 못한다. 하루하루 해야 할 일(Works) 때문에 퇴근하기도 벅차다. 대다수가 오늘의 할 일을 어떻게 하면 슬기롭게(?) 내일로 미룰 것인가에 대하여 고민할 뿐이다.

당연히 비즈니스는 안중에도 없다.

회사가 잘 되는 것(성장하는 것)과 자신의 일이 잘 되는 것 사이에 미묘하고 복잡한 상관관계를 따지고 싶지 않다. 머리 아프기 때문이다. 그래서 열심히 머리 박고 주어진 일(Tasks)을 제 때(Due-date)에 처리하는 것만으로 목표를 하향 조정한다. 그리고, 이를 달성했을 때, 일에 대한 만족감을 느낀다. 그런데, 그것도 오래가지 못한다. 금세 익숙해지기 때문이다.

비즈니스를 위한 노력은 커리어를 위한 노력과 맥을 같이 한다.

그 익숙함에 대해 스스로 백기를 들고 환영하면 큰 일이다. 어느덧 경험과 연차가 쌓이며, 좀 더 무겁고 큰 책임을 짊어져야 할 자리에 갈 것이기 때문이다. 나도 모르게 ‘비즈니스에 가까워져’ 버렸다. 아뿔싸, 미리부터 비즈니스를 공부할 것…이라는 후회가 밀려온다.

그렇게 우리는 준비도 없이 리더 혹은 리더에 가까운 위치가 된다

<비즈니스에 고전하는 9가지 이유>

첫째, 시장 경험이 거의 없거나, 다소 생소하고 생경한 ‘비즈니스’에 겁 없이 뛰어들어 일을 해야 한다.
“나는 할 수 있다 또는 해야 한다”라고 무작정 믿는다.

둘째, 비즈니스를 비즈니스로 보는 것에 그친다.
비즈니스 속 여러 요소가 있음에도 ‘돈’만 집중해서 본다.

셋째, 사업에 정해진 길이 있다고 착각한다.
결국, 과거의 경험 또는 몇몇의 타인을 의존하여 의사결정을 한다.

넷째, 자신의 리더십에 대해 과소 또는 과신하고 있다.
자신이 어떤 리더십 스타일을 지향하는지 잘 모른다

다섯째, 함께 하는 동료들을 믿지 않는다.
그저 이용만 하려고 한다. 그걸로 충분하다고 믿는다

여섯째, 목적과 목표를 명확히 공식화하지 않는다.
발생한 문제만 우선적으로 대응 및 대처합니다.

일곱째, 한 단계 높은 성장 및 확장을 위한 복안(腹案) 등을 생각하지 않는다.
다양한 시나리오를 갖고 움직이지 않는다. (Pivoting = Spin off vs Split off)

여덟째, 비즈니스에 대하여 학습하지 않는다.
주어진 상황 안에서 판단만 내리려고 한다.

아홉째, 비즈니스와 자신의 인생 방향을 동일시하려는 노력을 하지 않는다.
비즈니스와 삶을 별도로 두고, 두 가지 페르소나를 갖추려고 한다.

원문: http://bit.ly/3nfYQzn


프로덕트 매니저가 제품 아이디어를 관리하는 방법

프로덕트 매니저로 일하다보면, 여러 경로로 제품에 대한 다양한 제안과 피드백을 받게 됩니다. 새로운 아이디어가 나타날 때마다 ‘앗.. 이거 해야 하나..?!’ 라며 흔들리지 않으려면 분명한 목표와 탄탄한 로드맵이 있어야 합니다. 그리고 그 로드맵 안에서 제안된 여러 아이디어를 잘 조합하고 훌륭한 액션 아이템으로 발전시켜 프로덕트의 개선을 만드는 것이 바로 프로덕트 매니저의 일입니다.

아이디어를 잘 모으고 관리한다는 것이 생각처럼 쉽지 않을 때가 많은데요. 번역/편집해 소개하는 아래 글에서는 아이디어 관리 방법을 단계별로 쪼개어 구체화해두었습니다. 여기저기 흩어진 아이디어는 많은데 어떻게 활용해야할지 고민된다면 참고해보시기 바랍니다.

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


PM에게 유용한 ‘인수 기준’ 작성법

How to Craft Strong Acceptance Criteria for a User Story 원문을 요약했습니다.

제가 일하는 팀은 인수 기준(Acceptance criteria)을 작성하지는 않고, 테스트 케이스를 프로젝트 초반에 작성하여 유사한 역할을 담당하는데요.

개인적으로 PM이 인수 기준(Acceptance criteria)의 범위와 pass/fail 기준을 신중하게 검토하는 것이 중요하다는 점에 공감이 되어서, 주요한 혹은 유저 스토리 대상으로 사례를 만들어볼까 생각해봤습니다.

인수 기준(Acceptance criteria)은 우리가 마치 장보기 할 때, 사야 할 물건을 정리한 리스트와 유사함. 프로덕트의 기능을 성공적으로 개발하기 위한 체크리스트, 일종의 완료조건.

에자일에서 유저 스토리(user story)는 ‘사용자’ 관점에서 기능이 무엇인지 정의하는 것을 의미함. 좋은 유저 스토리 정의는 필수적으로 좋은 인수 기준((Acceptance criteria)의 작성을 필요로 함. 인수 기준은 팀이 유저 스토리의 범위에 무엇이 포함되고, 무엇이 제외되는지 제품 개발 범위를 이해하는데 도움이 됨.

Best practices for writing acceptance criteria

# 1. Who, When and How?
# 2. Shared understanding and consensus
# 3. Clarity comes first
# 4. Make it testable, measurable and achievable
# 5. The format

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


생존을 위한 ‘피벗’…대기업도 별도의 괴짜 조직 만들어야

시장이 급변함에 따라 가설과 검증을 통해 비즈니스 모델을 빠르게 수정하는 피벗 전략의 중요성이 커지고 있다. 변화에 대한 유연한 대처가 핵심인 피벗을 실천하려면 린스타트업 방식을 이해해야 한다. 특히 대기업은 기존과는 다른 방식으로 팀을 디자인하며 혁신 조직을 만들어야 한다. 혁신의 종류에 따라 규정집의 부록 같은 별도 절차를 만들거나 아예 별도 건물에 독립적인 조직을 구축할 수 있다. 린스타트업의 선구자인 ‘스티브 블랭크’ 스탠퍼드대 교수는 기업의 규모와 상관없이 피벗 전략이 중요해진 만큼 구체적인 실행 방안이 필요하다고 강조했다. 그와의 인터뷰를 소개한 DBR 313호의 내용을 통해 알아보도록 하자.

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


How Programmers and Testers (and Others) Should Collaborate on User Stories

Have the testers on your team ever struggled with what they should do early in a sprint before the programmers have finished coding a user story?

And have the programmers ever wondered what they should do near the end of the sprint while the testers are verifying the implemented code? Are they tempted, perhaps, to start on the next user story even though it can’t be finished in the sprint?

When a team discovers the right way to collaborate on user stories, these questions vanish. Plus, the team is able to deliver more value more regularly to its stakeholders.

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


글쓴이: 정의의소

Agile Coach, Organizational Change Coach @Samsung Electronics 팟캐스트 MC : 새꿈사 (새로운 조직문화를 꿈꾸는 사람들)

답글 남기기

아래 항목을 채우거나 오른쪽 아이콘 중 하나를 클릭하여 로그 인 하세요:

WordPress.com 로고

WordPress.com의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Google photo

Google의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Twitter 사진

Twitter의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

Facebook 사진

Facebook의 계정을 사용하여 댓글을 남깁니다. 로그아웃 /  변경 )

%s에 연결하는 중