테크니컬 라이팅 (353) 썸네일형 리스트형 WTD 애틀랜틱 2024 - 라이트닝 토크 첫째날 Abi Sutherland: A Documentation Carol: Scrooge has tech writing lessons for us all 스크루지 이야기를 통해 기술 문서를 작성할 때에 명심해야 할 몇 가지 사항을 이야기합니다. - 오래된 시스템(과거의 유령), 미래의 시스템(미래의 유령)을 따라가지 말고 현재의 시스템을 문서화하세요. - 동료(말리의 유령)의 말에 귀를 기울이고 기존에 만들어진 템플릿을 활용하세요. - 사용자(크래칫 가족)에게 실제로 필요한 것이 무엇인지 알아보고 우선순위를 정하세요. - 커뮤니티를 통해 서로 협력하고 지원하세요.https://youtu.be/DewfY-ult8M?si=clPNXDDTxYlNwAP4 Ariel Kaiser: You just spilled a .. WTD 애틀랜틱 2024 - 테크니컬 라이터에게 언어학이 필요한 이유 테크니컬 라이터가 언어학을 알아야 하는 이유 중 하나는 스타일 가이드를 좀 더 적극적으로 적용할 수 있습니다. 단지 이미 있는 가이드를 찾아보고 적용하는 것이 아니라 이런 가이드가 왜 정해졌고 어떤 규칙에 의해 적용되는지를 알 수 있다는 겁니다. 그럼 혹 스타일 가이드에서 누락된(또는 적용하기 애매한) 항목이 있더라도 이를 확인하고 어떻게 적용해야 할지 알 수 있으며 스타일 가이드에 추가할 수 있다는 것이죠. 수동태를 쓰면 안 된다는 규칙도 상황에 따라서는 수동태가 적절한 경우가 있는데 스타일 가이드에서는 이런 점을 언급하고 있지는 않습니다. 보통은 수동태 예시를 보여주고 이걸 능동태로 바꾸어버리죠. 결론은 스타일 가이드라는 틀에 너무 갇혀 있지 말고 좀 더 깊은 지식을 기반으로 이해하고 사용하자는 것.. 지메일에서 발견한 신기한 기능 메일을 작성하다가 빨간 줄이 그어지길래 뭐 오타구나하고 보았는데 아무리 봐도 오타가 아니더라구요. 지메일에서 추천하는 텍스트가 뭐야 하고 보니 괄호 안에 나열된 항목이 중복되었다는 것이었습니다. 입력한 텍스트는 minheight, maxwidth, minheight 였는데 마지막에는 maxheight를 쓰려는 것을 잘못 쓴 것이었죠. 일반적으로 오타만 확인하는 것이라면 마지막 단어를 체크하지 못할 텐데 지메일은 괄호 안에는 어떤 목록을 나열하려는 의도라는 것을 파악하고 중복된 항목이 없거나 패턴에 따라 다음 단어의 순서를 예측하는 것 같습니다. 근데 똑같은 단어를 메일 쓰기를 열어 그냥 입력하면 이런 추천이 나오지 않습니다. 단순히 괄호만 보는 건 아닌것 같구요. 본문의 전체 맥락을 확인하고 리뷰를 하.. WTD 애틀랜틱 2024 - 테크니컬 라이팅을 처음 접하는 이들을 위한 가이드 테크니컬 라이팅을 처음 접하는 이들을 위한 강의입니다. WTD 세션으로 적절한지는 모르겠네요(아마 대부분 비용을 들여 이 행사에 참여하는 분들은 테크니컬 라이팅이 뭔지 어느 정도는 알고 있으니깐요). 그럼에도 영상을 통해 접하는 분들이 있다면 의미가 있겠네요. 많은 오해 중 하나가 테크니컬 라이터는 글만 쓰는 것이라고 오해를 합니다. 하지만 테크니컬 라이팅을 테크니컬 커뮤니케이션이라고도 하는 것처럼 골방에서 글만 쓰는 것은 아닙니다. 개발자나 관련 담당자들과 끊임없이 커뮤니케이션을 해야 합니다(그렇다고 직접적으로 대화를 해야 한다는 것은 아닙니다. 이메일이나 메신저 같은 수단 또는 문서 그 자체로도 커뮤니케이션을 진행할 수는 있습니다). 여러 팀과의 협업을 이야기하면서 상당 부분 너무나 협조적인 동료가 .. WTD 애틀랜틱 2024 - UX팀과 같이 일하기 아웃시스템즈(OutSystems)에서 콘텐츠 개발자로 일하는 2명의 발표자가 함께 합니다. 한 명은 인도, 한 명은 스페인에서 일하고 있습니다. 2021년까지 아웃시스템즈의 문서화는 신규 기능이 나오면 이를 정리하고 문서화했습니다. 전체적인 개요에 대한 정리가 필요했지만 신규 기능을 다루는 것만으로도 벅찬 상태였습니다. 때문에 사용자들은 개별적인 기능은 알 수 있었지만 자신의 목표를 적절한 방법으로 달성하는 정보를 넓은 시각에서 바라볼 수 없었습니다. 그래서 콘텐츠팀에서는 점진적으로 문서를 사용자 중심으로 개선할 계획을 세우고 이를 진행했습니다. 문서화 계획을 세우고 진행하는 과정은 일반적인 과정과 크게 다르지 않습니다. 콘텐츠를 만드는 과정에서 UX팀과 협력해 각 과업마다 user journey를 만들.. RDB와 NoSQL 이야기 옛날 옛적, 데이터 마을에는 두 명의 강력한 수호자가 살고 있었습니다. 그들의 이름은 RDB와 NoSQL이었죠. 이 둘은 모두 왕국의 데이터를 안전하게 지키고 관리하는 임무를 맡고 있었지만, 서로 다른 방식으로 일을 처리했습니다. RDB는 질서를 사랑하는 수호자였습니다. 그는 모든 것을 깔끔하게 정리하는 것을 좋아했죠. "모든 데이터는 정확한 자리에 있어야 해!"라고 말하곤 했습니다. 그의 세계관에서는 모든 것이 표로 나뉘어 있었고, 각 데이터는 미리 정해진 규칙에 따라 저장되었습니다. "이건 엄격한 규칙이지만, 그래야만 모든 것이 완벽하게 맞아떨어지지!" RDB는 항상 이렇게 말하며, 데이터를 정확하게 관리했습니다. 그는 데이터를 서로 연결하고, 복잡한 관계를 만들어내는 데도 능숙했죠. 그래서 사람들이.. JSON(제이슨)과 XML(엑스엠엘) 이야기 옛날 옛적, 데이터 마을에는 두 명의 정보 배달원이 살고 있었어요. 그들의 이름은 JSON(제이슨)과 XML(엑스엠엘)이었죠. 마을의 모든 사람들이 정보를 주고받을 때, 이 두 친구는 그 정보를 정확하고 안전하게 전달하는 중요한 역할을 맡았습니다. 정보 배달원으로서 그들은 사람들 사이에서 데이터를 전달하는 일을 했어요. 하지만 그들이 일을 처리하는 방식은 조금 달랐죠. 제이슨은 매우 빠르고 간결한 배달원이에요. 그는 항상 가벼운 가방을 들고 다니며, 필요한 정보만 딱딱 정리해서 전달했어요. 정보를 전달하면서 불필요한 설명이 없었고, 누구나 쉽게 이해할 수 있는 방식으로 정보를 전했죠. 그는 "최대한 간단하게!"라는 철학을 가지고 있었어요. 덕분에 사람들은 그가 전해주는 정보를 빠르게 받아보고 처리할 수 .. WTD 애틀랜틱 2024 - 사용자 온보딩을 테크니컬 라이터가 주도하기 이번 세션에서 설명하는 온보딩은 신규 입사자가 아니라 고객 대상입니다 고객이 새로운 제품에 안정적으로 안착하고 그들의 목표를 달성할 수 있게 도와주는 과정에 대한 이야기입니다. 온보딩을 설명하는 단계는 여러 가지가 있지만 조직에 따라 적절하게 어느 단계에 들어가서(승차) 어느 단계에 나와야 하는지(하차) 명확하게 알아야 합니다. 온보딩은 실제 회사의 수익과 연결이 되는데 테크니컬 라이터가 잘할 수 있는 점을 활용해서 온보딩 프로세스의 주도권을 가지게 되면 테크니컬 라이터가 단지 제품의 부가적인 지원이 아니라 핵심적인 수익이 될 수 있습니다(최근 커뮤니티에 테크니컬 라이터 Role이 사라져서 일자리를 잃었다는 소식이 많은데 대부분 그들의 일이 회사의 수익과 연결된다는 것을 증명하지 못해서 그런 것일 수 있.. 이전 1 2 3 4 ··· 45 다음
