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à.