IT 프로젝트 관리자로서 무엇을 해야 하나요?

IT 프로젝트 관리자는 무엇을 해야 하나요?

프로젝트 매니저는 특정 프로젝트 업무를 관리하는 사람으로, 직장에서 리더십 역량을 지속적으로 키우는 동시에, 프로젝트에 대한 배경 조사와 책임이 공존하는 직업이다. 프로젝트 관련 정보를 수집하고, 수요 계획을 수행하고, 프로젝트 조사 보고서 및 정보 요약을 작성하고, 프로젝트 구성 요소 또는 모듈의 전체 시스템 설계를 수행하고, 관련 프로젝트 단위 및 관련 기술 전문가와 접촉하고, 프로젝트 타당성 조사 보고서를 작성하고, 공식화 및 작성을 위해 협력합니다. 프로젝트를 신청하고, 자료를 보고하고, 프로젝트 팀을 구성하여 프로젝트 작업을 완료하고, 프로젝트 완료 시간과 품질을 보장합니다. 다음은 제가 정리한 내용입니다. IT 프로젝트 관리자는 무엇을 해야 할까요?

IT 프로젝트 관리자는 무엇을 해야 할까요?

이런 프로젝트 관리자를 자주 뵙습니다! 그는 하루 종일 바쁘게 돌아다녔고, 전화는 계속 울리고, 그가 이끄는 팀은 그가 없으면 하루도 버틸 수 없을 것처럼 한 시간 안에 수십 개의 지시를 내려야 했다. 그런 다음 그는 또한 "나는 매우 바쁘다" 또는 "나는 매우 피곤하다", "더 많은 사람을 추가해야 합니다"라고 말할 것입니다. 그런 프로젝트 매니저는 자신이 관리하는 사람이 있어도 세세한 부분까지 직접 챙겨야 하는 경우가 많다.

연구개발부서장이 직접 그런 일도 있을 수 있지 않을까? 프로젝트 소프트웨어 코딩에 참여했습니다. 작업이 하나 또는 두 개뿐이라면 괜찮을 것입니다. 프로젝트가 12개 이상이고 추가로 특정 기술 작업에 참여할 수 있다고 상상해 보십시오. 부서 관리자가 특정 프로젝트에 참여함으로써 발생하는 다른 문제는 일상적인 업무가 처리되지 않고, 부서 내 누구도 주의를 기울이지 않으며, 부서의 다른 프로젝트가 프로젝트 관리자의 도움을 받지 못하고, 아무도 미래에 대한 계획을 세우지 않습니까? 부서. 프로젝트 관리자의 유사한 행동은 많이 있습니다. 예를 들어 영업을 잘하는 관리자는 항상 영업 직원을 걱정하고 아래 사람들이 항상 신뢰할 수 없다고 생각합니다. 글쓰기를 잘하는 프로젝트 관리자는 항상 문서 초안을 직접 작성해야 합니다. 비서 그는 항상 초안 작성 등을 무시했습니다.

결과적으로 매니저는 하루종일 바쁘고 관리 효율이 매우 낮다. 관리자는 부서 개발 문제를 고려할 시간이 없습니다. 부하 직원은 자신이 신뢰할 수 없다고 느끼고 일을 하는 데 있어서 감히 너무 멀리 나아가지 못하고 열정이 없습니다.

생각해보면 유비의 글은 제갈량만큼 뛰어나지 않고, 무술도 관장, 조, 마황만큼 뛰어나지는 않지만 사람을 이용하고 이기는 데는 능하다. . 프로젝트 관리자라면 어떤 측면에서 매우 뛰어나더라도 Liu Bei의 접근 방식을 배워야 할 것입니다. 당신의 경험을 부하 직원에게 전달할 수 있고 그들이 실수하는 것을 두려워하지 마십시오. "사람을 채용할 때는 믿지 말고, 의심할 때는 이용하지 말라"는 것은 어렵고 때로는 할 필요도 없지만 사람에게 그 직위와 그 월급을 주었기 때문에 , 당신은 그들이 자신의 역할을 완전히 수행하도록 해야 합니다. 당신은 그들을 대체할 수 없으며 당신이 그들에게 지불한 권한을 "훔칠" 수 없습니다. 기자가 CA컴퍼니의 왕지롄 회장과 인터뷰를 했을 때 왕씨는 아직 개인 이메일 주소가 없다고 하던 기억이 난다. 기자가 깜짝 놀란 이유를 묻자 그는 "필요없다. 나에게는 매우 훌륭한 사업 이사가 있습니다. 회사의 일상 업무를 잘 처리하려면 회사의 발전 전략을 고려할 충분한 시간이 필요하며 사소한 문제로 방해받고 싶지 않습니다." Wang Jialian은 훌륭한 관리자이므로 CA는 오늘날의 지위를 가지고 있습니다.

일을 잘하는 프로젝트 매니저는 매일 직장에서 그다지 긴장하지 않을 수도 있습니다. 따라서 일부 부하 직원은 "우리는 바쁜데 무엇을 하고 있습니까?"와 같은 질문을 할 수 있습니다.

프로젝트 관리자는 팀의 임무와 개발을 담당하는 사람입니다. 그러므로 구성요소의 합보다 더 큰 진정한 전체를 창조하고, 역동적인 전체를 창조하는 것이 교회의 첫 번째 사명이 되어야 합니다. 그것이 사람들이 흔히 말하는 경영이다. 경영을 통해 자연의 불가능이 1 1> 2 가능성으로 바뀔 수 있다. 이 사명을 완수하기 위해 프로젝트 관리자는 무엇을 해야 할까요?

1. 프로젝트 관리자는 먼저 목표를 설정해야 합니다. 즉, 어디로 가야할지 알아야만 팀의 목표를 결정할 수 있습니다. 거기.

목표가 무엇인지 결정하고, 목표는 팀의 책임을 효과적으로 지원하고 팀의 발전에 기여할 수 있어야 합니다. 그리고 목표는 팀의 모든 구성원에게 전달되어 목표 달성에 대한 책임과 중요성을 이해할 수 있도록 해야 합니다.

2. 프로젝트 관리자가 작업을 정리하려면, 즉 작업을 어떻게 정리해야 하는지에 대한 다양한 활동, 결정 및 관계를 분석하고 작업을 분류하고 우선순위와 작업을 결정해야 합니다. 업무의 우선순위를 정하고 해당 업무에 적합한 인력을 배정합니다.

3. 프로젝트 관리자는 동기 부여 및 정보 교환 작업을 수행해야 합니다. 그는 다양한 기능을 수행하는 사람들을 팀으로 결합하고 부하 직원에게 동기를 부여하고 상사, 부하 직원 및 동료 간의 정보 교환을 통해 작업을 조정하고 완료해야 합니다.

4. 프로젝트 관리자는 팀의 성과와 개인의 성과를 측정하기 위해 측정과 평가를 수행해야 합니다. 우선, 측정 기준을 수립하는 것이 필요합니다. 이 기준은 팀의 성과에만 초점을 맞추는 것이 아니라 개인의 업무에 집중하고 업무를 잘 수행할 수 있도록 돕는 것도 필요합니다. 프로젝트 관리자는 부하 직원, 상사 및 동료에게 측정의 의미와 결과를 전달합니다.

5. 프로젝트 관리자는 자신을 포함한 사람들을 교육해야 합니다. 프로젝트 관리자는 부하 직원의 강점과 약점을 다른 사람보다 더 잘 이해하고 있으며, 자신의 교육 요구 사항을 더 잘 알고 있습니다. 그들은 종종 부하 직원의 업무 성과를 향상시키는 데 필요한 기술을 갖추고 있습니다. 팀 전체가 발전해야 팀원들이 자신의 업무 수행에 열정과 책임감을 투자하게 됩니다. 관리자는 교육 계획을 개발하고 이를 배포해야 합니다.

우리 업계에서는 많은 프로젝트 관리자가 뛰어난 비즈니스 능력이나 기술 능력을 갖춘 후에야 관리자의 책임을 맡을 수 있습니다. 이 기사가 도움이 될 수 있기를 바랍니다. 그들에 대한 귀하의 책임을 이해하십시오.

프로젝트 관리자가 해야 할 일과 하지 말아야 할 일은 무엇인지

1. 목표 지향적으로 일을 하십시오

