GitLab 팀 안내서(team handbook)를 보고
입사하면 보게 되는 안내서. 안내서만 보면 어떤 회사인지 알 수 있다. 이렇게 호기롭게 지르고 싶지만 내가 본 안내서가 몇 개 안 될뿐더러 안내서를 공개한 회사 내부 사정을 잘 모른다. 회사 구성원은 어떤 소양을 가진 입사자를 원할까? 자기 동료에게 바라는 건 뭘까? 실상과 다르더라도 적어도 이건 확인할 수 있다.
외부인이 볼 수 있게 안내서를 공개한 게 호기롭다. 채용 페이지에 회사 소개를 적어 놓지만 안내서가 있다면 난 안내서를 보겠소. 회사 소개 보다는 일하는 방식을 더 많이 엿볼 수 있기 때문에. 외부 공개니 문서가 많이 정돈됐다. 업데이트도 잘 되겠지?
이하 인상적인 항목과 짤막한 코멘트.
2.Use asynchronous communication when possible (issues and email instead of chat), issues are preferred over email, email is preferred over chat, announcements happen on the team call agenda, and people should be able to do their work without getting interrupted by chat.
Communication > Internal Communication
비동기로 일할 수 있는 능력은 리모트 작업자에게 필수. issue > email > chat 순으로 권장.
2.Always reply to emails, even when no action is needed. This lets the other person know that you received it. A thread is done when there is a single word reply, such as OK, thanks, or done.
Communication > Internal Communication > Email
이메일 보냈는데, 한참 동안 답변이 없어서 다시 이메일을 보냈다. 그래도 응답이 없어서 자리로 찾아간다. “아~ 그거 시간이 좀 걸릴 것 같아요.” 허탈하게 자리로 돌아온다. 난 즉시 처리를 바라고 이메일을 보낸 게 아니다. 그리 급하면 찾아갔지. 난 내가 쓴 이메일을 확인했는지가 중요했다. 내가 찾아가서 들은 말을 이메일 답장으로 즉시 들었더라면 필요 없는 비용을 아낄 수가 있다.
즉시 답변을 못 하더라도 이메일을 확인하면 답장하라. 이거 제대로 안 하는 사람과 일하면 리눅스형 피드백을 하는 사람만큼이나 답답하다.
4.Email forwarding rules are specified in the shared “GitLab Email Forwarding” Google doc accessible to people in the company, if you want to be added or removed from an internal alias (e.g. sales@gitlab.com), change a rule, or add a forwarding email alias, please make a suggestion in the document.
Communication > Internal Communication > Email
Google Docs로 관리할 수도 있구나. 추가 삭제 요청이 편하겠다.
1.Thank people that did a great job in our ’Thanks’ chat channel. If someone is a team member just “@” mention them. If multiple people were working on something try mentioning each person by “@” name. ’Thanks everyone’ does not say much.
Communication > Internal Communication > Say Thanks
Thanks 채널이 따로 있네. 재미있다. 여기서는 고마운 사람 맨션을 팍팍해라. 모두 고마워. 이러지 마.
급한 일이 아니면 맨션을 최대한 자제하기를 안내서에서 당부하고 있다. 서로 맨션 하며 고맙다고 말하는 걸 부담스러워 할까 봐 채널을 따로 만든 것 같다. 별 시답잖은 일로 핸드폰 알림이 오면 짜증 나지만 자기한테 고맙다는 말을 해서 알림이 온다면 오버워치를 하는 중이라도 짜증이 안 난다.
3.Don’t thank the CEO or other executives for something that the company paid for, thank GitLab instead.
Communication > Internal Communication > Say Thanks
ㅋㅋㅋ. 사장님 고마워요. 이런 말 하지 마.
1.Always create an issue for things you work on. If it is worth spending time on, it is worth creating an issue for it since that enables other people to learn and help. You can always edit the description or close it when the problem is something different or disappears.
Communication > GitLab Workflow
좋은 정책이다. 현재 일하고 있는 팀에서도 이 정책을 따르고 있어서 마음에 든다. 항상 일감을 만들고 진행하라.
4.After a discussion about a feature update the issue body with the consensus or final conclusions. This makes it much easier to see the current state of an issue for everyone involved in the implementation and prevents confusion and discussion later on.
Communication > GitLab Workflow
일감 본문을 최신 정보로 업데이트하면 읽기는 편하겠다. 달린 댓글을 다 보는 수고를 아낄 수 있다. 댓글로 진행 상황 추가는 부지런히 잘하는 편인데, 본문 업데이트는 거의 안 한다. 배려가 부족했네.
4.The call is recorded automatically, and recordings are automatically deleted after 7 days. Recordings can be found by logging in to the BlueJeans web app, click recordings at the top, and all past recordings show up there. [.] Make sure the file is downloaded to your encrypted home drive, and delete it after viewing.
Communication > Team Call
7일만 저장하는 게 인상적이다. 영상을 많이 쌓아두고 후처리를 안 하면 찾아보기 힘들다. 무작정 계속 쌓아두면서 기록을 잘 남기고 있다는 착각을 방지하기 위해서인 것 같다. 이렇게 저장하는 기간을 정해놓으면 계속 유지해야 하는 사항은 문서로 남긴다.
5.If you have multiple points in a comment or email, please number them to make replies easier.
Communication > Writing Style Guidelines
번호를 붙이면 답변하는 사람이 편하다. 인용을 안 하고 1번은 어떻고 2번은 어떻다. 이런 식으로 말할 수 있기 때문.
