GN⁺: 소프트웨어 생산성을 떨어뜨리는 간단한 방법 (2023)

(erikbern.com)

62P by neo 16일전 | favorite | 댓글 11개

기술

핵심 시스템을 6-18개월 동안 재작성하도록 요구함. 이전 CTO를 비난함.
각자 다른 언어와 프레임워크를 사용하도록 권장함.
시스템을 임의의 경계로 분할하여 기능에 많은 시스템이 관여하도록 함.
복잡한 개발 환경을 조성함. 최소한 12개의 서비스가 포함된 서비스 메쉬를 실행하도록 함.
프로덕션 환경과 개발자 환경이 최대한 다르게 만듦.
배포를 가능한 한 드물게 함. 배포에 대해 극도로 신중할 것을 권장함.
코드 변경 및 일반 워크플로우에 매우 복잡한 프로세스를 도입함. 이를 "보안" 또는 "준수" 때문이라고 핑계댐.
모든 작업을 작업 추적기에 기록하고 최소 5명의 그룹이 검토, 우선순위 지정 및 승인하도록 함.
원래 작업 범위 외의 모든 것을 금지함. 예를 들어 코드 정리나 기타 개선 작업을 금지함.
핵심 역량이 아닌 거의 모든 것을 내부에서 구축함. "벤더 종속을 피하기 위해"라고 정당화함.
모든 것에 추상화 계층을 추가하도록 고집함. 추상화된 벤더를 사용하고 추가 추상화 계층을 추가함.
비현실적으로 낙관적인 규모의 기술 결정을 권장함. 현재보다 최소 3배 이상의 부하를 계획함.
시스템의 공동 소유를 권장함. 유지보수에 대한 책임감을 느끼지 않도록 함.
거의 모든 것을 "플랫폼"으로 중앙 집중화하도록 고집함. 플랫폼 팀을 인력 부족 상태로 유지하고 다른 팀이 플랫폼이 소유할 수 있는 것을 구축하지 못하도록 함.
플랫폼 팀이 API를 자주 반복하도록 하고 다른 팀이 최신 버전으로 코드를 리팩토링하도록 강제함.
"아키텍트"를 고용하고 작은 변경 사항에도 "아키텍처 검토"를 요구함.
작은 변경 사항에도 "보안 검토"를 요구함.

제품

유용한 지표를 학문적 이유로 무시함. 예를 들어 "편향" 또는 "지연 지표"라고 함.
비즈니스 가치와 상관없는 허영 지표를 선택함. 노이즈가 많은 지표를 선택함.
모든 것을 "큰 도박"으로 간주하고 모든 것이 완전히 완료되기 전까지 배포하지 않도록 고집함.
모든 기능을 "필수"로 간주하고 "버전 제로"의 중요한 부분으로 간주함. 절대 양보하지 않음.
매우 상세한 "전략적" 계획을 개발함.
자주 방향을 바꿈.
명백한 개선 사항을 "국지적 최적화"로 무시함.
최신 트렌드를 사용하여 자원을 묶어둠. 표면적으로 그럴듯한 "AI 전략"을 시작함. 이를 위해 벤더와 컨설턴트에게 많은 비용을 지출함.
제품 관리자가 대부분의 시간을 "전략"과 "계획"에 소비하도록 권장함.
엔지니어와 제품 관리자가 내부적으로 제품을 사용하기 어렵거나 불가능하게 만듦.
내부적으로 사용자를 "멍청이"로 무시함.

리더십

보상을 직함과 팀 크기에 연결하여 팽창을 유도함.
전략, 기능 또는 기술적 복잡성에 대해 큰 소리를 냄.
새로운 제품 영역에 진입하기 위해 비싼 인수를 함. "시너지"를 언급함. 인수한 제품을 폐기함.
보고 구조에 많은 점선 사용함.
가능한 한 많은 사람들이 다른 팀, 위치 또는 기능의 관리자에게 보고하도록 함. 관리자가 보고서를 감독할 수 없도록 함.
성과가 저조한 사람을 자주 다른 팀으로 재배치함.
성과가 높은 사람을 불확실한 결과물이 있는 매우 추측적인 R&D 프로젝트에 배치함.
사소한 결정에도 항상 회의를 요구함.
모든 "이해관계자"가 회의에 참석해야 한다고 고집함.

채용

겉보기에는 객관적이지만 실제로는 주관적인 채용 과정을 만듦.
"문화 적합성 부족" 또는 기타 모호한 기준으로 최고의 인재를 거부함.
"잠재력" 또는 "태도" 또는 기타 모호한 기준으로 가장 약한 후보자를 고용함.
대규모 인력 약속을 가진 매우 비싼 고위 리더를 채용함.
기회주의자를 유치하기 위해 부풀려진 직함과 만들어진 역할을 사용함.
매우 전문화된 "전문가"를 고용한 후 그들이 그만두지 않도록 인위적인 프로젝트를 만듦.
전문화를 다른 보완적인 사람을 고용하는 정당화로 사용함.

프로젝트 관리

