프로젝트에서 조심해야 할 운명의 경고 신호는 무엇입니까? [닫은]

실패한 프로젝트를 수행 한 것은 사용 된 언어, 산업 또는 경험에 관계없이 대부분의 프로그래머가 공통적으로 가지고있는 몇 안되는 것 중 하나입니다.

이 프로젝트는 훌륭한 학습 경험, 영혼을 부수는 재앙 (또는 둘 다) 일 수 있으며 여러 가지 이유로 발생할 수 있습니다.

• 마음의 경영 상 변화
• 미숙련 / 자원 부족 팀
• 개발주기 동안 우수한 경쟁 업체의 출현
• 오버 / 언더 관리

이러한 두 가지 프로젝트를 수행 한 후에는 프로젝트가 실패 할 때 정확히 초기 단계에서 인식 할 수 있습니까?

나를 위해 큰 징조는 기능 크리프와 결합 된 단단하고 빠른 외부 마감일을 가지고 있습니다 . 지연된 기능 요청이 시작되고 최종 "전달 가능"항목에 추가되면 프로젝트가 제대로 계획되어 일정대로 진행되고있는 것을 본 적이 있습니다. 이 요청의 제안자들은 "단지 하나만 더"요구하지 않고 거의 방을 나가지 않아 콜럼 보라 는 별명을 얻었습니다 .

머리에 임박한 운명의 알람 벨을 설정 한 경고 표시는 무엇입니까?

영웅적 코딩

늦은 밤에 코딩하고, 오랜 시간을 일하고, 초과 근무를 많이 보는 것은 무언가 잘못되었다는 확실한 신호입니다. 또한 내 경험에 따르면 누군가 프로젝트의 어느 시점에서 늦게까지 일하는 것을 보게되면 더 나빠질 것입니다. 그는 일정대로 자신의 기능 하나를 되찾기 위해 그것을하고있을 수도 있고 성공할 수도 있습니다. 그러나 이와 같은 카우보이 코딩은 거의 항상 계획 실패의 결과로 필연적으로 더 많은 결과를 초래할 것입니다. 따라서 프로젝트의 초기 단계에서 볼수록 결국 더 나빠질 것입니다.

프로그래머가 "코드가 끔찍하기 때문에 처음부터 다시 시작해야합니다."라는 논쟁에서 승리하기 시작했습니다. 성숙한 응용 프로그램에서.

더 잘 만들 수 있다고 생각하거나 문제를 더 완전히 이해한다고 생각할 수는 있지만 실제로는 그렇지 않습니다. 아 그리고 그 못생긴 패치들? 그것들은 재 작성에서 다시 도입 될 실제 문제에 대한 수정입니다.

또한 언젠가 6 개월 동안 작업 한 후 응용 프로그램을 시작할 때 기능의 거의 85 %와 버그의 150 %에 이르는 이유를 프로젝트 관리자에게 설명해야합니다.

문제 해결사로서의 새로운 도구.

사람들이 익숙하지 않은 도구를 사용하기 시작하면 신경 쓰지 않지만 계속주의를 기울입니다. 그들이 도구에 광고 된 모든 혜택을 일정에 계획하기 시작하면 걱정이됩니다. 재미있는 예 :

• 우리는 객체 지향 언어를 사용하려고 시도하기 때문에 한 달 일정을 단축 할 수 있습니다 (우리가 가진 모든 것이 c 개발자 임에도 불구하고).
• 우리는이 새로운 스크럼을 시도해 볼 것입니다. 그것은 모든 프로세스 문제를 해결합니다!
• 프로젝트가 반쯤 끝났다는 것을 알고 있지만 ORM을 새로운 것으로 바꾸면 어떻게 될까요?

새로운 기술과 관행은 훌륭하지만 거의 모든 이점을 얻을 수는 없습니다.

나에게 가장 큰 문제는 바로 비즈니스가 서면 요구 사항을 시간 낭비로 간주 할 때입니다.

