Unfortunately this is not a perfect world, so we end us with developers and clients going back and forth trying to arrive at the same destination. It can really help things move more smoothly if you have a very specific scope to start with (especially when you are building it yourself). Also, code, like art, is never truly finished, and as a result we will always have bugs. Now, unless you are interested in hiring a QA firm, you will probably be doing you bug checking yourself. So here are some tips to help you with the process of scoping a project and bug tracking it. These may seem extremely obvious to many, but it wouldn’t hurt to make sure you’re doing some of these things.
Scoping:
1. When you’re building a project, it’s a good idea to have a nice paragraph or two explaining why you are building the thing. Understanding the motivation behind an application can help a developer choose a certain route to take in building it.
2. Build a skeleton version of what you’re going to have made. Discuss the main parts of the system and use the SAME name for the SAME part consistently. E.g.:
a. A website that allows people to register for free tickets to concerts
b. Consisting of:
i. A homepage
ii. A registration page
iii. A profile editing page
iv. An About Us page
v. A Contact Us Page
c. An administrative end to edit the content of the home page and the about us page, as well as enter new concerts.
d. Logic that will match people by their zip code to the category of concerts they enjoy.
3. Imagine that this is your table of contents now. Each of those sections should have its own paragraph describing (in plain English) what the intention of the section is and anything specific the programmer should know.
4. Make a flow diagram! Flow charts help people like us see how the process should work. If you are lucky enough to be a Mac user, I highly recommend Omnigraffle for making flows, and if you’re a Microsoft user, Visio is pretty good as well.
5. Don’t be afraid to sound like you are talking to the mentally disabled. It is much better to be overly specific rather than vague with something like, “then make it work whichever way you think is best,” and then be unhappy with the result.
6. Make lots of pictures and give lots of examples. Screencast is free and easy to use, and it can really help you show a developer what you’re thinking
These few tips might help you have a better experience and a better relationship with your friendly neighborhood developer, but if you’re in Kansas City and your developer is in Tampa Florida, they can completely save a project.
Next time, I’ll give you some tips on how to bug test and report the bugs to your developer, so stay tuned!