저는 5 명으로 구성된 팀의 개발자이며 프로젝트가 재난을 겪고 있다고 생각합니다. 잠시 이유를 설명하지만 제 질문은 어떻게해야합니까?

마감일은 1.5 개월이며 우리가 무엇을하든이 프로젝트는 실패 할 것입니다. 프로젝트를 끝내고 시간 낭비를 중단해야한다는 의견이 있지만 정치적으로는 관리자가 그렇게 할 수 없다고 생각합니다.

이 경우 어떻게해야합니까? 좀 더 노력해야합니까, 아니면 그냥 쉬어야합니까? 그리고 관리자에게 무엇을 말해야합니까?

이 프로젝트가 실패한 이유 :

• 마감일이 다가옴에 따라 많은 필수 기능이 완성되지 않았습니다.
• 응용 프로그램이 불안정하고 사용하기가 매우 어렵습니다
• 시스템은 매우 복잡하고 코드는 이해하기 어렵고 변경하기가 매우 어렵습니다.-데이터 모델이 복잡한 관계형 데이터베이스 (100+ 테이블)에 의해 너무 많이 구동됩니다
• 불분명 한 지도력; 관리자는 주요 변경 사항으로 새로운 정보에 응답
• 자동화 테스트 또는 단위 테스트가 거의 없음
• 다른 시스템에 크게 의존하지만 아직 통합 테스트는 없습니다

실제로, 우리는 1-2 개월 전 같은 관리자의 다른 개발자 팀으로부터이 프로젝트를 엉망으로 물려 받았습니다.

관리 래더에서 가능한 가장 간결하고 비대화적인 방식으로 우려 사항을 전달하십시오. 위험을 요약하되 이에 대한 결론을 내리지 마십시오.

경영진은 항상 무엇을해야할지 선택해야하지만 상황을 평가하고 전달하는 것은 당신의 임무입니다. 남쪽으로 갈 때 종이 흔적을 남기려면 이메일을 사용하십시오.

그렇게 한 후에는 프로젝트를 계속 성실히 수행하십시오.

프로젝트, 프로젝트 후원자 및 프로젝트의 재정적 결정에 대해 알아야 할 모든 것을 알지 못할 수도 있습니다. 어리석은 것처럼 보이는 경영 결정은 실제로는 보이지 않는 현명한 추론에 근거 할 수 있습니다.

종이 흔적을 남기십시오 (예 : 일기, 저장된 이메일 등). 사실과 객관적인 관찰 만 포함하십시오 . 모든 결론은 누구든지 당신이 작성한 것을 읽는 사람에게 맡기십시오.

개발자로서 프로젝트에 장애가되지 않는다면 의심의 여지가없는 손가락 끝에서 잘 나올 것입니다. 귀하의 관리자는 운이 좋지 않을 수도 있지만 여기서는 관련이 없습니다.

일반적인 원칙에 따라 이력서를 업데이트하고 회사 외부의 다른 개발자와 가끔 만나도록하십시오. 로컬 개발자 그룹에 속하지 않으면 2 또는 3에 가입하십시오. 친구 및 지인 네트워크를 구축하는 데 몇 년이 걸리지 만 장기적으로 가치가 있습니다. 회사의 유능한 사람으로 회사의 개업을 채우는 데 도움을 줄 수 있다면 구직 활동을 돕는 사람만큼이나 좋습니다.

2 권의 책을 읽는 데 약간의 시간이 걸릴 것을 권장합니다.

죽음의 행진 은 소프트웨어 개발에 널리 퍼져있는 병리학 적 프로젝트 관리 스타일을 설명하는 표준 책입니다. 일정 압축, 기능 부풀림 또는 잘못된 관리로 인해 많은 프로젝트가 나쁜 상태가됩니다. 그것은 당신이 혼자가 아니며 프로젝트가 유일한 죽음의 행진이 아님을 이해하는 데 도움이됩니다. 저자 Edward Yourdon은 데드 엔드 프로젝트를 4 개의 사분면으로 분류합니다. 각 사분면에는 서로 다른 대처 전략이 있습니다. 때때로 유일한 대처 전략은 떠나는 것입니다. 나는이 책이 당신의 선택 범위가 무엇인지 파악하고 당신이 할 수있는 것과 할 수없는 것을 좁히는 데 도움이 될 것이라고 생각합니다.

재앙 혼란 은 프로젝트 관리자를 위해 더 쓰여졌습니다. 깨진 프로젝트를 심사하는 방법, 즉 잘라야 할 부분, 잘라낼 수있는 부분, 고객에게 어떻게 던지는 방법을 파악하는 것이 목표입니다. "기존의"소프트웨어 프로젝트 관리는 우리를 지저분한 프로젝트로 이끌며, 우리는 처음에 우리를 문제에 빠뜨린 것과 같은 생각으로 문제를 피할 수 없습니다. 이 책은 Death March 보다 읽기가 어렵지만책장에는 좋은 책입니다.

경력 / 위생을 유지하기위한 3 개의 단순하고 냉소적 인 전략.

1. 기차에서 내리는 열차 사고보기-기차에서 내리십시오 : 실패한 프로젝트는 사기에 끔찍한 것이며 닌자 이상의 관리 기술이 없으면 커리어에 부정적인 영향을 미칩니다. 부드러운 착륙을 볼 수 있다면 지금 점프하십시오.

2. 그래도 문제가 해결되지 않으면 머리를 숙여 두십시오. 사람들은 사람들을 비난하기 시작할 것입니다-쉽게 만들지 마십시오! 관리 체인에 대한 우려를 높이는 것이 옳은 것일 수도 있지만 효과가없고 위험합니다. 귀하의 관리자는 귀하의 우려를 제기하지 않고 그를 우회하지 않을 것입니다. 둘 다 나빠 보이게 할뿐만 아니라 귀하를 '고장 만들기'로 분류 할 수 있습니다. 물론 이것은 전문적이면서도 시간을 투자하지만 영웅은 없다는 것을 의미합니다.

3. T + 1의 비상구 계획 : 자신에게 몇 가지 옵션을 제공하고 잠재적 인 내부 또는 외부 전송을위한 토대를 마련하십시오. 사람들과 대화하십시오. 프로젝트 자금이 삭감되거나 몇 달 안에 이주하는 사람들의 피할 수없는 '스탬프 (stampede)'에서 다른 사람들이 당신과 함께 무엇을 해야할지 결정할 때까지 기다릴 이유가 없습니다.

지나치게 냉소적으로 들린다면 사과하지만 올바르게 부르면 불쾌감이 나빠질 수 있습니다. 전문적이고 낙관적이지만 항상 현실적이어야합니다.

이 곧 실패 할이 프로젝트는 회사 및 그 이상의 경력에 ​​어떤 영향을 미칩니 까? 내 경험상, 단지 성공적인 프로젝트와 관련이 있다고해서 귀하의 개인적 우수성을 나타내는 지표는 아닙니다.

당신이 역경을 겪을 때 당신이 나타내는 특성들과 때로는 어떤 실패로 보이는 것들은 종종 당신이 생각하는 것보다 더 높은 사람들이 눈에 띄게됩니다. 그리고 나는 당신의 직속 상사를 넘어서 이야기하고 있습니다.

나는 개인적으로 내 직속 상사가 무능력으로 해고당하는 것을 경험 한 후 바로 같은 날 자신의 위치로 승진했습니다. 유쾌하지는 않지만 사람들이 나를보고 있다는 것을 보여 주었고 내가 한 일을 좋아했습니다.

종종 실패한 프로젝트와 함께 제공되는 혼란과 혼란이 당신에게 빛을 발할 수있는 기회를 제공합니다.

프로젝트를 이런 식으로 살펴보십시오.이 실패한 프로젝트가 내 기회와 모든 장점을 밝게 비출 수있는 기회는 무엇입니까? 이 경험을 통해 어떤 교훈을 얻습니까?

본질적으로 실패로 인한 경험의 총합이 진정한 성공을 가져옵니다.

참고 : Thomas Owens는 이와 같은 프로젝트에서 사람이 할 수있는 구체적인 일을 물었습니다. 이러한 상황에서 개인적인 지침으로 사용한 몇 가지 일반적인 제안이 있습니다. 고통스러운 프로젝트가 기적적으로 성공하는 데 도움이됩니까? 아니요.하지만 상황에 대한 올바른 관점을 유지하고 나쁜 상황에도 불구하고 개인적으로 성공하는 데 도움이되었습니다.

1) 개인 우수성에 중점을 두십시오. 더 나은 코드를 작성하고 더 높은 품질 및 기능 표준을 충족 시키려고 노력하십시오.

2) 개인 통계에 중점을 둡니다. 코드를 얼마나 작성합니까? 후속 버그가 발생합니까? 그 비율을 가능한 한 낮게 줄이십시오. 자신에게 할당 된 작업에 대한 견적을 제공하라는 요청을받을 때 일반적으로 정확합니까, 아니면 타임 라인을 너무 / 낮게 버퍼링 했습니까? 실제로 작업을 배정 할 때 배송 일정 문제를 미리 미리 통지하는 등 작업 진행에 대한 적절한 피드백을 제공합니까?

3) 팀 메트릭에 초점-이것들은 내 머릿속의 일부일뿐입니다. 다른 팀 구성원이 작업중인 작업에 대한 종속성으로 인해 지연됩니까? 작업 / 하위 작업을 팀의 다른 사람에게 위임하거나 나누는 데 능숙합니까? 한 명 이상의 팀원과 의사 소통하기가 어렵습니까? 정기적으로 개선하기 위해 노력하는 모든 영역.

이와 같은 상황에서는 사다리의 가장 낮은 렁으로 프로젝트를 돕기 위해 할 수있는 일이 너무 많습니다.

• 작품이 흠이 없는지 확인하십시오
• 가장 큰 문제 영역을 식별하는 데 도움
• 문제뿐만 아니라 답변을 제공하십시오. 당신이 그들을 고치려고하는 것처럼 보입니다.

그 외에도, 당신은 정말로 숫자 1을 돌봐야합니다.

• 모든 것을 문서화
• 모든 이메일, 메신저 대화 유지
• 가능한 경우 프로젝트에서 벗어날 수있는 방법을 찾아보십시오

실패한 프로젝트는 영혼에 유독하고 우울증을 유발하며 과로와 자존감이 낮을 수 있습니다.

그것은 모두 관점과 관련이 있습니다.

나는 매일 그의 얼굴에 미소를 짓고있는 다른 남자와 맞닥 뜨리며 끔찍한 프로젝트를 진행했습니다. 오, 어떻게 그의 얼굴에서 그 미소를 때리고 싶어.

