편리성과 효용성 2/2

in #kr7 years ago

  • 스팀잇에 평화를...
  • 나는 지금 무엇을 하려고 하는가?

편리성과 효용성 2/2


많은 회사들이 품질 관리에 신경을 쓴다.
소프트웨어 분야도 예외는 아니다.
품질관리 하면 무엇이 떠오를까?
전통적인 품질관리는 지표를 관리하는데서 시작한다.
지표를 관리하면 자연스레 품질이 향상된다는 것이다.

지표 관리를 위해서는 측정이 필요한데,
측정에 관해서는 아래 두가지 상반된 모순을 갖고 있다.

길브의 법칙 : 측정할 필요가 있는 것은 어떤 식으로든
측정해 보는 것이 아예 안하는 것보다 훨씬 낫다. (피플웨어)

측정의 역기능 : 누군가 지식노동자의 효율을 측정하려 들면
모든 직서가 급격히 붕괴되어 버린다. (조엘온소프트웨어)

어느 이상적인 측정 시스템 이야기

관리자는 측정시스템을 구현하기를 좋아한다. 그것도 숫자로 말이다(KPI).
"작년에는 2.5였는데 올해는 5.0이야 두 배나 향상되었어."
관리자가 기쁨을 느끼는 순간이다.

직원들은 관리자를 즐겁게 하기 위해서 측정 대상을 적절한 난이도를 갖는 것으로
그리고 회사에 실질적으로 도움이 되는 것으로 선정했다.
직원들은 측정을 비교적 쉽게 해서 좋고 관리자는 좋은 결과를 얻어서 좋고,
직원과 관리자 모두 행복한 시스템이다.
더군다나 회사에 실질적인 도움이 되어 영업 실적이 증가하였다.


이러한 이상적인 시스템은 현실에서는 찾아 보기 힘들다.
대개 직원들은 관리자를 즐겁게 하기 위해서
측정대상을 개선하기 쉬운 것으로 선택하며, 지표 개선에 집중한다.
회사에 실질적으로 도움이 되는 지표라는 것은 대상을
선정하기도 어렵거니와 측정 방법 또한 쉽지가 않다.
대개 책에서 찾아 볼 수 있는 이러한 지표는
성공한 회사를 대상으로 사후 측정된다.
성공한 회사를 보니 이런 지표를 가지고 있더라.
책이 출간되고 몇 년이 흐르면 그 회사는 쇠퇴하는 회사가 되어있기도 하다.

쉽게 할 것인가? 효율적으로 할 것인가?

앞서 이야기한 우리의 교통경찰들은
“왜 단속을 하는 지?”, “무엇을 단속 하는지?” 알고 있을까?

관리자 개발자 사이의 측정의
“편리성”과 “효용성”을 조화시키는 노력이 필요하다.
“왜 측정하려고 하느냐?” 생각해 본다면
답이 나올 수 있지 않을까 생각해 본다.

만일 목표라는 것이 반드시 달성되어야 하는 것이라면,
그 목표가 어떤 의미를 가지고 있을까?
그리고 목표 달성을 하지 못한 것이 실패나 패배로 인식되는 경우에
측정을 제대로 할 수 있을까?

Sort:  

회사에서 KPI(Key Performance Indicator) 정해서 숫자 채우는 게 생각나네요. ㅎㅎㅎ
많은 경우에 어느 순간부터는 애초의 목적이 무엇이었는지 잊고 있는 듯 해요.

연초에 항상 Stretching Goal 을 세우라고 하지만,
실제로 입력하는 것은 할 수 있는 것, 했던 것을 적기도 합니다.
나중에 이걸로 진짜 평가하지도 않을 거면서....
왜 남의 것을 못보게 하는 걸까요?

휴... 글 감사합니다. 이 이야기를 하시려고 앞의 글을 적으셨던 거군요? ^^
예전에 시스코에있을때 매니져가 각종 매트릭을 측정하자고해서 별별걸 다 만들어서 아침 스크럼미팅때마다 이야기나누곤 했었는데.. 뭣때문에 저러는지 참 답답했던 기억이 납니다. 아마도 윗선에서 쪼아서 그랬겠지만.. 애자일도 잘 자리잡고 있는 팀이었고.. 프로젝트 관리가 안된다던지 딜레이가된다던지 한적이 없었는데도 그러니까 다들 피곤해 했었습니다. 저는 심지어 매일매일 technical debt 의 갯수와 트렌드를 문서로 업데이트 하기를 요구받았었지요. 알면서도 그런걸 시키는 매니저 입장도 이해는 갑니다만.. ㅎㅎ

