대규모 IT 프로젝트가 실패하거나 비용 / 스케줄 오버런이 큰 이유는 무엇입니까? [닫은]

저는 항상 전체 또는 거의 전체 재해 인 대규모 변환 또는 통합 프로젝트에 대해 읽습니다. 그들이 어떻게 든 성공을 거두더라도 비용과 일정은 크게 늘어납니다. 대규모 프로젝트가 실패하기 쉬운 이유는 무엇입니까? 이러한 종류의 프로젝트에 민첩성을 적용 할 수 있습니까, 아니면 전통적인 접근 방식이 여전히 최고입니다.

호주의 한 예는 프로젝트 성공을 위해 테스트 성공 기준을 변경 한 Queensland Payroll 프로젝트입니다.
이 SO 질문에서 더 많은 실패한 프로젝트보기 ( Wayback Machine )

공유 할 개인적인 경험이 있습니까?

주된 이유는 범위 가 증가 했기 때문에 "실용적인 프로그래머"라는 책은 다음과 같이 설명합니다.

• 특징 팽창
• 들어온다 기능주의
• 요구 크리프

삶은 개구리 증후군의 한 측면입니다.

다양한 "민첩한"방법의 아이디어는 피드백을 가속화하고 프로젝트의 시간 경과를 정확하게 수정하는 것입니다.

그러나 다른 이유는 릴리스 관리입니다 . 프로젝트를 릴리스하는 데 중점을 두지 않으면 (완벽하지 않을 수도 있지만) 너무 늦게 릴리스되어 버그가 많은 기능이 많으므로 수정 / 업데이트 / 수정하기가 더 어려울 수 있습니다 업그레이드).

그렇다고해서 릴리스 날짜가 고정되어 있지는 않지만 테스트 / 평가 / 릴리즈하려면 항상 실행중인 버전의 프로그램을 빌드 할 수 있어야합니다.

블로그 게시물 " 늦은 프로젝트는 한 번에 하루 늦습니다 "에는 더 많은 예제가 포함되어 있습니다.

'실제로 얻는 것'은 범위를 조정하고 시작 날짜를 고정시키는 것이지만 시간 내에 완료 할 수없는 기능에 동의하면 작동하지 않습니다.

이것이 우리가 사양을 옹호하거나 기능에 동의하지 않는 이유입니다. 이것이 문제의 근본 원인입니다. 첫 번째 픽셀이 페인트되거나 코드 라인이 작성되기 전에 필요한 것과 필요한 구현에 대한 모든 것을 알고 있습니다. .

유연한 선물에 대한 어려운 미래를 예측하면 어려움에 처하게됩니다. 리지드 미래는 가장 위험한 것들 중 하나입니다. 그들은 새로운 문을 여는 발견, 출현 및 실수의 여지를 남기지 않습니다.

일반적 으로 프로젝트 의 복잡성 은 과소 평가 됩니다.

Steve McConnell ( "Code Complete"명성의)은 고전적인 실수 의 목록을 가지고 있습니다.

많은 사람들에 의해 일부 비효율적 인 개발 관행이 자주 선택되어 왔으며, 이러한 예측 가능하고 나쁜 결과는 "고전적 실수"라고 불릴 자격이 있습니다 ...

이 섹션에는 30 가지의 고전적인 실수가 열거되어 있습니다. 나는 이러한 실수들 각각을 적어도 한 번은 개인적으로 보았고, 많은 실수들을 저 스스로 만들었습니다 ...

이 목록의 공통 분모는 실수를 피하면 반드시 빠른 개발을 할 필요는 없지만 피하지 않으면 개발이 느리게 진행된다는 것입니다.

쉽게 참조 할 수 있도록 목록은 사람, 프로세스, 제품 및 기술의 개발 속도 차원에 따라 분류되었습니다.

사람들

# 1 : 동기 부여 손상 ...

# 2 : 약한 직원 ...

# 3 : 통제되지 않은 문제 직원 ...

# 4 : 영웅 ...

# 5 : 늦은 프로젝트에 사람들 추가하기 ...

# 6 : 시끄럽고 복잡한 사무실 ...

# 7 : 개발자와 고객 간의 마찰 ...

# 8 : 비현실적인 기대 ...

# 9 : 효과적인 프로젝트 후원 부족 ...

# 10 : 이해 관계자 매입 부족 ...

# 11 : 사용자 입력 부족 ...

