Newsgroup: it.lavoro.informatica
Titolo: Tempi e modi di lavoro Osid-style


-- 
Living in Barbaropoli
http://www.barbaropoli.com


C'� il rischio di essere troppo on-site cos�. Subordinato al negozio.
Inaccettabile.
Segue il vero annuncio della Bottega Osid:
##################################
  cell. 333-osid�-osid�-osid�
  E voi qua pensavate di trovarmi?
  Ma col cazzo che lavoro!
##################################

 ##################################
aggiungerei:
- il cliente paga per il tempo lavorato e non per il risultato, anzi il 
risultato non � garantito, anzi che cazzo pretendete?
- la consegna non � vincolante. se vi dico "fra un mese" po'esse fra un 
mese ma anche no. non mi rompete le palle con le scadenze che non sono 
un finto cocopro, io!
- gli sforamenti sono a carico del cliente. se ci metto un mese paghi 
per un mese, se ce ne metto due paghi per due.
- il cliente che telefona pi� di una volta per sapere a che punto sono � 
un delinquente che tenta di subordinarmi, ma non ci riuscir�!
-- 
++ questo messaggio � scritto in forma ridotta per venire incontro alle 
vostre capacit� mentali
http://www.elogiclab.net/blog/
http://www.flickr.com/photos/marko_po/

 Anche tu torna a ripassare...
Al posto tuo non terrei conto delle opinioni (forse) sbagliate che 
qualcuno su � fatto di te, ma del perch� si � fatto queste opinioni.

ehr..
ma pensate così tanto a Osid?
=)

 un delinquente che tenta di subordinarmi, ma non ci riuscirà!
Pero' bisogna essere onesti.
C'e' anche da dire che spesso chi decide tempi e risultati, ovvero il
cliente,  lo fa ignorando (volutamente o meno) aspetti pratici e
fisiologici del nostro lavoro.
Ci sono clienti che si aspettano cose evidentemente impossibili, ma
per prendere la commessa devi promettere la luna e poi fare i salti
mortali per mantenere la parola.
Con "requirements" idioti, diventa fisiologico essere in ritardo nel
consegnare un lavoro cosi' come diventa inutile (ai fini del lavoro)
stabilire milestones.
E spesso per "analizzare" i tempi di consegna devi investire molto
tempo, che potrebbe essere speso per lavorare davvero e accorciare gli
stessi ... catch 22.
Senza arrivare ai limiti comportamentali di Osid (:-))) ) bisogna
ammettere che nello sviluppare software, non esiste una formuletta per
ricavare tempi di consegna attendibili.
Si puo' approssimare ma, almeno per la mia esperienza, la tolleranza
(in piu' o meno) e' elevata.
In condizioni ideali (hai tutto quello che ti serve, hai persone
motivate e competenti, hai specifiche chiare ed univoche, ecc.) si ha
sempre ALMENO un +/- 10% di tolleranza.
Molto spesso pero' le cose non sono cosi' belle, a partire da
specifiche iniziali a dir poco confuse ("avrei bisogno di questo, ma
forse no, ma forse qualcosaltro), cosa che porta automaticamente a non
avere gli strumenti e competenze corrette per il lavoro da fare ...
insomma, io la vedo piu' come la tipica applicazione GIGO.
Non e' un caso se negli ultimi 50 anni si sono sviluppate una miriadi
di tecniche di sviluppo SW !
La "colpa" di Osid e' IMHO di voler formalizzare questa cosa che
onestamente in  piu' di 25 anni di lavoro non ho mai visto smentita.
Non sta bene dire "ricevi il lavoro quando e' pronto" ma nella
maggioranza dei casi e' esattamente quello che accade.
Non lo puoi ratificare ma e' la realta' quotidiana, perche' proprio a
partire da chi commissiona il lavoro, quasi sempre le idee sono poche
e molto, ma molto ben confuse.
Inutile girare in giro.
Sviluppare SW non e' un lavoro comparabile con altri lavori.
Non si possono applicare tecniche e calcoli che funzionano con altri
lavori.
E la colpa e' anche nostra che non siamo capaci di dire al cliente
questa banalissima verita'.
C'ya
  STeve

=)
Quando ho visto l'immagine non ne ho potuto fare a meno. :)


Anche tu torna a ripassare...
Eh, ma vedi tutta sta pippa sul cartello non ci stava...



hahaha ! eco perch� non aggiorni pi� il blog :-)

Torna a ripassare.
"Ripassare"? Ma che credi di aver inventato una dottrina pure te ora? 
Esaltati, gente allegra... ;)

 mortali per mantenere la parola.
vero, per� permettimi una divagazione.
io sono dipendente di una azienda software, questo significa che dal 
cliente non sono sempre solo a fare le cose. soprattutto ci sono 
rapporti con clienti nuovi e rapporti consolidati: quest'ultimi sono 
rapporti in cui non dobbiamo conquistare ogni volta la fiducia del 
cliente, magari non chiede il preventivo solo a noi ma in ogni caso non 
ci dobbiamo scapicollare per prendere una commessa. e con questi si 
parla in maniera sempre molto franca, si discute, si lima l'impossibile; 
anche perch� di solito il cliente in questi casi � rappresentato da 
delle persone che a loro volta subiscono una pressione dall'alto e di 
conseguenza hanno interesse a trovare una soluzione realizzabile 
piuttosto che battere il muso in una soluzione impossibile.
e poi un'altra cosa che ho imparato da subito � distinguere i giorni di 
calendario dai giorni/uomo di progetto. sembra banale dirlo ma a 
discutere qui ho sentito tanta, ma tanta confusione... :) e la 
distinzione � fatta in questo modo: se diminuiscono i giorni di 
calendario che separano dalla scadenza *aumentano* i giorni/uomo. quindi 
se per un lavoro stimato 30 giornate mi dai 40 giorni (lavorativi) di 
calendario ok, ma se me ne dai solo 20 allora la stima sale a 50 (sono 
numeri a caso, ma per intendersi). questo concetto semplice per noi 
(diminuisce il tempo utile, devo dispiegare pi� forze) pu� sembrare 
complicato da far capire al cliente, ma in realt� anche in questo caso � 
una questione di fiducia: una volta che hai dimostrato che gli obiettivi 
li prendi a cuore e li centri il cliente mugugna ma poi accetta.
certo per fare questi ragionamenti bisogna avere alle spalle una 
potenziale squadra, ma l'ho sempre detto anche qui dentro, la 
programmazione *non* *�* roba per cani sciolti... qualcuno non � 
d'accordo ma poi i fatti son questi.
e anche a chi dice "la fai facile, sei dipendente e mangi uguale!" io 
rispondo in modo molto semplice: intanto se sforo con la stima mi arriva 
puntualmente ad inizio mese la telefonata del responsabile 
amministrativo a chiedere spiegazioni e a cui (per posizione, ma anche 
per caratterino) non � il caso di fare supercazzole... e comunque si 
tratta anche di senso di responsabilit�. trovo fondamentalmente stupido 
essere su una nave e non avere a cuore che navighi come meglio si pu�, 
capisco che qualcuno qui non concepisca o pensi subito a chi si 
arricchisce (o arricchirebbe) con la nave che viaggia col vento in 
poppa, ma personalmente se non mi prendessi a cuore quello che faccio mi 
risparmierei di alzarmi da letto la mattina :)
ovviamente tutto � facilitato da un bel rapporto umano con i colleghi e 
con i capi, ma anche qui avendo in passato lasciato aziende per 
questioni proprio di rapporti umani e avendo anche rinunciato a 
qualcosina pur di avere a che fare con persone umanamente valide non si 
pu� dire che non me lo sia meritato... :)
vabbeh, per oggi pu� bastare :-)


 un delinquente che tenta di subordinarmi, ma non ci riuscir�!
Eccoli, ne hai dimenticato qualcuno.
http://www.risateonline.it/mostravignette.phtml?c=vignettelavoro&p=4&o=
Ma Osid non era longobardo???
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 può dire che non me lo sia meritato... :)
Clang clang clang, wrrrrrrrrrrrrrrrrrr, ratatatatatatatatatata
E due :-)
C'ya
  STeve

 (in piu' o meno) e' elevata.
Assolutamente si. Per�, a furia di dai, riesci a capire qual � una
tolleranza accettabile, e a ragionare di conseguenza.
-- 
Ciao!
Luca

 pari a met� dello stipendio.
mi sa che sono problemi che devi affrontare, non so chi ti ha messo in 
testa che da dipendenti lavorare a mezzo servizio sia una cosa tollerata.


 svolge il lavoro.
Non cadere nello stesso vizio di forma che combatti !
Il cliente non e' tenuto a sapere "come" fare il lavoro e cosa ci
vuole.
Accettare scadenze impossibili e' colpa di chi accetta, non di chi
propone.
C'ya
   STeve

 propone.
Quoto.
-- 
Ciao!
Luca

 Ci� che non � garantito nell'Osid-style � che la stima sia rispettata.
Cosa che crolla miseramente quando si lavora per commessa e non su
prodotto.
-- 
Ciao!
Luca

 cosa legittima e sacrosanta. Se io ho 10 di risorse, e ho un progetto
Mica ho detto che e' una colpa, semmai e' legittima difesa.
C'ya
 STeve

 ecc. allungare i tempi di consegna (e quindi la data di consegna)?
Perch� c'� una certa differenza:
1) la data di consegna la definisco io;
2) la definisco PRIMA di iniziare il progetto, prendendomi tutte le mie
cautele;
3) la sottopongo al cliente, il quale la accetta o no;
4) se la accetta, per me diventa tassativa, a meno di modifiche al
progetto iniziale in corso d'opera.
Tu invece dai una data di consegna, ma dici che pu� tranquillamente non
essere quella, e pretendi che il cliente non si incazzi se sfori, cosa
che, per tua stessa ammissione, succede spesso.
-- 
Ciao!
Luca

 che, per tua stessa ammissione, succede spesso.
