훌륭한 프로젝트 관리자가 프로그래밍 배경이 필요합니까? [닫은]

프로젝트 관리자가 다양한 작업을 완료하는 데 걸리는 시간을 물을 때 요청하는 경우가 있습니다. 추정치는 추측이며 추측은 틀릴 수 있습니다. 일반적으로 잘못된 요구 사항 및 문서는 잘못된 추측으로 이어집니다.

따라서 프로젝트 관리자가 X와 Y 작업이 얼마나 오래 걸리는지, 그리고 클라이언트로부터 알려지고 수집되는 것이 얼마인지에 따라 숫자를 할당하는 것이 얼마나 어려운지 추측하려고 노력하는 경우가 종종 있습니다.

내 질문은 : 좋은 프로젝트 관리자는 프로그래밍 배경이 필요합니까?

아니면 좋은 프로젝트 관리자가 전에 좋은 프로그래머 였 어야 합니까? 상관 관계가 있습니까?

IT 프로젝트 관리는 다른 유형의 프로젝트 관리와 동일하지 않습니다. 한때 IT 경험 이 없는 프로젝트 관리자에 대해 들었습니다 . 그는 프로그래머를 좌절시키고 기본적으로 그들을 두렵게했습니다.

다른 한편으로, 프로젝트 관리자가 된 프로그래머는 제어 괴물이 될 수 있으며, 프로그래머가 제대로 할 수 없다면 문제를 해결할 수 있다고 생각합니다 (유사한 상황에서 내 문제였습니다)

기술적 배경이 강한 관리자는 일반적으로 팀이 어떻게 "생각"하는지 더 잘 이해합니다. 항상 당신을 이해하는 관리자를 갖는 것이 낫지 않습니까?

아니요. 완전히 다른 두 기술입니다. 나쁜 프로젝트 관리자가 반드시 IT를 이해하지 못하는 사람 일 필요는 없으며 그 반대도 마찬가지입니다.

합리적이고 합리적이며 조직적이며 프로젝트 목표와 관련 비즈니스를 이해하고 좋은 동기 부여를하는 것이 프로그래밍에 전혀 의존하지 않습니다.

다른 모든 것은 평등하고 최신 기술 경험이 풍부한 프로젝트 관리자를 선호합니다 . 그러나 실제 프로젝트에서 풀 타임 프로젝트 관리를 졸업 한 프로그래머는 자신의 기술이 오래되고 구식이 될 가능성이 높기 때문에 기술적 인 배경이없는 것보다 낫지 않습니다.

나는 훌륭한 프로젝트 관리자와 끔찍한 사람들과 함께 일했으며, 그들의 관리 능력과 기술적 배경 사이에는 거의 상관 관계가 없다고 정직하게 말할 수 있습니다. 가장 중요한 요소는 기술적 배경이 아니라 소프트웨어 프로젝트 관리 경험이 얼마나 많은가 입니다. 첫 번째 프로젝트를 관리하는 두 사람이 있다면 프로젝트 관리를 졸업 한 프로그래머는 IT 배경이없는 프로젝트 관리자만큼 나빠질 것입니다. 둘 다 가파른 학습 과정을 거칠 것입니다.

기술적 인 배경이없는 프로젝트 관리자의 능력에 대한 논쟁은 나에게 이것을 조금 생각 나게합니다.

솔직히 대답은 '아니오'라고 생각합니다. 훌륭한 프로젝트 관리자가되기 위해 필요한 역량의 전체 수하물이 있으며 프로그래머가되는 것은 그들 중 하나가 아닙니다. 좋은 프로젝트 관리자는 프로젝트 팀에 자신이하는 일을 잘 아는 사람들이 있다는 점에서 모든 유형의 프로젝트를 관리 할 수 ​​있습니다. 프로젝트 관리자가 가진 주요 품질은 의사 소통 기술 입니다. 프로젝트 관리자의 임무는 프로젝트 작업을 조정하고 고객, 프로젝트 팀 및 기타 이해 관계자간에 커뮤니케이션을 유지하는 것입니다. 팀의 진행 상황과로드 블록을 경험하고 있는지 항상 알고 있어야하지만 문제가 무엇인지 또는 해결해야하는 이유는 팀에 다른 사람이 연루되지 않는 한 알아야합니다. 문제 해결에 도움이되도록 조정해야합니다.