# 12 : 물질 위에 정치가 배치되었습니다 ...

# 13 : 희망적인 생각 ...

방법

# 14 : 지나치게 낙관적 인 일정 ...

# 15 : 불충분 한 위험 관리 ...

# 16 : 계약자 실패 ...

# 17 : 불충분 한 계획 ...

# 18 : 압력을받는 계획의 포기 ...

# 19 : 퍼지 프런트 엔드 동안 시간 낭비. "퍼지 프런트 엔드"는 프로젝트가 시작되기 전의 시간, 일반적으로 승인 및 예산 책정 프로세스에 소요 된 시간입니다.

# 20 : 변경된 업스트림 활동 ... "코딩으로 점프"라고도 함

# 21 : 부적절한 디자인 ...

# 22 : 부족한 품질 보증 ...

# 23 : 관리 제어가 충분하지 않습니다 ...

# 24 : 조기 또는 너무 빈번한 수렴. 제품 출시가 예정되기 직전에 제품 출시를 준비해야합니다. 제품 성능 향상, 최종 문서 인쇄, 최종 도움말 시스템 후크 통합, 설치 프로그램 개선, 예정되지 않은 기능 스텁 아웃 제 시간에 맞춰 준비하는 등

# 25 : 추정치에서 필요한 작업 생략 ...

# 26 : 나중에 따라 잡을 계획 ...

# 27 : 코드와 유사한 프로그래밍. 일부 조직은 빠르고 느슨하며 언제 어디서나 사용할 수있는 코딩이 빠른 개발 경로라고 생각합니다.

생성물

# 28 : 금도금 요구 사항. 일부 프로젝트는 처음부터 필요한 것보다 더 많은 요구 사항을 가지고 있습니다 ...

# 29 : 기능 크립 ...

# 30 : 개발자 금도금. 개발자는 새로운 기술에 매료되어 때로는 제품에 필요한지 여부에 관계없이 새로운 기능을 시험 해보고 싶어합니다.

# 31 : 날 밀어 붙여 협상을 끌어 내 ...

# 32 : 연구 중심 개발. 크레이 슈퍼 컴퓨터의 설계자 인 시모어 크레이 (Seymour Cray)는 실패 위험이 너무 높기 때문에 한 번에 두 개 이상의 영역에서 엔지니어링 한계를 초과하려고 시도하지 않는다고 말했다 (Gilb 1988). 많은 소프트웨어 프로젝트가 Cray로부터 교훈을 얻을 수있었습니다 ...

과학 기술

# 33 : 실버 불릿 증후군 ...

# 34 : 새로운 도구 나 방법으로 과대 평가 된 절감액 ... 프로젝트가 이전 프로젝트의 코드를 재사용 할 때 과대 평가 된 절감액의 특별한 사례가 발생합니다 ...

# 35 : 프로젝트 중간에 전환 도구 ...

# 36 : 자동 소스 코드 제어 부족 ...

큰 프로젝트 = 더 복잡성
복잡성 = 더 불확실성
더 많은 불확실성 = 세게 견적
세게 견적 = 잘못된 추정
나쁜 견적 = 비용 초과를

입찰 과정을 비난합니다. 그것은 거래가 종이에서 가장 저렴하고 빠르게 보이도록 할 수있는 그룹에게 보상합니다.

입찰을 함께하는 사람들은 이길 기회가 없다면 시간을 낭비하고 싶지 않으므로 정상적인 평가가 보류됩니다. POE 스위치 대신 일반 스위치를 지정하여 $ 80를 절약 한 사람들을 알고 있습니다. 그러나이 프로젝트에는 IP 카메라가 있었기 때문에 POE가 필요했습니다. 80 달러를 소비해야하지만 이제는 사양을 벗어납니다.

2 개월에 $ 2,000,000의 프로젝트가 얼마나 많은 입찰을 받더라도 2 개월에 $ 2,000,000이 소요될 것이라고 확신합니다. 제대로하는 것이 비싸다고 생각되면 기다렸다가 잘못하는 것이 얼마나 비싼 지보십시오.

하나의 가능한 이유는 실제로는 비용 증가가 복잡성 증가, 프로젝트 기간 연장 (요구 사항 변경에 더 많은 시간)으로 인해 2 차적 일 때 프로젝트 크기에 따른 비용의 선형 증가를 가정 할 때 추정치가 더 작은 프로젝트를 기반으로하기 때문입니다. 힘들고 프로젝트가 클수록 정확하게 예측하기가 더 어려워집니다.

