La strada rapida…

Taaanto tempo fa fa mi sono ritrovato a riflettere se aggiungere o meno una certa funzionalità ad un progetto che stavo sviluppando per lavoro. Nulla di trascendentale ma piuttosto secondario rispetto agli obiettivi del progetto.

Che fare in questi casi?

Non è la prima volta che mi trovo in questa situazione per cui ormai ho sviluppato una sorta di protocollo operativo di come comportarmi in questi casi.

Step 1. Analizzare la funzionalità

Analizzare la funzionalità significa sostanzialmente valutarla presa come singola entità e, nell’ottica di un’integrazione, dell’aumento di valore per il progetto che la ospita.

Sostanzialmente bisogna capire se si vuole aggiungere qualcosa di potenzialmente utile – economicamente, strategicamente e funzionalmente – oppure palesemente superflua. Ovviamente il secondo caso è uno “showstopper“, ossia blocca sul nascere qualunque azione successiva.

Un semplice discorso sul genere “mi piace l’idea e vorrei realizzarla” è una condizione del tutto insufficiente come pretesto o motivazione: nello scontro fra gli interessi personali e quelli dell’azienda, salvo casi particolari, la priorità va e deve andare a quelli della seconda, che paga per il nostro lavoro.

Avere un’idea precisa del valore della feature da aggiungere significa quindi anche poterla motivare. Una regola empirica abbastanza banale dice che:

“Se non sei in grado di motivarla, probabilmente non serve davvero: lascia perdere!”

Supponendo che non sia così, ossia che la nuova funzionalità abbia una sua precisa ragion d’essere, a questo punto vale la pena ipotizzare quanto tempo e quali risorse servano per implementarla.

Si aprono quindi due strade: procedere per via ufficiale, burocratica oppure per via semi-ufficiale, diciamo così.

Step 2. Scelta della strada giusta

La prima strada è quella canonica del chiedere ed ottenere il nulla osta ufficiale per poter procedere. Questa è la situazione da preferirsi in gran parte dei casi, ma anche la più lunga nei tempi e nei modi, sopratutto se vige la prassi del:

“Non si muove una foglia se non esplicitamente autorizzata!”

La seconda via è del tutto simile alla prima ma decisamente più rapida e, a detta di alcuni, è una sorta di “regalo all’azienda“, perchè implica l’utilizzare parte del proprio tempo “extra”, per esempio le proprie pause o addirittura il proprio tempo libero, per raggiungere gli scopi.

Prima che qualcuno cominci a storcere il naso o a darmi del matto, è bene ricapitolare la situazione:

• si vuole aggiungere qualcosa ad un progetto, qualcosa che a nostro modo di vedere aggiunge valore sebbene si tratti di qualcosa di interpretabile come secondario;
• per un qualche motivo non si può far rientrare la funzionalità fra quelle previste nel progetto, o non ci sono i tempi e le risorse per procedere in modo canonico, seguendo la prassi e la burocrazia aziendale;
• nonostante ciò si ha la certezza che la funzionalità serva e si nutre la speranza che, realizzata almeno in parte, si possa poi più facilmente motivarne l’esistenza in un secondo momento, mostrandola in funzione.

La strada rapida

Premetto che non si tratta di nascondere nulla a nessuno: per come è congegnata la cosa non serve un’autorizzazione formale in senso stretto, ma bisogna comunque avvertire chi di dovere dell’intenzione di voler procedere in un certo modo.

Se il vostro capo è sufficientemente flessibile, se da tempo avete già ottenuto la sua fiducia ed una certa carta bianca nelle vostre operazioni e, soprattutto, se siete in grado di spiegare cosa volete realizzare in più e perchè vale la pena farlo, si può partire subito.

Ovviamente sta a voi non farvi odiare ed evitare di passare per perditempo. Non puntate su funzionalità inutili, cavalli perdenti in partenza: se il gioco non vale la candela, non esiste scommettere.

Fatto ciò, si può partire e l’approccio migliore che ho trovato per esperienza include uno sviluppo su un binario parallelo e quanto più possibile slegato da quello ufficiale.

Parallelo non incidente perchè la funzionalità viene sviluppata fuori dall’orario di lavoro canonico, possibilmente in un progetto separato da quello aziendale con le funzionalità principali.

Ad esempio si sviluppa una porzione del codice “freestanding” (es: progettino-pilota o anche solo uno scheletro di codice, un banco di prova minimo per sviluppare e provare la funzionalità) e quando è sufficientemente maturo lo si integra nel progetto aziendale: il tutto richiede normalmente pochi minuti, se il lavoro è svolto bene.

Il fatto di lavorare in modo separato implica che non avrete la necessità di portarvi dietro il codice aziendale (comportamento normalmente e giustamente vietato) e che quanto producete in questo modo non disturbi il progetto principale (cioè niente bug addizionali).

Nel caso la funzionalità dipenda strettamente dal codice principale, createvi qualche oggetto finto (mock object) e fate largo uso di metodi stub: non dovete ricreare il programma principale, semplicemente simularne l’interfacciamento.

Ovviamente il progetto principale deve risultare sufficientemente ricettivo delle funzionalità che poi integrerete: un’architettura a plugin è l’ideale ma potere anche ricorrere a qualche riga di preprocessore per includere/escludere velocemente i file.

Anche dopo l’integrazione, il codice deve essere e rimanere in ogni caso separato, visivamente e funzionalmente: in ogni momento dovete essere in grado di poterlo identificare ed eventualmente disabilitare o rimuovere del tutto.

Risultati?

Il risultato di quanto detto è la vostra funzionalità implementata ed integrata ma in modo lasco e perfettamente controllabile. Se il risultato non vi aggrada, potete tranquillamente rimuoverlo: l’azienda non ci avrà guadagnato nulla ma nemmeno perso e voi avrete accumulato esperienza addizionale.

Se invece l’esito è positivo, sta a voi farvi valere. Nel caso normale non guadagnerete nulla, nemmeno il rimborso del tempo extra che avete dedicato (dopotutto lo avete fatto di vostra iniziativa), però di solito la propensione a fare di più (magari anche sperimentando ed innovando, qualcosa che non sempre si può fare abitualmente o che richiede troppe formalità e burocrazia) non passa inosservata, diciamo così.

Per quanto riguarda l’aspetto legale, non sono un avvocato (“IANAL” per gli amanti degli acronimi), ma si parla di qualcosa che nasce con un intento buono, realizzato a mo’ di regalo e pensato con le accortezze minime perchè non crei disturbo di alcun genere all’azienda o al prodotto principale stesso: dopotutto siete voi gli sviluppatori dell’uno e dell’altro, no? Chi meglio di voi può riscirvi senza fare danni?

Che ne pensate?