그래서 기본적으로; 서면 요구 사항 없음

죽음의 키스입니다.

관리 연결 해제

마감일, 기능, 인력 등을 담당하는 사람들이 프로젝트를 담당하는 사람들과 연결이 끊어 질 때. 이것은 다음으로 이어질 수 있습니다.

• 고객이 기능 비용을 이해하지 못하는 사람과 이야기 할 때 기능 크립
• 새로운 개발자가 도움보다 방해가 될 정도로 늦게 프로젝트에 투입되는 Man-month syndrome
• 마감 결정의 비즈니스 결과를 처리해야하지만 구현 결과는 다루지 않는 사람들이 만든 비현실적인 마감일.
• 고객과의 커뮤니케이션이 중간에 관리에 의해 방해 될 때 문제를 해결하지 못하는 제품.
• 잠재적 인 문제가 개발자와 관리 사이에 조기에 충분히 전달되지 않는 위험 관리 부족.

따라서 경영진이 프로젝트에서 관심이없는 것처럼 보이거나, 의사 소통이 잘되지 않거나, 고객의 말을 듣지 않거나, 개발자의 말을 듣지 않거나, 언덕을 향해 달려갑니다.

1. 주요 개발자가 떠나고 경영진이 신경 쓰지 않을 때

2. 주요 개발자가 떠날 때 다른 개발자가 신경 쓰지 않는 경우

첫 번째는 일반적으로 팀 역학 ( "10x 수퍼 스타", 괜찮은 프로그래머, 서로 상호 작용하는 방식)에 크게 영향을받지 않는 관리자를 나타냅니다.

두 번째 숫자는 일반적으로 나머지 개발자들에게 심각한 관심 부족을 나타냅니다.

누군가가 일반적으로 경영진은 "우리는 할 시간이 없다"고 말합니다.

일반적으로 문서화 또는 코드 검토와 같이 시간이없는 것보다 앞서는 것 (모든 형태의 테스트를 포함하여 다른 어떤 것보다 더 많은 버그를 통계적으로 찾아서 수정)

고객, 마케팅 또는 경영진이 날짜를 선택한 다음 가상 일정으로 거꾸로 작업하도록하십시오.

경영진이 비즈니스에 "아니오"라고 말하기에는 너무 약한 경우.

IT 부서에 대한 신뢰 부족으로 인해 개발자가 해킹 (예 : 누군가의 컴퓨터에서 실행중인 데이터베이스 액세스)을 생성하여 IT 부서에 악몽이 될 수 있습니다. 중요한 시스템을 마이그레이션해야합니다 ...

내가 생각할 수있는 첫 번째 나쁜 징조는 경영진이 나쁜 소식을 체인이나 고객에게 전달하지 않기를 바라는 것입니다. 나는 몇 번이나 생각할 수 없다. 개발자는 몇 주 또는 몇 달 앞선 마감 시간을 맞출 수 없다는 것을 입증했지만 아무도 고객에게 말하고 싶지 않습니다. 나는 그 필요성이 사전에 잘 설명 될 때 진지한 이유가있을 때 마감일을 지키지 않는 고객을 거의 보지 못했다. 마감일이 지나지 않아서 다음 날에도 만나지 않을 것이라고 2 달이 지났다고 말했을 때 나는 종종 화난 고객을 보았습니다. 이 시점에서 그들은 프로세스에 의문을 제기 할 수 있습니다.

