개발자 팀에 관리자가 필요합니까?

배경:

저는 현재 1 명의 관리자, 1 명의 수석 개발자 및 2 명의 개발자로 구성된 4 명의 팀에 속해 있습니다. 우리는 약 3500 명의 직원으로 구성된 맞춤형 사내 시스템 / 프로젝트 (예 : 6-8 주)뿐만 아니라 이전에 생성 된 시스템에서 필요한 모든 유지 보수 및 지원을 수행합니다. 잠재적으로 나아갈 모든 작업을 수행하기에는 충분하지 않습니다. 경영진은이를 인정하지만 예산 제한으로 인해 추가 멤버를 팀에 채용 할 수있는 능력이 제한됩니다 (저축으로 다시 급여를 내더라도).

변화

이것은 우리가 지금있는 곳을 떠납니다. 우리의 관리자는 목초지에 새로운 역할을 맡기고 팀에 공석을 남겨 두어야합니다. 경영진은이 기회를 사용하여 팀 관리자 역할을 다른 개발자 및 다른 선임 개발자로 대체 할 팀을 재구성합니다. 그들의 논리는 우리가 더 많은 개발자가 필요하다는 것이므로 여기에 자금을 조달하는 방법이 있습니다 (역할 중 하나는 다른 빈 자리에서 부분적으로 자금을 지원받습니다).

이 팀에는 직속 관리자가없고 역할과 책임은 선배와 (상대적으로 새로운 포스트) 서비스 관리자 (주로 개발 지식 / 경험이 거의없는 비 기술적 역할)로 나뉘어 질 것입니다. 많은 다른 팀과 개인들 사이에서)-누가 먹이 사슬의 다음 실제 관리자가 될 것입니다.

마지막 질문은 다음과 같습니다.

관리자없이 개발 팀을 운영 할 수 있습니까? 이것에 대한 경험이 있습니까? 어떤 일이 잘못되거나 우리에게 유익 할 수 있습니까?

이상적으로는 "빛을보고"이런 식으로 일을 할 때의 이점을 원하거나 이에 대한 논쟁의 요점을 생각해보고 싶습니다.

위험이 클수록 "에어 커버"가 더 필요합니다. 이것은 관리자가 실제로 제공 해야하는 것입니다. 팀이 작업을 수행하는 동안 관리자는 팀이 팀 목표를 달성하는 데 방해가되는 요소가 없도록해야합니다. 일정을 조정하거나 팀과 영업 직원 간의 간섭을 수행하거나 단순히 시간을 지불하고 커피 머신이 정상적으로 작동하는지 확인하십시오. 정말 훌륭한 관리자는 팀이 마치 관리자가없는 것처럼 작동하도록합니다.

물론 현실은 대부분의 관리자들이이 점에 완전히 실패한다는 것입니다. 그들은 마이크로 매니지먼트이거나 회사의 상류층이 더 직접적으로 일을 통제 할 수 있도록 쓸모 없게되었으며 진정으로 위대한 관리자는 드문 새입니다. 소프트웨어 팀에 관한 한, 계층 적이거나 평평한 팀 구조를 갖는 데에는 두 가지 장단점이 있습니다. 팀이 매우 작고 수행 된 작업이 거의 겹치지 않으면 (그리고 모든 사람이 독립적 인 프로젝트를 의미한다는 의미), 플랫 한 (일명 관리되지 않는) 팀 구조가 모든 경우에 잘 작동 할 수 있다는 것은 내 경험이었습니다. 팀원은 훈련을받습니다. 그러나 팀원들이하는 일에 상당한 중복이있는 곳, 상대적으로 강한 성격이 둘 이상인 곳,

관련된 많은 요소가 있지만 실제로는 관련된 성격, 개인의 동기 부여 및 경력 목표, 상급 관리자가 제공하는 모범 및 지침에 따라 관리자 또는 팀 리더의 위치가 얼마나 필요한지를 결정합니다. 일반적으로 혼돈이 있고 팀이 요청할 때 팀은 분명히 리더십이 필요합니다. 일반적으로 관리 입력없이 문제가 발생하면 팀은 적어도 작업량과 일정을 관리하기가 어려워 질 때까지 비 계층 구조 내에서 한동안 관리 할 수 ​​있습니다.