우선 무엇을 해야 하는지 이해해야 합니다. 두 번째로 수행 방법 Do. 목표는 프로젝트 관리의 중요한 특징입니다. 프로젝트 관리자의 업무 원칙은 프로젝트 목표를 중심으로 이루어지며, 프로젝트 관리자의 직업 윤리 및 행동 강령을 위반하지 않고 프로젝트 목표 달성에 도움이 되는 일은 모두 수행되어야 합니다. .

목표에는 단기 목표와 공동 목표가 포함됩니다. 목표에 따라 현재 프로젝트를 완료하는 것이 단기 목표일 수도 있고, 1년 안에 효율적인 팀을 구축하는 것이 장기 목표일 수도 있습니다. 비임시 프로젝트의 프로젝트 관리자는 현재 프로젝트의 단기적 이익에 너무 신경을 쓰기보다는 프로젝트의 장기적인 목표에 더 집중해야 합니다. 이를 깨달아야만 우리는 전체 프로젝트에서 훈련, 코칭, 팀워크, 자발성, 팀 언어 및 규칙의 중요성을 깨달을 수 있습니다.

2. 자신이 정의한 목표를 분해

소프트웨어 프로젝트의 경우 프로젝트 관리자는 비즈니스를 기반으로 출시 후 소프트웨어 제품의 실패율이 0.5/KLOC 코드 미만이라고 정의합니다. 또는 사용자 요구. 이 목표를 달성하기 위해서는 프로젝트의 시간 과정, 각 단계의 결과물의 품질, 결함 누출, 테스트 수준, 요구 사항의 변경 및 안정성을 기반으로 목표에 영향을 미치는 요소를 분석해야 합니다. , 초기 요구 사항 설계 및 개발 사양, 팀 규칙, 개발자의 책임감 및 많은 요소가 이 목표 실현에 영향을 미칠 수 있습니다.

전체적인 목표 달성은 단순히 하나의 영향 요인을 개선하는 것만으로는 달성할 수 없으며, 각 요인 사이에는 긍정적인 영향과 부정적인 영향이 있기 때문에 종합적이고 체계적인 사고가 필요합니다. 각 요소의 예상 범위 수준을 결정한 다음 이러한 예상 값을 추적 및 제어 계획에 포함시킵니다. 이 일련의 과정이 보여주어야 하는 것은 당신이 하는 모든 일에는 목적이 있고 원래 정의한 목표를 달성하는 데 도움이 된다는 것입니다.

3. 구체적인 실제 운영에 중점을 둡니다.

우선 위험과 위기에 대한 강조가 문제에 대한 강조보다 훨씬 큽니다. 이는 문제 해결이 중요하지 않다는 것이 아니라 프로젝트 관리자가 위험을 관리하고 숨겨진 위험을 제거하여 위험이 실제 문제로 변하는 것을 방지하기 위해 더 많은 노력을 기울여야 한다는 의미입니다.

프로젝트 관리자는 다양한 징후와 위기를 감지할 수 있는 충분한 예지력과 예리한 통찰력을 가지고 있어야 합니다. 위기가 발생하기 전의 대응은 프로젝트 관리자가 구성원과 대화하거나 절차에 대한 교육을 조직하는 것뿐인 경우가 많지만, 위기가 발생하면 손실이 발생합니다. 위험 대응 비용보다 훨씬 클 것입니다.

프로젝트 관리자는 리더보다는 코치에 더 가깝습니다. 관리자는 위임하는 방법을 알아야 하지만, 프로젝트 관리자는 위임이 진행 상황과 품질에 영향을 미치지 않을 것이라는 점을 더 염려합니다. 따라서 프로젝트 관리자는 반드시 모든 것을 스스로 수행하거나 모든 것을 맹목적으로 위임하고 무시하는 것이 아니라 좋은 코치 역할을 합니다. 프로젝트 구성원이 일을 완료하고 책임감을 가지고 일을 완료할 수 있는 능력을 갖도록 하십시오. 스스로 하는 데는 한 시간밖에 걸리지 않지만 팀원들에게 이를 가르치는 데는 하루가 걸린다면, 팀의 관점에서 보면 이 하루는 팀원들에게 올바른 방법을 가르치는 데 소비되어야 합니다.

