37P by neo 4일전 | ★ favorite | 댓글 9개
  • 엔지니어링 팀은 종종 "더 많은 기능을 더 빠르게 출시"해야 한다는 압박을 받음
  • 하지만 너무 많은 작업을 동시에 진행하면 오히려 생산성이 떨어짐
  • "더 많이 출시하는 비결은 오히려 덜 하는 것" - Less is More

핵심 원칙

  • 모든 작업을 가시화
  • 작업을 작은 단위로 정의
  • 진행 중인 작업을 제한
  • 용량에 맞게 자원을 할당
  • 보너스: 혹시 모를 것을 위해 여유 공간을 확보

# 모든 작업을 가시화함

  • 작업을 가시화하면 현실을 직시하게 됨
  • 모든 작업이 한눈에 보이면 다음과 같은 장점이 있음
    • 우선순위를 명확히 설정 가능
    • 불필요한 작업을 중단하거나 일시 중지 가능
    • 팀이 시작한 작업을 완료하도록 집중 가능
  • 목표는 모든 작업을 영원히 추적하는 것이 아님 → 현실을 명확히 파악하고 더 나은 의사 결정을 내리기 위함

# 작업을 작은 단위로 정의함

  • 작업이 너무 크면 팀의 에너지가 소진되고 진행 상황이 명확하지 않음
  • 작업 단위를 1~2주 정도로 제한
    • 개발자는 단기적 성과를 통해 동기 유지
    • 빠르게 피드백 받고 수정 가능
  • 작은 작업 단위의 장점
    • 코드 리뷰가 더 쉬워짐
    • 자연스러운 지식 공유
    • 팀원 간의 협력이 강화됨
    • 배포 위험 감소
  • 작업 단위를 줄이면 속도가 빨라짐 → 복잡한 기능에 압도되지 않고 모멘텀 유지 가능

# 진행 중인 작업을 제한함

  • 여러 기능을 동시에 처리하면 오히려 생산성이 저하됨
  • 맥락 전환 비용이 발생 → 새로운 작업에 적응하는 데 최대 23분 소요됨
  • 진행 중인 작업이 많아질수록 다음과 같은 문제가 발생
    • 품질 저하
    • 버그 증가
    • 팀의 사기 저하
  • 팀 수준의 과부하 신호
    • 개발자당 4개 이상의 작업 수행
    • 예상보다 완료 시간이 길어짐
    • 완료된 기능보다 진행 중인 기능이 많음
  • 개인 수준의 과부하 신호
    • 집중력 저하
    • 코드 리뷰 응답 시간 증가
    • 상태 회의에서 우선순위 설명 어려움

# 용량에 맞게 자원을 할당함

  • "한 명의 개발자가 하나의 기능을 맡는다"는 접근 방식은 비효율적임
  • 가장 중요한 작업에 팀의 리소스를 집중
    • 협업 강화 → 문제 해결 속도 향상
    • 코드 품질 향상 → 실시간 피어 리뷰 활성화
    • 작업 완료 속도가 빨라짐
  • 개발자들이 협업을 통해 더 깊은 이해 가능
  • 팀 단위 성과를 장려해야 함 → 개인 성과보다는 팀 성과에 중점

# 여유 공간을 확보함

  • 100% 용량으로 운영하면 오히려 성과가 저하됨
  • 예상치 못한 작업은 불가피함 → 언제 발생할지 모를 뿐임
  • 여유 공간이 없으면 발생하는 문제
    • 팀이 반응적으로 일하게 됨
    • 품질 저하
    • 혁신 감소
    • 기술 부채 증가
  • 여유 공간이 있으면 다음과 같은 장점이 있음
    • 예상치 못한 문제에도 유연하게 대응 가능
    • 창의적인 문제 해결 가능
    • 높은 품질 유지
    • 지속 가능한 작업 속도 유지
  • 적정 여유 공간은 약 20% → 팀 특성에 따라 조정 가능

