Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Recommendations? Questions for an RFP Meeting
Message
De
22/02/2001 13:47:51
 
 
À
21/02/2001 15:22:09
Information générale
Forum:
Visual FoxPro
Catégorie:
Contrats & ententes
Divers
Thread ID:
00478125
Message ID:
00478541
Vues:
18
Al:

> - Client currently has a functioning product written in FPD 2.6. This is
> a very narrow niche product, total market potential is between 50 and 100
> sales. Currently 3 sites are using the FPD version and are apparently
> happy with it.
>
> - The product is "semi-custom" - most of the functionality is the same
> for each customer, but there have been customizations made for each as
> well. It is likely that at least some of any new sales will also require
> customizations.
>
> - The existing customers have "expressed interest" in upgrading the
> product to a Windows version, however, they are not willing to help
> fund this process up-front. A developer working for my client has
> mostly completed a rewrite of the app in VFP5 using the CodeBook 6
> framework. At the moment, ownership of this work is divided between
> the developer and my client.
>
> - The developer has become permanently disabled with carpal tunnel
> syndrome and physically cannot complete the project; he wishes to cash
> out his interest in it and exit the profession entirely. However he will
> be available for consultation until this project is complete. My client
> would like me to take over this project and complete it so they can start
> to market it. They are open to straight pay for work, an equity position
> in the product, or some linear combination.
>
> - I am not familiar with the CodeBook 6 framework and would not use it
> on any other project (would use VFE6 instead). The developer is willing
> to consult on this issue as well.

I architected a "semi-custom" product for a private company. Although they
had less than 50 clients at the time, it was a very lucrative market because
the core product cost 30,000-250,000+ and maintenence fees were a flat percentage of the cost payable every year. A little more than half the
clients asked for customizations and these generated more than 30% of the
company's revenues.

The company already had a FPD application and ported it to FPW 2.6a. The
application I designed was developed using FORTE. The project took about
2 years to complete and required 6 people full-time (1 Project Leader/Analyst,
1 Architect/Analyst, 3 P/A, 1 Technical Writer). I left the company during
development but it did not create any serious problems.

I joined this company as a Senior P/A and, like every other P/A in the
company, was included in the Help and Maintenance rotations. I immediately
identified a few problems:

(1) Lack of good user documentation. The users often ask questions that
could have been answered by a good manual. One of the programmers wrote
a long manual but it did not always provide the appropriate level of
information.

(2) Lack of good technical documentation for the programmers. Sometimes
clients would call us and ask us to duplicate the functioanility of
another client. Most of the developers could not understand (explain to
the client( the differencesin implementation because it was rarely
adequtely documented.

(3) Deficient architecture. The architecture did not enough separation
between and within layers.

They had a decent design manual for the FPW 2.6a core system but it was
not always maintained.

In addition to the questions that Jacci raises, I would ask the client this
question.

- Ask them to see all the documentation available for the new system. If the
previous developer did not document Requirements, Architecture, and Detailed
Analysis, it is very likely that his or her work is worthless. The
system may work as he or she intended but unless you can easily recognize what
already exists and when, how and where to put the customizations, you will run
nto problems as soon as you start customizing the products for more than a
handful of clients. It's not your problem whether he or she gets paid.
Accepting him or her to continue to work on the project is a double-edged
sword. On the one hand, he or she can provide you with very valuable
information. On the other hand, he or she is not likely be accountable for
your work and and it is very likely that you will be blamed (and may be held
responsible) for all errors and omissions.

Personally I would accept this type of employment if:
(1) I am fully in charge of development, including the choice of tools.
(2) I could chose to throw away the other programmer's new system if not happy
for any reason.
(3) I could decide or not to use the other developer as a consultant.

Whenever I plan to terminate my relation with an employer as soon as a project
is finished, I am much more flexible in the type of work I will accept to
perform. However, these contracts are usually not rewarding from a
professional and morale point of view and I tend to stay clear of them.

My point is that I concur with Jacci. There seems to be are several red
flags already present in this project and I would evaluate my decision to
participate very carefully.

I would follow my gut feeling too.

Daniel
Précédent
Répondre
Fil
Voir

Click here to load this message in the networking platform