또 다른 이유는 낙관적 편견 추정치입니다. 입찰에서이기려면 최적의 견적이 가격을 계산하는 데 사용됩니다. 프로젝트가 클수록 모범 사례가 적습니다. 입찰 규칙은 가장 낙관적 인 제안자가 수락을받을 가능성이 높으므로 5 개의 공급 업체가 현실적인 추정을하고 6 번째가 너무 낙관적 일지라도 낙관적 인 제안이 입찰에서 이기고 나중에 실패합니다. 이것은 일종의 부정적인 선택입니다.

중요한 것은 '관리'의 관점에서 비용이 일정을 배제하지 않는 것이 중요합니다. 우리가 알다시피, "아홉 명의 여성은 한 달에 아기를 낳을 수 없습니다" , 그러나 당신은 얼마나 많은 사람들이 그들에게 던져지는 돈의 양과 관련하여 깊이가 줄어든다고 생각하는 것에 놀랄 것입니다. 나쁜 프로젝트 관리, 종종 마이크로 관리의 형태로 나타납니다 (제 경험상) 대부분의 프로젝트 탱킹의 주요 원인입니다. '관리'가 무언가가 통제 불능 상태임을 깨달았을 때 미시 관리가 시작됩니다.

그것이 원인이 아닌 경우, 프로젝트의 예상 결과는 아마도 시작하기 어려울 것입니다. 내 경험상, 프로젝트의 기간이 너무 짧으면 사람들은 실수를 너무 두려워하여 '이중 작업'으로 이어지는 일을 전혀하지 않습니다.

그렇기 때문에 성공적인 프로젝트를 만들어 낸 주요 팀의 역사를 가진 노련한 프로그래머로 경영진을 채워야합니다. 그러한 사람은 가능한 수입에도 불구하고 "우리가 책임감있게 그렇게 할 수 없다"고 말하고 오랫동안 관리하지 않을 것이므로 많은 사람들이 PHD 대신 MBA에 (궁극적으로) 대답합니다.

프로그래머가 아닌 사람이 프로그래머를 고용하는 곳에서 근무한 회사 수를 잃었습니다. 채용 관리자가 아무 것도하고 싶지 않은 최근의 인터뷰에서 최근의 스포츠 이벤트에 대해 토론했습니다 (축구 경기라고 생각합니다). 담당 직원이 Knuth보다 NFL 코치로부터 더 많은 영감을 얻으면 프로젝트가 시작됩니다.

때때로, 당신은 잘 계획되고, 잘 이해되고, 현실적이며 겉으로는 똑바로 보이는 무언가에 부딪칩니다. 6 개월의 개발 기간에 관계없이 모든 것이 바뀌 었습니다. 일어난다. 그러나 드물게 프로젝트의 근본 원인이 영광스러운 돼지 통이되는 것입니다.

아직도, 나는 인정해야한다 .. 만일 당신이 뉴스를 보는 경우에, 당신은 가끔 오토바이 사고 나 기차 사고를 볼 수있다. 사고없이 매일 정시에 도착하는 수백만 개의 오토바이 나 기차에 대해 들어 본 적이 없습니다. 프로젝트도 마찬가지입니다. 물론, 정말 나쁜 일에 대한 공개 부검을 보는 것은 흥미롭지 만, 실제로 잘 진행된 일에 대해서는 거의 듣지 못합니다. 전차 프로젝트는 여전히 예외가 아니라 표준이라고 생각합니다.

대부분 다음 중 둘 이상의 조합입니다.

• 부서 간 협업 문제
• 정치 ... 너무 많은 정치 ...
• 잘못된 팀
• 비현실적인 스케줄링
• 적절한 방법론없이 범위 변경
• 누락 된 정보

주제에 관한 좋은 책 : Death March .

사람들은 소프트웨어 개발이 예측 과정이라고 생각하는 경향이 있으며, 1 년 전에 물건을 측정하고 추정하려고합니다. 이건 불가능 해! 건축 소프트웨어는 볼트 제조가 아닙니다.

같은 "트렌드"에 이어, 그들은 모든 가능성을 다룰 것이라고 생각하고, 나중에 프로그래머를 단순한 타이피스트로 바꾸겠다고 생각하는 거대한 analisys를 시도합니다. 이것이 효과가 있다고 어떻게 생각하십니까? 이런 종류의 행동은 단지 잘못된 추정과 많은 관료주의로 이어집니다.