PMBOK의 9대 지식체계 내용은 모두 프로젝트에서 고려해야 할 내용이다. 그 키워드 중 하나가 프로젝트의 핵심 멤버들로 구성된 프로젝트 관리 그룹이다. 프로젝트 관리자가 수행하는 작업과 프로젝트 관리팀이 수행하는 작업을 명확하게 구분할 필요가 있습니다. 또 다른 우려 사항은 작업 수행의 세분성입니다. 프로젝트 작업 추적은 프로젝트 관리자의 책임이지만, 프로젝트 관리자는 프로젝트 목표에 따라 작업 추적 세분성을 결정해야 합니다. 프로젝트 구성원이나 팀 리더에 의해. 프로젝트 관리자가 해야 할 일은 간단할 수 없습니다. 프로젝트 관리자와 프로젝트 구성원을 위한 실용적인 지침

팀 내에서 팀 리더로서 당신은 다음을 수행할 것입니다.

1) 팀에 방향을 지시하지 마십시오. 목표와 정치 문제에 대한 타협

2) 팀 목표에 대한 개인적인 헌신을 보여주세요

3) 너무 많은 우선순위로 팀의 작업을 희석하지 마십시오

4) 공정하고 공평하게 팀원을 대함

5) 팀원의 성과 저하와 관련된 문제에 기꺼이 직면하고 해결합니다.

6) 직원의 새로운 사고와 새로운 정보에 대해 개방적인 태도를 취합니다.

팀원으로서 귀하는 다음을 수행해야 합니다.

1) 개인의 역할과 책임에 대한 진정한 이해를 보여줍니다.

2) 목표와 사실에 기반한 판단을 보여줍니다< /p >

　3) 다른 팀원들과 효과적으로 협력합니다

　4) 개인 목표보다 팀 목표를 우선시합니다

　5) 어떤 일이든 성공하는 데 필요한 노력을 기울이겠다는 의지를 보여줍니다. 프로젝트

　6) 기꺼이 정보와 감정을 공유하고 적절한 피드백을 생성합니다.

　7) 다른 회원이 필요할 때 적절한 도움을 제공합니다.

　8) 다음을 높이 존중합니다. 표준 요구 사항

9) 팀 의사 결정 지원

10) 팀의 성공을 위해 노력하는 방식으로 리더십을 보여주세요

11) 긍정적으로 반응 다른 사람의 피드백에 대한 응답은 이분법적인 문제로 이해되며 프로젝트 목표 및 관리 세분성과 관련된 작업을 수행하는 세부적인 문제에 가깝습니다.

IT 프로젝트 관리자의 경험 요약

나는 수년간 프로젝트 관리자로 일해 왔으며 이 일을 하면서 가장 중요한 것은 적응이 무엇을 의미하는지 이해하는 것이라고 생각합니다. 무엇이 옳고 무엇이 그른가? 프로젝트 관리자에게 가장 금기시되는 것은 완벽주의 경향이며, 특히 기술자인 경우에는 표준적인 답변을 찾는 것을 좋아합니다. 작업이 진행되고 혼란스러워집니다. 다음은 프로젝트를 진행하면서 제가 겪은 개인적인 경험 중 일부입니다. 이는 모든 사람의 지침을 위해 작성되었으며 토론 중에 함께 기술을 향상시킬 수 있습니다.

프로젝트의 시작은 가장 중요한 단계이다. 프로젝트 관리자가 새 프로젝트를 맡을 때 그는 먼저 다음과 같은 모든 측면에서 프로젝트에 대해 최대한 많은 것을 배워야 합니다.

1. 이 프로젝트는 무엇에 관한 것이며 누가 제안하는지. 어떤 문제를 해결하려고 나오나요? 많은 국내 고객이 매우 미성숙한 경우, 프로젝트 이름을 문자 그대로 보고 프로젝트의 목표를 상상하지 마십시오.

"사무 자동화"라는 프로젝트의 경우 고객이 실제로 필요한 것이 컴퓨터 생산 관리 보조 정보 시스템이라는 사실을 현장에 들어간 지 한 달 만에 발견할 가능성이 높습니다. 상황을 이해하기 위한 초기 작업이 더 자세할수록 나중에 예상치 못한 일이 줄어들고 프로젝트의 위험도 낮아집니다.