누군가 관리자가되어야하지만 팀의 경우에는 이것이 전 임직이라고 생각하지 않습니다. 다른 sr을 고용하십시오. 개발하고 그들 중 하나를 관리자로 만듭니다. 이상적으로는 관리자가 될 수 있고 반드시 최고의 프로그래머는 아닙니다.

관리자는 합의가없는 곳에서 최종 결정을 내려야하므로 기술적으로 자격을 갖추어야합니다. 다른 프로그래머, 회의를 평가하고 고위 경영진을 퇴치하는 것도 직업의 일부입니다.

제안 된 독서 : 바지없는 해 . 대규모 소프트웨어 프로젝트 (WordPress)조차도 직속 관리자 없이도 갈 수 있지만 일부 작업 (아무도하고 싶지 않은 / 아무 어려운 것도 없음)이 있거나 동일한 작업을 위해 많은 수의 개발자를 통합해야하는 경우 중앙 제어.

다른 사람들이 지적했듯이 귀하의 질문에 대한 간단한 대답은 그렇습니다.

귀하의 질문에 대한보다 완전하지만 복잡한 답변은 다음과 같습니다.

"관리는이를 인정하지만 예산 제한으로 인해 팀에 추가 구성원을 모집 할 수있는 능력이 제한됩니다"

경영진은 "예, 인정합니다. 인정합니다"라는 말은 단지 기분을 좋게하는 "단어"입니다. 그들은 조직의 성공에 비판적이라고 생각 하지 않거나 실제로 누군가를 얻는 것을 지원할 것입니다!

(심리학이 많기 때문에) 조심해야 할 또 다른 것들은 경영진이 나쁜 소식을 말하지만 약간의 농담이 섞여서 직접 문제를 언급 할 수도 있고 아닐 수도 있지만 근본적으로 질문 할 수없는 것입니다 ( 미묘하고 영리한 기술). 주의해야 할 또 다른 것은 계획을 제시하고 2 시간 55 분 안에 귀하의 의견을 묻는 3 시간 회의입니다.

옳은 일을하는 경영진이 아니라 옳은 일을 "말하는"경영진의 태도를 취하십시오.

관리자 없음 = 책임 없음 = 장기적으로는 메시지가 없습니다. 모든 사람은 자신이 좋아하는대로 행동 할 것이며 중간 경영진은 누가 누구에게 말해야하는지, 누가 옳은지, 누가 주어진 문제 나 요청에 대해 옳지 않은지를 확신하지 못할 것입니다. 작업이 그렇게 분리되어 있고 관계가 거의 없거나 전혀없는 한, 많은 '소규모 관리자'를 갖는 것은 주어진 작업을 수행 할 수있는 방법이 너무 많기 때문에 바쁜 개발자가 항상 습득하지 못한 전문 지식이 필요하기 때문에 개발에서 작동하지 않습니다. 누군가가 전체 그림을 볼 필요가 있습니다. 제안 된 스타일은 레거시 또는 현재 응용 프로그램을 지원하지만 개발되지 않은 팀에 적합 할 수 있습니다. 낙관적으로 말하면, 조직이 합리적으로 잘 작동하기 전에 조직과 시련과 실패가 필요합니다.

위의 답변에 동의하지만 중요한 고려 사항이 있습니다.

"관리자"는 직책이지만 역할의 관점에서 생각 하면 관리자는 특정 책임 이있는 사람입니다 . 이러한 책임이 무엇이든, CxO와의 협상, 보고서 작성, 휴가 관리 또는 커피 머신 작성 등 팀에 책임이있는 사람이 필요합니다.

