Developers love creating software. They look forward to opening their editors and churning out new features. But before that first line of code can be written on a new project somebody has to decide what software should do.
A clearly defined road map for what software should do will help make the most of everyone’s time and efforts over the lifetime of a project. The tricky part is crafting the right road map for your project.
Documentation is the old standby. Does anybody read it? Meetings can be helpful. Do the hours spent really improve the product? Prototypes look like rapid progress. Are the subject experts able to make any sense of mockups?
This post is the first in a series on how development teams can better collaborate with their business counterparts to capture what software should do. This first post focuses on why road maps are so important. Another will dive deeper into different approaches for capturing requirements in a meaningful way. And a later post will look at taking that leap from a road map into construction.
Making something out of nothing
A blank page can be a frightening prospect. Even when a team is upgrading an existing application, it can be intimidating to define what screens and what features are needed to launch.
At the very beginning of the requirements gathering process it’s best not to think about software at all. Instead, the focus should be on what users need to accomplish. Project members should spend time mapping out the goals and habits of the people who will use the new software.
If a team is developing an application for a company then they can spend time observing the day to day tasks of the people who work there. If they’re developing a product for the web then they should spend time talking with people likely to use the application. They should find out what tasks people are doing now in some other way. It’s a good idea to ask these future users what tools they think would improve their lives.
It sounds like a simple thing. But listening to users is a step that we often skip. It should always be our first step.
Communicate, rinse, repeat
Often the developers writing software aren’t experts in the subject matter behind a project. Software teams rely heavily on point people with business knowledge to help them build useful tools. It’s important that developers establish a collaborative relationship with the subject experts from the very beginning.
There will always be a period of requirements gathering at the beginning of a project. Collaboration shouldn’t end once developers start writing code. Business point people need to remain engaged with the development team throughout the life of a project. Keeping them connected as the project progresses is the best way to ensure the project remains true to the road map.
When subject experts and developers collaborate the road map becomes a living document. The teams’ working relationship will make it easier to make adjustments as issues arise. This will save on many headaches on the way to launch time.
Capturing the magic
Ideas can be magical. But putting ideas into action is where the real magic happens. And putting ideas into action will be much easier if everyone agrees on what software should do up front.
That still leaves the question of how to go about capturing those requirements. It’s not enough to jot down some ideas and move on to coding. It’s important to think about how the requirements will be used throughout the life cycle of the project. The content is fresh in everyone’s head when they start. Three months from now they’ll have to refer back to those notes. Will they still make sense?
Ideally a team should use tools that allow everyone: developers, subject experts, managers, and maybe even some users, to have a window into the project as it evolves. Nothing communicates the progress of a project better than tracking work as it moves along for all to see. Online tools such as wiki’s and other collaboration services can become a natural part of both the requirements and the development processes.
In the next post of this series we’ll take a closer look at some of the online tools and processes that your team can use to capture project requirements.