기술 리더로서 내가 배운 놀라운 교훈

안녕하세요 여러분! 글을 쓰지 않다가 다시 돌아와서 일상에 다시 적응하려고 합니다. 이 공간에서 공유하는 경험은 제 학업 및 직업적 경험에 기반을 두고 있다는 점을 강조하고 싶습니다. 따라서 여기에 설명된 내용은 현실의 일부에 불과할 수 있으며 특정 프로세스, 절차 또는 서비스에 대한 확정적인 공식으로 해석되어서는 안 된다는 점을 기억하는 것이 중요합니다.

저는 현재 제 경력의 이 새로운 단계에 대해 매우 흥분하고 있습니다. 저는 많은 것을 배웠고 이 여정의 일부를 커뮤니티와 공유하고 싶습니다. 여기에 제시된 정보가 독자들에게 큰 가치가 있기를 바랍니다.

사람이 우선 - 소프트 스킬의 중요성

몇 년 전 첫 선발 과정에 참여했을 때, 저는 제가 거친 거의 지루한 단계를 생생히 기억합니다. HR과의 면접, 실기 시험, 기술 리더와의 면접, 마지막으로 관리자와의 면접이었습니다. 개발자로서의 경력 동안 저는 여러 모델과의 면접에 참여했습니다. 그 당시 저는 항상 HR 담당자와의 면접이 불편했습니다. "기술 시험에서 요구되는 것을 할 수 있다면, 이미 그 직책에 충분한 역량을 보여주고 있는 거야."라고 생각하면서 그 이유를 잘 이해하지 못했습니다.

기술 개발 리더 역할을 맡았을 때 제 책임 중 하나는 HR(예, 선발 과정에 참여한 이유를 이해하지 못했던 사람들과 같은 사람들)과 협력하여 기술 테스트를 준비하고 백엔드 분야에서 시작하는 두 후보자를 위한 면접 형식을 정의하는 것이었습니다. 저는 백엔드 분야의 초보 개발자가 무엇을 제공해야 하는지, 테스트에서 무엇이 차별화 요소로 간주될지 이미 알고 있다고 생각했습니다. 하지만 예상하지 못했던 것은 코드의 중요성에도 불구하고 프로젝트 제공을 넘어서 다른 요구 사항이 생겼다는 것입니다. 의사 소통 측면에서 후보자를 평가하는 방법은 무엇일까요? 직책에 대한 관심은 무엇일까요? 그리고 그들이 제시하는 맥락이 제안된 직책에 대한 적합성에 어떤 영향을 미칠 수 있을까요? 이러한 질문과 다른 질문은 두 후보자가 제시한 코드만큼이나 관련성이 있는 것으로 드러났습니다. 이는 제가 개발자로서 초기에는 고려하지 않았던 것입니다.

저는 최종 결정을 내리기 위해 회의 테이블에 앉아 있었고 각 후보자의 기술 능력에 대해 얼마나 적게 논의되었는지 깨닫고 약간 놀랐던 것을 기억합니다. 그 이유 중 하나는 그들이 입문 수준의 후보자였기 때문에 그들의 기술 능력이 그렇게 발달되지 않았을 것이라는 예상이 있었고, 이것이 토론의 주요 초점이 아니었습니다.

그러나, 특히 고위 직책의 경우, 더욱 발전된 공석의 경우에도 커뮤니케이션, 문서화, 적응력, 적극성 및 자주 언급되는 다른 기술과 같은 기술을 고려하는 것이 중요합니다. 이러한 소프트 기술은 기술적 기술 외에도 기본적이며 역할에서 성공하는 데 결정적일 수 있습니다. 사실, 이것이 제 다음 요점입니다.

주니어와 시니어의 경계선입니다.(중급 레벨이 아닙니다.)

"시니어"와 같은 경험 수준과 관련된 용어의 의미와 분류에 대한 많은 논의가 있다는 것을 알고 있습니다. 어떤 사람들은 "시니어는 경험 연도로 정의된다"고 말하고, 다른 사람들은 "어떤 회사에서는 1년 후에 시니어 경험을 얻는다"고 주장합니다. "주니어와 시니어의 명확한 구분이 없다"거나 "시니어는 코드 검토만 하고 PR을 승인한다"고 말하는 사람들도 있습니다. 이러한 진술 중 일부는 우스꽝스럽고, 다른 일부는 진실이 있습니다. 사실 "시니어"라는 개념은 매우 다양하고 보편적인 표준을 정의하는 것은 나에게 달려 있지 않지만, 이 분류를 보다 개별적인 방식으로 이해하기 위한 몇 가지 지침을 제공할 수 있습니다.

선임자가 된다는 것은 기술적인 지식만을 의미하는 것은 아니지만, 이는 의심할 여지 없이 매우 중요합니다. 진정한 선임자, 또는 적어도 훌륭한 선임자는 코드와 시스템 아키텍처 측면에서 복잡한 문제를 해결할 수 있는 사람입니다. 코드 품질을 유지하고, 좋은 개발 관행을 따르고, 프로젝트 관리에 대한 지식을 갖는 것은 중요한 측면입니다.

가장 큰 차이점은 선임자는 이 모든 것을 자율적으로 실행해야 하며, 더 중요한 것은 가능한 최고의 프로젝트를 제공하기 위해 다양한 레벨과 부문의 팀과 협력해야 한다는 것입니다. 나아가, 진짜 선임자(또는 적어도 최고의 선임자)는 팀을 이끌고 안내할 뿐만 아니라, 다른 개발자들이 새로운 직책과 책임을 맡을 수 있도록 개발하고 준비시킵니다.

내가 처음으로 프로젝트를 이끈 경험

첫 번째 프로젝트를 맡았을 때, 상사는 제가 이전에 다른 프로젝트를 이끈 적이 없다는 것을 알고 있었습니다. 저는 개발에 참여하고 경영진과의 소통 측면에서 개발을 용이하게 할 몇 가지 사항을 알아냈습니다. 그가 저에게 한 첫 번째 질문은 "얼마나 많은 사람이고 어떤 종류의 사람이 프로젝트를 보완하기에 충분할까요?"였습니다. 저는 바로 답을 알 수 없었고, 매우 복잡한 질문이었습니다. 프로젝트가 개요에만 있었기 때문에 스택, 각 작업을 완료하는 데 걸리는 시간 및 상위 계층의 사람들에게 관심 있는 다른 지표에 대해 전혀 알지 못했습니다. 저는 다음 날 여러 프로젝트 관리 방법론을 전달할 수 있도록 완전한 연구를 수행했습니다. Pert, Planning Poker 우리는 가장 적합한 것을 협력하여 선택했고 도전이 시작되었습니다. 팀의 각 구성원에게 가장 적합한 개발 플랫폼은 무엇이며, 사용하기에 가장 적합한 스택은 무엇이며, 시스템 아키텍처는 어떻게 작동하며, 시중에 나와 있는 다른 솔루션을 연구하고, 각 개발자의 수준을 모니터링하고, 경영진과 회의, 회의, 회의 등을 했습니다 .

제가 가장 깨닫지 못했을 때, 저는 코드에서 점점 멀어졌습니다. 제 역할은 프로젝트가 작동할 수 있도록 개선 사항을 제안하고 몇 가지 중요한 버그를 수정하거나 적어도 개발자가 시작할 수 있는 견고한 기반을 제공하는 것이 되었습니다. 나머지 작업에는 개발자와 소통하고, 작업을 나누고, 지표를 모니터링하고, 기본적으로 Asana(프로젝트 납품 시간을 추정)에 한 눈을 두고, Meet에 다른 눈을 두고 마이크가 켜져 있지 않고 원치 않는 것이 "실수로" 빠져나가지 않도록 하는 것이 포함되었습니다.

결론과 과거를 돌아보며 - 스승님께 애정을 담아

저는 개발 인턴으로 경력을 시작했고, 흥미롭게도 - 제 입장에서는 약간 모순되는 것 같을지도 모르지만 - 저는 주니어, 풀, 시니어 개발자로 분류할 만한 구체적인 경험(적어도 제 고용 기록에 공식적으로 기록되지는 않은)이 없었습니다. 제가 얻은 경험의 대부분은 개인 프로젝트와 대학에서의 연구를 통해 얻었습니다. 제 기술이 그 초기 시절 이후로 발전했다는 것을 깨닫기 전까지는 점진적인 과정이었습니다.

하지만 그렇죠. 저는 개발자로서 다양한 레벨에서 집중적으로 일했고, 제 경력 동안 다양한 유형의 고위 전문가를 만날 기회가 있었습니다.

1. 매우 유능하고 효율적인 선임자였지만 의사소통 능력이 부족했고, 접근 방식에 대한 설명도 없이 문제를 해결했습니다.
2. 선배 선생님은 의사소통과 교육에 매우 능숙하지만, 긴급한 업무에 압도당해 가르칠 시간이 없는 경우가 많습니다.
3. 과도한 엔지니어링과 기술 중앙집중화를 열광적으로 지지했지만, 마감일을 맞추고 약속한 것을 이행한 선배.

가장 중요한 것은, 정당한 결함이 있음에도 불구하고(가능하지만, 요구 사항을 균형 있게 조절하는 것은 매우 어려움) 이 모든 전문가는 가르칠 만한 가치 있는 무언가를 가지고 있었다는 것입니다. 이러한 경험은 제 경력을 형성하는 데 도움이 되었고 시스템 개발에서 무엇이 효과가 있고 무엇이 효과가 없는지에 대한 명확한 관점을 제공했습니다.