Se la da' lui la data d'accordo. M se la impone il cliente, e questo
magari ce lo conferma o lo smentisce Osid, può anche essere che non ce
la fai. Certo si può anche non accettare quella data, ma se il cliente
insiste?

 quando io vi dico che è mia prassi, in caso d'imprevisti/sottostime/
Perche' tu parti con l'idea di non dare ne' seguire una data di
consegna.
E' legittimo dare una data di consegna "gonfiata" PRIMA di iniziare i
lavori, in modo da avere un margine per poterla garantire.
E' scorretto non dare una data del tutto o dire "tanto non la seguo
comunque".
La differenza c'e', se non la vedi mi sa che hai problemi tu :-)
C'ya
  STeve

 insiste?
Non accetti il lavoro. Inutile girare in giro.
La data la definisci tu che sai cosa serve a fare il lavoro. Se
accetti un'imposizione e sai a priori che e' difficile, se non
impossibile, starci dentro, la colpa e' solo tua e quindi il cliente
ha ragione a chiederti rimborsi/sconti/ecc. ecc. nel momento che non
la porti a termine.
Il fatto, gia' detto molte volte, e' che stabilire una data "reale"
per la consegna di un SW e' un'attivita' IMHO molto ma molto piu'
complessa che realizzare il SW stesso.
Quindi o ti copri il culo dando cifre molto piu' alte di quanto poi
magari in effetti serve, o rischi ogni volta di andare con il culo per
terra al primo problema.
Di sicuro una volta stabilita una data, devi lavorare per garantirla.
C'ya
  Steve

insiste?
Non pu� certo essere la norma che il cliente, colui che per
definizione non sa fare il lavoro che ci richiede di fare, decida il
sempre lui il "come" e il "quando". A senti parlare Osid, ogni lavoro
� in balia delle valutazioni tecnico-tempistiche del cliente; capirai
che la cosa � improponibile...

 che la cosa è improponibile...
Non ho mica detto che è la norma, magari pero è il caso di Osid. Per
qanto mi riguarda, quando mi capita di fare prevendita e aiutare a
scrivere un'offerta
1) io prevedo gia il 25% in più. Per ogni evenienza
2) l'azienda ci mette un'altro 10% ulteriore di "risk management"
Detto questo, l'imprevisto è dietro l'angolo, per progetti
sistemistici come quelli che seguo io non ti dico che sforare è la
norma, ma può esserlo se ad esempio il cliente non vuole, per suoi
motivi fare dei test preliminari e poi si va a ramengo... la posizione
di Osid la capisco pure, è certo che se il cliente si impunta il buon
commerciale deve mediare...

 che la cosa � improponibile...
