As a project manager, you have to get the requirements for the project. You can get them in various ways, but they all are a little complicated. You can gather candidate requirements by interviewing and reviewing other products, but this could be like trying to talk with the Ocean. They think they know what they want and you think you understand them, but you have to be very careful so you can take the useful information.
Specifying requirements, or commiting with the gathered requirements to tangible media, like storyboards, this could be like talking to Mini-Maui, he is pretty expresive, and he can write and store all the information from his adventures. Finally, you can analize requirements, or breaking them to their essential characteristics.
So, what's the best way to get all the requirements?
- Identify a set of key end users or defining who wil be using the system. You don't want an accelerometer on an app that will help you to cook on your house, or you wouldn't like to take a boat all by yourself if you do not know how to sail. Oh Wait.
- Interview the End Users, or actually make a first round of interviews. So you can see what is happening with your users. What do they think about it.
- Build a prototype, but it has to be a simple one. You don't have to be such a perfectionist. It just has to have the basic functionalities. It is very useful to record the results on paper, using storyboards and check the level of excitement of the users when the test comes to an end. Do you remember how excited was Maui when Moana learned how to sail? You have to wait and see if your prototype is actually working.
- Develop a style guide, after you have a functional prototype, you can start thinking on making the application cute. The grandma didn't make the necklace without having the heart of Te-Fiti. The guide shouldn't be very long, but it can help the designers to follow basic rules.
- Fully extend the prototype, this is the stage where you try to make everything better. the graphs, architecture and design work, interactions with other products, textual outputs, feasibilitiy study, architecture, etc. Don't forget this is not the final prototype!
- Treat the fully extended prototype as the baseline specification. Oce we have a baseline prototype, we can have valuable benefits, these activities often end up on the critical path, so it is pretty important to identify them from the beginning.
- Write a detailed end-user documentation based on a prototype. On average, Moana would leave the story-telling until the end of her adventure, but it is important to have it from day one.
- Create a separate, non-user interface requirements document. Wow, those are fancy words to say "create a manual". Maybe we as millenials don't appreciate manuals but they a re pretty useful when you get presented with a scenario that the user is not familiar with,
There you go adventurer! Now you are ready to go and find Te Fiti!
No hay comentarios.:
Publicar un comentario