핵심 전략 요약

  • 작업을 가시화 → 현실을 직시할수 있게
  • 작업을 작은 단위로 정의 → 모멘텀을 유지
  • 진행 중인 작업 제한 → 집중력을 높임
  • 용량에 맞게 자원 할당 → 우선순위에 맞춰 집중
  • 여유 공간 확보 → 유연성 확보

결론

  • 더 많은 작업을 하기 위해서는 덜 하는 전략이 필요함
  • 팀의 성과는 얼마나 많은 기능을 동시에 처리했는지가 아니라, 얼마나 효과적으로 고객에게 가치를 제공했는지로 측정됨
  • 리더의 역할은 팀에 더 많은 작업을 추가하는 것이 아니라, 불필요한 작업을 덜어내는 것

이렇게 작은 태스크로 나누게 되면 큰 그림을 가지고 있는 리더가 큰 권한을 가지게 됩니다. 같이 있는 엔지니어들은 오히려 동기가 박탈되고 "우리는 대체 어딜 향해 가는거지" 가 됩니다. 스프린트 기반 애자일의 대표적인 단점.
너무 리더의 관점으로만 쓰여진 것 같네요, 제목 그대로.

엔지니어의 모멘텀은 리더가 깃발을 어느 방향으로 들고 있는지도 크게 영향을 받습니다. 고객에게 주고싶은 가치가 무엇인지, 스프린트마다의 output 과 딜리버리 outcome이 무엇인지 제시 할 수 있는 방법에 대해서도 조금 더 고민이 필요해보입니다. 물론 어려운 소프트스킬이라 제대로 하는 리더도 보기 힘들고 글도 잘 없긴 하지만.

큰 그림을 공유하고, 모두가 이해한 상태에서 업무를 작은 태스크로 쪼개는건 아닐까요??

1-2 주로 나누게 되면 자연스럽게 하나의 기능에 대한 그림은 제한적인 사람만 알게 될 것 같습니다. 프로세스와 쓰레드의 차이처럼요. 관심을 제한하면서 생산성을 높이는거니까요.

그림을 공유하더라도 그 그림에 대해 의문을 가질거라는 전제이긴 한데, 매 스프린트 플래닝마다 조금씩 달라지는 방향에 따라 큰 그림을 어떻게 추적해가고 있는지 맞추지 못한다는 전제도 제가 자연스럽게 한 것 같습니다.

저는 이 글에서 제시하는 바에 전적으로 동의하면서도, 말씀해주신 문제도 동의합니다,
실제로 제가 고민하고 있는 포인트이기도 합니다.
스쿼드마다 다르긴 했지만 스프린트 플래닝에 팀원들을 적극적으로 참여시키면 말씀해주신 문제가 발생하지는 않았습니다. 프로젝트의 맥락을 공유하고 매 스프린트마다 변화하는 상황을 공유하면서 바뀌는 작업들을 충분히 인지할 수 있게 노력하면서도 작업은 굉장히 세분화해서 나눠보자고 요구했습니다.
말씀하신대로 관리하는 측면에서 진행 상황, 작업 속도 측정, 예상치 못한 상황에 대한 대처, 작업 내용이 의도대로 안되었을 때의 기회 비용을 생각하면 잘게 나누어야 결국 잘 진행되긴 하더라구요.

이 댓글에 격하게 공감되네요. 기술적인 부분에 대한 마이크로매니징이 발생할 위험이 있(었)습니다. 참 쉽지 않아요.

비슷한 글이 반복되지만, 인간의 욕심은 끝이 없고 같은 실수를 반복하죠

컴퓨터의 CPU로드 100%는 정상이 아니지만,
인간의 업무로드 100%는 더 열심히 해야 한다..는 결론이 나오니까요

긱뉴스에서 여러번 언급 되었던 책 <피닉스 프로젝트>에서도 비슷한 이야기가 나옵니다. 100% 용량에 가까울수록 응답시간이 기하급수적으로 길어진다고.

80%의 업무 그리고 20% 여유 공간을 두고자 노력하지만, 어떤 기준으로 할지.. 매번 고민이 되긴하네요. 단순 시간으로 해야하나 싶기도하구요

저는 그래서 금요일 오후는 개인개발시간으로 아예 빼놓고 있어요!