추정치에 관해서는, 그것은 모든 직업의 삶의 현실입니다. 전기 기사가 배선을하는 데 얼마나 오래 걸리는지 말할 수 없다면 집을 제 시간에 지을 수 없었습니다. 벽을 예약하는 것을 언제 알 수 있습니까? 나는 많은 수의 불가침으로 인해 IT가 견적을 내리는 것이 실제로 어렵다는 것에 동의합니다. 고객은 항상 자신이 원하는 것을 알지 못하며 많은 것을 말하지 않는 경향이 있습니다. 내가했던 것은 대략 시간이 걸린다고 추정 한 다음 2를 곱한 것입니다! 그리고 좋은 프로그램 관리자는 당신의 추정치가 틀렸다고 판단 될 때 당신을 십자가에 못 박아서는 안됩니다. 일정을 재구성하고, 고객과 이야기하고, 상사들에게 더 많은 비용이들 것이라고 설명하는 두통이 생길 것입니다 ... 그것은 그들의 일의 일부입니다-다시, 대부분 필요한 것입니다.

그리고 나는 심지어 프로그래밍 기술을 갖지 않는 것이 더 낫다고 말하고 싶습니다 . 전 프로그래머는 견적을 스스로 시도하거나 두 번째로 추측 할 수 있습니다. 그리고 우리는 모두 IT 기술이 정말 빨리 구식이된다는 것을 알고 있습니다. 프로젝트 관리자가 작업 시간과 작업 시간보다 작업을 수행하는 방법에 더 관심이있는 경우 질문을 시작해야합니다. 그들은 대안을 평가하고 세부 사항을 해시하도록 요청할 수 있지만 주요 요점은 프로젝트 일정에 어떤 영향을 미칠지 아는 것입니다.

마지막으로, IT 프로젝트를 관리하는 데 IT 기술이 필요하지 않다는 말은 아닙니다. IT 직원은 일반 사람들을 위해 말하는 것을 저속하게 만들 수없는 것처럼 보이는 유형의 사람들입니다! 그들과 의사 소통 할 수있는 기본 전문 용어! 또한 기본 단계를 아는 것은 매우 중요하다 - 당신은 그것을 웹 사이트를 실행하기 전에 설치에 서버가 필요합니다. 전기 기술자가 벽을 닫기 전에 배선을 끝내야한다는 것을 모르면 건설 프로젝트를 관리 할 수 ​​없었습니다 !!

PM은 실제로 프로젝트가 수행 할 작업을 알아야하며, 기술적 배경이 필요하지만 개발하지는 않을 것입니다.

그 외에는 실제 지식 이상의 분야와 개발자를 존중해야합니다. PM은 개발자를 진지하게, 필요로하는 것, 할 수있는 것, 할 수없는 것, 할 수있는 것, 시간이 얼마나 걸리는지를 고려해야합니다. 자신이 모르는 것을 아는 PM은 매우 효과적 일 수 있습니다. 자신이 모든 답을 가지고 있다고 생각하는 PM은 나쁘다. 이것은 자신이 모든 것을 알고 있고 알지 못한다고 믿는 전직 개발자 일 수도 있고, 개발을 결코하지 않고 자신을 관리하기 위해 특별한 기술 지식이 필요하다고 생각하는 전직 개발자 일 수도 있습니다.

IT 프로젝트의 프로젝트 관리자 는 IT 배경이 필요 하다고 생각하지 않습니다 . 그러나 IT를 확실히 이해해야하며 IT 프로젝트의 작동 방식을 알아야합니다.

IT 배경은 추가적인 이점이지만, IT 배경이 부족하여 IT 프로젝트 관리자가 좋지 않은 것은 아닙니다. 또한 IT 배경 지식이 결정적인 요소가 아닙니다.

나는 두 가지 유형 모두에서 일했으며 각각 고유 한 특성과 문제가있었습니다.

IT backround를 사용하면 :
-코드가 멀티 스레드가 아니기 때문에 성능 오류라고 말할 때 이해합니다.
그러나 일부 상황에서는 "이봐, 4 줄의 코드 만 추가하면 10 일 안에 할 수 있습니다"라고 말할 수 있습니다.

