Product manager – responsabile di prodotto

Quali sono le responsabilità di un Product Manager? Cosa lo differenzia da un responsabile di progetto? In quale posizione della gerarchia organizzativa dovrebbe trovarsi?

E soprattutto, quali caratteristiche, quali competenze bisogna possedere per essere un buon responsabile di prodotto? Serve una formazione appropriata, sostiene Ellen Chisa in “Evolution of the Product Manager“, ACM Queue, october 2014.

Criticità dei backup

I backup sono necessari, e sono critici sia per i singoli individui che per le organizzazioni. Figuriamoci per uno stato.

L’Estonia, che ha già subìto attacchi informatici nel 2007, si sta preparando a fronteggiarne altri possibili in futuro, come racconta questo articolo di The Economist: “How to back up a country“.

Alcune delle lezioni apprese dagli estoni in questo progetto sono familiari, anche se ardue da mettere in pratica:

“the better data and networks are organised, the better the system is documented, and the more standardised and up-to-date the software, the easier it is to back up and restore.”

Exploratory Testing 3.0

Una ridefinizione della pratica di testing esplorativo è stata proposta da James Bach e Michael Bolton , per superare la distinzione tra  il “testing guidato da script” e, appunto,  il “testing esplorativo”:

we now define all testing as exploratory.  Our definition of testing is now this:

“Testing is the process of evaluating a product by learning about it through exploration and experimentation, which includes: questioning, study, modeling, observation and inference, output checking, etc.”

Secondo il loro punto di vista, il testing guidato da script può essere solo uno strumento tattico da usare in particolari situazioni, ma è come un ospite in casa d’altri, un elemento estraneo al vero e proprio testing.

In quali casi è opportuno lavorare in coppia

Il pair programming (programmazione in coppia) è una delle tecniche “classiche” di extreme programming.

Ora il principale esponente di quell’approccio agile, Kent Beck, propone una ipotesi in merito a quando la programmazione in coppia funziona, e quando no: Pairing as Pruning.

In sintesi, lavorare in coppia è utile quando ci sono incertezze in merito alla definizione del problema da risolvere, e al modo in cui può essere risolto. I problemi chiari con soluzioni ben definite non necessitano secondo Beck di collaborazione, ma di automazione.

Software aziendale non richiesto dal settore IT

Secondo una stima di Gartner ripresa da The Economist, nel 2017 lo sviluppo software avrà come come committenti più le funzioni marketing che il settore IT.

Non solo, quindi, il settore IT non ha più la responsabilità di sviluppare direttamente il software che fa funzionare l’organizzazione (outsourcing dello sviluppo). Viene anche lasciato fuori dalla definizione dei requisiti, e dal processo di accettazione.

Tendenza in atto da anni, e ormai consolidata in molte aziende, ma altamente rischiosa, se non vengono potenziate le capacità di presidio.

 

di Adriano Comai, per lo sviluppo software.