프로젝트 관리자 전방위 해석

프로젝트 관리자 전방위적으로

프로젝트 관리자의 역할 포지셔닝을 해석하는 것은 토론의 핫스팟이며, 프로젝트 관리자의 작업 목표는 무엇입니까? 프로젝트 관리자는 누구에게 책임을 져야 합니까? 프로젝트 관리자는 직장에서 어떤 권한을 받아야 합니까? 어떤 사람이 프로젝트 매니저가 되기에 적합합니까? 이제 하나씩 알아봅시다!

프로젝트 관리자는 무엇을 합니까?

프로젝트 관리자의 작업 목표는 무엇입니까? 이 질문에 답하기 위해서는 먼저 프로젝트가 무엇인지 알아야 한다. 프로젝트에 대한 정의는 매우 많은데, 프로젝트 관리 전문가인 James P.lewis (미국) 가 대표적이다. 프로젝트는 일회성 멀티 태스킹 작업이며, 명확하게 규정된 시작 및 종료 날짜, 특정 작업 범위, 예산 및 달성해야 할 특정 성능 수준을 가지고 있다. 여기에는 네 가지 요소가 포함됩니다: p? 예상 성과, c? 비용 (비용), t? 시간 진행, s? 지정된 작업 범위. 이 네 가지 요소는 상호 연관되고 상호 작용합니다. C 가 인건비만 고려하는 경우 이 4 개 항목은

C=2P+3T+4S

라는 수학 표현식을 사용하는 것이 이상적입니다. 성과, 비용 및 시간은 삼각형의 가장자리이고 범위는 삼각형의 면적입니다 (그림 1 참조). 일반적인 프로젝트 골든 삼각형 이론 (그림 2) 에서 프로젝트 관리는 R (자원), C (비용), T (시간/일정), S (특성/범위) 를 집중적으로 고려합니다. 이에 비해 이곳의 정의는 P (성과) 를 중점적으로 제시했다. 소프트웨어 회사들이 ISO 9 인증과 CMM 인증을 잇달아 진행한 환경에서는 성과를 중시하는 의미도 자명하다.

프로젝트의 의미를 이해했습니다. 프로젝트 관리란 무엇입니까? 프로젝트 관리는 예정된 목표를 달성하기 위해 작업과 자원을 계획, 구성 및 관리하는 프로세스이며 일반적으로 시간, 자원 또는 비용 제약을 충족해야 합니다. 즉, 프로젝트 관리는 프로젝트와 밀접한 관련이 있는 성과 (P), 시간 진행 (T), 비용 (C), 범위 (S) 를 관리하는 프로세스입니다. < P > 결론적으로 프로젝트 관리자는 특정 방법과 도구를 사용하여 프로젝트에 대한 실제 프로젝트 관리를 수행하는 사람입니다. 간단히 말해서, 프로젝트 관리자는 프로젝트의 실제 관리자이다. 그의 목표는 프로젝트의 PTCS 를 성공적으로 관리하는 것이다.

는 누구에게 책임을 집니까?

