ETA(Estimated Time of Arrival)

✅ ETA란?

Estimated Time of Arrival
원래는 “도착 예정 시간”을 뜻하지만,
개발/PM 분야에서는 “예상 완료 시점”을 의미

---

🛠️ PM/개발에서의 ETA =**

작업 완료 예상 시간**

예시:

• 🧾 “이 기능 ETA 언제야?” → “언제까지 끝날 수 있냐”는 뜻
• 📍 Jira, Notion 등에서 “Due Date”나 “ETA” 필드로 표현됨

---

🔹 ETA를 정하는 기준

기준	설명
⏱ 작업 복잡도	로직이 단순한지, 기존 시스템과 얼마나 얽혀 있는지
🧩 의존성	다른 작업, 외부 API, 디자인, 승인 등 대기 요소 있는지
👨‍💻 작업자 역량 & 집중도	익숙한 영역인지, 멀티태스킹 많은지
📆 가용 시간	오늘 바로 투입 가능한지, 다음 주부터 가능한지
🧪 QA 포함 여부	개발 끝이 곧 ‘완료’는 아님. 테스트까지 포함했는지?

---

🧠 ETA는 왜 중요한가?

이유	설명
🗺 로드맵/스프린트 계획 수립	ETA가 없으면 일정을 못 짬
🚦 리스크 조기 감지	예상보다 지연될 작업을 빠르게 식별 가능
🤝 이해관계자 커뮤니케이션	“언제쯤 출시되냐”에 대한 근거 있는 답변 제공
📈 성과 추적 및 개선	ETA vs 실제 소요 비교로 예측력 개선 가능

---

📏 ETA 예측 방식 종류

방식	설명	사용 시기
🧠 경험 기반	“이거 지난번에 2일 걸렸으니 이번엔 비슷하겠네”	빠른 추정 필요할 때
⏳ Story Point 기반	스프린트마다 포인트당 평균 속도로 계산 (예: 1SP = 0.5일)	스크럼 팀
🧮 PERT 분석	비관/낙관/중간값 평균 (3점 추정)	고위험/불확실 작업
📊 히스토리 기반 예측	과거 작업 데이터 기반으로 자동 계산 (Jira Advanced Roadmap 등)	데이터 기반 조직

---

💬 ETA 커뮤니케이션 예시

🔄 PM과 개발자 간 대화 예시:

PM: 이 API 작업 언제쯤 끝날 수 있을까?

Dev: 논의한 로직으로만 하면 개발은 하루, 테스트까지 이틀이면 될 것 같아요.

PM: 그럼 ETA 수요일 오후 3시로 설정할게요. 혹시 리스크 있으면 중간에 꼭 알려줘요!

---

🔎 ETA 다룰 때 PM 팁

팁	설명
⏱ “언제 시작 가능한가”도 같이 확인	ETA는 “완료 시점”이므로 “시작 가능 시점”과 함께 체크해야 실질적인 일정 파악 가능
🧮 추정치에 버퍼 포함하라	실무에서는 20~30% 정도의 완충 시간 넣는 게 일반적
📣 커뮤니케이션은 유연하게	ETA는 “예측”이지 “약속” 아님. 책임 추궁이 아니라 신뢰 기반의 계획 도구로 사용해야 해
📊 ETA vs Actual 기록하라	반복하면서 팀의 예측 정확도를 높임 (velocity 계산에도 도움됨)