최고의 프로덕트는 무엇이 다른가 본문

book

최고의 프로덕트는 무엇이 다른가

halatha 2024. 7. 28. 01:34

  • ★★★★☆ July 27, 2024
  • pp23~24
    • 소프트웨어 프로젝트 문제점은 그 일을 하는 사람들의 의사결정 구조의 문제점을 닮아간다. 프로세스만 문제가 아니다.
    • 사회와 조직의 창의성과 생산성은 구조-시스템-절차-사람 (structure-system-process-people, SPSS)에 따라 달라진다
  • pp27~28
    • 소프트웨어 개발은 반복/반복/반복
    • 소프트웨어 개발 일정을 잡을 때는, 반복적으로 나눠서 출시한다… 안 끝날 수도 있다
    • [(1) Giora Morein on X: "You will only know all the requirements of a story when it is completed (not before you start it) #agile #scrum](what_is_different_in_the_best_product/ X
  • p30
    • 매 반복마다 피드백을 받아야 한다
  • p41
  • pp47~48
    • 어느 의사 결정을 먼저 하면 다른 의사결정들을 내리기가 훨씬 수월해질까?
    • 인지적 작업을 하는 경우 모두가 해당
    • 첫째, “누가 이 소프트웨어를 사용하는가?”… ‘액터(actor)가 누구인가?’… “고객이 누구인가?”
      • persona로 생각하면 될 듯? 작년 AWS re:invent에서 봤던 AWS의 4가지 persona가 생각난다
    • 둘째, “이 액터들이 해결하고 싶은 문제 3가지만 고르라고 하면 무엇인가?”… ‘문제해결’
    • 액터가 정해지면, 액터별로 모든 사용자 스토리들을 뽑을 수… 액터들이 해결하고자 하는 핵심 문제들에 따라서 사용자스토리들의 우선순위
  • pp52~53
    • 짧은 시간이라도 반복적으로 ‘찔러보기-느껴보기-반응하기’를 할 수 있던 그룹이 모든 것에서 더 나은 성과를 보여주고, 예상 대비 더 나은 성과
  • pp65~66
    • 원칙만 정한다는 것은, 그 실천 방안으로 이 원칙이 이야기하는 것만 지킨다면 무엇을 해도 된다는 것
    • principles behind the agile manifesto https://agilemanifesto.org/principles.html
      • 최우선 순위는, 가치 있는 소프트웨어를 일찍 그리고 지속적으로 전달해서 고객을 만족시키는 것
      • 요구사항 변경을 환영
      • 작동하는 소프트웨어를 자주 전달
      • 비즈니스 쪽의 사람들과 개발자들은 프로젝트 전체에 걸쳐 날마다 함께 일해야
      • 작동하는 소프트웨어가 진척의 주된 척도
      • 단순성이 — 안 하는 일의 양을 최대화하는 기술이 — 필수적
      • 팀은 정기적으로 어떻게 더 효과적이 될지 숙고하고, 이에 따라 팀의 행동을 조율하고 조정
  • pp85~89
    • ‘무엇이 나와야 하는지’를 합의
    • 하일마이어 질문(Heilmeier catechism)
      • 대부분 PRD에 들어가야 할 중요한 항목들
  • pp107~109
    • ‘애자일 실천법 중에서 도입해서 성과에 도움을 준 것들을 모두 고르세요’… 애자일 실천법 숫자가 많을수록 프로젝트의 성공도가 높았고, 성숙도와도 상관성이 강
    • ‘고객 참여’가 제일 중요
    • ‘고객을 조금이라도 일찍 불러다가 개발의 과정에 참여시키는 조직이 성공할 확률이 높다’… 조직의 성숙도를 떠나서 통계적으로 가장 유의미한 실천법으로 ‘고객 참여’… 꼭 해야만 하는 일
    • “많은 조직들이 고객 참여와 코드 공유를 뒤로 미룹니다”
  • pp146~149
    • 기획자도 개발자도 디자이너도 자신이 뭘 원하는지 명확하게 정의 내리지 못하는 경우가 허다… 언어라는 도구는 생각보다 부족한 도구이기 때문… 하지만 언어를 통하지 않고 자신이 뭘 원하는지를 이야기할 수 없습니다… 기획자가 아예 무엇을 원하는지를 말로 적을 수도 없으면 개발 담당자나 디자인 담당자는 더더욱 무엇을 만들어야 할지 모르게…
      • 언어를 통하는 게 주요하긴 하지만 그래서 나는 언어/글과 함께 이미지, diagram 사용을 매우 강력하게 권장한다. 하지만 보통 잘 되진 않는다
    • 이러한 문서를 통해서 서로 ‘목표 합의’…
    • ‘모든 것이 글쓰기’라는 실용주의 프로그래머의 말은, 진정 진리
  • pp153~154
    • 개발자가 모자란 게 아니라 개발자들을 잘 배치하지 못한 경영의 문제… 기획자들이 한창 개발팀에서 현재 해야 하는 일을 열심히 하고 있는데, 계속해서 ‘나 새로운 아이디어가 있어’라면서 자꾸 불러내서 새로운 아이디어라고 열심히 설명하고 ‘언제쯤 돼요?’라고 보챕니다.
  • pp157~158
    • “절대 없어서는 안 될 프로그래머가 있다면 한시라도 빨리 그를 프로젝트에서 제거하라”
    • 문서화
    • 핵심 개발자를 ‘제거’해서 전체 프로젝트의 안정성을 키워야… 성공한 기업은 결국 SSPP(structure-system-process-people)를 제대로 만들어서, 집단의 힘으로 개인의 힘을 넘어서서 이룬 것
  • pp161~168
      1. 사용자의 수요에서 시작하라(Start with user needs)
      • 서비스 디자인은 사용자의 니즈를 파악하는 것에서 시작… 사용자의 요구가 무엇인지 모른다면 제대로 된 것을 만들 수 없습니다. 조사하고, 데이터를 분석하고, 사용자와 대화하세요. 추측하지 마세요. 사용자에 대해 공감하고, 사용자가 요구하는 것이 항상 필요한 것은 아니라는 점을 기억…
      1. 데이터를 가지고 디자인해라(Design with data)
    • https://userresearch.blog.gov.uk/2019/03/12/how-to-use-data-in-user-research-when-you-have-no-web-analytics/
      • To gain insights into user behavior without web analytics, follow these steps: start with a research question, choose relevant data sources (like user accounts, search logs, support tickets, or social media), find a developer to help access the data, and analyze it using spreadsheets. This collaborative approach can provide a richer understanding of user needs and help the entire team become more user-focused.
    • “항상 그래왔어요” 라는 대답을 당연하게 받아들이지 마세요.
      • 마치 내가 PO들에게 “있으면 좋을 거 같아요”라는 기능은 거의 대부분 안 하는 게 정답이라고 말하는 거와 연결된다는 생각이 든다
    • 반복은 위험을 줄여줍니다. 큰 실패의 가능성을 낮추고 작은 실패를 교훈으로 삼을 수 있습니다. 프로토타입이 작동하지 않는다면 과감히 폐기하고 다시 시작…
      • double diamond model에서 divergence와 convergence를 반복하는 경우도 결국 이와 연결된다고 생각함
  • pp194~196
    • 조직의 구조와 시스템의 설계란 이러한 성과책임(accountability)의 구조… 합리적으로 달성해서 기대한 성과를 내는 것이 유능한 것
    • 행동을 조정하는 관리(혹은 행동주의적 직무 인식)의 문제점
    • 성과를 높이기 위해서는 행동이 아니라 목표를 조정
    • 목표를 조정하는 관리(혹은 성과주의적 직무 인식)의 장점
      • 합의된 목표를 설정
      • 책임을 명확히
  • pp199~200
    • 이 조직이 어떻게 돌아가는지 분석하는 가장 좋은 방법은 조직의 SSPP(structure-system-process-people)를 분석
      1. 구조(Structure): 조직의 각 기능과 역할이 명확히 정의… 체계적인 운영을 가능케
      2. 체계(System): 조직 내의 구조가 유기적으로 연결되어 네트워크를 형성… 각 부서 및 구성원들이 협력하여 목표를 달성…
      3. 과정/순서(Process): 정의된 구조와 체계를 기반으로 일의 흐름과 순서가 잘 구성… 업무의 효율성과 일관성 유지…
      4. 사람(People): 조직을 이루는 구성원들의 역량과 특성을 고려… 올바른 사람을 올바른 위치에 배치하고 적절한 책임을 부여…
    • 직무의 책임은 계층과 계열이 있어야
    • 지시와 명령보다는 구성원들에게 ‘책임’을 부여하고 협력을 장려
    • 이니셔티브는 특정 문제를 처리하거나 특정 목적을 달성하기 위한 다양한 방법들
    • 권한 위임(delegation)과 권한 양도(empowerment)… 권한 위임은 큰 책임을 상위 레이어의 결재를 받아 나누어 수행… 권한 양도는 상대적으로 덜 중요한 업무를 받은 사람이 스스로 판단하여 수행
    • 이니셔티브를 책임계약을 기반으로 조직화해서 짜 놓은 것을 ‘책임으로 지은 집’이란 이름으로…
  • pp205~207
    • “물건을 만드는 일에 직접 참여하면 사람의 자부심이 높아진다. 그리고 그 자부심은 자신이 만든 물건의 가치를 높게 평가하도록 만든다”
    • ‘참여적 의사결정의 4가지 핵심 가치’
      • 온전한 참여(full participation)
      • 상호 이해(mutual understanding)
      • 포괄적 해법(inclusive solution)
      • 공유 책임(shared responsibility)
    • 집단 의사결정의 현실적인 모델
    • ‘수렴적 사고’의 지대로 넘어올 수 있게 하고, 결정 지점으로 갈 수 있게 도와주는 게 리더… 갈등이 생길 수도 있고, 의견 대립이 있을 수도 있습니다. 이 순간을 ‘받아들여야 합니다’.
    • 누구 한 사람만의 의견으로 가는 게 아니라 ‘가장 좋은’ 결정을 하기 위해서 모든 좋은 생각들을 쏟아 넣어야 합니다.
  • pp210~214
    • 위임형 조직
      1. 명령에 복종하려고 할 때, 그것이 자신의 명예를 훼손한다고 판단되면 불복종할 수 있어야 한다.
      2. 복종은 원칙이지만 인간은 원칙 위에 있다.
    • 몰트케의 전략사상 핵심
      1. 계획은 적군을 만나면 살아남지 못한다: 생각하고 있는 시나리오 안에 있는 일이 일어나면 좋지만 없는 일이 일어날 확률이 높기 때문…
      2. 기술적인 모든 가능성을 부하들과 끊임없이 토론한다: 토론하는 와중에 지휘관이 몰랐던 혹은 일반 병사들이 몰랐던 많은 정보들이 오갑니다. 자연스럽게 많은 정보들을 두고 제일 좋은 안을 선택…
      3. 전쟁의 목적을 공유한다
      4. 전투 시 지휘관에게 포괄적인 자율성을 보장한다
    • 몰트케… “철저히 준비하고 과감히 실행한다(Erst wägen, dann wagen)”
    • 인간의 존엄이 지켜져야 합니다. 그래야 자율성이 살아납니다. 그 자율성 덕에 현장에서 알게 된 정보와 준비된 지식에서 나온 해결책으로 대단한 성과를 보여줄 수 있습니다. 인간의 존엄이 존중되어야 조직의 피드백 루프가 돌아가기 시작하기 때문입니다. 그리고 분권화, 자율화, 조직화된 조직이 만들어질 수 있기 때문입니다.
  • pp233~234
    • 일정을 ‘분할하여’ 달성
    • 프로젝트의 일정이 실제로 치명적으로 중요하다면, 필요한 경우 요구사항 일부분을 과감하게 버리는 결단
    • ‘이왕이면 다홍치마’를 피해야… 고객이 자신의 문제를 해결할 수 있느냐 없느냐가 문제
    • 제품 또는 서비스를 출시하기 전에 반드시 모든 이해 당사자가 직접 사용하고 경험
공유하기 링크
'book' Related Articles more
Comments