[ImoLUG] R: Procurarsi il lavoro da consulente informatico

Mer 17 Set 2008 00:05:08 CEST

Dimenticavo 2 dettagli,

1) in mezzo alle due figure ( programmatore-artista e committente ) ci
stanno in genere 2 entita' : il consulente, che e' inutile in quanto
non scrive codice, deve farci soldi anche lui in qualche modo e in
genere finisce solo per aggiungere entropia al processo. E il
"programmatore-lo-faccio-per-lavoro-ma-e'-un-lavoro-come-un-altro" che
e' altrettanto inutile per la scarsa qualita' di quanto produce e
perche' generalmente causa piu' danni di quanti ne risolva al
programmatore-artista assieme a cui di solito lavora.

2) Finora, non ho mai visto una soluzione decente all'intero problema.
La cosa che piu' ci assomiglia e' lavorare _fisicamente_ di fianco al
committente : portatile alla mano, liberta' di interrompere e fare
domande, e un po' di fantasia nel disegnare interfacce utente con i
post-it ritagliati. Ma senza bisogno di tirare fuori l'intero Agile
Manifesto, please.

/R.

On Tue, Sep 16, 2008 at 10:52 PM, Riccardo Govoni ☢
<battlehorse@gmail.com> wrote:
>> Tornando all'informatico ... è incredibile vedere gente che non ha mai fatto
>> economia aziendale mettere le mani su sw di gestione dai aziendali ... o
>> discettare di CMS senza avere alcuna nozione di marketing, branding etc ...
>> sanno solo quello che gli si dice e viene scambiato per "condivisione dei
>> saperi".
>
> Mica vero. Da 5 anni sono circondato di persone che si spaccano ( o si
> sono spaccate nel passato ) cercando  di spiegarmi come funziona una
> banca / una tv / una (grossa) forza vendite / il mondo cosicche' io
> possa svolgere al meglio il mio lavoro e trasformare le loro magiche
> parole in codice che funziona. Ovviamente, non ce la possono fare,
> visto che manco sanno cos'e' un min-heap.
>
> Scherzi a parte, nell'eterno problema dello sviluppo software e dello
> scambio di informazioni tra committente ed esecutore ci sono 2
> problemi fondamentali :
>
> Il committente sa' benissimo quello che vuole, ma non ha la piu'
> pallida idea di come farlo.
> Lo sviluppatore ( esecutore ) sa benissimo come scrivere 'cose che
> fanno cose', sa che con quello puo' risolvere tutti i problemi del
> mondo, ma capisce una mazza di cio' che il committente dice.
>
> Conseguenza : il committente parla sulla base dei propri sogni, lo
> sviluppatore scrive codice sulla base di quel poco che sa puo'
> tradurre in realta' ( o e' in grado di fare in tempo sufficientemente
> ristretto da guadagnarci qualche soldo )  e tutti sono tristi.
>
> Che e' lo stesso problema dell' idraulico :
> io: voglio il rubinetto aggiustato
> lui: son 200 euro
> io: sicuro? Da vedere non sembra complicato. Giusto quella vite li'
> lui: si, la vite e' ok. Ma il tubo non e' standard, perche' il
> precedente idraulico ha usato quello di gomma che non vendono piu'.
> Quindi devo martellare un adattore
> io: ma quello prima mi aveva detto che di gomma si sarebbero usati per sempre
> lui: eh si, ma il w3c ha cambiato le specifiche e adesso i selettori
> CSS3 hanno cambiato sintassi e tutti gli hash sha1 causano un
> off-by-one sull' EAX.
> io: eh??? vabbe', vada per i 200 euri. Chiamami quando fatto che devo
> fare la doccia.
>
> Vuoi per ignoranza generale del campo informatico, vuoi perche' e'
> difficile trovare i cosiddetti 'domain expert' che ne sanno sia del
> problema sia di come risolverlo, c'e' un fondamentale scisma tra le
> due figure.
> Da una parte, chi scrive codice ha generalmente una forte
> specializzazione nel proprio campo ( altrimenti e' un poveretto che
> crea pagine web con iWeb cercando di spacciarle per lavori di design )
> e disinteresse totale per il resto del mondo. Potesse, scriverebbe
> kernel, mica gestionali.
> Dall'altra, chi fa business in altro campo, non ha generalmente
> l'esperienza necessaria per capire cosa sia un lavoro di
> programmazione e considera il software come una commodity che si
> acquista in scatole.
>
> E' che la gente 'acquista' un lavoro informatico con lo stesso
> approccio con cui compri una Panda, mentre ci dovresti andare con la
> stessa cura con cui compri un dipinto fatto a mano.
>
> Qualcuno, tanto tempo fa, ha cercato di proporre al mondo lo sviluppo
> software come una disciplina di tipo ingegneristico, mentre e' molto
> piu' simile ad una disciplina artistica. Non e' un discorso idealista,
> ma se ci pensi, i tratti in comune sono parecchi. Se proprio vogliamo,
> una grossa software house puo' assomigliare ad una orchestra nei modi
> in cui ogni 'compositore' interagisce con gli altri ed e' in grado di
> garantire una certa qualita' / quantita' di lavoro continuativo, ma
> cio' non toglie che si rimane sempre musicisti.
>
> /R.
>
> P.s.: Mia personalissima convinzione, e' che e' tutta colpa di
> powerpoint e la sua mania di farmi disegnare tutte le schematiche come
> una serie di quadratini ben allineati con lineette di connessione. Mi
> facesse disegnare dei Rorschach, saremmo tutti molto piu' allineati
> alla realta' delle cose.
>
> On Tue, Sep 16, 2008 at 6:34 PM, antonino <antonino.attanasio@tin.it> wrote:
>> CUT
>>> Il bello è che si sta andando sempre di più verso lo scaricamento di
>> responsabilità
>>> sull'informatico perché costituisce la figura che più di ogni altra può
>> gestire in
>>> tutto o in parte quasi ogni processo/procedimento, ma imprescindibile a
>> monte
>>> una corretta compliance studiata a tavolino dai vertici aziendali.
>>
>> Non è del tutto vero questo ... diciamo che ciò che salva l'informatico è
>> l'assoluta mancanza di alcun potere gestionale. In pratica tutto si gioca
>> sull'equivoco del ruolo un po' come si faceva e si fa coi commercialisti.
>> Uno pensa di avere consulenza e assistenza fiscale e poi si ritrova al
>> massimo con la dichiarazione e i libri contabili formalmente tenuti. Del
>> famoso bilancino di verifica neanche parlarne e  men che meno di marketing
>> tecnica bancaria pianificazione e controllo di gestione e via dicendo.
>>
>> Lo stesso con gli avvocati. Puntano per lo più al foro dimenticando che un
>> VERO avvocato in tribunale non ci va. Perché quando si arriva in tribunale
>> si è già perso.
>>
>> Vogliamo parlare dei medici? Il medico generico sa un po' di tutto e niente
>> di poco. Per cui se uno non sta bene che fa? Il giro degli specialisti?
>> Ridicolo!
>>
>> Tornando all'informatico ... è incredibile vedere gente che non ha mai fatto
>> economia aziendale mettere le mani su sw di gestione dai aziendali ... o
>> discettare di CMS senza avere alcuna nozione di marketing, branding etc ...
>> sanno solo quello che gli si dice e viene scambiato per "condivisione dei
>> saperi".
>>
>> Insomma si può pensare allora di porre un freno a tanto sciupio di soldi e
>> di tempo dei committenti per pensare a una offerta integrata? Dove i saperi
>> si fondono armonicamente?
>>
>>
>>> Un esempio banale: quanti conoscono bene il decreto legislativo 231/01?
>>> Saluti
>>> Dott. Riccardo Corradino
>>
>> Buona questa ... ma io penso che anche solo il fatto di "conoscere" sia un
>> problema. Ma sai quando spesso si ha la visione dei problemi "giuridico
>> economico" come  "ciliegina" si perde di vista la reale dimensione dei
>> problemi
>>
>> antonino
>>
>> --
>> Mailing list info: http://lists.linux.it/listinfo/imolug
>>
>>
>