Ranting as usual

Tema per l’esame di qualche corso di business administration.

Il candidato esamini l’organizzazione delle seguenti aziende di software e descriva, motivandole, le probabilità di successo per ciascuna, tenendo conto delle condizioni di mercato in Italia.

Azienda A

Il concetto di “versione” è superato. L’idea di “build” altrettanto. Quando c’è qualcosa di pronto si rilascia. Le installazioni dai clienti sono identificate come “la compilazione del 3 Giugno alle 18.34“.

Quando c’è un’esigenza nuova, non si integra nel prodotto ma si fa un bel verticale custom per il cliente X. La stessa esigenza del cliente Y ? Un nuovo custom, embè ?

Non esiste alcuna documentazione dei custom sparsi in giro.

Il bug tracking non serve. La comunicazione dei problemi avviene per telefono, e-mail, nei giorni pari a voce nel corridoio, nei giorni dispari con file excel o word.Ogni problema è bloccante e a priorità massima.

Prima di cercare di risolvere i problemi, si passa la questione a R&D, non sia mai che ci pensano loro e si evita lavoro inutile. E’ inutile anche descrivere i problemi, basta dire “c’è un errore, vedete voi“. I log ? Sono dal cliente, basta collegarsi e andarli a prendere, embè ?

Le nuove richieste sono espresse a caso, alla prima persona che passa, o in piedi in cucina mentre si mangia la pasta.

Pianificazione, roadmap: inutili formalismi. Le priorità cambiano ogni settimana. Si fissa una data poi si elencano tutte le feature che dovranno essere consegnate.

R&D si scrive le specifiche, le implementa, scrive i manuali, esegue i test e va a installare. Delivery nel frattempo implementa custom.

Le risorse di R&D possono essere contattate da cani e porci e messe a lavorare su qualunque idea o progetto che passa per la testa.

Il prodotto, una volta stabilizzato, può anche fermarsi per due o tre anni per mandare tutti dai clienti a fatturare.

Ciascuno in definitiva fa quello che gli pare.

Azienda B

Ogni versione è contraddistinta da un numero major e un numero minor. Ogni anno, salvo esigenze speciali, si rilascia una major e al massimo due-tre minor. Una procedura automatica crea i build e assegna loro un identificativo univoco.

I rilasci sono pianificati con buon anticipo. Ciò che non rientra in un rilascio va nel successivo. Le priorità sono chiare e condivise.

Il prodotto ha un’identità precisa e ogni esigenza è valutata in merito a quanto può arricchirlo in generale, non in particolare.

Delivery, Marketing, Sales propongono nuove feature. Il Product Management scrive le specifiche. R&D analizza,  implementa. QA esegue i test e approva i rilasci. Delivery scrive i manuali e installa dai clienti.

Le risorse di R&D sono coordinate dal solo responsabile di R&D.

Ogni problema è analizzato primariamente da Delivery che scala a R&D soltanto dopo avere verificato che si tratta di un bug. Viene inserito in un sistema di bug tracking, completo di numero di build, analisi, istruzioni e dati per riprodurlo, log.

Il prodotto è in continua evoluzione perché i concorrenti non stanno a guardare.

Ciascuno in definitiva ha un proprio ruolo e responsabilità.

Annunci

Rispondi

Inserisci i tuoi dati qui sotto o clicca su un'icona per effettuare l'accesso:

Logo WordPress.com

Stai commentando usando il tuo account WordPress.com. Chiudi sessione / Modifica )

Foto Twitter

Stai commentando usando il tuo account Twitter. Chiudi sessione / Modifica )

Foto di Facebook

Stai commentando usando il tuo account Facebook. Chiudi sessione / Modifica )

Google+ photo

Stai commentando usando il tuo account Google+. Chiudi sessione / Modifica )

Connessione a %s...


%d blogger hanno fatto clic su Mi Piace per questo: