Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Help a Former Client
Message
De
04/10/2012 07:13:36
 
 
À
03/10/2012 18:29:41
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Divers
Thread ID:
01553137
Message ID:
01554282
Vues:
69
>I have now read almost all replies from the others here. What strikes me is that none tells you this:
>
>Apparently you have not well documented your work. Perhaps that was part of the deal, but I suspect that they only discovered this later, to their 'surprise'.
>
>Many developers have their means to make their clients dependent on them. Perhaps I'm also one of those, but I try very hard to document everything (at the level of a professional vfp developer). What drives me most is that the client must be able to continue business if something happens to me, like serious disease or accident.
>
>>I've got a client that is replacing my 15 year-old system with something new and has decided not to use me. "Nothing personal, just business" and we parted amicably.
>>
>>Once they made that decision, the Client has not used me for anything. They didn't ask for my help with an RFP, they didn't involve me in the data conversion, etc. They do however ask me questions - How does Table X relate to Table Y? What data structure do we pass the credit card processor and what format do they send back?
>>
>>Those questions are quick and easy to answer, but they are quick and easy to answer because of my expertise and years of experience. I feel like I'm selling myself short giving away that knowledge at my hourly programming rate. Also, and maybe it's petty, but I don't really feel like helping out the guy who's replacing me.
>>
>>So what to do? Suck it up, answer the questions, and charge the hourly rate? Tell them they are on their own at this point? Have a different hourly rate for this expertise? Tell them that if they want me standing by ready to help they'll have to pay me a retainer?

Regarding documentation, It's relatively simple to get agreement on what an accounts receivable aging should look like, but there is a wide range of opinions on what good system documentation should contain, and how it should be maintained as systems evolve.

We emphasize liberal use of comments in the code- mainly decribing the business reasons for doing the step.

The subject of documentation reminds me of a savvy business owner/client who once told me that there are things that you do that make the business more efficient and there are things that you do because they make your work seem more "professional"...

and the two often diverge.
Anyone who does not go overboard- deserves to.
Malcolm Forbes, Sr.
Précédent
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform