다른 직원이 남긴 프로젝트를 어떻게 관리합니까? [닫은]

어떤 사람은 갑자기 회사를 떠납니다. 이제 그의 작업이 완료되어야하고 당신은 그것을 할당 받고 있습니다. 자신이 무엇을했는지 모를 때 (90 % 또는 9 %) 남은 음식을 어떻게 관리합니까?

1. 처음부터 시작할까요? 90 % 완료되면 어떻게됩니까?
2. 그가 한 일을 이해하려고 노력해야합니까? 말도 안된다면?

무엇을해야하는지 파악하기 위해서는 자신이 무엇을하고 있는지 그리고 그 모양이 얼마나 좋은지 알아야합니다.

모든 소스를 빠르게 살펴보고 가지고있는 것을보십시오. 생생하게 분명하다면 누락 된 부분을 마무리하는 것이 가장 쉬운 방법입니다. 작동하는 것과 작동하지 않는 것을 찾기 위해 단위 테스트를 수행하십시오.

명확하지 않은 경우 새로운 단위 테스트와 함께 작동하는 것을 파악하십시오. 이것이 불가능한 경우, 팀 리더에게 문제가 있으며 문제를 해결할 수 없다는 사실을 알리십시오. 그런 다음 왼쪽 작업을 복구해야하는지 또는 너무 나빠서 다시 실행해야하는지 결정할 수 있습니다.

다른 사람들이 쓴 것 외에도 그 사람과 직접 접촉 한 사람과 이야기하는 것이 좋습니다. 나는 당신이 당신의 설명에서 그가 혼자 일하고 있다는 것을 이해합니다. QA 직원이 자신이 생산 한 것을 테스트했을 수도 있습니다.이 사람들은 (일반적으로) 최소한 떠나기 전에 프로젝트를 어느 정도까지 수행했는지 대략적인 아이디어를 가지고 있어야합니다. 물론 그가 제공 한 정보 / 제품은 완전히 신뢰할 수없는 것으로 판명되어 해고에 기여했습니다.

이를 관리자와 논의하고 남은 코드의 초기 탐색 / 테스트와 사양 및 요구 사항을 이해하기위한 시간 범위를 할당하십시오. 이것은 몇 사람의 월 규모의 프로젝트, 한 명 이상의 사람이 한 해의 프로젝트 등을 위해 최대 일주일에 대략 하루가 될 수 있습니다.

이 초기 탐색 후 대략적인 추정치가 있어야합니다.

• 제품이해야 할 일,
• 현재 무엇을 할 수 있고 얼마나 잘하는지,
• 처음부터 다시 작성하는 데 걸리는 시간과 위험,
• 이미 완료된 작업을 완료하는 데 걸리는 시간과 위험

그런 다음 관리자와 다시 앉아서 결정을 내릴 수 있습니다.

내 경험상 이것은 드문 상황이 아닙니다. 불행히도 여기 에는 두 가지 문제가 있습니다 .

1)이 프로젝트의 남은 부분 2) 처음에이 혼란에 빠진 이유

(1)의 경우 프로젝트의 크기 / 복잡성을 고려해야합니다. 일주일이면 다시 시작해야 할 것입니다. 1 년 분량의 작업 인 경우 기존 코드에서 구할 수있는 것이 무엇인지 확인해야합니다.

어느 쪽이든, 즉시 다음 단계를 수행해야합니다.

a) 관리자에게 큰 문제가 있다고 말하십시오.

b) 프로젝트 사양을 확보하고 달성해야 할 사항을 철저히 이해하거나 사양이없는 경우 프로젝트 스폰서와 대화하십시오.

C) 등 관리자 / 고객에 대한 토크와 사람이 있는지 확인 / 그들이 가지고있는 생각 어떤 프로젝트의 상태가 무엇인지 생각.

이 작업을 마치면 코드 검사를 시작하고 전략을 수립 할 수 있습니다.

(단위 테스트가 많은 도움이 될 것이라고는 생각하지 않습니다. 실제로 작성된 함수가 실제로 작동하는지 알려줄 수는 있지만 어떤 함수가 있어야하는지 알려주지는 않습니다.)

다음에는 존재하지 않는 코드의 아키텍처에 대한 개요와 이것이 사양에 정의 된 문제에 어떻게 매핑되는지 살펴 보겠습니다. 그런 다음 각 주요 구성 요소의 하위 구성 요소가 무엇인지 확인하고 큰 구성 요소에 어떻게 적용되는지 확인하십시오. 이렇게하면 누락 된 구성 요소를 대략적으로 알 수 있습니다.

무엇이 존재하는지 알고 나면 기존 코드 검사를 시작하여 코드가 수행 할 작업을 수행하는지 확인해야합니다.

이 모든 작업을 완료하면 남은 작업량을 추정 할 수 있습니다.

(2) 회사는 고용 정책 / 직원 유지 정책을 살펴보고 프로그래머가 진행 상황을 책임 지도록하는 방법을 찾아야 할 수도 있습니다.

마지막으로, 당신이해야 회사에 이런 일이 막을 수있는 방법을 고려해야 당신이 서둘러 떠나합니다.

작동하는 것과 작동하지 않는 것을 보려면 소프트웨어를 반드시 실행해야합니다.

그런 다음 남은 문서를 고려해야합니다. 서면 요구 사항이 있습니까? 특정 작업이 있습니까-어떤 방식으로 작업이 추적됩니까? 누구든지 그것을 테스트 해 보았습니까? 그렇다면 수행 된 작업과 수행하지 않은 작업을 알 수 있습니다.

행동 계획은 다음과 같습니다.

1. 어떤 요구 사항이 완료되었는지 표시 (테스터처럼 시스템을 빠르게 실행)

2. 코드를보세요. 이해가 되십니까? 잘 작성 되었습니까?

분명히 90 % 완료되고 코드가 제대로 작성되면 완료하면됩니다.

아직 언급되지 않았습니다.

떠난 사람에게 연락하십시오. 모든 경우에 가능하지는 않습니다. 그러나 그가 건강하고 최소한 그의 작품을 좋아한다면, 그는 당신에게 진보와 누락 된 부분에 대한 정직한 대답을 돕고 줄 것입니다. 그리고 그는 당신에게 큰 그림을 설명 할 수있었습니다.

축하합니다, 이것은 당신의 상사에게 빛을 발하고 정말 긍정적 인 인상을 줄 수있는 기회입니다. 당신이 여기있는 것은 귀중한 기회입니다. 그래서 어떻게해야합니까?

먼저 코드를 얻으십시오. 그는 모든 것을 체크인하지 않았을 수도 있습니다 (우리에게 이것을 한 사람은하지 않았습니다). 관리 권한을 가진 사람이 컴퓨터에서 가져 와서 체크인하도록하십시오.

다음으로 문제를 심사하십시오. 요구 사항을 확인하고 코드를 작성하고 표시하지 않은 부분을 확인하십시오. 완료되지 않은 대략적인 목록입니다. 다음 단계에 따라 성장할 것입니다. 그런 다음 코드를 살펴보고 평가하여 실행 한 후 코드가 작성되었지만 현재 작동중인 것과 작동하지 않는 것으로 보이는 것을 확인하십시오. 작동하지 않는 부품을 목록에 추가하십시오. 단위 테스트를 찾으십시오 (마지막 기한 직전에 구제 한 사람들이 실패한다는 것을 알면 놀라지 않을 것입니다). 적어도 당신은 그것이 얼마나 나쁜지 잘 알고 있습니다. 또한 요구 사항을 살펴보고 어떤 질문에 대답해야하는지 확인하십시오. 많은 시간 동안, 불필요 한 요구 사항과 (많은 이유로) 추가 질문을 원하지 않는 개발자의 결과로 프로젝트 실패가 발생합니다.

이제 프로젝트 계획을 세웁니다. 요구 사항에 대한 질문 목록 (문서에 공식적으로 작성)으로 시작한 다음 작업을 완료하는 데 필요한 사항을 나열하십시오. 각각의 소요 시간을 추정하십시오. 현재 존재하는 것이 구원 가능한 것인지 결정하십시오 (그렇지 않은 경우 이유를 정당화 할 수 있도록 준비하십시오).

이제 프로젝트 관리자 (및 두 명의 다른 사람인 상사)와 회의를하고 나쁜 소식을 전하십시오. (누군가가 갑자기 떠날 때 떠났을 때 거의 항상 나쁜 소식입니다. 좋은 곳에서 사람들을 떠나지 않아야합니다. 좋은 개발자는 사람들을 루치에 남겨 두지 않습니다. 적어도 그들이 한 일과해야 할 일의 목록을 남깁니다. 건강상의 문제로 누군가가 떠난 경우는 예외입니다.) 귀하의 토론에서 귀하는 필요한 답변을 얻을 수 있으며 귀하와 PM은 프로젝트 계획을 약간 재구성 할 수 있습니다.

PM 및 기타 중요한 이해 관계자 (PM은 누구를 식별 할 것인지), 답변이 필요한 질문의 사본 및 작업 한 프로젝트 계획을 보내 회의를 진행합니다.

이제 실제 코딩을 시작하기 위해 필요한 것을 얻었으므로 작업하십시오.

그동안이 프로젝트를 구하기 위해 다른 것을 빼 냈을 것입니다. 프로젝트를 완료 한 후 다른 사람이 픽업하거나 픽업 할 수 있도록 작업 상태가 올바른지 확인하십시오. 즉, 동일한 유형의 작업, 수행 한 작업과 수행 할 작업이없는 문서 및 모든 소스 코드 체크인 (작업이 완료되지 않은 경우 트렁크에 필요하지는 않지만 다른 사람이 액세스 할 수있는 곳) .

기존 작업에서 벗어나지 않은 경우 각 근무일에 얼마나 많은 시간을 소비 할 것인지 상사와상의해야합니다. 이것은 초과 근무가 필요할 수 있으며 그에 감사 할 때 중 하나입니다. 실제 마감일에 가까울수록 관리가 더 절실합니다. 마감일이 가까워지면 초과 근무 수당이나 큰 보너스를받을 수 있습니다. 이 작업이 다른 작업을 크게 지연시킬 경우 해당 프로젝트의 이해 관계자가이를 인식하도록해야합니다.

프로젝트 복구에 성공하면 다음 성능 검토에서이를 자랑해야합니다.