프로 -그것은 당신 중 하나 일 수 있으며, 이것은 그의 경력에 ​​큰 도움이 될 수 있습니다. 나머지 팀은 "위에서 배정 된"사람이 아니라 팀의 요구를 깊이 이해하는 사람을 얻게됩니다.
물론, 그녀가 관리 업무에 얼마나 많은 시간을 할애하고 이전에 그녀가하던 일에 남는 시간을 협상하는 것을 잊지 마십시오.

단점 — 관리자 가되고 싶지 않은 사람도있을 수 있습니다. 이것에는 나쁘지 않습니다. 많은 개발자들은 보고서, 다이어그램 및 회의에 "시간을 낭비"하는 것보다 키보드 및 기타 개발자를 선호합니다. 매일 아침 비명을 지르는 보스와 5 분의 시간이 극도로 자극적이라고 믿어주세요! :)

따라서 다음과 같이 질문하십시오. 전담 관리자
없이 개발 팀을 운영 할 수 있습니까? — 예 .
팀이 그 변화에 대비할 준비가 되셨습니까? — 말할 수 없습니다.
시도 해봐. 시도해 볼 가치가 있습니다.

저는 현재 관리자없이 소규모 팀에서 일하고 있습니다. 소규모 회사. 잘 작동한다.

귀하의 마일리지가 다를 수 있습니다.

기술 책임자와 관리자가 필요합니다. 예 하지만 개인적으로 기술 리드가 훨씬 더 중요하다고 생각합니다. (무엇인지 확실하지 않은 경우 기본적으로 작업을 수행하고 모든 사람이해야 할 일을 수행하는 사람입니다.)

각 팀원이 팀으로 일하고 이해 관계자의 기대에 부응 할만큼 성숙한 개발자 팀은 관리자가 필요하지 않습니다.

해결해야 할 문제에 중점을 두어야 할 다른 역할 (개발자 등)이 있으며 다른 환경 요인에 대해 걱정하지 않아도됩니다. 관리자가 도움이되는 곳입니다.

가치를 더할 수있는 선배가 항상 도움이된다고 말했습니다. CEO조차도 관리자 팀 (이사회)에게보고합니다.

내 2 센트 ...

나는 그것이 조직의 팀을 위해 싸워야 할 전투에 달려 있다고 제안합니다. 당신이 당신의 일을 방해하는 데 문제가있는 경우, 관리자는 그들을 분류해야합니다.

우선 순위가 현명하게 통제되고 설정되도록 보장하고, 업무를 수행하는 데 필요한 장비, 소프트웨어 등을 확보하는 등의 일이 있습니다. 그들은 조직에서 팀의 옹호자가되어야합니다.

비즈니스에 어떻게 참여하고 어떻게해야하는지 어떻게 결정하며 누가 언제 '완료'되었는지 결정합니다. 조직에서 관리자가 많은 일을하지 않고도 이러한 일을 처리한다면 큰 도움이됩니다. 그러나 팀 외부에서 변경이있을 수 있으며 비즈니스에서 한 두 명의 핵심 직원이 역할을 변경하면 어려운 상황에 처할 수도 있습니다.

아마도 당신은 당신의 옹호자가 될 수있는 조직에서 강력한 리더를 선택할 수 있지만, 매일 매일의 경영진에 참여할 필요가없고, 그들에게 다가 가서 그들이 팀을 기꺼이 맡을 의향이 있는지 알아볼 수 있습니다. (아마도 당신이 언급 한 '서비스 관리자'와 함께 그렇게했을 것입니다.)

짧은 대답 : 예 가능합니다.

긴 대답 : 그러나 그것은 팀 성격에 달려 있습니다. 분명히, 누군가가하고있는 일을 결정해야하므로보고 할 사람이 필요합니다. 팀의 관리자 일 필요는 없지만 누군가는 당신에게해야 할 일을 주어야합니다. 팀 내에서 우선 순위 및 / 또는 기술 문제를 결정하기 위해 누군가가 필요할 수 있지만 팀 리더가이를 쉽게 수행 할 수 있습니다.

