Design Docs at Google
Industrialempathy
Google Design Docs에 대한 설명입니다.
구글 내부에서는 소프트웨어 설계를 정의하는 디자인 문서를 비공식 정으로 사용한다고 합니다. 비공식 문서라서 엄격한 가이드라인이 있는 것은 아니지만 그동안 수많은 디자인 문서가 만들어지면서 유용한 구조가 자리 잡았다고 합니다.
맥락과 목표, 목표가 아닌 것을 명확히 설명하고 실제 디자인에 대한 설명과 다이어그램, 제약 조건을 명시하고 다른 대안이나 우려사항은 없는지를 설명하지만 바쁜 사람들도 쉽게 읽을 수 있을 정도로 짧아야 한다고 합니다.
디자인 문서를 작성하는 것도 비용이기 때문에 작성할 때 고민해야 하는데 보통 의사 결정에 대한 설명 없이 구현에 대한 설명만 있다면 문서를 작성하는 것보다는 바로 프로그래미을 작성하는게 더 좋은 선택이라고 얘기합니다.
이렇게 만든 문서는 반복을 통해서 개선한 뒤 리뷰를 통해서 다듬고 이후에도 계속 유지 관리를 하면서 시간이 지나면 소프트웨어가 만들어 진 후 다시 학습에 사용된다고 합니다.
----
디자인 문서나 테크 스펙을 많은 조직에서 사용합니다만 개인적으로 디자인 문서를 좋아하는 편은 아닙니다. 조직의 상황이나 문제에 따라 다르긴 하겠습니다만 일반적으로는 디자인 문서를 작성하는 것이 실제 할일보다는 너무 장황하게 느껴서 오히려 일이 느려지는 느낌을 많이 받는 편입니다. 실제 일보다 서류 작업이 많은 보수적 조직에 닮아가는 느낌이 어느 정도 있습니다.
물론 문서를 작성하고 형식에 맞게 설명을 하면서 구현자 스스로도 정리를 하게되는 효과도 있고 다른 사람도 이해할 수 있게 문서로 남음으로써 이해도도 높이고 히스토리가 되는 장점도 있다고 생각합니다. 이렇게 되려면 문서의 실용성이 상당히 많이 검증되어야 합니다만 일반적으로는 협업시에 제출해야할 서류 정도로 쓰이는 경우가 많아서 너무 사소한 일에도 문서를 작성해야 하거나 너무 추상적인 문서가 작성되는 상황을 종종 보게 됩니다.
물론 개인 취향이 많이 반영되어 있긴 합니다. 문서의 필요성은 중요하긴 하지만 저는 일반적으로 좀 장황하게 느껴지는 편입니다.
https://www.industrialempathy.com/posts/design-docs-at-google/
다음 내용이 궁금하다면?
이미 회원이신가요?
2024년 5월 18일 오전 9:24
댓글 0
함께 읽은 게시물
제가 잘못한 게 아니라고요?
큰 장애를 냈어요. 사소한 실수였죠. 연봉을 뱉어내도 메울 수 없는 손실을 냈어요.
... 더 보기
아직 나도 정립되지 않은 상태이긴한데, 실무에서의 바이브 코딩은 다르다.
비단 개발자 관점에서만이 아니라, 기획자, 디자이너도 마찬가지로 다른 방식을 써야한다.
저의 첫 온라인 강의, 모든 파트가 오픈되었습니다.
안
... 더 보기
<'책 한 권에 딱 한 줄만 가지겠다'라는 마음으로 책을 읽는다>
1. 적지 않은 사람들이 하는 말이 있는데 바로 '책을 읽긴 했는데 아무 생각도 떠오르지 않는다'라는 것이다. 목적 없이 책을 읽은 탓이다. 나 같은 경우에는 딱 한 줄만 가지겠다는 마음으로 읽는다.
... 더 보기< 매일 아침 헬스장 가기 싫은 당신에게 >
1. 두 선택지가 팽팽히 맞서고 어느 한쪽이 단기적으로 더 고통스럽다면 그 길이 장기적으로 이익일 가능성이 높다. 복리의 법칙에 따라 당신은 장기적인 이익을 선택해야 한다.
