TIL 3: Tech Spec

테크스펙(Tech Spec)이란?

기술 설명서. 기능을 구현하기 전에 이 기능을 어떻게 구현할 것인지 기술적으로 풀어 설명하고, 제안하는 글

 

장점

1. 기획적 오류, 버그를 초기에 발견 가능
2. 커뮤니케이션 비용 절감
3. 문서화를 통한 히스토리 파악 가능

내용

• 요약(Summary)
  테크 스펙을 세 줄 내외로 정리. 테크 스펙의 제안 전체에 대해 누가/무엇을/언제/어디서/왜를 간략하면서도 명확하게 적는다.
• 배경(Backgroud)
  프로젝트의 상황(문맥)을 적는다. 목적과 동기, 어떤 문제를 해결하려고 하는지, 이 문제를 해결하기 위해 이전에 시도가 있었는지 등을 적는다.
• 목표(Goal)
  예상 결과들을 Bullet Point 형태로 나열한다. 이 목표와 측정가능한 임팩트들을 통해 프로젝트의 성공 여부를 평가하는 척도로 활용한다.
• 목표가 아닌 것(Non-Goals)
  프로젝트에 연관되어 있으나 의도적으로 하지 않거나 해결하지 않으려 하는 것.
  이것을 정의하면 프로젝트 범위를 더 명확하게 제한하고, 독자들이 프로젝트 범위를 넓히려는 걸 막을 수 있다. 목표와 마찬가지로 Bullet Point 형태로 나열한다.
• 기타 고려 사항들(Other Considerations)
  고려했었으나 하지 않기로 결정된 사항들을 적는다. 이는 일종의 문서화 역할을 하며 이전에 논의되었던 주제가 다시 나오지 않도록 할 수 있다.
• 마일스톤(Milestones)
  테크 스펙의 내용을 바탕으로 추정한 마일스톤을 공유한다. 모든 작업을 주요 성과로 나누고 예상 날짜를 최대한 자세히 적는다.
  마일스톤을 항상 최신 상태로 유지하면서. 프로젝트 상태를 공유하고 합리적인 시간 내에 완료될 수 있도록 한다.

마치며

뱅크 샐러드 테크 스펙 글의 문서가 필요한 이유를 대화형으로 재밌게 풀었놓은 글을 재밌게 읽었는데 남일이 아닌 것 같아 이 글을 작성하게 되었다.
신규 기능 제작 도중에 기획 오류를 발견하거나, 누군가 '이 코드 설명 좀 해주세요'라고 물으면 실작업자를 찾아가라고 토스한 경험이 누구나 한 번쯤은 있을 것이다.
'테크 스펙'을 빨리 알았더라면, 우리 회사도 이것을 도입했더라면 커뮤니케이션과 개발 작업들이 훨씬 쉬워지지 않았을까 생각한다.
회사에서 받아줄 것같진 않지만.. 제안해 봐야지! 안 해주신다면 나중에 토이 프로젝트를 진행할 때라도 작성해야겠다🥲

출처

아래의 글들을 참고하여 개인 공부 목적으로 정리한 글입니다.
https://blog.banksalad.com/tech/we-work-by-tech-spec/
https://eng.lyft.com/awesome-tech-specs-86eea8e45bb9