좋은 건축가 / 관리자 / 리드 개발자를 위해 무엇이 필요한가요?

저는 소규모 소프트웨어 회사의 수석 개발자입니다. 지난 2 년 동안 우리 팀은 한 명의 개발자 (나)에서 약 9 명의 그룹으로 성장했습니다. 우리 대부분은 매우 유능한 선임 엔지니어 (1 인당 소프트웨어 제작 경험 20 년 이상)이므로 손을 거의 들지 않아도됩니다. 우리는 노력을 관리하기 위해 스크럼을 사용하며, 최소한의 서면 요구 사항만으로도 빠르게 많은 일을 처리합니다.

팀이 성장함에 따라 프로젝트 전체에 대한 기술 감독을 유지하면서 상당한 양의 새 코드를 직접 작성하는 것이 어려운 시점에 이르렀으므로 역할을 조정할 때가되었습니다. 더 이상 개발에 대부분의 시간을 소비하지 않을 때 팀에 가장 유용한 방법은 무엇입니까?

저의 목표는 더 많은 개발자를 추가하여 그룹이 더 성장할 수 있도록하는 것입니다. 다시 말해서, 불필요한 관료주의 계층을 추가하여 일을 늦추는 사람보다는 일이 더 잘 작동하도록 도와주는 사람이되고 싶습니다. 그럼에도 불구하고 우리의 주요 위험 중 하나는 동일한 페이지에 우리를 모두 유지할 수있는 충분한 구조를 갖지 않고 더 많은 사람들을 추가하면 상황이 통제에서 벗어날 수 있다는 것입니다.

목표를 달성하는 가장 좋은 방법은 무엇입니까?

이런 팀에 있었다면 상사가 그의 시간과 어떤 관계를 갖길 원하십니까?

1. 진행할 장애를 제거하십시오.
2. 팀원 간의 분쟁을 중재하십시오.
3. 비즈니스 사람들과 상호 작용할 필요가 없습니다.
4. 우리가 고립 된 느낌이 들지 않도록 더 높은 수준의 비즈니스 / 프로젝트에 대해 알려주십시오.
5. 특히 나쁜 사과가 팀에 들어간 경우 정직하게 유지하십시오.
6. 다른 부서의 팀을 옹호하십시오.
7. 불합리한 비즈니스 요청에 대한 푸시 백의 통일 된 목소리가 되십시오.
8. 팀 간의 커뮤니케이션을 촉진합니다.

내가 잊어 버린 무리가 있을지 모르지만 그것이 핵심입니다. 프로세스를 구현하지 말고 팀 규모가 증가함에 따라 자연스럽게 발생하는 오버 헤드 / 비효율을 처리하십시오.

경영진과 기술 직무의 균형을 이룰 수있는 팀장에게는 아무런 문제가 없었지만, 그 균형을 잘 관리하는 사람들을 찾기 란 쉽지 않습니다.

성장하는 팀의 팀 리더에서 두 가지 극단 중 하나를 선택해야한다면 ... 정말 어려운 선택이지만 궁극적으로는 팀 리더가 더 많은 관리자가되기를 바랍니다. 규모가 큰 팀에는 팀의 새로운 멤버를 육성하고 개발에 많은 노력을 기울일 수있는 수석 개발자 역할을 맡을 다른 후보자가 있기를 바랍니다.

그러나 성장하는 팀에서는 확실히 훌륭한 관리자를 원할 것입니다. 실제로, 관리 직책을 가진 좋은 사람을 갖는 것은 중요한 결정을 수행하기에 충분한 권한을 갖기를 원하기 때문에 중요합니다. 훌륭한 관리자는 팀의 행복과 정확한 이유에 큰 영향을 미칩니다. 생산성을 유지하고 당신처럼 생각하는 데 도움이됩니다. 쥐의 엉덩이를주지 않는 관리자가 많이 있습니다.

프로그래머의 다른 게시물을 추천합니다. 공식적인 관리 역할보다 팀장에게 더 적합하지만 다음과 같은 도움이 될 수 있습니다.

팀 리더로의 전환

수석 개발자로 성공하려면 어떻게해야합니까?

팀 리더로서 팀 구성원을 존중하는 방법

나는 이것이 이러한 특성의 균형이라고 생각합니다.

• 전문 기술 : 지시하는 업무의 질을 평가할 수없는 사람을 원하지 않습니다.
• 자기 주도적 : 목표를 정의 할 수 있으며 반응하지 않습니다.
• 갈등을 활용하는 방법을 안다 : 갈등은 대화를 유발한다
• 자동 학습 : 모든 것을 아는 것은 중요하지 않지만 배우는 방법을 아는 것은 중요합니다.
• 좋은 태도와 에너지 : 당신은 주문을 짖는 디바가 아니라 동기를 부여하고 모든 사람의 일을 더 편하게하는 사람을 원합니다.
• 실패 경험 : 아마도 가장 중요한 것입니다. 나는 이전의 모든 것에 문제가 없을지도 모르는 아주 어린 지도자들을 보았습니다. 그러나 실패의 첫 징후에 그들은 얼어 붙거나 책임을 회피합니다. 선배는 나이와 관련이 없지만 올바른 경험의 올바른 양과 실패는 분명히 고려해야 할 것입니다.

OTOH, 인터뷰는 올바른 사람을 얻는 데 중요한 부분이므로 인터뷰에서 다음과 같은 질문을하는 것이 좋습니다.

• "실패한 프로젝트, 실패한 관리 방법 및 그로부터 배운 내용을 알려주십시오."
• "일을 끝내기 위해 규칙을 어겼을 때를 말해줘"
• 생각할 수있는 약간의 왜곡으로 Fizz Buzz 테스트를 적용하십시오 .

FizzBuzz 테스트는 절대적으로 필수입니다. 옳고 그름은 다음과 같이 중요하지 않습니다.

• 응답하는 데 걸리는 시간 : 평균 15 분, 30 분 경계선 확인,> 30 분 NOT OK
• 자신의 코드를 디버깅 할 수있는 경우 : 한 번 15 년의 경력을 가진 사람이 고위 직책을 신청하게했습니다 ... 그는 의사 코드에서 테스트를 완료하는 데 40 분이 걸렸습니다 ... 잘못되어 이유를 찾을 수 없습니다. 나는 다른 사람이 약 5 분 동안 자신을 정당화하고 그가 잘못되었다는 것을 받아 들일 수없는 또 다른 경우를 가졌습니다.