Repository GIT (sistema di versionamento del codice) - (#tecnico)

Purtroppo ad oggi vedo ancora molte realtà che non utilizzano un sistema di versionamento del codice.
La scusa “lavoro da solo nel team” non è accettabile e studiare git è davvero banale.
Chiedete sempre al vostro fornitore dove si trova il vostro codice sorgente (i più famosi sono Github, Bitbucket e Gitlab).

Ps. (per colleghi che mi conoscono) Per favore, non ridete :) "Ho visto cose che voi umani non potete neanche immaginare"

Team di sviluppo

Avere una panoramica dell’azienda e del team è sempre una buona abitudine.
Non dovete per forza conoscere tutti uno ad uno ma sapere che X persone lavoreranno al progetto (nel senso che sono persone del team interne).
Se ciò non accade, molto probabilmente il vostro progetto verrà commissionato a terzi.

Differente è se l’azienda spiega fin dall’inizio che il team è composto da X persone ma si avvale di collaboratori esterni per momenti di picco (ehi, molto probabilmente in alcuni casi sono io!)

Cosa da non sottovalutare: Magento2 non si sviluppa con 1 singola persona, serve un team(almeno 2 quindi - frontend e backend).

Metodo di lavoro

In un progetto e-commerce il metodo che risulta più efficace è l’Agile.
La modalità "contrattuale" più efficace è Time-Material.

Quindi in parole più semplici: lavorare con costo orario/giornata, stimare il minimo necessario e vedere i progressi con periodi prefissati (settimana / 15 giorni).

Un “prezzo finito” è molto ma molto difficile e le specifiche iniziali non saranno mai sufficienti.
Puoi avere un prezzo di massima ma tutto sta in base all’obiettivo finale, più cose ci saranno nel progetto e più di costerà (scegli bene ciò di cui hai bisogno).
Man mano che si lavora nuove specifiche verranno fuori e fare ogni volta il preventivo per avere un nuovo prezzo è un enorme spreco di tempo.

Su questa sezione è bene aprire una discussione a parte, a mio avviso il Time-Material è un metodo vincente.
In ogni caso: il fornitore dovrebbe spiegarvi qual è il suo metodo (a prescindere di quale sia).

Metodo di lavoro > strumenti di comunicazione e organizzazione

Alla larga da chi usa come strumenti di comunicazione SOLO email e telefono (peggio ancora se Whatsapp).

I motivi sono:

• le comunicazioni devono essere condivise (capita spesso che ci si scordi di mettere in CC tutti)
• le email non hanno uno “status”, quindi vanno nel dimenticatoio
• le email molto spesso partono con un oggetto e finisco con mille altre attività
• le chat su whatsapp sono con singola persona (i gruppi, peggio, sono la morte assoluta)
  • le chat con vocali sono la cosa che si dimentica prima di tutto

Meglio se:

• utilizzo di un sistema di gestione progetti: Asana, Trello, Teamwork, Jira, e tanti altri
• sistema di chat condiviso: slack, hipchat, discord e molti altri

Metodo di lavoro > pubblicazione e SLA

Chiedere se c’è una programmazione nelle pubblicazione e quali sono gli orari/giorni in cui il team lavora sul progetto ti farà risparmiare tempo nel chiedere quando sarà pronta una modifica (oppure fare richieste nei giorni dove ci sono persone del team attive nel progetto)

In linea di massima, generalmente potete trovare:

• pubblicazione delle modifiche (in blocco) 1 o 2 volte a settimana (tranne che per casi di emergenza) → di solito martedì/mercoledì
• non si pubblica di venerdì (se succede qualcosa nel fine settimana gli interventi slittano a lunedì)
• non si pubblica dopo le 17:00 (mediamente) - cercare di risolvere problemi dopo 8-9 ore di lavoro non aiuta, anzi molto probabilmente il fix sarà fatto con “leggerezza”

Ovviamente questo si applica solo se il metodo di lavoro è Agile.

Quindi, il fornitore che pubblica a qualsiasi ora o senza schedulazione molto probabilmente non sa a quali rischi potrebbe andare incontro e vi sta facendo "un contentino".
Alla fine chi ci rimette è sempre il cliente, non prendete questo metodo come "forzatura" ma come garanzia del lavoro.

Avere una cadenza precisa nelle pubblicazioni permette di capire molto più rapidamente in caso di errori a cosa è dovuto il problema

Competenze

Difficile da testare e capire. Molto molto soggettivo.
Sicuramente deve esserci per forza fiducia nel fornitore, e non è detto che l’esperienza di un amico sia uguale anche per te.

Solitamente i fattori che fanno SCARTARE un fornitore sono:

• sono già pronti ad iniziare il tuo progetto → tutte le aziende esperte e competenti sono piene di lavoro, il personale è molto difficile da trovare e formare, quindi probabilmente il tuo progetto non può partire subito, ma dovrai aspettare un po’
• dicono di SI a tutte le tue richieste → chi è veramente competente sa dire di NO a ciò che non va fatto (perchè tempo perso) e non guarda alla richiesta solo per incassare i soldi
• fanno gli sconti → si avete letto bene. Il paragone che faccio sempre è con i medici. Per caso quando andate in visita da loro chiedete sconti? trattate sul preventivo? La visita costa X o ci vai o cambi medico. Quando si tratta di servizi non c’è una “produzione di massa” e quindi un lavoro che dura 6 mesi costa 6 mesi e non 5. Il costo dei dipendenti è sempre quello per il fornitore. L’unica eccezione è se viene chiesto al fornitore un servizio continuativo tipo body rental (di fatto gli stai chiedendo un suo dipendente full time)
• hanno il prezzo finito per il progetto → in questo caso le opzioni sono 2: ho il prezzo è esagerato oppure ci rimetterà il fornitore (e prima poi si ripercuote sul cliente). Non parliamo di 4 pagine di sito, ma di un sistema di vendita. Difficile prevedere tutto a priori e dire che non si spenderà 1 euro in più. Questo è il caso per chi non utilizza il Time-Material e solitamente si arriva un punto dove ci saranno altri X preventivi per concludere il progetto perchè la frase è sempre quella: “non era previsto nel progetto iniziale”
• propongono SOLO estensioni di terze parti -> di fatto è un "installatore di cose"
• cercano di far cambiare idea al cliente proponendo soluzioni simili ad estensioni di terze parti (perchè probabilmente ve ne vorrà installare qualcuna)

Unica eccezione: il fornitore propone una estensione invece di codice custom da zero per un discorso di risparmio tempo/soldi -> es. export feed, metodi di pagamento, metodi di spedizione.

Sistema di deploy + sistemi di test (#tecnico)

In generale il codice (qualsiasi sia la piattaforma) dovrebbe avere un sistema di deploy (preceduto da test automatici che ne controllano la qualità).

No non è utopia e creare un sistema di deploy anche solo per un sito statico è veramente banale con le pipeline (gitlab, bitbucket, jenkins)

Esempi e guide:
https://www.giuseppemorelli.net/blog/deploy-magento2-con-gitlab-pipeline-e-deployer-php https://www.giuseppemorelli.net/blog/deployer-bibucket-pipelines-automatizzare-deploy-progetto https://www.bitbull.it/en/blog/pipeline-magento2/

L’accesso al server o infrastruttura server dovrebbe essere limitato e la pubblicazione dovrebbe essere automatizzata (questo evita errori umani nel lanciare i comandi).
Il caricamento file via FTP può esistere solo per le immagini o file di interscambio e NON per il codice sorgente.
Nello specifico magento2 richiede un metodo specifico che tutti dovrebbero seguire: https://devdocs.magento.com/guides/v2.3/config-guide/deployment/

Questo implica che l’hosting deve avere delle caratteristiche ben specifiche (no hosting condiviso, no hosting solo con FTP).
Il fornitore solitamente spiega il motivo della scelta hosting di un certo tipo e deve essere in grado di poter effettuare il deploy in maniera corretta.