한국에서 매니저들은 그것이 자기의 업무라고 생각하는 것 같습니다.

스크럼이 잘 되고 있다면,
메트릭 측정을 하는 팀을 따로 만들면 될 일인데...
개발팀 스크럼 미팅에 이야기를 꺼내면 안된다고 생각합니다.

진짜 스크럼이 잘 되고 있었던 것이었을까요?
항상 잘 되고 있다고 믿는 것에 구멍이 생기기 마련입니다.
어느 누구도 나는 문제 있다고 심각하게 믿지 않기 때문이지요.

Technical debt 갯수는 어떻게 측정하는지 궁금해지네요.
어떤 회사는 COPQ 를 측정하기도 합니다.

저는 개인적으로 스크럼에 회의적인 사람이라.. 어떻게해도 잘되기 어렵다는 생각입니다. 기대치 자체가 낮습니다. 프로젝트 매니져와 회사를 위한것이 개발자를 위한 방식이 아니라서요. 개인적으론 칸반이 훨씬 낫다고 생각합니다. 이번에 드디어 7년만에 스크럼을 탈출하게 되어서 어찌나 신나는지.. ㅎㅎ

technical debt 매트릭은 COPQ랑 거의 같은 개념이었습니다. 개발자귀에 듣기좋은 용어일 뿐이지요.. ^^ 제가 매트릭 만들땐 일단 technical debt 목록을 만들기위해 팀원 한명한명 만나서 미팅을 했습니다. 항목하고, 우선순위, 개선하려면 드는 시간 등을 수집해서 현재 우리팀이 가지고있는 technical debt를 하나하나 user story로 만들었습니다. 초기 매트릭은, 갯수, 해결을위한 예상시간 이고.. 일단 초기 매트릭을 만든 후에는 각자가 시간상의 이유든 커스토머의 이상한 요구사항때문이든 technical debt를 지고있다고 느낄때 스스로 추가하도록 했습니다. A방식으로 할것을 B방식으로 했고 후에 A방식으로 고치려면 x일이 소요되고, 시간이지나면 더 고치기어려워지는지에 대하여 상중하로 매기게 하였습니다. 솔직히 안해도될일을 한것인데.. 나름 호평도 있었습니다. 방송사들의 요구사항이 급작스럽고 복잡하기에 항상 "해야하는방식"을 포기해야하는경우가 많았던 팀이었기 때문에.. 그것들을 목록으로 적어두고 유저스토리로 만들어놓으니, 스크럼미팅 때에 그부분이 언급됨으로써 개발자들에게 힘이 더 많이 실리기도 했고...

스크럼을 하는 이유가 꼭 잘 되기 위해서는 아니고, 문제가 무엇인지 드러내기 위함이지요.
스크럼마스터 교육을 받았을 때, 이건 오히려 심리학에 가깝다는 생각이 들더라고요.

이쪽 분야 사람들 말을 참 이쁘게 잘 만드는 것 같습니다.
"기술적 채무" 뭔가 돈과 연관되어 보이지 않나요?
COPQ 하면 별 관심 없던 경영자들도 채무 하면 관심을 갖기도 합니다.

암묵지의 지식을 드러내 보이는 것은 중요한 일이기는 한데,
인사이트 없이 하는 것은 차라리 머신러닝에 맡기는 게 나을 것 같네요.

ㅎㅎ 공감합니다.
저도 하루짜리 스크럼마스터 교육을 받았는데 개발자는 저랑 다른한사람 둘밖에 없고 전부다 매니져더군요. 무슨 게임하고 소꿉장난 같은거하다가 왔습니다. 풍선불고 카드집만들고.. 매니저들은 우리의 복잡하고 섬세한 일을 저렇게 간단하게 보는구나 하고 황당했던 기억이 납니다. ㅎㅎ
개발자를 최대한 쉽게 대체가능한 존재로 만들기위해 참 많이들 노력하는구나 이런 생각이 많이 들더군요. 반쯤은 성공한것 같기는 합니다.

잘 보고 갑니다

Coin Marketplace

STEEM 0.19
TRX 0.15
JST 0.029
BTC 63968.82
ETH 2633.99
USDT 1.00
SBD 2.84