2. 투자자, 특정 비즈니스 이해관계자, 프로젝트 완료 후 운영자, 기술 감독자 등 이 프로젝트에 참여하는 사람. 소유자 단위를 제외하고 많은 프로젝트에서 구조가 매우 또한, 프로젝트 감독 회사, 발주처 산업 당국 등과 같은 일부 다른 단위도 참여할 것입니다. 프로젝트 관리자는 프로젝트에 참여하는 모든 사람이 프로젝트에 대해 어떻게 생각하고 기대하는지 이해해야 합니다. 다양한 당사자의 의견과 기대를 미리 이해하면 프로젝트에서 문제가 발생했을 때 누가 어떤 측면에서 당신을 지지하고 누가 어떤 목적으로 반대할지 분석하여 친구들과 연합할 수 있도록 미리 준비할 수 있습니다. 적들을 처치하고 원하는 대로 일을 진행하게 하세요. 영원한 친구도 영원한 적도 없습니다. 오직 일관된 관심만 있을 뿐입니다. 프로젝트 관리자로서 이 문장을 기억해야 합니다.

3. 기본적으로 고객의 상황을 이해한 후에는 다음 사항을 다양한 측면에서 이해해야 합니다. 이 프로젝트에 대한 귀하의 회사의 정보입니다. 첫 번째는 고위 리더들이 이에 주의를 기울이는지 여부입니다. 이는 회사가 리소스가 필요할 때 요구 사항에 따라 가장 강력한 지원을 제공할지 여부를 결정합니다. 리더가 구두로 지원했을 것입니다. 당신이 해야 할 일은 이 프로젝트에 대한 회사의 실제 기대를 이해하는 것입니다. 프로젝트를 더 크게 만들고 싶습니까, 아니면 단순히 돈을 벌고 싶습니까? 형식적입니까? 프로젝트에 대한 회사 리더의 태도 귀하의 태도가 이 프로젝트에 대한 전략을 결정하며, 이러한 전략적 접근 방식은 프로젝트 계획에 직접적인 영향을 미칩니다.

4. 전체 프로젝트 계획을 세우기 전에 다음을 수행해야 합니다. 또한 보유하고 있는 자원을 대략적으로 계산합니다. 첫 번째는 시간입니다. 오늘날 시장은 경쟁이 치열하며 많은 프로젝트가 거의 불가능한 시간 내에 완료되어야 하는 경우가 많습니다. 이를 위해서는 프로젝트의 리스크 관리 계획을 세울 때 이를 충분히 고려해야 합니다. 다음은 인력입니다. 프로젝트 예산과 과거 경험을 바탕으로 향후 프로젝트 팀이 맡을 역할 수를 대략적으로 계산합니다. 현재 각 역할에 맞는 인력이 있는지, 이 프로젝트에서 이를 충분히 활용할 수 있는지 여부입니다. 추가 인력 채용이 필요하며, 채용 준비를 최대한 일찍 시작하십시오. 마지막 단계는 일부 장비를 준비하는 것입니다. 프로젝트에 필요한 대형 및 핵심 장비는 가능한 한 빨리 예약해야 합니다. 장비가 사람을 기다리고 있는지 여부에 관계없이 시간이 낭비됩니다. p>

　5. 이제 프로젝트 설명을 작성할 차례입니다. 좋은 프로젝트 설명은 수행해야 할 작업(주로 수행 방법이 아닌 무엇을 수행해야 하는지)을 명확하게 설명할 뿐만 아니라 이를 확인하는 방법도 철저하게 설명합니다. 즉, 수행해야 할 작업을 명확하게 설명할 뿐만 아니라 고객의 비즈니스 담당자(일반적으로 기술을 이해하지 못하는)가 프로젝트가 어떻게 완료되는지 알 수 있도록 합니다. 간단히 말해서, 프로젝트 사양은 프로젝트가 수행하는 작업, 각 작업을 얼마나 잘 수행하는지, 각 결과를 확인하는 방법을 설명합니다.

6. 이제 마스터 플랜을 세울 때인가요? 아니요, 이제 고객의 목표와 보유한 리소스를 알고 있으므로 계획을 세우기 전에 여전히 고객과 충분히 소통해야 합니다. 자원 문제. 많은 자원이 아직 명확하지 않기 때문에 이 프로젝트의 위험과 자원에 대한 수요를 자세히 분석하기 위한 보고서를 작성해야 합니다. 일부 문제를 해결할 수 없으면 어떻게 될까요? 자원이 부족한 경우 고위 경영진은 전략을 변경하고 프로젝트에 대한 투자를 늘려야 합니다. 조건이 허락하더라도 일부 회사는 프로젝트를 포기할 것입니다. 즉, 누구도 불가능한 작업을 완료할 수 없으며, 프로젝트 관리자가 위험을 조기에 감지하지 못한다면 그는 순교자가 될 수밖에 없습니다.