실패가 다가오고 있다는 또 다른 확실한 신호는 새로운 개발자를 현재 시스템을 이미 이해하고있는 사람들이 아니라 프로세스의 가장 어렵고 복잡한 가장 중요한 부분에 할당하는 것입니다. 그런 다음 실제로 작업이 제대로 완료되고 있는지 또는 질문이 있는지주의 깊게 보지 마십시오 (질문이없는 경우 큰 빨간색 플래그). 새로운 직원은 자신이 가지고 있다고 주장하는 기술이 실제로 있다는 것을 알 때까지 모니터링해야합니다. 중요한 프로젝트를 받았고 몇 달 동안 모든 것이 괜찮 았다고 말한 후 마감일로부터 일주일 전에 종료한다고 말한 신입 사원의 작업 (이미 받았을 때 마감일이 지났음)을 다시 실행하는 데 어려움을 겪는 한 여름을 보낸 것을 여전히 기억합니다. 그는 아무 것도 할 수 없었습니다.

실패의 또 다른 확실한 징후는 개발자가 먼저 수행되는 다른 작업에 의존하고 수행되지 않거나 시작되지 않은 작업을 수행하는 경우입니다. 경영진이 작업을 올바른 순서로 할당 할 수 없으면 튜브를 내려 가게됩니다.

물론 매번 마감일을 되 돌리지 않고 기능 크립은 상황이 나빠질 가장 일반적인 징후 중 하나입니다. 내 접시에 20 시간의 작업을 추가하면 마감 시간이 20 시간 씩 이동합니다. 그렇지 않으면 프로젝트가 실패하고 보장됩니다.

제가 경력에서 본 한 가지 확실한 신호는 경영진이 일정에 시간을 보충하기 위해 더 많은 신체를 투입하는 것에 대해 이야기하기 시작할 때입니다. 실제로 프로젝트 도움말에서 더 많은 시체를 본 적이 없습니다.

기술이 아닌 관리자가 자격을 갖추지 못한 기술적 결정을 내릴 때 크고 큰 붉은 깃발!

가장 확실한 표시는 직원 이직률이 높다는 것입니다. 모두가 새로운 일자리를 찾고있을 때 아마 당신도해야합니다.

또 다른 명백한 징후는 진보가 없다는 것입니다. 1 년이 지났는데 목표에 더 가까워 보이지 않는다면 운명에 처한 것입니다. 이는 특히 요구 사항을 구현할 수있는 것보다 빠르게 변경하는 경우에 발생합니다.

지루한 팀원.

당신은 "90 % 완료", 다음 주 배달은, 그러나 당신이 떠난 것은 "테스트"이기 때문에 괜찮습니다.

• 모두 육체적으로 정신적으로 지친
• 고객 / 사용자는 타임 스케일 또는보고있는 것에 대해 분명히 불만족합니다.
• 원래 아름다운 디자인은 이제 타협 느낌
• 당신은 당신이 정말로 고치지 만 해결할 수없는 상대적으로 중요한 버그들과 함께 사임했습니다.
• 당신은 자존심을 유지하는 것이 당신이 배송하는 것보다 배송 행위에 있다는 것입니다-전문적인 자존심보다 생존자 정신에 더 가깝습니다
• 팀은 작동하지 않는 부분이 있고 그 부분을 무시하고 거기에있을 수있는 것이 무서워서 최선을 바라고 있다고 두려워합니다.
• 모든 사람들은 자신이 위와 그 이상을 넘어 섰음을 확신합니다.
• 사람들이 소진의 징후를 보이고 있습니다 (일반적인 비관론, 무관심, 분노)

(Jim McCarthy의 소프트웨어 개발 역학 에서 발췌 ).

카우보이 코더, 큰 자아 및 관리 승인

프로젝트 계획에 1 개월 이상의 프로젝트 에 대해 단일 반복 설계, 개발, 테스트 및 배포 (클래식 폭포)가 필요한 경우 1 마일을 달리게됩니다.

완벽하게 민첩 할 필요는 없지만 개발주기가 짧으면 모든 사람 (고객, 관리자 및 개발자 자신)에게 진행 상황을 보여주고 불가피한 상황에서 변경된 요구 사항에 대처할 수 있습니다.

범위 내에서 야생을 달리는 개발자