어쩌면 개발자 팀을 다른 팀과 병합해야 할 수도 있습니다. 테스트 팀이 있습니까?

서비스 관리자가 수행 해야하는 작업을 제공하고 필요한 품질에 맞는지 확인할 수 있으며이 작업을 수행하는 데 개발 경험이 필요하지 않습니다. 소프트웨어는 비즈니스 도구입니다. 요구 사항에 맞거나 그렇지 않은 경우가 많으며 일반적으로 사용자를 결정하는 가장 좋은 사람들입니다. 서비스 관리자는 귀하와 그들 사이의 연락 담당자 역할을하며 귀하가 올바르게 일하기를 바랍니다. 일이 잘못되기 시작한 것처럼 경영진이 그를 책임질 때까지 불행한 상태에 빠지게 될 것입니다. 당신.

자체 관리 팀은 평범하지 않습니다. 내부적으로 생성 된 책임을 생성하려면 일반적으로 명확한 성능 메트릭이 필요합니다. 조직에서이 기능을 사용할 수 있지만 비용 절감을 기반으로 추가 인원을 생성 할 수 없으면 작동하지 않을 수 있습니다. 또 다른 도전은 새로운 상사가 재능을 보상하는 방법을 아는 사람처럼 들리지 않는다는 것입니다.

더 좋든 나쁘 든 플레이어 코치가 필요한 것처럼 들립니다. 팀을 관리하고 수행 할 수있는 사람. 4 명 그룹에서는 이것이 가능합니다. 8 개 또는 10 개 그룹에서는 그렇지 않습니다. 이 선수 코치가 누구인지 확인해야합니다. 기본값은 최고의 프로그래머가되지만 관리자와 반드시 연결하고 싶습니까? 뛰어난 성과를내는 조직이 모든 최고 기술자가 관리자가되도록 강요하지 않는 방법을 찾는다는 것 외에는 단단하고 빠른 대답이 없습니다.

관리자는 조직과 개발자 팀간에 누락 된 링크 인 경향이 있습니다.

• 그들은 귀하의 업무가 관련성이 있고 조직의 요구를 충족시키는 지 확인합니다.
• 경영진에 대한 답변
• 프로젝트가 제 시간에 맞춰 지도록 일정 관리
• 프로젝트에 대한 요구 사항이 해결되었는지 확인하십시오.

작은 책임을 가진 소규모 팀은 지정된 관리자 없이도 기능 할 수 있습니다. 그러나 책임이 커질수록 모든 위험과 문제를 관리하는 사람이 필요합니다.

설정이 완료되면 팀의 누군가가 지정되지 않은 경우에도 관리자 역할을 수행하게됩니다. 일반적으로 분산 책임은 제대로 작동하지 않습니다. 배포 방법과 관련된 사람들의 유형에 따라 다릅니다.

관리자의 장점은 팀의 역할에 따라 다릅니다. 따라서 실제로 팀에 필요한 역할이 결정됩니다.

• 팀원 간의 분쟁을 해결하고 팀이 제 시간에 양질의 작업을 제공하는 데 집중할 권한이있는 사람이 필요하십니까?
• 아니면 최고 답변에서 언급 한대로 에어 커버 를 제공 할 사람이 필요 합니까? 일정 관리, 우선 순위 결정, 고위 경영진과 팀 간 개입 등

그래서 그게 필요합니까? 당신이 언급 한 직책에있는 사람들이 당신을 위해 이것을 할 수 있습니까? 그렇다면 괜찮습니다. 그렇지 않다면 아마도 재난을 겪을 것입니다.

출처 : 그룹 프로젝트 및 관리 및 관리되지 않는 팀에 대한 개인적인 경험.

나는 한 명의 담당 직원을 동급 / 유사 급 엔지니어 그룹에 파견하지 않으면 플랫 팀이 항상 문제라고 생각합니다.