프로젝트 관리자는 누구에게 책임을 져야 합니까? 어떤 사람들은 회사의 직접 관리에 속하기 때문에 해당 회사에 책임을 져야 한다고 말합니다. 어떤 사람들은 프로젝트가 고객에게 서비스를 제공하기 때문에 고객에게 책임을 져야 한다고 말합니다. 프로젝트의 전반적인 이익에 대한 책임을 져야 한다는 얘기도 있다. 프로젝트가 모든 측면을 포괄하고, 프로젝트 매니저가 그 쪽에 편중하는 것은 옳지 않기 때문이다. (윌리엄 셰익스피어, 윈스턴, 프로젝트명언) 어느 말이 더 정확합니까? 이것은 먼저 프로젝트 관계자라는 개념을 분명히 해야 한다. < P > 프로젝트 관계자는 프로젝트 위험 주도자라고도 할 수 있으며 프로젝트에 기득권이 있거나 프로젝트와 직접적인 관계가 있는 모든 법인과 개인입니다. 여기에는 프로젝트 기여자, 프로젝트 관리자, 공급업체, 프로젝트 투자자, 고객 등이 포함됩니다. 이 사람들은 프로젝트의 진전을 직접 추진하거나, 프로젝트에 각종 원조를 제공하거나, 결국 프로젝트에 대한 평가 검수를 한다. 프로젝트 매니저는 업무 목표를 달성하고 프로젝트를 완성해야 하는데, 이들의 적극적인 참여는 근본적인 보증이다. 프로젝트 관리자가 실제로 통제하는 프로젝트의 권한은 해당 회사가 직접 부여한 것이지만 결국 이러한 프로젝트 관계자로부터 나온 것이라고 할 수 있습니다. < P > 는 프로젝트 관리자가 소재한 회사에 소속되어 있지만 회사의 임명 관리 프로젝트를 받을 때 회사의 이익에 대해 책임을 져야 한다는 것을 이해할 수 있다. 그러나 관리하는 프로젝트 자체의 관점에서 볼 때, 프로젝트는 다방면의 이익을 다루므로 다방면 * * * 승리의 목표를 달성해야 한다. 프로젝트 관리자는 회사의 이익을 보장하면서 프로젝트 관계자의 다른 모든 당사자의 이익을 보장해야 합니다. 그렇지 않으면, 프로젝트를 추진하는 과정에서 다른 당사자들의 압력과 방해를 받아 프로젝트가 배회하거나 실패로 나아가게 될 수밖에 없다. (윌리엄 셰익스피어, 오셀로, 실패명언) < P > 프로젝트 관리자는 자신의 회사를 위임하는 것만이 아니라는 것을 알 수 있습니까? 보스? 책임을 지고 다른 프로젝트 관계자에게도 책임을 져야 한다. 즉, 프로젝트 관리자는 모든 프로젝트 관계자를 대표하는 종합 이익에 대해 책임을 져야 합니다. < P > 실제 프로젝트 관계자들은 각자의 이익에만 초점을 맞추고 있습니다. 예를 들어, 회사 경영진, 프로젝트 투자자는 최소 비용, 최대 이윤에 초점을 맞추고 있습니다. 고객은 최저 가격으로 프로젝트 성과를 얻는 데 주력하고 있습니다. 프로젝트 구성원은 수용 가능한 시간과 비용 범위 내에서 프로젝트를 완료하여 정신적 만족과 경제적 수익을 얻는 데 주력하고 있습니다. 프로젝트 관리자는 이러한 모순된 이익에 대해 어떻게 책임을 집니까? < P > 이 질문에 답하려면 프로젝트 관리 목표의 정량화를 탐구해야 한다. 일반적으로 프로젝트 결정의 시작을 위한 중요한 전제 조건 중 하나는 프로젝트 관계자가 프로젝트의 양적 목표에 대해 완전히 일치된 의견을 얻는 것입니다. 여기에 관련된 정량화 목표는 네 가지 측면, 즉 정량화된 프로젝트 결과물 목록 (S) 으로 구성됩니다. 제출 프로젝트 결과물 목록이 충족해야 하는 품질 지침 (p); 프로젝트 최종 완료 및 중간 이정표의 기한 결정 (t); 프로젝트가 초과할 수 없는 비용 제한. < P > 모든 프로젝트 관계자는 정량화된 목표를 바탕으로 자신의 이익 최종선을 형성해야 합니다. 이렇게 하여 프로젝트 관리자는 정량화된 프로젝트 목표를 달성하고 프로젝트 종합 이익에 대한 책임을 실현했습니다. 물론, 프로젝트 관리자는 소속 기업에 의해 임명됩니다. 기업 발전의 여러 단계로 인해 단기 및 장기 이익에 대한 기업의 초점이 다르기 때문에 기업의 행동은 프로젝트 관리자의 실제 관리에 영향을 미칠 수 있습니다. 프로젝트 관리자는 이에 대해 적절한 균형을 이루고, 프로젝트 관계자들의 이익을 보호하고, 성공적인 관리를 달성해야 합니다.

프로젝트 관리자의 권한은 무엇입니까?

프로젝트 관리자는 어떤 권한을 받아야 합니까? 책임과 권력 대등성의 원칙에 따라 프로젝트 관리자의 승인에 대해 이야기하는 것은 당연히 프로젝트 관리자의 구체적인 책임을 먼저 고려해야 한다. 이제 소프트웨어 기업들은 기본적으로 프로젝트 관리자 책임제를 채택하고 있다. 기업마다 프로젝트의 책임 규정에 중점을 두고 있지만 일반적으로 다음과 같은 기본 내용이 포함되어 있습니다. < P > 정량화된 프로젝트 목표 완료

