작업 분해

 (jacobian.org)
5P by GN⁺ | ★ favorite | 댓글 1개
  • 프로젝트 추정이나 위임은 “이걸 만들기” 같은 큰 요청을 명확한 작업 목록으로 바꾸는 데서 시작하며, 각 항목은 원하는 변화와 완료 상태를 드러내야 함
  • 분해 과정은 아이디어·스케치·초기 목록에서 필요한 단계를 적고, 각 항목이 충분히 정의될 때까지 재귀적으로 세분화하는 방식임
  • 야외 활동용 streak tracker 예시는 데이터 모델, 캘린더 보기, 활동 기록, streak 계산, streak freeze로 점차 나뉘며 불확실한 지점도 함께 드러남
  • “충분히 정의된 작업”은 원하는 변화, 완료 모습, 완료까지의 모든 단계, 즉시 시작에 필요한 정보를 모두 예라고 답할 수 있는 상태임
  • 작업 분해는 경험 기반의 패턴 매칭이 필요한 기술이므로, 초보 팀에는 계획을 시도하고 피드백받는 안전한 연습 기회가 필요함

큰 프로젝트를 작업 목록으로 바꾸기

  • 프로젝트 추정에 관한 기존 논의는 이미 명확한 작업 목록이 있다고 가정했지만, 실제 현장에서는 그 이전 단계인 작업 분해가 먼저 필요할 수 있음
  • 작업 분해는 큰 프로젝트를 구성 작업으로 나누는 과정이며, 추정이나 위임을 하려면 “이 그림을 만든다” 같은 단일 작업보다 더 세밀한 단위가 필요함
  • 혼자 진행하는 개인 프로젝트라면 스케치만으로도 충분할 수 있지만, 다른 사람에게 맡기거나 기간을 추정하려면 세부성을 더 높여야 함

예시: 개인용 streak tracker

  • 야외 활동을 한 날을 추적하는 개인용 streak tracker가 예시로 사용됨

  • 1차: 스케치에서 시작

    • 시각적 목업은 만들 기능을 이해하기 쉽게 보여주는 좋은 출발점임
    • 혼자 만드는 프로젝트라면 이 정도 스케치만으로 바로 코드를 작성할 수도 있음
    • 추정이나 위임이 목적이라면 “이 그림을 만든다”보다 더 잘게 나뉜 작업 목록이 필요함

  • 2차: 큰 기능 단위로 나누기

    • 첫 번째 분해에서는 프로젝트를 대략적인 구성 요소로 나눔
    • 데이터 모델링
    • 현재 주의 날짜를 보여주는 캘린더 보기
    • 아이콘을 클릭해 활동을 기록하고 해당 날짜를 streak 추적상 완료로 표시하는 인터랙티브 캘린더
    • 현재 streak 길이 계산과 표시
    • streak freeze 구현
    • 예시를 단순화하기 위해 배포, 데이터베이스 설정 같은 운영 작업은 제외함
    • 실제 프로젝트, 특히 여러 사람이 참여하는 프로젝트라면 배포, 프론트엔드, 백엔드 작업을 별도 항목으로 나누는 편이 더 적절함
    • 이 단계만으로도 어느 정도 추정은 가능하지만, freeze 누적·추적 방식이나 과거 기록, 활동 유형 추가·삭제 같은 불확실성이 남아 있음

  • 3차: 완료 기준이 보이도록 더 나누기

    • 데이터 모델은 활동 유형, 기록된 활동, freeze, streak로 나뉨
    • 활동 유형은 run/bike/ski/climb 같은 하드코딩 목록이면 충분함
    • 기록된 활동은 날짜와 유형을 가짐
    • freeze는 획득 날짜와 사용 날짜를 가짐
    • streak는 시작일, 종료일, 활동 유형별 집계 정보를 가짐
    • 정적 캘린더 보기는 주간 보기, 홈 화면, 월간 보기, 탐색, 날짜 이동 입력으로 나뉨
    • 날짜 이동은 복잡한 fuzzy date 입력 없이 HTML5 date 위젯을 사용할 수 있음
    • 동적 주간 캘린더는 월간 보기에 동적 입력을 넣지 않고, 특정 날짜의 활동 유형 클릭으로 완료 기록을 남김
    • streak 계산과 표시는 활동 기록을 훑어 streak를 계산하고, 현재 streak를 UI에 표시하며, UI에서 활동을 기록하면 streak를 다시 계산함
    • streak freeze는 누적, 중복 누적 방지, UI에서 사용과 잔여 수 표시까지 포함함
    • freeze 획득 기준 X일은 일단 하드코딩해도 됨
    • freeze는 다음 streak로 이월될 수 있음
    • 과거 활동을 수정해 streak를 재계산할 때 freeze를 다시 얻는 중복 누적을 막아야 함

