SaaS
두 주마다 출시하고 일 년에 두 번 글을 써요
소프트웨어 팀에는 쓸 이야기가 부족하지 않아요. 부족한 건 그 이야기를 쓰는 사람이에요. 글쓰기는 항상 릴리스가 늦어질 때 밀려나는 업무이고, 매번 밀려나서, 블로그의 최신 글이 열한 달 전의 "소개합니다" 글이 될 때까지요.
실패는 구조적인 문제지, 편집의 문제가 아니에요
모든 팀이 더 써야 한다는 걸 알아요. 엔지니어도 쓸 수 있고, 창업자도 쓸 수 있고, 보통 누군가는 즐기기도 해요. 문제는 글쓰기에는 자체 마감이 없다는 것이고, 마감 없는 일은 마감 있는 일에게 항상 지는데, 두 주마다, 영원히요.
계획이 빠진 마감을 채워 줘요. 테마와 작가가 붙은 날짜가 정해진 슬롯은 한가한 주에 한 약속이고, 한가하지 않은 주에 적용되며, 아무도 기억하지 못했어도 초안이 나타나요. 승인은 몇 분이면 되지만, 아무것도 없이 쓰는 건 영원히 오지 않는 오후가 필요해요.
그게 논거의 전부예요. 모델이 여러분 팀보다 잘 쓰는 게 아니에요 — 그렇지 않아요. 화요일에 여러분이 편집한 초안은 존재하고, 쓰려고 했던 글은 존재하지 않는다는 것뿐이에요.
로드맵은 이미 여러분이 쓴 계획이에요
여섯 달의 대부분은 이미 정해져 있어요. 다음 두 분기에 대략 무엇이 출시되는지, 제품의 어떤 부분이 오해받는지, 어떤 연동을 계속 요청받는지, 어떤 질문이 매주 지원팀에 들어오는지 알고 있어요.
그 각각이 테마예요. 로드맵이 리듬을 제공해요 — 릴리스 하나가 체인지로그 항목 하나가 아니라 슬롯의 연속이 돼요 — 그리고 지원팀이 상시성 있는 절반을 제공해요. 한 달에 스무 번씩 받는 질문은 한 번 쓰고 영원히 링크할 만한 글이니까요.
빈틈을 남겨 두세요. 릴리스는 밀리는 법이고, 빈 슬롯이 없는 계획은 밀린 릴리스를 아직 존재하지 않는 것에 대한 글 세 편으로 만들어요. 슬롯의 4분의 1을 비워 두는 건 게으름이 아니라, 실제 일정과 부딪혀도 살아남는 계획의 부분이에요.
- 1블로그무엇이 출시됐고 왜 존재하는지. 문제가 먼저, 기능이 다음이에요.
- 2Facebook / Instagram체인지로그를 절대 열지 않을 사람들을 위한 한 문장 버전이에요.
- 3블로그실제로 누군가 어떻게 썼는지. 구체적으로, 어색한 부분까지 그대로 담아서요.
- ·밀리는 경우라면슬롯은 릴리스와 함께 움직여요. 존재하지 않는 것을 알리는 일은 없어요.
- 4블로그이번 릴리스가 마침내 답하는 지원 질문을 한 번만 써두세요.
로드맵이 리듬을 정해요지원이 주제를 정해요
여러분의 체인지로그는 콘텐츠가 아니에요. 영수증이에요.
작가 두 명, 때로는 세 명
제품을 설명하는 사람과 회사에 대해 이야기하는 사람
이 둘은 실제로 다른 목소리예요. 이를 합치면 소프트웨어 블로그 특유의 밋밋함, 즉 기술 설명도 아니고 사람의 이야기도 아닌 글이 나와요.
기술 작가
형용사 없이 정확하게 무엇이 무엇을 하는지 설명해요. 여러분의 제품이 무엇에 쓰이고 무엇에 쓰이지 않는지 알고, 그렇게 말할 수 있어요. 지원 티켓에서 링크되는 글을 쓰는 작가예요.
회사의 목소리
결정, 트레이드오프, 그리고 무엇을 향해 만들어가고 있는지에 대해 써요. 측정하기 어렵지만 채용에서도, 세일즈 콜에서도, 누군가 큰 회사 대신 작은 벤더를 고르는 이유에서도 드러나는 방식으로 유용해요.
답하는 사람
정책에 따라 댓글을 처리해요. 답할 수 있는 것은 답하고, 답할 수 없는 것은 표시하며, 로드맵에 대해 추측하지 않아요. 지원 사안으로 보이는 것은 즉시 사람에게 넘겨요.
승인 단계가 여기서 실제 역할을 해요
베이커리라면 승인되지 않은 글은 작은 창피함이에요. 소프트웨어 회사라면 지원 부담, 세일즈 반론, 아무도 동의하지 않은 약속이 돼요. 제한을 조금 잘못 설명한 초안은 고객에게 그대로 인용당하고, 날짜를 암시하는 초안은 약속으로 취급돼요.
그래서 이것이 오토파일럿에 가장 신중을 기해야 하는 경우예요. 합리적인 방식은 이미 발행된 내용을 다시 전달하는 짧은 소셜 슬롯에는 오토파일럿을 쓰고, 제품에 대한 주장을 담은 모든 것은 승인을 거치는 거예요. 가격, 용량, 날짜에 관한 내용은 영구적으로 사람이 읽어야 하고, 작가의 규칙에 그렇게 적어두면 그런 종류의 초안이 대기열에 들어가는 대신 보류되고 표시돼요.
보고서가 소규모 팀에게 알려주는 것
계획 대비 발행이 중요한 숫자예요. 소프트웨어 팀에게는 보통 첫 분기에 불편한 숫자죠. 그리고 글쓰기가 다시 릴리스에 밀려나는 일이 멈췄는지를 알려주는 유일한 정직한 척도이기도 해요.
반응은 보이는 것만큼 중요하지 않아요. 기술 글은 며칠이 아니라 몇 달에 걸쳐 독자를 찾아가고, 두 번째 주에 판단하면 나중에 효과가 있었을 글을 없애버리게 돼요. 초반에는 주제 균형이 더 유용해요. 출시된 것만 쓰고 있는지 보여주는데, 이것이 전형적인 실패 양상이고 수많은 소프트웨어 블로그가 문단 있는 체인지로그처럼 읽히는 이유예요.
정직하게 말하면: 제품이 진짜 기술적이라면 가장 깊은 글들은 여전히 엔지니어의 오후 반나절이 필요해요. 계획이 바꾸는 것은 그런 시간이 실제로 일정에 잡히고, 나머지 80퍼센트의 글쓰기가 그것과 경쟁하지 않게 된다는 점이에요.