quello che ripeto da n messaggi, stime/tempistiche e scadenze temporali 
sono due cose distinte!
� vero che il cliente non pu� (e non deve) entrare nel merito delle 
stime, ma � anche vero che � il cliente che sa per quale data di 
calendario gli serve sia finito un certo progetto. poi magari se c'� da 
trattare si tratta, si propone eventualmente un piano che sia realistico 
e fattibile con dei compromessi se necessario (un classico: "per quella 
data rilasciamo questa e quest'altra parte, mentre quest'altra ancora la 
rilasciamo la settimana dopo") per� le date bisogna che stiano bene al 
cliente.
il discorso di osid � diverso perch� lui *non* lavora a progetto. lo 
dice chiaro, lui si vende a tempo o a time & material che dir si voglia. 
come funziona nel dettaglio lo sapr� lui, ma in genere chi lavora in 
questa modalit� viene alimentato di lavoro dal committente giorno per 
giorno o poco ci manca, di sicuro per� se gli danno da fare un lavoro da 
tre giorni gli danno anche tre giorni per farlo. il progetto c'� ma lui 
non ne ha visibilit� quindi � chiaro che le scadenze le subisce.


non ne ha visibilit� quindi � chiaro che le scadenze le subisce.
Quindi si lamenta di un meccanismo di cui � parte integrante e che
soprattutto ricerca lui stesso... Giusto?

Non ho mica detto che =E8 la norma, magari pero =E8 il caso di Osid
No ma infatti non mi riferivo al tuo intervento, parlavo di Osid. A me
pare venire fuori, alla fine, che tra stime di tempistiche e date di
consegna Osid non l'abbia mai detta giusta al cliente.
Mancanza di esperienza (personale e/o riferita al dominio
applicativo)? Incapacit� nella comunicazione? Boh...

 insiste?
Ho mollato l'ultima commessa fatta in questo modo due mesi fa.
Tecnicamente impossibile da realizzare, e quindi inaccettabile.
Nota. Io ho detto chiaro al cliente (che � cliente di vecchia data):
per me � impossibile, ma se trovi qualcuno che te la fa per quella
data, sentiti libero di assegnare la commessa a lui.
Non mi risulta che la commessa sia stata accettata, e che sia ancora in
fase di palleggio fra commerciali e uffici tecnici.
-- 
Ciao!
Luca

 commerciale deve mediare...
Non sono d'accordo. Cio' che io ho da vendere non � il battere i tasti
(quello lo sanno fare tutti), � il mio buon nome; leggi, la mia
affidabilit� e la bont� di ci� che faccio.
Se derogo in qualche modo, sputtano il mio prodotto e, come sai,
sputtanare un prodotto significa mettersi in mano una bomba pronta ad
esplodere.
Vuoi che ti dica che nome si sta facendo un famoso software di cui
senti pubblicit� per radio?
-- 
Ciao!
Luca

 stato colposo.
IMHO quando una colpa diventa sistema, o si avvicina a diventarlo,
diventa dolo, anche se bisogna vedere da parte di chi. Ma, lo
ribadisco, IMHO.
-- 
Ciao!
Luca

 overtime.
secondo me � l'ennesimo esempio di come si confondono allegramente le 
stime di un lavoro e i tempi di consegna.
mi pare di capire che stimare un lavoro di 10 giorni per te equivale a 
dire al cliente "te lo consegno fra 10 giorni lavorativi". il che � una 
immane zappata sui piedi.
le stime servono a determinare quanto tempo ti serve per fare quel 
determinato lavoro e in ultima istanza per fare un preventivo costi per 
il cliente. se poi ti � dato facolt� di stabilire anche il tempo di 
consegna, � chiaro che questo deve essere "maggiore di". altrimenti � 
ovvio che ti basti prendere un caff� in pi� per sforare la scadenza.
altro appunto su questa vicenda. se tu dici di aver fatto una stima di 
10 giorni ma poi sostieni fra i motivi di sforamento lo studio della 
documentazione e il "misunderstanding" (che a casa mia vuol dire non 
aver capito cosa c'era da fare) vuol dire che tale stima non era solo 
estremamente ottimistica ma anche sbagliata.
converrai con me, se tu fai una stima troppo ottimistica (non tiene 
conto degli imprevisti) per giunta sbagliata (non aver capito cosa 
voleva il cliente � comunque un errore di analisi) e a questa stima ci 
associ una data di consegna senza darti alcun margine, � *evidente* che 
sei destinato a non rispettarla. oltretutto che ti presenti in ritardo 
magari ti porti dietro una fattura superiore del 50% sullo stimato, ci 
mancano solo le macchie di sugo per certificare quanto sia maccheronico 
questo modo di gestire un progetto... la maggior parte dei clienti 
*seri* (leggi: quelli che *pagano* le fatture al centesimo e puntuali) 
non vedo come ti potrebbero prendere in considerazione.


 Anche tu torna a ripassare...
un pochino utopistico.
se sei a 7 ore e 59 minuti ma ti serve altri dieci minuti rimandi al
giorno dopo? nemmeno io faccio 8 ore di fila inchiodato tra pausa
pranzo, caffe, 626, etc... magari le 8 ore lavorative diventano 10 alla
scrivania no?
si fa per dire cmq eh...