효과적인 계획 관리 수행

다양한 프로젝트 위험을 미리 피하십시오. 만약 위험이 이미 피할 수 없다면, 제때에 위험을 최소화해야 한다.

프로젝트 당사자 간의 관계 조정

프로젝트 팀의 상대적 안정성을 유지하십시오. 시험 대정리 < P > 이러한 요구 사항으로 인해 프로젝트 관리자는 실제 업무에서 < P > 의 어느 정도의 재정권을 부여받아야 한다. < P > 흔한 경우는 프로젝트 매니저가 기업 지도자들에게 어깨를 두드리며 말하는 것이다. 우리는 당신을 믿습니다. 그래서 당신을 프로젝트 책임 자리에 두었습니다. 그러나 신중을 기하기 위해서는 프로젝트 경비를 지출할 때 반드시 비준을 받아야 한다. -응? 실제로, 프로젝트 매니저는 경제적으로 충분한 직접적인 결정권을 얻지 못했기 때문에, 프로젝트가 전개될 때 항상 말을 느끼는가? 무게? , 도처에 제약이 있어 손발을 펼칠 수 없다.

그 프로젝트 매니저는 어떤 재정권을 부여받아야 합니까? 필자는 다음과 같은 기본 요구 사항을 충족해야 한다고 생각한다.

(1) 프로젝트 관리자는 적시에 개발 팀을 장려할 수 있도록 프로젝트 보너스의 일부를 파악해야 한다.

(2) 프로젝트 관리자는 개발 도구, 프로젝트 리소스 (기술 교육, 소프트웨어 엔지니어링 교육 등 다양한 서비스 포함), 사무용품을 구매할 권리가 있어야 합니다. 특히 프로젝트 관리자는 소프트웨어 개발 도구, 구성이 필요한 서버 개발, 인쇄 장치 등과 같은 프로젝트의 중요한 자원 조달 과정에서 어떤 성능을 선택해야 하는지 알고 있으며 향후 장비의 구체적인 사용을 책임져야 한다는 점을 특별히 지적해야 합니다. (윌리엄 셰익스피어, Northern Exposure (미국 TV 드라마), Northern Exposure (미국 TV 드라마), 예술명언)

(3) 프로젝트 관리자는 인력 조정 및 관리를 위해 일정 금액의 활동 비용을 직접 파악할 수 있습니다.

일정한 인사 관리권.

? 사람? 프로젝트 전체에서 가장 활발하고 가장 큰 영향을 미치는 요소입니다. 프로젝트 구성원의 적극적인 참여와 노력 없이 프로젝트를 완성하는 것은 터무니없는 일이다. 프로젝트 관리자는 직접적인 인사관리권이 없다면 실제로 프로젝트 인적자원에 대한 통제력을 크게 상실한 것은 프로젝트 완성에 불리하다. 그렇다면 프로젝트 관리자에게 어떤 인사관리권을 부여해야 할까요? 일반적으로

(1) 프로젝트 관리자가 프로젝트 멤버의 장비에 직접 참여해야 합니다. 프로젝트부터 프로젝트 관리자는 프로젝트 멤버의 선택에 참여해야 합니다. 그는 모든 후보들의 업무 배경, 지식 기술, 성격 특성 등에 대해 자신의 견해를 제시해야 한다. 조건이 있을 때, 그는 또한 각 후보자와 면담을 해야 한다. 그리고 최종 프로젝트 멤버 명단은 프로젝트 매니저의 동의를 받아야 한다.

(2) 모든 프로젝트 구성원의 작업은 프로젝트 관리자 또는 권한을 가진 사람에게 직접 보고해야 합니다. 프로젝트 팀이 어떤 방식으로 인력을 구성하든 프로젝트 관리자는 업무 평가의 핵심이어야 합니다. 프로젝트 관리자는 직원의 업무에 따라 직접 보상과 처벌을 받을 수 있다. 직원에 대한 그의 직무 평가는 직업 발전에 직접적인 영향을 미쳤다. 그리고 이런 영향은 프로젝트의 끝과 함께 끝나서는 안 된다.

