클라이언트가 비현실적인 기대를 할 때해야 할 일? [닫은]

지난 6 개월 동안 클라이언트 사이트에서 프로젝트를 진행했습니다. 데이터 기밀이 필요하고 사무실에서 일하기를 원하지 않았기 때문입니다.

이 고객 사이트에 혼자 나타 났을 때 2 개월 안에 프로젝트를 완료해야한다고 들었습니다.

클라이언트는 소프트웨어 회사가 아니며 다양한 정책으로 인해 이클립스, 톰캣 등과 같은 제품을 설치할 수있는 권한을 컴퓨터에 부여하는 데 약 20-25 일이 걸렸습니다. 환경 설정이 지연된 후에도, 그들은 여전히 ​​같은 2 개월 동안 프로젝트를 완료 할 것으로 기대하고있었습니다.

요구 사항 문서를 제공하지는 않았지만 고객 사이트에서 일하고 있기 때문에 요구 사항을 논의하기 위해 정기적으로 모임을 가졌습니다.

6 개월이 지난 후에도 신청서는 아직 끝나지 않았으며 모두가 나를 비난하고 있지만 처음 몇 회의에서 논의 된 것보다 더 많은 기능을 추가했다는 사실을 깨닫지 못합니다.

이 기간 동안 양식을 두 부분으로 분리하는 등 많은 일을 다시해야했습니다. 몇 주 후에 그들은 혼란스러워서 두 양식을 다시 병합하도록 요청했습니다.

응용 프로그램의 범위는 매일 증가하고 있지만 여전히 지연된 2 개월 프로젝트라고 생각합니다. 범위가 커졌다 고 말하면 처음에 요구 사항을 요구하지 않은 이유를 묻습니다.

나는 이미 매일 11-12 시간을 일하고 3-4 시간을 여행하며 이제는 토요일에도 올 것으로 예상합니다.

요구 사항, 디자인, 코드 및 테스트를 수행하십시오.

이런 경우 어떻게해야하는지 알려주십시오.

_{추가 세부 정보 : 우리는 결과물 목록을 가지고 있었지만 이것들도 중요하다는 것을 몇 가지 더 추가했습니다. 또한 몇 가지 결과물을 변경했습니다. 그들은 심지어 UAT 서버를 가지고 있지 않으며, IP 주소를 통해 개발 시스템 자체를 테스트합니다.}

이것은 관리자의 실패입니다 . 계약자로서 귀하는 회사에서 엄격한 요구 사항을 사전에 서면으로 작성하지 않은 채 마감 시간이 긴 상황에 처해서는 안됩니다. 이 중 어느 것도 나중에 넌센스 '그들은 기능을 추가하지'- 무슨 일이 있었 때마다, 그들은 것을 업데이트 일정에 떨어져 서명해야 당신이 준 그들을 .

관리자는 고객과의 만남을 계획하고 있기 때문에 고객으로부터 특정 요구 사항을 가져와야합니다. 프로젝트는 A, B, C, D 및 E를 수행해야합니다. 그 후에는 완료됩니다. 고객의 서명은 해당 목록에 동의하는 문서에 있어야합니다. 당신은 처음부터 그것을 가지고 있었을 것입니다.

귀하의 관리자가 귀하를 뒷받침하지 않고 귀하를 지원하는 경우 – 그리고 나는 이것을 자주 말하지 않습니다 – 다른 일자리를 찾기 시작하십시오. 아마 당신은 전체 혼란에 대한 희생양이 될 것입니다. 그리고 11 시간 일과 3 시간 출퇴근을 기꺼이하고자한다면, 더 나은 자격을 갖춘 매우 헌신적 인 개인 일 것입니다.

이러한 상황에서 중요한 것은 CYA 종이 흔적을 만드는 것입니다. 특히 복잡한 비즈니스 관계에서 문서를 작성하지 않고서는 아무것도 할 수 없습니다. 초기 일정을 고수하더라도 20 일이 필요했지만 작업을 복잡하게하는 것은 큰 위험 신호입니다.

추가 기능이 필요한 회의를 개최하십니까? 나중에 적어두고 각 항목에 "+ X 일을 현재 일정에 표시"하고 관련된 모든 사람에게 우편으로 보내십시오. 고객의 내부 메일 시스템 만 사용하는 경우받는 사람 :, 참조 : 및 숨은 참조 : 수신자 목록을 포함하여 추가로 인쇄하여 신중하게 보관하십시오. 그 외에도 GrandmasterB가 말했듯이 고객은 원래 요구 사항에 대한 변경 사항에 서명해야합니다.

필요한 일정을 잡을 수 없으면 일정을 작성하십시오. 변경 사항이 발생하면 결과를 포함하여 변경 사항을 작성하십시오. 등등.

