(번역글)
지난 2년간 두어 개의 컨퍼런스에서 ‘기능 공장’ 이라는 단어를 사용해 왔다. 이 단어를 처음 사용하게 되었던 것은 소프트웨어 개발자인 친구가 자신이 “그냥 공장에 앉아서, 하찮은 기능들을 뱉어내고, 라인에 올려보낸다”고 불평해서였다. 당신이 ‘기능 공장’에서 일하고 있는지는 어떻게 알 수 있을까?
1. 측정 도구 없음. 팀에서 자신들이 한 일의 영향도를 측정하지 않는다. 혹은, 측정을 하더라도, 단순히 제품 관리 팀 안에서 할 뿐이고 일부 사람들에게만 선택적으로 공유될 뿐이다. 당신이 한 일이 실제로 잘 돌아가고 있는 지 알 도리가 없다.
2. 잦은 팀과 프로젝트의 변경(팀 테트리스라고도 부른다). 팀에서 소명이나 계획을 따르게 되지 않고, 기능이나 프로젝트를 할당받게 된다. 만성적인 멀티태스팅과 과부하가 일어난다.
3. 성공 전시. 효과에 대한 논의 없이 “성과”에 대해 이루어진다. 당신이 회사에 대해 떠벌릴 수 있는 것은 회사에서 자축하고 있는 것에 대한 것이다.
4. 드문 (알려진) 실패와 업무 파편. 어떠한 기능도 사라지지 않았다. 실제로 나타난 결과가 아닌 초기 성공 지표에 의해 기능을 만든다. 데이터와 학습은 업무에 거의 고려되지 않는다. 팀에서는 불발된 일에 대해서 사전에 고려해야 하는 것을 놓친 것을 쉽사리 인정하지 않는다.
5. 중요 지표에 대한 고려 없음. 고객과 업무 결과에 대한 논의가 별로 일어나지 않는다. 팀에서는 업무를 주요 비즈니스와 고객 만족 지표와 연결시키지 못한다. “무엇을 가장 중요하게 고려해야 하는 지”에 대해 반복해서 고민할 수 없다.
6. 회고하지 않는 PM. 제품 매니저가 프로젝트에 대해 내린 결정이 잘 된 것인지에 대해 정기적으로 고려하지 않고 목표치와 현재 수치를 비교하지도 않는다. 개발자는 “통과 시험(passing test)”을 거치지만, 제품 매니저는 아니다. 제품 매니저는 변화량을 보고 주요 상태 지표를 그들의 성과 결과로 내놓는다.
7. 우선순위 중독. 엄격한 우선순위(무엇이 효과가 있는지를 결정함)와 검증(이런 일이라면 어떨까 . 정확히는, 해야 하는 지를 결정함) 간에는 불일치가 존재한다. 엄격한 우선순위는 사람들이 “적극적으로 일할 수 있도록” 내부적 순위를 조절하는 식으로 설계된다. 많은 자원을 투입해서 어떤 일을 할 지를 결정한다. 이 와중에 데이터 기반의 즉석 수정 및 조정 할 수 있는 여유는 거의 없다. 로드맵은 집중해야 할 부분이나 결과가 아닌 기능의 목록으로 나타난다.
8. 수정 없음. 일이 한 번 “이루어지면”, 양적, 질적 데이터 기반으로 이를 돌아볼 시간 따위 없이 팀은 곧바로 다음 “프로젝트”에 착수한다.
9. 손을 떼는 문화. 앞선 프로세스가 “손을 떼는 시점”에 위치하면 아이템은 “개발 준비” 상태가 된다. 팀은 연구, 문제 탐색, 실험 및 검증에 직접적으로 관여하지 않는다. 일단 일이 넘어가면, 팀은 운영, 고객 응대, 판매와 거의 의사소통을 하지 않는다.
10. 대형 배치. 실험에 대한 의무없이, 기능이 점진적으로 배포되는 대신 하나의 큰 배치로 서비스에 실린다. 당신은 물론 계속 스프린트 방식(그럼요. 우린 “애자일”하니까요)으로 일하고 있겠지만, 매 스프린트가 끝나도 고객에게는 어떤 새로운 것도 주지 못할 것이다.
11. 선행 수익 몰이. 기능을 추가하는 이유는 새로운 거래를 따내기 위해서다. 근본적으로 잘못된 것은 아니지만, 경제적인 정당화는 종종 (기껏해야) 별 것 아닌 것으로 나타나고, 제품의 복잡도만 비선형적으로 증가하게 되는 결과를 낳을 뿐이다(기능을 만든 것은 3개월이지만, 거기에 쏟아야 하는 시간은 몇 배가 될 것이다). 게다가, 이런 방식은 기능이 가치 측정의 단위라는 생각만 고착화할 뿐이다. 제품 결정에 있어서 건전한 경제적 근간은 결여된다.
12. 반짝이는 것들. 리팩토링 작업이나 (기술, 업무, 의사 결정 등의) 부채를 줄이는 것에 대한 낮은 가시성. 전체적인 가치 제공 능력에 대한 낮은 가시성. 앞에서 말한 것처럼, 기본적인 성공의 척도는 새로운 기능이다. 반짝이는 새 기능들을 보지만 전체 제품의 상태는 거의 고려하지 않는다. 새로운 기능의 효과로 인한 기존 제품의 사용성(과 유지 보수 및 확장성)에 대해서도 거의 고려하지 않는다.
원문: https://hackernoon.com/12-signs-youre-working-in-a-feature-factory-44a5b938d6a2#.ftcq7ow3b
(원문에 가면 이와 관련되어 기존에 쓴 다른 글들도 볼 수 있다)
글은 30분만에 뚝딱 번역한 초역본인데다가 약간의 의역이 있을 수 있습니다. 틀린 부분은 접수 받습니다. 흥미로운 이야기라 후루룩 번역해 보았다. 번역을 허가해 주신 원작자 분께 감사드린다.
(그리고 저자는 3여년 후 이에 대한 회고 글을 썼다. 역시 정리해 보았다. )