프로젝트 관리자는 특정 프로젝트의 관리자이며, 직장에서 지속적으로 리더십을 향상시킵니다. 동시에, 이 직업은 권리와 책임이 있는 직업이다. 이들은 주로 프로젝트에 대한 배경 조사, 프로젝트 관련 자료 수집 및 정리, 수요 계획, 프로젝트 조사 보고서 작성 및 정보 요약, 프로젝트 구성 요소 또는 모듈의 전체 시스템 설계, 프로젝트 관련 단위 및 관련 기술 전문가에게 연락, 프로젝트 타당성 조사 보고서 개발, 프로젝트 신고 자료 개발 및 신고, 프로젝트 팀 구성 등의 작업을 수행합니다. 다음은 내가 너를 위해 정리한 것이다. 독서를 환영합니다!
IT 프로젝트 관리자는 어떻게 해야 합니까?
나는 이런 프로젝트 매니저를 자주 보았는데, 온종일 바쁘고, 전화가 끊임없이 울리고, 한 시간 안에 수십 개의 지시를 내리는데, 마치 그가 이끄는 팀이 하루 종일 그를 떠날 수 없는 것 같다. 그런 다음 그는 "나는 바쁘다" 또는 "나는 피곤하다", "나는 일손을 늘려야 한다" 고 말할 것이다. 이런 프로젝트 매니저는 세세한 부분마다 항상 스스로에게 물어봐야 한다. 누군가가 그의 지휘 아래 있어도 그가 피곤하지 않을 수 있다고 생각하니?
심지어 이런 사건도 있다. R&D 부서의 관리자는 프로젝트 소프트웨어 코딩에 직접 참여합니다. 하나 또는 두 개의 프로젝트만 있는 경우 괜찮을 수 있습니다. 만약 당신이 10 여 개 프로젝트의 구체적인 기술 업무에 참여할 수 있다면 상상해 보세요. 부서 관리자가 특정 프로젝트에 참여하는 다른 문제를 고려해 본 적이 있습니까? 부서의 일상 업무는 처리하지 않고, 아무도 관심을 기울이지 않는다. 부서의 다른 프로젝트는 프로젝트 관리자의 도움 없이 부서의 미래를 계획하는 사람이 없다. 비슷한 프로젝트 매니저의 행동이 많다. 예를 들어, 판매를 잘하는 매니저는 항상 자신의 영업사원에 대해 불안해하며, 아래 사람들은 항상 그렇게 믿을 수 없다고 생각한다. 문필이 좋은 프로젝트 매니저는 항상 스스로 서류를 작성하는데, 비서가 초안을 작성하는 것은 항상 그를 업신여기게 하기 때문이다. (윌리엄 셰익스피어, 윈스턴, 독서명언)
결국 사장은 하루 종일 허둥대며 관리 효율성이 매우 떨어진다. 관리자는 부서의 발전에 대해 생각할 시간이 없다. 부하들은 믿을 수 없고, 조심스럽고, 선을 넘지 못하고, 적극성이 없다.
이에 따라 유비 문필은 제갈량보다 못하며 무예는 조마황보다 못하지만, 그는 사람을 써서 인심을 사로잡을 수 있다고 생각한다. 프로젝트 매니저가 되는 모든 사람은 유비의 방법을 배워야 할 것 같다. 설령 네가 어떤 면에서는 훌륭하다고 해도. (존 F. 케네디, 공부명언) 너는 자신의 경험을 부하 직원에게 전수할 수 있으니, 그들이 실수하는 것을 두려워하지 마라. 하기는 어렵고, 때로는 할 필요도 없지만, 한 사람에게 그 직위와 월급을 주었으니 충분히 발휘해야 한다. 너는 그들을 위해 일할 수도 없고, 네가 그들에게 지불한 권력을 빼앗을 수도 없다. 기자가 CA 의 사장 왕 선생을 인터뷰했을 때, 왕선생은 지금까지 개인 우편함이 없다고 말했다. 기자가 놀라서 그에게 왜 그런지 물었을 때, 그는 "그럴 필요가 없다" 고 말했다. 나는 회사의 일상 업무를 처리할 좋은 업무 책임자가 있다. 나는 회사의 발전 전략을 고려할 충분한 시간이 있다고 생각한다. 나는 사소한 일에 방해받고 싶지 않다. 클릭합니다 왕은 훌륭한 관리자이기 때문에 CA 는 오늘의 지위를 가지고 있다.
잘 한 프로젝트 매니저는 매일 직장에서 그렇게 긴장하지 않을 수도 있다. 그래서 일부 부하 직원들은 이런 질문을 할 수 있습니다. "우리는 매우 바쁩니다. 당신은 무엇을 하고 있습니까?" "
프로젝트 관리자, 팀의 사명과 발전을 담당하는 사람. 따라서 그것의 주요 임무는 그 구성 요소의 합계보다 큰 진정한 전체와 역동적인 전체를 만드는 것이다. 사람들이 흔히 말하는 관리입니다. 관리를 통해 자연의 불가능 1+ 1 > 2 가 가능해질 수 있다. 이 사명을 완수하기 위해 프로젝트 매니저는 무엇을 해야 합니까?
첫째, 프로젝트 관리자는 먼저 목표, 즉 팀의 목표를 결정해야 합니다. 어디로 가는지 알아야만 그는 거기에 도착할 수 있다. 목표가 무엇인지, 목표가 팀의 책임을 효과적으로 지탱할 수 있어야 하며, 팀의 발전에 도움이 되어야 한다. 또한 팀의 모든 사람에게 목표를 전달하여 목표를 달성하는 과정에서 자신의 책임과 중요성을 인식하도록 해야 합니다.
둘째, 프로젝트 관리자는 작업을 구성하는 방법, 즉 작업을 준비하는 방법, 필요한 활동, 의사 결정 및 관계를 분석해야 합니다. 그는 일을 분류하고, 1 차 및 2 차 임무와 우선 순위를 결정하고, 적절한 인원을 배정하여 일을 수행해야 한다.
셋째, 프로젝트 관리자는 정보를 장려하고 교환해야합니다. 그는 여러 가지 기능을 가진 사람들을 하나의 팀으로 결성하고, 부하 직원에게 동기를 부여하고, 동료, 동료, 동료 간에 정보를 교환하고, 업무 완성을 조율해야 한다.
넷째, 프로젝트 관리자는 팀 성과와 개인 성과를 측정하고 평가해야 합니다. 첫째, 팀의 성과뿐만 아니라 개인의 일에도 관심을 갖고 자신의 일을 잘 할 수 있도록 도와주는 척도를 세워야 한다. 프로젝트 관리자는 부하 직원, 상급자 및 동료에게 측정의 중요성과 결과를 알립니다.
프로젝트 관리자는 자신을 포함하여 사람들을 양성해야합니다. 프로젝트 관리자는 부하 직원의 장점과 단점을 다른 사람들보다 더 잘 이해하고 부하 직원의 교육 요구 사항을 잘 알고 있으며 부하 직원이 업무 성과를 향상시키는 데 필요한 기술을 갖추고 있는 경우가 많습니다. 부하 직원의 기술이 향상되어야만 팀 전체의 효율성이 향상되고 팀 구성원이 발전해야 열정과 책임감으로 일을 할 수 있다. 관리자는 교육 계획을 수립하고 구현해야합니다.
우리 업계에서는 많은 프로젝트 관리자들이 업무나 기술적으로 너무 강한 기술을 가지고 나서야 이 책임을 부여받았다. 그들은 경영 교육을 받지 못했을 것이다. 이 문장 들이 자신의 책임을 생각하고 이해할 수 있기를 바란다.
프로젝트 매니저는 무엇을 해야 하고, 무엇을 해서는 안 됩니까?
1. 일을 하는 데는 목표 지향이 있다
먼저 무엇을 해야 하는지 이해하고, 어떻게 해야 하는지 이해하다. 목표는 프로젝트 관리의 중요한 특징이다. 프로젝트 관리자의 업무 원칙은 프로젝트 목표를 중심으로 프로젝트 관리자의 직업윤리와 행동규범을 위반하지 않고 프로젝트 목표 달성에 유리한 모든 일을 하는 것이다.
단기 목표도 있고, 공통의 목표도 있다. 목표에 따라 현재 프로젝트를 완료하는 것은 단기적인 목표일 수 있고, 1 년에 한 명의 효율적인 팀을 데리고 오는 것은 장기적인 목표일 수 있다. 임시적인 프로젝트가 아닌 프로젝트 관리자에게 더 중요한 것은 현재 프로젝트의 단기적인 이익보다는 프로젝트의 장기적인 목표에 초점을 맞추는 것입니다. 이를 인식해야만 훈련, 코치, 팀웍, 자발성, 팀 언어, 규칙의 중요성을 프로젝트 전체에서 인식할 수 있다.
2. 자신이 정의한 목표를 분해합니다
소프트웨어 프로젝트의 경우 프로젝트 관리자는 비즈니스 또는 사용자 요구 사항에 따라 소프트웨어 제품 출시 후 비효율성을 0.5 /KLOC 코드보다 작게 정의합니다. 이 목표를 달성하기 위해서는 프로젝트의 시간 과정과 결합하여 목표에 영향을 미치는 요소를 분석해야 한다. 각 단계의 결과물의 품질, 결함 누출, 테스트 수준, 수요의 변화와 안정성, 사전 요구 사항 설계 및 개발 사양, 팀 규칙, 개발자의 책임은 모두 이 목표의 실현에 영향을 줄 수 있습니다.
하나의 전반적인 목표 달성은 단순히 하나의 영향 요인을 높이면 실현될 수 있는 것이 아니다. 각종 요소 사이에는 여전히 긍정적이고 부정적인 효과가 있기 때문에 반드시 전면적으로 체계적으로 고려해야 한다. 각 항목에 대한 예상 간격 레벨을 결정한 다음 추적 및 통제를 위해 이러한 기대치를 계획에 배치합니다. 이 일련의 과정은 당신이 하는 모든 일이 목적이 있고, 원래 정의된 목표를 달성하기 위해 봉사하는 것이지, 결코 아무것도 없는 것이 아니라는 것을 보여 주고 싶다. (알버트 아인슈타인, 도전명언)
3. 구체적인 실제 문제
첫째로, 위험과 위기에 대한 강조는 문제에 대한 중시보다 훨씬 크다. 문제 해결이 중요하지 않다는 것이 아니라, 프로젝트 관리자는 위험을 더 많이 관리하고, 위험을 많이 제거하고, 위험이 현실화되지 않도록 해야 한다. 프로젝트 매니저는 반드시 충분한 선견지명과 예리한 통찰력을 가지고 각종 싹과 위기를 발견해야 한다. 위기가 발생하기 전에 대응책은 종종 프로젝트 관리자가 회원과 대화하거나 절차에 대한 교육을 조직하는 것일 뿐이지만 위기로 인한 피해는 위험 대응 비용보다 훨씬 클 것입니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 위기명언)
프로젝트 매니저는 지도자보다는 코치가 되어야 한다. 관리자는 권한 부여를 알아야 하지만, 프로젝트 관리자는 권한 부여가 진도와 품질에 영향을 미치지 않는다는 것에 더 신경을 써야 하기 때문에 프로젝트 관리자는 확실히 모든 것을 스스로 하는 것이 아니라, 아무것도 허가하지 않고, 좋은 감독의 역할을 해야 한다. 프로젝트 멤버들에게 모든 일을 완수하고 책임감 있게 일을 할 수 있는 능력을 주다. 스스로 하는 데 1 시간이 걸리고 팀원들에게 하루 정도 걸린다면, 이 날의 시간을 들여 팀이 함께 사용하는 관점에서 올바른 일을 하는 법을 가르쳐야 한다. (윌리엄 셰익스피어, 템플릿, 일명언)
PMBOK 9 대 지식체계의 내용은 모두 프로젝트에서 고려해야 할 것이다. 프로젝트 핵심 멤버로 구성된 프로젝트 관리 팀이라는 키워드가 있습니다. 프로젝트 관리자가 하는 일과 프로젝트 관리 팀이 하는 일을 구분할 필요가 있다. 또 다른 관심사는 일의 세분성이다. 프로젝트 태스크 추적은 프로젝트 관리자가 해야 할 일이지만, 프로젝트 관리자는 프로젝트 목표에 따라 자신의 추적 태스크의 세분성을 결정해야 합니다. 세분성이 너무 미세한 경우 프로젝트 멤버 또는 팀 리더가 추적할 수 있습니다. 프로젝트 관리자가 해야 할 일은 단순히 프로젝트 관리자와 프로젝트 멤버에게 주는 실용적인 안내서가 아니다.
팀에서 팀 리더로서 다음을 수행할 수 있습니다.
1) 정치적 문제에서 팀 목표를 손상시키지 않도록 합니다.
2) 팀 목표에 대한 개인의 약속을 보여줍니다.
3) 너무 많은 우선 순위로 팀의 일을 희석하지 마라.
4) 팀 구성원을 공정하고 공정하게 대하십시오.
5) 팀 구성원의 저조한 성과와 관련된 문제를 직면하고 해결하고자 합니다.
6) 직원들의 새로운 생각과 새로운 정보에 대해 개방적인 태도를 취한다.
팀 멤버로서 다음을 수행해야 합니다.
1) 개인의 역할과 책임에 대한 진정한 이해를 보여줍니다.
2) 목표를 논증하고 사실에 근거하여 판단하다.
3) 다른 팀 구성원과 효과적으로 협력하십시오.
4) 팀 목표와 개인 목표를 우선적으로 고려한다.
5) 어떤 프로젝트의 성공을 위해 노력하겠다는 소망을 보여줍니다.
6) 정보를 공유하고, 느끼고, 적절한 피드백을 생성하고자 합니다.
7) 다른 회원들이 필요할 때 적절한 도움을 준다.
8) 자신에게 높은 기준을 보이다.
9) 팀 의사 결정 지원
10) 팀의 성공을 위해 앞장서고 있습니다.
1 1) 타인의 피드백에 대한 긍정적인 반응에 대한 이해는 이원적인 문제이며, 프로젝트 목표와 관련된 일의 세분성 및 관리 세분성과 관련이 있습니다.
IT 프로젝트 관리자 경험 요약
나는 여러 해 동안 프로젝트 매니저로 일했는데, 이 일을 하는 데 가장 중요한 것은 현지 여건이 무엇인지 이해하고 상황을 개선하는 것이라고 생각한다. 가장 잘 어울리는 것만 있고 옳고 그름은 없다. 프로젝트 매니저가 가장 꺼리는 것은 완벽주의 성향, 특히 기술을 하는 사람들은 표준 답안을 찾고, 업무 진도를 늦추고, 얼떨하다는 것이다. 다음은 우리 프로젝트의 몇 가지 개인적인 경험입니다. 여러분들이 지도해 주시고 토론에서 자신의 수준을 높일 수 있도록 작성해 주세요. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 토론명언)
프로젝트의 초기 단계가 가장 중요한 단계입니다. 프로젝트 관리자가 새 프로젝트를 인수할 때, 그는 먼저 다음과 같은 모든 방면에서 이 프로젝트에 대해 가능한 한 많이 이해해야 한다.
1. 이 프로젝트가 무엇이고, 무엇을 할 것인지, 누가 제기한 것인지, 어떤 문제를 해결하기 위한 것이다. 국내 고객들이 모두 미성숙한 상황에서 프로젝트의 이름을 근거로 프로젝트의 목표를 상상하지 마라. "사무 자동화" 라는 프로젝트는 당신이 시장에 진출한 지 한 달 후에 고객이 실제로 필요로 하는 것은 컴퓨터 생산 관리 보조 정보 시스템이라는 것을 알게 될 것이다. (윌리엄 셰익스피어, 윈스턴, 업무 자동화, 업무 자동화, 업무 자동화, 업무 자동화, 업무 자동화, 업무 자동화, 업무 자동화) 상황을 미리 이해하는 일이 세심할수록 놀라움이 적어지고 프로젝트의 위험이 줄어든다.
2. 이 프로젝트는 투자자, 구체적인 업무이해 관계자, 프로젝트 완료 후 운영자, 기술 책임자 등 누구를 포함한다. 많은 프로젝트에서, 업주 단위 구조가 복잡할 뿐만 아니라, 공사 감리회사, 업주 업계 주관부 등과 같은 다른 단위도 관련된다. 프로젝트 매니저는 이 프로젝트에 대한 모든 사람의 생각과 기대를 알아야 한다. 각 방면의 견해와 기대를 미리 이해하면 프로젝트에 문제가 있을 때 누가 어떤 방식으로 너를 지지할 것인지, 어떤 목적으로 너를 반대할 것인지를 분석하는 데 도움이 될 수 있다. 그래서 미리 준비하고, 친구를 단결하여 적을 대적하고, 일을 네가 원하는 방향으로 발전시킬 수 있도록 한다. 영원한 친구도, 영원한 적도 없고, 일관적인 이익만 있을 뿐, 이는 프로젝트 매니저로서 반드시 명심해야 하는 것이다.
3. 고객의 상황을 기본적으로 파악한 후, 다음 일은 우리 회사 각 측이 이 프로젝트에 대해 어떻게 생각하는지 이해하는 것이다. 첫째, 고위 지도자가 중시할지 여부, 이는 당신이 자원을 필요로 할 때 회사가 당신의 요구에 따라 가장 강력한 지원을 제공할 것인지의 여부를 결정한다. (존 F. 케네디, 노력명언) 당신이 해야 할 일은 이 프로젝트에 대한 회사의 실제 기대를 이해하는 것입니다. 프로젝트를 더 크게 하고 싶습니까, 아니면 돈을 벌고 싶습니까? 템플릿 프로젝트를 하고 싶든 그저 대강대강 하고 싶든, 프로젝트에 대한 회사 지도자의 태도가 당신이 이 프로젝트를 하는 전략을 결정한다. 이 전략 방침은 당신의 프로젝트 계획에 직접적인 영향을 미칠 것이다. (윌리엄 셰익스피어, 템플릿, 프로젝트, 프로젝트, 프로젝트, 프로젝트, 프로젝트, 프로젝트)
전체 프로젝트 계획을 세우기 전에, 너도 자신의 손에 있는 자원을 대충 계산해야 한다. 첫 번째는 시간입니다. 현재 시장 경쟁이 치열하여, 많은 종목들이 거의 불가능한 시간 내에 완성해야 하는 경우가 많다. 이 점에 대해 너는 프로젝트의 위험 통제 방안을 제정할 때 충분히 고려해야 한다. 둘째, 인력은 프로젝트 예산과 과거 경험에 따라 미래 프로젝트 팀이 얼마나 많은 역할을 할 것인지, 각 역할이 현재 회사에서 점유하고 있는지, 이 프로젝트에 의해 충분히 활용될 수 있는지, 다른 사람을 채용해야 하는지, 채용 준비는 가능한 한 빨리 시작해야 한다. 마지막으로, 일부 장비의 준비입니다. 프로젝트에 필요한 핵심 장비는 가능한 한 빨리 예약해야 합니다. 장비 및 기타 어떤 일이 발생하든 시간을 낭비하고 있습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 예술명언)
프로젝트 설명을 할 때입니다. 좋은 프로젝트 설명서는 무엇을 해야 하는지 (주로 무엇을 해야 하는지, 어떻게 해야 하는지) 뿐만 아니라 철저히 검사하는 방법도 명확하게 설명해야 한다. 즉, 무엇을 해야 하는지 설명할 뿐 아니라 고객의 업무 담당자 (일반적으로 기술을 이해하지 못하는 고객) 에게 프로젝트가 무엇을 하고 있는지 알려 줍니다. 간단히 말해서, 프로젝트 설명은 프로젝트가 하는 일, 모든 일이 어느 정도 이루어졌는지, 각 결과를 확인하는 방법을 설명합니다.
6. 마스터 플랜을 만들 때가 되었나요? 아니요, 이제 고객의 목표와 보유한 자원을 이미 알고 있습니다. 계획을 세우기 전에 관리자와 고객과 자원에 대해 충분히 소통해야 합니다. 많은 자원이 아직 명확하지 않기 때문에, 당신은 이 프로젝트의 위험과 자원에 대한 수요를 상세히 분석하는 보고서를 작성해야 합니다. 어떤 문제들은 해결되지 않으면 어떻게 될까. 자원이 부족하면 고위층은 전략을 바꿔 이 프로젝트에 대한 투자를 늘려야 한다. 조건이 허락하더라도 일부 회사들은 이 프로젝트를 포기할 것이다. 요컨대, 아무도 불가능한 임무를 완수할 수 없다. 프로젝트 매니저가 가능한 한 빨리 위험을 발견하지 못한다면, 그는 열사일 수밖에 없다.
7. 무엇을 해야 할지, 당신의 칩, 이 프로젝트에 대한 전반적인 전략, 프로젝트 팀을 설립할 때가 되었습니다. 많은 프로젝트 관리자들이 자신의 팀원을 선택할 권리가 없다면, 당신이 원하는 것을 찾기 위해 영향력을 발휘하기 위해 노력하라. (존 F. 케네디, 일명언) 회원의 구성은 프로젝트에 따라 차이가 커서 구체적인 요구 사항을 갖기가 어렵다. 그러나 고객 업무에 정통한 사람이 있어야 한다. 많은 작은 프로젝트, 이 사람은 프로젝트 매니저 자신이고, 큰 프로젝트는 업계 전문가를 배치하여 고객과의 소통이 닭과 오리에 대해 이야기하지 않고 쌍방이 서로 이해할 수 있도록 한다. 제가 자주 보는 것은 우리 기술자가 고객과 이야기할 때 전문 용어로 가득 차 있어서 고객들에게 안개가 끼었다는 것입니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 예술명언) 반대로, 그는 고객이 기술을 이해하지 못한다고 비난했다. 사실 자신이 무엇을 하고 싶은지 아는 고객은 이미 좋은 고객이다. 자신이 무엇을 하고 싶은지, 어떻게 해야 할지 모르는 고객은 많지만, 고객이 고객을 선택하는 것이 아니라 고객이 당신을 선택했다는 것을 알아야 한다. 고객과 함께 있어야 보수를 받을 수 있고, 마음이 평온해질 수 있다.
8. 이제 지도자, 팀원, 고객 등 세 그룹에 직면해야 합니다. 당신의 주된 임무는 이 사람들과 소통하여 당신이 무엇을 할 계획인지, 그리고 그들이 언제 준비하기를 원하는지 알려주는 것입니다. 소통이 이렇게 중요하기 때문에 미리 명확하게 소통하는 원칙도 중요하다. 많은 소통 원칙은 무언의 규칙이다. 만약 네가 한 부서에 오래 있었다면, 이 규칙들을 적용하는 것은 당연한 것이다. 하지만, 당신은 지금 여러 부서, 심지어 여러 부서에 직면하고 있습니다. 소통 규칙을 분명하게 말하지 않으면 앞으로 손해를 볼 것이다. 다음 몇 가지 일은 지루해 보이지만, 사실 유용하다. 첫 번째는 정보의 흐름을 규정하는 방식과 매체, 밀거나 당기는 것이다. 푸시란 프로젝트 관리자가 전화, 메일, 서면 형식 등 사전 예방적으로 정보를 게시하여 모든 사람에게 정보를 전달하는 것을 말합니다. 이 상황은 사람이 적은 작은 프로젝트에 적합하다. 당기기는 프로젝트 관리자가 웹 서버와 같다는 것을 의미합니다. 만약 당신이 어떤 정보가 필요하다면 그에게 물어 보세요. 물론, 어떤 프로젝트 관리자도 자신을 이렇게 힘들게 하지 않고, 그는 공공 매체에 정보를 게시하여 정보를 발표할 것이다. 이것은 간단한 화이트보드이고, 약간 복잡한 것은 프로젝트의 공공 정보 상호 작용 영역이다. 무언의 규칙은 내가 너에게 보내면 내가 너에게 말하지 않았다고 말하지 말라는 것이다. 이렇게 말하는 것은 지루해 보이지만, 실제로는 정보 전달의 불완전한 책임 문제를 포함한다. 물론, 이것들은 모두 일반적인 방식이니 절대화하지 마라. 일반적으로 능동적인 의사 소통과 수동적인 접근이 공존합니다. 특히 리더의 경우 프로젝트 관리자가 적극적으로 의사 소통을 해야 합니다. 두 번째 질문은 문서입니다. 많은 사람들이 문서 쓰기를 두려워하지만, 프로젝트 매니저는 "기억력이 좋은 것이 쓰는 것보다 못하다" 는 이치를 명심해야 한다. 왜 가끔은 잘 모르겠어요? 증거가 없기 때문입니다. 따라서 프로젝트 관리자는 프로젝트 관리자의 프로젝트 로그와 같은 일부 문서에 서명해야 하며 적어도 매주 고객이 서명해야 한다는 점을 고객에게 분명히 설명해야 합니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 프로젝트명언) 또한 회의록, 심지어 지도자의 연설 기록과 같이 * * * 양해를 달성한 모든 일은 서류로 작성해야 하며, 쌍방이 서명하여 향후 분쟁이 끝날 때 조사할 수 있도록 해야 한다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 전쟁명언) 기억하십시오: 당신이 말한 것은 당신이 말하지 않은 것과 같습니다. 네가 적어서 서명한 후에야 일어난다. 제출 한 보고서와 같은 몇 가지 질문이 있으며 리더십 (리더십 및 고객 리더십 포함) 에게 객관식 질문을 제공합니다. 결국 지도자는 비준을 거부하여, 네가 어찌할 바를 몰라 진도를 늦추었다. 이때 너는 기다릴 수 있지만, 기록을 남기고 책임자를 명시해야 한다. 또한, 만약 당신이 처음부터 지도자와 합의를 이룬다면, 지시 제출 후 3 일 후에 지도자의 답변을 받지 못한다면 상대방도 동의할 것이며, 그렇게 하면 많은 주도권을 장악할 수 있을 것입니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 성공명언) 또 다른 사건의 승인 절차: 프로젝트 일지에 어떤 등급의 일이 기록되어 있는지, 어떤 등급의 일에 쌍방의 프로젝트 관리자의 서명이 필요한지, 어떤 등급의 일에 쌍방 지도자의 서명이 필요한지 등을 예로 들 수 있다. (윌리엄 셰익스피어, 윈스턴, 일명언) 미리 생각해 보면 주도면밀할수록 앞으로의 일에서 더욱 주동적이 될 것이다.
9. 음, 우리는 이미 많은 선행 작업을 했고, 몇 가지 게임 규칙을 정의했다. 이제 앉아서 계획을 세울 때가 되었다. 이 섹션에서는 프로젝트 관리에 관한 어떤 책이라도 나보다 잘 말할 것이다. 나는 글을 적게 쓰고 자신의 경험에 대해 이야기할 것이다. 첫 번째는 고객 비즈니스 전문가, 시스템 분석가 등 몇 가지 주요 팀 구성원을 찾는 것입니다. , 프로젝트 모듈 분할 작업을 수행합니다. 프로젝트는 블록, 각 블록이 수행하는 것, 모듈 간에 정보를 교환하는 방법 등으로 나뉩니다. 수요는 무엇을 하느냐의 문제를 정의하지만, 여기서 우리가 말하는 것은 어떻게 하는 것이다. 여기서 강조해야 할 것은 하나의 목표를 달성하는 데는 여러 가지 방법이 있다는 것이다. 완벽해 보이는 것이 아니라 네가 가장 잘 아는 것을 선택해야 한다. 이 아이디어는 프로젝트의 많은 위험을 감소시킬 것입니다. 때때로 고객은 새로운 기술에 감동을 받아 이 신기술을 채택하라고 고집한다. 만약 네가 나를 이 프로젝트로 선택한다면, 너는 내가 좋아하는 방식으로 일을 하도록 허락해야 한다고 그에게 말해야 한다. 신기술이 사람을 매료시키는 것은 손해를 보는 사람이 많지 않기 때문이다. 나는 네가 첫 번째 희생자가 되기를 원하지 않는다. 계획을 사용하면 너의 일이 더욱 명확해질 것이다. 예를 들어, Microsoft 의 프로젝트 소프트웨어를 사용 하 여 양식을 작성 하면 프로젝트가 해야 할 일, 각 일에 필요한 자원, 관계, 소요 시간, 완료 후 표시 등을 알 수 있습니다. 모든 결과는 결국 간트 차트 라는 형태로 표시됩니다. 이 양식을 완성하면 간트 차트의 프로젝트 종료 시간이 계획 종료 시간보다 훨씬 뒤처진다는 것을 알게 될 것이다. (계약서에 서명한 사람은 결코 먼저 너의 의견을 구하지 않을 것이다.) 물론, 프로젝트 관리를 배운 사람들은 많은 WBS 와 최적화 경로에 대해 이야기하지만, 제 경험은 계획 시간이 끝날 때까지 기다려야 한다는 것입니다. 만약 당신이 이 문제를 겪지 않았다면, 당신이 편안한 직업을 선택한 것을 축하하기 전에, 당신이 해야 할 모든 일을 나열하고 그들이 필요로 하는 시간을 정확하게 평가했는지 확인해 주세요. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 노력명언) 이때 너는 몇 가지 임무를 희생할 시간을 고려해야 한다. 어떤 기준에 근거합니까? 이 프로젝트의 전략! 우리가 섹션 iii 에서 언급 한 전략. 내 경험은 만약 아무것도 따라잡지 못한다면, 결과는 아마도 열 가지 일을 제대로 하지 못한 것 같다는 것이다. (존 F. 케네디, 경험명언) 얼마나 실패했는지 생각해 보세요. 따라서 당신이 익숙하고 자신 있는 일에 자원을 투입한다면, 최종 결과는 10 가지가 될 것입니다. 그 중 3 개는 이미 훌륭한 제품으로 만들어졌고, 3 개는 이미 완성되었고, 4 개는 어떤 이유로 연기되었습니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 자신감명언) 성적표가 많이 예쁘지 않나요? 전략은 우선 순위를 결정하고, 우선 순위를 올바르게 정하는 것은 프로젝트 관리자 역량의 주요 구현이다.
자, 이제 프로젝트는 선행 작업을 완료하고, 프로젝트 목표를 이해하고, 수중에 있는 자원을 명확히 하고, 프로젝트 전략을 세우고, 프로젝트의 전반적인 방안을 편성하고, 프로젝트가 구현 단계에 들어섰습니다. 이 단계에 들어선 것은 프로젝트 매니저가 상대적으로 자유로울 때이다. 전기와는 달리, 프로젝트 매니저는 기자들처럼 서로 다른 사람들과 접촉하고, 그들이 무슨 말을 하고 있는지, 그들이 무엇을 생각하고 있는지, 그들의 진정한 목적이 무엇인지 추측하려고 노력해야 한다. 그것은 가장 힘든 일이다. 물론 소규모 프로젝트 프로젝트 관리자 자체도 자원이기 때문에 많은 일을 해야 한다. 이때 그는 누구보다도 고생한다. 이 기간 동안 프로젝트 관리자의 주요 업무는 고객 리더와 자신의 리더와 소통하는 것이다. 고객 리더와 소통할 때는 각별히 주의해야 한다. 상대방의 지지가 필요하지 않으면 구체적이어야 한다. 그렇지 않으면 그에게 모든 것이 잘되고 태도가 긍정적이라고 말해라. 지도자가 이해하지 못하는 세부 사항을 절대 말하지 마라. 예를 들면, "왕 주임, 요즘 프로젝트가 정상적으로 진행되고 있다. 바로 JVM 이 메모리를 자주 빠뜨리는 것이다." 왕 주임: (*&; $ @ @ ". 자신의 지도자에게 보고해도 이 문제에 주의해야 한다. 그가 기술 전문가가 아니라면, 너는 그의 기술 경험이 필요하다. 일반적으로 진도가 정상인지, 문제가 발생했을 때 너의 대책과 계획을 보고할 수 있다. 자원 호출과 같이 그의 지원이 필요한 일부 장소는 상세한 설명이 필요하다.
팀 구성원과 회의를 하는데, 일부 프로젝트 진도 추적회 외에도 많은 세미나가 있어 문제를 해결하기 위해 브레인스토밍을 해야 한다. 많은 참가자들은 세부 사항에 초점을 맞추고, 대국관이 부족하고, 다소 소극적이며, 자존심이 강하다 (총결이 정확하지 않아 벽돌을 찍는 것을 환영한다). 따라서 회의 주관자로서, 당신이 질문을 하고 그들의 관점을 기록하는 한, 절대 심사위원이 되지 마십시오. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 명예명언) 한 가지 문제에는 여러 가지 측면이 있다. 다른 각도에서 보면 현상은 완전히 다르다. 맹인이 코끼리를 만지는 이야기를 생각해 보세요. 이들은 종종 어떤 방면의 기술자들에 정통하여 자신의 관점에서 의견을 발표한다. 특별한 상황이 없다면, 그들이 제시한 방안이 그들의 관점에서 가장 합리적이라고 생각해야 한다. 당신의 강점은 일의 경중완급을 파악하고 각 방면의 경중완급을 평가하여 그들의 의견에 따라 적절한 방안을 내놓는 것입니다. 그래서 회의에서, 당신은 모든 사람과 그의 의견을 충분히 존중하고, 더 좋은 의견을 제시한 사람들을 칭찬해야 하며, 절대 회의를 끝없는 논쟁에 끌어들이지 말아야 합니다. (일이 흑백이 아니라 다양하다는 것을 모두에게 알려야 합니다. 아, 우리의 교육이 번거로움을 초래했습니다.). 회의 후에 네가 직접 서류를 써서 결정을 해라. 회의에서 모두의 체면을 모두 돌보았으니, 집행하면 당연히 아무런 저항도 없을 것이다. 만약 네가 아직 의견이 있다면, 사적으로 그를 찾아 이야기할 수 있다. 만약 당신이 여전히 그를 설득할 수 없다면, 그에게 알려야 합니다. 왜냐하면 이 프로젝트는 당신이 책임지고, 당신은 위험을 감당하기 때문에, 이 경중완급은 당신이 판단해야 하기 때문입니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 도전명언) 한 조직의 고위층이 반드시 일반 회원보다 높지는 않지만, 그는 조직의 위험과 정보의 비대칭을 감당해야 하기 때문에, 일의 경중완급에 대한 판단은 부하보다 확실히 낫다.
발전 과정에서 내부 관리는 항상 목적을 받아들이는 사상을 강조해야 한다. 각 임무의 최종 결과물을 검사해야 한다. 예를 들어 인터페이스는 우아하고 간결하며 활발하며 이 요구 사항을 어떻게 점검해야 할지 모르겠다. 그래서 개발팀에 임무를 지정할 때 결과를 어떻게 점검할지 고려해야 한다. 예를 들어, 임무 개발자 중 한 명이 EJB 프로그래밍에 익숙한 계획을 보았습니다. 이 임무에서, 이 사람들에게 전문적인 인증시험을 치르게 하는 것 외에는 성적을 확인하기가 어려울 것이다. 따라서 프로젝트 관리자에게는 결과를 검사하는 방법과 고객에게 결과를 전달하는 방법을 고려하는 것이 항상 중요합니다. 어떤 오래된 프로젝트 매니저가 역행 계획을 받았다고 들었는데, 먼저 검수, 검수 기준, 그리고 작업 계획을 결정하는 것이다. 많은 프로젝트가 착공된 지 오래되어 검수 방법을 모르기 때문에 이 프로젝트에 문제가 생길 가능성이 크다. 프로젝트를 하는 것은 검수를 위한 것이다. 우리의 역할은 연구 기관이 아닙니다. 우리의 목적은 이렇게 많은 노동을 한 후에 결과를 얻는 것이다. 또한, 나는 한 마디를 삽입한다: 나는 고객의 현장 개발에 강력히 찬성하지 않는다. 특히 한 무리의 기술자가 고객과 직접 소통하여 갈등과 갈등을 일으키기 쉽다 (기술자의 성격에 따라 결정됨). 제 접근 방식은 프로젝트 관리자와 프로젝트 구현자가 현장에 가고 소프트웨어 개발자는 회사에서 프로젝트를 하는 것입니다. 프로젝트 구현자는 초급 프로젝트 관리자입니다. 그들은 자신의 제품과 일부 고객의 업무를 알고 있다. 관건은 그들이' 낯가죽이 두껍다' 는 좋은 의사소통 능력을 가지고 있다는 것이다. 그들은 고객과 R&D 인원 사이의 다리이며, 그들의 직업 방향도 매우 민첩하다. 그들은 앞으로 개발업자보다 훨씬 넓은 방향으로 방향을 바꿀 수 있다.
그럼, 수요 변화라는 가장 골치 아픈 문제에 대해 이야기합시다. 변경은 일반적으로 두 가지 유형으로 나뉩니다. 하나는 원래 목표의 부분 변경, 즉 수요 변경입니다. 또 다른 하나는 목표가 변경되지 않았지만 고객은 프로세스 구현에서 인터페이스 레이아웃에 이르기까지 현재의 구현 방식에 만족하지 않는다는 것입니다. 이런 상황에 부딪히는 것은 피할 수 없는 일이다. 주로 사전 소통이 부족해 고객이 프로젝트가 진행됨에 따라 점차 문제를 파악하고 이전 생각을 바꾸기 때문이다. 이 시점에서 변경이 필요하고 전략이 이를 허용한다면 다음 사항에 유의하십시오.
1. 이전 파일이 이전 결론을 기록한 파일이고 고객이 서명했는지 확인합니다. 그렇지 않다면, 빨리 하던 일을 멈추고, 빨리 고객과 당신의 방안을 확인하고, 나중에 말을 하지 않도록 서명하도록 하세요. 증거가 없습니다.
2. 고객과 앉아서 그의 수정의 근본 목적이 무엇인지 직접 토론한다. 같은 목표를 달성할 수 있는 대안이 있지만, 당신에게 더 저렴합니까?
3. (프로젝트 초기 작업) 변경 프로세스를 명확히 하고, 일반적으로 고객이 지정한 한 사람이 서명한다. (그렇지 않으면 고객의 각 지도자가 끼어들 권리가 있으면 폐기된다.) 그런 다음 정식 프로젝트 문서로 제출한다. 그런 다음 평가 분석을 하고 비용과 진도에 미치는 영향을 분석합니다. 당신의 지도자가 동의한 후 그에 상응하는 의견을 제시합니다. 주로 설계 변경의 원인을 설명하고 불확실한 결과 (이 물건은 먼저 작성해야 함) 를 지적한 다음 고객이 서명하도록 하는 것입니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 예술명언) 병원에서 환자를 수술하기 전에 가족이 서명한 면책 조항을 본 적이 있습니까? 네, 이 점을 배우면 모든 사람이 모든 변화가 비용과 대가가 있다는 것을 깨닫게 됩니다.
을 눌러 섹션을 인쇄할 수도 있습니다