프로젝트 관리 시험 기간 요약

시간은 빠르다, 내가 xx 회사에 왔다는 짧은 시간이 2 개월 동안 견뎌왔다. 이 기간 동안 저는 xx 회사의 열정과 발전을 매일 느낍니다. 제 동료와 함께 지내면서 저는 많은 도움을 받았습니다.이 점은 강사 루의 도움이됩니다. 익숙하지 않은 작업이나 과제를 만날 때마다 언제나지도를받을 수 있습니다. 이제 저는 xx 회사에 대한 포괄적 인 이해와 많은 동료 간의 조화와 친근감, 프로젝트 팀의 팀 의식을 느낍니다.

지난 두 달 동안, 나는 x 모듈의 필요성 토론, 데이터베이스 설계, 코드 작성 진행 관리, 그리고 x 프로젝트 xx 플랫폼의 개발 진행 관리 책임을 맡았고, 기본적으로 모든 사람과의 협력을 통해 대부분의 비즈니스 요구 사항은 해당 기간 내에 완료되었습니다. 이 프로젝트를 통해 프로젝트 관리 경험을 향상시키고, x로 많은 비즈니스 지식을 배웠으며, 프로젝트 팀의 각 구성원의 포괄적 인 품질과 작업 능력을 종합적으로 이해했습니다. 개인 사업 측면에서, 나는 대부분의 사업에 대해 심층적으로 이해하고있다. xx 평가의 관점에서, 나는 주로 x, x, x, x 및 기타 서비스를 이해합니다. 물론, 이것은 Xiao Tang, Xiao Wei, Xiao Feng 및 다른 사람들의주의 깊은지도 덕분입니다. 나는 그들에게 매우 감사하고 있습니다.

지난 x 프로젝트 구현 과정에서 프로젝트 팀의 장점과 문제점을 발견했습니다. 장점에 대해 많이 말할 필요는 없으며 모든 사람들의 노력이 더 강하다는 것이 주된 내용입니다. 프로젝트 팀의 일부 문제에 대해서는 여기에 참조 용으로 개인적인 견해를 게시합니다.

1. 프로젝트 팀 관리

현재 진행중인 프로젝트가 새로운 조합이기 때문에 회원들 사이에 너무 많은 낯선 사람과 불확실성이있어 계획 작업을 수행하는 동안 위험 통제에 대해 낙관적 인 태도를 취할 수 없습니다. 우리가 관련 계획 작업을 수행 할 때 우리는 항상 첫 번째 감각에 의존하고 있습니다. 따라서 구현 과정에서 구현 과정에 많은 지체가 있습니다. 이러한 지체, 과도한 초과 근무 및 재 작업을 보완하기 위해 초과 작업 만하면됩니다. 이는 필연적으로 프로젝트 팀의 통제하에 그룹 구성원의 만족도를 떨어 뜨릴 것이며 당연히 회사의 인식과 평가에 직접적인 영향을 미칩니다.

저는 우리가 항상 통제하고 예측할 수있는 능력이 부족하다고 생각합니다. 무엇이든 목표를 성취 할 때 항상 예측할 수없는 위험이 있습니다. 그러나 위험이 무너지기 전에 최대한 통제하는 방법은 우리가 고려해야 할 사항입니다. 그리고 통제되었습니다.

2. 프로젝트 팀의 공동 작업

프로젝트 팀의 협력에 대해 말하자면, 우리는 매우 저조한 태도를 취하고 있다고 생각합니다.이 프로젝트를 수행하는 과정에서 현재 프로젝트 팀은 고대 중국의 세 왕국과 같습니다. 매일 우리는 매우 바쁩니다. 그러나 바쁜 것은 우리 자신의 공간이며 의사 소통과 협업을위한 시간이 너무 적습니다. 기능 모듈의 실현은 사업의 만족을 극대화하는 것이 아니라 낙서에 자신의 두뇌를 사용하고, 자신의 바퀴를 만들고, 항상 고객에게 자신의 의식을 부과하는 것입니다.

과거의 코드 작성 시간에 저는 많은 동료들이 문제가 있다는 것을 항상 발견했고, 그들이 만든 모듈은 다른 사람들의 존재와 관련이 있습니다. 지금은 서로 의사 소통하고 완성해야합니다. 그러나 많은 사람들이 의사 소통을하지 않고 다른 사람들의 코드를 직접 다운로드 한 다음 자신의 필요를 추가하고 문제를 제출하고 특정 직원이 코드가 수정되어 언젠가 알려지지 않을 때까지 기다렸다가 마침내 상호 문제를 만나기를 기다립니다. 밀기 만하면 이것은 의사 소통 부족의 결과입니다.

