Almost every business owner has heard about the Lean Startup approach and Agile methodologies in today’s world. In essence, they say you need to find your market fit and start getting positive user feedback with your product as quickly as possible.
Adding the frequent need to generate profit before running out of a limited budget, no wonder most entrepreneurs prefer to skip the documentation aspect.
And we at our web application company often hear that you can always write documentation later. That the benefits it brings are important yet not critical. And indeed, if you think about knowledge transfer, better communication, faster troubleshooting, these are all the things that you can pay attention to after the product release.
However, if done well, documentation is about much more important things:
- Documentation brings transparency to all the processes on the project. With it, at any given moment, you can easily find out what is going on, what are current risks and obstacles, what you want to achieve, and so on.
- Documentation helps everybody focus on the same outcome. When you describe a product or service in every little detail, from the hardware compatibility to peak load expectations, it's easy to be sure you'll get what you ask.
- Documentation explains things about your product you would not have thought about otherwise. Reading it, you often get a clear understanding of how your product would behave in certain – especially unexpected or critical – situations. In some sense, with proper documentation, you’ll get more than you could ask for.
- Documentation brings flexibility to managing the project since you always have data to get the performance and SWOT insights and adjust the roadmap.
When combining these advantages, documentation helps you build products/services with less hustle and money while bringing more quality and performance to the outcome.
After years of trial and error, EGO, the web development services company, has come with an optimal documentation approach that allows us to document just enough to deliver the necessary transparency, flexibility, and focus on the outcome. (And even if we notice the docs become a bit excessive, we’ll simplify them, but never remove any previously created data for good, as it might appear useful later.)
Let’s start with the document tree and then describe the three documents you’ll use most often when working with us. We will supplement the descriptions with screenshots from the Confluence project like the one we will create for your product.
Why Confluence? We believe Confluence is the most advanced documentation and collaboration software currently existing. Perfectly integrated with JIRA (an issue tracking solution for developers), it also provides features that cover almost every possible documentation need. Once starting a new project, we can quickly clone a demo space, share it with you and get the documentation framework ready for your project in a matter of minutes.
Next, we’ll focus on Project Plan, Requirements, Project Status Report. Those are the docs our stakeholders use most actively and find most handy in their day-to-day flow:
- the project plan gives an up-to-date overview of the project,
- requirements explain the expected result in the details,
- and status reports help evaluate the health of your project.
A project plan is a page that helps you have all the essential info on your endeavor in one place. That is:
The scope can also contain backlog, a list of tasks that are not in priority right now but should be reviewed and reprioritized later. Having those ideas early helps plan the project’s work and understand how to prepare your product’s code and architecture for future features and extensions.
Milestones, timelines, deadlines, and due dates are defined thanks to our experience in estimating the effort we require to put to perform different app development tasks.
In most of our projects, we leverage the Time And Material model, where you pay for the number of hours our experts spent on building your product or service. Our 15-year experience helps us make initial estimates. But they remain subject to change since, throughout the project, you can decide to change the team’s size, the project’s scope, or other parameters affecting the roadmap timeline.
With a project plan, you can quickly evaluate the current progress on the product and figure out what you should pay attention to next. For instance, if you see that deadlines are broken too often and\or the timeline appears too tight, you might want to review your roadmap or extend your development team.
Having a list of must-have features that is too big might also help you rethink if all of them are required to check your initial hypothesis.
Such an overview also helps clarify whether our partnership brings satisfaction and the project progresses according to your expectations.
Many find this section the most important since the better we describe what you want to get in the end, the happier you'll be with the outcome. That's why our team at the EGO mobile and web development firm pays so much attention to it.
The Requirements section defines:
- Devices, operating systems, and browsers your product or service should run on. We call them targets.
- Functional requirements or the features you want to see implemented in the product.
- Non-functional requirements. That is your expectations on the product’s security, availability, performance, size, and other possible restraints.
- Configuration, like the texts that the product should show in different scenarios or limitation details on the features presented on the product
This section helps you go through every detail of the product you want to build and lets you be sure everybody’s on the same page with what you want to get in the end.
Moreover, when functional requirements are thought-through, the designers can come with the UX and UI that will include the possibility to expand the project’s functionality over time without significant changes.
And with pre-described non-functional requirements, developers can design the product’s architecture that will allow it to scale and get new features without expensive code refactoring later.
So functional requirements docs are important to help you and your team plan every step early and avoid doing extra work later.
Contained in the Management section, Project status reports are generated regularly by project managers to let you evaluate project health. They always include:
A glance at such a report will help you understand if everything is going as it should or your intervention is required.
Progress reports might often have information that will cause you to change your initial plans: mitigate the risks by leveling-up some requirements or change feature priority. Such change requests will be put down into the Change Requests Log and get a separate page with its status, cost, and time we need to address it.
This document organization turns out to be the most comfortable and most effective with our clients. One thing they praise us for most often is the feeling of control we provide with our reports and instructions.
At our custom web development company, we believe it’s because we’ve been focused on the transparency well-design documentation can offer.
And if you want to feel it with your skin, we offer our new clients plans for easy project kick-off. Limited by time and budget, they provide maximum value and great opportunity to test EGO transparent workflow. Check them out at ego-cms.com/plans.