🫒 'SW 개발 '속도'집착이 모든 것을 망치고 있다' 등

🫒구독자님, CJOY 'TPM' 입니다.

'OLIVE LAB'는 오늘도 성장을 갈망하는 일잘러들을 위한 뉴스레터 입니다.
올리브영의 조직 성과와 조직 건강의 지속 성장을 연구합니다.

한 주간 인상깊게 읽은 비즈니스, 리더십, 매니지먼트, 조직문화 관련 아티클을
요약 정리해서 정성껏 담아 보내드립니다:D (마음에 드는 글에 '👍좋아요'도 눌러주세요)

✍️응원, 소감, 궁금하신 내용 그리고 함께 나누고 싶은 내용은 댓글로 남겨주세요.

SW 개발 '속도'집착이 모든 것을 망치고 있다. (Woody's Pick)

midjourney 생성 이미지, "lash running so fast that it causes the collapse of the multiverse, destroying the world."

어느샌가 우라는 빠르게 기능을 만들어내는 것에만 집중하고 있지 않았을까요? 우리가 만든 제품이 어떤 문제를 해결하기 위함이었고 어떤 지표/데이터를 개선하기 위함이었는지 고민해보면 좋을 것 같습니다.
만약 그 어떤 것을 위한 것도 아니었다면 우리는 서비스 품질에 더 신경써야함을 말하는 글이 있어 공유하게 되었습니다 :)

지속적 배포가 지배하는 세계에서 빈번한 개발 버전 릴리즈는 일상이 됐고, 대부분 기업은 거의 매일 제품을 업데이트 한다.
문제는 속도가 이런 엔지니어링 팀의 성공을 측정하는 지배적인 지표로 굳어지고 있다는 사실이다. 결과적으로 사람과 프로세스, 제품 가치는 뒷전이 됐다.
더 많은 스토리 포인트를 전달하는 것은 "일을 제대로 하고 있다"는 확실한 신호라고 보는 것이다.
출시 시기는 실제로 중요하다. 출시 속도가 5% 개선되면 ROI가 13% 증가한다는 연구 결과도 있다. 그러나 필자는 속도에 대한 맹목적인 집착이 소프트웨어 솔루션의 실질적 영향을 최적화하는데 중요한 여러가지 요소를 놓치게 된다고 생각한다.
오로지 속도에만 집중할 때 우리가 묻지 않는 다음과 같은 질문을 생각해보자
- 제품 사양이 적절히 작성되었으며 팀이 제품을 제공하고자 하는 방식과 조화를 이루는가?
- 목표한 비즈니스 문제에 맞는 올바른 솔루션을 구축하고 있는가?
- 시스템이 안전하고 안정적이며 즉시 확장 가능한가?
물론 속도와 품질은 모두 중요하다. 그러나 지금 엔지니어링 팀 전반에서 나타나는 속도 지표에 대한 집착은 모든 면에서 나쁜 습관을 조장할 뿐이다.
제품 측면에 대한 잘못된 이해에서 비롯된 요구사항이 있는 티켓을 받아서 그 사실을 파악하는데 20분을 소비한다고 가정해보자. 그 시간은 기능 테스트를 작성하거나 프로젝트를 진전시키는 뭔가를 개발하는데 사용할 수도 있었던 귀중한 시간이다. 여러번 이런 문제가 반복되면 어느 순간 낭비한 시간을 메우기 위해 허겁지겁 애쓰게 되고 그 과정에서 점점 더 많은 '제품 부채'가 발생하게 된다.
마감 기한이 유일하게 중요한 지표이고 엔지니어 앞으로 나아가기 전에 티켓부터 처리해야 한다면 결승선을 향한 경주에서 개발 측면은 처음부터 불리한 상태에 처하게 된다.
결과적으로 코딩은 부실해지고 결함은 만연하고 기술 부채는 프로젝트 품질을 끌어내린다. 성급한 제품 구성으로 인해 앞으로 새로운 기능을 추가하기 더 어렵게 되고, 악순환은 더 단단히 굳어져 반복된다. 단지 '시간'만 지켰을 뿐이다.

원문 보러가기

