[일간 애자일#703](6/1) 리더인 당신, 진짜 잘 듣고 계신가요? 등

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

리더인 당신, 진짜 잘 듣고 계신가요?

CEO는 조직 내에서 가장 많이 정보를 수집할 수 있는 사람이지만, 막상 전달받는 정보는 의심스럽거나 정보로서의 가치가 손상돼 있는 경우가 많다. 또한 리더 스스로가 리더십에 대한 시대착오적 생각과 과신으로 인해 스스로 만든 ‘정보 버블’에 갇혀기도 한다. 자신이 한발 앞서 있다고 믿기 때문에 보고받은 정보를 있는 그대로 인지하지 못하는 것이다.

‘케빈 셰어러’와 ‘애덤 브라리언트’는 오랫동안 이 문제를 연구해왔다. 실제로 케빈은 세계 최대 생명공학 기업인 ‘암젠(Amgen)’의 CEO로 재직하며 실제로 정보 버블에 갇혀 본 적이 있었다. 애덤은 신문기자로 일하는 동안 600명 이상의 고위임원들을 인터뷰하며 그 위험성을 인지했다. 이들은 CEO가 정보 버블에 갇히지 않기 위해서는 ‘경청’하는 자세를 익혀야 한다고 말한다. 당연하게 들리겠지만 제대로 듣는 데는 생각보다 훨씬 더 많은 노력이 필요하다. HBR 2021. 3-4월호에 실린 기사를 통해 경청을 보다 효과적으로 습득할 수 있는 방법을 알아보자.

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


프로덕트 매니저 여러분, ‘소비자의 요구사항 수집’을 그만두십시오

본문은 위시켓과 번역가 전리오가 함께 만든 해외 콘텐츠 기반의 번역문으로, 기획과 UX 디자인을 중점적으로 다루는 블로그 매체 ‘부트캠프(Bootcamp)’의 글을 번역했습니다. 필자 ‘라이언 S.’는 IT 산업에 대한 통찰을 담은 글들을 부트캠프에 기고하고 있습니다. 본문은 프로덕트 기획의 과정 중 관점이 필요한 지점에 대해 해설하는 내용으로 읽어볼만한 가치가 있어 번역해 전해드립니다.

프로덕트 매니저들이 “저는 고객들로부터 요구사항을 수집해서 제품을 만든다”라고 말하는 걸 들으면, 저는 정말 화가 납니다. 그것은 마치 패스트푸드 매장에서 햄버거를 주문할 때, 고객이 원하는 모든 걸 세세한 사항까지 전부 맞춰주는 거라는 생각이 들기 때문입니다.

프로덕트 매니저들은 오히려 좀 더 소믈리에처럼 행동해야 합니다. 소믈리에는 와인 감별사를 말하는 것으로, 그들은 어떻게 하면 고객이 좋아할 만한 와인을 추천해 줄 수 있는지를 정확히 알고 있습니다. 심지어 와인을 전혀 모른다거나, 아니면 까다로울 정도로 특이한 질문을 하는 고객들도 능숙하게 상대합니다. 일반적으로, 소믈리에는 고객들이 어떤 와인을 주문할 지를 결정하는데 있어서 상당한 영향력을 미칩니다.

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


아마존은 왜 싱글 스레드 리더십을 만들게 되었을까?

스타트업에서 일하다 보면 100명을 기준으로, 주도적이고 기민하던 조직이 눈에 띄게 느려지는 것을 경험할 수 있다. 여러 가지 이유가 있겠지만, 의존성의 문제가 꽤 크다. 코드도 업무도 중첩되기 시작하면서 예전에는 독자적으로 넣던 기능 개발에 이제는 ‘조율’이란 의사소통이 필요해지기 때문이다.

특히 부족 단계 전후로 급격한 채용이 이루어지는 경우가 많은데, 직원 규모가 선형적으로 증가할 때 의사소통의 수는 대부분 기하급수적으로 증가하게 되고 점점 조직의 속도는 지연된다. 이런 의존성 문제는 단순히 속도 차원의 문제가 아니다. 다른 팀에 빈번히 의존하게 되면 영향력을 발휘할 수 없는 직원들은 의욕을 잃어가고, 조직적인 저항으로 인해 혁신 아이디어를 추진할 의지도 사라지게 된다.

세계 최고의 회사 중 하나인 아마존 역시 의존성 문제를 겪으며 ‘폭발적인 성장은 혁신의 속도를 늦춘다’라는 경향을 인정하게 되었다. 아마존의 기술, 조직 의존성 문제에 관한 사례를 하나씩 소개한다.

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


“MZ 눈치보면서 우린 막 대해”…서글픈 낀 세대, 75~84년생

“저희가 무슨 MZ세대인가요? 술자리부터 야근, 행사차출, 의전까지 실제 삶은 기성세대와 같은데. 내 정체성은 뭔가 싶어요.” (중견기업 83년생 A과장)

낀 세대. 기업부터 정치권까지 사회의 관심이 온통 MZ세대(밀레니얼·Z세대)에 쏠린 가운데 소외된 70년대 중후반~80년대 초중반 출생 세대의 왜소한 별칭이다.

사실 MZ세대의 구분은 미국식이다. 밀레니얼 세대는 윌리엄 스트라우스가 『세대들, 미국 미래의 역사』에서 처음 쓴 용어로, 1980년대 초반~2000년대 초반 출생자를 가리킨다. Z세대는 영미권 학자들이 20세기에 태어난 마지막 세대라며 1996~2010년에 태어난 인구집단으로 구분했다.

문제는 MZ세대의 범위가 워낙 넓고 한국 현실에 들어맞지도 않는다는 점이다. 국내 인구학 권위자인 조영태 서울대 보건대학원 교수는 “한국에선 75년~84년생이 같은 감정을 공유하는 X세대로 묶인다”고 말했다.

이들은 공통적인 사회·경제·문화적 환경에서 자랐다. 중간에 초등학교로 명칭에 바뀌었을지언정 ‘국민학교’를 경험했고, 수능시험을 봤다. 비슷한 나이일 때 각각 IMF외환위기(1997년)와 글로벌 금융위기(2008년)를 겪었다.

조 교수는 “90년대생인 밀레니얼은 부모가 교육부터 취업, 결혼까지 아낌없이 지원해준 첫 번째 세대인 만큼 공동체보다는 본인 중심주의일 수밖에 없다”며 “단적으로 X세대는 회사에서 부당한 처우를 받아도 참고 체념하는 반면, 밀레니얼들은 사표를 내버린다”고 예를 들었다.

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


커리어 관리에서 ‘자기계발’보다 중요한 세 가지

불확실한 자본시장에서 믿고 투자할 안전 자산은 오직 ‘나’ 뿐이다. 시장조사전문기업 엠브레인 트렌드모니터가 전국 만 19세~49세 급여소득자 남녀 1,000명을 대상으로 조사한 결과 전체 응답자의 3명 중 2명(67%)이 직무 및 업무와 관련한 자기계발을 하지 않으면 도태되기 쉽다고 생각했다. 즉, 자기계발을 하지 않으면 커리어 관리를 이어가기 어렵다는 것이다. 그런데 사실 커리어 관리에는 직무, 업무 관련 공부 외에도 더 주의 깊게 살펴야 할 세 가지가 있다. DBR 13호에 실린 기사를 통해 자세히 알아보도록 하자.

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


[일간 애자일#691](5/3) 캐나다 정부의 프로덕트 매니지먼트 정책 도입의 의미 등

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

캐나다 정부의 프로덕트 매니지먼트 정책 도입의 의미

  1. 피닉스 프로젝트 실패의 뼈아픈 교훈에서 출발

많은 나라의 정부가 추진하는 정보기술 정책에는 유사성이 있다. 기술에 대한 만성적인 과소 투자, 품질 기반 성능 평가시스템보다는 비용 중심적 평가, 사회 변화에 따른 데이터 및 디지털 역할의 확산 요구는 많으나 종종 디지털 리더십이 부족하고, 임기 내 위험 부담을 회피하는 환경을 갖고 있다. 많은 정부에서 정부 CIO 조직을 마련하고 컨트롤타워로의 역할을 추진하려 하고 있지만 CIO의 비전과 목표만으로는 기존의 업무 관행을 바꾸는 것은 거의 불가능하다.

캐나다 정부는 2009년 연방 공무원을 위한 새로운 급여시스템을 완전히 갱신하는 프로젝트 를 야심 차게 시작한다. ‘피닉스 급여 시스템’ 이라 이름 붙여진 이 거대한 프로젝트는 2년 동안 기술 파트너를 찾는데 시간을 보내고 2011년 IBM과 3천만 달러 계약을 맺는다. 그 후에 수많은 잡음과 충돌이 나고, 예산은 한정 없이 늘어나고, 2016년에 1월에 30만 명의 직원 신상정보가 유출이 된다. 그 후 2월에서야 첫 번째 출시가 된다. 품질 문제가 곧 나타나기 시작했고, 2017년 6월 말까지 누적 급여 오류가 5억 달러를 넘게 되었다. 엄청난 실패를 가져다준 프로젝트였다. 프로젝트가 실패한 원인은 다음과 같이 정리된다.

엔드 투 엔드 프로세스 변환에 대한 전반적인 관리가 제대로 이루어지지 않았다.
비즈니스 프로세스, 인력/기술, 조직 문화, 서비스 및 기능, 인사 데이터 및 관련 인사 시스템의 품질 및 적시 제공에 대한 포괄적인 계획이 개발되거나 구현되지 않았다.
정부 전체의 일관성을 위한 공통 비즈니스 프로세스가 충분히 상세한 수준으로 구현되지 않았다.
역할과 책임에 관해 설계, 문서화 또는 전체적인 프레임워크의 일부로 구현되지 않았다.
전반적인 거버넌스 기구는 없었다.
위험에 대해 오픈하는 문화가 없었고, 진실에 대해 말하는 것을 허락하지도 않았다.
충분히 테스트되지 않았다. 테스트 볼륨과 적용 범위는 시간 및 예산 압박으로 인해 최종 단계에서 축소되었다.

이렇게 어마어마한 예산을 들여 추진했던 프로젝트가 완전한 실패로 끝난 뼈아픈 경험을 가진 캐나다 정부가 최근 정보기술 부분에서 꽤 인상적인 변화를 만들고 있다. 소위 소프트웨어 기업에서 활용하고 있는 프로덕트 매니지먼트 관리기법을 사용하고 디자인 씽킹(Design Thinking), 린스타트업(Lean Startup), 애자일(Agile), 데브옵스(DevOps)까지 도입하며 빠르게 변화를 시도하고 있다.

그림 2는 캐나다 정부의 공공 디지털 서비스를 제공하는 캐나다 디지털 서비스(CDS)가 프로덕트 매니지먼트 그룹장을 채용 하는 공고이다. 정부가 사용하는 프로덕트/서비스를 기획하는 프로덕트 매니저를 관리하고, 정부와의 파트너 관계를 유지하면서 요청하는 디지털 서비스에 대한 비전과 솔루션을 제공하는 역할이다. 공고 내용을 살펴보면 실리콘 밸리에서 채용하는 프로덕트 매니지먼트 그룹장의 기준, 경험이나 역할과 다르지 않다. 단지 업무 파트너로서 정부 부서를 상대할 뿐이다.

매우 놀라운 변화가 아닐 수 없다. 많은 나라의 정부가 디지털 트랜스포메이션을 표방하고 변화를 시도했지만, 실제 프로덕트 매니지먼트를 도입하여 실행하고 있다는 것은 생각보다 훨씬 더 많은 변화를 의미하기 때문이다. 그중에서도 가장 큰 변화는 정부 디지털 서비스의 기준이 ‘프로젝트’에서 ‘프로덕트’로 패러다임이 넘어왔다는 것을 의미한다.

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


10배 빠르게 업무 성과를 내는 마인드셋

IT 기업을 중심으로 빠르게 사업을 실행을 하는 것이 사업의 중요한 경쟁력이 된다는 것은 이미 공감대가 만들어져 있다. 그리고 서바이벌을 고민해야 하는 스타트업에서는 그 중요성은 더욱더 크게 받아들여진다. 하지만, 빠르게 실행하는 것에 대한 우리가 가진 선입견 때문에 실제로 빠르게 실행하는 조직은 많은 것 같지 않다.

왜 많지 않다고 확신할 수 있냐면, 빠르게 실행하는 것은 실행의 속도의 문제가 아니기 때문이다. 일주일에 100시간 가까이 일하면서 빠르게 성장하는 스타트업을 본 적도 있지만, 그렇게 일하면서도 성장이 더딘 스타트업도 있다. 빠른 실행은 구성원들이 “실행”하는데 시간을 많이 쓴다고 그냥 얻어지는 것은 아니라는 것을 많은 사례로 보아왔다. 하지만 지금도 “우리는 빠르게 실행해야 해”라고 할 때 가장 먼저 얘기가 나오는 것은 근무 시간일 것이다.

시험 준비를 벼락치기하는 예를 들어 보자. 나도 중고등학교, 대학교, 대학원까지 길고 긴 학교 생활에서 벼락 치기를 하지 않았던 시험이 없는 것 같다. 벼락치기의 핵심은 내가 시험을 보기 전에 많은 시간을 투자해서 시험을 준비하는 것에 있지 않다. 시간이 얼마 남지 않은 제약이 생기고 나서야 나는 교과서 100페이지 시험 범위 중에서 어떤 것이 시험에 나올만 한지, 어떤 것은 그렇지 않은 지에 대해 매시간 고민하고 선택 취사해서 공부하게 되었다. 즉, 벼락치기의 핵심은 마감을 앞에 두고 고도의 집중도로 짧은 시간에 많은 일을 하는 것이 아니라, 짧은 시간 내에 내가 꼭 해야 하는 것을 발견(Discovery)해 나가는 것이 핵심이었다.

즉, 빠르게 실행하는 것은 정해진 결과물을 한정된 시간 내에 빠르게 만들어 내는 것이 아니다. 이건 불가능하다 (혹은 계속 그런 방식을 유지할 수 없다). 빠르게 실행한다는 것은 한정된 시간 내에서 만들 수 있는 목표와 가장 가까울 수 있는 결과물로 업무를 한정하고 이를 받아들이는 것이다. 빠른 실행에서 제한 요소는 결과물의 요구 사항이 아니라 시간인 것이다. 시간을 아무리 효과적으로 써도 24시간을 240시간처럼 쓸 수는 없다. 하지만 한정된 시간 때문에 우리가 정말 중요한 것만 보려고 한다면, 만드는데 240시간이 걸릴 만큼 결과물이 결국 어떤 가치를 전달하는 것인가에 더 집중하게 된다. 최종 목표로 생각한 결과물이 사실은 그 가치를 전달하기 위한 도구인 셈이다.

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


1편 일을 제대로 리딩하는 법 / 3화 일을 만드는 구조

Why는 일의 이유다. 안타깝게도 왜 그 일을 해야 하는지 알고 수행하는 사람은 많지 않다. 설명해주거나 설득하는 사람이 별로 없기 때문이다. 물론 Why만 유독 강조하는 관리자들이 있다. 이들은 괜찮은 사람처럼 보인다. Why를 강조하는 것은 업무에 뛰어들 분위기를 만드는 데 분명 도움이 된다. 하지만 이것만 늘어놓는 것은 허무함을 가져온다. ‘그래, 해야 한다는 건 알겠는데, 다음은 뭔 데?’라는 반응이 뒤따르기에 십상이다. 집은 당위성만 가지고 지을 순 없다. 이런 관리자는 실무에는 약하고 마음씨만 좋은 ‘몽상가’ 타입이다.

그 다음은 일의 주제(WHAT)다. 일을 잘 분류해서 단계별, 분야별 주요 사항을 발라내야 한다. 마치 집을 지을 때 집 전체를 받쳐주는 주춧돌과 기둥을 잘 아는 것과 비슷하다. 하지만 여기서 멈춘다면 실무자는 우왕좌왕할 수 있다. 구체적인 방도까지 함께 꿔내야 한다. 잘 모르겠다면 함께 찾아보자고 해야 한다. 본인도 모르면서 두루뭉술한 지시만 하고, 결과를 가져오라 독촉만 하는 관리자는 (나쁜) 권위주의자 타입이다.

실행(HOW) 단계에선 실무진의 의견을 들어야 한다. 단순히 의견을 수렴하는 것뿐만 아니라 일부 사안은 과감하게 위임하는 것이 필요하다. 특히나 요즘 젊은 세대는 본인의 의견이 일에 직접 반영되는 것을 선호한다. 전반적으로 그들의 자발적인 반응을 끌어낼 수 있다면, 작은 부분이 망가지는 것까지 감수할 수 있는 것이다.

마지막으로 교훈(Lesson learned)을 얻을 차례다. 일은 복기를 통해 완전히 종료되며 교훈을 남긴다. 그 교훈은 후일을 위한 기본 토양이 된다. 우리는 교훈을 얻기를 꺼리는 경향이 있다. 잘된 경우에는 뭘 그런 거까지 하나 싶은 생각이 들고, 못된 경우에는 안 좋은 기억과 다시 대면하기 싫기 때문이다. 그래도 맞닥뜨려야 한다. 그래야 일을 다시 시작할 수 있다.

원문:https://bit.ly/338fgSv


우리는 성장을 위해 올바른 노력을 하고 있는가

우리는 선택적 노력을 하지만,
그 선택은 전략적이지 못할 때가 많다

우리는 각자의 방식으로 성장을 위한 노력을 한다.

오래전부터 해왔던 여러 루틴을 꾸준히 가져가기 위해 하는 여러 종류와 힘이 필요한 다양한 노력부터, 어떤 일을 새롭게 시작할 때 하는 사전적 활동도, 새롭게 추진하여 실행한 일들을 잘 마무리 짓는 것도 모두 각자가 가진 방식대로 진행한다. 유지, 반복하는 것이 곧 성장할 수 있다는 믿음 아래, 새롭게 시작하게 되는 모든 일을 다할 수 없어 선택적으로 노력한다. 그것도 일종의 능력의 일종이다.

하지만, 우리는 이를 전략적으로 활용하지 못한다.

무언가를 새롭게 시작하여 이를 추진하는 것에만 초점을 맞추지, 그다음에 이어질 여러 활동들과의 인과 및 상관관계, 내가 현재 하고 있는 새로운 활동과 기존 활동 간의 ‘부딪힘’에 따른 긍정/부정적 효과 등 각종 시너지 등에 대하여 생각하지 않는 경우가 많다. 새로운 활동은 기존의 활동을 대체하거나, 가치를 더하는 쪽으로 해야 하지만, 이러한 관련성을 갖지 못한 경우가 많다. 그저 누군가를 따라 하거나, 좇거나, 막연하게 되고 싶다는 생각으로 하는 시도(try)에 가까운 것이 대부분이다.

예를 들어, 가장 일상적인 ‘독서’도 마찬가지다.

어떤 기준과 목적으로 책을 선택해야 하고, 그걸 어떻게 활용해야만 잘 읽고 활용한다고 볼 수 있고, 단순히 읽는 것에 그치지 않고, 함께 읽거나, 읽고 토의 또는 독후감과 같은 것을 쓰는 것도 마찬가지다. 기왕이면, 자신의 일과 삶에 적극적으로 도움을 줄 수 있는 요소를 갖춘 책을 고르는 것도, 이를 내 일과 삶에 전략적으로 활용하기 위한 읽고 활용하는 방법을 책과 그 주제에 맞도록 사용할 수 있는 것도 역량, 실력일 수 있기 때문이다.

**조금 더 기획적/전략적 요소를 더해보면, 되고자 하는 나를 위한 다양한 활동들이 널려있다. 처음에는 막연하게 누군가를 닮고 싶다는 생각을 갖고 시작할 수 있지만, 변화하는 자신의 모습으로부터 새로운 기획이 나타날 수 있고, 그에 대한 디테일을 부분적 전략과 전술로 검증하고 완성하는 과정에서 나만의 원리와 원칙(Principle & Rule)이 만들어질 수 있다. 물론 이 부분도 자연스럽게 변화한다. 이 과정에서 내가 가진 정체성(Identity)도 그 정체성에 어울리는 생각과 태도 등도 비로소 자연스럽게 나타날 수 있는 것(Routine)이다.

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


중고신입 전성시대..멘토링만 바꿔도 탈출 막는다는데..

지금 회사 그냥 다니기 VS 경력 포기하고 ‘쌩’ 신입되기
당신의 선택은?

취업포털 사람인이 올해 성인남녀 3833명을 대상으로 한 설문에 따르면 2명 중 1명은 경력을 포기하고 신입으로 지원한 경험이 있었다. 중고신입으로 지원해도 무리가 없을 저연차 사원들이 직장에 마음을 두지 못하는 것으로 보인다. 기껏 뽑았는데 1-2년 후면 나가버리는 현실 앞에서 조직의 고민도 깊다.

그런데 의외로 답은 가까운 곳에서 찾을 수 있다. 바로 멘토링이다. 대부분 회사는 입사 초 신입사원에게 선배 사원을 멘토로 붙여준다. 멘토가 어떻게 이끌어가느냐에 신입사원의 열정과 몰입을 끌어낼 수 있다고 한다. DBR 206호에 실린 기사는 심리학자 클레이튼 앨더퍼(Clayton Alderfer)의 ERG이론을 활용한 멘토링 기법을 소개한다.

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

[일간 애자일#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