(3) 프로젝트 관리자는 직원을 이전 할 수 있습니다. 직원들에게 동기를 부여하고 가장 큰 힘을 발휘하는 것은 프로젝트 관리자의 인적 자원 관리의 가장 중요한 목표입니다. 그러나 직원을 프로젝트에서 이전하는 것이 여전히 프로젝트 관리자의 손에 필수적이라는 것을 인정해야 합니까? 에이스? , 프로젝트 팀이 적시에 신진 대사를 수행 할 수 있도록하는 보증입니다.

기타 권한.

필요한 재정권과 인사권 외에 프로젝트의 실제 상황에 따라 프로젝트 관리자에게 다른 권한을 부여해야 한다. 예를 들어, 프로젝트 관리자에게 고객과 직접 의사 소통할 수 있는 권한을 부여하는 것을 고려해 볼 수 있습니다. 이는 고객이 프로젝트의 진행 상황을 적시에 이해하고 불필요한 오해를 줄이는 데 도움이 될 뿐만 아니라 또한 이러한 의사 소통은 프로젝트 관리자가 제품 수요를 파악하는 데 매우 유용하며, 제품이 고객에게 더 나은 가치를 창출할 수 있도록 합니다.

여기서는 많은 프로젝트 관리자가 받아야 할 권한에 대해 이야기하고 있습니다. 그러나 프로젝트 매니저로서 성공적인 관리를 위해서는 권력 사용이 매우 신중해야 한다는 점을 스스로 이해해야 한다. 프로젝트 관리자는 일반적으로 영향력과 강제력 (권력) 의 두 가지 힘을 사용하여 관리할 수 있습니다. 영향력은 직원들에게 어떤 일을 하는 것이 옳다고 느끼게 하고, 마땅히 해야 한다. 강제력 (권력) 은 직원들에게 어떤 일을 할 수 있는 선택의 여지가 없다고 느끼게 하고, 반드시 해야 한다. 권력의 사용이 직원들에게 미치는 영향은 좀 더 강해야 하는데, 얻을 수 있습니까? 즉각적인 효과? 효과를 볼 수 있습니다. 그러나 이는 직원들에게 역반심리를 일으키기 쉬우며, 직원 혁신의 적극성을 억누르기 쉽다. 프로젝트 관리자의 영향력과 권력 사용에 관한 문제는 이 글의 중점이 아니며, 여기서 더 이상 군말을 하지 않는다.

프로젝트 관리자가 되기에 가장 적합한 사람은 누구입니까? < P > 누군가가 말할까? 배우고 우수한 선비? , 최고의 기술, 누가 매니저가 될 수 있습니다. 과거 (소프트웨어 워크샵 시대) 에도 많은 기업들이 직원을 승진시키기 위해 왔습니다. 기술자가 프로그래밍이 우수하다면 시스템 분석/디자이너로 승진하는 것을 고려해 볼 수 있습니다. 시스템 분석/설계 능력이 우수하다면 프로젝트 관리자로 승진하는 것을 고려해 보십시오. 만약 비교적 강한 프로젝트 관리 능력을 가지고 있다면, 부서 관리자로 승진하는 것을 고려해 볼 수 있다. 기술 부서를 잘 관리할 수 있다면 적절한 경우 기술 부사장으로 승진할 수 있습니까?

기술에서 관리에 이르기까지 소프트웨어 영웅? 이상적인 프로그래머에게 있어서, 확실히 자신을 끊임없이 증명하고, 끊임없이 자신을 뛰어넘는 발전의 길이다. 하지만, 소프트웨어 기업들과 함께? 워크샵? 개발 대상? 공장? , 이런 생각을 계속 따라가면 결국 프로젝트 진도가 심각하게 뒤처져 프로젝트 실패까지 초래할 수 있다. 그 중 가장 큰 원인은 기술 부족이다.

원인? 소프트웨어 공장? 중인원. 분업은 점점 더 가늘어지고 전문화되고 있다. 소프트웨어 엔지니어에 대한 요구는 프로젝트 개발에 필요한 다양한 소프트웨어 기술을 습득하는 반면, 프로젝트 관리자에 대한 요구는 프로젝트 관리에 필요한 다양한 기술을 습득하고 다른 사람을 이끄는 성격 특성을 갖추고 있다. 아무리 우수한 소프트웨어 엔지니어라도 프로젝트 매니저라는 직위를 쉽게 감당할 수 있는 것은 아니라고 할 수 있다.

