리더십에서 코드 라인까지: 팀 리더를 위한 가이드

안녕하세요!

팀 리더 역할로 전환한 모든 개발자는 처음에는 팀과 함께 코딩 및 작업 해결로 돌아가려고 노력한다고 생각합니다. 나중에 우리는 더 많은 비즈니스 작업과 문제를 포괄하고 비즈니스 관련 과제, 부서 또는 클라이언트 간의 커뮤니케이션, 아키텍처를 자세히 살펴봅니다.

이 시점부터 우리는 더 이상 다른 일을 할 시간이나 욕구가 없습니다. 일반적인 팀 리더의 일정은 다음과 유사합니다.

개발로 돌아가서 코딩을 다시 시작하려면 어떻게 해야 합니까? 어디서부터 시작해야 합니까?

자신이 얼마나 바쁜지, 일반적인 근무일은 어떤지 평가하는 것도 중요합니다. 퇴근 후에 자기계발에 참여하시나요? 이것들은 모두 중요한 요소입니다.

내 경험을 바탕으로 나는 "퇴근 전후 시간도 없고, 욕망이나 기회도 없다"에서 "나는 항상 컴퓨터 앞에 있고 이것이 나의 열정이다"로 가는 길을 따라갈 것을 제안합니다.

시간을 막아라!

효과적인 출발점은 개발 전용 시간을 계획하는 것입니다. 달력에서 '코딩 시간'을 한 시간 이상 차단해 보세요. 가능하다면 매주 기술적인 작업을 처리하기 위해 반나절 또는 하루 종일 시간을 확보하는 것이 좋습니다.

그렇습니다. 회의를 여러 곳으로 옮기거나, 불필요한 회의를 없애거나, 일부 회의에 참석해야 할 필요성을 논의하는 일이 포함될 수 있습니다. 그러나 특정 그루밍 세션이 여전히 귀하에게 적합한지 재평가해 보세요.

팀과 함께 코드 검토!

주변의 특정 프로세스를 최적화하기 위한 두 번째이자 가장 중요한 측면은 프로젝트의 가치나 접근 방식을 동료에게 전달하는 것입니다. 모든 개발자가 문제 해결에 대해 동일한 접근 방식을 보는 것은 아니므로 코딩 스타일, 테스트 범위, 플랫폼이나 서비스의 기본 방법 및 메커니즘을 별도로 미리 정의하는 것이 중요합니다.

항상 코드 검토를 수행하고, 질문이 길어지는 것 같은 느낌이 들면 팀을 모아 PR(풀 요청)의 문제를 신속하게 해결하세요. 실습에서 알 수 있듯이 이 접근 방식은 문제 해결 시간을 단축하여 결과적으로 기능 출시 시간을 단축합니다.

시간이 지남에 따라 팀은 주의가 덜 필요한 개발 접근 방식을 완전히 이해하고 적용하게 됩니다. 당면한 작업과 해당 논리를 해결하는 데에만 집중하게 되며, 이를 통해 처음에는 몇 분, 장기적으로는 몇 시간의 개발 시간을 절약할 수 있습니다.

당신은 무엇을 책임지고 있나요?

가장 명백한 작업처럼 보이지 않을 수도 있지만 스스로에게 물어보세요. 당신의 책임은 무엇입니까? 뭘하길 원해? 이 모든 사항을 종이에 적고 불필요한 일을 맡았는지 확인하십시오.

아마도 당신은 습관이 되었기 때문에 다른 사람의 일을 하고 있을 수도 있습니다. 아마도 당신은 이웃 팀의 프로세스를 돕고 있으며 여전히 참여하고 있을 것입니다.

자신의 위치와 프로젝트나 회사에 기여하는 바를 명확하게 정의하세요. 대규모 팀을 이끌고 있다면 작업 및 문제 대기열을 만들 수 있는 노트를 사용하세요. 항상 검토를 수행하고, 예를 들어 DevOps 책임자인 경우 모바일 앱 개발자를 위한 작업을 실수로 처리하지 않도록 하십시오.

업무와 의존성으로 인해 과부하가 걸렸다면 잠시 멈춰 상사와 대화하고 부서에서 이런 일이 발생하는 이유를 알아내는 것이 좋습니다. 예를 들어 데이터 엔지니어를 담당하는 DevOps 팀이고 자체 리드가 있는 경우 부서가 아닌 리드에게 책임을 다시 위임하는 것이 합리적일 수 있습니다.

설정이나 유지 관리에 대한 계약이나 숨겨진 세부 정보를 공식화하고 인력을 해당 팀으로 돌려보내는 데 필요한 사양과 필요한 문서를 만듭니다.

우선순위 지정 및 위임

우선순위가 계속 바뀌기 때문에 작업을 완료하지 못할 수도 있습니다. 회사 전체가 2주간의 스프린트로 운영되지만 이 설정은 더 이상 적합하지 않으며 가치도 없습니다. 약한 우선순위로 인해 스프린트 내에서 기능이 완료되지 않습니다.

이는 서비스 지향 팀과 관련이 있습니다.

칸반(Kanban)이나 물 흐름 접근 방식을 고려해 보세요. 우리 팀은 더 나은 방향으로 프로세스를 변경하려고 시도할 권리가 있는 별도의 섬과 같습니다. 한 달 동안 새로운 접근 방식으로의 전환을 테스트하고 측정항목을 관찰하세요. 내 경험상 스크럼이 우리에게 적합하지 않다는 것을 깨닫는 데 몇 주가 걸렸고 우리는 칸반으로 전환했습니다.

이제 우선 순위가 일주일에 두 번씩 변경되어 문제를 더 신속하게 해결할 수 있게 되었기 때문에 출시 시간이 크게 단축되었습니다.

다음으로 팀을 도메인 영역으로 나누되 너무 세분화하지는 마세요.

70/30 규칙에 따라 각 팀원을 몰입시킵니다.

• 70%는 메인 스택, 프로젝트 또는 제품에 전념합니다.
• 그 외 모든 것에는 30%

팀이 5명 이상인 경우 모든 서비스와 기능을 다루므로 개인이 해당 주제 영역에 더 빠르게 접근할 수 있습니다.

이것이 무엇을 달성합니까?

개발자가 이미 충분한 이해도와 몰입도를 갖추고 있다고 판단되면 혼자서 모든 일을 하기보다 팀에 일부 작업을 위임할 수 있습니다. 전체 알고리즘과 통합을 설명할 필요가 없습니다! 그들은 이미 다 알고 있어요!

시간 관리 및 생산성

팀은 작업 시간을 어떻게 계획하고 있나요?

간단한 것부터 시작해 보겠습니다. 팀으로서 어떻게 활동합니까? 추정치를 살펴보고 작업을 평가하는 방법을 살펴보세요. 모든 것이 정상인가요? 개선의 여지가 있거나 작업량 계수를 도입할 여지가 있을까요?

작업량 계수는 지원에 대한 잠재적인 방해 요인을 고려하여 스프린트 또는 주 동안 각 팀 구성원이 어떻게 로드되는지 이해하는 데 도움이 됩니다. 예를 들어, 자체 제품을 유지 관리해야 하는 서비스 팀인 경우 다른 팀이 도움을 구하거나 개선 사항을 요청할 수 있으므로 스프린트 내 의사소통에 시간이 소요됩니다.

버그를 처리할 때도 마찬가지입니다. 프로덕션 환경의 긴급한 문제를 해결하기 위해 종종 다른 길로 갈 수 있습니다.

이제 계수로 돌아갑니다. 문제 해결을 위해 우리 각자가 5일 중 1일 이상 채팅이나 회의에 참석해야 한다는 사실을 인정한다면 계획을 세울 때 이를 고려하세요. 이렇게 하면 팀에 진정으로 도움이 되는 작업을 현실적으로 관리하여 잠재적으로 코드 작성 시간을 확보할 수 있습니다.

뽀모도로 기법을 사용해 보세요.

획기적인 것은 없습니다. 45분과 같이 정해진 시간 간격 동안 작업에 집중할 수 있는 휴대폰 앱을 사용하세요. 특별한 건 없는 것 같아요.

추적기를 활용하세요.

근무 시간 8시간을 무엇에 소비했는지 조사해 보세요. 한 주 또는 한 달 동안의 활동을 매 시간, 분 단위로 기록하세요. 주의를 산만하게 하는 요인을 발견할 수도 있고, 점심 식사 후 15분 동안 산책을 하면 일을 더 효율적으로 할 수 있다는 것을 알게 될 수도 있습니다. 이것이 아마도 성공의 열쇠일까요? 아니면 세 번 연속 회의를 하게 되면 그 후 한 시간 동안 아무것도 하지 않고 사양만 읽는 자신을 발견하게 됩니까? 아마도 당신에게는 어려운 일이겠죠?

요점은 당신이 하고 있는 일을 면밀히 조사하는 것이고, 나는 당신이 개선할 부분을 식별할 것이라고 믿습니다.

기술적으로 어려운 프로젝트 참여

시스템 설계 또는 아키텍처 솔루션 전용 회의에 참석할 수 없는 경우 후속 조치나 문서를 읽어보세요. 문제를 해결하는 방법과 방법을 이해하려고 노력하십시오. 그러한 회의를 놓치지 않고 기술적인 측면에 최대한 몰입하도록 노력하는 것이 바람직합니다.

코드에 대한 심층 분석이 필요한 프로젝트 또는 프로젝트 측면을 선택하세요. 이를 통해 새로운 기술과 개발 방법론을 따라잡을 수 있습니다.

당신을 위한 RnD

프로젝트에서 문제가 있거나 기능을 개선할 수 있는 영역을 발견한 경우 자유롭게 프로토타입을 만들어 보십시오. 이를 통해 제안된 변경 사항을 시각화할 수 있을 뿐만 아니라 팀에 토론 및 의사 결정을 위한 실질적인 자료도 제공됩니다.

주요 목표는 단순히 아이디어를 선보이는 것이 아니라 실제로 중요하거나 유익한 것으로 입증되면 이를 프로젝트에 구현하는 것입니다. 예를 들어, 오래된 서비스를 Java 1.8에서 버전 21로 마이그레이션하는 것을 항상 꿈꿔왔다면 시도해 보는 것은 어떨까요? 프로토타입을 만들어 팀에 보여주고, 솔루션을 개발하고, 나중에 참조할 수 있도록 전체 프로세스를 철저하게 문서화하세요.

이 접근 방식은 기술적 개선을 구현하는 것뿐만 아니라 잠재적인 변경 사항에 관해 팀 내에서 공유된 이해를 형성하는 데에도 도움이 됩니다. 따라서 귀하는 프로젝트에 건설적인 기여를 하여 효과적인 개발을 보장하고 혁신을 촉진할 수 있습니다.

리뷰포인트!

이 단계에서는 몇 시간 동안 코드를 작성하고 솔루션을 제안한 후 잠시 휴식을 취할 수 있습니다. 물론, 리더십 위치는 단순히 두 가지를 모두 수행하는 것을 허용하지 않으며, 여전히 개발에 초점을 맞추고 있다면 복귀를 고려해 볼 가치가 있을 수 있습니다.

그것에는 아무런 문제가 없습니다. 비록 당신이 관리에 뛰어나더라도 관리가 지루해지고 있다는 것을 깨닫는 것은 괜찮습니다. 단지 이 시점에서는 그것이 당신에게 매력을 잃었을 뿐입니다.

아직 여유 시간이 있다면

학습과 자기계발

기술 문헌을 읽고, 교육 과정을 탐색하고, 기술 컨퍼런스에 참여하여 지속적으로 교육하십시오. 이는 소프트웨어 개발의 최신 동향과 모범 사례를 파악하는 데 도움이 됩니다.

기술 문헌을 읽으면 새로운 기술, 방법론 및 모범 사례를 깊이 있게 알아볼 수 있는 독특한 기회를 얻을 수 있습니다. 여기에는 소프트웨어 개발의 다양한 측면을 다루는 책, 기사, 블로그 및 기타 자료가 포함될 수 있습니다.

교육 과정을 수강하는 것은 새로운 주제와 기술에 대한 지식을 습득하는 체계적이고 체계적인 방법입니다. 온라인 강좌 플랫폼은 다양한 프로그래밍 언어, 프레임워크 및 개념에 대한 광범위한 강좌를 제공합니다.

기술 컨퍼런스에 참여하면 최신 동향과 혁신에 대해 배울 수 있을 뿐만 아니라 업계 전문가와 교류할 수 있는 기회가 열립니다. 컨퍼런스는 경험을 공유하고, 어려운 문제를 논의하고, 기술 커뮤니티 내에서 연결을 구축할 수 있는 플랫폼을 제공합니다.

요약하자면, 독서, 강좌 수강, 컨퍼런스 참석을 통한 지속적인 학습을 통해 소프트웨어 개발자는 최신 동향을 따라갈 수 있을 뿐만 아니라 새로운 지식과 기술을 일상 업무에 적극적으로 통합할 수 있습니다.

예: leetcode, Udemy 또는 Youtube(가끔 정말 좋은 무료 콘텐츠를 찾을 수 있습니다!)

개인 프로젝트 작업

가능하다면 자유 시간에 개인 프로젝트를 진행하세요. 이는 프로그래밍 기술을 향상시킬 뿐만 아니라 주요 업무에 대한 새로운 아이디어의 원천이 될 것입니다.

또한 이 활동을 기사의 RnD 포인트와 결합하면 창의성과 혁신에 대한 추가 인센티브가 될 수 있습니다.

개인 프로젝트를 수행하면 실제 시나리오에 자신의 기술을 적용하고, 새로운 기술을 실험하고, 실제 문제를 해결할 수 있습니다. 이러한 프로젝트에는 자체 웹 애플리케이션 개발, 오픈 소스 프로젝트 생성 또는 흥미로운 사이드 프로젝트 참여가 포함될 수 있습니다.

앞서 언급한 RnD(연구 개발) 작업과 이 활동을 통합하면 프로토타입을 제작하고 직장에서 전시할 수 있습니다. 오픈 소스 개발에 참여하는 등 프로젝트를 대중에게 공개하면 기술이 향상될 뿐만 아니라 귀중한 전문적 인맥을 구축하고 창의성을 인정받는 데에도 도움이 됩니다.

결론

팀 리더로서 코딩 시간을 찾으려면 의식적인 노력과 효과적인 우선순위 관리가 필요합니다. 귀하의 역할에는 팀을 직접 이끄는 것뿐만 아니라 기술적인 능력을 만족스러운 수준으로 유지하는 것도 포함된다는 점을 기억하십시오.

쉽지 않은 일이 될 것입니다. 행운을 빕니다!