7. 이제 이 프로젝트를 위해 수행해야 할 작업, 보유한 칩 및 전반적인 전략을 이해했으므로 프로젝트 팀을 구성할 차례입니다. 많은 프로젝트 관리자는 팀원을 스스로 선택할 권한이 없으므로 자신의 영향력을 활용하여 원하는 사람을 찾으십시오.

프로젝트에 따라 구성원의 구성이 크게 달라지는데, 고객의 업무에 능숙한 사람이 반드시 존재합니다. 프로젝트에는 업계 전문가(업계 전문가)가 있으므로 고객과 대화할 때 동시에 이야기하지 않고 양측이 서로를 이해할 수 있습니다. 제가 자주 보는 것은 우리 기술자들이 고객과 대화할 때 전문적인 용어를 사용함으로써 고객이 기술을 이해하지 못한다고 비난하는 것입니다. 사실 자신이 무엇을 하고 싶은지 이해하는 고객은 이미 아주 좋은 고객입니다. 자신이 무엇을 하고 싶은지, 어떻게 해야 할지 모르면서도 여전히 손가락질하고 싶은 고객은 어디에나 있습니다. 당신을 선택하는 것은 당신이 아니라 고객입니다. 당신은 고객과 함께만 돈을 받을 수 있습니다.

8. 이제 당신은 세 그룹의 사람들, 즉 리더, 팀원, 고객과 대화해야 하며 이들에게 당신이 무엇을 할 계획인지, 언제 하기를 원하는지 알려주세요. . 이런 것들을 준비하는 것이 당신의 주요 임무가 될 것입니다. 의사소통이 이렇게 중요한 만큼, 의사소통의 원칙을 미리 정의해 두는 것도 중요합니다. 많은 의사소통 원칙은 숨겨진 규칙입니다. 오랫동안 한 부서에 있었다면 이러한 규칙을 적용하는 것이 당연할 것입니다. 그러나 이제는 여러 부서, 심지어 여러 부서에 직면하게 됩니다. 의사소통 규칙을 명확하게 만드세요. 그리고 당신은 앞으로 불이익을 당할 것입니다. 다음 사항은 지루해 보일 수 있지만 실제로는 매우 유용합니다. 첫 번째는 푸시인지 풀인지 정보의 흐름 방법과 매체를 지정하는 것입니다. 추진한다는 것은 프로젝트 관리자가 정보가 모든 사람에게 전달되도록 전화, 이메일 또는 서면을 통해 적극적으로 정보를 공개한다는 것을 의미합니다. 이 상황은 소수의 소규모 프로젝트에 적합합니다. La는 프로젝트 관리자가 웹 서버와 같아서 필요한 정보를 요청할 수 있음을 의미합니다. 물론, 어떤 프로젝트 관리자도 정보를 공개 매체에 게시하여 공개하지 않을 것이며, 더 복잡한 것은 프로젝트의 공개 정보 상호 작용 영역입니다. 규칙은 내가 보낸 것이고, 읽지 않았다면 내가 말하지 않았다고 말하지 마세요. 이렇게 말하는 것이 지루해 보일 수도 있지만 실제로는 불완전한 정보 전달에 대한 책임 문제가 포함됩니다. 물론 이는 일반적인 방법이며 절대적인 것은 아닙니다. 일반적으로 리더와 적극적으로 소통하는 방법은 적극적 커뮤니케이션과 수동적 접근이 공존하는 것입니다. 두 번째 문제는 문서화입니다. 많은 사람들이 문서 작성을 두려워하지만 프로젝트 관리자는 "좋은 기억이 나쁜 글쓰기보다 나쁘다"는 원칙을 명심해야 합니다. 때로는 증거가 없기 때문에 명확하게 설명할 수 없는 이유는 무엇입니까? 따라서 프로젝트 관리자는 적어도 매주 고객이 서명해야 하는 프로젝트 관리자의 프로젝트 로그와 같은 일부 문서에 서명해야 함과 합의를 달성하는 기타 모든 사항을 처음에 고객에게 분명히 해야 합니다. 회의록, 지도자의 연설 등의 기록은 문서에 기록하고 양측이 서명해야 향후 분쟁이 발생할 경우 잘 문서화됩니다. 기억하세요: 말한 내용은 말하지 않은 내용과 동일하며 모든 사람이 기록하고 서명한 경우에만 실제로 발생합니다. 제출한 보고서와 리더(본사 리더, 고객 리더 포함)에 대한 객관식 질문 등의 문제도 있으며, 결과적으로 리더가 승인을 거부하여 어떻게 해야 할지 고민하게 됩니다. 진행을 지연시켰습니다. 이때는 기다려도 되지만, 책임자가 누구인지 기록해 두도록 주의하세요. 또한, 처음에 리더의 의견에 동의한 경우: 지시사항을 제출한 지 3일이 지나도 리더로부터 답변을 받지 못한 경우; , 이는 동의한 것으로 간주되어 귀하가 보다 적극적으로 조치를 취하게 됩니다. 또 다른 예는 다양한 이벤트에 대한 승인 프로세스 문제입니다. 프로젝트 로그에 기록되는 문제의 수준, 양 당사자의 프로젝트 관리자가 특별 각서에 서명해야 하는 문제의 수준, 양 당사자의 리더가 필요한 문제의 수준은 무엇입니까? 당사자들이 계약서 첨부 등에 서명하기 위해 나섰습니다. 미리 생각할수록 미래에는 더 적극적으로 대처할 수 있습니다.