회고가 잘 동작하지 않는 3가지 패턴 (Eddy's Pick)

"회고가 잘 이뤄지지 않는 팀을 보면 다음 세 가지 패턴을 볼 수 있습니다. (1)필요할 때만 모여 회고합니다 (2)회고 시간에 아무도 말하지 않습니다 (3)회고 후에 아무일도 일어나지 않습니다. 우리의 모습은 어떤가요? 어떻게 이 모습을 바꿔볼 수 있을까요?"

첫째, ‘필요할 때만 회고 하고 있나요?’ 이것은 아플때만 병원에 가는 것과 마찬가지 입니다. '건강함'을 위해 우리는 정기적으로 검사를 받아야 합니다. 더 우려되는 것은 ‘필요할 때만’ 진행하는 회고는 ‘뭔가 잘못됐을때 하는 것’, ‘비난을 받는 시간’으로 생각하게 할 수 있습니다.
그럼, 어떻게 해야 할까요? 먼저 정기적인 회고 진행을 위해 물리적인 시간을 할애해야 합니다. 그리고 생각의 변화도필요합니다. 다음 비유로 구성원들과 함께 이야기 나눠보는 것도 좋을거 같습니다. "회고는 집을 청소하는 것과 같습니다. 미루면 먼지가 쌓이고 벅찬 일이 되죠. 대신 정기적으로 청소하면 보다 쉬울 수 있습니다. 우리의 일도 마찬가지 입니다."
둘째, ‘회고 시간에 아무도 말하지 않나요?’ 회고는 구성원이 의미있는 참여를 하지 않으면 의미 있는 시간이 될 수 없습니다. 일부는 '아무도 말하지 않는 것'을 '모든것이 괜찮다'라는 의미로 오해하곤 하는데 큰 실수가 되곤 합니다. 구성원들이 관리자나 팀원의 부정적인 피드백을 두려워하여 참여하지 않을 가능성이 있습니다. 또한 어느 누구는 그냥 쉬러 왔거나(Vacationer라고 부릅니다), 어쩔 수 없이 참여한 사람(Prisoner라고 부르죠)도 있을 것입니다.
먼저 유용한 회고 시간이 되도록 하는 환경을 만들어야 합니다. 구성원과 서로의 생각과 회고의 취지를 나누고, 어려움을 개선하며 회고를 위한 환경을 만들어보면 좋겠습니다.
반대로, '발화량이 많은 개인이 있을 수 있습니다' 우선 그 개인에 대해 공감하며 참여에 대해 감사해야 합니다. 그런 다음 "아직 말씀하지 않은 사람들의 의견을 듣고 싶습니다", "백엔드 개발자들의 의견을 들어보았는데, 프론트엔드 개발자들의 의견 있나요?"'라는 말로 다른 사람들의 참여를 요청할 수 있습니다.
셋째, '회고 후에 아무일도 일어나지 않나요?' 회고의 목적은 '팀이 어떻게 하면 더 효과적으로 일할 수 있는지 돌아보고 그에 따라 조정하는 것입니다'. 팀이 회고 후 조정이 이뤄지지 않으면 회고에 문제가 있다는 것입니다.
회고 시간에 누군가 개선을 위한 제안을 한다면, 그것을 질문을 통해 'SMART'한 제안으로 끌어내면 좋습니다. 따라서, 더 구체적이고, 측정 가능하고, 달성 가능하고, 시간 제한이 있는 실행과 완료 가능성이 높은 '제안'을 만들 수 있습니다. 또한, 종종 만들어진 제안에 담당자를 정하는 것도 좋습니다. 팀이 함께 실행하지만, 담당자가 리딩하고 진행사항을 추적하는 권한을 부여할 수 있습니다.
회고가 의미있게 진행되지 않는다면 팀과 조직이 학습하지 않는다는 반증입니다. 세 가지 패턴을 개선하여 의미 있는 회고를 만들 수 있습니다. '정기적인 주기로 회고를 실행'합니다. '모든 사람들이 참여'하고 있는지 확인합니다. '의미 있는 작업 항목'을 정의하고 완료합니다.

원문 보러가기

🫒 'SW 개발 '속도'집착이 모든 것을 망치고 있다' 등

많은 것을 잃고 단지 '시간'만 지켰을 뿐이다.

SW 개발 '속도'집착이 모든 것을 망치고 있다. (Woody's Pick)

회고가 잘 동작하지 않는 3가지 패턴 (Eddy's Pick)

다가올 뉴스레터가 궁금하신가요?

이번 뉴스레터 어떠셨나요?

댓글

이전 뉴스레터

다음 뉴스레터