당신은 동시에 관리자와 프로그래머가 될 수 있습니까? [닫은]

자신이 프로그래밍 인력의 일부인 동안 다른 프로그래머 관리

적어도 내가 일한 회사에서는 매우 일반적인 계획입니다.

동시에 두 가지를 모두 수행하면 훌륭한 프로그래머 나 훌륭한 관리자가 될 수 있습니까?

나는 매우 다른 기술, 환경, 집중력, 조직 등을 요구하는 두 가지 매우 다른 역할을 해야하는 개인의 효과에 의문을 제기하고 있습니다.

업데이트 : 내 질문에는 특히 팀 관리가 아닌 회사 관리 (내 경우)가 포함됩니다. 그러나 나는 물론 둘 다에 관심이 있습니다.

수행해야 할 프로그래밍의 양과 유형과 수행해야하는 관리 업무의 양과 유형에 따라 다릅니다.

관리자가된다는 것은 많은 방해, 압정의 변화 및 회의와 같은 것들을 의미합니다.

프로그래밍이 긴급하지 않은 작은 작업으로 "제한적"인 경우 관리 업무 주위에 이들을 맞출 수 있습니다. 프로그래밍 작업에 상당한 양의 "품질"시간을 소비해야하는 경우 관리 책임으로 인해 해당 시간을 확보 할 수 없습니다.

팀 규모가 크거나 복잡한 경우 하나 또는 두 개의 제품 / 프로젝트 전용 소규모 팀인 경우보다 관리에 더 많은 시간을 소비해야합니다. 소규모 작업에서도 의미있는 프로그래밍을 할 시간이 없다는 것을 알게 될 것입니다 .

이전 작업에서이 역할을 수행했으며 프로그래밍 작업을 작게 유지했기 때문에 저에게 효과적이었습니다. 실제로 우리에게 유리하게 작용했습니다.

먼저, 들어오는 모든 요청을 평가할 수 있고 요청이 작을 경우 내 대기열에 추가하거나 (항상 짧았 음) 작업 시간에 대해보다 정확한 시간 척도로 클라이언트 (이 경우 다른 관리자)에게 다시 연락 할 수 있습니다. 완료하십시오.

둘째, 팀의 개발자가 사소한 버그를 수정하거나 약간의 개선을 위해 현재 작업을 중단하지 않고 있음을 의미했습니다.

셋째, 긴급한 문제가 상당히 빠르게 해결되어 고객이 만족했습니다.

코드 팀과 연락을 유지하여 팀에 항상 관여하지 않고도 팀과 문제 및 관리자 및 고객과 시간 척도에 대해 의미있는 대화를 나눌 수있었습니다.

한 프로그래머가 우리의 관리자이기도 한 개발자 팀의 일원이었습니다. 이로 인해 생산성과 유사한 모든 것이 무너졌습니다. 요컨대, 모든 결정은 그 사람에 의해 이루어졌으며 그는 완벽한 마이크로 매니저였습니다. 그가 동의하지 않은 아이디어와 제안은 격추되거나 무시되었다. 이것은 결국 모든 창의성과 동기를 죽였습니다.

따라서 개발자 팀의 누군가를 "더 높은"위치에 두는 것은 나쁜 생각이라고 생각합니다. 필자의 경우, 그 사람은 명령 및 제어 관리자 였지만 훌륭한 관리자조차도 의도하지 않게 다른 개발자에게 영향을 미쳐 결국 성능이 저하됩니다. 최소한 팀은 그에게보고하고 있습니다.

예
, 동시에 프로그래머 및 관리자 인 관리자 몇 명을 보았습니다.이 직원들과 함께 일하는 것이 훌륭하다고 믿습니다.
관리자와 프로그래머가되면 관리자가 앞을 내다 볼 수있을뿐만 아니라 부하 직원이 최선을 다하도록 동기를 부여 할 수 있습니다.
대부분의 직원은 자신의 관리자에 대해 관리자가 가치가 없다고 주장하지만 관리자뿐만 아니라 코드를 작성하는 관리자는 항상 최상의 결과를 제공합니다.
내가 언급 한 두 관리자는 프로그래밍이 다른 사람들을 도울뿐 아니라 거의 버그가없는 응용 프로그램을 만들어내는 열정이었습니다.

