Newsgroup: it.lavoro.informatica
Titolo: [MOLTO LUNGO] Mi piacerebbe fare...

Ciao a tutti,
scrivo per sottoporre alle critiche (costruttive) un'idea che da qualche 
tempo mi tormenta e che mi piacerebbe discutere per capirne le eventuali 
potenzialità.
Premetto che sono socio di una piccola software house di torino e 
pertanto conosco bene le problematiche "dal lato PICCOLO imprenditore" 
che questo lavoro comporta.
L'idea a cui mi riferisco parte dalla considerazione che esitono ormai 
parecchi progetti opensource di successo sviluppati in modo congiunto da 
sviluppatori (ma anche grafici e altri profili) distribuiti su tutto il 
pianeta. In sintesi si tratterebbe di creare una sofware house "senza 
sede", o meglio una sede potrebbe anche esserci ma i team di sviluppo 
sarebbero collaboratori remoti.
A questo punto la cosa può sembrare cosi' banalizzata da essere 
liquidata con una tra le mille critiche possibili, e per questo provo ad 
elencarne alcune da me identificate con le potenziali soluzioni.
Q) La collaborazione remota (detta anche telelavoro) è dimostrato che 
non funziona.
A) In effetti ci sono moltissimo casi fallimentari ma ritengo che 
attuando una serie di processi basati su strumenti opportuni possa 
essere funzionante.
Q) Bene, quali processi e strumenti?
A1) Inizio dagli strumenti: da skype a messenger ormai tutti i software 
di IM supportano funzioni di conferenza che, superato il blocco 
psicologico di utilizzarli in ambito professionale, risultano più che 
adeguati anche con le ADSL casalinghe.
Per quel che concerne la collaborazione sul software strumenti di source 
control come SubVersion (ma anche altri) sono già usati con ottimi 
risultati in moltissimo ambiti distribuiti. In realtà il set di 
strumenti è molto vasto ma ritengo che tutti gli aspetti siano ad oggi 
coperti da altrettanti tool.
A2) Per i processi è evidente che per ogni progetto ci andrebbe un 
coordinatore che è anche quello che tiene i rapporti con il committente 
(se esiste un committente) e che attua i controlli di avanzamento 
lavori. In realtà ogni progetto diventerebbe un "ecosistema" a se 
organizzandosi nel modo più opportuno in funzione dell'esigenza. 
Naturalmente andranno definite delle regole di alto livello alle quali 
tutti dovranno conformarsi.
Q) Ok, senza dilungarci ulteriormente su strumenti e processi, 
supponiamo che l'idea parta. Il coordinatore, o meglio la software 
house, si assume una responsabilità nei confronti del committente (se 
c'è). Come garantirsi che uno sviluppatore situato dall'altra parte del 
globo non sparisca a metà progetto lasciando nella "bagna" la stessa ed 
il resto del team?
A) Non è ovviamente possibile creare garanzie di questo tipo come non è 
  possibile in una software house tradizionale garantirsi che uno 
sviluppatore si ammali a metà progetto lasciando la società nella stessa 
situazione. Diciamo che si possono attuare meccanismi di 
resposabilizzazione, per esempio il sistema di pagamento degli 
sviluppatori nella mia idea sarebbe basato su paypal o equivalente. 
Nulla vieta una versamento di una cauzione per ogni sviluppatore che 
partecipa ad un progetto che funga da garanzia (ovviamente sono ben 
accette proposte alternative).
Q) AH HA HA HA!! E quindi per lavorare doveri pagare?
A) No, una cauzione non è un pagamento perchè viene restituita. Il 
problema è che in una struttura tradizionale il rapporto tra 
collaboratori è regolato da opportune leggi in funzione dei contratti. 
Volendo partire con un'idea "sperimentale" all'inizio è conveniente 
rimanere molto "light" per ridurre gli investimenti e di conseguenza 
usare metodi "non troppo ortodossi" sui quali tarare la strategia futura.
Q) Riassumendo il processo dal punto di vista del collaboratore potrebbe 
essere: mi registro nella lista dei collaboratori, vedo periodicamente i 
lavori che sono attivi o devono partire. Se valuto di avere gli skill 
necessari sottopongo la richiesta di partecipazione ad uno di questi, il 
  coordinatore approva la mia richiesta e da li parte l'attività.
