작업량과 신입 사원 간 균형 유지 [폐쇄]

나는 약 2 개월 동안 첫 직장에 있었고 워크로드와 신입 사원 간 균형이 미묘하다는 것을 알았습니다. 경영진은 버그를 수정하고 가능한 한 많은 고객 문제를 해결해야한다는 압박이 많기 때문에 팀의 모든 직원은 새로운 직원의 속도를 높이는 대신 작업의 백 로그에 매우 집중하는 것 같습니다. 신입 사원은 질문을 할 수 있으며 때로는 개발자가 앉아서 도움을 줄 수 있지만 종종 제품의 베테랑만이 너무 바빠서 이해하지 못하는 모호한 답변을 얻습니다.

나는 새로운 고용이 균형을 유지해야한다는 것을 이해한다. 때로는 베테랑이 20 분 안에 할 수 있었던 일을 조사하고 고치는 데 3 일 정도 새로운 고용이 필요할 것입니다. 신입 사원은 제품과 코드베이스를 배우는 데 노력을 기울여야합니다.

재향 군인의 업무량을 줄이지 않으면 서 새 임차인을 돕는 것과 백 로그 작업을 합리적인 속도로 계속 진행하는 것 사이의 균형을 잡을 수 있습니까?

나는 당신이 "새로운 고용"관점에서 이것을 요구한다고 가정합니다. 나는이 상황에 여러 번 있었다. 때로는 많은 질문을하는 것이 기분이 좋지 않지만 도메인 지식이 부족한 경우가 종종 솔루션에 올 수있는 방법이 없습니다.

가장 기억해야 할 것은 이것입니다. "가정"할 때 질문을하지 마십시오. 스스로 답을 찾을 수 없습니다. 사물을 촬영하고, 먼저 찌르고, 코드를 검사하고, 몇 가지 사항을 변경하고, 어떤 일이 일어나는지 확인하십시오. 먼저 무언가를 얻을 수 있는지 확인하십시오. 당신이 정말로 할 수 없다면, 질문하십시오. 그러나 질문 할 때는 이미 시도한 예제를 사용하여 질문하십시오. 그들 중 누구도 당신이 당신을 위해 일을하도록 요구하는 것처럼 느끼기를 원하지 않습니다.

"저기서 노력하고 있는데 이걸 시도했는데 이미 아이디어가 있습니까?" 그렇게하면 더 적은 시간을 할애 할 수 있으며 더 많은 시간을 할애 할 수 있습니다.

우리 회사에서 우리는 처음 몇 개월 동안 그를 고용 할 모든 신입 사원을 임명합니다. 이 공식 과제를 통해 초보자는 한 사람 만 소비하고 새 직원을 "코칭"하는 사람은 자신의 개발에 대한 책임을지게되므로 부담이 아니라 일시적인 책임입니다. 새로운 녀석은 더 빨리 배우기 때문에 좋고, 이미 투자 한 녀석에게는 투자가 있습니다.

제가 드릴 수있는 가장 좋은 조언 은 약속을 잡는 것 입니다. 모든 사람은 하루 동안 약간의 가동 중지 시간을 갖지만 무작위로 떨어질 경우 타격을 입을 가능성이 거의 없습니다. "X에 대해 몇 가지 질문이 있습니다. 오늘 시간을 내서 함께 할 수 있습니까?" 그들은 즉시 또는 나중에 시간을 주거나 귀하의 질문에 더 잘 또는 더 빨리 답변 할 수있는 사람을 추천 할 수도 있습니다. 어느 쪽이든, 당신은 더 집중된 관심을 얻게 될 것입니다. 그들이 나중에 당신에게 약속을 주면, 개입 시간을 사용하여 스스로 답을 알아 내거나 최소한 질문을 수정하십시오. 내가 15 분 동안 누군가의 질문을 연기하더라도, 그들은 종종 스스로 알아 채지 못합니다.

대부분의 사람들에게 귀하의 질문 은 우리에게 중요하며, 보통 긴급 하지는 않습니다 . 그 차이에 화를 내지 마십시오.

경험이 풍부한 코더 중 일부는 실제로 더 젊은 개발자를 멘토링하는 것을 좋아하며 그렇게하는 것을 우선시합니다. 나는 기회가있을 때마다한다. 어쩌면 도움이 필요할 때마다 다른 동료에게 질문 한 다음 답변에 대한 열정을 측정하여 회사에서 그런 사람을 찾을 수 있습니다.

도움이 필요할 수있는 두 가지 방법이 있습니다. 언어 나 도구에 문제가있는 경우 온라인이나 기술 서적을 구입하여 제 시간에 읽음으로써 답변을 찾을 수 있습니다. 당신을 훈련시키는 것은 회사의 책임이라는 느낌이 합리적이지만 더 이상 훈련에 투자하는 회사는 거의 없습니다. 개발자로 성장하려면 직장에 없을 때 스스로 훈련하는 데 시간과 돈을 투자해야합니다.

소스 코드에서 어떻게 작동하는지와 같이 회사 제품에 대한 질문이있는 경우 동료에게 도움을 요청해야 할 가능성이 높습니다. 또는 개정 제어 시스템에서 제품 코드의 분기를 작성하고 "learning_new_code"와 같이 분기의 이름을 지정한 다음 실험 해보십시오.

마지막으로 프로젝트 관리자와 부서 관리자가 귀하와 같은 문제를 해결하도록 도와줍니다. 더 많은 경험이있는 동료들로부터 시간을 내야한다고 생각하지만 다른 사람들이 당신에게 그것을 줄 수 없다면, 마감일이 있기 때문일 수 있습니다. 아마도 관리자는 마감 시간을 연장하여 더 많은 시간을 할애 할 수 있습니다.

나는 이것이 현재 문제가되지 않는 곳에서 일하고 있음을 행운입니다. 나는 이곳에서 건강한 멘토링을 받았으며, 매우 기쁘다.

1. 우리 회사의 한 개발자는 매일 "유틸리티"개발자입니다. Util 개발자는 지원이 무언가를 에스컬레이션해야 할 때 첫 번째 연락선입니다. 종종, Util은 다른 사람에게 문제를 전달하고 있습니다. 그러나 그것은 하나의 특정 개발자이며 지원은이 사람에게 가야한다는 것을 알고 있습니다. 나는 몇 가지 문제를 어떻게 다루 었는지보기 위해 처음에는 몇 가지 "승마 동행"을했다. 이것은 코드의 일부에 노출되었습니다. 그들이 나의 정규 이용일을 계획하기 시작했을 때, 처음에는 추가 지원을 추가 할 "통화 중"누군가가있었습니다.

2. 우리는 페어링합니다. 당신은 거의 페어 타임을 예약해야하지만, 여기의 모든 사람들이 기꺼이 할 것입니다. 더욱이, 모든 사람들은 일정이 무엇인지 알고 있으며 다음 포인트 덕분에 각 개인의 발전 상황에 대한 아이디어가 있습니다. 따라서 문제가 있으면 적절한주의를 기울입니다.

3. 매일 우리는 11:45에 스탠드 업 회의를합니다. 15 ~ 20 분입니다. 모든 개발자 / QA 담당자가 말합니다. 기본적으로 "이것은 내가하고있는 일이며 이것이 붙어있는 곳입니다"라고 말하는 방법이며, 붙어있는 경우 일반적으로 다른 방향으로 향하게됩니다 (알려진 문제 / 코드 관련 문제가있는 경우 누군가에게 매우 익숙합니다) with) 또는 페어링 시간이 설정되었습니다. 간혹 추가 회의가 예정되어 있습니다.

4. 나는 (모든 직업과 마찬가지로) 여기에서 여러 번 완전히 외계인 코드로 뛰어 들어야했습니다. 누군가가 즉시 질문에 대답 할 수 있도록 항상 노력해 왔습니다.

나는 다른 사람들에게 반향을 줄 것이다 : 가능한 경우 질문을하기 위해 회의 시간을 계획한다. 그래도 도움이되지 않습니다. . . 글쎄, 나는 여기서 극단적으로 가고 싶지 않습니다. 그러나 나는 그것이 이상적인 직장이라고 생각하지 않습니다. 사람들이 여전히 당신에게 워밍업을 할 수 있습니까?

사람들이 한 번 느꼈을 때 속도가 빨라져서 업무 시간이 줄어들었기 때문에 탑승 할 때 소요되는 추가 시간이 쉽게 정당화 될 수 있다고 생각합니다. 더 많은 시간을 단기적으로 보내면 장기적으로 많은 시간을 절약 할 수 있었으며 모두가 내가 일하는 곳을 이해했습니다. 나는 현재 위치에서 매우 운이 좋다.

종종 이것은 시간보다 초점의 문제입니다. 일주일에 두 번 팀 리더 또는 멘토와 30-45 분 간의 회의를 예약하십시오 (점심 전이나 후에 항상 선호합니다.

대부분의 개발자 (또는 최소한 회의에서 가장 도움이 될 것 같은 개발자)는 이것으로 충분할 것입니다.

진행 상황을 막고있는 세부 사항이 있다면 이메일을 사용하십시오.