3 ms·
When I read this title, the first thing I thought was, "Oh no, another poser telling the rest of us what to do based on what they think". Boy was I wrong about
by edw519 17y ago
When I read this title, the first thing I thought was, "Oh no, another poser telling the rest of us what to do based on what they think".
Boy was I wrong about that. This is an excellent post that could have only been written by someone who has suffered in the trenches and knows what he's talking about.
Many of his points:
2. Get in bed with the business people
3. Ease their pain
5. No one gives a rip what the artist thinks
6. You get to control those lovely details
7. Write it down, write it down, write it down
8. Get in bed with the QA team
9. You have to have a middle man
10. Proximity breeds understanding
11. Learn to articulate well
emphasize that the people part of the process is just as important as the technical part. This is easy to overlook and we need to be reminded every once in a while. The main reason we do what we do is not because it's cool (it is), we do it for and with other people.
The only point I challenge is "4. Force business to iterate in design, not in development." This is perplexing because it runs counter to most of his other points. The reason people tend to iterate in development instead of design is because it's much easier. They're not sure what they want, but once they see something, they know what they like and don't like about it. I'd alter #4 to something like, "Learn to prototype well, so everyone is equally comfortable iterating toward the most desirable outcome."
- hga 17y agoA cited subset "emphasize that the people part of the process is just as important as the technical part", and I'd argue "1. Be a Developer" does as well. In that case, while in and of itself it's technical, it's the minimum required to work well with developers and is a prerequisite for doing part "10. Proximity breeds understanding" well. It also lets you effectively "3. Ease their pain", since you understand it at some level. A lot of it comes down to respect and what falls out of that. It's clear the author respects everyone in the process and that goes a long way towards making the disparate functions and people cohere. I think I'd like to work for this guy: he'd let me hunker down on "engine" work as I prefer most of the time, would welcome the times I want to do HTML/AJAX GUI work, and be very happy about my focus on the big picture, requirements, hand off to QA and production, etc. etc. etc.
- jimbokun 17y ago"The reason people tend to iterate in development instead of design is because it's much easier. They're not sure what they want, but once they see something, they know what they like and don't like about it." This just happened to my team last week. The designer had pretty comprehensive mock ups of the site, the stake holders all said "sure, looks good," we implemented it, and then the stake holders saw it and asked for something very different from the initial design. I agree that, to some extent, this is inevitable. However, if you can somehow teach or convince or trick the business people to give feedback during the design phase, it would save time overall because modifying mockups take much less time than actually building something multiple times. That does not change the need for developers to iterate as rapidly as possible, of course.