어떤 사람들은 프로젝트의 현재 상황에 의해 방해받지 않습니다. 그들은 자신의 공헌과 업무를 즐기고 관심 분야에서 협력하고 있습니다. 다른 사람들은 현재 상황에 대해 강한 부정적인 반응을 보입니다. 그것은 우리의 일상 업무에 대한 우리의 기대에 관한 것입니다.

당신이 즐기는 일을하고 있을지 모릅니다. 현재 프로젝트에 싫어하는 요소가 분명히 있습니다.

이러한 문제 요소가 무엇인지 식별하고 해결해야합니다.

• 마감일 압력
• 품질 관리
• 전문 직업 의식
• 경영진의지도

위의 개발 측면을 중요하게 생각하지 않는 많은 팀과 회사가 있습니다. 내가 찾은 것은 종종 다음을 생각한다는 것입니다.

• 마감일 압력은 사람들에게 동기를 부여하는 방법으로 인식됩니다.
• 품질은 더 비싸고 반품 한도입니다.
• 전문성은 사업의 다른 영역에 적용됩니다.
• 관리자는 계시원이며 개발에 기여하는 사람이 아닙니다.

이 문제는 당신의 것이 아닙니다. 그것은 그들의 것이며, 그들의 행동에 에너지를 낭비해서는 안됩니다. 절벽으로 향할 때에도 웃으며 그의 일을 즐기는 사람 중 하나가 아니라면 like minded개발자 의 장소를 찾는 것에 대해 생각해야합니다 .

당신은 훨씬 행복 할 것입니다.

프로젝트 성공을위한 새로운 방법을 찾는 데 적극적으로 노력하십시오. 대안을 제안 할 수있는 방법에 대해 생각해보십시오. 지금 당신의 상사는 아마도 실패한 프로젝트에 대해 두들겨 맞을 것입니다. 누군가가 문제 대신 해결책을 찾는 것에 대해 감사하지 않습니까?

기능을 엇갈린 결과물로 나누는 방법이 있습니까? "필수"수준이있는 경우가 많으므로 우선 순위를 정하고이를 마일스톤으로 그룹화 할 수 있는지 확인하십시오. 타임 라인이 끝날 때 제품이없는 것이 좋습니다. 또는 새로운 기능을 담당하는 사람들과 안정성을 담당하는 다른 사람들로 팀을 분리하는 것을 고려하십시오. 이렇게하면 두 가지 측면에서 어느 정도 진전을 보일 수 있습니다.

이러한 노력이 성공하면 성공할 수있는 방법을 찾을 수있는 팀원임을 알 수 있습니다. 그렇지 않은 경우 여전히 포기하지 않고 해결책을 찾기 위해 노력할 것입니다.

내가했던 대부분의 프로젝트처럼 들린다. 그러나 생각만큼 나쁘지 않을 것입니다.

1) 당신의 일을하십시오. 책임을 완수하는 한 전체 프로젝트에 대해 크게 걱정하지 마십시오.

2) CYA. 프로젝트가 실패하고 관리자가 자신을 제외한 모든 사람을 비난하기 시작한 것으로 의심되면 필요한 모든 것을했다는 충분한 증거가 있는지 확인하십시오 (항목 1 참조).

3) 개선을위한 몇 가지 공손한 제안을한다. 경고 종소리를 울리지 말고, 파멸과 우울함을 느끼지 말고 예의 바르게 행동하십시오.

예를 들어, 팀이 효과적인 단위 테스트 (또는 다른 테스트)를 작성하지 않는 경우 몇 가지 단위 테스트를보고자하는 것에 더 가깝게 작성하여 특정 문제를 해결하는 데 도움이되거나 시간을 절약하는 방법을 인과 적으로 언급하십시오.

결과에 영향을 미치려면 구체적인 결과를 얻는 긍정적 인 단계에 초점을 맞추십시오. 이 프로젝트는 결코 승자가 될 수 없지만 팀은 다음 프로젝트를 배울 수 있습니다.

또한:

4) 기회 리팩토링은 당신의 친구입니다.

1. 열심히 일하다; 그러나 가족이나 건강을 희생하지는 않습니다.
2. 모든 중요한 설계 결정을 기록하십시오. 특히 그들은 당신의 일과 관련이 있습니다.
3. 상황이 너무 어려워 지거나 대량 해고의 희생양이되면 네트워킹을 유지하고 옵션을 열어 두십시오.
4. 시도 하지 는 "실패한 프로젝트"로 프로젝트의 생각. 모든 사람들은 역경에 직면하여 긍정적 인 자세로 열심히 싸우는 사람들을 좋아합니다. 가능한 한 오랫동안 그 사람 이 되십시오. 긍정적 인 전망, 그릿 및 결단은 항상 작업장에 좋습니다.
5. 실패한 프로젝트를 예상하는 경우 사후 회의를 기대하는 것입니다. 사후 회의에서 모든 사람이 회계를받습니다. 모든 코드를 방어 할 준비를하십시오. [참고 : 일반적으로 나중에 쉽게 방어 할 수 있도록 항상 깨끗한 코드를 작성해야합니다.] 의사 결정에 영향을주는 전자 메일 또는 디자인 문서가 있다면 훨씬 좋습니다.
6. 사후 회의에서 긍정적 인 태도를 유지하십시오. 그리고 오직 당신의 판단과 노력, 또는 제작이 질문에 호출되는 경우 이메일 및 설계 문서 증거를 제시한다.

