Newsgroup: it.comp.www.php
Titolo: correzioni ad un software: in garanzia o a pagamento?

Salve a tutti
ho un quesito da chiedervi. Ho realizzato un piccolo programmino in
php per un cliente, programma che per una serie di motivi che non sto'
ad elencare ho avuto tutta una serie di problematiche che si sono
protratte per diversi mesi. Ora, in seguito a vari interventi tale
programma è operativo e funzionante. Finora, ho sempre considerato la
correzione "in garanzia", ma da questo momento in poi vorrei chiedere
un piccolo canone "di manutenzione". Per eventuali "aggiunte" invece
sarebbero preventivate e pattuire volta per volta.
Sottolineo che da parte mia, un po' per ingenuità, un po' per fiducia,
non ho specificato all'inizio clausole di licenza software
(proprietario, gpl, in uso, ecc.), comunque non ho problemi a
lasciargli sorgenti e quant'altro.
Sbaglio? E' una richiesta esagerata da parte mia? Dovrei considerarlo
in garanzia vita natural durante?
Che ne pensate?
grazie
M.

 garanzia vita natural durante?
Se vuoi morire di fame, consideralo in garanzia per sempre... :)
Dovresti prevedere un periodo dopo la consegna (da una settimana a qualche 
mese, dipende dal software) nel quale il cliente testa il software in un 
ambiente di test, ma con dati reali e con gli operatori che poi andranno 
ad usarlo.
Questa parte la comprendi nel prezzo.
Stando attento che le correzioni che ti chiedono siano debug, e non nuove 
funzionalita` o modifiche di quelle esistenti.
Dopodiche` lo consideri accettato cosi` com'e`, ed eventualmente gli fai 
firmare una carta che lo attesti.
In seguito, piccole correzioni le puoi gestire come "customer 
care" (aggratis), mentre per bug piu` grossi devi valutare caso per caso, 
ma non dovrebbero essercene piu`.
Tutto il resto, cash. :)
Bye.

 M.
Personalmente penso che la migliore soluzione in questo caso è venirvi
reciprocamente incontro e trovare una soluzione soddisfacente per
entrambi, al di là del legale. Per quanto riguarda il futuro, invece,
credo ti converrebbe pensare un business model a te affine e scegliere
un insieme di licenze da applicare al software, e che andrai a
spiegare al cliente fin dal principio, in maniera che non possano
esserci dubbi. Come si dice: "patti chiari, amicizia lunga".
La cosa più giusta in generale (secondo me) sarebbe rilasciare tutto
il software che si scrive sotto GPL (o LGPL in certi casi), ma di
solito i clienti non sono d'accordo quando gli viene spiegato quello
che questo comporta: caso in cui il codice non verrà consegnato
nemmeno a loro, se non a prezzo molto superiore. Questo in generale,
poi ovviamente si può cambiare caso per caso.
Ciao!

 ma non dovrebbero essercene piu`.
  Per il resto sono d'accordo con te, qui invece ho una domanda: ma
