{
  "schemaVersion": 1,
  "status": "discussion-proposal",
  "title": "팀내 정의 기반 2",
  "basis": "docs/sources/직무평가/직무역량/09-09-팀내-정의-기반-2-질문과-답변.md",
  "definition": "좋은 기획자는 왜 무엇을 바꿔야 하는지 근거로 설명하고, 여러 해결 방법 중 적절한 방법을 골라, 주어진 조건 안에서 함께 실행할 수 있는 계획으로 만드는 사람입니다.",
  "principle": "판단의 근거가 부족하면 확인하고, 새로운 근거가 나오면 수정합니다.",
  "scope": "idea.pdf를 바탕으로 정리한 질문에 답변 초안을 붙인 논의용 제안입니다. 신입은 주어진 자료에서 판단 근거와 선택안을 제시하고, 권한을 넘는 결정은 담당자와 협의하는 범위로 설명합니다. 팀 합의와 실제 직무 사례를 통한 검토는 후속 논의에서 진행합니다.",
  "groups": [
    {
      "code": "TD2.1",
      "name": "달성하려는 결과와 성공 기준을 정합니다",
      "description": "요청받은 기능이나 작업 뒤에 있는 목적을 파악하고, 무엇이 달라져야 성공인지 설명합니다.",
      "children": [
        {
          "code": "TD2.1.1",
          "name": "이 일이 끝났을 때 누구에게 어떤 변화가 생겨야 하며, 무엇을 보면 성공했다고 판단할 수 있나요?",
          "answer": "먼저 변화가 필요한 대상과 현재 상태, 도달하려는 상태를 정합니다. 성공 기준은 기능을 만들었는지와 실제로 원하는 변화가 생겼는지를 구분해 작성합니다. 결과를 언제 어떤 자료로 확인할지 정하고, 목표 수치의 근거가 부족하면 현재 수준을 확인한 뒤 목표를 제안합니다.",
          "children": [
            {
              "code": "TD2.1.1.1",
              "name": "요청받은 작업과 실제로 원하는 결과를 어떻게 구분하나요?",
              "answer": "요청받은 작업은 목적을 달성하기 위해 제안된 수단입니다. 그 작업을 원하는 사람이 겪는 상황과 기대하는 변화를 확인하면 작업과 목적을 구분할 수 있습니다. 요청의 배경을 설명한 뒤 같은 결과를 만드는 다른 수단도 가능한지 검토합니다.",
              "children": [
                {
                  "code": "TD2.1.1.1.1",
                  "name": "예를 들어 ‘기능을 추가한다’는 요청에서 어떤 질문을 해야 그 기능이 필요한 이유를 알 수 있나요?",
                  "answer": "“누가 어떤 상황에서 어려움을 겪나요?”, “이 기능이 생기면 무엇이 달라져야 하나요?”, “기능을 추가하지 않고도 그 변화를 만들 수 있나요?”를 묻습니다. 답을 대상·현재 어려움·원하는 변화로 정리하고 요청자에게 이해가 맞는지 확인합니다."
                }
              ]
            },
            {
              "code": "TD2.1.1.2",
              "name": "사용자가 원하는 변화와 회사가 원하는 성과는 어떻게 연결되나요?",
              "answer": "사용자의 행동이나 경험이 달라지는 것이 회사의 성과로 이어지는 과정을 설명합니다. 예를 들어 사용자가 필요한 정보를 찾기 쉬워져 신청을 완료한다는 연결을 가정할 수 있습니다. 이 연결은 가설로 표시하고, 사용자에게 생길 손실과 회사가 감수할 비용도 함께 비교합니다.",
              "children": [
                {
                  "code": "TD2.1.1.2.1",
                  "name": "두 가지가 충돌한다면 무엇을 우선하며, 그 판단은 누가 내려야 하나요?",
                  "answer": "법적 의무와 안전처럼 지켜야 할 조건을 먼저 확인하고, 그 안에서 이번 목적과 손익을 기준으로 선택지를 비교합니다. 기획자는 선택 이유와 영향을 제안하며, 최종 우선순위는 해당 결과에 책임과 결정 권한이 있는 담당자가 정합니다. 신입에게는 그 담당자를 확인하고 판단에 필요한 자료를 준비하는 역할을 제안합니다."
                }
              ]
            },
            {
              "code": "TD2.1.1.3",
              "name": "처음 정한 목적을 다시 검토해야 하는 경우는 언제인가요?",
              "answer": "대상의 요구가 달랐거나 기대한 변화가 사업 성과와 연결되지 않는다는 근거가 나오면 목적을 다시 검토합니다. 자원이나 정책이 바뀌어 목적을 달성할 조건이 사라진 경우도 검토 대상입니다. 결과가 나쁘다는 이유만으로 목적부터 바꾸지 않고, 측정 오류와 실행 방법의 문제를 함께 살펴봅니다.",
              "children": [
                {
                  "code": "TD2.1.1.3.1",
                  "name": "어떤 근거가 나오면 실행 방법뿐 아니라 목적이나 성공 기준도 바꿔야 하나요?",
                  "answer": "목표로 삼은 행동이 늘어도 사용자의 문제가 남거나 중요한 부작용이 커지면 성공 기준을 재검토합니다. 반복된 관찰에서 처음 가정한 필요 자체가 확인되지 않으면 목적도 검토합니다. 어떤 근거가 기존 판단을 바꾸는지 기록하고 목적을 정한 담당자와 변경 범위를 협의합니다."
                }
              ]
            }
          ]
        }
      ]
    },
    {
      "code": "TD2.2",
      "name": "해결할 문제를 근거로 좁힙니다",
      "description": "현재 상황에서 확인한 사실과 원인에 대한 추측을 구분하고, 먼저 해결할 문제를 정합니다.",
      "children": [
        {
          "code": "TD2.2.1",
          "name": "원하는 결과를 가로막는 문제는 무엇이며, 그것부터 해결해야 한다는 근거는 무엇인가요?",
          "answer": "원하는 결과와 현재 관찰된 상태의 차이를 구체적으로 적고, 그 차이를 설명할 원인 후보를 나눕니다. 원인을 확인한 자료와 아직 확인하지 못한 부분을 구분합니다. 영향을 받는 대상과 문제의 크기, 원인을 바꿀 가능성을 비교해 먼저 다룰 문제를 제안합니다.",
          "children": [
            {
              "code": "TD2.2.1.1",
              "name": "현재 관찰한 현상과 그 현상이 생긴 원인을 어떻게 구분하나요?",
              "answer": "현상은 실제로 관찰한 일이고, 원인은 그 일이 왜 생겼는지에 대한 설명입니다. 신청 중 이탈이 발생했다는 기록과 안내가 어려워서 이탈했다는 설명을 따로 적습니다. 같은 현상을 다른 원인으로도 설명할 수 있는지 살펴보고, 이를 구분할 자료를 찾습니다.",
              "children": [
                {
                  "code": "TD2.2.1.1.1",
                  "name": "확인된 사실은 무엇이고, 아직 가설인 설명은 무엇인가요?",
                  "answer": "화면 기록·이용 로그·직접 관찰처럼 출처와 확인 조건을 제시할 수 있는 내용은 사실로 기록합니다. 사용자 진술은 그 사람이 그렇게 말한 사실이며 모든 사용자의 원인을 입증하지는 않습니다. 원인과 예상 효과는 가설로 표시하고 이를 지지하는 자료와 반대되는 자료를 함께 적습니다."
                }
              ]
            },
            {
              "code": "TD2.2.1.2",
              "name": "여러 원인 중 무엇을 먼저 확인해야 하나요?",
              "answer": "틀렸을 때 해결 방향이 크게 달라지는 원인을 먼저 확인합니다. 문제에 미치는 영향과 현재 근거의 부족 정도, 확인에 드는 비용을 함께 봅니다. 쉽게 확인할 수 있다는 이유만으로 영향이 작은 원인에 조사를 집중하지 않습니다.",
              "children": [
                {
                  "code": "TD2.2.1.2.1",
                  "name": "어떤 자료나 관찰이 있어야 다른 설명보다 이 설명을 더 믿을 수 있나요?",
                  "answer": "원인 후보별로 참일 때 관찰될 현상과 그렇지 않을 때 관찰될 현상을 적습니다. 같은 조건에서 후보들을 구분할 수 있는 로그, 이용 장면, 재현 결과를 모읍니다. 두 현상이 함께 나타난다는 사실만으로 인과를 확정하지 않고 다른 설명이 남는지도 확인합니다."
                }
              ]
            },
            {
              "code": "TD2.2.1.3",
              "name": "그 원인을 해결하면 원하는 결과가 얼마나 달라질까요?",
              "answer": "그 원인이 영향을 주는 사용자와 발생 빈도, 결과를 방해하는 정도를 확인합니다. 원인을 바꿨을 때 영향을 받는 범위와 다른 장애가 남을 가능성까지 고려해 기대 변화를 설명합니다. 자료가 부족하면 정확한 개선 수치를 단정하지 않고 추정 범위와 가정을 명시합니다.",
              "children": [
                {
                  "code": "TD2.2.1.3.1",
                  "name": "다른 문제보다 먼저 다룰 만큼 영향이 큰지 어떻게 판단하나요?",
                  "answer": "각 문제를 같은 기준으로 비교합니다. 이번 목적에 미치는 영향, 해결의 시급성, 근거의 확실성, 대응에 드는 자원을 함께 정리합니다. 수치가 없으면 정성 자료로 비교한 이유를 밝히고, 우선순위를 바꿀 추가 정보도 적습니다."
                }
              ]
            }
          ]
        }
      ]
    },
    {
      "code": "TD2.3",
      "name": "대안을 비교해 해결 방법을 선택합니다",
      "description": "여러 방법이 문제에 어떻게 작용하는지 설명하고, 기대 효과와 비용·위험을 비교해 선택합니다.",
      "children": [
        {
          "code": "TD2.3.1",
          "name": "이 방법은 문제를 어떻게 해결하며, 다른 방법보다 적절한 이유는 무엇인가요?",
          "answer": "각 대안이 원인의 어느 부분을 바꿔 원하는 결과로 이어지는지 설명합니다. 현상 유지까지 포함한 대안을 같은 조건에서 비교하고, 기대 효과와 비용·시간·위험을 기준으로 선택 이유를 적습니다. 선택안의 가장 불확실한 가정과 그 가정을 확인할 방법도 함께 제시합니다.",
          "children": [
            {
              "code": "TD2.3.1.1",
              "name": "같은 문제를 푸는 다른 방법에는 무엇이 있나요?",
              "answer": "해결 방법은 새 기능 개발, 기존 기능이나 문구 수정, 운영 절차 변경, 외부 수단 활용, 현상 유지 등에서 찾습니다. 중요한 것은 대안의 개수보다 문제에 작용하는 방식이 실제로 다른지입니다. 각 대안이 바꾸는 원인과 적용할 대상을 한 문장으로 설명합니다.",
              "children": [
                {
                  "code": "TD2.3.1.1.1",
                  "name": "새 기능을 만드는 방법 외에 기존 기능 수정, 운영 방식 변경, 현상 유지도 비교했나요?",
                  "answer": "새 기능이 없어도 목적을 달성할 수 있는지 먼저 확인합니다. 현재 방식을 유지했을 때의 손실도 비교 기준으로 두고, 수정이나 운영 변경으로 같은 효과를 낼 수 있는지 검토합니다. 관련이 없는 대안을 표를 채우기 위해 추가하지 않고, 제외한 방법에는 이유를 남깁니다."
                }
              ]
            },
            {
              "code": "TD2.3.1.2",
              "name": "무엇을 기준으로 비교하며, 선택하면서 무엇을 포기하나요?",
              "answer": "목적에 기여하는 정도를 우선 기준으로 삼되, 지켜야 할 조건과 자원 한계를 함께 적용합니다. 동일한 기간과 대상 범위에서 대안을 비교하고, 선택으로 얻는 이점과 감수할 손실을 적습니다. 자료가 다른 수준으로 확보된 대안은 그 차이를 명시해 근거가 풍부하다는 이유만으로 유리해지지 않게 합니다.",
              "children": [
                {
                  "code": "TD2.3.1.2.1",
                  "name": "효과·속도·비용·위험이 서로 엇갈릴 때 어떤 기준을 우선하나요?",
                  "answer": "먼저 안전·법적 의무·필수 일정처럼 넘을 수 없는 조건을 구분합니다. 가능한 대안 안에서는 이번 목적에 가장 중요한 효과와 허용할 비용·위험을 담당자와 확인합니다. 예를 들어 빠른 학습이 목적이면 작게 시험할 수 있는 방법을, 안정성이 필수이면 위험을 낮춘 방법을 우선 제안할 수 있습니다."
                }
              ]
            },
            {
              "code": "TD2.3.1.3",
              "name": "선택한 방법이 효과를 내려면 무엇이 사실이어야 하나요?",
              "answer": "사용자가 제안한 방법을 실제로 이용하고, 바꾸려는 요소가 원인에 작용하며, 필요한 구현과 운영이 가능해야 합니다. 이런 가정을 명시한 뒤 틀렸을 때 선택 전체가 무너지는 가정을 찾습니다. 확인 결과에 따라 그대로 진행할지, 범위를 바꿀지, 다른 대안으로 바꿀지 판단합니다.",
              "children": [
                {
                  "code": "TD2.3.1.3.1",
                  "name": "그중 가장 불확실한 가정을 어떻게 작게 확인하고, 어떤 결과가 나오면 방법을 바꾸나요?",
                  "answer": "확인할 가정에 맞춰 가장 작은 검토를 설계합니다. 이해 가능성은 화면 초안의 이용 관찰로, 기술 조건은 담당자 검토나 작은 구현으로 확인할 수 있습니다. 사업 효과처럼 작은 검토만으로 알기 어려운 내용은 판단 범위를 제한하고, 무엇이 관찰되면 방법을 바꿀지 확인 전에 정합니다."
                }
              ]
            }
          ]
        }
      ]
    },
    {
      "code": "TD2.4",
      "name": "제약을 확인해 실행할 범위를 정합니다",
      "description": "필요한 시간·인력·비용·기술 조건을 확인하고, 지금 할 일과 미룰 일을 구분합니다.",
      "children": [
        {
          "code": "TD2.4.1",
          "name": "현재 조건에서 목적을 달성하려면 어디까지 해야 하며, 무엇을 줄이거나 미뤄야 하나요?",
          "answer": "목적을 달성하는 데 필요한 핵심 결과를 먼저 정하고, 그 결과에 필수적인 일과 미룰 수 있는 일을 구분합니다. 시간·인력·비용·기술·협조 조건을 확인한 뒤 가능한 범위를 제안합니다. 핵심 결과까지 제거해야 일정에 맞는다면 목적이나 일정의 조정을 협의합니다.",
          "children": [
            {
              "code": "TD2.4.1.1",
              "name": "실행에 필요한 조건 중 확인된 것과 추정한 것은 무엇인가요?",
              "answer": "필요한 조건을 목록으로 만들고 각 조건에 확인 근거, 확인한 사람, 남은 불확실성을 붙입니다. 담당자가 검토한 일정과 기획자의 예상 일정은 구분합니다. 외부 의존 사항에는 언제까지 확인해야 다음 결정을 내릴 수 있는지도 적습니다.",
              "children": [
                {
                  "code": "TD2.4.1.1.1",
                  "name": "기술 구현, 다른 팀의 협조, 데이터 확보 등을 누구에게 어떤 방법으로 확인하나요?",
                  "answer": "기술 구현과 일정은 개발 담당자에게 대상 범위와 조건을 제시해 검토받고, 협조가 필요한 일은 해당 팀의 담당자에게 일정과 역할을 확인합니다. 데이터는 소유 담당자에게 존재 여부·접근 권한·품질·사용 가능 범위를 묻습니다. 신입은 독자적으로 가능 여부를 확정하기보다 확인 내용과 남은 질문을 정리합니다."
                }
              ]
            },
            {
              "code": "TD2.4.1.2",
              "name": "시간이나 인력이 부족하면 무엇부터 줄여야 하나요?",
              "answer": "목적 기여도가 낮고 독립적으로 나중에 추가할 수 있는 부분부터 줄입니다. 핵심 이용 흐름과 안전·법적 의무·필수 품질 조건은 유지합니다. 단순히 항목 수를 줄이기보다 제외했을 때 기대 효과와 실행 부담이 어떻게 달라지는지 설명합니다.",
              "children": [
                {
                  "code": "TD2.4.1.2.1",
                  "name": "어떤 부분을 빼도 목적을 달성할 수 있고, 어떤 부분을 빼면 기획의 의미가 사라지나요?",
                  "answer": "각 항목을 빼도 대상 사용자가 핵심 일을 끝낼 수 있는지 점검합니다. 핵심 일을 완수하는 데 필요한 조건은 남기고, 부가 편의나 추가 대상은 후속 범위로 제안할 수 있습니다. 단, 특정 이용자의 접근을 막거나 운영 부담을 감출 수 있으므로 제외 대상과 영향을 함께 기록합니다."
                }
              ]
            },
            {
              "code": "TD2.4.1.3",
              "name": "어떤 조건에서는 시작을 미루거나 계획을 중단해야 하나요?",
              "answer": "필수 권한·안전 조건·핵심 의존 작업이 확보되지 않았거나 목적 달성이 불가능한 범위만 남으면 시작을 미룹니다. 실행 중 예상 손실이 커지거나 핵심 가정이 깨지면 중단과 재설계를 제안합니다. 기획자는 근거와 대안을 공유하고 최종 결정 권한자와 판단합니다.",
              "children": [
                {
                  "code": "TD2.4.1.3.1",
                  "name": "실행 전에 반드시 갖춰야 할 조건과 실행하면서 해결해도 되는 조건을 어떻게 구분하나요?",
                  "answer": "나중에 해결할 수 없거나 실패 시 되돌리기 어려운 조건은 시작 전에 확인합니다. 제한된 범위에서 시험할 수 있고 책임자와 대응 방법이 정해진 불확실성은 실행 중 확인할 수 있습니다. 각 조건의 영향·되돌릴 수 있는 정도·확인 시점을 기록해 구분합니다."
                }
              ]
            }
          ]
        }
      ]
    },
    {
      "code": "TD2.5",
      "name": "함께 실행할 수 있도록 일을 구체화합니다",
      "description": "해야 할 일과 순서·담당·완료 조건을 정하고, 실행자가 추측해야 하는 부분을 줄입니다.",
      "children": [
        {
          "code": "TD2.5.1",
          "name": "이 계획을 받은 사람이 무엇을 해야 하고, 어디까지 하면 완료인지 같은 뜻으로 이해할 수 있나요?",
          "answer": "해야 할 일의 대상과 범위, 순서와 의존 관계, 담당과 인계 시점, 완료 조건을 적습니다. 실행 담당자가 자신의 작업을 다시 설명하게 하거나 실제 예시를 함께 검토해 같은 뜻으로 이해했는지 확인합니다. 작성한 문서의 양보다 실행에 필요한 결정이 빠짐없이 전달됐는지를 봅니다.",
          "children": [
            {
              "code": "TD2.5.1.1",
              "name": "실행자가 일을 시작하려면 어떤 결정이 끝나 있어야 하나요?",
              "answer": "목적·대상·범위·필수 동작·완료 조건처럼 실행 방향을 좌우하는 결정이 먼저 필요합니다. 작업 간 선후 관계와 다른 담당자에게 받아야 할 입력도 확인합니다. 아직 정하지 않은 내용에는 결정 담당자와 필요한 시점을 적어 실행자가 임의로 메우지 않게 합니다.",
              "children": [
                {
                  "code": "TD2.5.1.1.1",
                  "name": "기획자가 정해야 할 내용과 실행 담당자에게 맡길 내용을 어떻게 나누나요?",
                  "answer": "기획자는 사용자 문제와 요구사항, 우선순위와 수용 조건을 구체화해 협의합니다. 구현 방법이나 전문 영역의 세부 선택은 해당 담당자에게 맡기되 지켜야 할 조건을 전달합니다. 담당 범위는 조직마다 다르므로 시작 전에 역할과 최종 결정 권한을 확인합니다."
                }
              ]
            },
            {
              "code": "TD2.5.1.2",
              "name": "같은 계획을 읽고도 서로 다르게 해석할 부분은 어디인가요?",
              "answer": "성공·완료·빠르게 같은 추상적인 말과 대상·조건이 빠진 문장을 먼저 찾습니다. 정상 흐름뿐 아니라 실패, 취소, 중복 요청처럼 결과가 갈리는 상황을 검토합니다. 담당자들이 같은 예시에 서로 다른 결과를 예상한다면 그 부분의 결정이나 표현을 보완합니다.",
              "children": [
                {
                  "code": "TD2.5.1.2.1",
                  "name": "예시·예외 상황·완료 조건 중 무엇을 보완해야 해석 차이를 줄일 수 있나요?",
                  "answer": "무슨 동작을 뜻하는지 다르면 예시를, 특정 상황의 처리가 다르면 예외 조건을 보완합니다. 어디까지 해야 끝인지 다르면 완료 조건과 확인 방법을 적습니다. 설명을 추가한 뒤 같은 장면을 다시 검토해 해석 차이가 실제로 줄었는지 확인합니다."
                }
              ]
            },
            {
              "code": "TD2.5.1.3",
              "name": "실행 중 예상과 다른 상황이 생기면 무엇을 기준으로 바꾸나요?",
              "answer": "합의한 목적·범위·완료 조건을 기준으로 변경 영향을 판단합니다. 새 상황이 일정·비용·품질·다른 담당자의 작업에 미치는 영향을 정리하고, 바뀐 결정과 이유를 관계자에게 알립니다. 목적 자체가 달라지는 변경은 실행 상세 조정과 구분해 다시 협의합니다.",
              "children": [
                {
                  "code": "TD2.5.1.3.1",
                  "name": "담당자가 스스로 결정해도 되는 범위와 다시 협의해야 하는 범위는 어디까지인가요?",
                  "answer": "합의한 조건과 다른 담당자의 작업을 바꾸지 않는 세부 조정은 위임받은 범위에서 결정할 수 있습니다. 목적·범위·대외 약속·일정·안전 조건이 달라지거나 권한이 불분명하면 다시 협의합니다. 시작할 때 이 경계를 정하고 변경 기록에 결정자와 영향 범위를 남깁니다."
                }
              ]
            }
          ]
        }
      ]
    }
  ],
  "discussion": {
    "question": "잘한 사례와 겉보기에는 그럴듯하지만 부족한 사례는 무엇이 다른가요?",
    "answer": "잘한 사례는 판단의 대상과 근거, 비교한 대안, 실행 조건이 이어져 다른 사람이 선택 이유를 검토할 수 있습니다. 부족한 사례는 보기 좋은 결과물이나 결론은 있지만 중요한 판단이 추측에 머물거나 확인할 방법이 빠져 있습니다. 실제 제출물이나 업무 사례를 같은 질문으로 비교해 차이를 확인하고, 자료와 권한이 주어지지 않아 생긴 한계는 수행자의 부족과 구분합니다."
  },
  "crossCutting": [
    {
      "name": "능동적으로 필요한 정보와 다음 행동을 찾습니다.",
      "description": "판단에 필요한 정보와 다음 행동을 스스로 찾고, 자신의 권한을 넘는 결정은 필요한 사람과 협의합니다.",
      "question": "지시받지 않았지만 확인하거나 제안해야 했던 것은 무엇이며, 왜 그것이 필요했나요?",
      "answer": "목적 달성에 빠진 정보, 검토되지 않은 위험, 다음 작업에 필요한 조건을 찾아 확인하거나 제안합니다. 좋은 능동성은 일을 많이 앞서 하는 것보다 지금 필요한 행동을 근거와 함께 선택하는 데서 드러납니다. 권한을 넘거나 다른 사람의 작업을 바꾸는 행동은 영향과 선택지를 정리해 먼저 협의합니다."
    },
    {
      "name": "창의적으로 기존 방법의 한계를 해결할 대안을 만듭니다.",
      "description": "기존 방법을 그대로 적용하기 어려울 때 지식과 방법을 새롭게 조합해 목적에 맞는 대안을 만듭니다.",
      "question": "기존 방법의 어떤 한계를 해결하려고 무엇을 바꿨으며, 그 변화가 실제로 더 나은 이유는 무엇인가요?",
      "answer": "기존 방법이 목적이나 제약을 충족하지 못하는 지점을 설명하고, 다른 지식·절차·도구를 연결해 대안을 제시합니다. 새로움 자체보다 같은 조건에서 기대 효과나 실행 가능성이 나아지는지를 비교합니다. 실제 개선 여부는 확인한 자료로 설명하고, 아직 시험하지 않은 효과는 가설로 남깁니다."
    }
  ]
}