ビジョンドキュメントの重要性とそれが開発にどのように役立つか
私は単独で作業する開発者です。最近、正式に何も必要としなくても、どのような種類のドキュメントでも引き続き利益を得ることができるか探していますが、今でも執筆することを強くお勧めする1つのドキュメントはプロジェクトです。ビジョンドキュメント。
私はそれを解決する必要がある問題、それをどのように解決するか、およびエンドユーザーがソリューションからどのように恩恵を受けるかを含む短いドキュメント（1ページまたは2、3ページ））として記述されていることを発見しました。
さらに読むと、このドキュメントは要件を発見し、最終的にユーザーストーリーを完成させるための1つの非常に重要な入力のようです。
その場合、私が理解しているように、これは最初のステップであることを考慮して、ソフトウェアの構築を開始するとき、このドキュメントの重要性は何であり、開発に役立つようにどのように使用されますか？
そのような単純で短いドキュメントがどれほど重要であり、それほど役立つかはまだわかりません。
このドキュメントはどのように重要であり、開発プロセスを支援するためにどのように使用されますか？特に、要件収集プロセスにおけるこのドキュメントの役割は何ですか？
あなたが一人で作業していることを考えると、ビジョンドキュメントはほとんどがコミュニケーションツールであるため、ほとんどの場合よりも役に立たないでしょう。ただし、より重要なのは、ビジョンドキュメントは参照ポイントであり、これを振り返って、努力が適切な場所に進んでいるかどうかを判断できるものです。
一人の開発者であっても、私たちは設計上の決定について2つの考えを持つことができます。あるいは、時間とともに考えを変えることができます。 元のビジョンを信頼するが役立つかもしれません。ツールの焦点が「マルチプラットフォーム」になることになっているが、ソリューションを急いでいるためにプラットフォーム固有のコードを使用することに夢中になっていることに気付いた場合は、ドキュメントを見直して、元のアイデアと方法を思い出してください。考えること。それはあなたが優先するのを助けることができます。
ビジョンドキュメントは、仲間の愛好家、友人、および将来的にプロジェクトが聴衆または他の利害関係者を含むように成長する場合に、自分が何を作っているかを他の人と伝えるのにも役立ちます。
それはあなたに正しい質問のすべてについて考えることを強制します：なぜ、どのようにそして何。個人的には、ビジョンドキュメントから行を引用するだけなので、ビジョンドキュメントを書いた後に「エレベーターピッチ」を暗唱する方がはるかに簡単だとわかりました。
ビジョンドキュメントは、製品の将来がどうあるべきかを関係者がどのように見ているかを説明しています。
ビジョンドキュメントの目標は、製品の開発に携わるすべての人が、製品を取り入れる方向に焦点を合わせ続けることです。
ビジョンドキュメントがないと、さまざまな利害関係者/部門が開発を独自の方向に向けようとする可能性が高く、開発者は多数の矛盾する要件に巻き込まれます。
ビジョンドキュメントがある場合は、「このビジョンドキュメントはすべての利害関係者が合意した方向であり、新しい要件はそれから逸脱しています。新しいビジョンまでそれらを考慮することはできません。合意されている。」
ビジョンドキュメントのメリットは、主に利害関係者とのコミュニケーションの手段と考えています。紙にアイデアをもたらし、製品を作成するためのベースとして機能します。それは確かに開発者によって書かれたドキュメントではなく、むしろ製品マネージャーです。
他の人がすでに指摘したように、このドキュメントは順調に進むのに役立ちます。要件を導出するときに参照できます。
孤独な開発者としてプロジェクトに集中し続けるのは難しい場合があります。あなたが最終的に責任を負うので、変更を加えたり、物事を追加したりする場合、多くの場合、あなたを止める方法に誰もいません。
このドキュメントがあれば、目的を正式にして、計画に固執するためのツールとして使用できます。または、少なくとも計画を変更する場合は、ドキュメントを変更して新しい焦点を示します。
最大の部分はユーザーにとってのメリットです。これが決定されず、ドキュメントに入力されただけではアプリがいくつ作成されるのか、驚くでしょう。それは「あなたがそれを構築すれば、彼らは来る」という考え方です。このドキュメントを作成できない場合は、このプロジェクトを開始しないでください。
最初から入り込まずに済むかもしれない唯一の部分は、それをどのように構築するかということです。これは、少し調査と実験を行った後、少し後で発生する可能性がありますが、特定して決定したら、それを文書化して把握してください。
これは、自分にプッシュバックをかけ、誰も望まない機能をたくさん追加しないようにするための素晴らしい方法です。他の誰かがあなたにこれをするのは十分に悪いことです。自分でしないでください。
ドキュメントは、プロジェクトの重要な部分です。
それは私たちがすべてを一元化するのに役立ち、議論しながら、ドキュメントを参照して中心的なことについて話すことができます。
簡単な例として、ほとんどのクライアントは一般的な要件を備えています。
- ある場所で彼らはライオンを見せてそれを好きになり、今それを調べてから、私たちは1匹の動物を作りたいと結論付けました。
- それから彼は私が4本の足、1本の鼻、2本の目などで1匹の動物を作りたいという要件を持ってくるでしょう
- 話し合うと、明確な要件が得られ、クライアントは4本足の象などを望んでいるという結論に達しました。
- 要件を取得して開発を開始し、納品すると、彼は私にこれを作成したくないと言いました。その後、あなたは私が4本足の動物を作成したと主張し、それが続きます。
この例が気に入らない場合は申し訳ありませんが、伝えたいことが明確になることを願っています。
代わりに、それについて話し合うことができるすべてを文書化した場合、それについてブレインストーミングを行うと、その時点で物事は明確になります。
変化はないとは言いませんが、少なくとも80％は明確になると言えます。
参考までに、ビジョンドキュメントを作成する際に考慮すべきことについて考えています。
ソフトウェア/製品を開発しているときはいつでも、この3つの基本的な質問をしようとします。
- なぜクライアントは彼らが解決しようとした特定の問題を望んでいるのですか？
- どのクライアントが欲しいのか、ここでは、なぜクライアントをブレーンストーミングして、システムから回答を得ようとするクライアントの質問を準備できますか？ 3私たちがどのように提供できるか、あなたは基本的なワイヤーフレームとフローを行い、それらに見せることができますか？
また、問題と解決策について考え、アイデアをクリアすることも必要になります。
これに関するあなたのフィードバックを教えてください。