9. 많은 사전 작업이 완료되었으며 일부 게임 규칙이 정의되었습니다. 이제 앉아서 계획을 세울 시간입니다. 이 섹션에서는 찾을 수 있는 프로젝트 관리 서적이 나보다 더 잘 설명할 것이므로 글을 덜 쓰고 내 경험에 대해 이야기하겠습니다. 첫 번째 단계는 고객 비즈니스 전문가, 시스템 분석가 등 몇 명의 핵심 팀 구성원을 찾아 프로젝트를 모듈로 나누는 것입니다.

이런 기술적인 사람들은 한 가지 면에 능숙하고, 자신의 관점에서 자신의 의견을 표현하는 경우가 많습니다. 아주 특별한 상황이 아닌 한, 그들이 제안하는 솔루션이 그들의 관점에서 가장 합리적이라고 생각해야 합니다. 당신의 강점은 우선순위를 정하고, 모든 당사자의 우선순위를 평가하고, 그들의 의견을 바탕으로 적절한(올바르지 않은) 해결책을 찾는 것입니다. 그러므로 모임에서는 모든 사람과 그들의 의견을 충분히 존중하고, 더 나은 의견을 제시하는 사람을 칭찬하고, 모임을 끝없는 논쟁으로 이끌어서는 안 됩니다. (모든 것이 흑백이 아니라는 것을 모두가 알았으면 합니다. 아아, 우리 교육이 잘못됐네요...). 회의 후에는 스스로 문서를 작성하고 결정을 내립니다. 회의에서 모든 사람의 얼굴이 관리되었으므로 자연스럽게 구현에 대한 저항이 줄어들 것입니다. 여전히 의견이 있으면 그 사람과 개인적으로 대화를 나눌 수 있습니다. 이 프로젝트에 대한 책임은 귀하에게 있으므로 위험을 감수하는 것이므로 우선순위를 판단하는 것은 귀하에게 달려 있습니다. 조직의 최고경영자는 반드시 일반 구성원보다 높은 직급을 갖고 있지는 않지만, 조직의 위험을 감수해야 하고, 정보의 비대칭성으로 인해 사물의 우선순위에 대한 판단력이 그보다 강해야 합니다. 그의 부하들 중.

