'plain please then what I did wrong here then: Me "Did you test it?"
Them "Yes we tested it, please install" Four weeks later: Them "Hey the commissions aren't comming out for RMA returns" Me "I thought you said you didn't want RMA returns customized because you didn't do those?" Them "We did them manually. We just started doing them 2 weeks ago" This continued for 6 more applications they SPECIFICALLY asked to NOT CUSTOMIZE because they didn't want to spend the money. Then I had to create a commissions routine that would go backwards through time to re-do the commissions and come up with a delta. ---- Tony Gravagno <3xk547...@sneakemail.com> wrote: > Allen wrote: > > Other onsite and offsite clients that didn't want to > > spend the time or just blurted out incorrect answers > > to end the questioning.... received finished projects > > that matched the quality of their answers and the > > quantity of their time invested. > > Hmmm, I dunno if this is good or bad in the eyes of the masses, > but I won't deliver a finished product where there isn't a > reasonably clear line from here to there. I'm not saying I'm > going to hold out for every "i" to be dotted on a signed spec. > I'm saying if there are obvious holes in the request, where we > have a strong feeling that the project is going to end with a > perception of failure, I personally prefer to withdraw from > starting down the path that will lead to that failure, and > possibly the blame for it. > > I've had to learn this the hard way, after eagerly trying (but > failing) to please a few clients who couldn't express what they > wanted, but they expected me to deliver 'it' anyway. I still get > lots of inquiries like "I want a website, how much will 'it' > cost?" Well, we can't estimate 'it' and we can't code 'it' until > we know what 'it' is. I won't subscribe to the GIGO principle of > development where I'll accept garbage for a spec, knowing that > they're going to get garbage at the end of the project. No one > is happy with that sort of solution. > > I provide two services - the first is to help determine what is > needed, and the second is to create it. While the first part > often isn't required, unfortunately some clients who need it > don't have the patience for it. But I consider it my job to ask > the questions that should lead to success. When I get vague > specs, I don't deliver vague results. I tell my clients that the > more time I need to spend on the clock asking questions, the less > time I'm spending in code. I'll do what's required to get them > where they want to go but we need to work out if I should be > asking the questions or if they can get someone who can quickly > provide the required specs and data. This is where a > "programmer" becomes a "consultant", and in most cases clients > need and appreciate someone who can ask the right questions and > get the right answers - more than they need or appreciate someone > who just cranks out code. > > Tony Gravagno > Nebula Research and Development > TG@ remove.pleaseNebula-RnD.com > Nebula R&D sells mv.NET and other Pick/MultiValue products > worldwide, and provides related development services > remove.pleaseNebula-RnD.com/blog > Visit PickWiki.com! Contribute! > > _______________________________________________ > U2-Users mailing list > U2-Users@listserver.u2ug.org > http://listserver.u2ug.org/mailman/listinfo/u2-users _______________________________________________ U2-Users mailing list U2-Users@listserver.u2ug.org http://listserver.u2ug.org/mailman/listinfo/u2-users