내가 가장 효과적인 것은 일정 압력에 대처하는 방법 에 대한 Robert L. Read의 추천입니다 . Read가 쓰는 내용은 다음과 같습니다.

일정 압력에 맞서 싸우는 열쇠는 단순히 시장 출시 시간 압력으로 바꾸는 것입니다. 이용 가능한 노동력과 제품 간의 관계에 대한 가시성을 제공하기위한 방법. 이 작업을 수행하는 가장 좋은 방법은 모든 노동에 대해 정직하고 상세하며 무엇보다도 이해할 수있는 견적을 작성하는 것입니다. 또한 기능 상충 관계에 대해 적절한 관리 결정을 내릴 수 있다는 이점이 있습니다.

추정치가 분명 해져야 할 핵심 통찰력은 노동이 압축 할 수없는 유체라는 것입니다. 컨테이너의 부피 이상으로 컨테이너에 더 많은 물을 담을 수있는 것보다 더 많은 시간을 더 이상 포장 할 수 없습니다. 어떤 의미에서 프로그래머는 절대 '아니오'라고 말하지 말고 '원하는 것을 얻기 위해 무엇을 포기할 것입니까?' 명확한 추정치의 결과는 프로그래머에 대한 존중을 높이는 것입니다. 이것은 다른 전문가의 행동 방식입니다. 프로그래머의 노력이 보일 것입니다. 비현실적인 일정을 설정하는 것은 모든 사람에게 고통 스럽습니다. 프로그래머는 괴롭힐 수 없습니다. 비현실적인 일을하도록 요청하는 것은 무례하고 낙담합니다.

프로젝트가 "실패로 향하고있다"고 말하면 수행해야 할 작업과 각 작업에 얼마나 많은 노력이 필요한지에 대한 평가를 기반으로합니다. 그 평가를 명시 적이고 이해 가능 하며 상세하게하십시오 . 작업을 구성 요소 부분으로 분리하십시오. 개발 시간이 어떻게 소요될 수 있는지 최대한 자세하게 설명하십시오.

일단 그렇게하면 경영진과 관련된 문제를 논의 할 수있는 견고한 토대가됩니다. 어쨌든 평가를 완료해야 할 특정 작업으로 나눈 후에는 작업보다 시간이 많이 걸린다는 사실을 입증 할 수 있습니다.

이 세부 일정을 관리자와 논의한 후에는 융통성있게 준비하십시오. 관리자는 "태스크 X는 한 달이 걸리지 않습니다. 최대 일주일이 걸릴 것입니다."또는 "태스크 Y는 전적으로 불필요합니다. 당신은 확실히 이러한 점을 논의,하지만 훨씬 더 중요한 것은 당신과 관리자 사이의 이해에 도달하는 것입니다 수있는 몇 가지 일정의 현실적인 버전. 이런 식으로, 테스트를위한 시간을 할당받지 않는다면, "예기치 못한"시간이 아닌 테스트를하지 않는 명시적인 지시어를 갖게됩니다. 그리고 관리자가 정시에 배송을 위해 명시 적으로 특정 모서리를 자발적으로 기꺼이 기꺼이 내릴 가능성이 있습니다.

견적은 토론하고 논의 할 구체적인 내용을 제공합니다. 같은 페이지에 표시됩니다. 관리자가 우려 사항을 고려했다고 확신 할 수 있습니다. 그리고 그것은 당신의 매니저가 불가능을 명백히 요구한다면, 그것은 당신에게 완벽하게 명백해질 것입니다. 프로젝트가 훌륭하고 진정으로 끝났다면, 그 사실을 분명히했을 것이며, 시간을 어떻게 보내고 싶어하는지 정확하게 결정하는 것은 관리자의 책임입니다.

관리자가 실패 할 것임을 알고 있기 때문에 대부분의 경우보다 낫습니다. 관리자와의 작업을 고려하고 제외 할 수있는 앱의 일부 / 기능이 있는지 확인합니다.

우리는 종종 모든 고객 요청이 '거래 킬러'라고 생각하고 배달 약속을하지 않습니다. 누군가가 클라이언트와 작업하고 더 깊이 조사 할 때까지 이러한 결정을 내릴 수 없습니다. 이 작업을 수행 할 수없는 경우 여전히 가장 중요하다고 생각하는 내용을 전달하십시오. 때로는 허가보다 용서를 구하는 것이 더 쉬운 경우가 있습니다.

분명 실패한 세 가지 프로젝트에 참여했습니다. 이것들은 상당히 고통 스럽지만 뒤돌아 보았고, 3 명 중 2 명은 내 경력에 부정적인 영향을 미치지 않았으며, 세 번째도 세상의 종말이 아니 었습니다.

다음은 내가 기억하는 관찰 사항입니다.

주니어 위치 ( "사양 별 코드", "버그 수정"등)의 개발자는 팀의 사기가 낮아져 느슨해지지 않는 한 크게 영향을받지 않습니다. 이런 위치에서 현명하고 때로는 성공적인 생존 전략은 최선을 다하는 것일 수 있습니다.

• ^{예를 들어, 내가 경험 한 실패 중 하나는 수백 가지의 알려진 버그를 체계적이고 체계적으로 수정하여 극복했습니다. (기술 리더가이 진보를 촉진하는 특히 현명한 접근 방식과 함께) 결국 경영진이 프로젝트를 복구하고 새로운 출시로 또 다른 기회가되었으며, 그 결과 합리적인 성공을 거두었습니다.}

더 선임적이고 영향력있는 직위의 프로그래머 는 프로젝트 실패의 부정적인 결과를 공유 할 수 있도록 준비하는 것이 좋습니다. 건축가, 기술 책임자, 수석 개발자는 일반적으로 프로젝트 성공 또는 실패에 대한 책임으로 간주 될 정도로 큰 영향을 미칠 것으로 예상됩니다.

고위직에서, 무엇이 잘못되었는지와 더 잘했을 수있는 것을 분석함으로써, "간접적으로"실패로부터 얻을 수있는 준비를하는 것이 좋습니다.

WP에서이 훌륭한 답변에 설명 된 대로, 이러한 지식의 일부, 사후 수업은 제대로 배운다면 귀중한 것이 될 수 있습니다. 고위 직책에서의 성공적인 경력은 이들이 얼마나 잘 배웠는지에 달려 있습니다 .

판단은 성공이 아니라 실패에서 비롯됩니다. 대부분의 회사는 이전 회사에서 비용을 지불 한 사람을 고용하려고합니다 ...

보다 실용적인 참고로, "다음 / 업데이트 릴리스"접근 방식을 가능한 실패 방법으로 고려할 수 있습니다. 우연히도 아니든 ( 아니라 생각 하지는 않지만 ) 내 경력에 해를 끼치 지 않은 두 가지 실패는 모두 비슷한 시나리오를 겪었습니다. 릴리스 N는 총 재해, 릴리스 N+1는 허용 가능, 릴리스 N+2및 나중에는 명백한 성공이었습니다.

당신의 신발을 걸을 때, 나는 "다음 릴리즈"라는 아이디어를 준비 / 촉진하는데 약간의 노력을 기울일 것입니다. 계획된 릴리스 후에 해결하려는 알려진 문제의 잠정적 인 목록과 같은 것을 작성 하고 전달하십시오 ! 다음 릴리스에 대한 비공식적이고 거친 로드맵을 작성하십시오.

이러한 아이디어를 주변 사람들에게 전달할 수있는 방법,이 계획을 고려하여 경영진에 영향을 줄 수있는 방법을 생각해보십시오. 프로젝트에 마케팅 기술이 좋은 사람이 있다면, "조기 액세스", "베타", "고객 미리보기", "소개 릴리스"와 같은보다 부드러운 용어로 릴리스를 마무리하여 실패 피해를 상쇄하도록 참여 시키십시오. 그.

높은 아이디어가이 아이디어에 귀찮게 보일 경우를 대비하여 백업 계획을 생각해보십시오. "백 개가 넘는 알려진 버그 수정"에 대한 위의 이야기를 기억하십니까? 실제로 상황이 변할 기회가 있습니다.

경영진은 다음 릴리스 아이디어에 귀찮게 보일지 모르지만, 프로젝트 품질 진행에 대한 확실한 설득력있는 증거에 직면하여 그들이 재검토 할 수있는 좋은 기회가 있습니다.

• ^{계획된 릴리스를위한 고정 코드와 코드를 완전히 삭제하기위한 관리 결정 사이에는 다소 오랜 시간이 걸릴 수 있습니다. 그때는 기회입니다. 알려진 문제를 해결하고 진행 상황을 적절하게 "복음화"하는 데 노력을 기울이면 변화가 생길 수 있습니다.}

여기에 실질적이고 다른 조언이 많이 있지만,이 비밀의 열쇠는 다음 두 가지 항목입니다 (강조 광산).

마감일은 1.5 개월입니다.

과

... 우리는 실제로 단지 주변 (혼란과 함께)이 프로젝트를 상속 1~2개월 전 에서 같은 관리자에서 다른 팀 dev에 ...

그래서....

팀 패시 어벤저 스에 오신 것을 환영합니다

이전 팀은 실패보다 더 나은 일을했습니다. 그리고 어떻게 든 매니저는 그와 함께 갔다. 마감일이 가까워진 팀을 변경하는 것이 프로젝트 관리에 가장 적합한 방법은 아닙니다.

수정 : 마감일 3 개월 전 이전 팀이 교체되었습니다.

-> 이전 개발자 팀이 탈출 한 방법을 확인하고 그렇게하십시오. <-

3 개월이면이 겉보기 크기의 시스템에서 속도를 내고 아키텍처를 훨씬 덜 수정하고 테스트를 추가하고 완료 할 수있는 시간이 거의 없습니다. 시간이 더 필요해

그렇게 할 수 없다면, 프로젝트가 무기한으로 확장되거나 마법의 엘프 또는 다른 것에 의해 도움이 될 것이라고 확신 하지 않는 한, 가방을 들고 마지막으로 서있는 사람이되고 싶지 않습니다.

거친? 예. 그러나 이전 팀 / 관리자에 의한 잘못된 계획 (적어도!)은 귀하의 잘못이 아니지만 '실패에 실패하는 것 ' 이 될 것입니다 .

이전 팀은 물러났다 . 이전 팀이 연석에 쫓겨났습니다. 그게 뭐에요? 그것은 당신이 턴어라운드 팀이고 ... 당신의 매니저는 당신의 영웅을 믿고 하루를 저장한다고 말합니다.

5 명으로 구성된 팀으로 1.5 개월 남았습니다. 새로운 팀은 1-2 개월 동안 만 프로젝트를 진행 했으므로 새로운 팀은 학습 곡선을 넘지 못합니다 . 이 프로젝트의 규모를 대략 추측 하면 프로젝트에 전혀 문제가 없더라도 새로운 팀이 학습 곡선을 넘을 방법이없는 것처럼 보입니다 .

그래서 (여전히) 당신이 동요했다고 생각합니다.

이 경우에 – 그리고 오직 당신이 진실한 것을, 또는 당신이 믿고 싶은 것을 결정할 수 있다면 – 당신은이 열차 잔해에서 벗어나는 데 대한 설명이나 사과를 빚진 사람이 없습니다. 당신은 그것에 대해 신중해야합니다.

관리자가 프로젝트가 위험에 처해 있음을 알지 못한다는 점을 진지하게 의심합니다. 즉, 부드러운 설명은 부정적인 관심을 가질 것입니다. 관리자가 로저스 씨 가 아니라면 미래는 위험에 처해 있습니다.

그러나 항상 기억하십시오 : 인터넷상의 낯선 사람의 직업 조언을하지 마십시오.

이것은 당신에게 놀라운 기회입니다! 이것에 대한 기업가 적 견해를 보자.

경영진이이 프로젝트의 성공을 원한다고 가정하면,이를 수행 할 수있는 좋은 위치에 있습니다. 이 실현이 중요한 이유는보고있는 경고 표시가 실제로이 프로젝트의 실패로 이어질 것이라는 확신과 확신을 개발해야하기 때문입니다 [1].

이것은 체계적인 사고와 대인 관계 의사 소통에 중요한 기술을 연습 할 수있는 기회입니다. 놓치고있는 문제와 잠재적 기회를 이해하고 시각화하여 가능한 한 명확하고 간단하게 의사 소통하는 전략을 개발할 수 있습니다.

기술을 향상시킬 수있는 기회를 여기에서 인식하십시오.

[1] 프로젝트를 취소하면 실제로 성공합니다. 실패는 나쁜 후에 좋은 돈을 쓸 것입니다.

당신은 무엇을 할 수 있나요

• 이것을 자신의 우수성 용어로 다루십시오. 그것은 "그들의"프로젝트 일뿐만 아니라, 당신도 실패 할 것이라는 것을 알고 있지만 소유권을 갖습니다. 왜? a) 당신은 조금 덜 실패하도록 도울 수 있기 때문에, b) 도전 시간에, 가장 많이 배우는 곳입니다. c) 자신의 우수성 메트릭스를 통해 스스로를 측정해야합니다. 최선을 다하면 프로젝트를 저장하지 못할 수도 있습니다. 여전히 자신을 자랑스럽게 생각할 수도 있습니다

• 다른 동료 개발자들과 이야기하고 그들이 생각하는 것을 알면, 많은 사람들이 신중하게 수행하면 같은 좌절감을 공유한다는 것을 알게 될 것입니다 (사람들이 당신이 mutyy 또는 무언가를 시작하고 싶다고 생각하지 않도록하십시오). 다른 사람도

• 문제를 무시하지 않으면 문제가 해결되지는 않을 것입니다. 모든 확률에 대해 여전히 문제를 해결하는 방법에 대해 이야기하는 것입니다. 프로젝트가 덜 비참하게 실패합니다. 어떻게합니까? 글쎄, "가혹한 일이 힘들어 질 때"또는 "필요한 시간이 절망적 인 조치를 정당화한다"와 다른 위기에 대한 아이디어는 거의 없다. 주말 근무). 이것은 당신이 리더십을 보여줄 수있는 시간입니다 (팀장 / 선임 직에 있지 않다면 조심스럽게). 그러나 당신은이 이점을 취하고 그들의 조롱이 될 수 있습니다. 모든 사람들이 그것을 알고 있습니다.

• 경영진이 알고 있지만, 매우 신중하게, 그들이 알고 있다면, 그들이 대립하지 않고 차분한 방식으로이 사실을 알려 주면 감사 할 것입니다. 전에 그것에 대해. 감정적 인면이없고, 명백한 사실이없고, 의제없이이를 서비스로 알려야합니다. 그들이 당신이해야한다고 생각하는 것을 물어 보면 (이것은 훌륭한 신호이지만 드문 경우입니다) 다음 섹션을보십시오

할 수없는 일이지만 경영진은 아마도

• 그들은 "도움"프로젝트에 더 많은 사람을 추가해서는 안 볼 이

• 고객에게 즉시 전화하여 나쁜 소식을 전하십시오. 이것이 왜 좋은 생각입니까? 글쎄, 나는 민첩한 소프트웨어 개발을 위해 선언문을 인용 할 것이지만, 그것 없이도 워터 애호가조차도 나쁜 놀라움을 싫어한다. 고객이이 프로젝트가 실패 할 운명이라는 것을 이미 알고 있다면 불행 할 것입니다. 그것. 고객은 많은 작업을 수행 할 수 있지만 대부분은 전달할 수없는 제품 (또는 품질이 좋지 않은 제품)을 찾는 순간보다 나쁘지 않습니다. 고객은 테스트 직원 채용, 해외 IT 직원 채용, 내부 교육 계획 변경 등 모든 직원이 정직하기 때문에 감사하게 생각합니다.

• 고객과 함께 프로젝트에서 무언가를 만들 수있는 방법을 생각할 때 가장 일반적인 것은 물건을 정리하는 것입니다. 예를 들어, 설계 방식을 개발하기에는 너무 어려운 일부 기능이있을 수 있으며 고객이 약간의 수정 및 단순화에 동의하면 일부 기능이 더 단순 해집니다.

