사용자 검증을 건너뛴 요구사항이 개발자에게 오는 이유
2020년 8월에 써둔 글이 있길래 지금도 유효한가 다시 읽어봤더니 여전히 유효하길래 이제야 발행해 본다.
10년간 잘 다니던 회사를 때려치우고 처음으로 이직이란 걸 했는데, 새로운 회사에서 만 1년을 보내는 과정에서 정신적으로 고통을 심하게 받았더랬다. 다행히도 만 1년이 되기 전에 벗어날 구멍이 생겨(이직) 마음이 좀 편안해진 상태에서 썼던 글.
아래의 상황은 비단 SI에서만 벌어지는 일은 아니다. 많은 대기업에서 흔히 벌어지는 일이고, 대기업이 아니어도 벌어지는 일이다.
수차례 회의를 하고 회의록과 새로운 프로젝트에 대한 기획안을 보다가 기획을 한다는 사람들이 어떤 맥락에서 요구사항을 예측해서 넣게 되는지에 관한 포인트를 발견했다. 아, 이건 내가 있는 대기업의 이야기다.
1. 기존 제품 A를 사용하던 고객의 추가 요청이 있다. 그걸 만들어줌.
2. 살펴보니 A를 사용하는 다른 고객들에게서도 비슷한 요구가 있다. 일괄로 반영함
3. 일괄 반영했더니 못쓰는 고객들이 많다. 각자에 맞게 고쳐줌.
4. 신규 제품 B를 기획한다.
5. 고객과 요구사항을 달라고 했더니 A에서 누적된 것을 그대로 전달한다. (개발자는 자신이 만들기 때문에 같은지 다른지 알지)
6. 왜 A 것을 주냐, 고객이 누구냐 물었더니 얼버무리면서 시키는 대로 하지 왜 자꾸 물어보냐고 화낸다.
---
4번부터 문제가 시작되는데,
사실 제품 B는 ‘대기업’에서 ‘기존 조직이 살아내기 위해(임원의 수명 연장)’ 새로운 이름을 붙여 A와 속성은 같고 껍데기와 이름만 다르다. 한데 그렇다고 말할 수 없으니 그럴듯하게 고객이 다르다는 이야기를 끼워 넣는다.
하지만 실제로 고객을 분석한 적은 없다.
1-3을 거치는 동안 특정 고객에게서 개인적으로 요청 왔던 걸 'B에 대한 고객의 요구사항이다'라고 개발팀에 전달한다.
즉, 1번과 같은 요구사항은 그 제품과 그 고객에게서만 유효한 것인데 모든 제품과 모든 사용자에게 유효하다고 제조자 입장에서 추측하고 이를 신규 제품 기획 시점에 검증 없이 반영해 버리는 수순.
이런 사고가 가능한 이유는, A에서 정의했던 고객 카테고리에서 아주 미세하게 벗어나는 부분이 있어서 다른 고객이라고 여기기 때문이다. 물론 그것마저도 제대로 분석한 적이 없기 때문에 느낌적인 느낌일 뿐이지만.
헌데 이러한 욕구는 누구에게든 매 순간 일어나는 것 같다. 기존에 내가 알고 있는 게 있는데 그걸 없는 셈 치고 다시 한번 확인하는 그 과정을 번거롭다고 생각한다거나, 이미 검증했다고 인지한다든가 해서 말이다.
그리고 대기업에서 이런 일이 흔한 건 아마도 회사 이름이 주는 안정감 때문일 게다. 대기업에서 이미 생긴 조직을 없애지 않는 건, 보상으로 팀장 자리를 주었던 사람에게서 그 보상을 빼앗을 수 없기 때문이다. 그래서 애초에 팀이 생길 때 주었던 미션의 수명이 다했더라도 팀은 없어지지 않는다. 대신 팀장 자리를 유지할 수명 연장의 명분을 찾기 시작한다.
이러한 일들은 돈 한 푼 없이 바닥부터 하나씩 쌓아 나가야 할 일이 아니라서 벌어진다. 이미 먹고 살만큼의 돈을 포함한 모든 게 갖춰져 있고, 갖춰진 환경을 이용하며 그 안에 있는 고만고만한 다른 이들보다 내가 조금 더 잘나 보일 방법을 궁리하는 것.
대기업에서 시작한 커리어지만 나의 방향이 늘 회사 밖을 향하고 있는 건, 이 회사가 내 인생의 끝이 아니므로 언제든 자립할 수 있도록 각자의 힘/역량을 길러야 한다는 생각에서였던 것 같다. 그리고 같은 이유로 굳이 대기업으로만 이직을 해서 애자일 코치를 하며 내 동료들이 부품이 되지 않길 고집하고 있는 것 같기도 하고.
#뱅이데일리로그 #뱅이회사일기
