So I've just discussed the importance of engaging a web developer in an Agile process. Everything should be fine now, just iterate quickly and actively and it will all work out. Right?
Well, I left out one important piece of information. Reality has a way of getting stuck in the gears from time to time. It's the thing that Agile proponents don't much like to talk about: billing and contract scope.
As a client, you want a web site. You'll pay a fair price for it, and you want to know what that price will be up front. That, to me, sounds like a very reasonable proposition. The alternative is hourly rates, which have some problems:
- Incentives are misaligned. More work equals more pay for the developer, but not necessarily more product for the client. There is more than one way to skin a cat, and some of those ways take more time.
- Expectations are not agreed to. How long is this going to take, anyhow? If you don't nail down some specifics, you will have a project that will end when the money's gone, finished or not.
I'm a believer in defining the scope of a project before starting and putting a fixed price tag on it. This keeps the project to manageable, finishable scope and encourages the developers to work smartly.
The astute reader will realize that this advice is in direct conflict with my last post on keeping things Agile. And you're right.
More to the point, this is an area that requires some finesse. In exchange for some tangible benefits (a solid scope and a better alignment of the client and the developer), we generally have to sacrifice some Agility. We can nail down the obvious big issues, but still remain Agile about which of the smaller issues get our attention and when they get it.
Here's the process I use.
Client Homework. You, as a client, need to do your homework before I get involved. You need to have thoroughly thought through the problems you are trying to solve. Put more concretely, you need to have created some wireframes of what you think the site will end up looking like (functionally, not aesthetically). I like to use Balsamiq Mockups, but Powerpoint, Visio, Omnigraffle, or just pen and paper are fine too. These mockups should be complete. All of the important views need to be drawn with all the buttons in the right places. Text and copy can be rough, but there should be something there.
Walk through the wireframes, imagining that you are using the software. Click here. What happens next? Run through all the most common scenarios you can come up with and adjust your wireframe to suit what you've learned from your thought experiment. If you need help, check out Don't Make Me Think: A Common Sense Approach to Web Usability
or the voluminous information at Jakob Nielsen's site. Another good rule of thumb for user interface (UI) design is to look at how Apple or Amazon handle similar issues. There's a good chance they've come up with a very good solution.
And now, the important part - the part that requires a mental shift. Understand that you will not be getting this product. The purpose of this exercise is to understand the problem at a detailed level before you get started, not to spec out a web application. You will find some concepts that are critical to the product, some that might be useful, and some that really don't need to be there at all. But you must understand and embrace this point:
This is not a requirements document. It is your vision, written down.
This education process, which you should share with your contract developer, will allow both of you to gain the insight into what the scope of the project will turn out to be.
Developer Homework. Next, you need to thoroughly communicate your findings to the web developer, and come to an agreement about pricing and timeline. You will have put enough thought into the product so that you will be able to come up with some rough time and price estimates, even though you know the product will evolve in development. At this point you must both commit and name a price, a deadline, and an outline of the critical features. The deadline is especially important and must be a hard date to launch the product.
Get to Work. Now that you have a price and a timeframe, it's time to get to sign a contract and get to work. Expect to meet with your developer at least once a week, sometimes twice. Expect to work almost as much as the developer does. You will need to redraw interfaces that don't work like you thought they would. You'll test and retest the live application (there will be something live to test within a few days, and every few days after that). Your experiences will cause some of your features to shift in priority and in form. That's not only ok, it's expected and good. It's all part of the process.
Over time, the product will mature and the deadline will creep up on you. Pay attention to it. The knowledge that your developer time is running out will be a great motivator to build what is important, use the simplest solutions, and ignore the fluff. This is a critical piece of the Agile puzzle. You cannot be Agile without constraints. Even you're not under any particular time pressure, pick a hard deadline and stick to it. I cannot stress this enough:
DO NOT MISS YOUR DEADLINE
Launch. If all has gone well, you'll have a product that is minimally sufficient come launch day. Launch it. Tell your friends to try it.
Post Launch Work. You will also probably have a few "must have" features that are missing that the developer committed to. That's ok and normal. Just add them after launch. You and your developer should have budgeted some time for post launch activities. This is when you fit in the stuff that took a little longer than you might have thought. It's also when you start listening to your initial users. You will undoubtedly learn something right away that will make you want to change something. Do it now.
Contract End. At this point, you'll have a working, but imperfect application that you can use to start testing your market. If you take a look at your original wireframes, you'll probably find that some parts your new product look just like you drew them, and other parts are a bit different. There will probably be some features that didn't get built, and some that were built that aren't on your wireframe.
In practice this a typical contract might be scheduled for four weeks of pre launch work, followed by one week of post launch work, and consist of a fixed price tag and a high-level, but specific list of "must have" functionality.
There are some risks inherent in this method. It requires a degree of trust. It won't work, for example, if you, the client, are intent on squeezing out as much work as humanly possible from this one contract. It also won't work if the developer is intent on doing as little work as humanly possible on this one contract. It requires a professional partnership-style attitude on both sides of the deal to work. By the end of the contract, you should both want to work with each other again - so keep that in mind during the contract. Choose the people you work with very carefully. If they can't or won't understand a part of this process, don't even get started.
Is this Agile Utpoia, where products freely evolve until they achieve greatness? No. But it's about as close to it as you'll get without an open-ended, hourly contract. (Which, by the way, can work. It's just that it requires even more professionalism, interpersonal understanding, communication, and trust than the process I've laid out. It's more suitable for a second contract with a proven partner.)
Up Next: Picking A Platform
0 comments:
Post a Comment