What is the importance of the vision document and how it helps development?

Question

I'm a developer that works alone, and recently, searching for what kinds of documents I still could benefit, even though I don't require anything formal, I've read that one document that still is highly recomended to write is the project vision document.

I found it described as a short document (a page and a half or two) containing what problem has to be solved, how it will be solved and how the end user will benefit from the solution.

Reading more, it seems that this document is one extremely important input to discover the requirements and finaly the user stories.

In that case, considering that this is, as I understood, the first step when starting to build a software, what is the importance of this document, and how is it used so that it helps the development?

I still don't fully get how such a simple and short document can be that important and help that much.

How is this document important and how it is used to help the development process? In particular, what is the role of this document in the requirements gathering process?

Answer 1

Considering you are working alone the vision document would be less useful for you than most as it's mostly a communication tool. More importantly however, the vision document is a reference point, something you can look back to and determine whether or not your efforts are going to the right place.

Even as a solo developer we can be in two minds about design decisions, or change our minds over time. It might be useful to trust your original vision. If your focus for a tool is to be "multi-platform", but you find yourself getting bogged down with using platform specific code because you're rushing solutions, you might look back at the document and remind yourself of your original idea and way of thinking. It can help you prioritise.

The vision document would also help you to communicate with others what it is you are making to fellow enthusiasts, friends and if the project grows in the future to include an audience or other stakeholders.

It forces you to think about all of the right questions: why, how and what. Personally I've found it much easier to recite an "elevator pitch" after writing a vision document, because I just quote lines from the vision document.

Answer 2

The vision document describes how the stakeholders see what the future for the product should be.
The goal of the vision document is to keep everyone who is involved in the development of the product focused on the direction that the product should be taken into.

Without a vision document, the chances are high that different stakeholders/departments will try to steer the development in their own direction, with the developers getting caught in the middle with a bunch of conflicting requirements.
If there is a vision document, then it is easier to say "this vision document is the direction that all stakeholders agreed upon and your new requirements deviate from that. We can't take them into consideration until a new vision is agreed upon."

Answer 3

I see the benefit of the vision document mainly as a means of communication with the stakeholders. It brings an idea on paper and serves as a base to create a product on. It is certainly not a document that is written by the developer but rather the product manager.

As others already pointed out, the document helps you keeping on track. You can refer to it when you derive the requirements.

Answer 4

It can be difficult to stay focused on a project as a lone-developer. You're ultimately in charge, so if you want to make changes or add things, often there is no one in the way to stop you.

Having this document should help you formalize your objective and use it as a tool to stick to the plan. Or at least if you change the plan, you change the document to show your new focus.

The biggest part will be the benefit to the user. You would be surprised how many apps get created where this isn't determined let alone put into a document. It's the "if you build it, they will come" mentality. If you can't write this document, don't start on this project.

The only part you may get away with not entering in the very beginning is the "how" you're going to build it part. This may come a little later after you've done some research and experimentation, but once you've identified and decided that, get it documented and hold yourself to it.

It's a great way to have some push-back on yourself and prevent you from adding a bunch of features no one wants. It's bad enough when someone else does this to you. Don't do it to yourself.

Answer 5

Documentation is an essential part of any project.

It will help us to centralize everything and while discussion, we can talk about central thing with reference of the document.

Simple example, Most clients will come with generic requirements.

• At one place they show Lion and like it, now they research it and then conclude that we want to create one animal.
• then he will be coming with the requirement that I want to create one animal with four legs, one nose, two eyes etc etc
• while discussing, you got the clear requirement and you came out to the conclusion that client wants Elephant with four legs etc.
• you got the requirement and started development and deliver then he told no I don't want to create this and then you argue that I have created animal with four legs and then it goes on.

Sorry if you don't like this example but hope it will give clarity about what I want to convey.

Instead, if we have documented everything we can have a discussion on it, brainstorm around it and things will be clear at that time.

I don't say there is no change but at least I can say 80% things will be clear.

For reference, I am just giving my thought on things to consider while creating vision doc.

Whenever you are developing any software/product, trying to give this three basic questions.

1. Why client want, which specific problems they tried to solve?
2. What client want, here you can brainstorm on Why part and prepare questions which client is going to get an answer from the system? 3 How we can deliver, you can do basic wireframes and flow and show to them?

It will also force you to think on the problem and solution and Clear your ideas.

Let me know your feedback on this.