A) Si, il processo base è più o meno questo. L'idea è però che non si 
presenti solo lo sviluppatore ma anche colui che ha un lavoro da 
svolgere e non sa a chi farlo fare. Quindi diventa colui che sottopone 
un lavoro alla lista citat, questa attività è ovviamente fatta 
principalmente dalla software house. Inoltre il tutto si basa su 
rapporti umani forti, non c'è una sorta di bottone "partecipa al 
progetto" e la cosa si avvia, c'è sempre una fase di dialogo/colloquio 
tra le parti con i mezzi di conferenza descritti sopra.
Q) Se conosci le problematiche "lato imprenditore" sai che uno dei 
problemi grossi è farsi pagare, quale soluzione hai pensato?
A) Se avessi la soluzione a questo avrei molti meno problemi ;-) In 
realtà non c'è una soluzione se non quella classica di richiedere un 
anticipo e definire delle fasi di rilascio al quale corrisponde un 
pagamento. In ogni caso, parlando di sperimentazione, sarebbe opportuno 
partire con progetti medio/piccoli (le classiche web application tutte 
simili che nel nostro paese abbondano).
Q) Ok, ma parlando dei pagamenti va distinto il pagamento delle software 
house con quello dei collaboratori.
A) Si è vero ma, non essendo una banca, l'unico modo possibile è la 
condivisione del rischio. Salvo trovare investitori ma qui sforiamo 
nella fantascienza.
Q) Ma alla fine qual'è il reale vantaggio rispetto ad una software house 
tradizionale? Non è che vuoi fare il furbo e procurarti manovalanza a 
basso costo.
A) Il vantaggio è la dinamicità. Al giorno d'oggi è praticamente 
impossibile per una struttura di medio/piccole dimensioni crescere, 
ovvero creare un business cosi' solido da poter garantire i requisiti 
necessari a creare team di lavoro stabili e competenti. Va però 
considerato che molto del talento esistende è "sparpagliato" proprio tra 
queste piccole realtà. Quindi: o lasciare il mercato in mano alle grosse 
società che sappiamo come lavorano o provare alternative.
Per quel che concerne la "manovalanza a basso costo" nella mia idea ogni 
progetto avrebbe un budget pubblicamente visibile suddiviso in modo 
collaborativo (il dialogo) tra i partecipanti (con delle percentuali 
PUBBLICHE costanti per la software house che ha i costi di struttura).
Di dubbi/questioni ne esistono ancora a milioni ma per non fare un post 
chilometrico mi fermo qui e attendo le vostre considerazioni.
Grazie,
Fabrizio Guglielmino

 fantascienza.
Questo è ovviamente un punto debole. Personalmente credo che il rischio lo 
possano condividere dei soci ma non dei collaboratori che vengono 
naturalmente tenuti all'oscuro del prezzo finale pagato dal cliente e da 
tutti i dettagli contrattuali con esso.
In altre parole: i collaboratori VANNO PAGATI, altrimenti cercati dei soci.
My two cents.
-- 
Zonter 

 In altre parole: i collaboratori VANNO PAGATI, altrimenti cercati dei soci.
zonter si quota a priori, specie quando ha ragione
d.
-- 
Sai quelli che dicono: «Uno torna la sera a casa stanco...».
«Che strazio questo che torna sempre a casa stanco. Lo detesto.
Ma non tornare a casa! Sei stanco? Muori!». 
                                             ### E. Vaime

Zonter ha scritto:

Si hai ragione ma ho scritto alla fine che il budget è pubblico, tutti i 
partecipanti al progetto sanno quale costo sostiene il cliente per il 
progetto nel quale si è coinvolti e si definiscono anche i vari compensi 
in funzione di questo. Un punto debole in tal senso è dato da chi fa 
l'offerta che potrebbe sottodimensionare il costo ma è anche questo un 
problema che comunque esiste già in qualsiasi struttura.
ciao
Fabrizio

 chilometrico mi fermo qui e attendo le vostre considerazioni.
Per esperienza ho visto funzionare progetti con sviluppatori, grafici
e commerciali sparpagliati in tutta Italia.
Gli strumenti sono skype, un server in telecontrollo ed un buon ftp e
non serve altro.
Il problema è che il lavoro devono farlo professionisti (e vanno
trovati) con esperienza, gente che sa fare il lavoro (e non deve
imparare facendolo).
Solo che i professionisti (ovviamente) volgliono essere pagati bene e
fornire un prodotto di qualità, che raramente è richiesto o valutato
dal mercato.
L'aspetto commerciale è il secondo grosso problema, cercare e trattare
con i clienti. Chi lo fa ? Quanto viene pagato ?
Personalmente penso che invece di rivolgersi ai clienti una struttura
di produzione potrebbe/dovrebbe rivolgersi ai commerciali, fornendo
stime e prodotti affidabili ma permettendo un buon margine al
venditore.
Quindi l'idea secondo me è buona, ma bisognerebbe partire con la
ricerca di un commerciale e di clienti.

 compensi in funzione di questo.
Sì, ma il punto è che per me questi compensi dovrebbero essere debiti veri e 
propri per la ditta.
Mi spiego meglio: un conto è dire "vi pagherò non appena avrò i soldi" ma 
comunque i collaboratori hanno un pezzo di carta firmato nel quale la ditta 
si assume l'onere di versare loro - prima o poi, ma di sicuro - l'importo 
dovuto, ben diverso è "vi pagherò se mi paga il cliente finale, altrimenti 
ciccia" e questo - secondo me - è inaccettabile.
-- 
Zonter 

   coordinatore approva la mia richiesta e da li parte l'attività.
Ma vuoi fare un progetto opensource o una ditta geograficametne
dislocata? Non si capisce.
-- 
Lawrence, 
oluyede.org
 - 