프로젝트가 클수록 대규모 조직에서 일할 가능성이 높습니다. 조직이 클수록 관리 계층이 늘어납니다. 관리 계층이 많을수록 나쁜 소식 ( "우리가 감당할 수있는 것을 가질 수 없음")이이를 통제의 사슬로 만드는 것이 더 어렵습니다. 나쁜 소식이 적기 때문에 명령의 사슬을 구성 할 수 있으며, 환상 계획이 받아 들여질 수없는 것으로 알려진 후에 오래 지속될 가능성이 높습니다.

모든 규모의 소프트웨어 프로젝트는 "실패하는 경향"또는 "비용 초과가 발생" 당신은 모퉁이 사업의 비용 오버런 듣고하지 않습니다,하지만 당신은 할 연방 수사 국 (FBI) 가상 케이스 시스템 또는 덴버 공항 수하물 처리 시스템과 같은 것들에 대해 듣고. 따라서 모든 대형 시스템이 고장 나거나 모든 대형 시스템에 비용 / 스케줄 오버런이 발생하지는 않는다고 주장합니다.

나는 제 시간에 ( 프로젝트 중 한 번만 이동 한) 일정 과 사양 (우리가 많은 공급 업체 중 하나에 불과하기 때문에 예산 정보에 액세스 할 수 없음) 에 들어온 대규모 시스템 을 접했습니다. 나에게 여전히 인상적인 것은 (이 사이트에서 그것에 대해 조금 글을 썼음) 대규모 (고객 500의 첫 100 대) 금융 고객을위한 대규모 통합 고객 관리 시스템이었습니다. 나는 그들이 전화 회의 중 사람들의 급여에 대해 하루에 약 1 만 달러를 불렀다고 추정합니다.

수하물 관리 시스템의 경우 소프트웨어 관리자는 "이 크기와 복잡성 프로젝트를 기반으로이 시스템을 구축하고 디버깅하는 데 4 년이 걸릴 것"이라고 말했다. 영업 및 경영 관리자는 "공항은 2 년 만에 문을 열며 고객에게 2 년이 걸리므로 2 년이 걸릴 것"이라고 말했다. 프로그래머 또는 관리자가 아닌지 확인하는 테스트는 다음과 같은 질문에 대한 간단한 답변입니다. "수하물 처리 시스템이 늦었거나 정시에 이루어 졌습니까?"

고객이 원하는 것을 정확히 아는 경우 (아주 적은 수), 비용과 시간을 통제 할 수있는 경로를 따라갈 것입니다 (그리고 이들은 상당히 아웃소싱하는 경향이있는 사람들입니다). 프로젝트가 고객이 상상할 수있는 모든 가능한 기능을 충족해야하고 모든 부서에서 애완용 금 브릭이 프로젝트에 추가 될 때 거부권을 행사하는 경우 FBI와 같이 처음부터 실패를 막을 수 있습니다 VCF 프로젝트).

현실에 대한 인식

내가 찾은이 문제에 대한 가장 좋은 설명은 다음과 같습니다. businessballs.com에서 나무 그네

나는 프로그래밍 실력자에게 "현실의 지각" 이라는 개념을 일찍 소개했다 . 이를 위해 나는 정말로 감사합니다. 이것이 IT 프로젝트 뿐만 아니라 모든 프로젝트가 실패하는 가장 큰 이유라고 생각합니다 .

실패의 한 가지 이유는 큰 프로젝트는 일반적으로 중요하고 중요한 비즈니스 프로젝트이기 때문입니다. 프로젝트와 작업이 중요한 경우 사람들이 거짓말을하도록 권장합니다.

상사는 당신이 높은 쪽에서 완료 상태를 추정하기를 원합니다. 그는 낮은 쪽에서 오버런 및 지연을 추정하려고합니다. 문제가 발생하면 작업에 3 주가 추가 될 것이라는 말을 듣고 싶지 않습니다. 그는 오늘 밤 몇 시간 안에 작업 할 수 있다고 들었습니다.

그리고 등등.

나는 고객을 위해 몇 년 전에 한 프로젝트에있었습니다. 입찰 및 프로젝트 계획이 완료된 후 들어 왔습니다. 더 빠르고, 빠르며, 우스운 비용 절감 결정, 직원의 과도한 과부하, 직원을위한 리소스가 없어야한다는 지속적인 압박이있었습니다. 책상, 컴퓨터 등은 없습니다.