다른 개발자 (또는 불행히도)가 디자인과 크게 다른 구성 요소를 개발했으며 시스템 / UAT 테스트를 거치기 전까지는 이러한 구성 요소를 발견하지 못했음을 알았을 때 이런 일이 발생했습니다. 나는 버그를 말하는 것이 아니다. 중요한 시스템 구성 요소에 누락 된 기능이 있거나 기능에 대한 요구가 없으며 상당한 재 작업없이 UAT를 통과하지 않을 것이라고 말하고 있습니다. 이 문제는 다음을 나타냅니다.

• 품질 시스템이 고장났습니다. 관련 개발자가 설계 / 구현 단계에서 문제를 해결하지 못한 이유는 무엇입니까? 코드가 검토 / 검사되지 않았습니까? 단위 및 통합 테스트가 왜이 문제를 해결하지 못했습니까? 일관된 단위 / 통합 테스트가없는 경우 문제가 발생합니다.
• 프로젝트 관리자 / 기술 책임자는 개발 팀을 통제하지 않습니다. 개발자가 필요한 것을 제공 할 수 없으면 완전한 솔루션을 제공 할 수 없습니다.

프로젝트의 주요 개발자가 몇 주 동안 코드를 체크인하지 않았고 심각한 이정표가 올 때.

계약직이었고 더 많은 선임 개발자와 PM은 팀을 구성하여 더 큰 규모의 컷 인을 시도하여 다른 개발자가 3 주 동안 중요한 코드 인질을 잡기로 결정했습니다. 결국, 우리는 무능한 PM (6 개월 동안 프로젝트를 파멸시키기 위해 보낸 시간)을 해고하고 개발자와 이야기를 나 we습니다.

말할 것도없이, 나머지 프로젝트는 마조히즘적인 죽음의 행진이었고 사양 동결이 지연되었고 고객에게 PM이 프로젝트를 떠난 끔찍한 일정을 보충 할 수있는 많은 양보 기능이 주어졌으며 프로젝트의 품질이 떨어졌습니다. 그것 때문에 모든 주위에.

PM은 심지어 고객과의 회의를 버리고 히스 핏을 맞추기 위해 CDR (Critical Design Review)을 위해 신경을 쓰게되었습니다. 그가 프로젝트에 따라 여행 경비를 지불 할 것을 요구했을 때, 그는 자신에게 간음하라고 정중하게 들었다.

해당 프로젝트에 영향을 준 다른 답변 중 5 개 이상으로 쉽게 확인할 수 있습니다. 요컨대, 첫 번째 심각한 코딩 프로젝트에 대해 많은 어려운 교훈을 얻었습니다.

그 중 첫 번째 사인은 그들이 우리가 향후 10 주 동안 몇 시간을 초과 근무할 것인지를 물었고, 급여를받은 근로자에게 프로젝트의 성공과 마감일 준수에 따라 초과 근무를 할 수있는 보너스를 제공했을 때였습니다.

내가 본 다른 주요 징후 : 요구 사항 정의가 일정을 초과하고 종료 날짜가 이동되지 않습니다. 우리는 심지어 시작하기 전에 뒤에 있었다. 데이터베이스 디자인과 사이트 디자인은 시작하지 않았지만 디자인과 생성되지 않은 테이블로 가져 오기를 수행하여 시간에 맞춰 전달할 것으로 예상했습니다.

임계 경로의 항목이 순서 대신 동시에 수행되는 경우 (도구 X를 사용해야하고 프로그래머 A가 방금 빌드를 시작하면 작업이 지연됩니다.)

관리자가 추수 감사절에 코드를 작성하는 경우

오후 11시 이후와 오전 6시 이전 날짜 스탬프가있는 이메일을 받기 시작하면

복잡한 문제를 처리하는 방법에 대한 모든 질문에 동일한 대답이 나오면 "아직 걱정하지 마십시오."

고객이 여전히 품질 보증에 들어가거나 생방송하기 전에 요구 사항을 변경하는 경우.