neropercaso.it
"It is difficult to get a man to understand 
something when his salary depends on not
understanding it" - Upton Sinclair

in...@mostraip.it
 ha scritto:

In effetti il problema del professionista che, giustamente, richiede un 
adeguato compenso è se vuoi correlato al secondo.
Nel senso che il caso tipico è quello del commerciale che per portare a 
casa il contratto svende l'attività, questo genera la catena di eventi 
che tutti conosciamo (figure professionali sottopagate e tipicamente 
scarse, qualità del prodotto bassissima, gestione del progetto assente 
etc...).
All'inizio credo che la parte commerciale andrebbe centralizzata nella 
software house, quindi è un onere che si assume la struttura per creare 
il volano, ovviamente sarebbe interessante a tendere coninvolgere allo 
stesso modo delle figure tecniche quelle commerciali.

Zonter ha scritto:

Su questo concordo al 100% (ho vissuto l'esperienza sulla mia pelle 
essendo principalmente un tecnico), diciamo che per attuare 
correttamente l'idea la software house deve assumersi il rischio 
imprenditoriale come una realtà tradizionale pagando i collaboratori 
come pattuito ad inizio progetto al di la di come e quando il cliente lo 
paga alla stessa. Credo sia questo che intendi.....

Lawrence Oluyede ha scritto:

L'idea è una ditta geograficamente distribuita con scopo di lucro, solo 
con un approccio sulla falsa riga della consulenza. Nel senso che chi 
collabora non è dipendente della stessa ma partecipa a determinati 
progetti per i quali concorda un compenso economico quando avvia la 
collaborazione. Il consulente con partita iva fa già questo normalmente 
solo che lo fa lavorando fisicamente dal cliente e/o committente, in 
questo caso potrebbe farlo da dove meglio crede, quando gli risulta più 
comodo (compatibilmente con le scadenze del progetto).

 il cliente lo paga alla stessa. Credo sia questo che intendi.....
Esattamente,  garantire il pagamento dei collaboratori è un buon metodo per 
non vederli svanire nel nulla! :-)
-- 
Zonter 

> zonter si quota a priori, specie quando ha ragione
Troppo buono.
-- 
Zonter 

 chilometrico mi fermo qui e attendo le vostre considerazioni.
A me ancora non e' chiaro *chi* ci mette quel budget
Ciao,
Marco
-- 
questo articolo e` stato inviato via web dal servizio gratuito 
http://www.newsland.it/news
 segnala gli abusi ad 
ab...@newsland.it

 fatto dei bei talk su come gestire un team dislocato geograficamente:
A pPyConUno non hanno fatto dei talk specifici sull'agomento (almeno io
non li ho visti), pero' si intuiva che la cosa e' fattibile, anche
se alcuni sembrano contrari. Il punto e' che le motivazioni dei contrari
a me non hanno convinto nemmeno un po'.


 comodo (compatibilmente con le scadenze del progetto).
Questo che tu dici e' una mia idea da tempo immemorabile e se ne e' gia'
discusso  varie volte qui sopra. Molti sono contrari al lavoro
a distanza in se (non certo io), altri sono favorevoli al lavoro a distanza
solo se e' t.i. (non certo io), ecc. Se poi passi fuori da internet, per
non dire fuori dall'informatica, le percentuali sono ancora piu'
schiacchianti In altre parole la maggioranza dei
lavoratori informatici e non e' assolutamente contraria al lavoro a
distanza 
Ciao,
Marco.


 PUBBLICHE costanti per la software house che ha i costi di struttura).
Costi di struttura? Ma se il telelavoro e' fatto apposta per evitare i
costi di struttura?
Non e' che saresti tu il costo di struttura? ;)
Voler realizzare una software house "dispersa" non e' una cattiva idea
secondo me,
ma dovresti innanzitutto chiarirti le idee su questo: vuoi farla su
modello collaborativo
cioe' con una serie di soci che dividono in maniera equa eventuali
profitti, o sul modello
classico in cui tu sei il capetto e gli sviluppatori sono i tuoi
impiegati?
Dovresti riflettere sul fatto che affinche' un sistema del  genere
funzioni dovresti avere a
disposizione dei programmatori e dei grafici di alto livello, e un
professionista di alto livello
non lavora per delle noccioline o delle promesse. Quindi in entrambe
le tipologie di organizzazione
dovresti garantire una retribuzione degna di questo nome. Se non lo
farai attirerai solo
persone poco competenti, e nonostante la tua buona volonta' nessun
progetto funzionera' bene
se affidato a incompetenti. In sostanza l'unico patrimonio di una
software house "distibuita" sono i suoi
elementi. In altre parole, un team di sviluppatori motivati (ben
pagati) e cazzuti puo' fare cose che voi umani nemmeno immaginate ;)
Ma se parti con l'idea che a questi sviluppatori vadano i soliti mille
eurini al mese lascia perdere.


www.guru.com
Sorry, ma per questo non c'e' bisogno di te.