매니저로 일하시는 분들은 업무를 시작하자마자 느낄 수 있는 것 중 하나가 피드백 루프가 이전과 다르다는 것입니다. 느립니다. 모호합니다. 회의를 진행하거나 프로세스를 변경하거나 새로운 직원을 고용하는 경우, 자신이 잘 한 일인지 아닌지 판단하기 어렵습니다. 결과가 나타날 때까지 수개월이 걸릴 수 있으며, 심지어 이후에도 어느 정도 자신의 행동이 그 결과로 이어졌는지 정확히 알기는 어려울 수 있습니다.
특히 소프트웨어 엔지니어링 분야에서 매니저로 전향한 경우, 충격일 겁니다. 엔지니어로서 우리는 명확한 피드백을 지속적으로 받았습니다. 코드 작성하기. 코드 실행하기. 현대적인 도구를 사용하지 않아도 우리는 우리의 노력 결과를 볼 수 있었습니다. 타입 체커 및 린터, 자동화된 테스팅이 등장함으로써 피드백 루프가 단축되었습니다. 결과를 확인하려면 실제로 코드를 실행할 필요조차 없었습니다. 우리가 작성한 조금씩 좋은 코드마다 수천 번이나 확인되었습니다. ✔️
좋은 소식은 매니저들 및 비매니저 리더들을 위한 피드백 루프가 느리고 모호한 것이 그리 나쁘지 않을 수 있다는 것입니다. 소프트웨어 엔지니어들이 코드의 피드백 루프를 개선하기 위해 새로운 도구 및 기술을 개발하던 동안, 리더들은 사람들과의 업무에 대해 같은 일을 하고 있었습니다. 이것이 리더십 버전의 유닛 테스팅, 즉 1:1 미팅을 구현한 이유입니다.
믿지 않으신다구요? 단위 테스트가 제공하는 혜택 목록을 살펴보도록 하죠:
문제를 더 빨리 발견하기
작고 빠른 테스트를 통해 엔지니어들은 문제를 빨리 발견할 수 있습니다. 코드베이스에 통합되기 전이나 고객에게 제공되기 전에 문제를 발견하면, 그 문제들이 더 작고 해결하기 쉬워집니다.
문제를 조기에 발견할수록 해결하기 쉽고 저렴해지는 것은 코드 문제 뿐만 아니라, 발견 시 더 쉽고 저렴하게 해결할 수 있는 사람 간의 문제들도 포함됩니다. 방치된 채로 두면 확산되거나 적개심이 생겨날 수 있습니다. “밥이 자기가 할 수 있는 일을 계속 부탁하는 건 짜증스러워” 라는 말을 들은 것과 대놓고 싸움하는 상황과 해결하는 게 완전히 다릅니다. 승진에 대해 담당자가 당신이 준비되지 않았다고 생각한다는 것을 알고 있는 것은 성과 검토 회의 전에 알 수록 더 가치 있습니다.
잘 운영되는 일대일 미팅은 양쪽이 문제를 제기할 수 있는 안전한 공간을 제공하며, 문제를 유발할 충분한 자극과 충분한 빈도를 제공하여 그 문제가 큰 문제로 발전하기 전에 조치를 취할 수 있습니다.
문제 해결을 쉽게하기
작은 문제는 큰 문제보다 자연스럽게 디버깅하기 쉽습니다. 단위 테스트도 더 나은 인터페이스를 제공하여 디버깅을 도와줍니다. 프로드를 망가뜨릴 걱정은 없습니다. 전체 코드베이스를 빌드할 필요도 없습니다. 버그를 재현하기 위해 모든 단계를 거쳐야 할 필요도 없습니다. 버그에 대한 가설을 빠르게 개발하고 (부족)증명하고 필요할 때 반복함으로써 최소한의 마찰로 진행할 수 있습니다.
일대일 미팅에도 똑같이 적용됩니다. 문제를 식별했을 때 (예: 밥이 짜증나, 승진에 대해 의견이 일치하지 않음), 두 사람은 더 쉽게 이에 대해 이야기할 수 있습니다. "왜 밥이 짜증나요?" "왜 승진에 대해 준비가 되지 않다고 생각하시나요?" "이를 해결하기 위해 우리가 무엇을 할 수 있을까요?"
한 명의 대상을 대상으로 메시지를 맞춤 설정하는 것이 더 쉬워집니다. 문제에 대한 이 사람의 관점과 그에 대한 감정에 초점을 맞추어 전체 그룹의 다양한 해석을 관리하려고 하는 대신 빠른 솔루션을 찾을 수 있는 상호 대화형 일대일 미팅이 중요합니다.
안전하게 변경 사항 적용하기
잘 작성된 테스트 스위트는 코드베이스에 적용된 변경 사항이 안전한지를 확신할 수 있도록 합니다. 문제를 발견하는 것 이상으로 유닛 테스트는 문제가 없음을 확인할 수 있지만(보장하지는 않음), 엔지니어들이 코드를 리팩터링하거나 라이브러리를 업데이트하거나 익숙하지 않은 코드에서 작업할 때 테스트 스위트가 문제가 있는지 알려줄 수 있다는 것을 의미합니다.
리더의 일은 변경을 촉진하는 것의 무시할 수 없는 부분입니다. 문화 전환, 프로세스 재작성, 인사, 직원 조직 변경 등. 일대일 미팅을 통해 주변 사람들과의 관계를 구축하여 보다 자신 있게 변경사항을 수용할 수 있게 됩니다. 주변 사람들이 어떤 종류의 변경을 수용할 수 있을지, 무서워할지를 배웠습니다. (희망적으로) 그들은 변경 사유가 충분하지 않으면 변경 사항을 도입하지 않는다는 것을 배웠습니다. 미팅을 통해 변경 사항을 내보낼 전에도 후에도 모든 사람들이 변경 사항을 의문시 하고 설명하고 조정할 수 있는 장소가 제공됩니다. 간단한 "무엇을 생각하십니까..."라는 질문으로 변경 사항을 배포하기 전에 직접 테스트할 수 있습니다.
인터페이스 향상하기
라이브러리나 API를 작성할 때, 해당 코드의 첫 번째 사용자는 대개 테스트입니다. 설계는 문서상으로 잘 보일 수 있지만, 구현은 여전히 사용하기 어렵거나 실행이 느릴 수 있거나 디버깅하기 어려울 수 있습니다. 코드가 테스트하기 어렵다면, 사용하기도 어려울 것입니다.
대부분의 일대일 미팅은 문제를 찾거나 디버깅하는 데 관한 것이 아닙니다. 변경 사항을 도입하는 것도 아닙니다. 그것들은 관계를 구축하고 신뢰를 유발하는 데 관한 것입니다. 각자가 상대방이 가치를 두는 것과 무서워하는 것에 대해 배우며, 상대방이 에너지를 얻는 것과 소모되는 것에 대해 알게 되는 것입니다. 서로 더 잘 협업하는 방법을 배우며, 리스크가 적은 환경에서 피드백 주고받는 연습을 합니다. 그러면 까다로운 대화 중에 그것에 대해 고민하지 않아도 되겠죠.
물론, 유닛 테스트가 이러한 혜택을 제공하지 않는 많은 코드베이스가 있습니다. 테스트가 불안정하고 신뢰할 수 없거나 크고 느린 경우가 있습니다. 또는 코드 커버리지 봇을 달래기 위한 것이거나, 행동을 확인하기 위해 작성된 것이 아닌 구현을 검증하기 위한 것인 경우도 있습니다. 이것만으로도 어떤 사람에게는 유닛 테스트가 시간 낭비임을 증명하는 충분한 증거가 될 수 있습니다.
비슷하게, 많은 1:1 미팅이 큰 이득을 주지 않는 경우가 많습니다. 상태 업데이트 미팅. 한 쪽이 참여하지 않거나 듣지 않는 1:0 미팅. 탄탄한 안건 미팅으로 탐색할 여지가 없는 경우. 너무 짧거나 너무 자주 열리는 미팅. “그냥 해야 되니까”라는 이유로 열리는 무의미한 미팅. 이것들은 1:1 미팅이 시간 낭비라고 생각하는 이에게 충분한 증거가 됩니다.
단위 테스트와 1:1 미팅은 잘하기 위해 기술이 필요합니다. 그렇지 않다면... 그외에 더 많은 능력 있는 프로그래머와 관리자들이 있었을 것입니다. 네 맞아요, 처음에는 너무 많은 노력으로 느껴질 수 있습니다.
하지만 제대로 활용하면, 문제가 발생했을 때 감지할 수 있고 수정할 수 있으며 자신 있게 변경을 가할 수 있고 제품 출시 전 시도해볼 수 있게 도와줍니다. 이 점은 엔지니어로써 가치 있었습니다. 당신의 피드백 루프가 몇 주가 걸리는 리더로서는 더 가치 있게 느껴집니다. 그러니 소홀히 하지 마십시오.