5P by neo 7일전 | favorite | 댓글 1개
  • 복잡한 소프트웨어 현대화 프로젝트에서의 팁: 추정치를 마감일이 아닌 지침으로 취급해야 함.

  • 개인적인 경험:

    • 서울과 속초에서의 즐거운 휴가 후, 시스템 사고와 "Zen and the Art of Motorcycle Maintenance"라는 책에 대해 쓰려 했으나, 최근 2주간의 사건들로 인해 계획이 변경됨.
    • 미국 선거 전 주말에 사고를 당했으며, 회사인 New York Times에서의 기술자 파업 경험이 있었음.
  • 추정치 - 예술인가 과학인가?:

    • 자동차 수리 과정에서 보험 조정자와 수리점 간의 추정치 차이와 협상 과정을 설명함.
    • 예상치 못한 손상이 발견될 경우 추가 비용이 발생할 수 있으며, 보험사의 승인이 필요함.
  • 복잡한 소프트웨어 아키텍처 현대화와의 유사성:

    • 레거시 소프트웨어 현대화 과정에서 초기 추정치와 실제 복잡성 간의 차이를 설명함.
    • 추가적인 복잡성이 발견될 때마다 추가 승인이 필요함.
  • 좋은 리더는 올바른 질문을 함:

    • 복잡한 문제를 해결하기 위해 올바른 질문을 던지는 것이 중요함.
    • 예상치 못한 복잡성을 발견했을 때의 대응 방법에 대해 논의함.
  • 진행할 것인가, 아니면 총 손실로 간주할 것인가?:

    • 현대화 프로젝트에서 추가 비용이 승인되어 작업이 계속되는 경우와 프로젝트가 중단되는 경우를 설명함.
  • 복잡한 맥락인가, 복잡한 맥락인가?:

    • Cynefin 프레임워크를 사용하여 복잡한 상황에서의 의사결정 과정을 설명함.
    • 복잡한 레거시 소프트웨어 프로젝트에서의 학습과 실험의 중요성을 강조함.
  • 부정 - 분노 - 협상 - 우울 - 수용?:

    • 현대화 프로젝트에서의 예상치 못한 상황에 대한 대응 방법을 설명함.
    • 조직 문화가 이러한 상황에 어떻게 대응하는지에 대한 Ron Westrum의 모델을 소개함.
  • 현대화 이니셔티브를 이끄는 리더를 위한 팁:

    • 복잡한 도메인에서는 실험적 관리 방식이 필요하며, 실패를 수용하는 것이 중요함.
    • 리더가 질서를 강요하려고 하면 실패할 것이며, 패턴이 나타나도록 허용하는 것이 성공의 열쇠임.
  • 새로운 희망:

    • 자동차 수리와 보험 처리 과정에서의 경험을 통해 현대화 프로젝트에서의 추정치의 중요성을 강조함.
    • 소프트웨어 회사와 리더십이 성공을 측정하는 올바른 프레임워크를 사용하기를 바람.
Hacker News 의견
  • 관리자가 추정치를 마감일로 취급하는 경우가 있었음. 사양이 자주 변경될 때마다 "헤드라이트를 받은 사슴" 반응을 사용하여 시간을 벌고, 추정치를 최대한 보수적으로 제공하여 일정을 앞당겨 완료하는 전략을 사용했음. 좋은 관리자는 이런 전략이 필요 없었음.

  • 현대화 프로젝트는 소프트 마감일을 가지며, 예산 압박과 사용자 요구가 있지만, 하루 늦어도 큰 문제가 되지 않음. 반면, 우주 탐사선 발사나 Ford와 같은 대기업의 경우, 마감일을 놓치면 큰 손해를 입을 수 있음.

  • 미켈란젤로는 교황 율리우스 2세의 무덤을 5년 내에 완성할 것이라고 추정했지만, 실제로는 40년이 걸렸음. 이는 고객의 요구 변경, 공급망 문제, 계약 재협상 등의 이유로 프로젝트 규모가 축소되었기 때문임.

  • 초기 추정치는 기억에 남으며, 새로운 정보를 제공해도 초기 추정치를 바꾸기 어려운 경우가 많음. 이로 인해 추정치를 제공하는 것을 꺼리는 사람들이 있음.

  • 보험 회사가 원래 추정치만 지불하려고 하는 경우가 종종 발생함. 이는 자동차, 주택, 건강 보험 모두에 해당하며, 항상 합리적인 결과로 이어지지는 않음.

  • 고정 범위에 대한 추정치를 제공하고, 발견된 추가 작업에 대해 새로운 마일스톤을 추가하는 것이 중요함. 그러나 이러한 접근 방식을 이해하는 관리 계층이 필요함.

  • 리더십은 마감일이 동기부여가 된다고 생각하지만, 이는 잘못된 접근 방식임. 마감일을 현실적으로 조정하지 않으면 팀의 사기가 떨어질 수 있음.

  • "No Estimates" 접근 방식을 지지하며, 정확한 추정치는 과거와 동일한 작업이거나, 남은 작업이 명확히 정의된 경우에만 가능함.

  • 재미있는 추정 공식이 있으며, 이는 개인 경험에 기반한 비공식적인 공식임. 예를 들어, 프로젝트에 참여하는 사람 수, 새로운 도구 수 등을 고려하여 실제 소요 시간을 계산함.

  • 가장 좋은 추정 시스템은 완료 날짜를 내기고, 가장 가까운 사람이 점심을 얻는 방식임. 이는 친구들 사이에서 이루어졌으며, 매우 정확한 결과를 가져왔음.

  • 기업은 미래를 정확히 예측하고 싶어하지만, 이는 불가능함. 추정치는 주로 관리 계층에서 강조되며, 정확한 추정치를 제공하는 사람에게 보상이 주어지지 않음. 시간에만 집중하면 다른 중요한 요소들이 부정적인 영향을 받을 수 있음.