• 더 높은 경영진을 업데이트하면 업무를 계속 유지할 수 있습니다.

당신이해야합니까 NOT 할

• 프로젝트에 더 많은 사람을 추가하도록 요청하십시오 ( 이것 참조 ).

• 다른 직업 (적어도 아직은 아님)을 종료 / 찾으십시오. 이것은 당신이 배울 수있는 것입니다. 많은 것들을 더 잘 이해하고, 더 나은 시간 관리, 더 나은 디자인, 코드 작성, 동료 및 경영진과의 협력에 대해 배우게됩니다. 다른 이유로 인해가 아니라 거기서 일하는 것을 좋아하지 않는다면이 2 개월이 지난 후에 일자리를 찾으십시오.

• 프로젝트, 관리, 당신이 물려받은 나쁜 디자인, 당신이 1 시간 걸리는 무언가를 설명하기 위해 3 시간이 걸린다는 멘토링을받는 멘토링에 대해 불평하거나 불평하거나 부정적인 반응을 보임 할 수있다.

• 관리를 비판하고 문제 해결 자로서의 목표가되고, 그들은 같은 배에 있으며, 그들이하지 않는 것을 알고있을 수도 있습니다. 업데이트 할 수 있습니다 (항상 자신의 직속 관리자를 업데이트하고, 그녀를 우회하지 마십시오)

• 사람들을 비난하십시오 (또는 자신), 결코 도움이되지 않습니다.

• 의료 장비가 아니라면 마감일을 놓치면 아무도 죽지 않을 것입니다. 소프트웨어이기 때문에 생계 마감일을 놓치면 휴식을 취하십시오.

그건 내 두 센트 YMMV

프로젝트에서 발생하는 문제를 찾아 객관적으로 가능한 한 명확하게 수량화하려고합니다. 모든 "메트릭"을 수량화 할 때마다이 메트릭이 중요한 이유를 정의해야합니다. 특정 메트릭이 "허용 가능한 범위"내에 있지 않은 경우 결과에 어떤 영향이 있는지 관리자에게 통찰력을 제공하고자합니다. 각 값에 대해 "Good", "Acceptable", "Problematic"또는 "Bad"값을 나타내는 지침을 제공해야합니다. 모든 기준을 미리 정의하십시오. 가능하면 프로젝트가 성공하기 위해 최소한으로 필요한 것을 설명하고 현재 프로젝트와 대조 할 수 있습니다.

• 정적 코드 품질은 수많은 정적 분석 도구로 수량화 할 수 있습니다. 적합하다고 생각되는대로 간단하거나 자세하게 유지할 수 있습니다. 내가 제안하는 통계는 다음과 같습니다.
  • 순환 복잡성
  • 코드 크기 (예 : 함수 / 클래스 당 줄 수, 파일 수, 테이블 수 ...)
  • 너무 큰 모듈 식별
  • 복사.
  • 코드 스타일 준수
• 결함 비율
  • 모듈 및 / 또는 서브 시스템 별 KLOC 별 (시스템의 문제가있는 부분 식별)
  • 팀 원당 금액을 계산할 수는 있지만 직접 유지해야한다고 생각합니다
  • 해결 대 발견
  • 버그를 해결하는 데 필요한 시간 (아마도 이것이 그래프를 작성하는 경우)
  • 현재 속도로 계속 진행되는 경우 필요한 시간을 추정 할 수 있습니다.
• 계획
  • 빌드 된 기능에 사용 된 추정 시간. 기능의 복잡성을 고려하십시오. 이것은 매우 정확할 필요는 없습니다. 이것으로 전달하고자하는 것은 "기능 A, B 및 C는 D, E 및 F와 같은 복잡성 주위에 있습니다. 예정된 시간에 ABC가 170 ​​%를 사용하는 기능을 사용합니다. 아무 것도 변경하지 않으면 동일하게 예상됩니다. DEF에 시간이 필요합니다. "또는"평균 기능이 계산 된 것보다 X % 시간이 더 걸립니다. "나머지 기능을보다 쉽게 ​​구축 할 수 있다고 가정 할 이유가 없으므로 향후 계획에서이를 보완해야합니다. 현실적이지 않으면 계획을 세우는 것은 아무 소용이 없습니다.
  • 매월 또는 바람직하게는 더 짧은 출시 일정을 갖도록 노력하십시오. 내부 전용 인 경우. 이것은 프로젝트에 필요한 시간을 추정하는 데 도움이 될 수 있습니다. 또한 비현실적인 약속을하지 않아도됩니다 (릴리스가 완료되기 전에 새로운 작업에 전념하지 않는 경우). 각 사이클을 계획하고 새로운 기능이 다음 주기에 만 입력되도록하십시오 (즉, 현재주기에 추가 할 수 없음).
• 테스트 범위 : "일반"테스트 범위 값을 설명하고 현재 범위가 어떻게 표시되는지 보여줍니다.
• 문서 : 실제로 얼마나 많은 %가 문서화되어 있습니까? 얼마나 좋은가요?
• 모듈성 :
  • 클래스 기반 (커플 링 및 결속)
  • 패키지 기반
  • 서브 시스템 기반 (통신 경로는 몇 개입니까?)