진행 부족에 대해 토론하기 위해 몇 시간이 걸리는 매일 회의를 시작할 때. 내가 하루 종일 모임에 있기 때문입니다. 매일 5 분 간 회의, 1 시간 넘게 진행되는 매일 회의.

데이터베이스 팀과 애플리케이션 팀이 서로 대화하지 않는 경우

클라이언트가 약속 된 정보를 제 시간에 제공 할 수 없을 때. 특히 데이터 가져 오기 파일이고 코드가 어떻게 작동하는지 확인하기 위해 데이터베이스에 해당 데이터가 필요한 경우.

관리자의 사무실 외부에 정지 등을 설치하여 그날 그에게 접근하는 것이 안전한지 알려줄 때.

마감일이 다가 오면 실패한 프로젝트를 발견하는 것이 일반적으로 쉽다고 생각합니다. 당신이 말했듯이, 특징적인 크리프는 석재 마감 기한과 결합되어 프로젝트를 죽이는 확실한 방법입니다.

그러나 핵심은 실패한 프로젝트 방식을 미리 파악하는 것입니다. 나는이 경우에 '진정한 징표'가 유일하게 '우리가 언제 끝났는가'에 대한 정의가 부족하다고 생각한다. 오프셋에서이 사실을 알지 못하면 실패 IMO에 대한 운명입니다.

나는 지난 5 년 동안 3 번의 죽음 행진에 처해있었습니다. 내 직감이 임박한 운명에 기여한 몇 가지 사항이 있습니다.

• 이 회사는 주니어 개발자가 새로운 기능을 디자인하고 개발하도록 결정하고 더 비싼 수석 개발자에게 버그를 수정하도록 지정합니다.
• 이 회사는 중요한 소프트웨어 구성 요소를 필요한 도메인 전문 지식이없는 타사에 아웃소싱합니다.
• 크런치 타임 사이클이 너무 가까워 사람들의 건강이 나 빠지고 있습니다.
• 당신의 팀장이 약을 복용하면 매일 밤 자면서 약을 복용합니다.
• 클라이언트는 변경 주문을 분석 할 수있는 것보다 빠르게 보냅니다.
• 몇 주 안에 몇 년간의 작업을 수행해야하지만 경영진은 기능 동결을 거부합니다.
• 하드웨어 공급 업체는 일정에 따라 실행 가능한 제품을 제공하는 데 어려움을 겪고 있으며 회사의 의사 결정자는 대안을 고려하지 않습니다.
• 프로토 타입 장치 개발자는 아마도 비현실적인 일정이 사라지고 최고의 실무진에게 기분이 좋게 전달 될 수있는 기회를 가질 수있는 유령을 갖게됩니다.
• 첫째 주 : "아, 쓰레기, 코드가 엉망이야. 모두 새로운 기능을 끝내고 버그를 고쳐라." 둘째 주 : "아, 헛소리, 우리는 기능 스케줄을 충족시키지 않을 것입니다. 모두 버그 수정을 그만두고 새로운 기능을 작성합니다." 무기한 반복하십시오.
• 개발은 한 국가에서 이루어지고 QA는 전 세계 다른 국가에서 이루어 지므로 버그에 대한 왕복 통신에는 항상 24 시간이 필요하며 관련 담당자 중 한 명 이상이 복잡한 기술 문제를 논의하고 있습니다. 능숙하지 않은 언어로

저에게는 기능 세트 (일명 관리자, 제품 소유자, 고객 등)를 담당하는 사람들이 돌보지 않거나 대답에 대해 희망이없는 것처럼 보일 때입니다. 기능에 대한 질문은 냉담하고 낙담합니다. 그들이 프로젝트에 대한 투자 나 신뢰를 잃어버린 것은 분명합니다.

이것은 내가 진행중인 프로젝트가 "상위 경영진의 변화"에 부딪쳤을 때 나에게 일어났다. 나는 그것이 어떻게 작동 해야하는지에 대해 질문하고 있었고 갑자기 아무도 진정한 의견을 가지고 있지 않았습니다.