S.Robins가 언급했듯이 모든 팀원이 잘 훈련되어 있다면 관리자를 배치하는 것이 불필요한 병목 현상이 될 수 있습니다. 내가 일한 소수의 회사 중 일부는 (다른 이유로 예산 제약으로 인해) 인력 제약이 있기 때문에 몇 명의 신입생 / 후배 그룹을 평범한 팀에 배치하는 경향이 있습니다. .

"1 수준 이상"관리자가 사람을 관리 할 수없는 경우 역효과가 발생합니다. 경력을 시작한 신입생 / 후배 자들은 경쟁이 치열해질 것입니다. 가능한 한 빨리 팀에 자신을 확고히하고 누군가가 때때로 사람들을 사로 잡아 경쟁이 협력을 해치지 않도록해야합니다.

평평한 팀을 갖는 문제는 프로젝트 확장으로 인해 한 두 사람이 조금 더 많은 일을하도록해야하고, 더 많은 책임을 져야한다는 것입니다. 이 시점에서 잘 정의 된 계층 구조를 작성하고 전화를 받고 사람들을 관리 할 적절한 관리자를 반드시 배치해야합니다. 동일한 그룹 내에서 프로모션이있을 때는 항상 불행한 무리가 있기 때문입니다.

내가 더 작은 Cos에서 볼 수있는 또 다른 나쁜 생각은 단지 수석 사람을 관리자로 지정하거나 경험하는 관점에 두는 것입니다. 또는 그룹에서 가장 기술적으로 능숙한 사람이 관리자의 역할로 승진합니다.

프로젝트 규모가 좋은 경우 4 명 이상의 팀이 타임 라인 초기에 반드시 관리자가 필요하다고 생각합니다. 이상적으로는 사람 관리 기술을 갖춘 기술 담당자, 특정 의사 결정을 담당하는 적절한 의사 소통이 필요합니다.

저는 민첩한 관행, 특히 Scrum을 수용하는 회사에서 일합니다. 개발팀과 경영진 모두 행복합니다. 그들은 원하는 것을 얻습니다.

1. 모든 엔지니어는 엔지니어링 관리자에게보고합니다. 엔지니어링 관리자는 매우 기술적이고 기능적인 역할이며 부서에 더 많은 비즈니스를 제공해야합니다. 이 역할은 제품 ​​소유자와 동일합니다.
2. 프로젝트 관리자는 별도의 역할을하며 스크럼 마스터와 유사하며 일반적으로 고정 기간 (12 개월에서 18 개월, 계약 연장없이)의 계약자입니다.
3. 프로젝트 관리자 (스크럼 마스터)는 비 기능 및 비 엔지니어링 활동을 전적으로 책임집니다.

개발 팀이 엔지니어링 측면에 초점을 맞추고 비즈니스 분석가 / 제품 소유자는 비즈니스 측면에 초점을 맞추기 때문에 이는 훌륭하게 작동했습니다. 프로젝트 관리자는 작업 추적,보고 및 기타 일반적인 Scrum Master 업무를 담당합니다.

중간 관리는 아웃소싱되며 중간 관리에서 최고 관리로의 성장 경로는 없습니다. 성장 기회는 개발 팀 또는 비즈니스 분석가의 역할에서 엔지니어링 관리자가 아닌 감독 역할입니다.

우리 회사는 중간 경영진이 회사에 큰 부가 가치가 아니라고 믿고 외부 컨설팅 회사에 맡기는 것이 가장 좋습니다.

주목할 가치가있는 한 가지는 그들이 사람을 관리자로 지정했는지 여부에 관계없이 여러분 중 한 명이 '실제'관리자, 아마도 가장 많은 경험 / 시간을 가진 사람이 될 가능성이 있다는 것입니다.

특히 이것이 구조 조정을 통한 생각이 아닌 비용 절감 조치 (즉, 관리자에게 비용을 지불하지 않고 개발자를 대신 고용하지 않음)로 수행됨에 따라 더 높은 경영진이 계속해서 작동 할 것 같습니다 이전에는 더 잘 아는 사람들 (즉 가장 긴 서빙)을 다루었습니다.