그리고 Standish Group의 Chaos Report는 끝없이 인용되지만, 실패한 프로젝트가 어떤 느낌인지 알려주는 보고서는 필요하지 않습니다. 당신은 그것을 느낄 수 있습니다. 공기가 변합니다. 회의가 더 무겁게 느껴집니다. 마감일은 제안처럼 들리기 시작합니다. 그리고 사람들, 특히 좋은 사람들은 조용히 출구를 계획하기 시작합니다.
좋은 소식이요? 가장 많이 실패한 프로젝트 ~할 수 있다 안정된 곳으로 돌아가게 됩니다. 그러나 초기 위험 신호를 심각하게 받아들이고 “다음 스프린트에서 수정하겠습니다”라고 무시하지 않는 경우에만 가능합니다. 누군가가 ‘구조’라는 단어를 큰 소리로 말하기 훨씬 전에 일반적으로 나타나는 신호를 살펴보고 실제적인 상황에 대해 이야기해 보겠습니다. 소프트웨어 프로젝트 구조 정말 같아요.
실패의 분석 : 데이터가 말하는 것(그리고 팀이 실제로 느끼는 것)
저는 단 한 가지 이유로 인해 프로젝트가 중단되는 경우가 거의 없다는 사실을 확인했습니다. 이는 일반적으로 불분명한 목표, 우선순위 순환, 피곤한 개발팀, 리더십 압박, 매주 접근하기 점점 더 어려워지는 코드베이스 등의 지저분한 조합입니다.
업계 데이터에 따르면 많은 비율의 프로젝트가 실패합니다. 이는 기술적으로는 사실이지만 너무 추상적이기도 합니다. 데이터가 표시하지 않는 것은 실패한 프로젝트 내의 일상적인 작업입니다. “어제 작동 중이던” 손상된 테스트, 프로덕션과 전혀 일치하지 않는 스테이징 환경, 혼란스러운 질문으로 가득 찬 Slack 스레드, 이해관계자가 더 이상 “완료”에 대한 공유된 정의가 없다는 것을 깨닫는 순간입니다.
그 중 하나라도 익숙하게 들린다면, 아직 누구도 이를 인정하지 않더라도 귀하는 이미 소프트웨어 프로젝트 구조가 필요한 경로에 있는 것입니다.
위험 신호 클러스터 1 – 사람 및 정치
사람 문제는 일반적으로 기술 문제보다 먼저 나타납니다. 그리고 그렇게 되면 그것이 어디에든 기록되기 오래 전에 긴장감을 느낄 수 있습니다.
낮은 사기의 속삭임
엔지니어가 질문을 중단하거나 회의를 피하기 시작하거나 “이게 바로 지금입니다”라고 말하는 것은 무관심이 아니라 조용히 체념하는 것입니다. 저는 수석 개발자가 “이 버전이 마침내 유지될 것”을 바라면서 동일한 모듈을 세 번 조용히 재작성한 팀을 지도한 적이 있습니다. 하지만 요구 사항이 너무 자주 바뀌어 두 번의 스프린트 이상 지속되지 않았습니다.
팀이 순조롭게 진행하고 있지만 작업에 대한 믿음이 없다면 이미 살얼음판 위에서 스케이트를 타고 있는 것입니다.
이해관계자의 채찍질(일명: 움직이는 표적 문제)
대부분의 프로젝트는 누군가 잘못 결정했기 때문에 실패하지 않습니다. 아무도 제대로 평가하지 않은 40개의 작고 문서화되지 않은 변경으로 인해 실패했습니다. 한 이해관계자는 ‘빠른 개선’을 추가하고, 다른 이해관계자는 ‘사소한 조정’을 원하며 갑자기 제품이 원래 계획과 닮지 않습니다.
개발자가 먼저 느낍니다. 다음과 같은 내용을 듣게 됩니다.
- “잠깐, 이미 승인된 거 아니었어?”
- “아직 그런 건 만들지 않은 것 같은데?”
- “그건 티켓에 없었는데…”
팀이 실제로 무엇을 만들고 있는지에 대한 직설적인 대화를 통해 소프트웨어 프로젝트 구조가 종종 시작되는 곳입니다.
버스 팩터 현실 점검
대부분의 팀에는 “모든 것이 어떻게 작동하는지 알고 있는” 사람이 한 명 이상 있습니다. 그리고 괜찮습니다… 그들이 휴가를 떠나거나, 지치거나, 새로운 직업을 받아들이기 전까지는 말이죠.
몇 년 전 저는 배포 작동 방식을 아는 유일한 엔지니어가 있는 프로젝트에 들어갔습니다. 그의 빌드 스크립트는 말 그대로 그의 데스크탑에 있었습니다. 문서가 없습니다. 백업이 없습니다. 그 혼란을 해결하는 데 3주가 걸렸습니다.
프로젝트의 생존이 한두 사람에게 달려 있다면, 당신은 이미 위험을 알고 있습니다.
위험 신호 클러스터 2 – 범위 및 요구 사항
범위가 불분명한 프로젝트는 강둑이 어디에 있는지 모르고 다리를 건설하는 것과 같습니다.
H3: 거의 존재하지 않는 문서
아무도 읽지 않는 80페이지 분량의 PDF를 의미하는 것이 아닙니다. 기본 사항을 의미합니다.
- 프로젝트를 시작하는 방법
- 서비스가 서로 통신하는 방법
- 주요 흐름이 수행해야 하는 작업
- 지뢰가 있는 곳
시스템을 배우는 유일한 방법이 동일한 엔지니어에게 계속해서 질문하는 것이라면 개발 속도가 느려지는 것이 아닙니다. 어디에도 기록되지 않은 지식에 프로젝트의 전체 미래를 걸고 있는 것입니다.
영원히 피벗
모든 팀은 이전에 시장 변화, 고객 피드백, 리더십 변화 등 방향을 전환했습니다. 그건 정상입니다. 그러나 모든 스프린트가 재설정 버튼처럼 느껴지면 프로젝트는 포기한 아이디어 모음이 됩니다.
그 시점에서는 개발자의 재능이 얼마나 중요한지는 중요하지 않습니다. 그들은 변화하는 기반을 구축하고 있습니다.
누구도 말하고 싶지 않은 기술적 부채
기술 부채는 적이 아닙니다. 무시하는 것입니다.
테스트를 실행하는 데 거의 1시간이 걸리고, 배포에 수동 데이터베이스 편집이 필요하고, 종속성의 절반이 수년 오래된 프로젝트에 참여했습니다. 개발자의 부주의로 빚이 쌓이지 않은 경우도 많았다. 모두가 너무 빨리 움직여 일을 제대로 하지 못했기 때문에 그것이 쌓였습니다. 코드가 의미 없이 병합되었습니다. 코드 검토, 기한을 맞추기 위해 서둘러 수정 작업을 진행했고, 표면 아래에서 천천히 썩어가는 것을 정리할 숨쉬는 공간이 아무도 없었습니다.
일상 업무가 불필요하게 고통스럽다면 이미 실패의 초기 단계에 있는 것입니다. 그렇습니다. 이곳은 소프트웨어 프로젝트 구조팀이 발굴을 시작하는 첫 번째 장소 중 하나입니다.
위험 신호 클러스터 3 – 기술 및 프로세스
훌륭한 팀이라도 기본 프로세스가 손상되면 프로젝트를 저장할 수 없습니다.
CI/CD “It Kind of Works” 설정
파이프라인이 10번 중 7번 실패하는 것을 본 적이 있지만 ‘그게 원래 그런 거야’라고 다들 계속 무시했습니다. 파이프라인이 가드레일 대신 성가신 존재가 되면 팀은 모퉁이를 돌기 시작하고 문제는 빠르게 해결됩니다.
조용히 비난하는 문화
비난이 항상 소리를 지르는 것처럼 보이지는 않습니다. 때로는 다음과 같이 보입니다.
- 버그가 발견되면 침묵
- 다른 팀을 비난하는 사이드 메시지
- 코드 커밋을 주저하는 개발자
사람들이 발언하는 것이 안전하지 않다고 느낄 때 실제 문제는 숨겨져 있습니다. 그리고 숨겨진 문제는 항상 다시 나타나며, 규모가 더 크고 비용도 더 많이 듭니다.
데이터는 없고 의견만 있을 뿐입니다
팀이 속도, 결함 패턴, 출시 안정성에 대한 기본적인 질문에 답할 수 없는 경우 정보를 얻기보다는 감정적으로 결정을 내리게 됩니다. 측정할 수 없는 프로젝트를 구출하는 것은 거의 불가능합니다.
실제로 프로젝트를 정상 궤도로 되돌리는 방법
실제 소프트웨어 프로젝트 구출은 영웅적인 행위에 관한 것이 아닙니다. 출혈을 멈추고 실제로 무슨 일이 일어나고 있는지 파악하기에 충분할 정도로 속도를 늦추는 것입니다.
이론이 아닌 실제로 제가 본 작업은 다음과 같습니다.
기능 추가 중지(일시적으로)
예, 리더십은 이에 저항할 것입니다. 하지만 프로젝트를 안정화하려면 이미 손상된 부분에 집중해야 합니다. 새 바닥을 추가하는 동안 물이 새는 지붕을 고칠 수는 없습니다.
기술 상태 점검 실행(슈가코팅 없음)
이는 대규모 감사가 아닙니다. 실용적인 것입니다.
- 우리가 가장 많은 시간을 낭비하고 있는 곳은 어디입니까?
- 코드베이스의 어떤 부분이 사람들을 겁나게 합니까?
- 배포 속도가 느려지는 이유는 무엇인가요?
- 환경이 안정적인가요?
이러한 질문에 대한 답변은 일반적으로 첫 주 이내에 실제 문제를 드러냅니다.
모두를 같은 방에 있게 하세요
단순히 정렬 문제로 인해 실패한 프로젝트가 얼마나 많은지 놀라실 것입니다.
한 번의 솔직한 대화를 통해 모든 사람이 서로 다른 가정을 가지고 작업해 왔다는 사실이 드러나는 경우가 많습니다.
좋은 소프트웨어 프로젝트 구조에 일반적으로 포함되는 내용
제가 참여한 대부분의 회복 과정은 다음과 같습니다.
성공적인 구조는 몇 가지 주요 영역에 중점을 둡니다. 첫 번째는 범위 재설정으로, 목표는 모든 것을 한 번에 추적하는 것을 중지하는 것입니다. 실제로 일어나는 일은 팀이 기능을 무자비하게 줄이고 현실적인 최소 기능 제품(MVP)에 동의하는 것입니다. 다음은 속도 회복을 목표로 하는 기술적 정리입니다.
실제로 이는 전체 코드베이스를 점검하려고 시도하기보다는 가장 큰 고통을 야기하는 문제인 상위 2~3개의 차단 요소를 수정하는 것을 의미합니다. 그 다음에는 혼란을 줄이기 위한 프로세스 복구가 이어집니다. 이 단계에서는 CI/CD 파이프라인이 복구되고, PR(Pull Request) 검토가 더욱 엄격해지고, 스프린트 의식이 안정화됩니다.
마지막으로 소유권을 되찾기 위한 팀 재참여가 있습니다. 이는 개발자에게 수정이 필요하다고 알고 있는 오랜 문제를 최종적으로 해결하기 위한 전용 시간을 제공함으로써 달성됩니다. 이 중 어느 것도 화려하지는 않지만 작동합니다.
최종 생각…
이러한 위험 신호가 여러 개 보이더라도 프로젝트가 실패한 것은 아닙니다. 이는 단지 뭔가 변화가 필요하다는 신호일 뿐입니다. 그리고 솔직히 말해서 이러한 문제가 마술처럼 해결되는 척하는 것보다 지금 처리하는 것이 더 낫습니다.
소프트웨어 프로젝트 구조는 체면을 구하는 것이 아닙니다. 팀에게 숨을 쉴 수 있는 공간을 제공하고, 프로세스에 대한 신뢰를 재구축하고, 혼돈보다 명확성을 선택하는 것입니다. 어려움을 겪고 있는 대부분의 프로젝트는 다시 살아날 수 있지만 문제를 조기에 인식하고 겸손하고 정직하게 해결 방법에 접근하는 경우에만 가능합니다.
때때로 프로젝트에서 할 수 있는 가장 용감한 일은 단순히 “좋아. 멈춰서 둘러보고 이 문제를 제대로 고치자”라고 말하는 것입니다.