저는 여러 회사, 프로젝트 및 팀과 함께 수년간 프로그래밍 프로젝트 관리자였습니다.

프로젝트 관리 및 프로그래밍은 매우 다른 종류의 작업 / 역할이므로, "우수한"수준에서 동시에 두 가지를 모두 수행 할 수는 없다고 주장합니다. 그것은 타협입니다-없음의 주인, 모든 거래의 잭, 일종의 것.

저에게 가장 큰 어려움은 관리자와 프로그래머 모드 사이의 상황 전환입니다. 그들은 뇌의 다른 부분 (또는 무언가)에 관여하는 것 같습니다. 하루 프로그래밍, 하루 관리는 잘 할 수 있지만 그 역할을 끊임없이 전환하는 것은 어렵습니다.

두 시나리오를 모두 보았습니다. {시간의 일부} 코딩을하고있는 개발자 관리자와 코딩을 전혀하지 않는 개발자 관리자.

문제는 당신이 얻을 더 많은 수석이다, 더 많은 가능성이 좀 더 지불하려는, 그리고에서 것을 얻을 수있는 유일한 방법 많은 장소 관리로 이동합니다. (물론 전부는 아니지만 많은 장소). 따라서 이것은 실제로 관리자가 될 준비가되어 있지 않은 사람들이 그 상황에 빠질 수 있습니다.

(물론 Dev 관리자와는 달리 Dev, Dev 리드를 통해 Architect 등의 위치로 이동할 수있는 회사가 있습니다)

당신 은 사람들이 관리하는 데 쓸모없고 코드에서 멀어 질 수 있습니다. 그래서 당신은 나쁜 관리자가되고, 당신이 즐기는 일을 덜하고 있고 아마도 개발에 들어갔을 것입니다!

저에게는 관리자가되기 위해 코딩 작업을 진행해야하지만 기술에 대해 항상 최신 상태를 유지하여 문제에 대해 최소한 일관성있게 이야기 할 수 있습니다.

그것이 일어날 때 나는이 정확한 이유로 프리랜서를 시작했다. 나는 사람들 관리에 관심이 없으며, 특히 잘하지 않을 것이라고 생각하며, 코드를 많이 작성하지는 않을 것입니다.

할 수는 있지만 함정이 가득합니다. 그룹 규모와 중단 수준은 큰 역할을하지만 가장 큰 위험은 관리자가 기술 리더가되는 것입니다. 충분한 시간 / 노력이 없으면 의견을 정당화하기에 너무 많은 양의 의견은 잘못된 결정으로 이어질 수 있습니다. 그리고 방향에 대한 토론은 관리자와 팀의 나머지 부분 사이의 수준이 아닙니다.

이 경로를 고려하는 사람들에게는 몇 가지 조언이 있습니다.

• 아키텍처 역할을 벗어나고 그룹의 리드를 식별하십시오.

• 중요한 경로 항목에 대해서는 작업하지 마십시오. 상사가 당신을 산만하게하는 '중요한 것들'을 발견했을 때 신속하게 버릴 수있는 버그를 수정하고 프로토 타입이나 다른 아이템에 대해 작업하십시오.

• 팀, 프로세스, 사기 및 성공적인 팀을 구성하는 데 필요한 기타 측면을 방어하고 홍보하여 ​​전반적인 효율성에 집중하고 집중하십시오. 당신의 목표는 단순히 성공적인 프로젝트 그 이상일 것입니다 (상사, PM 또는 다른 사람들의 말에 관계없이).

• 팀의 성장을 돕습니다 :보다 독립적이고, 자기 조직적이며, 기술에 능숙하며, 높은 수준의 인식이됩니다.

• 여러면에서 당신은 팀과 외부 세계 사이의 다리입니다. 초점의 상당 부분이 팀 외부에 있어야합니다.

질문에 대답하기 위해 할 수 있습니다. 아니요. 집안의 기술 측면에서 너무나 많은 새로운 관리자가 쉽지는 않습니다. 훌륭한 리더 였을 수도 있지만 성공적인 관리자로 전환 할 수는 없습니다.

좋은 관리자가 될 수 있습니다. 단호하고 일관성있는 한 문제는 없습니다.

직원이 관리자와 팀 동료와 관련된 문제를 제기하라는 지시를 받았으며 관리자도 팀 동료 인 경우 끈적 끈적해질 수 있습니다. 모든 피드백을 객관적으로보고 때때로 잘못 될 수 있음을 인식해야합니다. 또한 피드백을위한 일종의 익명 수단을 제공해야합니다.

신생 기업에서 이것을 보는 것이 매우 일반적입니다.

아니에요

두 작업 모두 집중, 에너지 및 헌신이 필요합니다. 두 가지를 동시에 수행하는 것은 매우 어렵습니다. 팀장의 책임을 맡아야했을 때 프로그래밍에 소비 한 시간 (및 그에 따라 프로그래밍 관련 작업량)이 줄었습니다.

팀 리더 역할에서 관리 역할을 수행하고 한 달 이내에 코딩을 완전히 중단 한 다른 동료를 알고 있습니다 (두 가지 모두 시도했지만).

또한 관리자가 되라는 요청을받은 건축가도 알고 있습니다. 그는 또한 관리 책임을 맡은 후 한 달 안에 코딩을 중단했습니다. 8 개월 후 동일한 건축가가 중요한 현장 문제로 인해 코딩으로 돌아와야했습니다. 그는 버그 수정에 크게 기여했지만 한 달 안에 관리 책임을 맡을 대체 관리자를 찾아야했습니다.

제한된 경험에서 나는 완전한 프로그래머처럼 다른 프로그래머와 코드를 관리하는 사람을 찾지 못했습니다.

제 생각에는 대부분의 시나리오에서 가능하지만 좋은 배치는 아닙니다. 특정 스킬 셋이 아니거나 원하는 직책이 아니더라도 개발자로서 능숙한 사람들이 어떻게인지되고 팀 관리 역할을하는지에 대한 수많은 기사가 있습니다. 그들은 "업무"가 프로그래밍을하는 것으로보고, 보고서를 작성하지 않고 회의에 참석하기 때문에 "관리"에 집중하는 데 어려움을 겪고 있습니다.

Spolsky는 개발자 추상화 계층 에 대한 그의 기사에서 다음과 같이 썼습니다 .

"소프트웨어 회사의 경우, 관리의 최우선 과제는 프로그래머를위한 추상화를 만들어야합니다."

이 기사에서 (의견이 있지만 잘 추론 된) 기사에서 관리자의 역할은 코드 나 소프트웨어 개발에 관여하는 것이 아니라 그것을 생산하는 사람들이 전적으로 집중할 수있는 환경을 만드는 것입니다.

내 전 상사가 시도했다. 그의 관리 역할에서 너무 많은 interuptions가 있었다.

그는 여전히 내가 아는 최고의 개발자 중 하나입니다.

물론 가능하지만 그렇다고해서 쉬운 것은 아닙니다. 좋은 개발자가되기 위해서는 어떤 사람이 필요합니다. 어떤 사람은 좋은 관리자가되고 어떤 사람은 둘 다가됩니다. 그 사람 (또는 그 사람)을 찾을 수 있다면 확실한 이점이 있습니다. 프로그래머의 1 급 또는 2 급 관리자는 직원들이 매일하고하는 일을 진정으로 이해해야합니다. 개발자가 아니고 계속 개발하지 않고 연락을 유지하거나 최신 상태로 유지하기 어려운 경우 수행하기가 어렵습니다.

내가 가진 최고의 관리자 (~ 25 년 동안 사업을 해왔음)는 활발한 개발자, 관리자 및 회사의 반 소유자 (약 40 emps)였습니다. 그는 특별했지만이 질문에 분명히 성공했습니다.

확실히 아니야 !!

시도해 볼 수는 있지만 무엇보다 많은 것을 관리하게됩니다. 문제는 사람들이 5 분마다 전화를 걸거나 1 시간마다 "상태"회의를 시도 할 때 코드를 작성할 수 없다는 것입니다. 말도 안 돼요 .. 지금하고 있어요.이 실로 넘어 졌어요.

