Capo1: Senti sei impegnto le prossime 2 settimane?

Io: sì. Dobbiamo consegnare il progetto ultra/urgent/senonconsegnamocifannounculocosì.

Capo1: Capo2 mi ha detto che puoi dedicarti contemporaneamente a quest’altra cosa. Tanto ti ci vogliono solo un paio di giorni, ti mando la documentazione.

… leggo…

Io: Capo1, chi ha fatto la stima di sta cosa? Ci vogliono minimo 20 giorni per svilupparla.

Capo1: Ma come???!?!? Capo2 mi ha detto che in qualche ora si faceva. Abbiamo già fatto l’offerta, già ce l’hanno accettata (e ti credo N.d.me), se non consegnamo fra 3 giorni, si parla di penali!

Io: O abbiamo i commerciali più veloci del west che fanno offerte e fanno firmare contratti a caso, oppure di sta cosa si sa da un sacco di tempo ma non mi avete interpellato per i tempi di sviluppo.

Capo1: Ehm… ma adesso come facciamo????

Io: boh (Trad: cazzi vostri)

tutti uguali… piccoli, grandi, medi… mah

Out.

Eccomi qua, dopo un anno e mezzo circa era ora (!?) di cambiare di nuovo lavoro. Pare che i conttratti a tempo indeterminato, per me, siano più flessibili degli altri. :)

Da tipica aziendina informatica sono passato a grossa aziendona informatica. Cambierà qualcosa? Intanto mi sono perso per i corridoi del sesto piano…

out.

ClienteCoiSoldi, dopo settimane di incertezza, ci commissiona un nuovo lavoro…

CCS:Potete farci avere una stima dei giorni per domani?

Io/Noi: Ok, però visto che dobbiamo interfacciarci con i vostri sistemi A, B, C, ci servirebbero le specifiche per fare una stima decente.

CCS: Quelle del sistema A non le abbiamo, bisogna sentire l’omino che gestisce il sistema A. Quelle del sistema B non le abbiamo, bisogna sentire l’omino che gestisce il sistema B. Quelle del sistema C non le abbiamo, bisogna sentire l’omino che gestisce il sistema C.

Io/Noi:Vabbè, almeno diteci se useremo WS, RMI, HTTP, TuSorella, ecc…

CCS: Non lo sappiamo, per il sistema A bisogna sentire l’omino che gestisce il sistema A. Non lo sappiamo, per il sistema B bisogna sentire l’omino che gestisce il sistema B. Non lo sappiamo, per il sistema C bisogna sentire l’omino che gestisce il sistema C.

Io/Noi: Ok, ci dato un cantatto di ominoA, ominoB, ominoC?

CCS: ominoA è malato, ominoB è in ferie, ominoC è disponibile (evviva)

Io/Noi: Ma andate a cacare (No, questo non l’abbiamo detto ma l’abbiamo pensato intensamente).

out.

Da ciente arrivano le nuove specifiche:

Si richiede lo sviluppo delle seguenti robe:
Requisito 1
Requisito 2
Requisito 3
Requisito 4

Passano n giorni e si rilascia il pacchetto contenente i nuovi requisiti.

n+m giorni dopo arriva una mail:
Potreste rilasciare un pacchetto senza il Requisito 4 perchè, lato nostro, non siamo pronti?

Ok rilascio.

n+2m giorni dopo arriva un’altra mail:
Potreste rilasciare un pacchetto senza il Requisito 3 perchè, lato nostro, non siamo pronti?

Ok rilascio.

n+3m giorni dopo arriva un’altra mail:
Potreste rilasciare un pacchetto senza il Requisito 2 perchè, lato nostro, non siamo pronti?

Ok rilascio.

n+4m+vacanzenatalizie giorni dopo arriva un’altra mail:
Potreste rilasciare un pacchetto senza il Requisito 1 perchè, lato nostro, non siamo pronti?

Ma io gli ultimi n+4m+vacanzenatalizie giorni che ho lavorato a fare??

Mah…

Questa settimana si è finalmente sbloccato un progetto da ‘cliente importante’.
Bene, aspettavamo da un mese che ci dessero il via (che l’ufficio acquisti di ‘cliente’ approvasse la spesa).

Quindi in teoria io starei lavorando su questa cosa da consegnare a fine mese… in teoria perchè il simpatico ‘cliente’ ci ha dato il via senza darci uno straccio di requisito, una specifica, un documentino, una chiacchierata di 5 minuti, ecc.

Vabbè, vorrà dire che inventerò.

Si può andare avanti così? (Domanda retorica: si va sempre avanti così…)

out.

PM. A: Ok, con PM. B e superCapo abbiamo deciso che dalla prossima settimana sarai all’80% sul progetto A e al 20% ti lasciamo al progetto B.

***

Il giorno dopo:

PM. B: Ok, abbiamo deciso con PM. A e superCapo che dalla prossima settimana sarai all’80% sul progetto B e al 20% sul progetto A.

***

Io al PM A. verbalmente: Senti un po’ PM.A, guarda che mi avete detto due cose diverse tu e PM. B.

PM.A: Sì,sì, tutto chiarito. Ho ragione io.

***

Io al PM. B. via mail: Senti un po’ PM. B mi confermi che sto all’80% su A come dice PM. A ?

PM. B: Certo che no. All’80% su B e al 20% su A come avevamo detto.

***

Io dal superCapo: Supercapo, PM. A e PM. B dicono entrambi che sto principalmente sul loro progetto. A chi do retta?

