• Moderatore

    E-commerce Magento2 - quali sono i requisiti che il fornitore deve avere

    Mi capita molto spesso nell’ultimo periodo di dover ripetere sempre le stesse cose a persone che chiedono una consulenza o un aiuto per il loro progetto e-commerce Magento2.
    Per questo ho deciso di scriverlo e di poterlo arricchire nel tempo (anche con l’aiuto di altri).
    Molti colleghi lo danno per scontato, ma dalle telefonate ed incontri che faccio vedo che un post del genere è necessario.

    Magento2 essendo una delle piattaforme più complesse su cui lavorare richiede conoscenze di alto livello e strumenti adatti per lo sviluppo.

    Il post in questo caso è rivolto ai clienti.
    (può essere spunto per fornitori)

    ATTENZIONE! :gthi:
    Ciò che viene scritto
    (e
    ** NON è marchiato come #tecnico) è una mia opinione personale e rimane tale.**
    Prendetelo come spunto.

    **->**** questo invece indica che è un requisito oggettivo necessario**


    **Repository GIT(sistema di versionamento del codice) - **
    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)

    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**”

    **Sistema di deploy + sistemi di test **
    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.

    **Hosting - **
    Riporto il tutto alla discussione: https://devdocs.magento.com/guides/v2.3/config-guide/deployment/

    IMPORTANTE!
    Solamente perchè qualche servizio di hosting offre il sistema di installazione automatico di Magento2 (e l’avete provato e vi funziona) non vuol dire che la modalità sia corretta.

    In generale il discorso del deploy citato sopra implica che i costi di hosting per magento2 non siano alla portata di tutti i progetti.
    Solitamente fornitore hosting e fornitore di sviluppo non solo la stessa società.


  • Moderatore

    Ciao Giuseppe,
    grazie per gli ottimi spunti.

    E io che avevo letto "E-commerce Magento2 - quali sono i requisiti che l'Hosting deve avere" e mi sono reso conto leggendolo di avere letto male.


  • User Newbie

    Ciao Giuseppe,

    sono un nuovo utente, incuriosito dalle segnalazioni sul canale Telegram FastForward.

    Dal punto di vista tecnico ci sono vari punti che possono essere oggetto di approfondimento e di miglioramento nei nostri progetti. Ti ringrazio per questo.

    Volevo aggiungere un ulteriore punto di discussione sulla questione Tema, ovvero la possibilità di scegliere uno commerciale e apportare modifiche on top, tramite la definizione di un child theme.
    Dal punto di vista tecnico la ritengo una scelta molto importante, perché gran parte della qualità del codice e quindi delle performance e ottimizzazioni per i motori di ricerca dipenderanno da questa scelta.

    Inoltre vedo spesso progetti di Layout che si adeguano alle possibilità offerte dal tema, limitando quindi la creatività e lo spazio di manovra.

    Quanto questo punto può essere considerato un requisito che il fornitore deve avere?


  • Moderatore

    @bcarriero said:

    Ciao Giuseppe,

    sono un nuovo utente, incuriosito dalle segnalazioni sul canale Telegram FastForward.

    Dal punto di vista tecnico ci sono vari punti che possono essere oggetto di approfondimento e di miglioramento nei nostri progetti. Ti ringrazio per questo.

    Volevo aggiungere un ulteriore punto di discussione sulla questione Tema, ovvero la possibilità di scegliere uno commerciale e apportare modifiche on top, tramite la definizione di un child theme.
    Dal punto di vista tecnico la ritengo una scelta molto importante, perché gran parte della qualità del codice e quindi delle performance e ottimizzazioni per i motori di ricerca dipenderanno da questa scelta.

    Inoltre vedo spesso progetti di Layout che si adeguano alle possibilità offerte dal tema, limitando quindi la creatività e lo spazio di manovra.

    Quanto questo punto può essere considerato un requisito che il fornitore deve avere?

    Ciao bcarriero,
    ottima domanda!

    Personalmente ritengo che la questione Templating debba essere incluso nel discorso Competenze.
    Può essere considerato un requisito ma è difficile da capire e testare.
    L'unico è con progetti passati o "test" da parte di un consulente di cui ti fidi (molto spesso mi chiamano per avere feedback su una determinata società chiedendomi di fare da intermediario).

    Detto ciò il requisito sul Tema del sito deve essere 1 a mio avviso: trasparenza con il cliente.

    I fattori di SCARTO sono:

    • il fornitore** NON propone temi custom**: se non lo proponi probabilmente è solo un "installatore/modificatore di template" e non hai sviluppatori frontend esperti nel team
    • il fornitore può proporre temi custom (tramite mockup) ma non fa vedere progetti passati -> il cliente non può sapere senza un minimo di competenze se la base è da un template commerciale o meno (molti prendono 2-3 template e creano le varie varianti "spacciandoli per custom"). Se tutti i progetti passati si somigliano probabilmente il tema NON è custom
    • il fornitore NON avvisa il cliente che un tema commerciale non ripulito è più un danno che un guadagno (google te la farà pagare 🙂 )

    Il discorso "offerte layout limitate al tema" è puramente di budget.
    Poche sono le aziende che possono permettersi un buon lavoro nel template con codice "pulito" (e più che altro, poche lo sanno fare)

    Lo stesso argomento lo si può collegare al discorso Personalizzazioni del sito:

    I fattori di SCARTO sono:

    • il fornitore propone SOLO estensioni di terze parti -> di fatto è un "installatore di cose"
    • il fornitore cerca di far cambiare idea al cliente proponendo soluzioni simili ad estensioni di terze parti (perchè probabilmente ve ne vorrà installare qualcuna)
    • dice sempre SI alle richieste senza domandare i motivi della richiesta
    • non propone nuove modifiche

    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.


  • Moderatrice

    Ciao Giuseppe,

    secondo me, hai ragione se stiamo parlando di grandi progetti. Ho avuto la fortuna di lavorare nel team di sviluppo Vodafone e Pirelli per Magento e sono stati gli unici progetti in cui ho trovato un team o comunque persone dedicate solo al web design, solo al front end, solo backend, solo alla sistemistica...

    Ma la piccola azienda o comuqnue non anziende cosi grandi, se gli nomini git credono che siano qualche parolaccia tipo "gitta a mammata" ahahah e sopratutto **è tutto questione di budget.
    **
    Quando c'è il budget e "cultura" del nostro lavoro è completamente diverso.

    Negli ultimi periodi ho visto molti siti magento maltrattati o arronzati, uno in particolare di una azienda abbastanza importante di moda! Con orrori sul magento che nemmeno un niubbo di programmazione eppure i soldi ne investono tanto! Direi quasi che mi pagano profumatamente..

    Per me la colpa è sempre del commerciale...:lol:


  • Moderatore

    @CAYGRI.com said:

    Ciao Giuseppe,

    secondo me, hai ragione se stiamo parlando di grandi progetti. Ho avuto la fortuna di lavorare nel team di sviluppo Vodafone e Pirelli per Magento e sono stati gli unici progetti in cui ho trovato un team o comunque persone dedicate solo al web design, solo al front end, solo backend, solo alla sistemistica...

    Ma la piccola azienda o comuqnue non anziende cosi grandi, se gli nomini git credono che siano qualche parolaccia tipo "gitta a mammata" ahahah e sopratutto **è tutto questione di budget.
    **
    Quando c'è il budget e "cultura" del nostro lavoro è completamente diverso.

    Negli ultimi periodi ho visto molti siti magento maltrattati o arronzati, uno in particolare di una azienda abbastanza importante di moda! Con orrori sul magento che nemmeno un niubbo di programmazione eppure i soldi ne investono tanto! Direi quasi che mi pagano profumatamente..

    Per me la colpa è sempre del commerciale...:lol:

    Ciao Elena,
    si ma qui parliamo di fornitore non di clienti.
    Il problema è che clienti con budget si affidano ad aziende che di fatto subappaltano il lavoro a persone incompetenti.

    Il fornitore che non sa nemmeno cosa sia git non dovrebbe scrivere "esperti nella realizzazione ecommerce magento".
    Il fatto che poi il cliente vada da queste persone perchè non ha budget è un suo problema.

    Qui spiego di fatto che:

    • cliente: poco budget? mi dispiace non puoi fare magento
    • "ma quell'azienda fa magento e mi costa la metà" -> "ok vai pure da lui e poi vediamo i risultati"

    I commerciali "old style" nel mondo tech spariranno (e direi per fortuna) :yuppi:


  • Moderatrice

    Non credo..i commerciali esisteranno sempre...sopratutto in enormi aziende...


  • User Attivo

    @CAYGRI.com said:

    Non credo..i commerciali esisteranno sempre...sopratutto in enormi aziende...

    Si ma nel mondo tech, i commerciali "old style" come dice @giuseppemorelli, che senso hanno, quali competenze, su quali basi e esperienze potrebbero argomentare? Se non sulla loro provvigione ovviamente.
    Spero davvero di no, la cosa mi fa rabbrividire :dull:


  • Moderatrice

    eh lo so..ma sono commerciali! E capiscono di contrattualistica...ovvero quanto guadagnagno e far costare il progetto.