GN⁺: 소프트웨어 생산성을 떨어뜨리는 간단한 방법 (2023)
(erikbern.com)기술
- 핵심 시스템을 6-18개월 동안 재작성하도록 요구함. 이전 CTO를 비난함.
- 각자 다른 언어와 프레임워크를 사용하도록 권장함.
- 시스템을 임의의 경계로 분할하여 기능에 많은 시스템이 관여하도록 함.
- 복잡한 개발 환경을 조성함. 최소한 12개의 서비스가 포함된 서비스 메쉬를 실행하도록 함.
- 프로덕션 환경과 개발자 환경이 최대한 다르게 만듦.
- 배포를 가능한 한 드물게 함. 배포에 대해 극도로 신중할 것을 권장함.
- 코드 변경 및 일반 워크플로우에 매우 복잡한 프로세스를 도입함. 이를 "보안" 또는 "준수" 때문이라고 핑계댐.
- 모든 작업을 작업 추적기에 기록하고 최소 5명의 그룹이 검토, 우선순위 지정 및 승인하도록 함.
- 원래 작업 범위 외의 모든 것을 금지함. 예를 들어 코드 정리나 기타 개선 작업을 금지함.
- 핵심 역량이 아닌 거의 모든 것을 내부에서 구축함. "벤더 종속을 피하기 위해"라고 정당화함.
- 모든 것에 추상화 계층을 추가하도록 고집함. 추상화된 벤더를 사용하고 추가 추상화 계층을 추가함.
- 비현실적으로 낙관적인 규모의 기술 결정을 권장함. 현재보다 최소 3배 이상의 부하를 계획함.
- 시스템의 공동 소유를 권장함. 유지보수에 대한 책임감을 느끼지 않도록 함.
- 거의 모든 것을 "플랫폼"으로 중앙 집중화하도록 고집함. 플랫폼 팀을 인력 부족 상태로 유지하고 다른 팀이 플랫폼이 소유할 수 있는 것을 구축하지 못하도록 함.
- 플랫폼 팀이 API를 자주 반복하도록 하고 다른 팀이 최신 버전으로 코드를 리팩토링하도록 강제함.
- "아키텍트"를 고용하고 작은 변경 사항에도 "아키텍처 검토"를 요구함.
- 작은 변경 사항에도 "보안 검토"를 요구함.
제품
- 유용한 지표를 학문적 이유로 무시함. 예를 들어 "편향" 또는 "지연 지표"라고 함.
- 비즈니스 가치와 상관없는 허영 지표를 선택함. 노이즈가 많은 지표를 선택함.
- 모든 것을 "큰 도박"으로 간주하고 모든 것이 완전히 완료되기 전까지 배포하지 않도록 고집함.
- 모든 기능을 "필수"로 간주하고 "버전 제로"의 중요한 부분으로 간주함. 절대 양보하지 않음.
- 매우 상세한 "전략적" 계획을 개발함.
- 자주 방향을 바꿈.
- 명백한 개선 사항을 "국지적 최적화"로 무시함.
- 최신 트렌드를 사용하여 자원을 묶어둠. 표면적으로 그럴듯한 "AI 전략"을 시작함. 이를 위해 벤더와 컨설턴트에게 많은 비용을 지출함.
- 제품 관리자가 대부분의 시간을 "전략"과 "계획"에 소비하도록 권장함.
- 엔지니어와 제품 관리자가 내부적으로 제품을 사용하기 어렵거나 불가능하게 만듦.
- 내부적으로 사용자를 "멍청이"로 무시함.
리더십
- 보상을 직함과 팀 크기에 연결하여 팽창을 유도함.
- 전략, 기능 또는 기술적 복잡성에 대해 큰 소리를 냄.
- 새로운 제품 영역에 진입하기 위해 비싼 인수를 함. "시너지"를 언급함. 인수한 제품을 폐기함.
- 보고 구조에 많은 점선 사용함.
- 가능한 한 많은 사람들이 다른 팀, 위치 또는 기능의 관리자에게 보고하도록 함. 관리자가 보고서를 감독할 수 없도록 함.
- 성과가 저조한 사람을 자주 다른 팀으로 재배치함.
- 성과가 높은 사람을 불확실한 결과물이 있는 매우 추측적인 R&D 프로젝트에 배치함.
- 사소한 결정에도 항상 회의를 요구함.
- 모든 "이해관계자"가 회의에 참석해야 한다고 고집함.
채용
- 겉보기에는 객관적이지만 실제로는 주관적인 채용 과정을 만듦.
- "문화 적합성 부족" 또는 기타 모호한 기준으로 최고의 인재를 거부함.
- "잠재력" 또는 "태도" 또는 기타 모호한 기준으로 가장 약한 후보자를 고용함.
- 대규모 인력 약속을 가진 매우 비싼 고위 리더를 채용함.
- 기회주의자를 유치하기 위해 부풀려진 직함과 만들어진 역할을 사용함.
- 매우 전문화된 "전문가"를 고용한 후 그들이 그만두지 않도록 인위적인 프로젝트를 만듦.
- 전문화를 다른 보완적인 사람을 고용하는 정당화로 사용함.
프로젝트 관리
- 모든 프로젝트에 대해 매우 상세한 견적을 요구함.
- 가능한 한 많은 팀, 이상적으로는 다른 위치에 있는 팀에 걸친 프로젝트를 권장함.
- 다른 팀이 수행한 작업에 의존하는 새로운 요구 사항을 추가함.
- 비싼 에이전시를 자주 사용함. 범위를 모호하게 만들고 미완성 프로토타입을 내부 팀에 넘겨 마무리하도록 함.
- 다른 팀의 이해관계자를 위한 복잡한 "셀프 서비스" 시스템을 구축함.
결과
- 생산성을 떨어뜨리는 것은 어려운 일임. 하지만 적진 후방에 낙하산을 타고 CTO로 취업하면 이를 실현할 수 있음.
- 비파괴적인 사람들에게: 이는 팀의 생산성을 최대한 끌어내는 방법에 대한 이야기임. 생산성은 작은 것들이 모여서 이루어짐.
- 100가지 작은 것들이 각각 5%의 생산성 세금을 부과하면 모든 것이 131배 느려짐. 엔지니어를 행복하게 유지하려면 그럴듯하고 그럴듯한 100가지 작은 것들을 거부해야 함.
GN⁺의 의견
- 이 기사는 소프트웨어 개발에서 생산성을 저해하는 다양한 방법을 유머러스하게 설명하고 있음. 이를 통해 실제로 피해야 할 행동들을 명확히 알 수 있음.
- 기술적 부채를 줄이고 효율적인 개발 문화를 유지하는 것이 중요함. 불필요한 복잡성과 관료주의를 피하는 것이 핵심임.
- 팀의 사기를 높이고 협업을 촉진하는 환경을 조성하는 것이 중요함. 이는 생산성 향상에 직접적인 영향을 미침.
- 이 기사는 소프트웨어 엔지니어링과 관리의 복잡성을 이해하는 데 도움이 됨. 특히 초급 엔지니어들에게 유용한 통찰을 제공함.
- 다른 유사한 기능을 가진 프로젝트로는 "The Phoenix Project"와 같은 책이 있음. 이는 IT와 DevOps의 효율성을 높이는 방법을 다룸.
Hacker News 의견
-
CIA의 제안이 실제로 효과가 있었는지에 대한 확신이 부족함: 원래 CIA의 제안이 실제로 효과가 있었는지에 대한 설득력 있는 이유를 본 적이 없으며, 조직은 자연스럽게 그런 사람들을 무시하는 경향이 있음.
-
회사를 망치는 방법: 나쁜 사람들을 관리직에 승진시키고, 수익성 없는 것을 최적화하도록 하는 것이 회사에 큰 타격을 줄 수 있음.
-
파괴적인 CTO가 되는 방법: 거의 아무것도 하지 않고, 유능한 사람들을 제거하며, 책임을 아래로 미루는 문화를 조성하는 것이 쉬움.
-
공식 채널을 통한 작업과 서면 명령 요구: 일부 사람들에게는 공식 채널을 통한 작업과 서면 명령 요구가 더 생산적일 수 있음.
-
OSS와 CIA의 차이: OSS(전략 서비스국)가 2차 세계대전 중에 훌륭한 책을 만들었고, CIA는 1947년에 설립됨.
-
비전의 중요성: 제품의 전체적인 작동 방식이나 더 나은 미래에 대한 일관된 비전을 가진 사람들을 제거하는 것이 가장 중요한 단계임.
-
채용 섹션 업데이트 필요: Leetcode의 어려운 문제를 30분 내에 해결하도록 요구하고, 불확실성과 의심을 용납하지 않는 것이 필요함.
-
생산 환경과 개발자 환경의 차이: 현대 아키텍처에서는 외부 서비스가 많아 생산 환경과 개발자 환경이 다를 수밖에 없으며, 이는 개발자들이 항상 인터넷에 연결되어 있어야 함을 의미함.
-
자기 보호를 위한 결정: "사보타주"를 위한 많은 결정이 사람들에게 자신의 실수를 덮으려는 시도를 설득하는 것과 관련이 있음.
-
회사에서의 "최고 관행": 기사 초반에 제시된 여덟 가지 규칙이 회사에서 "최고 관행"으로 엄격히 따르고 있음.
-
컨설턴트들의 행동: 많은 컨설턴트들이 이러한 행동을 대부분, 아니면 전부 하고 있음.
-
기술 업계의 문제: 기술 업계에는 이러한 행동을 하는 사람들이 많으며, 그들은 자신들이 도움을 주고 있다고 믿음.
-
대기업에서의 경험: 대기업에서의 제한된 경험이 이 글의 내용과 매우 일치함.