성공 여부에 관계없이 모든 프로젝트에서 작업을 수행하고 수행해야합니다. 업무 수행에 대한 대가를 받고 있습니다. 당신의 능력을 최대한 발휘하십시오. 프로젝트 관리자 / 리드가 아니라고 가정하면 프로그램을 취소해야하는지 여부를 결정하는 것은 귀하의 책임이 아닙니다. 느슨하게하기로 결정하는 것은 프로젝트를 취소하기로 결정한 것과 같습니다. 그것은 직업 설명의 일부가 아닙니다.

그러나 더 큰 그림에서 그렇다고해서 일주일에 50 시간, 60 시간 이상 일해야 일정을 달성하려고하는 것은 아닙니다. 다시 한 번, 프로젝트 목표를 달성하는 방법을 파악하는 것은 경영진의 임무입니다. 초과 근무 시간을 기꺼이 지불하지 않고 가족의 삶을 기꺼이 보류하지 않는 한 50 시간 이상의 근무 시간은 합리적인 선택이 아닙니다. 다시 한 번, 달성 가능한 일정을 잡는 것이 경영진의 일이었습니다. 그들은 비현실적인 일정을 맞추기 위해 직원들이 가족의 삶을 무시하도록 강요 할 수 있다고 가정 할 수 없습니다.

또한 일정이 1 1/2 개월 남았다 고 말할 수 있습니다. 아마도 "죽은 날짜"날짜가 아닐 것입니다. 일부 고객은 전부는 아니더라도 해당 날짜까지 가지고있는 것을 가져갈 수 있습니다. 일부 고객은 이미 프로젝트에 많은 돈을 가졌기 때문에 추가 자금을 마련 할 수 있습니다. 때때로 회사 자체는 고객 만족을 보장하기 위해 추가 비용을 부담 할 수 있습니다. 이 모든 것이 통제 할 수 없습니다. 최선을 다해 일을하십시오. 그것은 재난 프로젝트를 큰 성공 스토리로 바꿀 수있는 관리 옵션을 제공 할 것입니다. 나는 그것이 여러 번 일어나는 것을 보았습니다.

나는 다른 사람들의 말을 되풀이 할 수 있지만, 강조합니다 : 항상 최선을 다하기 위해 노력하고 종이 흔적을 남기십시오. CYA와 기술적 이유로 인해

당신의 길을 떠나는 것은 경영진의 개인적인 성격에 달려 있습니다. 그러나 그것이 무능하고 거짓말하는 관리를 받고있는 것이 지옥이라는 것을 말씀 드리겠습니다. 그러나 최악의 경우 자신과 동료의 존중은 그대로 유지됩니다.

죽음의 행진에 대한 기술적 측면을 잘 기록하십시오. 피할 수없는 인터뷰 질문 을 받으면 실패한 프로젝트에 참여한 적이 있습니까? 왜 실패했고 그것을 막으려 고 무엇을 했습니까? 이유가 있더라도 본 헤드 관리는 답이 아닙니다.

그것이 불가피하고 완전히 실패하고 프로젝트를 포기한다고 가정하는 쉬운 방법 일 수 있습니다. 컨설턴트로서 나는 종종 퇴보, 실패 또는 실패의 여러 단계에있는 프로젝트를 돕기 위해 초청받으며, 내가 지불하고있는 것의 일부는 그러한 프로젝트를 부활시키고 완료하는 것입니다.

당신이 완전한 실패로 보는 것은 관점에 따라 모든 사람에 의해 그렇게 인식되지 않을 수 있습니다. 이상적인 세상에서 모든 기능은 다른 시스템 및 테스트 된 모든 코드 라인과 상관없이 우아하고 독립적으로 코딩됩니다. 레브 1에서는 그와 같은 단일 프로젝트를 보지 못했습니다. 실제 세계에서 프로젝트를 배송한다는 것은 타협을하는 것을 의미하며, 일부 주요 기능이 누락되었을 수도 있지만 제품은 배송 할 수 있으며 최상의 베타 품질이지만 적어도 수정해야 할 사항에 대한 피드백을받을 수 있습니다. 이것의 단점은 소프트웨어가 결코 수행되지 않았 음을 관리자에게 알릴 수 있으며 진공 상태에서 특정 v 1.0을 개발하려고 시도하는 것보다 민첩한 방식으로 변경 사항을 반복하고 응답하는 것이 좋습니다. 마지막으로이 직책의 개발자로서 중요한 것은 이러한 조건에서 가능한 한 좋은 코드를 개발하는 것입니다. 문서화하고, (특히 외부 종속성의 경우) 직접 테스트를 작성하고, 시스템에 대한 지식을 사용하여 어떤 기능이 정말로 중요하고 필요한지 통신합니다. -일주일 또는 한 달 동안 기다릴 수있는 사람 자신의 우려에 대해 목소리를 내고 당신이 우리에게 한 것처럼 정당화하십시오. 계획 B를 준비하는 대신, 당신과 다른 가난한 영혼들은 아마도 제품이 배송 된 후에도 버그가 있고 코드를 작성하지 않은 모든 코드를 수정하게 될 것입니다. 퍼시스턴스 레이어 코드가 잘못되었다고 생각합니다. 다음 개정판에서 코드를 완전히 대체 할 수 있기를 바랍니다. 마지막으로, 절망하지 마십시오-그러한 상황을 다루는 것은 당신의 일의 일부입니다 다시 지불 받고 학습 과정입니다. 이 특정 프로젝트의 결과에 관계없이 이것은 미래의 소중한 경험으로 간주됩니다.