개발 과정에서 내부 경영진도 주의해야 할 점은 각 작업의 최종 결과물을 점검할 수 있어야 한다는 점을 항상 강조하는 것입니다. 요구 사항: 아름답습니다. 관대하고 간결하며 명확합니다. 이 요구 사항을 어떻게 확인해야 할지 모르겠습니다. 따라서 개발팀에 작업을 할당할 때 결과를 어떻게 확인할 것인지 고려해야 합니다. 예를 들어, 이러한 작업을 위해 개발자가 EJB 프로그래밍에 익숙해지는 작업을 수행하는 계획을 본 적이 있습니다. 일부 전문 인증 시험을 치르지 않으면 결과를 확인하기가 어렵습니다. 따라서 결과를 어떻게 확인하고 고객에게 어떻게 전달할 것인지 항상 고민하는 것은 프로젝트 관리자가 항상 주의해야 할 사항입니다. 일부 오래된 프로젝트 관리자는 프로젝트를 받을 때 거꾸로 계획하는, 즉 먼저 방법을 살펴본다고 들었습니다. 합격 기준을 확인하고 승인한 후 작업 계획을 결정합니다. 많은 프로젝트가 오랫동안 시작되었지만 여전히 이를 어떻게 받아들여야 할지 모르기 때문에 프로젝트에 문제가 발생할 가능성이 매우 높습니다. 프로젝트를 하는 목적은 수용을 위한 것입니다. 우리의 역할은 연구 기관의 역할이 아닙니다. 많은 노력을 기울여 결과를 얻는 것이 우리의 목적입니다. 추가적으로 한 문장을 더 추가하고 싶습니다. 저는 개발을 위해 고객 사이트에 가는 것을 강력히 옹호하지 않습니다. 특히 다수의 기술자가 고객과 직접 소통할 경우, 기술자의 성격에 따라 갈등과 모순이 발생하기 쉽습니다. 내 접근 방식은 프로젝트 관리자와 프로젝트 구현 담당자가 현장으로 이동하고 소프트웨어 개발자는 여전히 회사에서 프로젝트를 수행하는 것입니다. 프로젝트 수행 인력은 자신의 제품과 일부 고객의 비즈니스를 이해하는 주니어 프로젝트 관리자입니다. 핵심은 일반적으로 "두꺼운 피부"로 알려진 좋은 의사 소통 능력을 갖추고 있다는 것입니다. 그들은 고객과 개발자 사이의 다리 역할을 하며, 경력 방향도 매우 유연하며, 미래에는 개발자의 진로보다 훨씬 더 다양한 방향으로 전환할 수 있습니다.

다음으로 수요 변화의 가장 골치 아픈 문제에 대해 이야기하겠습니다. 변경은 일반적으로 두 가지 유형으로 구분됩니다. 하나는 원래 목표의 부분 변경, 즉 수요의 변경이고, 다른 하나는 목표를 변경하지 않고 목표만 변경하는 것이지만 고객이 현재 구현 방법에 만족하지 않는 것입니다. , 프로세스 구현부터 인터페이스 레이아웃까지 모두 이 범주에 속합니다. 이런 상황에 직면하는 것은 피할 수 없는 일인데, 이는 사전 의사소통이 부족하고, 프로젝트가 진행됨에 따라 클라이언트가 문제에 대해 천천히 명확하게 생각하고 이전 생각을 바꾸었기 때문입니다.

이때 변경이 필요하고 전략이 이러한 상황을 허용하는 경우 다음 사항에 주의하세요.

1. 이전 결론을 기록한 이전 문서에 해당 기관의 서명이 있는지 확인하세요. 그렇지 않은 경우 즉시 작업을 중단하고 고객과 직접 계획을 확인한 다음 서명을 요청하여 향후 증거 없이 이야기하지 않도록 하세요.

2. 고객과 함께 앉아 논의합니다. 자신의 수정의 근본적인 목적이 무엇인지 토론하고 동일한 목적을 달성할 수 있지만 비용이 덜 드는 옵션이 있습니까?

3. (프로젝트의 초기 작업) 변경 사항을 명확히 하십시오. 프로세스는 일반적으로 고객이 서명할 사람을 한 명 지정하고(그렇지 않으면 고객의 모든 리더가 간섭할 수 있는 권한이 있으므로 쓸모가 없게 됩니다) 이를 공식 프로젝트 문서의 형태로 제출합니다. 비용과 일정에 미치는 영향을 분석하기 위한 평가 및 분석. 리더가 동의한 후 해당 의견서를 발행하여 주로 설계 변경 이유를 설명하고 이로 인해 발생하는 불확실한 결과를 지적합니다. 나중에 그런 일이 일어나더라도 적어도 당신의 잘못은 아닐 것입니다.) 그런 다음 고객에게 서명을 요청합니다. 병원에서 환자 수술을 수행하기 전에 가족에게 서명을 요구하는 면책 조항을 본 적이 있습니까? ;