그런데 노동의 분단, 코드 작성 과정에서 가장 중요한 것은 노동의 분업이 명확하다는 것입니다. 우리는 해당 사람들이 관련 파일을 수정할 권리가 있다는 것을 엄격히 규정 할 필요가 있습니다. 파일을 삭제하기 전에 방송해야합니다. 맹목적으로 변경, 삭제 및 추가하는 대신 작업 전에 프로젝트 또는 다른 사람에게 미치는 영향에 대해 생각합니까?

3. 프로젝트 팀 수행

실행 측면에서 볼 때 주된 이유는 사양이 너무 적고 신뢰할 수있는 표준이 거의 없다는 것입니다. 우리의 "개발 사양", "프로젝트 팀을위한 일상 행동 강령", "시스템 기술 선택 계획", "기술 스테레오 타입 평가 기준", "압력 테스트 평가 범위", "코드 검사 계획", "코드 검증" 표준, 비즈니스 프로세스 처리 지침, 프로젝트 위험 예측 보고서. 유사한 표준이있는 곳에서는 일반적인 개발 사양을 제외하고는 어떤 형식의 문서도 존재하지 않습니다.

우리는 s2, spring, ibatis, dojo와 같은 기술 프레임 워크를 선택했는데, 왜 s1, hibernate, ext 등 대신 이것을 선택합니까? 또한 우리가 선택한 방식을 분명하게 기억하고 있습니다. 테이블 가져 와서, 좋아,하지만 왜?

우리가 비즈니스 분쟁을 토론 할 때마다, 나는 항상 당신에게 한 마디를 가지고 있다고 Zhang Youli는 말했다. Li는 Li Youda를 말했다. 하늘은 말의 전쟁입니다.이 토론은 시간만큼의 시간을 낭비하지 않으며, 그 시간은 집에 돌아가는 것만 큼 좋지 않습니다.

좋은 개발 프레임 워크는 사용자의 연구 방향을 제한하고 영향을 주어야합니다. 왜냐하면 우리의 일일 코딩 기술은 프레임 워크에서 ctrl + c 및 ctrl + v를 기반으로하므로 개발 선택과 성숙을 위해 조심스럽고 지속적이어야합니다. 이 과정에서 우리가 지금 사용하고있는 프레임 워크가 확장되어야하는지 모르겠다면, 견고성, 호환성, 확장 성, 유지 보수성 등과 같은 관련 검토 지침을 제공해야합니다.

다양한 높은 동시성 및 갑작스러운 위험 관리를 처리 할 수있는 견고성 유지, 지속적인 기술 버전, 다양한 데이터베이스의 유연한 사용, 다양한 유형의 가용성 기능 확장 성, 확장 성 및 유연성으로 호환성을 업그레이드해야합니다. 변경 가능하며 유지 보수 가능성은 우리가 지속적으로 버그와 다용도를 수정해야한다는 것을 알려주고 다른 버전의 업그레이드를 완료하는 특별한 인원이 있으며 시스템 아키텍처에 중점을 둔 관련 인력은 그들이 사용하는 프로젝트 기술에 대한 전문화 프로세스를 가져야합니다. 결국 모든 것이 좋고 나쁘고 철저히 이해하지 못합니다. 개선이 필요한 부분을 어떻게 알 수 있습니까?

4. 프로젝트 팀의 조정

마지막으로, 전원 조정에 대해 이야기하겠습니다. 이것은 종종 프로젝트 계획을 구현하고 프로세스 관리를 구현하는 경우입니다. 우리가 계획을 세울 때마다 우리는 몇 명의 사람들이 할 수있는 간단한 검토 절차를 수행하기를 바랍니다. 많은 경우 계획을 세우는 사람들은 항상 자신의 아이디어와 아이디어에 따라 걷기 때문에 프로젝트를 완료하고 프로젝트에 참여한 임원들과 의사 소통을하여 계획 한 시간 내에 계획을 완료 할 수 있는지 확인해야합니다. 그리고 개정안을 토론하십시오. 과제 계획이 있고, 현재 계획의 위험성을 고려 했습니까? 그리고 연기자가 일하러 오지 않거나 하루를 그만두면 어떻게됩니까? 특정 기간의 프로젝트 시간이 회사의 집단 활동에 의해 점유되면 어떻게됩니까? 언젠가 회사가 언젠가 힘을 잃으면 어떻게해야합니까? 비슷한 질문이 너무 많습니다. 프로젝트의 위험 요소입니다. 예측할 수 없으며, B 계획을 고려해야합니까?

맹목적으로 계획하지 마십시오. 집행관에게 항상 말하지 마시고, 그냥 해고하고, 초과 근무를 끝내지 마십시오. 매우 폭력적입니다.

나는 내 생각을 너무 많이 썼는데, 그 중 많은 부분이 일방적 인 아이디어 일 수 있습니다. 현재 프로젝트 팀에게는 매우 협조적입니다. 물론, 태어난 것이나 완벽하지 않은 것이 있습니다. 천천히 개선하고 실행하십시오. 진심으로 저는 xx 회사의 큰 가족이 함께 발전하고 함께 일할 수 있기를 바랍니다.