Corsi on-line

Sviluppatori e commerciali, breve manuale di sopravvivenza

Non sempre, anzi in buona parte dei casi succede fortunatamente il contrario, ma qualche volta i commerciali sono persone che non sanno di cosa stanno parlando mentre vendono prodotti a clienti che non hanno idea di cosa stanno comprando. A pagarne le spese sarà lo sviluppatore, costretto a modifiche e aggiornamenti richiesti da utenti che non hanno acquistato quello che volevano e sono privi delle competenze necessarie per spiegarlo.

1Parliamo di un circolo vizioso che presenta alcuni passaggi obbligati:

  1. un’azienda richiede un’applicazione allo sviluppatore;
  2. lo sviluppatore fa il suo lavoro: progetta, implementa, testa, esegue il debugging e prepara il software per la distribuzione, tutto secondo le specifiche ricevute dal committente;
  3. il commerciale contatta un cliente e gli presenta l’applicazione ignorando del tutto le specifiche;
  4. il cliente, a cui non è dato conoscere le specifiche, chiede se nel software sono presenti funzionalità che, naturalmente, non erano previste nel progetto iniziale;
  5. il commerciale deve vendere, quindi risponde affermativamente a qualunque domanda, sapendo che qualsiasi situazione dovesse venirsi a creare, anche la più imbarazzante, sarà lo sviluppatore a doverla risolvere.

Alla fine l’azienda avrà avuto l’applicazione che desiderava, il commerciale avrà venduto e il cliente avrà speso per ciò che credeva di aver comprato. Il finale felice è assicurato per tutti, tranne che per lo sviluppatore.

Inizierà quindi un nuovo circolo vizioso dove il concetto di “personalizzazione” corrisponde pericolosamente a quello di “da zero”. Lo sviluppatore perderà tempo e pazienza sapendo che riferirsi alle specifiche sarebbe del tutto inutile, nessuno le ha lette.

Come riuscire a conservare la sanità mentale in una situazione dove tutti sono intenzionati a pregiudicarla credendo di essere in perfetta buonafede? Vediamo quali potrebbero essere le soluzioni praticabili:

  1. modularità: i sorgenti monolitici saranno i vostri più acerrimi avversari, adottate quanto più possibile il paradigma ad oggetti (PHP,Java..) nell’implementazione delle feature e l’approccio per componenti (JavaScript, React..) per le interfacce;
  2. riusabilità: la capacità di astrazione vi salverà la vita, badate a come progettate classi, interfacce e metodi; quando potete non siate maniaci della specializzazione, creare funzioni che accettano solo parametri specifici potrebbe renderle inutili ai fini del riutilizzo;
  3. boilerplate: dovrebbe essere un aspetto scontato e invece non lo è (avete presente WordPress?), gli aspetti legati alla presentazione devono essere sempre separati da quelli funzionali, altrimenti vi troverete a dover gestire modifiche monumentali ogni volta che verrà richiesta una minima modifica all’interfaccia utente o al vostro sorgente;
  4. Open Source: se non volete che “personalizzazione” significhi realmente “da zero” evitate di farvi trascinare dal fascino del from scrath, nessuno vi premierà per l’originalità dei vostri sorgenti, quindi tenete presente che in Rete ci sono così tante versioni della ruota da rendere inutile (e non esattamente razionale) il doverla reinventare. Non si tratta di un invito ad ignorare le best practice per il coding, semmai parliamo del contrario facendo riferimento a ciò, non poco, che è già disponibile in forma ottimale.

Un ultimo dettaglio, forse dispensare consigli non è compito di chi scrive, ma è fondamentale ricordare che nel lavoro si ottiene spesso quello che si contratta e non quello che si vuole; tenetene conto quando avrete a che fare con i commerciali.

Post correlati
I più letti del mese
Tematiche