사내 버그신고 및 제안

사내에 직원들이 버그를 신고하는 제도가 있고 매달 기념품을 준다. 물론 자기 서비스는 자기가 신고해도 집계되지 않는다고 한다.

이번달까지 3달동안 받은 기념품이다.

기념품

2기가 USB 메모리 2개와 인형 1개이다.

2기가 메모리 8개 모아서 아이팟터치 16기로 바꿔달라고 하려고 한다니깐 안해준단다. 쩝.

버그나 제안을 하는 것 귀찮은 일이다. 특정 기능이나 서비스는 다른 회사것이 마음에 들기도 해서 다른 회사 서비스를  쓰고 싶기도 하다.

그러나 내가 버그를 신고나 제안을 하는 것은 자사의 제품을 사용하지 않는 직원 이 되고 싶지 않기도 하고, 내 일과 관련해서는 사용자연구가 못하는 것을 하게 하기 위함이기도 하다.

사용자 연구팀이 매일 사용성 테스트를 쉬지 않고 해도 사용자가 긴 시간 경험하면서 사용하는 문제를 다 찾아낼 수가 없다. 게다가 버그와 같은 사용자 경험을 나쁘게 하는 것은 무슨 행사처럼 하는 연구 같은 것으로는 빨리 찾아 낼  수가 없다. 깨진 유리창 법칙이라고 있다고한다. 사람들이 금이간 유리창을 보기 전에 먼저 고쳐놓아야 한다.

‘사용자 연구자는 사용자의 대변인다’ 라는 미션을 제대로 이해하는 사람이 얼마나 될까? 평소에 사용하면서 버그나 불편한 것을 찾는 것은 무슨 무슨 연구랍시고 보고서를 써 대는 것 보다 훨씬 더 중요한 것을 발견하고 아이디어를 낼 수 있다.

사용자 연구 한다고 새로운 아이디어나 혁신이 툭툭 나오는 것은 아니다

고객의 안경을 쓰고 고객의 니즈를 이해를 통해서도 개선이나 향상, 혁신이 나온다.  사용자 연구는 그런 장을 만드는 일을 하지만, 여전히 실제 사용자의 문제를 인식하고 해결하는데는 한계가 있다.

출시한 제품중에서 사용자 연구나 시장조사안해서 꽝되었다는 통계자료들이 있다. 그러면서 리서치를 해야 한다고들 한다. 그럼, 우리가 흔히 아는 제품이나 서비스 중에서 무슨 조사나 사용자 연구 해서 성공한 것은 얼마나 될까?

사용자들이 고객센타에 불편함을 신고하거나 제안을 하는 것은 사용자 연구를 해서 얻는 것에 비해 양적이나 질적으로 보면 사용자 연구가 훨씬 많다.  당연하다. 사용자는 정말 아쉽지 않으면 제안을 하지 않는데 반해, 사용자 연구는 고객을  쫓아 다니면서 알아내려고 하니깐 말이다. 그러나 매주, 매달 사용자 연구를 하고 있지 않으면 사용자 연구는 아무것도 안하는 것이다.

사내 직원들이 서비스를 사용하면서 불편한 것을 신고 하고, 버그를 신고하고, 서비스에 대한 제안을 하는 것들을 쉽게 할 수 있게 하고, 많은 보상을 해야 한다고 생각한다. 그런다고 맨날 신고하는 직원들만 신고하는 것은 별로 바람직하지 않다. 전 직원이 그래야 한다. 그런게 조직문화일 것이다.

나처럼 실력 없는 사용자 연구자는 그 성과를 보완하기 위해서는 사내 직원들이 사용하면서 느끼는 아이디어를 수집하는 것도 한가지 방법일 것 같다.

Related Post




  • 비슷한 생각을 한 적이 있습니다.

    분야는 다름니다만 저희 팀이 S/W 인력만 100명이 넘는 지라 여러 작은 팀으로 나뉘어져 있고, 그 덕(?)에 부서간 알력이나 협조가 안되는 경우가 무척 많습니다.

    그리고 문제가 생겨 디버깅을 하다 보면 남의 파트의 로그나 디버깅 기능을 이용하는 경우가 많은데 무척이나 불편한 경우가 많습니다. 솔직히 그 담당자가 봐도 해석이 어려운 로그가 많더군요.

    그래서 부서내 게시판을 하나 만들어서 내가 아닌 남의 프로그램에 대해 아쉬운 점이 있으면 적는 건 어떨까 하는 생각을 했습니다. 그리고 주기적으로 각 부서장들이 모여서 리뷰를 해서 정말 코드 수정까지 반영할 만한 가치가 것을 뽑아서 다음 번 패치때 추가하는 겁니다.

    근데 아직 제대로 제안은 못했습니다. 제 생각에는 그럴 듯한데 말이죠.

  • 비슷한 생각을 한 적이 있습니다.

    분야는 다름니다만 저희 팀이 S/W 인력만 100명이 넘는 지라 여러 작은 팀으로 나뉘어져 있고, 그 덕(?)에 부서간 알력이나 협조가 안되는 경우가 무척 많습니다.

    그리고 문제가 생겨 디버깅을 하다 보면 남의 파트의 로그나 디버깅 기능을 이용하는 경우가 많은데 무척이나 불편한 경우가 많습니다. 솔직히 그 담당자가 봐도 해석이 어려운 로그가 많더군요.

    그래서 부서내 게시판을 하나 만들어서 내가 아닌 남의 프로그램에 대해 아쉬운 점이 있으면 적는 건 어떨까 하는 생각을 했습니다. 그리고 주기적으로 각 부서장들이 모여서 리뷰를 해서 정말 코드 수정까지 반영할 만한 가치가 것을 뽑아서 다음 번 패치때 추가하는 겁니다.

    근데 아직 제대로 제안은 못했습니다. 제 생각에는 그럴 듯한데 말이죠.

  • Pingback: 개밥 먹기(Eating one’s own dog food) at sosa0sa.com()




Scroll Up