프로젝트 매니저의 핵심은 상사, 고객, 파트너, 팀원과의 커뮤니케이션을 잘 파악하는 것입니다. 다음은 제가 축적한 내용 중 일부입니다. 잘못된 부분이 있으면 정정해 주시기 바랍니다. 1. 정보 시스템 프로젝트는 상대적으로 독특하고 진보적이며 상대적으로 복잡한 엔지니어링 정보 시스템 프로젝트라는 점을 상사에게 알리십시오. 상대적으로 눈에 띄고 고정된 속성을 가지고 있습니다. 고도로 사용자 정의가 가능하기 때문에 역동적입니다. 일단 연락을 받으면 장기전을 대비해야 하며, 회사의 모든 자원은 프로젝트팀에 우선순위를 두어야 합니다. 프로젝트 승인 지연과 고객 요구 사항의 빈번한 변경도 주요 원인입니다. 회사의 성공은 주로 프로젝트의 적절한 관리에 달려 있습니다. 2. 프로젝트 범위 및 프로젝트 목표 관리를 준비합니다. 프로젝트 범위는 표준화된 문서에 기술되어야 합니다. 고객은 대부분 자신이 원하는 것을 구두로 설명하는데, 이는 특히 정부 프로젝트의 경우 매우 비공식적입니다. 공식 문서를 작성하는 데는 능숙하지만 요구 사항을 체계적으로 표현해야 합니다. 한마디도 하기 어렵고, 설사 한다고 해도 몇 주가 걸릴 것이다. 더욱이, 프로젝트의 범위가 불분명하여 프로젝트가 진행됨에 따라 프로젝트 팀 전체의 열정이 쉽게 압도될 수 있습니다. 양측 모두 프로젝트가 초기 범위와 계획된 완료를 심각하게 초과하여 커지고 있다고 느낍니다. 날짜. 오늘의 기능은 완벽하지 않지만, 내일의 기능은 다듬어져야 합니다. 시간이 지나면서 개발 엔지니어들은 자신의 능력을 의심하기 시작했습니다. 프로젝트의 어느 단계인지, 프로젝트의 범위와 목표를 표시하고, 프로젝트 범위를 초과하는 경우 수행할 작업을 문서에 표시하는 것이 가장 좋습니다. 고객이 사용하는 사업부서와 고객 리더의 서명이 있어야 합니다. 고객께서 계약을 기피하는 사유가 있는 상황이 있을 수 있으니, 이는 회사의 프로젝트 절차 및 규정임을 납득시켜 주시기 바랍니다. 3. 고객 요구 사항의 변화를 엄격하게 통제하고 모든 변경 사항이 구현되어야 하는 것은 아니며 구현될 수 있다는 점을 고객에게 알려줍니다. 프로젝트는 궁극적으로 클라이언트에 의해 사용됩니다. 때로는 고객이 제기한 요구 사항이 다소 이상하고 비현실적이거나 구현 비용이 당분간 매우 높다는 사실을 발견한 적이 있습니까? 그런 다음 확고한 태도로 그들이 하는 일을 하면 어떻게 될지 말해야 하며, 그러면 비용, 일정, 품질과 관련된 실질적인 문제가 발생할 수 있습니다. 우리가 전반적이고 중요하며 필요한 문제를 해결하는 데 중점을 두고 있는 시스템 솔루션 제공자라는 느낌을 주십시오. 게다가 Microsoft에는 아직 패치가 있습니까? 고객의 요구에 맞춰 구현하는 정책은 "모두 기록하고, 모두 평가하고 제어하고, 일부를 구현하고, 모두 수용"하는 것입니다. 넷째, 고객에게 관련 담당자를 제공하고 필요한 "통합" 사항을 구성하도록 요청해야 합니다. 일부 고객 내가 아는 것은 원하는 것을 말한 다음 완료 날짜를 요청하고 때가되면 사용하는 것뿐입니다. 그 이후에는 그 사람과 아무 관련이 없는 것 같았습니다. 클라이언트는 결국 비즈니스 부서의 직원일 가능성이 높습니다. 그런 다음 용기를 갖고 마지막 프로젝트 시작 회의에서 리더가 프로젝트에 대한 책임을 발표했다고 그에게 말하십시오. 그리고 실제 업무상의 어려움을 그에게 말하십시오. 더 이상 머뭇거리고 회피하기는 어려울 거라 믿습니다. 5. 개발 엔지니어가 "나가서" 연구를 완전히 이해하게 하세요. 고객과 소통할 때 연구가 시간 낭비라고 생각하지 마세요. 편리하다면 여성 동료를 데리고 가세요. 너무 사소하게 여기지 마세요) 여성 동료들과 개발 엔지니어들을 보세요. 나는 동의하지 않습니다. 연구원들 사이에는 프로젝트 관리자와 요구 사항 분석가라는 두 가지 역할만 있습니다. 설문조사의 문제점에 대한 분석 보고서를 생성해야 합니다. 그리고 연구 내용을 바탕으로 핵심, 어려움, 핵심 이슈를 빠르게 제시할 수 있습니다. 이러한 방식으로 개발 엔지니어는 핵심 모듈에 대부분의 에너지를 집중하고 핵심 모듈을 더 효과적으로 개선할 것입니다. 우리 각자는 개발 엔지니어가 코딩 기술과 기능 구현에 더 많은 관심을 갖고 있습니다. 설문 조사에 참여하는 개발 엔지니어 대표는 설문 조사가 개발을 안내하고 비즈니스 요구 사항과 개발 간의 단절을 더 잘 피할 수 있도록 보장할 수 있습니다. 게다가 사용자가 말하고 생각하는 것을 실제로 느끼게 해주세요. 또한 때로는 고객 요구 사항의 표현이 불분명하고 변경 가능하다는 점을 이해하게 하십시오. 수요 분석가와 연구자가 의도적으로 개발 엔지니어를 당황하게 만드는 경우는 일반적으로 발생하지 않습니다. 매일매일 제품 품질 개선을 외치며 사용자 입장에서 생각하는 것보다 훨씬 낫습니다.
6. 구현을 준비하고 먼저 시스템을 "승리"하기 위해 "실행"하십시오. 일단 시스템이 준비되면 사람들은 이를 사용해야만 시스템의 가치와 회사의 신뢰성을 얻을 수 있다고 믿습니다. 반영되다. 시스템을 활용해야만 프로젝트 매니저로서의 가치가 반영될 수 있습니다. 따라서 우리는 고객이 먼저 데이터를 수집할 수 있도록 가능한 모든 조치를 취할 수 있는 방법을 찾아야 합니다. 데이터가 들어오면 이니셔티브는 우리 손에 있습니다. 다양한 후속 수정은 더 이상 시스템의 불완전한 기능을 나타내지 않습니다. 더 중요한 것은 회사에서는 당신이 이전에 했던 다양한 변화와 수정이 회사에서 의미가 있다고 생각할 것이라는 점이다. 데이터를 수집하기 위해 온라인에 접속하기 전에 모든 기능을 다듬지 말고 완벽해질 때까지 기다리십시오. 성공 가능성은 매우 낮고, 떠나는 날까지 시스템 기능은 그대로 수정될 가능성도 있지만 고객의 비즈니스 데이터에 대한 지원이 없기 때문에 의미가 없게 됩니다. 크고 작은 많은 프로젝트에는 구현 방법론이 부족합니다. 나는 많은 소프트웨어 회사를 만났습니다. 영업사원과 소프트웨어 엔지니어라는 두 가지 역할만 있으며 전담 구현 엔지니어는 없습니다. 어쩌면 프로젝트가 작다고 생각하지 않을 수도 있지만, 프로젝트의 규모가 조금 커지면 문제가 드러날 것입니다. "3개는 발전이고 7개는 실행이다"라는 말이 있듯이. 시스템의 대부분의 기능을 테스트한 후 먼저 실행하는 것이 좋습니다. 일부 사소한 수정, 중요하지 않은 목표는 "실행 후" 업그레이드로 처리됩니다. 이런 방식으로 일부 기능이 충분히 상세하지 않더라도 고객과 상사에게 프로젝트가 예상한 목표를 달성했음을 안전하게 알릴 수 있으며 심지어 성공했다고 말할 수도 있습니다. 7. 개발 과정 중 사용자 협의 회의에 대해서는 프로젝트 매니저 또는 개발사의 담당자가 주도적으로 회의 진행을 진행해야 합니다. 고객이 참석하는 모든 프로젝트 회의에서 시스템을 소개한 후 고객의 리더는 종종 자신의 의견을 표현하게 되는데, 그 중 일부는 시스템 기능과 관련되고 일부는 관리 메커니즘, 작업 흐름, 심지어 작업 측면까지 포함될 수 있습니다. 고객의 기능 부서. 봄 축제 갈라조차도 동의하기 어렵습니다. 주제에서 벗어나면 제때에 다시 가져오세요. 이러한 의견 중에는 프로젝트에 방해가 될 수 있는 높은 의견도 배제되지 않습니다. 회의는 너무 길지 않아야 합니다. 정보 시스템과 관련된 회의의 경우 주제는 "당신이 개발하는 시스템은 무엇이며, 시스템이 이를 위해 무엇을 할 수 있으며, 실제 시스템을 어떻게 구현하고 최적화하는지"라는 중심 아이디어에서 벗어나서는 안 됩니다. 비즈니스 프로세스?" 너무 많은 데모를 사용할 필요가 없습니다. 계정, 개발된 정보 시스템 운영. 그들의 토론은 너무 길면 안 됩니다(약 40분 정도). 회의 후에는 가능한 한 빨리 회의 보고서를 작성해야 하며 회의 중에 전담 담당자가 현장에서 Word 문서를 준비하도록 하는 것이 가장 좋습니다. 그 자리에서 서명을 한 뒤 퇴장을 요청했다. 회의를 녹화한 후 회사로 돌아와 프로젝트 팀의 모든 구성원과 고객 지원자를 소집하여 회의록에서 관련 문제를 평가 및 통제하고 최종적으로 고객 요구 변화 평가 및 통제 문서를 작성합니다. 아카이브(3개 사본, 1개는 고객에게 확인용으로 제출, 1개는 회사 사업부로 제출. 물론 1개는 본인이 보관해야 합니다. 사장님께서 진행 상황을 확인하실 때 보관하시면 좋을 것 같습니다. 설명).