最初にリリースするか、最初にドキュメントを作成しますか？

私は数年前からプロジェクトに取り組んでおり、まともなユーザーベースを集め始めています。いくつかの基本的なドキュメントを含むプロジェクトページを作成しましたが、現時点ではFAQにすぎません。新しいユーザーとパワーユーザーの両方にとってより有益になるように改善する必要があることを知っています。そして、それは次のリリースのToDoリストにあります。

ただし、次のリリースには、ユーザーベースが取得したい機能があります。今すぐリリースする準備ができており、パッケージ化されており、すぐに使用できます。適切な配布サービスに展開するだけです。

ポイントへ。この機能はユーザーにとって重要ですが、ドキュメントは私にとって重要です。ドキュメントを書き直すまでリリースを待つべきですか？私の現在のユーザーベースは、新機能の使用方法を理解するのに十分な知識を持っているので、心配していることではありません。このプロジェクトに取り組む自由な時間は限られているため、ドキュメントを完成させるのに数週間かかる場合がありますが、もう待つようにするとコミュニティは唾を吐きます。

このシナリオで顧客は正しいですか？新規ユーザー向けの堅牢なドキュメントよりも、既存のユーザー向けの素晴らしい単純な機能を優先すべきでしょうか？

更新：うわー、非常に多くの素晴らしい、高品質の応答！プロジェクトとそのユーザーの両方をどのようにやり取りし、サポートする必要があるかについて、あなたが本当に助けてくれました。感謝万円！

シンプル：ベータ版をリリース！次に、ドキュメントが完成したら、新しいバージョンの最終リリースを行います。

新しいものを試してみたいユーザーがいる場合は、ぜひ利用してください。バグレポートを入手できます。おそらく、難しい点に関するコミュニティからの質問があるので、ドキュメントに集中する場所などがわかります。また、ユーザーのフィードバックに基づいて、ドキュメントに影響する可能性のあるものを微調整することもできます。

基本的に、誰もが勝ちます。

早期リリースを行わない理由の1つは、ユーザーが「ベータ版」を受け入れないと思う場合は、それを行うことについてもう一度考えるべきであるが、あなたが書いていることを考えれば、彼らはそれについて満足しているように聞こえるということです。

もう1つの理由は、使用するリリースチャネルを使用してベータリリースを行うことについて技術的な問題がある場合です。そうすれば、ベータ版と最終版を別々にリリースするよりも面倒かもしれません。あなたのソフトウェアが完全だと思うなら、この場合、私は早期リリースに頼り、それが終わったらドキュメントを更新します。そうしないと、ドキュメントが遅れてしまい、リリース全体が遅れたり、最終的なドキュメントがなくてもリリースされてしまうリスクがあるので、今すぐやってください。

私は右のあなたを得た場合、あなたはあなたにこのプロジェクトをやっているの自由時間とのためにお金がありません。このような場合は、気分が良くなるようにしてください（ユーザーが待って、時間を記録してください）。「ユーザー」からのプレッシャーを感じてはいけません。多くの人々がこれについてインターネット上で書いています（圧力を感じたFLOSSの大著者と貢献者）。

ただし、支払いを受けている場合、または何らかの利益を得ている場合は、ユーザーが望むことを実行してください。これは、顧客やユーザーにとって最善のことを行うことを意味し、その場合は、それをリリースして、時間通りに文書化します。あなたは彼らが彼らの方法を見つけるだろうと言ったので、それは大したことではないはずです。

一般に、ドキュメントには2つのタイプがあります。コード（クラス、ユニットなど）をドキュメント化する技術と、コードおよびユーザードキュメントでの新機能の動作と実装方法です。IMO、特にソフトウェア開発がフルタイムの仕事ではない場合、技術文書は必須です。私はこれに多くの時間を費やします。なぜなら、人生のコミットメントのためにコードを書くのに大きなギャップ期間があるかもしれないからです。

ユーザーのドキュメントは持っておくのが良いですが、必須ではありません。もちろん、それはアプリケーションの複雑さ、議論の対象分野でのコンピューターとシステムの使用に関するユーザーベースの熟知に依存します-あなたの場合、顧客は新機能がどのように機能するかを把握できるようです。優れたユーザーエクスペリエンスと優れたユーザーインターフェイスで最小限のユーザードキュメントが必要であると主張する考え方があります。

また、時間に限りがあり、提案どおりにドキュメントを作成する必要があると感じている場合は、新しい機能のみを紹介する短いビデオをいくつか作成できます。これにより、実際のドキュメントを作成する時間がいくらかかかり、重要性の低い詳細を入力できます。

マーケティングのヒントによっては、ユーザーの期待とバランスを取りながらブランドを高めることができます。アプリケーションの種類とこれまでに作成したワークフローに本当に依存しますが、新しいバージョンへのようこそ画面があり、アプリケーション内でリンクを提供するか、アプリ内でビデオを再生することでビデオを表示できます。

この特定の例だけでなく、一般的なワークフローのために何かを追加するだけです：

ドキュメントはあなたかもしれませんが、definition of doneほとんどの場合、ドキュメントは最小限の実行可能な製品（MVP）を超えています。

顧客は常に正しいだけではありません。商用製品である場合、リリースは多くのビジネス価値がある可能性があり、絶対的な優先事項です。

所有者はビジネス価値を定義します（これはあなたの考えです）、顧客にとって製品としてもっと価値があるものは何ですか？

また、ドキュメントなしでリリースされるリスクはありますか？

たとえば、競争。競争があなたの前にこのスーパー機能をリリースする場合、あなたはただいくつかのユーザーを失うかもしれません。

これらの質問を自分自身または製品所有者に尋ねると、答えは明確になります。

新機能は、古いユーザーを幸せにします。適切なドキュメントは新しいユーザーを招待します。どちらに集中すべきかは、どちらがより必要かによって異なります。あなたは、新しい機能が待つことができるように、ユーザーベースが健全であることを示しました。古いユーザーとして言えば、私も良いドキュメントが好きです。オープンソースの良いところ：古いユーザーは独自の機能を追加します。

あなたはあなたの質問で明確にしておらず、おそらくあなたのユーザーにこれらの選択の結果を明確にしていないでしょう。ユーザーサポートに費やす時間はどれくらいですか？追加のドキュメントは、サポートに費やす時間を減らしたり、売り上げを増やしたりしますか？ドキュメンテーションを行うことの利点は何ですか？

ユーザーはドキュメントよりも新しい機能を求めていますが、サポートを提供したり、バグを修正したり、パッチをリリースしたりするために可用性が低下する可能性があることを認識していますか？

質問を記載したメールを送信するだけで指示を読みたくない場合、新しい機能に関するドキュメントが必要になるのはなぜですか？

パッケージをリリースする準備ができたら、顧客/クライアントにリリースし、ドキュメントの作業を開始します。展開された機能を理解するのに役立つドキュメントを共有する場合、クライアントとの通信が良好です。