이것은 "나는 당신에게 그렇게 말한"것이 아닙니다. 엉망이 마침내 벽에 부딪 치면 어쨌든 듣지 않을 것입니다. 고객이 계약을 이행하지 않았다고 생각하여 고객을 고소하거나 지불을 거부하여 회사를 고소 할 때 보험이됩니다.

당신이 묘사 한 것에서, 당신은 고전적인 Death March 프로젝트에 참여하고있는 것 같습니다 :

에서 프로젝트 관리 하는 죽음의 행진 dysphemistic 관련된 병리학 적 프로젝트의 여러 종류의 실제에, 어두운 유머 비유입니다 죽음의 행진혹독한 결과를 초래할 위험이 높은 프로젝트 (예 : 프로젝트 실패, 개인 및 그룹 평판 손상의 위협)에 대해 근거가없는 이유로 혹독하게 과로하게 근무하는 등의 . 따라서 "죽음 행진 (death march)"이라는 이름은 궁극적으로 성공했지만 지속 불가능한 과로의 가정 확장, 또는 아마도 더 많은 정보를 가진 모든 구성원이 볼 수있는 프로젝트 (또는 더 자주)와 관련이있는 프로젝트에 적용될 수 있습니다. 실패의 위험이 매우 높음에도 불구하고 회원은 그럼에도 불구하고 상사에 의해 행동해야합니다 ...

현상은 잘 알려져 있으며 물론 에드워드 유든 (Edward Yourdon)의 저서 ' 죽음 행진 :'미션 임파서블 '프로젝트 생존을위한 완전한 소프트웨어 개발자 안내서'를 포함하여 진행 방법에 대한 많은 문헌 이 있습니다.

위에서 인용 한 Wikipedia 기사 는 죽음의 행진 프로젝트에 관심이 있거나 관심이있는 사람들을위한 더 많은 정보, 연구 및 권장 사항을 찾는 좋은 출발점을 만듭니다 .

신발을 걸을 때 가장 먼저 고려해야 할 것은 위의 기사에 대한 참조를 관리자에게 전달하는 것입니다.

그렇게하면 내가 무슨 일이 일어나고 있는지 알 수 있으며, "현재 상태는 XYourdon의 장 에 설명 된 것과 비슷합니다 . 밀접하게 관련된 챕터 Y등과 함께 ... "

관리자가이 연구 분야에 대해 잘 모르는 경우 (참조하지 않을 경우), 상황을 식별하고 처리 방법을 결정하는 데 도움이되는 생각에 충분한 음식을 제공 할 수 있습니다.

솔직히, 이것이 가능하다면 가장 좋은 해결책은 종료하는 것입니다. 이와 같은 상황은 당신에게 유독하며 아무리 노력해도 시간이 지남에 따라 거의 나아지지 않습니다.

손실을 줄이고 다른 공연을 찾는 것이 가장 좋습니다. 그러나 귀하의 경험에 대해 생각하고이 글에 대한 다른 답변의 조언을 받으십시오.

그것은 심각하다 issue in project management . 당신은 것 같습니다 Project Manager작동합니다 산출물 목록 및 우선 순위를 클라이언트로합니다.

가장 중요한 것은 귀하의 PM should discuss이며 귀하의 추정에서 시간 문제 (문제 / 해결 방법의 설계 및 분석 포함)를 고객과 동의합니다.

갖는 clear estimation of your work load프로젝트의 산출물 항목,뿐만 아니라, 스트레스를 해소 추가 할 마음의 평화 당신의 일에 자신감을.

스프린트 (2-3 주)로 항목을 전달하고 클라이언트와 UAT (사용자 승인 테스트)를 만들어 애자일 방식 을 사용 하십시오. 스프린트를 시작하기 전에 항상 스프린트 계획을 세우십시오.

편집 : 의견에서 이것이 실제로 프로젝트 관리자의 실패 라는 것이 분명합니다 . 귀사와 같은 심각한 프로젝트에 적합한 테스트 및 / 또는 개발 환경을 설정하지 않으면 SDLC 프로세스에 큰 구멍 이 project됩니다.

나는 이것이 관리 실패라는 것에 동의하지만, 그것은 또한 당신의 실패이기도합니다. 이 단계에서는 해결하기가 매우 어려울 수 있으므로이 문제를 해결하기 위해 필요한 것은 향후 프로젝트를 처리하는 방법입니다.

먼저, 프로젝트 시작시 요구 사항 기준 문서를 주장해야합니다. 화려하거나 공식적 일 필요는 없지만 클라이언트가 예상 한 것을 지정할 때까지 아무것도 만들 수 없습니다. 서면으로 작성하지 않은 경우 고객이 최종 결과에 만족할 확률은 거의 0 %입니다. 따라서 이것은 매우 중요합니다. 이 문서에서 모호성을 찾아 가능한 빨리 정리하는 것도 귀하의 임무입니다. 당신이 이것들 중 하나를 발견하고 그것을 해석하는 방법을 모른다면, 그것이 의미하는 바에 대해 추측하지 말고, 당신과 클라이언트가 그것이 의미하는 바에 대해 같은 페이지에 있는지 확인하십시오. 그렇습니다. 이는 사람들과 더 많이 대화하고 더 많은 회의를하며 코딩을 줄입니다. 그러나 불명확 한 요구 사항을 잘못 코드화 한 다음 다시 코드화하는 것보다 명확하지 않은 시간이 소요됩니다. 또한 재 코딩을 무료로 제공해야하는 경우가 많으며 이는 회사에 좋지 않은 일입니다.

다음으로 작업을 수행하는 데 걸리는 시간과 마감 시간을 설정합니다. 요구 사항을 충족하기 위해 작업을 수행하는 데 걸리는 시간 이외의 시간을 기준으로 마감 기한을 수락하지 마십시오. 그렇게하면, 당신은 다시 죽음에 처할 것입니다. 시간이 걸리는 동안 상세한 외식을하여 마감 시한을 맞추지 못하는 방법을 보여주십시오. 클라이언트가 원하는 양에 관계없이 개발자 한 명만 있으면 일주일에 200 시간의 개발 시간을 맞출 수 없습니다. 최종 기한을 변경할 수없는 시점에서 다음 반복으로 어떤 항목을 이동해야하는지 묻습니다.

프로젝트 시간 추정을 수행 할 때 개발 시간은 프로젝트 시간의 일부에 불과하다는 것을 잊지 마십시오. 또한 회의 및 이메일 / 전화 통신, 테스트, 배포, 문서화, 서버, 워크 스테이션, 소프트웨어의 물리적 설정을 고려해야합니다. 또한 마감 기한을 계획 할 때는 하루에 6 시간을 사용할 수 없다고 가정 할 수 있습니다. 이는 휴가, 사별, 병가, 불가피한 지연 (예 : 허가를 받기 위해 기다려야 할 때)을 설명하는 것입니다. 네트워크 등), 교육, 프로젝트와 관련되지 않은 작업 (시간표, 인사 회의 등). 사람들이 마감일을 지키지 않는 가장 큰 이유 중 하나는 매일 개발 만하고 8 시간 동안 일을한다고 가정하기 때문입니다. 이것은 단순히 현실적인 가정이 아닙니다.

그리고 그들이 다른 작품을 추가 할 때마다 얼마나 오래 걸리고 추가 작업으로 인해 마감일이 얼마나 걸릴지 알려줍니다. 마감 기한을 옮기라고 요구하지 않고 새로운 요구 사항으로 인해 움직이고 있음을 알려줍니다. 이제 관리자를 통해이 작업을 수행해야하지만 , 요구 사항이 변경 될 때마다 그리고 프로젝트에 얼마나 추가 될 것인지 관리자가 알도록하는 것은 모든 책임입니다. 이 모든 것이 서면으로되어 있는지 확인하십시오. 필요한 경우 자신을 방어 할 수 있습니다.

다음으로, 11 시간 일과 주말에 자신을 학대하지 마십시오. 6 개월마다 1 주일 미만의 짧은 분출 량으로도 괜찮지 만, 장기적으로는 허용되지 않습니다. 피곤한 사람들은 코드를 느리게 만들고 더 많은 실수를합니다. 정기적으로 11 시간보다 8 시간 더 정기적으로 고품질 작업을 수행하면 더 많은 일을 할 수 있습니다. 주말.

이런 종류의 상황에서 간트 차트가 매우 훌륭하다는 것을 알았습니다. 고객에게 현재 일정을 설명 할 수 있으며 새로운 기능 / 변경 사항을 추가하는 효과를 설명하는 데 유용 할 수 있습니다. 때때로 고객에게 x 기능이 y 일까지 배달에 영향을 준다고 말하면 등록되지 않습니다. 그래프에 명확하게 표시하면 더 잘 이해할 수 있습니다.

이상적으로는 프로젝트 시작부터 수행해야합니다. 이 시점까지 " 지연 " 을 설명하는 것은 유용하지 않지만 프로젝트 진행에 도움이 될 수 있습니다.

에서 위키 :

간트 차트는 프로젝트의 터미널 요소와 요약 요소의 시작 날짜와 완료 날짜를 보여줍니다.