<뱅크샐러드의 특별한 스펙, '테크 스펙'> 많은 글에서 일할 때 '문서화'를 해두는게 중요하다고 강조하지만, 막상 문서화를 하려면 어떻게 할지 막막한 경우가 많습니다. 그래서 뱅크샐러드에서 문서 작성하는 방식에 대해 소개한 글을 가져왔습니다. '테크 스펙'이라는 문서는 개발자가 작성하는 것을 상정하고 있긴 하지만, 디자이너 또한 같은 양식을 활용해도 무리가 없다고 생각합니다. 저는 특히 '목표가 아닌 것'을 같이 적는 것이 인상 깊었습니다. 그동안 문서를 써두고 공유하면, 제가 써두지 않은 영역까지 상상하여 스펙이라고 생각하는 경우가 정말 많았거든요. 그래서 새로 이야기가 나온 부분까지 스펙으로 넣을 것인지 말지를 논의하느라 시간이 많이 허비되곤 했습니다. 어느 직군이든 '내가 무엇을 위해, 얼마의 기간 안에 이 일을 해내야하는가'를 주지하고 일하는 것은 매우 중요하다고 생각합니다. 나 자신에게 마일스톤이 되줄 뿐만 아니라 공유하기에도 편한 테크 스펙 양식을 활용해보시는 건 어떨지 추천해봅니다! --------------------------- - 복잡도가 증가한다는 것은 더 많은 함정을 만드는 일입니다. 그리고 개발자의 일은 이 복잡도를 제어하는 것이죠. 복잡도를 제어할 수 있는 가장 좋은 방법은 휘발성이 높은 Short Term Memory로부터 👉 의도와 목적을 조율할 수 있는 수단으로 나아가는 것입니다. 그래서 뱅크샐러드는 테크 스펙을 쓰기 시작했습니다. - 요약 (Summary) 가장 먼저 테크 스펙을 세 줄 내외로 정리합니다. 테크 스펙의 제안 전체에 대해 누가/무엇을/언제/어디서/왜를 간략하면서도 명확하게 적습니다. - 배경 (Background) 프로젝트의 Context를 적습니다. 왜 이 기능을 만드는지, 동기는 무엇인지, 어떤 사용자 문제를 해결하려 하는지, 이전에 이런 시도가 있었는지, 있었다면 해결이 되었는지 등을 포함합니다. - 목표 (Goals) 예상 결과들을 Bullet Point 형태로 나열합니다. 이 목표들과 측정 가능한 임팩트들을 이용해 추후 이 프로젝트의 성공 여부를 평가합니다. - 목표가 아닌 것 (Non-Goals) 목표가 아닌 것은 프로젝트에 연관되어 있으나 의도적으로 하지 않거나 해결하지 않으려 하는 것을 말합니다. 목표가 아닌 것을 정하면 프로젝트 범위를 더 명확하게 할 수 있고, 이 기능도 붙이자, 저 기능도 붙이자 하는 것을 막을 수 있습니다. 목표처럼 목표가 아닌 것도 Bullet Point 형태로 읽기 쉽게 적어 독자가 직관적으로 이해할 수 있도록 합니다. 목표가 아닌 것을 세부적으로 잘 적으면 프로젝트 범위를 넓게 보려 하는 독자들의 폭주를 막을 수 있습니다. - 계획 (Plan) 테크 스펙에서 가장 긴 파트 입니다. 준비한 모든 리서치, 준비 내용들을 여기에 씁니다. 어떻게 기술적, 엔지니어링적으로 접근할지 상세히 묘사합니다. 만약 어떤 부분을 어떻게 할지 확실히 결정하지 못한 상태라면 어떤 것들을 고려하고 있는지 목록화해서 적습니다. 그렇게 하면 이 문서 리뷰어들이 올바른 결정을 내리도록 도움을 주게 됩니다. - 이외 고려 사항들 (Other Considerations) 고려했었으나 하지 않기로 결정된 사항들을 적습니다. 이렇게 함으로써 이전에 논의되었던 주제가 다시 나오지 않도록 할 수 있고, 이미 논의되었던 내용이더라도 리뷰어들이 다시 살펴볼 수 있습니다. - 마일스톤 (Milestones) 프로젝트를 제 시간에 맞추기 위해 테크 스펙의 내용을 바탕으로 추정한 마일스톤을 공유합니다. 실험 계획, 배포 날짜를 포함해 최대한 자세히 적습니다.