그렇다면 누가 프로젝트 매니저가 되기에 가장 적합합니까? 필자는 다음과 같은 기본 요구 사항을 충족해야 한다고 생각한다. < P > 리더십 의식을 갖추고 있다. < P > 리더쉽이란 관리자가 자신의 업무 임무를 완수하기 위해 자신의 재능에 크게 의존해야 한다는 것을 깨닫는 것을 말한다. 프로젝트 관리자는 전체 프로젝트의 가장 직접적인 관리자로서 이런 의식을 가져야 한다. < P > 물론, 다른 사람을 이끄는 방법은 다양하다. 예를 들어 영향력을 사용하는 경향이 있고, 관리자들이 잠정적인 침묵 속에서 자신을 따르게 하는 경향이 있다. 어떤 사람들은 권력을 사용하는 경향이 있고, 관리자들이 있게 하는 경향이 있습니까? 권위? 자신을 따르라고 요구하다.

의사 소통 의식을 갖추다.

IT 프로젝트 관리는 사람에 대한 관리라고 할 수 있습니다. 사람들과 잘 어울리지 못하고, 항상 부하들이 자신과 맞서게 하는 프로젝트 매니저는 일을 전개하기 어렵다.

타인을 존중하다.

누구를 상대하든 (회사 지도자, 투자자, 고객, 프로젝트 직원? ), 프로젝트 관리자는 다른 사람들을 존중하는 법을 알아야합니다. 표면적으로 예쁜 말을 하는 것이 아니라, 프로젝트 매니저가 타인의 투입을 진정으로 존중하고, 타인의 노동을 존중하고, 상대방의 입장에서 문제를 고려하고, 일을 해결할 수 있도록 하는 것이다. -응? 남의 일을 도모하고, 사람의 위기를 이해하는가? ,? 자기가 원하지 않는 것을 남에게 행하지 마라? , 이러한 고대 격언은 여전히 ​​프로젝트 관리자가 준수 할 가치가 있습니다.

팀 구성 이해.

진행 중입니까? 팀 작전? 오늘날 프로젝트 관리자의 팀 구성 능력은 매우 중요합니다. 프로젝트 관리자는 팀의 조직 구조를 구축하고 팀을 이끌고 동기를 부여하는 방법을 알아야 합니다.

일부 프로그래밍 기술을 습득하십시오. < P > 프로젝트 관리자가 프로젝트에 관련된 프로그래밍 기술에 대해 어느 정도 파악해야 하는지에 대한 업계의 논란 중 하나였습니다. 먼저 두 가지 견해를 분석해 보겠습니다.

(1) 프로젝트 관리자는 반드시 기술에 정통하고 프로그래밍에 능통해야 합니다. < P > 분석: 이 견해는 프로젝트 관리자에 대한 기술적 요구 사항이 좀 높은 것 같습니다. 어떤 소프트웨어 프로젝트 관리 방법 (폭포법, 원형법, 반복 진화법) 을 채택해도? ), 특정 단계의 경우 프로젝트는 항상 수명 주기 관리 프로세스: 실현가능성 논증? 프로젝트? 수요 분석? 시스템 설계? 인코딩? 테스트? 릴리즈 요약.

프로젝트 관리자는 프로젝트의 실제 관리자로서 프로젝트와 관련된 다양한 요소 (PTCS) 를 충분히 고려하고, 프로젝트 수명 주기의 각 프로세스에 대한 상세 계획을 개발하고, 다양한 단계에 따라 관계자를 효과적으로 관리하고, 프로젝트 진행을 성공적으로 추진하는 것이 가장 중요한 임무입니다. < P > 이는 프로젝트 관리자의 업무 중심이 기술 연구가 아닌 다양한 자원에 대한 계획, 프로젝트 구성원에 대한 인센티브임을 분명히 보여줍니다. 따라서 프로젝트 관리자는 프로그래밍 기술에 정통할 필요가 없습니다.

(2) 프로젝트 관리자가 기술, 특히 개발을 방해하는 기술적 세부 사항에 익숙하지 않으면 납득하기 어려울 것입니다. <