40
Riot Games 유유유 Inconvenient Truth An

An inconvenient truth

Embed Size (px)

Citation preview

Page 1: An inconvenient truth

Riot Games 유석문

Inconvenient TruthAn

Page 2: An inconvenient truth

이야기

Communication

Culture

Deadline

Conclusions

Page 3: An inconvenient truth

Deadline추측할 수 밖에 없는 상황에서 정확성을 고집하지 않는 태도는 지식인의 표시다 . - 아리스토텔레스 [Aristoteles, BC 384 ~ BC 322]

Page 4: An inconvenient truth

Uncertainty Principle - I

Page 5: An inconvenient truth

Uncertainty Principle - II QA 업무의 특징 및 문제점• QA 범위와 QA 기간을 동시에 정확히 알 수 없다 .• QA 범위를 정의 하면 QA 기간이 불명확해 지며 , QA 기간을

확정하면 QA 범위가 불명확해진다 .• 아무리 노력해도 줄일 수 없는 QA 기간의 임계값이 존재

• 초기 투입 인원 대비 인력을 늘리는 경우에도 Communication 에

의한 손실로 인하여 줄일 수 있는 기간에 한계가 있으며 때로는 인력

투입으로 인해 기간이 더 늘어난다 .

Page 6: An inconvenient truth

Uncertainty Principle - III Seok’s Suggestion(Not Suck !)• 목표 QA 범위와 기간 중 하나를 선택 한다 .• 한가지가 고정되면 다른 한가지를 추정 하고 보정 할 수 있는 예측

시뮬레이션을 활용 한다 .• WBS 가중치 방법 등

• 업무의 규모 및 특성에 맞는 적당한 투입 입력수가 존재 한다

• 통계 데이터를 수집 하고 분석하여 최적의 값을 찾아야 한다

• 조직에 가장 잘 맞는 시뮬레이션 모델을 개발 하고 발전 시켜 나가야

한다

Page 7: An inconvenient truth

적절한 QA 기간 ?? - I 개발팀 설문 조사 결과

• 2 주

왜 2 주일까 ?• 1 주라고 말하기엔 짧은 것 같고 빨리는 끝났으면 좋겠고… . • 제품 규모에 따른 기준 QA 기간 부재

• 개발팀은 QA 시작 시점에 QA 가 자신들과 동등한 수준의 제품

정보를 가지고 있는 것으로 생각 하는 경우가 많음 ( 자신들이 알기

때문에 남들도 알고 있는 것으로 착각 )

Page 8: An inconvenient truth

적절한 QA 기간 ?? - II Seok’s Suggestion (Not Suck !)• 제품 규모별 QA 기간에 대한 데이터 수집 및 제공

• Iteration 을 통한 QA 기간의 수렴 값을 결정 하여야

한다

• 개발팀 또는 기획팀에 의한 QA 기간 산정 금지

• QA 기간은 품질 목표에 맞추어 추정 되고 변경 되어야 한다 .

Page 9: An inconvenient truth

적절한 QA 기간 ?? - II Seok’s Suggestion (Not Suck !)• 개발 프로세스 끝 단에 한정된 QA 활동을 상위로 이동

(Moving Quality Upstream)• 개발 과정 초기부터 참여 하여 개발자와 동등한 수준의 제품

정보를 가져야 한다 .• 제품 개발 단계에 맞추어 테스트가 수행 되어야 한다 .• 위의 모든 조건을 만족 시킬 경우 프로세스 끝 단의 QA 기간이 2

주일 수도 있다 .

Page 10: An inconvenient truth

Deadline 은 왜 지킬 수 없는가 ?? - I 테스트 범위 및 품질 목표는 늘 변화 되며 상향 조정

되는 경향을 갖는다 .

• 테스트 시작 후 이해도가 증가 할 수록 업무 범위가

늘어남

• 특정 오류로 인하여 추가적인 테스트가 불가능한 상태

발생

• 테스트 수행 중 오류 수정 모듈에 대한 Regression

Test 수행 기간이 반영 되지 않음 ( 동시에 여러 개의

패치를 테스트 하고 있는 상황이 자주 연출 됨 )

• Deadline 은 고정이지만 요구사항은 고정되지 않는

다 .

Page 11: An inconvenient truth

Deadline 은 왜 지킬 수 없는가 ?? - II Seok’s Suggestion (Not Suck !)• Agile Practice 인 Incremental Implementation 을 이용

• 테스트 수행 결과를 이용하여 Deadline 을 예측 하여 보정 하여 나감

• 최소한의 QA 기간이 보장 되어야 함

Page 12: An inconvenient truth

The Management Paradox - I 프로젝트에 대하여 최우선적으로 파악 해야 할 것은 ?• 일정

Page 13: An inconvenient truth

The Management Paradox - IData 가 없을 때 선택 할 수 있는 관리 방법은 ?

Page 14: An inconvenient truth

The Management Paradox - II 독재와 무의미한 칭찬 만으로 얻을 수 있는 것은 반감 뿐이다 .• 일정을 목표로 한 관리 방법 지양

• 적절한 방법을 통한 Data 의 축적 및 활용 ( 예 : Agile Practices)

Page 15: An inconvenient truth

CultureNo culture can live if it attempts to be exclusive. - 마하트마 간디 [Mohandas Karamchand Gandhi , 1869.10.12 – 1948.01.30]

Page 16: An inconvenient truth

한국에는 너클볼 투수가 없다 - I 너클볼의 정의

• 투수가 던진 공이 거의 회전하지 않고 홈플레이트 (home plate) 에서

예측 불가능하게 변하는 특성을 갖는 구질

Page 17: An inconvenient truth

한국에는 너클볼 투수가 없다 - I 너클볼의 장점

• 공을 세게 던질 필요가 없다 ( 세게 던지면 회전이 발생 하여 안됨 )• 정통파 투수에 비하여 피로가 덜하여 더 많은 이닝을 소화 하며 자주 등판 할 수

있다 .• 활동 기간이 길다 (40 대에도 왕성 하게 활동 한다 )

너클볼의 단점

• 익히기가 어려우며 오랜 시간이 걸린다

• 너클볼을 받을 수 있는 포수가 드물다

• 기술이 완성 되기 이전에 사용 하면 난타를 당할 확률이 높다 ( 평균 구속 100Km 이하 )• 기술이 완성 되기 까지 기다려 주는 지도자가 드물다

Page 18: An inconvenient truth

한국에는 너클볼 투수가 없다 - II QA 업무의 특징 및 문제점• 긴박하고 짧은 Deadline 상황 에서 업무가 진행 된다

• 새로운 기술을 익히고 성숙 하게 만들 시간적 여유가 없다

• 새로운 기술에 대한 관리자의 믿음을 얻는 것에 실패할 확률이 높다

• 몸으로 때울 수 있는 다양한 방법이 있다

• 정말 부지런 하고 손이 빠른 사람이 많다

Page 19: An inconvenient truth

한국에는 너클볼 투수가 없다 - III• Seok’s Suggestion (Not Suck !)• 신기술 습득을 장려 하는 조직 분위기 확립

• 신기술 적용에 의한 단기간의 실패를 인정 하고 실패로부터 배울 수 있는

문화 확립 ( 실패를 비난 하는 분위기에서는 절대 개선 불가능 )• 외부에 의하여 실현 불가능 하게 주어지는 Deadline 이 아닌 QA

담당자가 현실적으로 가능한 Deadline 을 잡을 수 있는 환경 및 프로세스

• 담당자들의 신기술 습득을 위한 끊임없는 노력 ( 빠른 손은 30 대만 되어도

느려지기 시작 한다 ) • “ 예전부터 이렇게 잘 해왔어” 이 말 제발 하지 맙시다 .

Page 20: An inconvenient truth

Sinking Boat - I 증상• 급한 일을 진행 하느라 중요한 일을

하지 못함

• 인력을 늘려 보지만 급한 일은 더 빨리

증가 함

• 물 퍼내다 지쳐 멈추면 다 같이 빠져

버림

Page 21: An inconvenient truth

Sinking Boat - II Seok’s Suggestion (Not Suck !)• 급한 일과 중요한 일 사이의 조화 필수

• 전체 업무에서 반드시 중요한 일을 진행 하는 비율 설정

• 중요한 일의 비율을 급한 일보다 작게 설정 할 수 있지만 0 이 되어서는 안됨

• 급한 일이 일정 비율을 넘어서게 될 때 더 이상의 업무 할당이 되지 않는 문화 정착

• “ 이게 하던 방식이야” 말하지 않기

Page 22: An inconvenient truth

Negative Metrics - I 정의

• 정의된 Metric 중 징벌적인 용도로 사용되는 모든 Metric

Page 23: An inconvenient truth

Negative Metrics - II 영향

• QA 의 업무를 Defect Detection 수로 관리 할 경우 QA 는 Defect detection 부분에

역량을 집중 하게 된다 .

• 불행히도 Detection 에 집중 하면 개발프로세스에서 defect 는 감소 하는 것이 아니라

증가 하는 경향이 있다 .

• QA 는 Quality 에 집중 하지 않으며 Defect 의 수에만 집중 하게 된다 .

• 발견되기 쉬운 Defect 들만 보고 되며 치명적인 Defect 은 사용자가 발견 한다 .

• 개발자들은 Defect 을 은폐 하려는 경향을 갖게 된다 ( 코드 라인 수를 증가 시켜 오류

비율을 낮춤 )

• 개발자들과 QA 간의 상호 불신이 확대 된다

Page 24: An inconvenient truth

Negative Metrics - III Seok’s Suggestion (Not Suck !)

• 어떠한 Metric 도 비난의 목표나 수단이 되어서는 안됨

• 특정 Metric 의 수치적 개선을 목표로 삼지 않고 Metric 의

본질적 목표를 이해 하고 이용 어떠한 Metric 도 사용 의도에

따라 Negative Metric 이 될 수 있음을 명심

Page 25: An inconvenient truth

눈치만 보는 - I 경향

• 어떠한 의견도 개진 하지 않음

• 스펙 등 중요한 커뮤니케이션 내용이 잘 못 된

경우에도 이야기 하지 않음

• 잘 못 된 부분을 발견 하여도 절대로 이야기

하지 않음

• 자기 방어가 필요한 경우에만 열정으로 대화에

참여함

Page 26: An inconvenient truth

눈치만 보는 - II 원인

• 독재자에 의하여 지배 당할 경우

• 나만 모른다는 불안감

• 이야기 함으로써 자신이 공격의 대상이 되지

않을까 하는 불안감

• 추가적인 일을 더 만들게 되지 않을까 하는

불안감

• 자신과 관련된 업무가 아니기 때문

Page 27: An inconvenient truth

눈치만 보는 - III Seok’s Suggestion (Not Suck !)• There are no Dumb Questions

• 어떠한 의견도 경청되는 조직 문화 정착 (Freedom for Everyone)

• 개인이 의견을 표현 할 수 있는 다양한 채널 제공

• 내가 모르면 남들도 모른다 . ( 자신감 필수 , 집단 지성의 활용 )

Page 28: An inconvenient truth

압력 , 야근 그리고 끓는 물 속의 개구리 - I 압력과 납기일의 상관 관계에 대한 오해

• 압력을 가하면 납기를 어느 정도 단축 할

수 있다 .

• 어느 정도의 효과 라는 것도 무시 하지

못할 정도의 수준이다 .

• 그러므로 압력을 사용 하는 것은 적절한

방법이다 .

Page 29: An inconvenient truth

압력 , 야근 그리고 끓는 물 속의 개구리 - II 야근의 진실

• 압력이 가해지면 야근이 증가 한다 .

• 야근이 많아 지면 정상 근무 시간을 낭비 하고 야근 시간에 해결 하려는 경향이 나타난다

• 야근을 통하여 업무 지연에 대한 책임을 회피 한다 . ( 나 이렇게 고생 하니까 뭐라 하지

마 !)

• 야근을 통하여 추가적인 업무 할당에 저항한다 .

Page 30: An inconvenient truth

압력 , 야근 그리고 끓는 물 속의 개구리 - II 끓는 물 속의 개구리

• 업무가 과도 하게 주어지면 담당자는 추가

적인 업무 할당에도 반응 하지 않게 됨

• 할 수 있는 업무량을 벗어 났으므로 추가된

업무량이 아무리 많더라도 신경 쓰지 않게

• 어느 순간 Burnout 되어 버림

Page 31: An inconvenient truth

압력 , 야근 그리고 끓는 물 속의 개구리 - II Seok’s Suggestion (Not Suck !)

• 근무 시간에 집중할 수 있는 환경 조성

• 야근을 근면과 혼돈하지 말 것

• 야근을 보상의 대상으로 삼지 말 것

• 야근은 필요 악이 아닌 그냥 악임을 인식할

Page 32: An inconvenient truth

CommunicationThe greatest problem in communication is the illusion that it has been accomplished. - 조지버나드 쇼 [George Bernard Show , 1856.07.26 - 1950.11.02]

Page 33: An inconvenient truth

Fortress - I 정의

• 비밀 주의 또는 혼자 다해야 직성이 풀리는

특성을 가진 사람

특징

• 단독 작업으로 인하여 업무에 오류 개입 될

확률 높음

• 협업 문제

• 당사자 이직 시 문제 발생

Page 34: An inconvenient truth

Fortress - II 원인

• 강한 자의식

• 비난 받을 수 있다는 두려움

• 실패에 비난 하는 조직 문화에 의한 영향이 많음

• 독재자 밑에서 일을 하고 있는 경우

• 동료에 대한 신뢰 부족

• 협업 관계가 아닌 경쟁 관계로 인식

• 자신이 아는 것 만을 최고의 가치로 생각

• 나도 이렇게 배웠어…

Page 35: An inconvenient truth

Fortress - III Seok’s Suggestion (Not

Suck !)• 개인이 업무를 독점 하지 못하도록

제도화

• 협업에 대하여 보상하는 문화

• 실패를 비난 하지 않으며 실패로부터

배우는 조직 문화

• 상대방의 불안감을 인지 하고 공감

• 자발적으로 성 밖으로 나오도록 유도

Page 36: An inconvenient truth

Pair Programming - I 안 하는 또는 못하는 이유

• 둘이 한가지 일을 하면 능률이 떨어질 것이라는 선입견

• 둘이서 한 가지 일을 같이 하면 논다는 주변의 인식

• 서로 감시 한다는 느낌

• 혹시라도 망신 당하지 않을까 하는 두려움

• Pair Programming 을 할 수 없는 좁은 책상

• 대화를 하며 업무를 진행 하면 타인에게 방해가 되는 환경

Page 37: An inconvenient truth

Pair Programming - II Seok’s Suggestion (Not Suck !)

• Pair Programming 을 할 수 있는 물리적 환경

지원

• Pair Programming 시간을 업무에 명시

• 협업에 대한 보상

• 팀원 간의 신뢰 및 비난 하지 않는 문화

Page 38: An inconvenient truth

ConclusionsThere is no greater mistake than the hasty conclusion that opinions are worthless because they are badly argued. - 토마스 헉슬리 [Thomas Henry Huxley , 1825 - 1895]

Page 39: An inconvenient truth

사심이 많이 포함된 결론

• 무릎이 닿기도 전에 알 수 있는 방법은 없다 .

• 성벽 허물기

• 소통하기

• 다양한 문화의 Melting pot

• 진화 하는 조직

Page 40: An inconvenient truth

Q&A