집중 작업과 답변 시간을 분리합니다
설계나 디버깅처럼 문맥을 오래 유지해야 하는 일은 캘린더에 한 덩어리로 잡으세요. 오전이 모두에게 맞는 것은 아닙니다. 자신이 실제로 집중되는 시간대를 고르고, 긴급 연락을 받을 방법은 팀과 미리 정해 두는 편이 현실적입니다.
작업을 다음 행동 크기로 줄입니다
“결제 기능 개발”처럼 큰 이름만 적으면 시작점이 보이지 않습니다. 요구사항 확인, 실패 조건 작성, 테스트 추가, 구현, 리뷰 요청처럼 다음 행동을 나누세요. 하루 우선순위도 숫자를 억지로 고정하기보다 마감, 사용자 영향, 다른 사람의 대기 여부로 정하면 됩니다.
타이머는 선택 도구로 씁니다
포모도로는 일정 시간 집중한 뒤 쉬는 방법입니다. 25분이 잘 맞지 않으면 더 짧거나 긴 구간을 써도 됩니다. 타이머가 오히려 흐름을 끊는다면 사용하지 않아도 됩니다. 중요한 것은 시작 전 한 가지 결과를 정하고, 끝난 뒤 다음 행동을 남기는 것입니다.
회의는 시간보다 목적부터 확인합니다
결정할 내용, 필요한 참석자와 준비 자료가 없으면 문서나 메시지로 대신할 수 있는지 먼저 보세요. 복잡한 설계 논의처럼 대화가 빠른 일은 회의를 열되, 끝날 때 결정과 담당자, 다음 확인 날짜를 기록하세요. 모든 회의를 오후나 30분 이하로 고정할 필요는 없습니다.
리뷰 대기 시간을 일정에 포함합니다
코드를 작성한 뒤에도 리뷰와 수정, 테스트, 배포 시간이 남습니다. 작업 계획에는 본인 작업뿐 아니라 다른 사람이 확인하는 시간을 넣으세요. 큰 변경은 리뷰하기 쉬운 단위로 나누고, 왜 바꿨는지와 확인 방법을 함께 적으면 왕복 시간을 줄일 수 있습니다.
자동화는 반복 횟수와 실패 비용으로 고릅니다
한 번에 5분이 걸린다는 이유만으로 모두 자동화할 필요는 없습니다. 자주 반복되거나 사람이 놓치기 쉬운 테스트, 형식 검사, 배포 전 확인부터 작은 자동화를 시험하세요. 유지보수 시간이 절약 시간보다 커지면 단순한 체크리스트가 더 나을 수 있습니다.