프로젝트 관리에 대한 요약과 반성은 성공적인 회사로서 불가피하다. 요약 과정에서 어떤 장점과 단점이 드러나야 빠른 개선과 최적화가 가능하기 때문에 요약과 반성이 필수적이다. 다음은 프로젝트 관리의 요약과 반성을 공유해 보겠습니다.
프로젝트 관리에 대한 요약과 반성 1 은 이미 1 년 동안 프로젝트와 함께 해왔다. 이 기간 동안 나는 기술과 관리 경험 방면에서 많이 성장했다고 느꼈다. 프로젝트 팀 전체에서 나는 프로젝트 매니저이지만 가장 힘든 일이다. 그러나 나는 이런 느낌을 더 즐긴다.
이 기사는 올해이 프로젝트를 관리하는 방법을 요약합니다. 여러분이 다 보고 좋은 건의를 해 주시기를 바랍니다.
첫째, 회사는 사업 단위에 속하고, 안에 있는 직원들은 대부분 다년간 근무한 노사원이기 때문에 평소 회사의 업무 분위기가 좋지 않고, 일이 게을러지고, 지각하는 현상이 더욱 심각하다. 효과적인 근무 시간을 하루 5 시간 유지하는 것이 좋다. 물론, 나는 이런 부류에 속하지 않는다. 나는 여러 차례 지도자에게 이런 현상을 반영했지만, 지도자는 합리적인 해결책을 제시하지 않았다.
분담하기 전에, 프로젝트 팀은 항상 어떤 사람에게 좋은 임무를 배정하고, 그 다음에는 상관하지 않고, 공사 기간에도 많은 제한이 없다. 직원들이 게으르기 때문에 회사도 이런 게으른 상태에 익숙해져 프로젝트마다 공사 기간이 오래 끌린다.
내가 프로젝트를 관리한 후, 지도자는 나에게 이런 상황이 바뀌어야 한다고 말했고, 그래서 우리는 명확한 분업제도를 시행했다.
1. 프로젝트 시작 시 프로젝트를 작은 기능 점으로 분할합니다.
2, 모든 작은 기능. 프로젝트 팀의 모든 사람에게 나누어 공사 기간을 분명히 하다.
실제로 프로젝트를 분할하고 작업량을 추정하는 것은 매우 어렵습니다. 프로젝트를 분할할 때, 나는 대체로 실현 사고를 이해했다.
나는 프로젝트 팀 구성원을 나누었다. 제가 처음으로 분업과 근무시간을 발표했을 때, 사람들은 놀라움을 금치 못했습니다. 왜냐하면 제가 나누는 시간이 거의 짧기 때문에 모두가 다 끝내지 못할 줄 알았기 때문입니다. (데이비드 아셀, Northern Exposure (미국 TV 드라마), 일명언) 하지만 결국 내가 예상했던 시간 안에 완성했다. 이 프로젝트는 모두의 시간 활용도와 모두의 업무 효율성이 크게 향상되었다.
내가 관리하는 프로젝트에서, 나는 주로 다음과 같은 일을 한다.
1, 수요 도킹, 전체 기술 선택 및 데이터베이스 설계
2. 프로젝트 진행 관리
3, 프로젝트 팀 구성원 분업
4, 프로젝트 생성, 핵심 코드 및 일부 기본 코드 작성.
후자의 프로젝트에서, 회사의 수요측은 사실 그다지 책임을 지지 않는다. 기본적으로 전체 프로젝트의 모든 작업은 우리 프로젝트 팀이 수행했으며 프로토 타입지도는 좋은 피드백을 받지 못했습니다. 간단한 프로토타입을 그리는 도구인 Balsamiq Mockups 3 를 추천합니다. 간단하고 사용하기 쉽고, 나도 계속 쓰고 있다.
이러한 프로젝트를 통해 우리는 또한 몇 가지 문제를 발견했습니다.
1. 프로젝트 팀 구성원 간의 의사 소통이 부족합니다. 한 가지 방법은 기능은 같지만 쓴 버전은 다르다.
2. 개인적으로 가장 어려운 것은 프로젝트 팀의 일부 노직원들이 나보다 몇 년 더 일했다는 것이다. 때로는 화를 내기도 하고, 회의 때는 핸드폰만 쳐다본다. 이런 상황은 나도 말할 수 없다. 관계를 악화시킬 뿐이다. 물론, 나의 지도자가 이런 상황을 반영한 것처럼, 나는 지금까지 이렇게 한 적이 없다. 왜냐하면 나와 지도자의 관계는 다른 사람이 좋지 않기 때문이다.
프로젝트 관리의 총결산과 반성 Part 2 는 회사의 고위 관리자로서 지난 한 해 동안의 일을 총결산한 후 할 말이 많습니까? 이런 의혹이 있었나요?
1, 벌금은 쓸모가 없습니다.
벌금은 풀뿌리 관리자에게 유용하다. 기층 직원에 대해서는 처벌해야 할 뿐만 아니라, 명백하게 처벌해야 한다. 하지만 당신이 고위 관리자라면 부하 직원을 처벌하는 것은 소용이 없다는 것을 알게 될 것이다. 어린아이가 잘못을 저질렀듯이, 부모는 큰길로 가득 차서 너를 쫓아다니지만, 네가 어른이 되면 그들은 그만두었다. (윌리엄 셰익스피어, 햄릿, 가족명언)
부하 직원은 기계가 아니기 때문에, 특히 당신이 주관하는 것은 실제 업무에 종사하는 직원이 아니라 다음 수준의 관리자이기 때문이다. 벌금의 효과가 매우 낮다.
모두들 벌금이 청천벽력이라고 생각하는 것 같은데, 상대방이 벌금을 두려워하면 당연히 일정한 책임을 져야 한다. 사실 이것은 당연한 것이다! 이런 방법이 유용하다고 생각할 때, 벌을 받는 사람의 마음가짐은 바로' 벌해, 어차피 돈을 벌면 뭘 더 원해?' 이다. " 나는 이 수업을 전혀 마음에 두지 않았다.
2. 민주주의와 비열함은 차이가 없다
민주주의는 실제로 대부분의 사람들의 의견을 경청하는 것입니다. 각박한 것은 사실 소수의 사람들의 의견을 듣는 것이다. 표면적으로 보면 민주주의가 더 안전한 것 같다. 사실 그렇지 않습니다. 대부분의 사람들은 어리석고 소수만이 똑똑하다는 것을 깨달아야 한다.
만약 임원이 민주적 관리를 신봉한다면, 기본적으로 그는 아무것도 할 수 없다. 그러나 만약 한 사람이 모든 것에 인색하다면, 그는 아무것도 할 수 없다.
따라서 임원은 내성적인 기질을 가져야 한다. 우리는 어떤 일은 무대에 올려놓고 민주적 방식으로 실천해야 한다는 것을 이해해야 한다. 어떤 일은 마음속에 기억하고 비밀리에 진행해야 한다.
3. 인재는 말을 듣지 않는 사람이다.
만약 한 사람이 말을 잘 듣는다면, 이 사람은 거의 쓸모가 없다.
진정한 재능이 있는 사람만이 너를 태울 것이다. 이것은 수천 년 동안 변하지 않는 법칙이다. 진정으로 재능이 있는 사람은 모두 자부심을 가지고 있다. 그는 네가 그를 해고하는 것을 전혀 두려워하지 않는다. 왜냐하면 그는 재능이 있어서 마음대로 나가면 일자리를 찾을 수 있기 때문이다.
고위 경영진은 매일 말을 잘 듣는 사람과 스스로 고민할 필요가 거의 없다. 이런 일은 기층 주관이 쉽게 해결할 수 있지만, 규율에 따라 가르치는 것에 지나지 않기 때문이다. 무슨 어려움이 있습니까? 고위 경영진의 어려움은 진정으로 재능 있는 사람들을 설득하는 데 있다. 이것이 주요 작업이다.
4, 문제를보십시오, 우리는 더 깊이 생각해야합니다.
한 사람, 사과를 보면 사과인 것 같아요. 이 사람은 기층 직원이다.
한 사람이, 사과를 보면, 이것이 누구의 사과인지 생각할 것이다. 이 사람은 기층 주관이다.
한 사람, 사과를 보면, 이 사과가 어떻게 여기에 있을까? 이 사람은 고위 주관이다.
한 사람이 사과를 보면 이런 사과는 가치가 없다고 느낄 것이다. 이 사람이 바로 사장이다.
5. 좋은 사람은 하기 어렵다
혼자서 나쁜 사람이 되는 것은 사실 매우 간단하다. 능력이 없는 사람은 나쁜 사람이 될 것이다. 능력 있는 사람만이 더 잘하려고 노력할 수 있다. 나쁜 사람이 되고, 아무런 걱정도 없이, 어떤 사람에게 큰 소리로 외치고, 직원들에게 일을 강요하는 것은 잔인하고 우렁찬 소리일 뿐이다.
고위 주관은 좋은 사람이 되는 데 능하다. 좋은 사람이 되기는 어렵다. 왜냐하면 네가 한 사람에게 좋기 때문이다. 모두가 네가 그에게 잘해 주길 바란다. 나쁜 사람은 이런 걱정이 없다. 너는 한 사람에게 좋지 않으니, 모두들 나에게 좋지 않다고 생각한다. 그래서 나쁜 사람은 간단하다.
6. 대국에서 출발하는 데 능하다
임원은 항상 이해해야 한다: 네 차례가 되면 모든 일이 반드시 큰 문제이므로 해결하기 어렵다. 표면적으로 보면 간단할 수도 있습니다. 아래에 풀뿌리 임원들이 있고, 그들은 문제를 쉽게 보고하지 않기 때문입니다. 왜냐하면 당신이 의문을 제기하고 비난할 것이기 때문입니다. (존 F. 케네디, 공부명언)
따라서 고위 임원은 어떤 결정을 내리기 전에 심사숙고해야 한다. 왜 이러는 거야? 더 적합한 방법이 있습니까? 만약 회사에 이 방면의 규정이 있다면, 왜 기층 주관은 회사의 규정에 따라 하지 않고 에 업로드합니까? 회사의 규정이 실제 상황에 맞지 않습니까? 다른 사람들은 이 일에 대해 어떻게 생각합니까? 모두 고려해야 할 것이다. 본선과만 하는 것이 아니다. 그것은 어리석은 주관의 방식이다.
7. 학습과 발견에 능하다
이것은 고위 관리자에 대한 요구일 뿐만 아니라, 기층 관리자에 대한 요구이기도 하다. 다만 임원은 한 사람이 영화를 볼 때 한 줄의 좌석 가운데에 앉아 있는 것과 같다. 만약 그가 일어나 화장실에 간다면, 옆에 있는 사람들은 모두 따라갈 것이고, 맨 끝에 앉아 있는 사람은 화장실에 가면 거의 아무도 방해하지 않을 것이다. 다른 이유는 없습니다. 임원의 위치는 그가 같은 일을 한 결과를 결정한다.
기층 관리자가 학습 능력이 부족하여 부하 직원의 장점을 제때에 발견할 수 없다면, 영향은 그리 크지 않을 수도 있고, 팀을 이끌고 전쟁터를 통과할 수도 있다. 그러나 고위 관리자로서 직원이나 부하 직원의 플래시 포인트를 제때에 배우고 발견할 수 있는 능력이 부족하면 팀에 미치는 영향은 치명적일 수 있습니다.
한 팀, 한 기업이 비약적으로 발전하려면 햇빛과 긍정적인 마음가짐이 필요하다. 수시로 부하 직원의 반짝이는 점을 적시에 발견하는 것은 바로 햇빛 심리의 좋은 전달이다. 간단하고 진실한 칭찬일 뿐 부하들을 울게 할 수도 있다. (윌리엄 셰익스피어, 햄릿, 겸손명언) 유황숙이 장팔로 아두를 바닥에 놓았을 때, 그는 조운에게 말했다. "이 소년이 나를 좀 다치게 해줘." 。 결론적으로, 이 동작은 향후 50 년 동안 자룡의 간과 뇌를 바꾸었다. 왜 안돼?
8, 강인함, 강인함, 강인함
상식이 있는 모든 사람들이 잘 알고 있는 화제다. 성공하려면 강인해야 한다는 것을 누구나 다 알고 있다. (조지 버나드 쇼, 성공명언) 하지만 대부분의 사람들이 다른 사람이 성공하는 것을 지켜보는 이유는 자신이 강경해야 한다는 것을 알고 있지만 어떻게 강경해야 할지 모르기 때문이다. (윌리엄 셰익스피어, 햄릿, 성공명언)
세계관은 옳지만 방법론이 잘못되어 목표를 달성할 수 없다. 모든 사람은 심리적 최종선을 가지고 있지만, 어떤 사람은 최종선이 더 높고, 어떤 사람은 최저선이 더 낮다. 어떻게 하면 자신을 강하게 만들 수 있을까?
아주 간단합니다. 상황이 얼마나 어려워 보이든, 곤경이 얼마나 절망적이든 간에, 우리는 가장 작은 전환점의 가능성을 찾기 위해 최선을 다해야 한다. 나는 이 가능성이 스펀지의 물과 같다고 믿는다. 우리가 찾기만 하면 반드시 있을 것이다. 그런 다음 이 가능성은 운영가능한 방안을 통해 전개되고 전개되면 수출이 나타난다. 이 모든 것은 관리자의 강인함에 달려 있다.
프로젝트 관리에 대한 총결산과 사고는 작년부터 XX 프로젝트의 건설과 관리에 전면적으로 참여했다. 지금까지 프로젝트는 기본적으로 종료되었으며, 다음 단계 항목은 곧 시작될 것이다. 이제 프로젝트의 득실을 총결하여 다음 단계의 프로젝트 건설을 지도하고, 범한 잘못을 재범하지 말아야 한다. 좋은 방법은 유지하고 발양해야 한다.
첫째, 프로젝트의 성공
1, 프로젝트 진행 관리가 더 좋습니다.
본 프로젝트의 진도관리는 비교적 좋으며, 심각한 진도 지연은 발생하지 않고, 주로 주회+월회+프로젝트 심사 제도를 시행하였다. 프로젝트 팀은 매월 말에 월회를 개최하는데, 주로 지난달 작업 목표 완성을 총결하고 다음 달 작업 목표를 공동으로 제정하는 것이다. 월별 작업 목표 달성을 보장하기 위해 월별 작업 계획을 주간 작업 계획으로 분할하고 주간 정기 회의를 형성하여 프로젝트 목표 달성을 추적하고 모니터링합니다. 월회와 주회를 제외하고 프로젝트 팀을 동시에 심사하고, 월별 작업 목표를 완료하지 않으면 심사 점수를 공제한다. 세밀한 진도 관리는 감독 심사 메커니즘과 결합하여 기본적으로 프로젝트의 진도를 보장할 수 있다.
일부 관리 시스템이 수립되었습니다.
프로젝트 구현 과정에서 일상적인 업무에서 표준화되지 않고 혼란스러운 부분에 대한 관리 메커니즘이 마련되어 있으며, 주로 다음과 같은 측면에서 나타납니다.
(1) 새로운 비즈니스 요구 사항 대응 메커니즘
새로운 비즈니스 요구사항이란 업무 부서가 일상적인 업무 과정에서 제기한 시스템 최적화 요구사항으로, 프로젝트 건설 과정에서 프로젝트 수요에 포함되지 않습니다. 과거에는 프로젝트 팀이 새로운 비즈니스 요구 사항을 처리하는 과정이 혼란스러웠으며, 새로운 비즈니스 요구 사항은 종종 프로젝트 팀의 머릿속에 존재했습니다. 시간이 지나면서 어떤 업무 부서가 어떤 요구를 제기했는지, 심지어 수요가 실현된 후에도 피드백 메커니즘이 없어 업무 부서의 인식을 뛰어넘었다. 프로젝트 구현 과정에서 이 문제를 해결하기 위한 새로운 비즈니스 요구 사항 대응 메커니즘이 마련되었습니다. 새로운 비즈니스 요구 사항을 받은 후 요구 사항 설명, 요구 사항 제출자 등과 같은 요구 사항에 대한 정보를 기록해야 합니다. 수요를 받은 후, 즉시 수요 제출자와 수요를 확인하고, 수요 접수에 대한 피드백을 받고, 수요의 계획 완료 시기를 알려야 합니다. 새로운 비즈니스 요구 사항이 온라인으로 개발되면 요청자에게 온라인 피드백 양식을 보내 요구 사항이 충족되었음을 알릴 필요가 있습니다.
수요 접수부터 최종 발표 후 피드백까지.
(2) 온라인 메커니즘
역사적인 이유로, 우리 프로젝트 팀 관련 업무의 규범성은 BOSS 만큼 좋지 않으며, 온라인 시스템도 규범적이지 않다. 예전에는 프로젝트 팀이 온라인에 접속하고 싶었기 때문에 시스템의 안정성과 안전성에 큰 위험이 있었다. 시스템 온라인 프로세스를 표준화하기 위해 BOSS 측과 도킹하고 온라인 프로세스를 구축하여 한 달에 두 번 온라인 접속을 허용합니다. 온라인 전에 요구 사항, 설계, 테스트, 온라인 위험 평가 보고서 등의 문서를 제공해야 하며, 온라인 신청은 리더십 사무실에 제출하여 승인을 받아야 합니다. 승인이 통과된 후에야 개방자가 온라인에 접속할 수 있고, 온라인 후 온라인 추적 분석 보고서를 제출해야 한다.
(3) 의사 소통 메커니즘
월회, 주회제도가 수립되어 각 회의가 끝난 후 회의에서 달성된 * * * 지식은 회의록 형식으로 발부되어 후속 측정과 관련 결정의 집행 여부를 평가하는 근거로 사용되었다. 이전 프로젝트 팀도 정기적으로 회의를 했지만 회의에서 해결해야 할 문제는 종종 잘 논의되었지만 회의 후 실제로 하지 않아 회의가 한 가지 형식이 되었다.
(4) 시스템 운영보고 시스템
이전 프로젝트 팀은 시스템 애플리케이션 홍보에 거의 관심을 기울이지 않았습니다. 기능이 온라인 상태에서 완료되어도 이 기능이 사용되었는지, 전체 시스템이 어떻게 적용되었는지 알 수 없는 경우가 많습니다. 프로젝트 기간 동안 Dell 은 시스템 운영 월보 제도를 구축하여 시스템의 중요한 응용 프로그램 사용을 월보 형식으로 리더와 관계자에게 전송했습니다.
둘째, 프로젝트의 단점
1. 프로젝트 계약에 대한 통제가 부족하여 후속 관리에 숨겨진 위험을 초래합니다.
회사의 IT 시스템 계약은 다른 부서에서 관리하며, 우리 부서는 주로 구체적인 시스템 건설을 담당하고 있기 때문에, 본 프로젝트에서 우리는 프로젝트의 계약에 대한 중시가 부족하고, 프로젝트의 계약 내용에 대한 통제가 부족하다. 주로 다음과 같은 측면에 반영됩니다.
(1) 계약의 공사 내용은 원보건안의 내용과 자세히 대조되지 않았다. 우리가 포함하고자 하는 일부 건설 내용은 계약에 반영되지 않아 결국 소프트웨어 공급업체와의 다툼으로 이어졌다. 소프트웨어 공급자가 계약을 예로 들자면, 이것은 치명적인 문제이다. 결국, 두 부서의 프로젝트 계약 연결에 문제가 생겼다.
(2) 프로젝트 팀 구성원은 신중하게 확인하지 않았다. 그들은 계약을 볼 때 이 문제를 발견했지만 상대방이 우리 회사의 장기 파트너이기 때문에 이런 작은 문제들은 별로 신경 쓰지 않았다. 지금 보기에, 이 원칙적인 문제는 무시할 수 없다.
(3) 프로젝트 계약서에 서명할 때, 우리 회사는 통상 프로젝트가 포함된 심사 규칙 파일을 요구한다. 이 프로젝트를 할 때, 우리는 어떻게 평가할지 자세히 고려하지 않았다. 그래서 계약서에 매우 일반적인 평가 규칙 파일을 넣었지만, 이 일반적인 평가 규칙은 여러 곳에서 이 프로젝트에 적합하지 않아 후속 실제 평가 작업에 문제가 생겼는데, 이러한 문제는 평가 규칙에 명확하게 설명되지 않아 구체적인 집행에 근거가 없어 쉽게 나타난다.
2. 새로운 비즈니스 개발 모델
이 프로젝트의 수요가 비교적 분산되어 있기 때문에 프로젝트 구현에 새로운 비즈니스 개발 모델, 즉 각 기능 모듈이 순차적으로 개발되고 각 기능 모듈은 수요 분석, 설계, 개발, 온라인 등의 단계를 거쳐야 합니다. 반복 개발 모델과 비슷하다. 그러나 이 모델에는 몇 가지 문제가 있습니다. 첫째, 각 반복이 너무 세밀하게 나누어져 거의 매달 수요, 설계 및 온라인 작업이 발생합니다. 둘째, 이러한 개발 모델은 시스템의 전반적인 제어 능력이 부족하게 한다. 일부 관련 기능 모듈은 요구 사항과 설계를 균일하게 고려해야 하지만 인위적으로 여러 단계로 나뉘어 현재는 미래를 고려하지 않고 기존 기능 모듈에 영향을 미치기 때문일 수 있습니다. 셋째, 이러한 개발 모델을 통해 프로젝트 관리자는 전체 프로젝트의 중심이 어디에 있어야 하는지 알 수 없습니다.
이 개발 모델은 프로젝트의 다음 단계에서 개선이 필요하며 더 이상 이 모델을 채택할 수 없습니다.
3, 건설 프로그램 설계 및보고 능력이 부족합니다.
본 공사 시공 계획은 주로 감독이 완성한다. 이상적으로, 나는 방안을 쓸 것이고, 주관은 약간의 지도와 의견을 제공해야 비로소 직무에 적합한 셈이다. 계획이 끝난 후 지도자에게 보고하는 것은 그다지 성공적이지 못했고, 앞뒤에는 세 번의 보고만 통과했다. 이것은 매우 심오한 교훈이므로 흡수해야 한다.
4. 요구 사항 문서 및 설계 문서의 규범
수요 문서와 설계 문서의 표준화 문제가 줄곧 나를 괴롭히고 있다. 이 프로젝트뿐만 아니라 다른 프로젝트에도 같은 문제가 있다. 제가 현재 참여하고 있는 프로젝트로 볼 때, 수요와 디자인은 거의 할 수 없습니다. 요구 사항 문서 및 설계 문서에는 어떤 내용이 반영되어야 하며, 요구 사항 및 시스템 설계를 명확하게 설명할 수 있도록 어떻게 더 잘 표현할 수 있습니까?
응용 및 홍보의 중요성이 충분하지 않습니다.
시스템 구축의 목적은 무엇입니까? 그 목적은 시스템이 회사에 가치를 가져다 줄 수 있기를 바라는 것이다. 그렇다면 어떻게 가치를 반영할 수 있을까요? 시스템은 회사의 업무 발전을 지원하여 가치를 구현함으로써 회사의 수익 성장을 실현합니다. 그렇다면 시스템은 실제로 업무 부서에서 사용해야 역할을 할 수 있다. 이 프로젝트의 건설 과정에서, 나는 응용 보급의 중요성을 깨달았지만, 구체적인 응용 보급 작업은 여전히 충분치 않았다. 나는 시스템을 구축 하기 위해 시스템을 구축 하는 것, 그리고 가장 중요 한 것은 건설 작업을 완료 하는 것입니다 생각 합니다. 쓸모가 없는 것은 내 일이 아니다.