먼저 릴리스하거나 문서를 먼저?

나는 몇 년 동안 프로젝트를 진행해 왔으며 적절한 사용자 기반을 모으기 시작했습니다. 기본 문서로 프로젝트 페이지를 만들었지 만 실제로는 FAQ가 아닙니다. 나는 새로운 사용자와 고급 사용자 모두에게 더 유익한 정보를 제공하기 위해 개선해야한다는 것을 알고 있으며 다음 릴리스의 할 일 목록에 있습니다.

그러나 다음 릴리스에는 사용자층이 염려하는 기능이 있습니다. 지금 당장 출시 할 준비가 되었으니 포장되어 준비가되었습니다. 적절한 배포 서비스에 배포하면됩니다.

요점. 이 기능은 사용자에게는 중요하지만 설명서는 중요합니다. 설명서를 다시 작성할 때까지 릴리스를 기다려야합니까? 현재 사용자층은 새로운 기능을 사용하는 방법을 이해할만큼 정통하므로 걱정하지 않아도됩니다. 이 프로젝트에 참여할 수있는 자유 시간이 제한 되었기 때문에 문서를 완성하는 데 몇 주가 걸릴 수 있지만 더 이상 기다리게하면 커뮤니티에서 침을 뱉을 것입니다.

이 시나리오에서 고객이 맞습니까? 기존 사용자를위한 환상적이고 간단한 기능이 새로운 사용자를위한 강력한 문서보다 우선해야합니까?

업데이트 : 와우, 많은 훌륭한 고품질 응답! 프로젝트와 사용자를 어떻게 상호 작용하고 지원해야하는지 더 잘 이해하도록 도와 주셨습니다. 정말 고마워!

단순 : 베타 버전을 출시하십시오! 그런 다음 문서화가 완료되면 새 버전의 최종 릴리스를 수행하십시오.

사용자가 새로운 것을 시도 할 의향이 있다면 반드시 그것을 활용하십시오. 버그 리포트를 받고, 어려운 점에 대한 커뮤니티 질문을받을 수 있으므로 문서 등에 집중해야 할 위치를 알 수 있습니다. 사용자 피드백을 기반으로 문서에 영향을 줄 수있는 몇 가지 사항을 조정할 수도 있습니다.

기본적으로 모두가 이깁니다.

초기 릴리스를 수행하지 않는 한 가지 이유는 사용자가 "베타 버전"을 받아들이지 않을 것이라고 생각하는 경우이를 수행하는 것에 대해 두 번 생각해야하지만 자신이 작성하는 내용에 따라 만족할 것 같습니다.

사용하는 릴리스 채널을 사용하여 베타 릴리스를 수행하는 데 기술적 인 어려움이 있다면 또 다른 이유가 있습니다. 그렇다면 별도의 베타 및 최종 릴리스를 수행하는 것보다 훨씬 번거로울 수 있습니다. 소프트웨어가 완벽하다고 생각되면이 경우 초기 릴리스에 의존하고 완료되면 문서를 업데이트하십시오. 그렇지 않으면 문서가 지연 될 수 있으며 전체 릴리스가 지연되거나 최종 문서없이 릴리스가 될 수 있으므로 지금 바로 수행하십시오.

내가 바로 당신이있어 경우에, 당신은 당신에이 프로젝트를하고있는 자유 시간 및 위해 돈 . 이런 경우에는 기분이 나아지도록하십시오 (사용자는 기다립니다, 시간을 문서화하십시오). "사용자"로부터 압력을 느끼지 않아야합니다. 많은 사람들이 인터넷에 대해 글을 썼습니다 (큰 FLOSS 작가와 압력을 느낀 기고자).

그러나 돈을 받거나 혜택을 얻는다면 사용자가 원하는 것을하십시오. 즉 , 고객 이나 사용자 에게 가장 적합한 모든 것을 수행해야 합니다.이 경우에는 즉시 릴리스하고 문서화하십시오. 당신은 그들이 길을 찾겠다 고 말 했으므로 큰 일이 아닙니다.