superCapo: Boh, senti loro…

***

160%… la matematica è morta.

out.

Cliente. Ma perchè se hai accettato un’offerta che dice che ci vogliono 30 giorni-uomo e gli uomini sono 2 adesso mi vieni a dire che fra 5 giorni vuoi il progetto finito?

Perchè, ogni santa volta, ti dobbiamo sventolare sotto il naso il documento che TU hai firmato per ricordarti le condizioni? Lo leggi quello che firmi?

Cliente. Mi dispiace per te, ma stavolta ti arrangi.

Eccheccazzo.

out.

Nella mia ‘lunga’ carriera di lettore di libri tecnici, mi è capitato spesso di addormentarmi a metà di un tomone per non svegliarmi più (leggasi: librone abbandonato più o meno a metà). Questo accade soprattutto per la noia mortale che procura un libro tecnico, specialmente se l’argomento non è dei più appassionanti, come ad esempio una certificazione.

Mi è capitato recentemente, dovendo approfondire un po’ la conoscenza di qualche pattern architetturale, di leggere un libro della serie ‘Head first’ della O’Reilly: questo.

In questa serie, in cui non ci sono libri ‘reference’ ma manuali destinati ad insegnare qualcosa, si utilizza un approccio molto diverso. Vengono utilizzate tecniche tipiche delle scienze cognitive per raggiungere il più velocemente possibile l’obbiettivo di far capire l’argomento di cui si parla, in particolare con l’ausilio di diagrammi, disegni, dialoghi, esempi di codice commentati ‘a mano’, nuvolette fumeettose.

Detto così può sembrare un approccio quasi infantile, in effetti è la prima impressione che ho avuto aprendo il volume. Mi sono ricreduto molto presto, quando i capitoli filavano via lisci e i pattern mi entravano in testa rapidamente.

In definitiva consiglio caldamente i libri di questa serie. Ce ne sono molti in catalogo, dai linguaggi di programmazione alle tecniche di design.

Qualche link:

Catalogo ‘Head First’ di O’reilly

Head first Labs

out.

Quando parlo di cliente intendo Cliente con la C maiuscola, uno di quelli che hanno migliaia di dipendenti, centinaia di fornitori ecc.
Il Cliente si compone di una serie di sottoclassi, in particolar modo l’IT e il famigerato ‘cliente interno’.

Premessa per chi non lavora nel mondo dell’informatica.
Nelle grandi organizzazioni il ‘cliente interno’ è la sezione (marketing, CS, Amministrazione, ecc…) che chiede un prodotto software al dipartimento IT (da ora solo IT).
IT che, in genere, di IT non capisce una ceppa si rivolge al fornitore che, nel 90% dei casi, si rivolge a fornitoreFeudatario. Tralasciamo il fatto che anche fornitoreFeudatario spesso chiede l’assistenza di forniteroVassallo, fornitoreValvassore e fornitoreValvassino.

Il probema nasce proprio dal fatto che spesso IT non capisce un tubo di informatica e promette al ‘cliente interno’ qualsiasi cosa, tanto poi ci pensa fornitore. Fornitore se ne frega tanto poi ci pensa fornitoreFeudatario che è costretto ad accettare qualsiasi lavoro per tirare a campare.
Ovviamente lavoravo e lavoro per fornitoreFeudatario, anche se quello attuale riesce abbastanza spesso ad essere Fornitore e basta

Alla fine di ogni cappero di progetto a cui ho preso parte negli ultimi mesi succede sempre la stessa cosa.
Prima fase: consegnamo il progetto, Fornitore è contento,  IT è entusiasta, ‘cliente interno’ è incazzato perchè non ha avuto quello che voleva, IT scrive un nuovo documento di un gozziliardo di pagine senza senso con le modifiche richieste da ‘cliente interno’ e lo passa la fornitore che lo passa a fornitoreFeudatario.
Seconda fase: fornitoreFeudatario legge le specifiche, le butta nel cesso e fa le modifiche ritenute più logiche, Fornitore è preoccupato, IT si incazza perchè non sono state fatte tutte le modifiche, ‘cliente interno’ è contento perchè adesso funziona tutto come volevano e vuole parlare direttamente con fornitore per qualche dettaglio in più.
Terza fase: fornitore manda in incognito fornitoreFeudatario che parlando direttamente con ‘cliente interno’ che fa le richieste direttamente, 5 minuti dopo viene rilasciata una nuova release con quel cavolo di ‘a capo’ in più che ‘cliente interno’ voleva. Fornitore non capisce, IT non capisce, ‘cliente interno’ è entusiasta.

Considerando che fornitore è necessario per esigenze di mercato e IT non è sostituibile in aziende di mastodontiche dimensioni, cosa si potrebbe cambiare per migliorare un po’ la comunicazione tra chi chiede un’applicazione e chi la sviluppa?
Boh.

out.

Troppo lavoro e pochi aggiornamenti.

Volevo scrivere un articolo sull’iphone, in risposta a quello pubblicato su un blog amico (cercate e troverete). In particolare avrei voluto spiegare perchè, secondo me, l’iphone è un oggetto che non vale assolutamente il suo costo. Dal punto di vista di una persona che lo ha testato, lo ha usato e ha scritto webapp studiate apposta per il mattoncino.

Ma poi mi sono detto… ‘Ma chi se ne frega, torno al lavoro’.    ;)

out.