반복해서 적용하는 분해 절차

  • 작업 분해는 한 번에 끝나는 설계가 아니라 반복 과정임
    • 작업 목록이나 하나의 큰 프로젝트에서 시작함
    • 그 작업을 끝내기 위해 필요한 단계를 생각해 적음
    • 각 단계가 충분히 정의됐는지 확인함
    • 충분하지 않으면 해당 항목을 다시 분해함
  • 각 반복은 완전하거나 정확할 필요가 없고, 이전 목록보다 조금이라도 더 확장되면 충분함
  • 모든 작업이 충분히 정의될 때까지 같은 과정을 반복함

“작업”과 “충분히 정의됨”의 기준

  • 소프트웨어 개발과 프로젝트 추정에서 작업은 충분히 정의되고, 완전하며, 변화를 전달하는 일의 단위임
    • “work on stuff”는 요구사항 윤곽이 없기 때문에 작업이 아님
    • “나무를 벤다”는 전기톱만 가져왔다면 완전한 작업이 아님
    • 업무 맥락에서 작업은 수행 후 무언가가 달라져야 의미가 있음
  • 작업이 충분히 정의됐는지는 작업자가 다음 질문에 모두 “예”라고 답할 수 있는지로 판단함
    • 원하는 변화가 무엇인지 이해하는가
    • “완료”가 어떤 모습인지 이해하는가
    • 완료까지 필요한 모든 단계를 정의할 수 있는가
    • 차단 요소나 의존성이 없다고 할 때, 지금 바로 시작하는 데 필요한 정보를 모두 가지고 있는가
  • 조직 맥락에 따라 프로젝트 매니저, 주요 이해관계자, 감사자 같은 관찰자도 이 질문들에 “예”라고 답할 수 있어야 할 수 있음
  • 버그 수정처럼 더 이상 세분화하기 어려운 미지수가 있는 작업도 있음
    • 이런 경우에는 timeboxing 같은 기법을 사용할 수 있음

경험으로 쌓이는 분해 감각

  • 작업 분해는 연습이 필요한 기술이며, 처음부터 쉽게 느껴지지 않는 것이 정상임
  • 예시에서 데이터 모델링을 먼저 둔 이유는 명확한 알고리듬이 아니라 경험에 따른 직관임
    • 비슷한 도구를 만들 때 데이터 모델을 먼저 잡으면 일이 더 잘 풀렸던 경험이 있음
    • Django는 모델 데이터 우선 흐름에 더 잘 맞는 affordance를 제공함
  • 여러 프로젝트를 보거나 수행한 경험이 부족하면 시작점을 정하기 어려울 수 있음
  • 팀이 이 능력을 기르려면 안전한 환경에서 프로젝트 계획을 만들고, 분해해 보고, 피드백을 받아야 함
  • 초기 계획이 많이 틀리더라도 처벌하지 않으면, 그 실수가 다음번 패턴 매칭에 쓰일 경험 데이터가 됨

예시 프로젝트의 추정 결과

  • 보너스 추정에서는 작업을 세분화한 뒤 복잡도, 불확실성, 예상 일수, 최악의 경우 일수를 붙임
  • 전체 예상치는 15.5일, 최악의 경우는 23.5일로 계산됨
  • 주요 항목 중 streak 계산과 freeze 누적은 medium 복잡도와 moderate 불확실성으로 각각 예상 3일, 최악 4.5일임
  • freeze 중복 누적 방지는 small 복잡도지만 extreme 불확실성으로 예상 1일, 최악 5일로 잡힘
  • 실제로는 약 열두 번의 저녁과 긴 비행 한 번에 완성했지만, 디자인을 크게 생략했고 freeze 알고리듬에는 나중에 마주칠 버그가 있을 가능성이 있음

함께 보면 좋은 글 β

GN⁺   [-]
Hacker News 의견들
  • 나도 이런 식으로 많이 해봤고, 다들 그렇겠지만 내 경험상 문제는 두 가지임
    첫째, 실제 단계들을 계획한 대로 끝까지 수행한 적이 거의 없음. 몇 단계만 지나도 새로 깨닫거나, 빠뜨린 걸 발견하거나, 더 쉬운 방법이 보여서 계획은 따라가지 않게 됨
    둘째, 만드는 방법을 생각하는 창의적 노력이 전부 앞부분에 몰리는 느낌이라 이런 방식으로 일하는 게 싫음. 나머지가 여전히 대부분의 작업인데 가장 지루한 부분만 남고, 창의성과 지루함을 더 고르게 섞는 편이 더 재미있고 그래서 더 빠르며 결과도 나음
    둘은 아마 관련이 있고, 내가 ADHD일 가능성도 없진 않음
    • 작업 쪼개기나 추정 얘기는 보통 여러 명이 함께하는 팀이나 예산 같은 제약이 있는 프로젝트를 전제로 함
      자기 프로젝트를 탐색하거나 만들고 있고 별다른 책임 구조가 없다면, 계획 자체를 좋아하지 않는 이상 그렇게까지 계획할 필요는 없음
      하지만 상사가 “얼마나 걸리나? 누가 뭘 하나? 어디서 시작하나?”라고 묻는 순간 어떤 틀은 필요해짐
      나도 임의적이거나 지나치게 경직된 시스템에 맞추는 걸 싫어하지만, 시스템은 단순하고 유연해야 하며 생산성 시스템은 사람을 돕기 위한 것임
      글쓴이가 이걸 상세한 조리법처럼 의도했다기보다는, 자기 접근 방식을 보여줘서 다른 사람들이 자기만의 아이디어를 얻도록 하려던 것 같음
    • HN 댓글이 이런 글에 현실감을 얼마나 잘 불어넣는지 아직도 놀라움
      “계획은 절대 그대로 따라가지 않는다”는 말보다 더 나쁠 때도 있음. 실행 중에 작업을 계속 추가하다 보면, 끝에는 계획 때 만든 작업과 뒤섞여서 더 이상 필요 없는 미완료 작업 목록만 어지럽게 남음
      그런 작업들은 실행 중에야 생기는 전체 맥락 없이 만들어졌기 때문임
    • 일을 바라보는 정확하고 통찰 있는 방식임. 요즘 많이 생각하는 부분인데, 프로그래밍은 좋아하지만 업무 환경에서 하는 프로그래밍은 싫음
      프로그래밍의 재미는 유연하고 흐르듯 진행되는 창의적 활동이라는 데 있음. 진행하면서 만들어가고 유기적으로 경험함
      업무 환경에서는 감시와 책임 소재가 필요하기 때문에 이런 유기성이 주로 제거됨
    • 계획이 완벽하거나 미래를 다 알아맞히지 못하는 것까지도 계획의 일부임
      다음에 같거나 비슷한 일을 계획할 때 미래의 계획은 더 나아짐
      프로젝트 관리자들에게도 “계획에 실패하면 실패를 계획하는 것이다”라는 구호가 있음
    • 개인 작업에서는 목록과 계획을 싫어하지만, 점점 좋아하는 법을 배우는 중임
      기억해야 할 수많은 것들 속에서 놓치는 일이 많다는 걸 자주 깨닫기 때문임
      계획은 과거의 내가 생각했던 이상적인 결과물을 미래의 나에게 상기시키는 방법일 뿐임. 끝없이 계획을 바꾸며 반딧불을 쫓는 대신에
  • “업무 맥락에서 작업은 그 결과로 무언가가 달라질 때만 의미가 있다”는 기준은 유지보수 작업에서는 “무언가가 달라진다”의 의미를 더 넓고 세심하게 따져야 할 것 같음
    “작업 쪼개기”는 책 장르나 팟캐스트 장르가 되어도 될 만큼 큰 주제임. 자기계발이나 조직화 관련 책들을 보면 작업을 쪼개는 활동을 독자들이 이미 갖춘 원초적 인간 능력처럼 가정하는 경우가 많음
    하지만 내 경험이나 그룹 세션에서 들은 이야기로는, 작업 쪼개기는 매우 어렵고 회피감이나 절망감을 불러일으킬 수 있음
    내가 본 가장 넓게 적용 가능한 조언은, 내가 그 작업을 성공적으로 끝낼 수 있다는 확신이 90% 에 이를 때까지 계속 더 잘게 쪼개라는 것임. 이 확신 수준은 자기신뢰와 위험 감수 성향에 따라 달라져서, 어떤 사람은 성공 확률 70% 정도까지 쪼갤 수도 있음
    • 작업 분해에서 겪는 문제는 엔지니어의 과신이 너무 크다는 점임. 실제로는 하루 미만으로 끝나는 작업이 거의 없음
      하루에 쓸 수 있는 시간은 대략 6시간인데, 누군가 “반나절”이면 된다고 자신 있게 말해도 그게 약 3시간이라고 짚어주면 갑자기 훨씬 덜 확신하거나 불쾌해함. 그리고 3일 뒤에도 여전히 그걸 하고 있음
    • 비슷하게, 불확실성이 클수록 더 잘게 쪼갬
      이 방식은 시간 추정에서 놀라울 만큼 정확했는데, 총합으로 보면 그렇고 개별 추정은 크게 빗나감
      결국 확률 추정인 셈임. 많은 사건을 거치면 평균으로 수렴함
    • 맞음, 유지보수 작업은 더 많은 자원을 먹음. 고전적인 소프트웨어 개발 생명주기 방법론도 그렇게 말함
  • 소프트웨어 개발은 이런 식으로 관리할 수 없음. 이런 작업 분해는 고전적 관리 교육에서 나온 것임
    대부분이 모르는 문제는 소프트웨어 개발이 무엇보다 창의적 활동에 가깝다는 점임. 물론 진지한 기술적 측면은 있지만, 문제 자체가 가상적이고 토목공학처럼 현실 세계의 제약에 묶여 있지 않기 때문에 최적해가 하나로 정해지지 않음
    문제를 제대로 살펴보기 전에 해법을 정의하려 하면 최종 결과물만 제한하게 됨. 대부분의 탐색은 실제로 코딩을 시작한 뒤에야 일어남
    소프트웨어에서는 최종 결과물과 시간이 명확히 정의되지 않는 것이 그리 중요하지 않은데, 단위당 비용이 없기 때문임. 소프트웨어 공학 배경이 없는 관리자들은 이걸 잘 이해하지 못함
    범용성 있는 제품은 추가 개발 비용 없이 여러 고객에게 팔 수 있음
    하지만 대부분의 회사가 공장처럼 운영되기 때문에, 모든 절차는 결국 특정 고객을 겨냥한 매우 제한적인 제품을 만들어냄. 대형 기술 기업들이 피한 것이 바로 이것임
    • 3D 모델링이나 예술작품 제작 같은 창의적 작업도 얼마나 잘 정의되고 꽤 정확하게 추정 가능한 작업으로 나눌 수 있는지 알면 놀랄 것임
    • “대부분의 회사가 공장처럼 운영되기 때문에 결국 특정 고객 대상의 제한된 제품을 만든다”는 부분에 대해, 기능 공장이 아닌 회사 예시가 더 있나 궁금함
      업계 전체가 이 패턴을 받아들인 것처럼 보임
  • 커리어 내내 엔지니어로 일해와서, 큰 프로젝트를 병렬화하고 시간축에 배치할 수 있는 작은 단위로 나누는 데 익숙하지 않은 건 아님. 해야 하는 일이고, 더 잘하게 되어야 함
    하지만 솔직히 우리 대부분을 막는 건 오히려 그걸 하지 않는 능력이 부족해서라고 봄. 만들고 싶은 것이 있다면 모든 조각을 계획하지 말고, 가치가 있을 수 있는 가장 작은 것을 그냥 만들면 됨
    예시라면 “오늘” 화면과 버튼 4개부터 시작하면 됨. 매일 누를 운동 버튼 4개를 보여주는 것을 오늘 만들 수 있을 것임. 연속 기록, 동결, 달력 보기는 없어도 됨
    그런 아이디어들은 다 좋고 나중에 하게 되겠지만, 먼저 추진력이 필요함. 며칠 뒤에는 그 달력 보기가 마음에 안 든다고 판단할 수도 있음
    더 많은 프로젝트에는 “작게라도 그냥 해라”는 밀어붙임이 필요함. 오늘 끝내고, 그 지점에서 다음 작업이 뭔지 보라. 계획 단계에서 생각했던 것과 다를 가능성이 큼
    물론 이것도 쉽지는 않음. 가장 작은 것을 찾고, 산만해지지 않은 채 출시하기로 결심하려면 생각과 규율이 필요함. 그래도 연습할 가치가 있음
    • 내 작업을 정리할 때 이것을 Anna Principle이라고 생각하게 됨
      불확실성에 직면하면 “다음에 해야 할 올바른 일”에 집중해야 한다는 원칙임 [0]
      이걸 하찮게 보려는 뜻은 아님. 다음에 해야 할 올바른 일을 알아내는 건 어렵고, 내 관점에서는 계획에서 가장 가치 있는 부분임
      0: https://en.wikipedia.org/wiki/The_Next_Right_Thing#Synopsis
    • 이런 불확실한 상황에서 병렬화에 효과적인 것은 반드시 필요하다고 아는 것들임. 그게 단지 테스트를 준비하는 일일 수도 있음
      예를 들어 한 명은 테스트용 비교 방법을 만들고, 다른 한 명은 한 접근법을, 또 다른 한 명은 다른 접근법을, 세 번째는 또 다른 접근법을 시도한 뒤 정해진 기간 뒤에 모두 평가함
      물론 이미 선호되는 접근법이나 명백히 우월한 접근법이 없을 때만 의미가 있음
      실제 개발 중에는 모듈화가 병렬화 방법이 될 수 있음. 사람별 또는 팀별로 한 컴포넌트를 맡는 식임
      내 작업에서는 특히 아직 방향을 파악 중일 때, 사람이 마주하는 부분과 기술적 내부를 번갈아 진행하는 걸 좋아함. 쓰임을 모른 채 기술만 개발하면 사용할 수 있는 방식이 특정 방향으로 강제되고, 기술을 모른 채 인터페이스만 설계하는 것에도 함정이 있음
    • 보통 이걸 PoC나 MVP라고 부르지 않나? 이것도 일정화하고 예측해야 하는 것 아닌가?
    • 이런 태도는 인생 전반에도 꽤 좋다고 봄
  • 작업을 쪼개는 방식은 쪼갤 수 있는 것이 알려져 있을 때까지는 잘 작동함
    하지만 연구처럼 사전에 알 수 없는 것을 검증하기 위해 창의적 실험과 개념 증명이 필요한 일에서는 작업 분해 자체가 무너짐
    • 경영진이 개념 증명이나 연구여야 할 것을 산출물로 보면, 윗선이나 다른 팀에 약속하기 시작함
      그래서 나는 개념 증명 작업 대부분을 비공개로 하고 아무에게도 말하지 않는 습관이 생김
      잘 되면 공개하면 되고, 안 되면 체면을 구기거나 계속하면 안 된다는 걸 확인한 뒤에도 어떻게든 되게 만들라는 말을 듣지 않고 폐기하고 넘어갈 수 있음
    • 그건 쉽게 해결 가능함
      “X 조사에 3시간, Y에 3시간, Z에 3시간 쓰고, 그다음 무엇을 할지 계획 회의를 하자”라고 하면 됨
      결과는 네 가지임. 첫 번째가 해결하거나, 두 번째가 해결하거나, 세 번째가 해결하거나, 아무것도 해결하지 못하거나
      약간의 노력으로 풀 수 있는 문제라면 두 번째 시도, 즉 6시간 안에 해결할 확률이 50%임
    • 그러다 보면 결국 보험계리 모형을 꺼내게 됨
      그리고 어느 순간에는 그냥 해야 함
  • 이건 교사들에게도 많이 걸리는 문제임. 작업이 너무 몸에 배어 있어서, 의식적으로 이해하는 부분은 모두가 이미 아는 사소한 부분뿐인 경우가 많음
    작업 분해와 추정은 거의 같은 것임. 분해가 끝나면 몇 년 경험이 있는 사람은 작은 작업에 대한 표준 추정치가 있으므로 각 조각에 추정치를 붙이는 데 몇 분이면 됨
    내 경우에는 내가 추정할 수 있는 덩어리로 작업을 쪼개고, 추정할 수 없는 부분은 다른 사람 의견을 구함
    다만 숙련의 진짜 길이 작업 분해라고는 생각하지 않음. 누구나 나쁜 분해안은 만들 수 있음
    진짜 숙련은 증거가 그 작업 분해가 문제를 일으킬 만큼 틀렸음을 보여줄 때를 알아차리고, 그걸 소통하거나 재추정하는 데 있음 [0]
    그리고 그런 일이 생길 것임을 편하게 받아들여서, 바뀔 가능성이 큰 일정을 처음부터 내놓는 데 스트레스받지 않는 것도 중요함
    관리자들은 보통 처음부터 정확한 로드맵을 원하지만, 그건 불가능한 것을 요구하는 것임. 좋은 관리는 유연성에 있고, 시간이 지나며 개발자가 배우면서 예상했던 작업의 성격이 바뀐다는 걸 이해하는 데 있다고 봄
    글 끝의 작은 예시도 생각해볼 만함. 누군가 정확한 추정치, 즉 “비행기 여행 중 저녁 몇 번이면 끝난다”라고 말했더라도 그는 너무 위험하다고 거절했을 것임
    이는 추정이 정확성만의 문제가 아니라는 걸 보여줌. 여기에는 위험 관리, 기대치 관리, 작업 친숙도 같은 말로 다 드러나지 않는 요소가 많이 있음
    [0] https://jacobian.org/2021/jun/8/incorrect-estimates/ - 이 주제에 대한 글도 있음
  • 여기서 “작업화는 절대 안 한다”는 쪽은 내가 함께 일했던 주니어 개발자들과 일해본 적이 없는 것처럼 보임
    이들은 좋은 신입 소프트웨어 인력이지만, 영역이 새로워서 기본 기능을 세우는 법을 정말 모를 때가 있음. 내 경험상 그들은 배우고 잘해낼 수 있는 작업을 원하고, 그게 성장으로 이어짐
    반드시 기억해야 할 것은 프로세스 비용은 팀에 맞춰 조정하는 연속체라는 점임. NBA 선수들은 경기 중 허들에서 공 던지는 법을 배우지 않지만, 초등학교 3학년 아이들은 배움
    두 방식의 계획과 코칭은 각 팀에 맞을 때 적절함
  • 잘 모르겠음
    그게 소프트웨어 공학의 핵심 진실일지도 모름. 글쓴이가 만들려는 Streak 앱의 오픈소스 버전이 이미 있어서 바퀴를 다시 발명하는 것일 수도 있음
    뇌는 작업 목록을 좋아하지 않는 것 같음. 목록을 만드는 건 즐거울 수 있지만, 창업이나 코딩의 대부분은 탐색임
    그리고 작업 목록은 탐색을 막음
    • 궁금한데, 벽을 칠할 시공업자를 고용했을 때 기간이나 견적을 “모르겠습니다”라고 해도 받아들일 건가?
      아니라면, 소프트웨어 개발에서는 무엇이 달라서 우리 직업에서는 “모르겠습니다”가 합리적인 답이 되는 건가?
    • 동의함. 작업 목록의 목적 자체가 다른 일을 하지 못하게 스스로 막는 것임
      그게 맞을 때도 있지만 아닐 때도 있음. “지도는 영토가 아니다”
  • 작업을 나눌 때 가장 큰 문제는 중복되거나 불필요한 일을 하기를 꺼리게 된다는 것임
    작업을 더 작은 작업으로 나누려면 중복 작업을 해야 하고, 요령은 그걸 최소화하는 것임
    불필요한 일을 전혀 하지 않으려 하면 결국 모든 것을 한꺼번에 해야 함
    예를 들어 B가 A에 의존하는 모듈 A와 B가 있는 프로그램을 리팩터링한다고 하자. 가장 낭비가 적은 방법은 두 모듈을 함께 리팩터링하는 것임. 하지만 그게 가장 위험하고 추정하기도 어려움
    나눈 방식은 A를 리팩터링하고, B가 리팩터링된 A와 동작하도록 맞추는 것임. 그다음 A를 다시 리팩터링하면, 앞서 한 적응 작업이 금방 버려질 위험이 생김
    버려질 작업을 0으로 만들고 싶다면 작업을 쪼갤 수 없는 경우가 많음. 20년 경력이 있어도 나는 일을 나누기 위해 버려질 임시 작업을 하는 데 아직도 자주 망설임
    대신 몇 주짜리 작업을 하면서, 남겨둔 야크털 하나 없이 전부 깎아버리는 식이 되곤 함
  • 내가 게으르거나 규율이 없거나 카우보이식으로 일하는 걸 수도 있지만, 일을 “점수 매길 수 있는” 작업으로 쪼개야 하는 건 관리자가 진행 상황을 볼 수 있게 하려는 잡무처럼 느껴짐
    시작하기 전에 풀려는 문제를 생각해보는 건 말이 되고, 대략적인 이정표도 중요함. 하지만 대부분은 알려지지 않은 미지수가 너무 많아서 완전히 쪼개는 건 전혀 쓸모없거나 불가능함
    프로젝트를 쪼개는 데 걸리는 시간을 그냥 해결책을 찾거나 만드는 데 썼다면 훨씬 빨리 끝났을 것 같음. 적어도 그렇게 느껴짐
    • “관리자가 진행 상황을 볼 수 있게 하려는 잡무처럼 느껴진다”는 느낌을 가진 사람이 많음
      나는 보통 다르게 접근함. 애초에 만들지 말지 판단하기 위해 투입 노력을 추정하려는 것임. 말하자면 비용-편익 판단을 돕는 게 첫 번째 이유임
      팀에도 매우 유익할 수 있음. 특히 경험이 적은 사람들과 일할 때는 작업을 많이 나눠주고 병렬화할 수 있음
      Jacob도 자기 Streak 앱을 구현할 때는 이런 분해를 많이 하지는 않았을 것 같고, 그래서 설명을 위해 재귀적으로 예시를 든 듯함
    • 관리 부분을 빼고 보면, 작업 분해가 도움이 됐던 곳은 별로 의욕이 나지 않는 일을 해야 할 때였음. 지루하거나, 나른하거나, 너무 벅차 보이는 경우임
      그런 때는 더 작은 작업으로 나누고 하나씩 끝내는 게 유용했음. 그러면 교착 상태에 있거나 일하기 싫은 상태에서도 진전이 생기고, 그 진전이 계속할 추진력을 만들어줌
    • “표준적인” 회사에서 일한다면 대체로 동의하지 않음. 보통은 “폼 만들기”나 “데이터 옮기기 / CRUD 처리” 같은 일이고, 이런 작업에는 대체로 알려지지 않은 것이 그렇게 많지 않음
      관리자들이 속도를 추정할 수 있는 것도 분명 가치가 있음. 다만 한 번 맛을 들이면 “확실하지 않다”는 말을 정말 이해하지 못하게 되는 게 문제임
      나도 컨설턴트라서, 우리가 “애자일”하게 일하더라도 “이것을 이 시간 안에 납품합니다”라고 말하는 것이 매우 중요함
답변달기