se il programma ha un bug, quindi un problema legato ad una "cattiva"
programmazione da parte tua (mia, va'... :-) ), quanto e' lecito
(legalmente) farlo pagare al cliente? Non si tratta di un difetto
di progettazione la cui riparazione rimane sempre di competenza del
produttore?
  Saluti,
-- 
Gianfranco Bertozzi
Linux User #183585

Gianfranco ha scritto:

Entro i normali tre mesi di garanzia a decorrere dalla consegna sě.




Come dicevo, devi valutare caso per caso.
Se si tratta, che ne so, di un errore per cui una news inserita a 
mezzanotte e un secondo viene visualizzata il giorno prima, lo correggi e 
amen.
Se invece e` un bug per cui un prodotto, in base a un codice prodotto, 
deve infilarsi automaticamente in una categoria, ma le specifiche non 
erano chiare o la lista dei codici non era completa al momento della 
progettazione o che so io, e` un "bug" dovuto a progettazione fatta male 
perche` mancavano informazioni complete. Questo io lo farei pagare extra.
Se invece hai proprio cannato una procedura perche` hai sbagliato 
l'algoritmo, e invece che ordinarti delle cose correttamente, quando 
superi le 1000 unita` te le ordina a caso, questo e` un bug grosso e 
avresti dovuto accorgertene in fase di test (per questo parlavo di test in 
ambiente protetto ma con dati reali).
Bye.

 in garanzia vita natural durante?
COme qualcuno ti ha consigliato, la cosa migliore e' mettere tutto per iscritto
prima.
IMHO quando si vende un software ad hoc bisogna stendere delle specifiche di
funzionamento del software, discuterle con il committente, fargliele APPROVARE e
costruire il software basandosi su quelle specifiche.
In questo modo ci si intende anche sul termine "baco" che e' una deviazione
dalle specifiche di funzionamento: io faccio un programma che somma interi, se
fornisco 2 e 5 e il programma ritorna 10 e' un baco; se fornisco 2,5 e "pippo"
il programma deve dare errore perche' le specifiche dicono che deve sommare
interi, non decimali e stringhe.
Tutti gli interventi "in garanzia" IMHO devono coprire i bachi, ovvero le
diviazioni dalle specifiche.
Eventuali interventi di ampliamento o modifica non banale su attivita' non
previste dalle specifiche dovrebbero essere tariffate (previo preventivo con le
stesse modalita' di di cui sopra con specifiche e accettazione) a parte. Che poi
questa tariffazione sia a progetto o a forfait ("contratto di assistenza") devi
deciderlo tu con il cliente.
Cio' detto, se tu non hai redatto all'inizio le specifiche, puo' essere il
mmento giusto per farlo. Potresti sederti al tavolo con il cliente, parlare
francamente dicendo quello che hai scritto a noi e dire che consideri "chiuso"
il progetto di realizzazione del software (la scelta e' arbitraria anche perche'
non c'erano specifiche scritte all'inizio, quindi nemmeno il committente puo'
avanzare molte richieste) e che da ora in avanti se il cliente ha piacere di
continuare a collaborare con te ci saranno queste e queste condizioni (che
andrai ad elencare).
My two cents.
Ciao,
luigi
-- 
/
+--[Luigi Rosa]--
\
For every human problem, there is a neat, simple solution;
and it is always wrong.

 ha scritto nel messaggio 
news:goomj7$tvg$3...@tdi.cu.mi.it...

come ti hanno detto gli altri, se il bug č grande ed č tua colpa
non puoi farlo pagare al cliente...
se invece il bug dipende anche dal cliente allora č un'altra cosa 

Ciao, l'argomento è abbastanza "fastidioso" e le cause sorte negli ultimi 
anni hanno sempre avuto evoluzioni soggettive e discussioni e interventi di 
avvocati,giudici, testimoni e anche consulenti spesso paradossali.
Anni fa ho comprato un libro sull'argomento utilizzato per due cause di una 
software house con clienti che non pagavano e si difendevano dicendo di 
tutto sul software e chiedendo risrciimenti di danni  "enormi" per il 
malfunzionamento di programmi o per carenze funzionali.
Non sono avvocato ma un analista programmatore  (poco esperto di php)  di 
gestionali e in altri linguaggi ma il concetto non cambia.
Prima di tutto bisogna capire se hai fornito:
--  un prodotto ,  ossia il cliente ti ha comprato un software in php . In 
tal caso la proprietà intelettuale è tua ( se già l'avevi) e vale la 
garanzia di 1 anno con le aziende (2 con i privati) .  Garanzia da 
malfunzionamenti . Nel caso poi il software non rispetti le caratteristiche 
presentate quando lo hai venduto (esempio poter gestire fino a 100.000 
articoli e invece ne gestisce solo 10.000) allora ti può chiedere indietro i 
soldi. Inoltre se ritiene di avere avuto danni alla sua attività per colpa 
del software  può addirittura cercare di dimostrare che la colpa è tua e 
chiederti i danni.
-- un servizio , ossia hai sviluppato il software sulla base di una 
specifica che definsice una commessa . valgono tutti gli aspetti negativi di 
prima oltre che definire a chi appartiene il software ossia i diritti di 
autore (da regolamentare in fase di contratto) e poi il concetto di collaudo 
che se non ben definito nel contratto può vole dire tutto e niente  e 
portare una assistenza infinita, a un non pagamento , danni etc ...
Quindi fai attenzione per le prossime volte.
Ciao