마지막으로, 프로젝트가 7 개월 1 천 6 백만 달러에 입찰되었다는 것을 알게되었습니다. 봉투 뒷면에는 24 개월이 걸리고 50 ~ 1 억이되어야한다고 추정했습니다. 나는 상사와 상사와 회의를하고 내 사건을 발표했으며, 시간이나 예산을 준수하지 못한 곳에서는 어떻게 오지 않았는지; 그들은 모든 문제를 경시했다. 회의가 끝날 무렵 CIO는 원래 입찰에 결함이있는 경우를 제외하고 두 관리자 모두 본질적으로 내가 말한 내용을 전화로 말했습니다.

기술이 내가 익숙하지 않은 기술로 변경했을 때 프로젝트를 시작했습니다. 나는 훨씬 나중에 누군가와 이야기했다. 프로젝트는 약 12 ​​개월 만에 3 천 5 백만 달러에 절반 정도 완료되었을 때 취소되었습니다.

큰 프로젝트는 사람들이 "이것은 실수입니다"라고 말하지 못하게합니다. 실수는 용납되지 않습니다.

VonC의 답변에 대해 자세히 설명합니다.

이 큰 프로젝트는 "전부 또는 전무"정신을 갖는 경향이 있습니다. 정의 된 프로젝트는 종종 기존 시스템과의 전환으로 인해 한 번에 릴리스되어야합니다.

이는 기능 / 요구 사항 크리프의 문제를 해결하기가 더 어려워 프로젝트가 실현 될 때 더 이상 요구 사항을 충족하지 않는 것으로 간주됨을 의미합니다. 기존 시스템이 업데이트되었거나 그 동안 기술이 발전한 경우 악화 될 수 있습니다.

이것에 대한 해결책은 무엇입니까?

아무도 두 개의 시스템을 병렬로 실행하여 변경되는 기능 세트를 두 시스템으로 나누기를 원하지 않습니다.

대규모 프로젝트의 복잡성은 외부 정치적 압력에 의해 심하게 악화 될 수 있습니다. 한 부서는 새로운 시스템에서 원하는 것에 대해 매우 명확하고 집중된 아이디어를 가질 수 있지만 관련 부서는 "글쎄요. 그렇게하는 한, 왜 그렇게하지 않습니까? 우리에게도이 작은 일이 있습니까? " "아니오, 그것은 범위를 벗어났습니다."라고 말하면서 시작할 수도 있지만, 청각 상들 사이의 정치적 싸움이 시작되고 모든 사람들이 파이 조각을 얻지 않으면 프로젝트 예산이 위협받습니다.

수년간 우리 지역 경찰은 자동차 시스템을 통해 부분 판을 검색 할 수 없었습니다.이 기능은 터무니없이 단순 해 보입니다. 친구에게이 기능을 추가하는 것이 어려웠던 점을 친구에게 물었고, 그들은 현대 데이터베이스로 전환을 제안 할 때마다 자동차 시스템과 상호 작용 한 상태의 다른 모든 부서가 시스템도 수정되었습니다. 그 결과 IT 현대화가 완전히 지연되었습니다. 마지막으로 국가는 시스템 전체의 현대화 노력을 수행하기에 충분한 자본을 모았고, 이는 너무나 복잡하여 혼란에 빠졌습니다.

아직 다루지 않았지만 아직 해결되지 않은 요소 :

거의 모든 극적인 실패는 낙찰 된 계약입니다. 그러한 상황에서 유능한 회사는 어떻게됩니까? 그들은 현실적인 추정을하므로 나쁜 추정을 한 사람에 의해 거의 확실하게 금지됩니다.

회사가 제대로 추정 할 수 없다면 시스템을 제대로 구축 할 수 없다는 것이 놀라운 일입니까?

ZDNet의 Michael Krigsman은 " IT Project Failures "에 관심을 가질만한 블로그 를 가지고 있습니다.

또 다른 요점은 수년에 걸친 긴 프로젝트의 경우 일반적으로 고려해야 할 업그레이드 또는 대체 솔루션이있을 수 있다는 것입니다. 이것들은 프로젝트가 시작될 때 주어지지 않았습니다. 예를 들어, 무언가가 6.0에있는 동안 시작할 수 있지만 첫 번째 단계가 완료 될 때 6.3 또는 6.4가 종료되고 업그레이드시기에 대한 질문이있을 수 있습니다. 요구 사항이 올바르게 수집되지 않았거나 누군가 마음을 바꿨 기 때문에 범위 및 원하는 기능의 변경은 이미 상당 부분 다루어 진 또 다른 몇 가지 사항입니다.

이러한 종류의 프로젝트에 민첩성을 적용 할 수 있습니까, 아니면 전통적인 접근 방식이 여전히 최고입니다.

잘 적용되는 민첩한 프로세스가이 문제로 어려움을 겪지 않는 이유는 단순한 이유 때문입니다. 민첩하게 큰 프로젝트를 시작할 수 없습니다. 둘 중 하나를 선택할 수 있습니다.

민첩한 프로세스를 사용하면 프로젝트의 미래에 한두 번의 반복 작업을 실제로 보지 않아도됩니다. 향후 2 년 동안에는 '계획'이 없으며 앞으로 2 주만 있습니다. 견해가 짧으면 몇 가지 타협을해야합니다. 디자인하는 어떤 종류의 위젯에 대해서도 "위젯의 최종 단어"를 만들 계획으로 시작할 수 없습니다. 대부분의 작업은 한두 번의 반복으로 수행 할 수있는 작업에 대한 것이므로 "감기 할 수있는 위젯"으로 시작할 수 있습니다.

이것에 대해 좋은 점은, 몇 번 반복 한 후, 당신은 이미 다른 사람이 유용 할 수있는 완료, 작업 제품이 특히 그 필사적으로 FROB 수있는 위젯이 필요 하나 개, 고객 과 zort을.

본질적으로 대규모 프로젝트는 모든 잠재 고객의 모든 문제를 해결하는 것을 목표로하기 때문에 실패 할 수 있습니다. 애자일 프로젝트는이 목표를 가지고 있지 않으며, 각 버전에서 단일 고객이 가질 수있는 중요한 문제 하나만 해결합니다. 하지만 오랜 시간이 지나면 민첩한 프로젝트가 많은 고객에게 중요한 문제를 많이 해결하고있을 수 있습니다.

• 실제 사용자에게 배송하지 않음

대규모 프로젝트는 수년 동안 "인프라"모드에 들어가는 경향이 있으며 실제 최종 사용자 기능을 구축하고 제공하는 것을 잊어 버리십시오. 배송 시점에는 변경 비용이 매우 비싸며, 최초의 실제 베타 테스트가 수행 된 후 가장 큰 개념 변경이 요청됩니다.

• 비용을 정확하게 예측하지 못함

프로젝트가 투자 수익을 능가하는 것처럼 보이면 취소됩니다.

• 품질 관리 실패

충분한 결함으로 인해 순방향 모멘텀이 0 이하로 떨어질 수 있습니다. 아무런 진전이 없다면 지속적인 존재를 주장하기가 어렵습니다.

그들은 Hofstadter의 법칙을 잊어 버렸습니다 : Hofstadter의 법칙을 고려하더라도 항상 예상보다 오래 걸립니다.

웹 개발에서 본 것들 :

• 요리사가 너무 많음-B & M 소매점에서 갑자기 웹으로 강조했습니다. 갑자기 20 명의 부서장이 새로운 헤드 치즈에 감동을주기 위해 모든 이니셔티브를 개척하고 있습니다. 법적으로 이전 아이콘의 모양이 마음에 들지 않았기 때문에 새로운 아이콘을 구현해야했습니다.

• "IE6의 아이콘은 IE7에 비해 약간 흐리게 표시됩니다. 실행중인 중요 작업을 중단하고 고객 기반의 .05 %에 참석하여 며칠이 걸리는 끔찍한 일을하십시오." "IE 경험을 구현하고 더 느리게하기 위해."

• 사내 개발자에게 조언을 구하는 데 귀찮게하지 않은 비 개발자가 선택한 나쁜 도구.

• 툴로 선정 된 나쁜 개발자- "버전 제어를 사용하기에는 너무 적은 지식을 가진 200 명의 코드를 모르는 사람들을 아웃소싱 할 수있을 때 20 개의 유능한 Java 개발자에게 왜 급여를 지불해야 하는가?" 다른 국가의 사람들과 동시에 동시에 3 개의 큰 앱을 위해 백엔드에서 작업합니다.

• Bad / Broken Architecture-해고 당했거나 어제 관리자 인 사람들에 의해 당황하고 어제 완성 된 코드 레이어에 레이어.