IT 배경이없는 경우 :
-최종 기한을 편안하게 변경하기 위해 협상하기에 매우 편할 것입니다
.-요구 사항이없는 프로젝트의 경우 (아직도) 100 일의 대략적인 추정치를 제공하고 30 % 버퍼를 언급 할 수 있습니다.

나는 그들이 프로그래밍 배경이 필요하다고 생각합니다. 만약 그렇지 않다면, 그들은 항상 프로그래머들에게 그들의 작업을 빠르게 압박하고 실제로 그 작업이 많은 사고와 헌신을 요구할 때 몇 시간 안에 완료 될 것으로 기대할 것입니다. 이러한 자질은 프로그래머들에게 잘 알려져 있고 잘 알고 있기 때문에 프로젝트 관리자가 프로그래밍 배경을 가지고 있다면 특정 작업이 얼마나 오래 걸리는지 이해하고 부서 내에 인수가 없으므로 결국 좋은 프로젝트가 발전 할 것입니다.

@NimChimpsky 동의합니다.

그것은 어떻게 , 문제의 문제입니다 (액티브 리스닝은 훌륭한 도구입니다).

추정은 소규모 기술 작업에는 효과적이지만 계획을 위해서는 복잡한 작업을 모두 수행해야합니다. 그리고 당신은 라이벌이 아닙니다.

그들이 좋은 프로젝트 관리자가 아닌 경우 특히 도움이 될 것입니다. 좋은 프로젝트 관리자에게는 정말 중요합니다.

아니.

훌륭한 프로젝트 관리자는 건설 현장, 제조 현장 또는 소프트웨어 개발 하우스에 상관없이 팀의 요구, 선호 사항 및 기능이 무엇인지 공감하고 이해할 수있는 사람입니다.

좋은 또는 나쁜 프로젝트 관리자는 모든 종류의 배경을 가질 수 있습니다.

기술적 인 배경을 가진 나쁜 관리자는 포인터와 같은 평범하고 "쉬운"개념을 다룰 때 초보자가 겪는 어려움을 인식하지 못하는 에이스 프로그래머 일 수 있습니다.

좋은 관리자는 동료만큼 훌륭하거나 영리하지는 않지만 프로젝트 구조, 요구 사항에 대해 깊이 이해하고 신화적인 남자 달의 교훈을 마음에 들지 않았기 때문에 자신 이 나쁜 코딩 일을했으며 그의 제물을 제 시간에 끝내지 않은 것에 대해 씹 혔다.

좋은 관리자는 자신의 클라이언트에게 자신이 준 비현실적인 약속 때문에 그의 코더 친구가 주말에 그와 데이트를 할 수 없다는 것을 알게 된 소프트웨어 영업 담당자 일 수 있습니다.

두 직무에 필요한 기술이 완전히 다르기 때문에 기술 지식은 관리자로서 프로그래머의 자격을 미리 결정하지 않습니다. 그래서 안돼.

IT 경험이없는 프로젝트 관리자는 결코 가치가없는 소프트웨어 개발 프로젝트를 관리 할 수있는 것을 본 적이 없습니다. IT 경험이있는 프로젝트 관리자 는 거의 없었지만 그보다 덜 망치는 것처럼 보였습니다.

내 경험상 경영진은 효과적인 의사 소통과 의사 결정에 관한 것입니다. 이를 염두에두고 관리하는 사람들이 사용하는 공예 (적어도 핵심 개념과 용어)를 이해하는 사람은 이해력이 낮은 사람보다 관리자가되기에 더 적합하지만, 상관 관계가 없습니다. 프로그래밍 경험이없는 관리자는 프로그래밍 경험이없는 관리자와 마찬가지로 성공 및 실패를 보았습니다.

내 생각에 극단적 인 것은 나쁘다. 프로그래밍 경험이 너무 적은 사람들은 자신의 프로그래머를 맹목적으로 신뢰할 수 있습니다. 경험이 많은 사람들은 팀의 노력에 지속적으로 의문을 제기 할 수 있습니다 (소규모 관리)

개인적으로 핵심 프로그래밍 개념을 잘 알고 있지만 "핫샷"이 아니라는 것이 이상적인 관리자라고 생각합니다.

명확히.

나는 이것이 진실한 이야기를 바탕으로 한이 원인에주의해야하지만 내 고통을 설명하려고 노력할 것입니다.

저는 소프트웨어 엔지니어로 일하고 있으며 최근에 많이 일하는 프로젝트 관리자가 있습니다. 그는 기술적 인 배경이 없으며 전혀 관심이 없지만 문제는 아닙니다 (모든 사람은 자신의 관심사가 있습니다). 기술적 인 노하우를 원하지 않는다면 그것이 당신의 것보다 "기괴한"일이지만 기술적 인 수준에서 고객과 대화하는 것이 직업이라면 그가하지 않는 기술적 노하우를 갖는 것이 필수적입니다 있다.

어쨌든 그는이 서버가 작동하는 방식, 웹 페이지 작동 방식, 프로그래밍 작동 방식 등을 이해하지 못하는 사람이 있습니다. 때때로 나는 그가 아무것도 모른다는 느낌이 든다. 그래서 내가 지금해야 할 일이나 문제가 무엇인지 이해하려고 할 때마다 그가 이해하지 못하는 순간이 있습니다. 그리고 그는 "잠깐만 요. 정말 이해하지 못한다는 것을 반복 할 수 있습니까?"라고 말하는 그런 사람이 아닙니다. 아니요, 그는 전체 대화에서 아무것도 이해하지 못했음을 보여주고 싶지 않은 그런 사람입니다.

그러나 여기서 끝나지 않고 고객에게 전화하여 기본적으로 사실이 아닌 것을 말합니다. 그리고 다시 명확하게하기 위해 고객에게 전화를 걸어야합니다.

그렇기 때문에 기본적인 기술 배경과 기술 노하우를 갖는 것이 실제로 필수적이라고 말합니다. 코드를 작성할 수는 없지만 진행중인 작업과 수행해야 할 프로세스를 이해할 수 있어야합니다.

BTW 나는 그와 함께 일한 이후 더 이상 재미가 없다.

나는 네, 프로그래밍 배경이 있어야한다고 말할 것입니다. 관리자가 프로그래밍 방식에 대한 단서가 없다면 개발 및 버그 수정에 대한 비현실적인 평가로 끝납니다. 또한 그는 결정을 내리기에 충분한 기술적 문제를 이해하지 못했습니다. 팀의 프로그래머는 그에게 거짓말을했을 수도 있고, 깨닫지 못할 수도 있고, 프로그래머도 그에게 문제를 말할 수 있으며 주변에서 헛소리를하고 있다고 생각할 수도 있습니다.

기술적 인 기술은 훌륭한 관리자가 아니라 좋은 관리 기술이됩니다. 평신도가 가질 수없는 과정에 대해 감사 할 수 있기 때문에 관리자가 "트렌치"에서 시간을 보낸다면 도움이 될 수 있습니다. 그러나 제어 평신도 관리자에게는없는 제어 괴물의 종류가 될 수도 있습니다. 그들은 모든 일을 스스로하려고하거나 매우 불편한 방식으로 당신의 일을 면밀히 조사하려고 할 것입니다.

개인적으로 경험 한 최고의 관리자는 기술에 대한 단서가 없었지만 그 밑에서 일하는 사람들이 자신의 지식을 알고 팀의 충성도와 존중을 얻는 방법을 알았습니다. 나는 4 년 동안 그 밑에서 일을했고, 회사를 떠났고 그다지 좋지 않은 관리자로 교체 되었기 때문에 회사를 떠났다.

내가 가진 최악의 관리자 중 하나는 코딩 (소프트웨어 디자인이 아닌 경우)에 정통하고 많은 작업을 직접 수행하여 스크랩, 버그 수정 또는 원하지 않는 프로젝트만으로 나머지 사람들을 떠나게합니다. 자신을 위해.

혼동이있는 것 같습니다.

PM은 개발자의 보스가 아닙니다 . 개발자 팀 (팀장, 관리자)을 담당하고 채용 및 평가를 수행하는 사람이 충분히 열심히 일하고 있는지 결정해야합니다.