기술 회사의 관리자는 .. 아니요. 코딩 방법을 알아야합니다. 당신은 고객의 문제를 추정하거나 이해할 수 없습니다. 코딩과 관리는 두 가지 유형의 사람들입니다. 한쪽은 괴짜이며 사람들과 어색합니다 (얼굴, 내가 말하는 것을 알고있는 괴짜). 다른 쪽은 사람들과 잘합니다. 당신은 측면을 선택해야합니다. 두 가지를 모두 수행하면 코딩을 할 수 없습니다. 아내가 방해받지 않으면 코딩을 좋아하고 24/7 할 수 있다면 관리를 피하십시오. 필요한 경우 급여를 삭감하십시오. 나는이 일을하려고하지만 경영진의 삶을 더 편하게하기 때문에 상사들이 이것을 좋아할 것이라고 생각하지 않는다. 그들이 동의하지 않으면 프리 랜싱으로 돌아 가야합니다. 왜냐하면 행복과 당신이 사랑하는 것을하는 것이 돈과 그것이 사는 환상보다 훨씬 중요하기 때문입니다.

귀하의 노력과 함께 최선의 소원 과이 게시물을 계속하시기 바랍니다. 당신들은 멋진데.

이 사이트의 "프로그램 중심 경력 경로 부족"섹션을 읽으십시오. 아주 좋은 것들과 매우 관련성 : http://c2.com/cgi/wiki?ProgrammingIsNotFun

"모든 사람의 잭은 누구의 주인이 아니다"라는 말이 떠오름에도 불구하고 사람은 훌륭한 관리자와 좋은 프로그래밍 기술을 모두 가질 수 있습니다.

그러나 두 기능을 동시에 결합하면 두 작업을 절반 만 수행하는 경향이 있습니다. 그것은 수행해야 할 관리의 양에 달려 있지만 필연적으로 완전히 다른 성격의 두 가지 작업을 다루고 있습니다. 필자는 코딩 작업에서 수행해야 할 관리 작업 (제 경우에는 코스 관리 및 보고서 작성)이 훨씬 적습니다.

또 다른 함정은 그룹을 관리하고 있지만 직접 참여하는 당사자라는 것입니다. 때로 돈을 지불하고 때로는 큰 문제를 일으킬 수 있습니다. 다른 프로그래머가 귀하의 작업에 동의하지 않는 경우, 귀하가 관리자라는 사실이 완전히 공개되지 않도록 할 수 있습니다.

그런 다음 관리하는 동일한 프로젝트에서 코드를 작성할 때 코드 자체에 약간의 느낌이 들기 때문에 프로그래밍 비트가 실제로 관리 비트를 도울 수 있습니다. 모든 것은 관리해야 할 사항, 필요한 시간 및 작업중인 코드와 관련하여 유지해야하는 양에 따라 다릅니다.

따라서 명확한 대답은 없지만 두 가지를 너무 많이 섞지 않는 경향이 있습니다. 내 2 센트

글쎄, 소프트웨어 프로젝트 관리자는 분명히 코더 자체가되어야한다는 것을 읽었습니다.

관리자는 한 가지 이유로 관리자라고 생각합니다. 나는 이것을 엄지 손가락의 법칙으로 삼을 것이다. 어떤 것들은 양날의 칼일 수있다.

나는 그것이 작동하는 경우를 알고 있습니다. 그 사람은 일종의 일을 잘하는 사람이므로 매니저로 풀 타임으로 일하고 프로그래머로 거의 풀 타임으로 일합니다.

정상적인 근무 시간을 고려할 때 그러한 이중 역할이 좋은 생각이라고 생각하지 않습니다. 관리 프로그래머 (또는 프로그래밍 관리자)는 프로그래머가 프로그래밍을 수행하는 대신 항상 많은 프로그래밍 작업을 수행하려고합니다. 이러한 변명은 항상 "설명하는 것보다 설명하는 데 더 오래 걸립니다"가 있지만 장기적으로 볼 때 프로그래머가 수행하는 50 %의 프로그래머 작업이 누락되어 다른 프로그래머의 효율성이 떨어집니다.