[💸프러덕트매니저와 엔지니어가 가장 간과하기 쉬운 비용 한 가지] 🖌우리가 물건을 구매하며 흔히 “가성비”를 따지듯, 프러덕트 매니저들이 로드맵을 기획하거나 일의 우선순위를 정할 때 있어 ROI (Return on Investment)에 대한 논의는 빠질 수가 없는데요. 오늘은 실리콘 밸리의 마이크로소프트 기업용 제품군 중 하나로 기업 내 협업을 위한 소셜 네트워크를 제공하는 Yammer의 VP of Engineering 크리스 게일의 “복잡성의 비용” (complexity cost)에 관한 글을 소개하려고 합니다. 🖌그는 복잡성의 비용을 문제를 해결하기 위해 기능이나 기술을 복잡하게 하면서 발생하는 일종의 빚이라고 정의합니다. 20가지 기능을 구현하기 위해 짜여진 코드는 3-4가지 기능을 제공하는 코드보다 당연히 복잡할 것이고, 이를 향후에 유지 보수하거나 거기에 또 새로운 기능을 추가할 때 훨씬 큰 시간일 들 수 밖에 없단 것인데요. 주요 내용은 아래와 같습니다. - 프러덕트 매니저가 엔지니어에게 어떤 기능을 새로 추가하는데 걸리는 시간을 물으면 대부분 기능을 구현하기 위해 최초의 코딩 시간만 고려하여 대답하고는 하는데 이는 잘못한 것임 - 초기에 들어가는 리소스는 향후에 이 기능이 존재하는 한 계속 들어가야할 유지 보수 노력에 비하면 매우 미미함 - 따라서 기능 개발 여부를 정할 때 이러한 장기적인 관점에서 고려해야함 - 이 장기적 비용은 유지 보수에 필요한 시간만 해당되는 것이 아니라 이러한 피쳐가 왜 만들었는지 설명하고, 누군가가 훨씬 복잡한 코드를 이해하려고 들여야 하는 시간, 나중에 버그 발생 시 고치고 QA팀이 추가 테스트하게 하는 등 복합적으로 향후 업무의 복잡성을 증대시킬 수 있음 - 따라서 엔지니어와 피엠 간에는 “이 기능을 추가하는 데 얼마나 시간이 걸리나요”가 아닌 “이 기능을 추가함으로써 앞으로 얼마나 업무의 복잡성이 증대되나요”가 논의의 포인트가 되어야 함 - 이렇게 절제하는 습관은 좋은 유저 경험을 제공하는 데도 도움이 됨. 유저들 대다수는 가용한 모든 기능 중 극히 일부만을 이용하며, 복잡한 기능이 많아질 수록 인지 과부하만 초래하게 됨 - 피엠 입장에서 복잡성 비용을 줄이기 위한 가장 좋은 방법은 데이터를 활용하는 것임. 새로운 기능이 실험 상 중요 KPI에 부정적 영향은 안 끼치더라도, 복잡성 비용을 고려했을 때 유지할 만한 가치가 없는 것이라면 과감히 버려야 함 - 또한 장기적으로 모든 기능의 사용 빈도가 데이터로 기록되고 모두가 쉽게 확인가능하도록 하여, 엔지니어가 향후에 새로운 프로젝트를 진행 시 과거에 추가된 인기없는 기능이 업무 난이도를 높일 경우 이 기능을 없애는 걸 제안할 수 있는 프로세스와 문화가 필요함 🖌사실 피엠의 입장에서 많은 고민을 통해 기획한 프로젝트를 “포기”하는 것은 쉽지 않고, 이미 개발을 시작하거나 완료한 피쳐라면 공을 들였던 코드를 삭제하기 어려운 건 엔지니어 분들에게도 마찬가지일 거라고 생각해요. 하지만 보이지 않는 이러한 “복잡성의 비용”이 향후에 더 중요한 업무를 진행하는데 있어 방해가 될 수 있다는 것을 잊지 않고 더 철저한 ROI 검증을 통해 의사결정을 하려고 노력해야 할 것 같습니다.