Lesson Learned (2) - 간단한 Task도 공식적으로 다뤄야 한다

스프린트를 운영하다 보면, 유독 간단하게 생각되는 Task 들이있다.
기능 추가라고 해도 규모가 작고, 복잡한 화면 설계가 필요한 것도 아니고, 별도의 디자인 작업도 없어 보이는 그런 일들이다.

이번에도 비슷했다.

나는 이 작업을 보면서 “이 정도는 굳이 기획서를 쓸 필요는 없겠다”라고 판단했다.
디자인도 필요 없는 task라고 생각했고, 팀에게도 간단히 설명만 한 뒤 넘어갔다.

그 순간에는 꽤 효율적인 판단처럼 느껴졌다.
문서를 작성하는 시간도 아낄 수 있고, 모두가 각자 필요한 부분만 이해하면 충분하다고 생각했기 때문이다.

그런데 결과적으로는, 그 판단이 오히려 팀의 흐름을 끊는 원인이 되었다.

AI 파트는 자신들이 맡은 작업을 기준으로 task를 진행했고, 필요한 부분을 모두 완료한 뒤 다른 파트의 지원이 필요한 시점에서 협업을 요청했다.

하지만 프론트엔드와 백엔드 입장에서는 이야기가 달랐다.

처음 설명을 들을 때 이 작업이 자신들과 직접 관련이 있다고 인식하지 못했고,
정식 문서나 리뷰가 없었기 때문에 어디까지 연결되는 일인지 파악할 기회도 부족했다.
그러다 어느 순간 갑자기 새로운 할 일이 생긴 것처럼 느껴졌고, 자연스럽게 당황스러운 상황이 만들어졌다.

돌이켜보면 문제는 task의 크기가 아니었다.

문제는 공유 방식이었다.

작은 일이라고 해서 작은 영향만 가지는 것은 아니다.
특히 여러 파트가 연결되어 있는 조직에서는, 처음에는 단순해 보이는 일도 진행되는 과정에서 다른 파트의 리소스와 일정에 영향을 준다.
그런데 이 연결 구조가 사전에 명확히 공유되지 않으면, 어떤 파트는 “이건 내 일이 아닌 것 같다”고 받아들이고,
또 어떤 파트는 “당연히 이어서 도와줄 수 있는 일”이라고 생각하게 된다.

결국 같은 task를 보고도 서로 다른 전제를 갖게 되는 것이다.

이번 일을 통해 내가 분명하게 배운 점은 하나다.

간단한 Task도 공식적으로 다뤄야 한다

큰 프로젝트는 원래 모두가 긴장한다.
PRD를 작성하고, 리뷰를 하고, 일정과 역할을 나누는 것이 자연스럽다.
하지만 작은 task는 그렇지 않다.
“이 정도는 말로 설명하면 되겠지”
“이건 금방 끝나겠지”
“굳이 다 같이 볼 필요는 없겠지”
이런 생각이 끼어드는 순간, 오히려 협업의 사각지대가 생긴다.

작은 task에서 가장 위험한 것은 복잡함이 아니라 방심이다.

그래서 이제는 원칙을 바꾸려고 한다.

아무리 사소해 보이는 task라도 다음 두 가지는 지키려고 한다.

 

---

1. 정식으로 PRD를 작성하기

문서의 분량이 길 필요는 없다.
하지만 최소한 이 task가 왜 필요한지, 어떤 파트와 연결되는지, 누가 언제 어떤 방식으로 대응해야 하는지는 남겨야 한다.
그래야 각 파트가 자기 일과의 연관성을 정확히 판단할 수 있다.

2. 과제 리뷰를 반드시 진행하기

모든 팀원이 함께 보든, 최소한 각 파트 리드들과라도 리뷰를 하든
과제를 한번 더 확인하는 과정이 필요하다.
이 짧은 확인만 있어도 나중에 “갑자기 생긴 일” 같은 느낌은 훨씬 줄어든다.

이번 경험은 단순히 문서를 안 써서 생긴 문제가 아니었다.
협업에서 중요한 것은 일의 크기가 아니라, 같은 그림을 보고 시작하느냐는 점이라는 걸 다시 느꼈다.

앞으로는 작은 일일수록 더 명확하게 열고, 더 공식적으로 공유하려고 한다.
그래야 팀이 중간에 놀라지 않고, 각자의 일정 안에서 자연스럽게 연결될 수 있다.