잠시 후 프로젝트가 취소되고 내가 작성한 모든 아름다운 코드가 폐기되었습니다.

Paul Vick은 몇 년 전 블랙홀 프로젝트 에 관한 훌륭한 글을 썼습니다 . 나는 모든 조언이 관련이 있다고 생각합니다. (길이에 대한 항목 및 요약을 편집했습니다.)

• 대단한 목표 . "사람들이 컴퓨터로 작업하는 방식을 근본적으로 다시 상상하십시오."
• 완전히 비현실적인 마감일 . 일반적으로 원래 코드베이스를 원래 시간보다 훨씬 적은 시간에 다시 작성할 수 있다고 생각하기 때문입니다.
• 호환성에 대한 비현실적인 신념 . 추가 노력없이 모든 작은 문제를 다시 작성하고 보존 할 수 있다고 믿는 것처럼.
• 결코 도착하지 않는 주요 마감일로부터 항상 "6 개월" . 또는 도착하면 보상을 위해 프로젝트 끝에 다른 이정표가 추가됩니다.
• 엄청난 양의 자원을 소비해야합니다 . 일반적으로 하나 이상의 기존 제품에서 생명의 혈액을 빨아들입니다.
• 아직 입증되지 않은 새로운 기술을 사용하십시오 . 따라서 새로운 기술로 모든 확장 성 문제를 해결할 수 있습니다.

나는 정신적으로 "모든 것이 괜찮습니다. 우리는 걱정할 것이 없습니다." 경영진의 말을들을 때마다 "우리 모두 망 쳤어" 일반적으로 관리자가 관련없는 회의 ( "아, 그런데 모든 것이 잘 진행되고 있습니다. 걱정할 이유가 없습니다!")에서 실수로 문제를 처리한다고 들었지만, 특별히 회의를 열라는 것은 더 큰 위험입니다.

나는 관리자가이 선을 따라 무언가를 말하고 거짓말로 판명 되지 않았습니다 .

죽은 프로젝트의 몇 가지 점은 내가 속한 부분입니다.

• 경영진은 팀을 두 배로 빠르게 마무리합니다.
• 개발자는 기한을 맞추기 위해 "매립"버그를 시작하고 명백하지만 코드 검토 중에는 무시됩니다.

경영진이 프로젝트를 동시에 다른 방향으로 끌어 당기고 캐리지는 여전히 남아 있습니다.

한 번은 두 사람이 관리하는 프로젝트에 참여했습니다. 그들은 서로 대화하지 않았거나 각자 해결해야 할 자아가 있었지만 매주 정도 반대 방향으로 우리의 사역을 지휘하고있었습니다. 결과가 없을 것이라는 것을 깨닫기까지 오랜 시간이 걸리지 않았습니다. 기꺼이 내 참여는 몇 달 동안 지속되었습니다.

간결한 기사 : IT 프로젝트가 올바르게 진행되는시기 참조 .

기사에 명시된 요소가 없으면 알람 벨이 울리도록 설정해야합니다.

따라서 프로젝트에 다음 사항이 모두 있는지 확인하십시오. 그렇지 않은 경우 걱정해야합니다.

(위 기사를 인용하기 위해 :)

1. "첫 번째는 달성해야 할 대상에 대한 명확한 비전을 기반으로한다는 것입니다."

2. "두 번째 특징은 비즈니스 전반에 관련된 여러 당사자, 특히 고위 경영진의 지원과 헌신에 관한 것입니다."

3. "세 번째는 해결해야 할 문제에 대한 이해입니다."

4. "최종의 공통된 특징은 충분한 자원과 기술을 이용할 수 있다는 것입니다."

통계적으로 소프트웨어 프로젝트 시작은 압도적 인 대다수의 사람들처럼 실패 할 것이라는 징조입니다 ...