Lavorare di meno != produrre di meno…

Probabilmente avrete già sentito parlare di questa storia, ma voglio riproporvela con due considerazioni finali.

As for productivity, the sociologist Arlie Hochschild in one of her books mentions an IT company that were in big financial trouble. Rather than lay some people off they switched to a 30-hour work week and a corresponding pay cut, and experienced no reduction in production. They did the exact same amount of work in 30 hours a week as in 40.

Fighissimo😀 e allora lavoriamo di meno…. eheheh

A parte gli scherzi mi sono trovato proprio di recente a dover confermare questa teoria, per un problema di consegne rapide di una valutazione, e ho visto che effettivamente la scadenza ravvicinata mi faceva lavorare di più: ma in che senso lavorare di più?

Il tempo che normalmente una persona spende dietro la scrivania, solitamente 8 ore, sono comprensive di:

  • lavoro
  • lettura/invio mail
  • lettura di notizie da repubblica/blog
  • scrittura di post
  • ricerca di informazioni personali
  • formazione
  • pausa caffè
  • pausa merenda

e chi più ne ha più ne metta… ho elencato solo le mie principali attività durante una giornata modello di lavoro😀.

Quindi il mio lavorare di più in questa ottica è stato, nello stesso arco di tempo giornaliero, dare maggiore priorità alla vera attività di produzione, eliminando quasi completamente le restanti attività, negative rispetto alla quantità di lavoro svolto.

Per questo motivo penso che le iterazioni brevi di XP funzionino: perchè avendo scadenze brevi ci si concentra meglio sul problema.

Purtroppo essendo assegnato a questa attività con un altro collega che chiameremo chatters per la sua formidabile abilità a chattare con 5/6 finestre di IM tra msn e il talk, mi sono ritrovato in certi momenti in una situazione di elevato stress, vista la data di consegna anticipata per me segnata dalla mia partenza per le vacanze.

Per etica professionale ho voluto concludere il tutto prima di partire, ma in questo mio obiettivo il mio compagno di merende ne ha approfittato: invece che dare una mano a remare praticamente ha remato contro, visto che oltre a sorbirmi il doppio lavoro mi dovevo pure sentire scarrellate di tasti battuti con la delicatezza di un elefante, che facilitano la concentrazione per il problem solving.

Il pair programming si è rivelato deleterio in questo caso, soprattutto perchè questi problemi rimanevano nascosti al gruppo, visto che l’unica possibilità di venirne a conoscenza sarebbe stata quella di esporre la situazione al mio responsabile. Purtroppo questo tipo di elementi all’interno di un task di sviluppo sono le classiche mele marce che compromettono la qualità del lavoro piuttosto che quella del codice.

Il tutto è stato amplificato dal fatto che abbiamo lavorato su questa attività senza ruotare le coppie, aumentando i momenti e i motivi di attrito tra i componenti. Oltretutto a ogni scrum meeting questo tipo di persone trovano sempre qualcosa da recitare, e quindi questo incontro giornaliero senza strumenti di controllo quali uno sprint backlog piuttosto che le carte che tracciano i tempi di stima ed effettiva attività non funzionano, ma di questo voglio parlare in un post successivo dedicato allo scrum.

Lo stereotipo del “più ore = più produttività” è praticamente un caposaldo dell’IT. Una relativa abitudine che chiameremo adattamento al lavoro è che gli impiegati per mostrarsi disponibili a fare straordinario, si “parcheggino” dietro le loro scrivanie. Solitamente quello che ho potuto vedere nella mia esperienza in qualità di consulente presso il cliente, dove lo straordinario non è nè pagato nè richiesto, è che nonstante tutto persone non motivate su 8 ore ne lavorino a malapena un terzo.

Quello che purtroppo ho maturato per esperienza è che la natura umana porta a una certa volontà di “vendicarsi” di certe situazioni, e in questo momento ho un conto in sospeso con qualcuno.

Spero andando in vacanza di poter lavare via questi pensieri assolutamente negativi all’interno di un team di sviluppo…

Mazi

5 Responses

  1. Queste è l’esperienza comune.

    Però tutte le attività che fai nelle 8 ore di lavoro, sembrerà strano, ma le fai proprio perchè il tuo lavoro renda di più.

    Se non lavori, non hai bisogno di riposarti, di fare una pausa.
    Se non lavori, non hai bisogno di informarti sulle novità che possono migliorare il tuo lavoro, la tua produttività.
    Se non lavori, non hai bisogno di condividere le esperienze tecniche e metodologiche scrivendo e leggendo i blog.
    Se non lavori, non hai bisogno di socializzare con i colleghi, li puoi mandare tutti a cagare🙂

    Io penso che il lavoro sia una lunga maratona, a volte puoi fare lo sprint, ma non puoi sempre correre come se facessi i 100 metri, prima o poi in qualche modo schiatti.

    E poi quei tipi lavoravano 30 ore, ma guadagnavano anche di meno e tutte le attività di cui sopra se le portavano a casa a loro spese, sperando un giorno di ritornare a guadagnare per 40 ore.

    Le vacanze sono sempre la miglior cura, per tutto🙂

  2. In alcune aziende dove si fa XP hanno tempi fissi per tutto, compreso mail, auto formazione etc. L’alternarsi lavoro/pausa è indicato con un timer che scatta ogni 20/25 minuti (unità identificata da un pomodoro; 1 pomodoro= 25 minuti). Sono minuti di lavoro in coppia di lavoro effettivo, senza agenti esterni.
    Ci sono momenti per le mail, momenti per il wiki, momenti per il tracking del lavoro (quanti pomodori ho lavorato su una story card).
    Tra poco, quando avrò finito il TomatoTimer programmabile, con pulgin per Eclipse, anche io passerò al pomodoro!
    Chatters (che io ho visto….. ragazzi), ha semplicemente capito male, ha il pomodoro a 5 minuti, con 25 di pausa🙂

  3. posso solo confermare che lavorare 30 ore non è molto meno produttivo che lavorarne 40.
    Lo so perché io lavoro 30 ore e, quando stimo i progetti, li stimo in Giorni Uomo; quando il progetto viene assegnato è indifferente se viene assegnato a me o ad un’altra persona che lavora 40 ore: i GU restano gli stessi…

    Questo perché la concentrazione, per un lavoro impegnativo come la programmazione, è per forza di cose limitata nel tempo.

    L’uno vero caso in cui trovo che le 40 ore sono “meglio” di 30 è per la risoluzione di problemi, non tanto per i bug (maggior concentrazione equivale a meno bug!) ma per i problemi di installazione/configurazione di ambienti di sviluppo, prodotti esterni e così via…

  4. Se vi sono apprezzati i necessari complimenti, lascio qui un modesto commento per attestare il mio apprezzamento per l’eccellente vostro lavoro. Buona giornata!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: