Skip to main
경고 지표를 무시하지 않기 위해 버그 리포팅 시스템을 활용하는 것
- 경고 지표는 언제나 사고 전에 존재한다
- 그러나 시스템이 경고 지표를 무시하도록 강요한다
- 장애를 분석하는데 있어서 “개인적 요소"는 큰 영향을 주지 않을 것
- 만에 하나 큰 영향을 주었다고 해도, 이는 개인에 대한 교육등으로 간단하게 가능할 것이다.
- 반대로 모든 장애는 “시스템적 요소"가 숨어있다
- 이로인한 “개인적 요소"는 무시되어야 한다.
- 예) 수십개의 명령어를 써야지 로그를 확인할 수 있다고 했을때, 로그를 보지 않는것은 “프로그래머의 귀찮아 하는 성격"을 수정해서는 효과가 없다.
-
- 프로그래머가 경고를 보고 수정하면, 수정 시간이 벌로 느껴짐
- 자신이 하고 싶어하는 일을 하지 못하기 때문에
-
- 프로그래머가 경고를 보고 수정해도 “수정 이후에 장애가 없음"이 보상으로 느껴지지 않음
- 장애 없음이 “자신의 수정 덕분"인지 “그냥 버그가 없었던 순간"인지 명확한 피드백이 없기 때문에
-
- 프로그래머가 경고를 보고 무시하면 “자신의 시간을 벌게됨”
-
- 무시한 경고로 인해서 장애가 일어나도, 이는 피드백의 시간이 길어져서 “경고를 무시한 벌"이라고 느껴지지 않음
- 피드백의 시간이 너무 나중이라, “그냥 언젠가 일어날 일"정도로 느껴짐.
- 직접적인 연관을 느끼기 힘들 것
- 따라서
프로그래머가 경고 지표를 보고 무시하면 벌을 주고, 무시하지 않는다면 상을 주어야한다
- 단순한 보상과 벌로는 안된다 재미이론
- 그러나 벌이
벌금, 연차 자르기등으로 이루어 진다면 정말 최악의 벌
- 마찬가지로 보상도
상금 혹은 추가적인 연차등으로 이루어 지는것도 최악의 보상
중요한 것은 금액이 아니라 자신의 행동을 실제로 느낄 수 있는 데 있다. 금액이야 10분의 1일 수도 있고, 심지어 100분의 1일 수도 있지만, 그 효과는 같다. 안티프래질재미이론보상
- 재미이론에서 “보스를 쓰러뜨린 보상은 아이템이 아니라 다시 도전할 수 있는 다음 스테이지"라고 표현했다
- 프로그래머에게 보상이란
더 프로그래밍 할 수 있는것이 되어야 하고, 벌은 더 프로그래밍 할 수 없는것이 되어야 한다
- 따라서 버그 리포팅 시스템이 어느정도 해결책이 될 수 있을 것
- 찜찜함 것부터 실제 확인한 버그까지 모든것이 버그 리포팅 시스템에 추가 되어야 한다
- 그리고 장애가 일어난 경우 “버그 리포팅 시스템의 어떠한 것으로 인해서” 일어난 것인지 명시적으로 피드백한다
- 이경우 피드백의 시간은 길지만, 명확하게 피드백이 될 것
- 반대로 새로운 기능을 추가한 경우 “버그 리포팅 시스템의 어떠한 것을 수정했기 때문에"가능 했는지 명시적으로 피드백한다.
- 버그 리포팅 시스템을 관리하는 사람이 있어야 하고, 최소한의 강제적인 상벌은 필요할 것
- 문화가 정착할 때 까지는 “버그 리포팅에 없는 버그로 인해서 장애가 일어난 경우"에 회의를 해서 왜 없었는지, 왜 못찾았는지 등의 피드백을 주어야 한다
- 또 버그 리포팅 시스템을 관리하는 사람을 두어서, 이 시스템을 사용하는데 있어서 부담을 줄여야 할 것
- 어떤 조직이던 이런거 추가적으로 관리하면서 희열을 느끼는 나같은 변태들이 있을것이다.
- 물론 이들의 소모 또한 막아야 하는데, 이 또한 시스템적 영역과 재미이론의 관점에서 해결되어야 할 것이다.
블로그,
아이디어,
안티프래질,
개발,
Published