소프트웨어 프로젝트가 실패하는 20 가지 이유
모든 소프트웨어 프로젝트는 큰 꿈과 큰 비전으로 시작됩니다. 대체 우주 어딘가에는 모든 꿈을 이루는 프로젝트가 있지만 우리 우주의 소프트웨어 프로젝트는 결승선을 향해 비틀 거리며 때로는 교차합니다.
물론 정의에 따르면 소프트웨어 프로젝트 실패는 이진 작업이 아닙니다. 잘 실행되지만 아무도 사용하지 않는 코드로 끝날 수 있습니다. 또는 당신은 심지어 컴파일되지 않습니다 코드로 끝낼 수 있습니다. 때때로 당신은 불타는 잔해에서 유용한 무언가를 회수 할 수 있으며 때로는 폭발하기 전에 도망가는 것이 가장 좋습니다.
연기가 난 난장판이 식으면 부검이 시작되는데,사람들은 무엇이 잘못되었는지 알고 싶어한다. 여기에 가장 일반적인 범인이 있습니다.
너무 적은 팀원
너무 적은 프로그래머와 너무 많은 일을하려고하는 것은 일반적인 문제입니다. 개발자는 불타기 전에 너무 많은 코드 만 연마 할 수 있습니다. 나는 한 번 관리자가 민첩한 팀에서 더 많은 작업을 짜내는 올바른 방법은 이전 팀 직후에 시작되도록 각”스프린트”를 예약하는 것이라고 생각한 팀에서 일했습니다. 무슨 일이 있었는지 알아 내기 위해 사려 깊은 일시 중지가 없습니다.스프린트 42 는 수요일 오후 1 시 59 분에 끝났고 스프린트 43 은 수요일 오후 2 시에 시작되었습니다. 회고 분석 회의는 다음 스프린트가 이미 시작된 후에 예약되었습니다. 어떤 영리한 사람은”마라톤”으로 이름이 바뀌었고 곧 다른 직업을 찾을 것을 제안했습니다.
물론 얼마나 많은 프로그래머가 충분한지 알기는 어렵습니다. 때로는 장애물과 문제가 방해가됩니다. 일이 크기에서 두배로 한다 그러나 너는 일에 충분한 사람이 있지 않으면,너의 계획사업은 아마 운명을 정한다 고 매니저 결함 이지 않을지도 모르지 않는다.
너무 많은 팀원
너무 적은 프로그래머가 나쁠 수 있다면 네트워크 효과가 소프트웨어 프로젝트를 파멸시킬 수 있으므로 너무 많은 프로그래머가 잠재적으로 악화 될 수 있습니다. 더 많은 사람들이 더 많은 조정을 의미하고 그 코드를 작성에서 멀리 시간을내어,더 많은 회의를 의미한다. 그러나 충분한 회의를 개최하지 않으면 곧 팀 비의 마이크로 서비스를 인터페이스하지 않는다는 것을 알게 될 것입니다.
프로젝트를 지나치게 집중함으로써 문제에 돈을 던질 수 있다면 좋겠지 만 할 수는 없습니다.
너무 많은 커뮤니케이션
소프트웨어를 쓰는 것은 독방 예술입니다. 인간은 함께 일할 수 있지만 제한된 관찰에서만 일할 수 있습니다. 그들은 더 개방,사회적 모드로 깊은 몰입 논리적 사고에서 자신의 정신 기어를 이동해야하기 때문에 많은 개발자들은 회의를 싫어. 이 시간이 걸립니다. 몇몇 팀 지도자는 모두를 동기화되는 유지하기 위하여 회의를 더 붙들어서 실패를 싸우는 것을 시도한다. 그것은 고귀한 노력 하지만 기어 연 삭 들을 수 있습니다. 팀은 동기화를 유지하기 위해 충분한 정보를 공유 할 필요가 있지만 더 이상 뇌주기를 낭비합니다.
기본 기능 변경
이론적으로 개발자는 자신이 민첩하다고 생각합니다. 그래서 그들은 그 말을 받아들입니다. 그러나 때로는 민첩성이 모든 사람을 균형에서 벗어날 수 있습니다. 그것은 모두 변화가 기본 프레임 워크에 근본적인 변화를 필요로하는지 여부에 달려 있습니다. 그것은 주위에 버튼을 이동하거나 색상을 변경할 때 민첩하기 쉽다. 그러나 데이터베이스 스키마를 재 작업하거나 샤딩 및 복제를 처리 할 때 우아하게 피벗하는 쉬운 방법은 없습니다.
작업에 대한 잘못된 기술 선택
신중하게 계획하고 올바른 기능 목록을 작성하더라도 잘못된 기술을 사용하면 실패 할 수 있습니다. 예를 들어 데이터베이스는 일반적이고 유연하도록 설계되었지만 아키텍처 제한이 있습니다. 그들이 할 수 있도록 설계되지 않은 무언가를 제공하기 위해 그들을 밀어,확장하도록 요청하면 그들은 가상 정지 속도가 느려집니다. 왜냐하면 그들은 단지 당신이 정말로 일관 된 것 들을 유지 하는 산 성 등급 트랜잭션을 필요 하 고 데이터베이스를 제공 하지 않습니다 나중에 발견 멋진 소리. 아차
빈약한 우선 순위 지정
좋은 플래너는 기능 목록을 작성하고 우선 순위를 지정합니다. 그러나 때때로 우선권은 그(것)들을 실행하기의 현실과 일렬로 세우지 않는다. 최악의 경우 가장 중요한 기능을 만들기가 가장 어렵습니다.
개발자는 무엇을 할 수 있습니까? 그들이 가장 중요한 특징에 집중하는 경우에,진전을 보이지 않으며 위로 기능의 아무도를 전달하기 끝낼지도 모른다. 그러나 그들이 쉬운 것들을 두드리기 시작하면,그들은 쓸모없는 것으로 끝날 수 있습니다.
좋은 계획은 체크리스트 이상을 필요로합니다. 건축 비전은 이를 전달하는 데 필요한 비용과 요구 사항을 고려해야 합니다.
시장 창 닫기
때로는 프로그래머의 잘못이 아닙니다. 내 프로젝트 중 하나는 응용 프로그램에 베스트 셀러 참고 도서를 설정하는 것이 었습니다. 이 책은 인터넷 이전 몇 년 동안 핫케익처럼 판매되었습니다. 이 계획은 그 수요를 활용하고 사람들이 정렬하고 데이터를 검색 할 수있는 대화 형 버전을 만드는 것이 었습니다. 프로그래밍 팀은 책의 모든 것을 포함하지만 책 자체보다 빠르고 예쁘고 훨씬 가벼운 소프트웨어를 제공했습니다. 그러나 아무도 더 이상 그것을 원하지 않았습니다. 이 충분한 다른 소스가 있었고,아무도 뉴스 사이트가 사방처럼 거의 같은 일을 한 다른 응용 프로그램을 필요로하지 않았다.
때로는 아이디어가 훌륭해 보이지만 시장은 계속 나아갔습니다.
잘못된 아키텍처 결정
한 프로젝트에서 데이터베이스의 한 행에서 하나의 번호를 변경하는 작업을 받았습니다. 사용자가 등록을 완료 할 때,나는 최신 주문에 사용자의 아이디 번호를 추가했다. 바로,간단한 소리? 그러나 시스템은 마이크로 서비스 아키텍처를 기반으로 구축되었으며 데이터베이스에 해당 열을 업데이트하도록 알려주는 한 줄의 코드를 작성하여이 문제를 해결할 수 없었습니다. 아뇨 아키텍처 계획은 기존 스택에 새로운 마이크로 서비스 호출을 추가하는 것이 었으며 첫 번째 마이크로 서비스 호출이 다른 마이크로 서비스 호출을 트리거하는 데 필요했기 때문에 힘들었습니다.
결국 이 마이크로서비스 네트워크를 만든 건축적 재능은 이 모든 것이 매우 단순하다고 말했고,건축의 5 층을 통해 뱀 모양의 길을 개략적으로 설명했다. 이는 또한 각 계층에 대해 5 세트의 자동화된 테스트를 추가하는 것을 의미했습니다. 지난 몇 년 동안 다른 팀에 의해 개발되었으며,저는 다섯 가지 코딩 스타일을 이해하고 모방해야 했습니다. 모두 하나의 번호를 변경합니다.
건축 결정은 평생 지속될 수 있습니다—특히 자아가 철저히 투자되어 변경할 수없는 경우. 프로젝트 관리자는 주요 건축 계획이 작동하지 않을 때 큰 결정을 내릴 수 있음을 알 준비가되어 있어야합니다.
정치적 갈등
기술적 실패에 대한 정치적 요인을 비난하는 것은 족제비처럼 보일 수 있지만 점점 더 사실입니다. 프로젝트가 더 커지고 여러 조직에 걸쳐 있기 때문에 파벌이 나타나고 그룹이 통제,자원 및 궁극적으로 권력을 위해 기수가되는 것은 놀라운 일이 아닙니다.
정치적 파벌은 실제 기술적 차이와는 다릅니다. 종종 다른 방식으로 동일한 작업을 수행하는 기술 표준 또는 코드 기반이 있습니다. 나는 그것을 좋아한다. 지금은 입력 한 것을,나는 그들이 동일하지 않은 이유를 설명하기 위해 돌진 중 하나의 팬을 느낄 수 있으며,자신이 좋아하는 선택은 바로 하나입니다. 그러나 한 팀의 한 부분이 하나의 선택을 좋아하고 다른 팀이 경쟁 파벌을 가장 중요하게 생각할 때,마찰은 그들을 찢어 버릴 것입니다.
건축가가 여러 개의 소규모 서비스와 아피스로 응용 프로그램을 분할함에 따라 이는 더욱 보편화되었습니다. 다른 그룹은 이들을 통제하게 될 것이고 그들은 항상 함께하지 않을 것입니다. 팀에서는 둘 다 구현하거나 둘 중 하나를 변경해야 합니다. 세 가지 모두 그룹 및 그룹 모두와 함께 작업해야하는 모든 팀의 고통입니다.
생산 준비가 되지 않은 기술에 대한 베팅
프로그래머는 최신 도구와 프레임워크를 좋아합니다. 그들은 새로운 접근 방식이 이전 세대를 습격하는 모든 절벽을 쓸어 버릴 것이라고 믿고 싶어합니다.
그러나 종종 다음 세대는 생산을 위해 준비되지 않았습니다. 새로운 기능은 완벽하게 보일 수 있지만 즉시 명확하지 않은 간격이 종종 있습니다. 때로는 코드가 몇 개의 파일 형식 또는 몇 개의 데이터베이스가있는 인터페이스 만 지원합니다. 다른 사람은 빨리 오고 있다,당신을 확신한다,그러나 당신의 프로젝트는 이 달을 발송할 필요가 있고”빨리”당신이 필요로 하는 특징이 완전하기 전에 6 개 이상 달을 의미할 수 있었다.
곧 구식이 될 기술에 베팅
내 경험에 의하면,오래된 물건은 일반적으로 더 안정적이고 전투 테스트,하지만 오래된 기술이 완벽하다는 것을 의미하지 않는다. 기능은 라이브 간다 일단 소프트웨어 프로젝트에 필수적인 누락 될 수 있습니다. 더 나쁜 것은 오래된 기술에 베팅하면 변경 사항을 기반으로 미래의 기회를 놓칠 수 있다는 것입니다. 새로운 아이디어,프로토콜 및 파일 형식이 나타나고 구현되지 않을 수 있습니다. 그리고 경쟁 팀의 누군가가 당신이 새로운 프로토콜을 지원한다고 주장한다면 오래된 기술은 상처를 입을 것입니다.
비현실적인 마감일
마감일은 까다 롭습니다. 많은 프로젝트는 특정 계절이나 이벤트에 의해 시장에 그것을 확인해야합니다. 그러나 마감 기한이 처음 기록 될 때 개발자는 자신의 길에서 장애물과 장애물을 발견하기 시작하지 않았습니다. 그런 다음 프로젝트가 미끄러지고 소프트웨어가 실행되지 않고 이벤트가 통과하면 코드가 원활하게 실행 되더라도 전체 프로젝트가 실패로 간주됩니다. 마감일은 모두가 집중하고 함께 끌어 도움이,하지만 그들은 또한 비현실적 일 수있다 기대를 만들 수 있습니다.
예상치 못한 경쟁
좋은 제품 관리자는 다이빙 전에 경쟁을 조사하지만 아무도 경쟁이 갑자기 나타날 수 있습니다 예측할 수 없습니다. 새로운 경쟁자가 복제해야 새로운 기능을 소개하는 경우,음,위의 기능 변경 및 우선 순위 불일치에 대한 섹션을 참조하십시오.
프로세스 돌진
많은 소프트웨어 프로젝트는 무언가를 고치려는 사람이나 팀의 비전으로 시작됩니다. 그들은”스냅챗 포 와이”또는”우버 포 와이”와 같은 문구를 생각해 낸 다음 제품 팀이 스냅챗 또는 우버처럼 반응할 것으로 기대합니다. 문제는 프로젝트의 범위를 파악하고,데이터 흐름을 스케치하고,사용자 인터페이스를 상상하는 것이 코드를 작성하는 것보다 10 배나 많은 작업이라는 것입니다. 그러나 상상가들은 아이디어에서 코드로 바로 가고 싶어합니다.
와이어프레임,데이터베이스 스키마 및 사용자 스토리는 단순히 손을 흔드는 것이 아니라 작업의 필수적인 부분입니다. 그러나 대부분의 사람들은 소프트웨어 프로젝트가 아이디어를 구현하기 위해 코드를 작성하는 것이라고 믿고 싶어합니다.
소프트웨어의 힘에 대한 잘못된 믿음
몽상가들은 종종 세상을 변화시키는 소프트웨어의 힘에 대한 비현실적인 믿음을 가지고 있다. 많은 사람들이 소셜 미디어가 우리를 하나로 묶을 것이라고 상상했지만 어떻게 든 항상 명백한 단층 선을 노출 시켰습니다. 소프트웨어 프로젝트는 종종 세계의 일부 구석에 혁명을 약속 슬라이드 데크로 시작합니다. 데이터베이스에 비트를 밀어 때 사람을 변환하지 않습니다,잘,사람들은 화가,지루,혼란 또는 악화. 그들은 모든 사람들이 예상했던 마법의 변화를 제공하지 못하기 때문에 소프트웨어가 고장 났다고 말합니다.
많은 소프트웨어 프로젝트는 컴파일 품질 보증을 통과,선박,심지어 괜찮은 리뷰를 얻을 수 있지만,음,그 변화-더-세계의 약속은 불가능하기 때문에 궁극적으로 슬라이드 갑판에 약속 중 하나를 달성하기 위해 실패 할 수 있습니다.
사악한 하청 업체
우리는 단지 몇 줄의 코드로 마법을 만들 수있는 라이브러리와 도구를 생산하는 공급 업체를 좋아합니다. 때때로,그들은 그들의 힘의 바람을 얻고 프로젝트를 파괴하는 데 사용합니다. 버전 1.0 에 대한 예산 시트는 관리가 버전 2.0 을 승인하는 것을 망설이지 않았다 너무 좋았다. 다음 납품업자는 가격을 세 겹으로 하거나 5 배로 해서 저희를 짜내는 것을 결정한다.
이 효과는 공급 업체가 의도적으로 수행하지 않는 경우에도 느낄 수 있습니다. 무료 계층은 프로젝트를 매우 저렴하게 만들 수 있습니다. 그런 다음 수요가 급증하고 두 번째 버전이 수요를 확대 할 때 실제 가격이 시작됩니다.
바다의 변화
전염병과 시위로 1 년 동안 시대 정신보다 더 빨리 변한 것은 없습니다. 이 프로젝트는 강력한 개인 정보 보호를 중심 기능으로 만들었습니까? 으악. 전염병은 모든 사람들이 접촉 추적에 관심을 갖게했습니다. 누군가 비즈니스 여행에 집중하고 싶습니까? 으악. 호텔 산업이 무너졌다. 1 년 이상 걸릴 수있는 더 큰 소프트웨어 프로젝트는 대격변 적 사건으로 뒤엎을 위험이 있습니다. 처음에는 멋진 아이디어처럼 보였던 것이 절망적으로 길을 잃고 끊어지는 것처럼 보일 수 있습니다.
기술 변화
그것은 단지 세계의 변화가 아닙니다. 기술 커뮤니티의 조석 변화는 동일한 효과를 가질 수 있습니다. 노스클은 한때 관계형 스키마에서 우리를 해방시킬 천재적인 아이디어였습니다. 그런 다음 모든 레코드가 로컬 스키마를 수행하기 때문에 누군가가 파일이 부풀어 오르는 것을 깨달았습니다. 기술적 인 바다 변화가 리더십과 고객의 태도를 바꿀 때 좋은 민첩한 개발 팀이 바뀔 수 있습니다. 그러나 심지어 가장 민첩한 팀은 건축 계획에서 모든 공기를 빨아 큰 변화를 처리 할 수 없습니다. 이 시스템은 엑스 좋은 생각이었고,갑자기 엑스 먼지 가정 구축되었다. 때로는 그것을 날려 다시 스타하는 것이 가장 좋습니다.
너무 많은 추가
일부 소프트웨어 프로젝트는 잘 시작되고 성공적으로 배송됩니다. 그런 다음 누군가가 코드를 따라 절뚝 거리는 계속 방식으로 기존 버전에 새로운 코드를 접목,추가 기능 또는 세 가지를 추가합니다. 영웅 개발자는 초기 건축가가 잘 계획 특히,이 떨어져 여러 번 해낼 수 있습니다. 그러나 어떤 시점에서 재단이 무너집니다. 어쩌면 데이터베이스가 부하를 처리 할 수 없습니다. 어쩌면 다양한 쿼리를 만족시키는 데 필요한 조인이 너무 많을 수 있습니다. 좋은 소프트웨어는 너무 뚱뚱해질 수 있으며 때로는 가장자리 위로 밀어 넣은 약간의 개선 덕분에 얻을 수 있습니다.
목표 게시물 이동
초기 계획은 마케팅 계획을 돕기 위해 고객 지출을 추적하도록 데이터베이스를 요청했습니다. 그런 다음 일부 천재는 일기 예보와 지출의 상관 관계를 인공 지능을 사용하는 기능을 추가했다. 또는 다른 사람이 자동으로 검색 엔진 광고에 대 한 입찰 소프트웨어를 원했다. 대상을 변경하면 프로젝트가 바뀔 수 있습니다.
변화가 스스로 일을 망치는 것은 드문 일이다. 그러나 새로운 목표는 약점을 드러내고 실패 모드를 유발할 수 있습니다. 어쩌면 팀이 너무 작아서 프로젝트를 성공적으로 완료 할 수 없을 수도 있습니다. 어쩌면 기술 기반은 새로운 접근 방식에 대해 매우 비효율적 일 수 있습니다. 목표를 변경하기로 결정했을 때 모든 사람들이 초조한 조합을 예상하는 것은 어렵습니다.