견적은 완벽하지 않습니다. PM은 당신이 생각하는 것보다 이것을 더 많이 이해한다고 생각합니다. 어떤 일을하는 데 시간이 얼마나 걸리는지 아무도 묻지 않을 것이라고 진지하게 생각하십니까? Everyboy는 작업이 완료된 시점을 알고 싶어하며 PM을 추적하는 작업입니다.

당신은 PM이 될 수 있습니다 : A) 프로젝트 관리 방법 이해 B) 개발 과정 이해. 이들 중 어느 것도 코딩 지식이 필요하지 않지만 도움이 될 수 있습니다.

프로그래머가 충분히 수행되고 있는지 확인하는 것은 팀 리더로 두 배가되지 않는 한 PM의 업무가 아닙니다. 작업 완료 시간에 대해 "연기 연기"가 있는지 여부를 알기 위해 관리자는 관련된 내용을 이해하면 항상 유리합니다.

특정 유형의 프로젝트를 수행 한 경험이있는 숙련 된 프로그래머와 함께 견적을 개선 할 수 있습니다. 아무도 완벽하다고 기대하지는 않지만, 시간이 지남에 따라 여러분이 가까이 와서 더 나아질 것으로 기대합니다.

나는 "여기서 일하기 위해 미쳤을 필요는 없지만 도움이된다"는 옛말을 떠올리게됩니다.

짧은 대답은 실제 코딩 경험이 좋은 소프트웨어 PM의 필수 조건은 아니지만 일반적으로 선호된다는 것입니다. 유능한 PM이되기 위해 중요한 것은 개발 프로세스 (어떤 방법론이 사용 되든)를 이해하고 개발자가 자신의 업무를 기꺼이 수행 할 수 있다는 것을 신뢰하는 것입니다. 개발 경험은 해당 프로세스에 대한 실무 지식을 제공하므로 도움이됩니다. 회사에서 사다리를 타고 올라가는 PM은 회사 문화 (및 코드베이스)를 추가로 알고 있으며 개발 팀의 다른 오랜 구성원과의 관계를 가지고 있기 때문에 대신 IPM에서 최고의 PM이 승진되는 이유 외부에서 들여 오는 회사 외부 사람이 내부 직원보다 팀을 더 잘 관리 할 수 ​​있다면 문제가 매우 잘못되었습니다.

내가 언급 한 한 가지는 PM과 개발자 팀 간의 관계입니다. 이것은 대인 관계 및 기술 수준입니다. 여기서 핵심은 의사 소통입니다. 개발자는 기술 및 대인 관계로 PM에 문제를 제기 할 수 있어야하며 PM은 문제를 설명 할 때 개발자 팀 구성원을 이해해야합니다.

귀하의 질문의 특정 특성에 대해서는 정확히 추정치입니다. 수량에 대한 교육 된 추측 (가설과는 대조적이며, 이는 미래 사건의 결과에 대한보다 일반적인 예측) 관리자는 일반적으로 최근 추정치와 실제 타임 라인을 기반으로 수학적으로 또는 직관적으로 일부 수정자를 적용합니다. 애자일은이를 추정 과정에 구축합니다. 고객은 직관적으로 요구 사항의 복잡성을 추정 한 다음 개발자가 동일한 작업을 수행 한 다음 개발자가 실제로 솔루션을 개발하고 개발하여 관리자 데이터 포인트에 요구 포인트 대 개발자 포인트의 비율, 개발자 포인트 대 사람의 비율을 계산합니다. 시간 요구 사항.

간단히 말해, 관리자는 다음 세 가지 시나리오 중 하나에서 액면가로만 견적을 가져옵니다.

• 과거의 유사한 작업에 대한 추정치는 꽤 정확했습니다.
• 그는 전달하라는 압력을 받고 있으며, 당신의 추정은 생각보다 낫습니다.
• 그는 당신을 해고 할 이유를 찾고 있습니다.

그것이 마지막 상황이라면, 직장 주위에 지옥을 꺼내야 할 다른 많은 단서가있을 것입니다.

잘 모르겠지만 관리자에게는 기술적 지식이 필요합니다. 때때로 그를 설명하는 것은 불가능합니다.