모든 프로젝트에 대해 매우 상세한 견적을 요구함.
가능한 한 많은 팀, 이상적으로는 다른 위치에 있는 팀에 걸친 프로젝트를 권장함.
다른 팀이 수행한 작업에 의존하는 새로운 요구 사항을 추가함.
비싼 에이전시를 자주 사용함. 범위를 모호하게 만들고 미완성 프로토타입을 내부 팀에 넘겨 마무리하도록 함.
다른 팀의 이해관계자를 위한 복잡한 "셀프 서비스" 시스템을 구축함.

결과

생산성을 떨어뜨리는 것은 어려운 일임. 하지만 적진 후방에 낙하산을 타고 CTO로 취업하면 이를 실현할 수 있음.
비파괴적인 사람들에게: 이는 팀의 생산성을 최대한 끌어내는 방법에 대한 이야기임. 생산성은 작은 것들이 모여서 이루어짐.
100가지 작은 것들이 각각 5%의 생산성 세금을 부과하면 모든 것이 131배 느려짐. 엔지니어를 행복하게 유지하려면 그럴듯하고 그럴듯한 100가지 작은 것들을 거부해야 함.

GN⁺의 의견

이 기사는 소프트웨어 개발에서 생산성을 저해하는 다양한 방법을 유머러스하게 설명하고 있음. 이를 통해 실제로 피해야 할 행동들을 명확히 알 수 있음.
기술적 부채를 줄이고 효율적인 개발 문화를 유지하는 것이 중요함. 불필요한 복잡성과 관료주의를 피하는 것이 핵심임.
팀의 사기를 높이고 협업을 촉진하는 환경을 조성하는 것이 중요함. 이는 생산성 향상에 직접적인 영향을 미침.
이 기사는 소프트웨어 엔지니어링과 관리의 복잡성을 이해하는 데 도움이 됨. 특히 초급 엔지니어들에게 유용한 통찰을 제공함.
다른 유사한 기능을 가진 프로젝트로는 "The Phoenix Project"와 같은 책이 있음. 이는 IT와 DevOps의 효율성을 높이는 방법을 다룸.

▲

rockmkd 6일전 [-]

저렇게 안하는 회사가 있나요? ㅜ.ㅜ
작고 성공을 거둔 회사라도 커지면 다 저렇게 되는 것 같은데...

답변달기

▲

wedding 15일전 [-]

전설의 책 "유지보수하기 어렵게 코딩하는 방법"이 떠오르네요.

답변달기

▲

laeyoung 15일전 [-]

저도 이 책이!

답변달기

▲

neo 16일전 [-]

Hacker News 의견

CIA의 제안이 실제로 효과가 있었는지에 대한 확신이 부족함: 원래 CIA의 제안이 실제로 효과가 있었는지에 대한 설득력 있는 이유를 본 적이 없으며, 조직은 자연스럽게 그런 사람들을 무시하는 경향이 있음.
회사를 망치는 방법: 나쁜 사람들을 관리직에 승진시키고, 수익성 없는 것을 최적화하도록 하는 것이 회사에 큰 타격을 줄 수 있음.
파괴적인 CTO가 되는 방법: 거의 아무것도 하지 않고, 유능한 사람들을 제거하며, 책임을 아래로 미루는 문화를 조성하는 것이 쉬움.
공식 채널을 통한 작업과 서면 명령 요구: 일부 사람들에게는 공식 채널을 통한 작업과 서면 명령 요구가 더 생산적일 수 있음.
OSS와 CIA의 차이: OSS(전략 서비스국)가 2차 세계대전 중에 훌륭한 책을 만들었고, CIA는 1947년에 설립됨.
비전의 중요성: 제품의 전체적인 작동 방식이나 더 나은 미래에 대한 일관된 비전을 가진 사람들을 제거하는 것이 가장 중요한 단계임.
채용 섹션 업데이트 필요: Leetcode의 어려운 문제를 30분 내에 해결하도록 요구하고, 불확실성과 의심을 용납하지 않는 것이 필요함.
생산 환경과 개발자 환경의 차이: 현대 아키텍처에서는 외부 서비스가 많아 생산 환경과 개발자 환경이 다를 수밖에 없으며, 이는 개발자들이 항상 인터넷에 연결되어 있어야 함을 의미함.
자기 보호를 위한 결정: "사보타주"를 위한 많은 결정이 사람들에게 자신의 실수를 덮으려는 시도를 설득하는 것과 관련이 있음.
회사에서의 "최고 관행": 기사 초반에 제시된 여덟 가지 규칙이 회사에서 "최고 관행"으로 엄격히 따르고 있음.
컨설턴트들의 행동: 많은 컨설턴트들이 이러한 행동을 대부분, 아니면 전부 하고 있음.
기술 업계의 문제: 기술 업계에는 이러한 행동을 하는 사람들이 많으며, 그들은 자신들이 도움을 주고 있다고 믿음.
대기업에서의 경험: 대기업에서의 제한된 경험이 이 글의 내용과 매우 일치함.