@이동재 지현님이 생각할때, 현재 개발 시간을 100이라고 한다면 몇정도를 문서에 시간을 들이는 것 같나요?
@JIHYUN KIM 현재는 100중에 10 정도만 차지하는 것 같지만, 앞으로 문서화에 더 집중하면 목표했던 개발 속도를 맞추지 못할 것 같아요.
@이동재 회의나 논의를 문서화를 했을 때, 문서화를 안하고 회의, 논의만 했을 경우에는 → 100에서 몇정도를 문서작성 하는 시간에 할애한것 같나요?
@정주연 개발+논의+문서화의 시간이 개발+논의의 시간보다 오히려 짧을 수 있을 것 같아요. 쉬는 시간을 가지고 와서 다시 봤을 때 문맥을 파악하기에도 좋고 논의 중 말이 다른 곳으로 가버리는 문제도 방지할 수 있고! 생각을 정리한 상태로 개발할 수 있어서 개발하는데도 오히려 시간을 절약할 수 있었어서 좋은 것 같아요.
@이동재 주연님과 같은 생각. 글로 적다보면 더 짜임새 있고, 다른 곳으로 새지도 않음. 다른 팀원에게도 고민한 내용을 공유 가능. 나중에 어떤 고민을 했는지 어필도 가능.
@혜원 강 지금 우리의 구현 속도가 나쁘지 않다고 생각해요. 무리해서 잡은 스프린트 일정인데도 꽤 잘 소화해내고 있다고 생각해서 문서화를 더 하더라도 문제 없을 것 같습니다.
@JIHYUN KIM 여러분의 말씀 덕분에 회의 내용을 문서화 하는게 오히려 회의 시간을 줄일 수 있는 방법이라는걸 알게 되었습니다.
@이동재 아티클을 작성하는 것은 또 다른 내용인것 같다. 아티클 작성은 개발 진전에 영향이 별로 없을것 같긴 해요. 목표를 학습하는 과정으로 두면 너무 좋은 방법이다 라고 생각해요. 아티클을 작성했다라는 것은 내가 이 프로젝트를 통해서 어떤 문제가 있어서 어떤걸 학습해서 어떻게 해결했다 라는걸 증명하는 건데 → 사이드프로젝트의 근간.
@JIHYUN KIM 굳이 아티클을 작성하지 않고, 화면 공유 같은걸 통해서, 예를 들면 도커에 관해 설명한다고 하면, 머리속에 잘 남고 괜찮지 않을까?
@정주연 증거가 없어져서 그런 것 같아요. 평일에 개발할 때는 개발논의 문서화 위주로 문서화 하고, 어떤 고민이 있었고 어떻게 해결했는지에 대한 아티클을 평일에 하면 개발시간을 빼야되서, 평일에는 주제를 빼놓고 주말에 아티클을 남기는 시간을 갖는것도 좋을 것 같아요.
@이동재 기술 공유에 관련된 내용을 문서화하면 몇개월이 지나도 기억할 수 있어서 필요할 것 같다고 생각했어요. 학습한 내용을 잊지않고 다시 들춰볼 수 있어요.
@정주연 아티클 작성이 강요는 아니고 자율적으로 하는 걸로 생각하자.
@이동재 금요일 기술 발표를 위해서는 아티클이 필수이지 않을까?
@JIHYUN KIM 기술발표 어떤식으로 하면 괜찮을까요? 1. 말그대로 기술 발표, 2. 개발하면서 만난 문제 해결 과정.
@이동재 보통 기업의 기술블로그 느낌을 생각했어요. 어떠한 문제를 겪어서 어떤 기술 도입을 통해 해결했다 라는 방식의 글.