일반적으로 두 가지 유형의 문서가 있습니다. 코드 (클래스, 단위 등)를 문서화하는 기술과 코드 및 사용자 문서에서 새로운 기능이 작동하고 구현되는 방식입니다. IMO, 기술 문서 는 소프트웨어 개발이 정규직이 아닌 경우에 반드시 필요합니다 . 인생에 대한 약속으로 인해 코드 작성 시간이 크게 간격을두기 때문에 많은 시간을 할애합니다.

사용자 설명서는 가지고 있지만 꼭 필요한 것은 아닙니다. 물론 응용 프로그램의 복잡성, 토론중인 주제 영역의 컴퓨터 및 시스템 사용에 대한 사용자의 친숙성에 따라 달라집니다. 귀하의 경우 고객이 새로운 기능의 작동 방식을 파악할 수있는 것처럼 보입니다. 좋은 사용자 경험과 우수한 사용자 인터페이스는 최소한의 사용자 문서가 필요하다고 주장하는 학교가 있습니다.

또한 시간이 제한되어 있고 제안한대로 설명서를 작성해야하는 부담이 있다면 새로운 기능 만 소개하는 짧은 비디오 몇 개를 만들 수 있습니다. 이렇게하면 실제 문서를 작성하는 데 시간이 걸리고 덜 중요한 세부 정보를 채울 수 있습니다.

일부 마케팅 팁을 통해 사용자 기대의 균형을 유지하면서 브랜드를 향상시킬 수 있습니다. 실제로는 응용 프로그램 유형과 지금까지 만든 워크 플로에 따라 다르지만 새 버전에 대한 시작 화면이있을 수 있으며 응용 프로그램 내에서 링크를 제공하거나 앱 내부의 비디오를 재생하여 비디오를 표시 할 수 있습니다.

이 특정 예제뿐만 아니라 일반적인 작업 과정을 위해 무언가를 추가하십시오.

문서가 귀하의 것일 수도 definition of done있지만, 문서는 대부분 MVP (Minimable Viable Product)를 넘어서는 시간 입니다.

고객이 항상 옳을뿐만 아니라 상용 제품인 경우 릴리스는 비즈니스 가치가 높을 수 있으며 절대 우선 순위입니다.

소유자는 비즈니스 가치 (당신이 생각하는 것)를 정의하므로 고객을위한 제품으로 더 가치있는 것은 무엇입니까?

또한 문서없이 배포 할 위험이 있습니까?

예를 들어 경쟁 ; 경쟁 업체가이 기능을 출시하기 전에 일부 사용자를 잃을 수도 있습니다.

본인이나 제품 소유자에게 이러한 질문을하면 답변이 명확 해집니다.

새로운 기능은 기존 사용자를 행복하게합니다. 좋은 문서는 새로운 사용자를 초대합니다. 집중해야 할 대상은 더 필요한 대상에 따라 다릅니다. 새로운 기능이 대기 할 수 있도록 사용자 기반이 정상임을 표시했습니다. 오래된 사용자라고 말하면 좋은 문서도 좋아합니다. 오픈 소스에 대한 좋은 점 : 오래된 사용자는 자신의 기능을 추가합니다.

귀하는 귀하의 질문에 명확하게 설명하지 않았으며 사용자에게 이러한 선택의 결과에 대해 설명하지 않았습니다. 사용자 지원에 시간이 얼마나 걸립니까? 추가 문서를 통해 지원 또는 판매 증가에 소요되는 시간이 줄어 듭니까? 문서를 작성하면 어떤 이점이 있습니까?

사용자는 설명서보다 새로운 기능을 원하지만 지원 제공, 버그 수정, 패치 릴리스 등의 가용성이 떨어질 수 있다는 것을 알고 있습니까?

내가해야 할 때 지침을 읽지 않아도된다면 내 질문과 함께 이메일을 보내면됩니다. 왜 새로운 기능에 대한 문서를 원합니까?

패키지를 릴리스 할 준비가되면 고객 / 클라이언트에게 릴리스하고 문서 작업을 시작하십시오. 배포 된 기능을 이해하는 데 도움이되는 설명서를 공유 할 때 클라이언트와 통신하는 것이 좋습니다.