Salta ai contenuti

Playbook

Prefazione

Questo documento è ancora in fase di sviluppo e richiede il contributo di tutti per individuare e correggere errori e omissioni.

Lo scopo del manuale operativo aziendale è quello di fornire una guida a tutti i collaboratori dell’azienda su come eseguire determinate attività aziendali, garantendo il rispetto delle procedure appropriate.

Il nostro approccio aziendale mira a concedere un adeguato grado di autonomia a tutti i livelli di gestione, consentendo ai vari team e responsabili di organizzare il proprio lavoro in modo efficiente, con l’obiettivo comune di raggiungere gli OKR (Objectives and Key Results) e contribuire alla realizzazione della nostra missione aziendale.

Per questo motivo, la gestione dei compiti non è disciplinata da regole rigide, ma piuttosto è concepita come una mappa per raggiungere gli obiettivi con flessibilità.

Tuttavia, alcune sezioni di questo manuale sono contrassegnate da un simbolo che indica regole fondamentali da rispettare rigorosamente, poiché costituiscono la base del nostro approccio aziendale: poche regole, ma importanti da far rispettare.

Senza un metodo condiviso e standardizzato per gestire determinati aspetti tecnici del nostro lavoro, non possiamo procedere con efficienza e pertanto chiediamo il massimo rispetto e aderenza alle procedure indicate.

Struttura del Documento: Il playbook è organizzato in capitoli che delineano le regole e le best practice da seguire in varie situazioni e contesti. Si consiglia di utilizzare il motore di ricerca interno (e presto l’intelligenza artificiale) per trovare risposte alle domande comuni come:

  • “Cosa devo fare se…"
  • "Cosa fare quando…"
  • "Chi è responsabile di…”

Questo approccio favorisce la consultazione rapida e la risoluzione efficiente dei problemi quotidiani.

Changelog

2024.03.24Private (https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-318072)
2024.03.19Private (https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-303872) e Private (https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-134010) e Private (https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-303892)
2024.03.18Private (https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-301272)
2024.03.18Private (https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-299552) e Private (https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-251192)
2024.03.16Private (https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-63301)
2024.03.14Private (https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-70241) e Private (https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-274792)

Glossario

  • Z.ticket

    Zendesk Ticket

  • C.task

    ClickUp Task

  • COO

    Chief Operative Officer: dirige la produzione e le risorse di produzione.

    Di seguito sono riportati alcuni degli aspetti principali del ruolo del COO:

    1. Gestione Operativa: Il COO è responsabile della gestione operativa dell’azienda, assicurandosi che tutti i processi e le procedure siano eseguiti in modo efficiente e in linea con gli standard stabiliti.
    2. Pianificazione Strategica: Collabora con il CEO e altri dirigenti per sviluppare e implementare le strategie aziendali a lungo termine, assicurando che le attività quotidiane siano allineate agli obiettivi strategici dell’azienda.
    3. Supervisione dei Dipartimenti: Sovrintende ai vari dipartimenti dell’azienda, assicurandosi che ciascuno svolga il proprio ruolo in modo efficace e contribuisca al successo complessivo dell’azienda.
    4. Controllo dei Costi e del Budget: Monitora e gestisce i costi operativi dell’azienda, assicurandosi che le risorse finanziarie siano utilizzate in modo efficiente e che i progetti siano completati entro i limiti di budget stabiliti.
    5. Gestione del Personale: Supervisiona il dipartimento delle risorse umane e si assicura che l’azienda abbia la forza lavoro necessaria per raggiungere i suoi obiettivi. Questo può includere l’assunzione, la formazione e lo sviluppo del personale.
    6. Implementazione dei Processi: Collabora con altri dirigenti per sviluppare e implementare processi aziendali efficaci che migliorino l’efficienza e la produttività dell’azienda.
    7. Gestione delle Relazioni: Gestisce le relazioni con i clienti, i fornitori e altre parti interessate chiave per garantire la soddisfazione del cliente e la stabilità delle relazioni commerciali.
    8. Rapporto con il Consiglio di Amministrazione: Il COO può anche essere responsabile di fornire aggiornamenti regolari al consiglio di amministrazione sull’andamento operativo dell’azienda e sulle strategie in corso.
  • PM

    Project Manager: governa tempi e costi del progetto

  • PO

    Project Owner o anche Product Owner: responsabile del progetto e del suo successo

  • PP

    Parametri Primari di un progetto, come date e costi

  • SP

    Sprint Point - unità di quantificazione dell’effort di un compito o lavorazione. Utilizzato anche per quantificare il preventivo e costo di progetto

  • TGP

    Team di Gestione del Progetto

  • Contratto

    Rappresenta un accordo fra cliente e f.technology ed è supportato da un preventivo di massima, un accordo su scope e tariffe, e un documento firmato fra le parti. Dentro a un contratto possono insistere più progetti diversi e svolti più preventivi nel tempo. Un contratto può essere pluriennale, non avere scadenza o avere tacito rinnovo di anno in anno.

    Le informazioni relative al contratto devono essere riportare dall’Account all’interno della documentazione interna associata allo space del progetto su ClickUp. Al momento su F.suite non è prevista la gestione del contratto come entità ma è solo un campo contenitore sull’entità Progetto, ma dovrà essere creato questo strumento di gestione in seguito.

  • Progetto

_______ GUIDE

CLICKUP

Space & Cartelle

Guida all’Utilizzo di Space, Cartelle e Liste associati ai clienti su ClickUp

Step di creazione nuovo space per nuovo cliente:

  • Cliccare sul ”+” a destra di “Spaces” nella barra laterale

  • Cliccare su “Use template”

  • Selezionare il template “Space per clienti Produzione”

  • Cliccare su “Use template”

  • Inserire un nome per lo space e cliccare su “Use template”

  • Modificare il nome dello space, delle cartelle e delle liste interne come da indicazioni sotto

  • Eliminare i documenti “Precontratto” e “Template standard di progetto” (è un errore e non riesco a cancellarli permanentemente 😞)

  • Una volta creata anche la lista shared, modificare i link nella prima pagina con quelli della cartella shared e della documentazione shared relativa

  • Aggiungere un automation sulla lista Ticket in modo da venire notificati (PM) ogni volta che viene creato un nuovo task.

Step di aggiunta nuovo progetto per cliente già esistente:

  • Progetto a corpo nato da preventivo con contratto associato ➝ crea una nuova cartella verde all’interno dello space del cliente

  • Progetto da mantenere con pacchetto a ore o con contratto (es. T&M/Manutenzione/Fastline) ➝ aggiungere una lista all’interno della cartella grigia o creare una nuova cartella grigia con nuovo contratto, se differente da quella già presente

I template non devono essere mai modificati in autonomia ma solo dal COO.

Inoltre non vanno duplicati gli esempi forniti ma vanno applicati i template come da guida.

Struttura di Base

  • Lo space corrisponde a uno specifico cliente, con una serie di progetti attivi e in manutenzione, eventualmente collegati a una repo su github tramite l’integrazione su clickup*.
  • Il nome dello Space deve rispettare il seguente schema: “{{nome cliente}} | {{codice cliente}}“.

Esempio: “Cliente | 00001”

  • Nella vista dello space, pinnata in alto deve sempre esserci la documentazione interna con i link alla documentazione condivisa nella cartella shared.

➝ Rinominare il documento pinnato in alto sulla cartella sostituendo “Cliente codicecliente” con {{Nome Cliente}} {{Codice Cliente}}

Esempio: “Cliente 00001 | Doc interno”

Il nome dei documenti e il loro contenuto sono descritti qui: Private (https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-198472)

  • All’interno dello space è presente:
    • una o più cartelle verdi per ogni progetto attivo nato da preventivo con contratto associato, rinominata con “{{nome cliente}} | {{nome progetto}}“. Utilizzare le liste per organizzare le fasi del progetto secondo quanto indicato nel preventivo. Ogni fase dovrebbe essere rappresentata da una lista separata. Aggiungere nelle descrizioni delle liste il dettaglio del budget della singola fase, in modo da avere sott’occhio sempre un controllo sulle ore tracciate e il budget complessivo. Se il progetto non ha delle fasi, dividere le liste per funzionalità da sviluppare e/o macrocategorie che aiutino il PM a controllare il budget del progetto in modo adesguato. Quando il progetto è completo e passa in manutenzione, si può rinominare la cartella verde aggiungendo il nome dell’anno solare in corso e archiviarla.
    • una o più cartelle gialle sprint, rinominata con “{{nome del progetto}} | Sprint”, per pianificare il lavoro nel futuro e controllare di poter rispettare le scadenze pattuite con il cliente. Aggiungere sprint allineati con le due settimane dello sprint del team e assicurarsi di crearli sempre prima della partenza del nuovo sprint perché non possono essere creati in modo retroattivo. Gli sprint vanno creati manualmente e vanno archiviati dopo 3 mesi man mano che si va avanti con il progetto. Quando il progetto è finito e passa in manutenzione, si può rinominare la cartella di sprint aggiungendo il nome dell’anno solare in corso e archiviarla.
    • Una o più cartelle cartelle grigie dove raggruppare tutti i progetti in manutenzione, con un contratto, una volta che sono stati conclusi. Il nome di questa cartella deve rispettare il seguente schema ➝ “{{nome cliente}} | {{tipo contratto}}“

Esempio di tipologia di contratto: FastLine, Manutenzione, T&M etc..

In questo caso, le liste sono utilizzate per differenziare i singoli progetti mantenuti.

  • * Una **lista** esterna alle cartelle chiamata "**Ticket**" dove l'assistenza o la segreteria possono creare i task da passare in produzione o che non sanno in quale cartella e/o lista inserire. I task in _ticket_ dovranno essere controllati e spostati dal PM nelle liste corrette all'interno dei progetti, per poi essere duplicati nello shared del cliente e fatturati (vedere Private ([https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-198572](https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-198572))).

* ogni qual volta serva collegare un nuovo progetto a una repo, chiedere al COO che ha i permessi per farlo_._

NB. Il codice cliente si trova su FileMaker - sotto Clienti.

Archiviazione

A fine anno lavorativo o alla chiusura del progetto, rinominare le cartelle di progetto aggiungendo l’anno solare in corso e archiviarle.

Importante: non vanno mai eliminati o archiviati gli Space, ma solo le Cartelle e le liste Interne. E non spostati.

Selezionando “mostra archiviati” sugli spaces, potete visualizzare, all’interno degli space dei clienti, tutte le cartelle e le liste che sono state archiviate nel tempo. Quindi se per esempio vi serve trovare i progetti o i task dell’anno scorso.

Cartelle per Contratti di Manutenzione

(descrivere qui)

Folder Shared

Guida all’Utilizzo della Folder Shared, le folder dei progetti condivise con i clienti e usate per la rendicontazione

Folder Shared

La configurazione della Folder Shared all’interno di ClickUp serve per agevolare l’interazione con i clienti, la rendicontazione necessaria, il monitoraggio dei progressi e degli stati dei progetti, e aiutarci nel caso di contestazioni con il cliente. Inoltre è fondamentale per fare in modo che tutti in azienda possano sostituire i propri colleghi PM in caso di assenza o malattia.

Lo space è il seguente: 90060141282 (https://app.clickup.com/2402546/v/s/90060141282)

Per ciascun progetto viene designato un Account responsabile di iniziare la redazione della Documentazione Interna di Progetto con tutte le informazioni che servono al PM per creare la shared e gestire il progetto correttamente (definizione degli elementi commerciali, come contratti e budget). Questo compito è essenziale per di procedere con la strutturazione della Folder e per una gestione efficace del progetto. Il PM è quindi invitato a segnalare ovunque manchi e l’Account è tenuto a fornirla il prima possibile.

Il PM assegnato a quel cliente, è invece responsabile di accogliere le nuove richieste del cliente e gestire le richieste esistenti. Nel caso, per un qualsiasi motivo, il PM risulti indisponibile verrà individuato un backup che possa fare le sue veci durante la sua assenza. Tale informazione dovrà essere condivisa con il cliente. Private (https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-198632)

Di base tendiamo ad associare Cliente e PM, in modo che si crei un rapporto più consolidato anche su progetti diversi. Questo non è un però un obbligo, specie se il cliente è un’agenzia che gestisce molti progetti, anche contemporaneamente.

L’interazione tra cliente e noi è sempre possibile, attraverso Shared Folder / List, commentando i task: è questo il canale principale da utilizzare e da tenere sempre allineato, anche per istanze provenienti da canali diversi, in quanto unico condiviso sia con il cliente sia con tutta l’azienda.

Ovviamente le informazioni interne che non vanno condivise con il cliente, non dovranno essere scritte nei task condivisi ma solo in quelli interni.

Qui è possibile trovare il template delle cartelle shared: 90121011341 (https://app.clickup.com/2402546/v/f/90121011341/90060141282) Seguire gli step seguenti per applicarlo a una nuova cartella.

Step per creare una nuova cartella nello shared:

  1. Cliccare su ”+” a destra di “Shared with Clients”

  2. Cliccare su “Folder”

  3. Cliccare su “Use Template”

  4. Selezionare “Cartella shared produzione

  5. Cliccare su “Use Template”

  6. Modificare il nome della cartella e della lista preesistente

  7. Creare nuove liste, se necessario

  8. Modificare la descrizione della cartella e delle liste, se necessario

  9. Modificare i form/moduli di nuove richieste, in base ai progetti o ai clienti, se necessario

  10. Modificare il nome del documento pinnato in alto, e completare il read.me sostituendo gli screenshot e i link ai form

  11. Aggiungere i primi task, se già presenti (partiamo con il riportare quelli non ancora fatturati dalle cartelle interne, se necessario)

  12. Condividere la cartella con il cliente cliccando su ”…” ➝ “sharing & permissions” ➝ aggiungere l’email del cliente

I template non devono essere mai modificati in autonomia ma solo dal COO.

Inoltre non vanno duplicati gli esempi forniti ma vanno applicati i template come da guida.

La cartella deve essere condivisa con i clienti come guest con la sola abilità di commentare. Il cliente non può editare nulla, ma solo visualizzare e commentare i task e la documentazione.

All’interno della cartella deve esserci una lista dedicata per ciascuno dei progetti del cliente, per dare una visione globale (con la cartella) e specifica (con le liste) per singolo progetto.

La cartella deve includere nella Descrizione della Folder le info del PM di riferimento e i suoi contatti, nonché una sintesi delle condizioni contrattuali in corso.

Le liste contengono una serie di task che rappresentano le macrofunzionalità o le singole attività, suddivise in diversi stati:

  • To plan: attività/funzionalità non ancora programmate.

  • Pending: attività/funzionalità in sospeso in attesa di informazioni o risposte da parte vostra.

  • Planned: attività/funzionalità pianificate all’interno di uno sprint.

  • Client review: attività/funzionalità completate e in attesa di verifica e conferma da parte vostra.

  • Completed: attività/funzionalità completate.

Le informazioni visualizzate nelle liste nei task rappresentano:

  • Priorità: indica l’ordine di priorità delle attività.

  • Progress: fornisce un’indicazione generica del progresso dell’attività.

  • Environment: specifica l’ambiente di sviluppo e di rilascio (locale, di stage o di produzione).

  • Data di inizio e di scadenza: indica solitamente le date di inizio e fine dello sprint in cui il task è stato pianificato. Nel caso in cui un’attività non venga completata entro la fine di uno sprint, la data di scadenza verrà aggiornata con quella dello sprint successivo (e così via). In base alle necessità possono esistere anche dei casi in cui le due date coincidano o dove la data di scadenza sia prima della fine dello sprint in cui è inserita.

  • Ore/Costo: riporta le ore o il costo effettivo delle attività, nel caso di progetti a pacchetto ore o Time and Material (T&M).

  • Stima: indica le ore o il costo preventivato per le attività, nel caso di task che hanno richiesto una quotazione preliminare.

  • Tag: opzionale, se necessario per prevedere contestazioni del cliente (vedere)

  • Fase: opzionale, da usare per i progetti a corpo [custom field da creare come options con la lista delle fasi specifiche del progetto]

Nel caso di contratti con pacchetto ad ore o Time & Material (T&M), settiamo la vista della cartella che raggruppa tutti i progetti con le seguenti colonne:

View Lista della Folder

  • Nome card

  • Ore tracciate

  • Quotazione

  • Data inizio (opzionale)

  • Data di scadenza (opzionale)

  • Progress (opzionale)

  • Environment (opzionale)

Questa vista consente di filtrare le informazioni per ottenere una visione completa delle ore utilizzate, divise per progetto o meno: a che punto sono del pacchetto, quante ore sono state usate per le singole richieste, quante ne sono state preventivate e quante ne mancano.

Se per i progetti a corpo viene richiesto dal cliente un report mensile o un consuntivo del lavoro, allora si gestirà con un esportazione delle liste interne o con una rendicontazione manuale filtrando i task nelle space interno (a opera del PM). L’account quindi in questi casi deve sempre chiedere al PM.

Oltre alla visualizzazione in forma di lista, sono disponibili anche le viste Gantt e Timeline per fornire un quadro temporale delle attività passate e future.

Pinnato in alto deve esserci sempre anche una vista doc che contiene tutti i documenti condivisi con il cliente, suddivisi per progetto. La documentazione deve contenere le condizioni contrattuali complete, le documentazioni dei progetti (funzionale e tecnica), divise per sottosezioni e una guida sull’utilizzo della Folder (in seguito aggiungeremo un link con dei video tutorial) ➝ Esempio:Private (https://app.clickup.com/2402546/v/dc/29a7j-46192)

Per aggiungere nuovi task e fare richieste, il cliente è invitato a usare i moduli creati nella lista ticket a seconda del tipo di richiesta:

Questi sono i link di esempio. Ovviamente saranno dei link diversi per ogni cliente.

I moduli sono anche disponibili nella lista Ticket, pinnati in alto. Il PM deve avere un automation sulla lista in modo che venga notificato ogni volta che viene creato un nuovo task.

Una volta ricevuta la notifica di un nuovo task, il PM deve seguire i seguenti step:

  1. Il task sarà visualizzato nella lista ticket e sarà automaticamente taggato come bug fix, change request o con nessun tag nel caso di nuove implementazioni. In questo caso aggiungere new request o quotation o altro, a seconda del caso.
  2. Associare il template corretto (vedi ) alla card
  3. Aprire il task e sistemare le informazioni secondo lo schema del template
  4. Spostare il task nella lista progetto (shared) corretta
  5. Mantenere o modificare la data di scadenza, e nel caso comunicare al cliente la possibilità o meno di rispettare la sua richiesta
  6. Taggare il task con il tag urgenza se richiesto come tale
  7. Taggare il cliente con le informazioni mancanti, se necessario, e spostare il task in pending
  8. Quando si hanno tutte le informazioni e il task è completo, duplicarlo selezionando solo questi campi:

  1. Creare il taks clone nella lista interna del progetto come task interno da assegnare al team

  2. Collegare il task interno al task shared

  3. Pianificare il task spostandolo nello status Planned e inserendo le date di inizio e scadenza

Per altre segnalazioni (domande, richieste di supporto, ecc.), è possibile per il cliente contattare il PM di riferimento via email o per urgenze, al numero di telefono. In caso di indisponibilità, è necessario richiamare il cliente il prima possibile o fissare una videochiamata e registrarla.

Il cliente deve essere invitato a fare riferimento a queste liste e ai relativi task per monitorare il progresso e lo stato delle attività, nonché per fornire o richiedere informazioni aggiuntive. Ogni qual volta si viene contattati via email bisogna rispondere al cliente su clickup.

Lo stesso PM e le persone che si occupano dei task devono comunicare il più possibile con il cliente all’interno dei task condivisi, e non via email o sulla chat di teams. Ogni qual volta invece sia richiesta una chiamata telefonica o una videochiamata, è importante riportare e riassumere poi quanto è stato detto all’interno dei task specifici.

Gestione & responsabilità del PM:

  • Monitorare ed informare il cliente sul progress delle attività attraverso la gestione e la modifica di stati, scadenze, environment, progress, ore etc.
  • Aggiornamento della card tramite commenti (in seguito ad aggiornamenti sulle card interne o a call con il cliente)
  • Linkare le card interne con quelle condivise (ogni task deve avere una o più card interne collegate)
  • Riportare le informazioni dette a voce al cliente o nelle SAL (in chiamate telefoniche o videocall) nelle card relative
  • Gestione progetti a corpo
    • Creare una lista con il nome del progetto dentro alla cartella cliente
    • Creare i task man mano che si procede con il lavoro e taggarli
    • Linkare i task condivisi con quelli interni
    • Associare i task alle fasi del progetto creando il custom field relativo (le fasi del progetto sono quelle che sono state quotate nel preventivo. es. analisi, design, sviluppo fuunzionalità, integrazione etc..)
    • Archiviare una volta concluso il progetto, rinominare aggiungendo l’anno in corso e creare una nuova lista per la fase di manutenzione (o per una seconda fase di sviluppo)
  • Gestione progetti con pacchetto ore
    • Creare una lista per progetto
    • Aggiunta Campo ore o costo in base al contratto*
    • Taggare i task
    • Riportare le ore da fatturare dai task interni ai task condivisi, usando il custom field apposito
    • Aggiornare il totale delle ore acquistate man mano che vengono acquistati nuovi pacchetti ore
    • Archiviare a fine anno lavorativo, rinominare aggiungendo l’anno in corso e creare una nuova lista per l’anno nuovo

*non per i pacchetti di manutenzione dove non dobbiamo riportare le ore al cliente

Responsabilità degli altri membri del Team

  • Comunicare con il cliente attraverso i task shared (a meno che non sia esplicitato il contrario)
  • Modificare il progress della card usando il custom field relativo
  • Spostare il task in pending (se bloccati) o in review (se si è completato il lavoro e non c’è bisogno di una review o della validazione del PM)
  • Riportare le informazioni dette a voce al cliente o nelle SAL (in chiamate telefoniche o videocall) nelle card relative

Task

Come creare, usare e gestire i task all’interno del team di Produzione.

Utilizzo generale dei Task per ogni Space

Vista Board

Nella vista board, la più utilizzata da noi, sono mostrate le seguenti informazioni:

  • Immagine: cover (se presente) o ultima immagine aggiunta ai commenti

  • Nome Cartella > Nome Lista: devono dare contesto alla card, in particolare chi è il cliente e qual è il progetto (vedere Private (https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-198492) per nomenclatura cartelle e liste)

  • Titolo card: Il titolo deve essere breve e far capire cosa c’è da fare in modo intuitivo

  • Assegnatari: Se sono presenti più assegnatari, e il task si trova in review, i primi sono quelli a cui è stato assegnato il task, l’ultimo è rappresenta la persona che deve occuparsi della review

  • Priorità: serve per dire all’interno dello sprint quali card vanno fatte prima delle altre per le singole persone. Viene cambiata dal COO/Scrum Master dopo l’assegnazione delle card

  • Data di inizio e fine: La data di inizio, se presente, indica che non bisogna iniziare quella task finchè non la si raggiunge; la data di fine, se presente, indica la scadenza entro quando deve essere completata. Ogni qual volta che una card scade, solo il PM o il COO sono tenuti a modificarne la data per spostarla. Inoltre le date di scadenza valgono anche quando in task è in review perchè indicano entro quando la review deve essere completata, mentre vanno rimosse quando in pending. Le date di scadenza devono essere rispettate: se ci si rende conto che non si riesce a finire qualcosa in tempo, bisogna avvisare il PM di riferimento o il COO.

  • Estimate: se presente, indica la stima/quotazione fatta per la card in termini di ore o il tempo massimo da dedicare alla card (poi va avvisato il PM)

  • Sprint Point: indica l’effort quotato in fase di sprint planning

  • Tag: servono per identificare l’urgenza che ha un costo extra per il cliente, il tipo di lavoro da fare; e deve aiutare il PM a identificare facilmente i task di uno stesso tipo in caso di contestazioni con il cliente.

Esempi di TAG utili per contestazioni:

  • urgenza: il cliente chiede di gestire l’attività da un giorno all’altro

  • bug fix: bug implementativo, problematica da sistemare

  • improvement: miglioramento prestazioni

  • change request: modifica su funzionalità già esistente con nuove specifiche

  • verification: verificare problema e vedere se è un bug o un problema del cliente

  • support: supportare il cliente in operazioni sulla piattaforma, in call, con altri fornitori .

  • quotation: quotazioni su nuove funzionalità o modifiche

  • new request: nuove richieste rispetto ad analisi e preventivo

  • documentation: attività di documentazione

  • analysis: attività di analisi

  • development: attività di sviluppo

  • testing: attività di testing & QA

  • design: attività di design

  • content: attività di inserimento o modifica contenuti

  • sysop: attività tecniche, legate all’infrastruttura, hosting etc.

  • dumped request: feature che è stata fatta sviluppare per poi rifarla da capo completamente, quindi “buttata” per le richieste del cliente poco chiare o per cambi di idea del cliente

Dettaglio Card

  • titolo:

  • status:

  • assigned to:

  • dates:

  • priority:

  • sprint point:

  • time estimate:

  • tag:

  • cover:

  • immagini:

  • descrizione: Nella descrizione della card, a seconda del tipo di card, vanno aggiunte le seguenti informazioni

  • environment: serve a indicare dove si trova la modifica fatta e va aggiornata quando viene pubblicato un set di funzionalità in stage o in produzione. Local indica che non è stata ancora rilasciata da nessuna parte ma è in locale, Stage e Production indicano rispettivamente ambiente di stage e live. Sta al PM il compito di assegnare il rilascio di un certo tipo di funzionalità live o in stage, mentre sta alla persona incaricata, di cambiare l’environment delle card rilasciate.

  • note di rilascio: va completata dalla persona assegnata alla card con informazioni importanti riguardo a quanto fatto (quando necessario). Ad esempio: dopo aver corretto un bug fix, segnalare dov’era il problema e come si è risolto; oppure dopo aver fatto un’implementazione complessa, per segnalare cose importanti da tracciare.

  • subtask: devono essere usati per suddividere tra frontend e backend; o per esempio quando ci sono tanti microcambiamenti frontend a una pagina, si suddividono in sottotask con tutte le info in ogni sottotask. Non devono essere usati invece per mettere assieme tipi di lavori diversi che invece dovrebbero essere suddivisi in task separati.

  • github integration: devono essere usate per tracciare il lavoro fatto sulle repo e rendere più semplici le review. Tutorial su come usarla: https://help.clickup.com/hc/en-us/articles/6305771568791-GitHub-integration

  • task collegati: nel caso di review, è necessario linkare tutti i task di cui effettuare la review; se un task viene chiuso perchè si è concluso lo sprint ma va duplicato, è corretto linkarlo al precedente; inoltre ogni task condiviso nelle liste shared coi clienti avrà sempre uno o più task interni collegati. Sta al PM inserire questi collegamenti. Chi si occupa del lavoro potrà utilizzare il task shared collegato per comunicare con il cliente direttamente, quando necessario. (Vedere Private (https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-195232) per maggiori dettagli)

  • dipendenze (waiting on, blocking): vanno sempre indicate le dipendenze quando un task blocca o è in attesa di un altro. Un task bloccato non deve essere iniziato finchè non si sblocca.

  • commenti: utilizzare i commenti per comunicare con gli altri membri del team, tracciare il progresso del lavoro, avvisare di eventuali problemi. Tutto quello che riguarda una certa card attiva, dovrebbe essere tracciato al suo interno e non su altri canali (teams, email etc..). Quando si fanno delle call è necessario riassumere quanto detto nelle call nei commenti della card, per esempio. Lasciare un commento chiaro e dettagliato facilita la comunicazione all’interno del team e fornisce un contesto prezioso per comprendere le decisioni prese durante il processo di gestione del task.

Stati

Stato “Open”

Lo stato “Open” indica che una card è stata creata e assegnata, ma non è ancora stata presa in carico o che è stata riaperta in seguito a una review o a una modifica della richiesta del cliente (ma solo se nello stesso sprint; non si possono infatti riaprire le card negli sprint non in corso).

Stato “Pending”

Lo stato “Pending” indica che una card è bloccata da fattori esterni al controllo del team. Questo può includere attese per la risposta di un cliente, il completamento della documentazione da parte di un fornitore o altre dipendenze esterne che impediscono il progresso dell’attività. Ogni volta che un task viene spostato in pending bisogna scrivere nei commenti per quale motivo.

Stato “In Progress”

Una card contrassegnata come “In Progress” è attualmente in lavorazione da parte di uno o più membri del team. Le card iniziate vanno portate in progress per fare sapere agli altri membri del team che sono in corso.

Stato “In Review”

Quando il lavoro sulla card è stato completato, la card deve essere messa nello stato “In Review”. In questa fase, la card è in attesa di approvazione e verifica da parte di un revisore, che esaminerà il codice, i test, le modifiche apportate (nel caso di un task tecnico) o il lavoro fatto in modo generico (nei casi di lavori di altro tipo) per garantire che soddisfino gli standard di qualità e i requisiti concordati. La card portata in review deve essere assegnata a un’altra persona, ma non devono essere mai rimosse le altre persone che hanno segnato delle ore e svolto del lavoro all’interno di essa. La review non deve essere sempre e solo assegnata al lead tecnico ma anche agli altri membri del team, in base alle loro competenze e alla disponibilità effettiva. E’ importante anche, quando si fa la review, di verificare le funzionalità e le modifiche testandole in locale o in stage. Il revisore può essere una figura tecnica che valida sia il lavoro funzionale che tecnico, oppure solo funzionale per verificare il lavoro svolto senza guardare il codice scritto. Nel caso in cui si abbiano più card sullo stesso progetto o PR e si voglia aspettare di finire tutte le card per assegnarle a un revisore, si possono spostare in review e poi assegnarle solo quando sono tutte in review segnalando il link alla PR o al deploy in ambiente di stage o produzione. Ricordarsi in questi casi di cambiare il campo environment di conseguenza.

Stato “Completed”

Una volta che la card ha superato con successo la fase di revisione, viene contrassegnata come “Completed”. Si passa quindi alla revisione del cliente. Se il cliente approva il lavoro, la card può essere messa nello stato invoiced, altrimenti dovrà essere riportata in Open, ma solo se si trova ancora nello sprint corrente. Se la card si trova in uno sprint vecchio, dovrà essere duplicata o creata una nuova card con la revisione richiesta.

Stato “Invoiced”

Lo stato “Invoiced” è utilizzato dal Project Manager per indicare che gli sprint point o le ore associate a quella specifica attività sono già stati fatturati al cliente. Questo stato è importante per tenere traccia delle attività che hanno generato fatturazione e per assicurarsi che tutte le prestazioni fornite al cliente siano state adeguatamente registrate e contabilizzate. Oppure per indicare che una card non deve essere fatturata al cliente ma è da considerarsi gratuita o inclusa.

Test

Nel caso di task di sviluppo, durante lo sviluppo di una funzionalità complessa, è essenziale che vengano realizzati test unitari per garantire la correttezza del codice. Inoltre, per le feature core del prodotto, vengono eseguiti anche test end-to-end per garantire la stabilità del sistema. Per considerare una card conclusa, tutte le pipeline legate a quella pull request devono passare con successo. Chi sviluppa la card è responsabile di correggere eventuali errori nei test e di garantire che la card sia completata con successo.

Documentazione

Una volta completata una card, vanno completate le note di rilascio, se necessario, e va aggiornata la documentazione funzionale e/o tecnica di progetto, in base alla tipologia di card. Queste attività sono a carico di chi ha fatto il lavoro.

Deploy

Quando è necessario deployare una serie di card collegate a un progetto, il PM può fare in autonomia il deploy (se esistono delle pipeline e actions associate su github) oppure creare una card di deploy da assegnare al Lead Tecnico del progetto.

Si richiede a tutti di controllare le notifiche su ClickUp con elevata frequenza, preferibilmente più volte al giorno, al fine di rispondere prontamente alle domande e alle richieste di informazioni da parte dei colleghi. Si consiglia di gestire le notifiche in modo proattivo: una volta risposto, è opportuno “pulire” le notifiche relative a tali interazioni, mentre è consigliabile lasciare quelle che richiedono una risposta in un momento successivo per una gestione più efficiente delle comunicazioni.


Creazione Card

Come creare le card, che tipo di informazioni sono necessarie, divise per tipologia.

Per ogni tipologia è stato creato un template che può essere applicato anche dopo aver creato la card, cliccando con tasto destro sul task e selezionando il template in questo modo:

Bug fix

Utilizzare questo template e inserire queste informazioni per le segnalazioni su malfunzionamenti o bug. Da notare che non sempre lo sono, ma vanno trattati come tali. Descrivere nel dettaglio il problema ci aiuta a riprodurlo, verificarlo e risolverlo, tutto ciò che segue è fondamentale per diagnosticare e risolvere il bug in modo efficace. quindi questi campi vanno raccolti e completati con attenzione nella creazione di un task:

  1. Piattaforma: alcuni progetti hanno più piattaforme al loro interno. Segnalare in quale tipo di piattaforma è stato segnalato il problema: admin, client.. (se presente una distinzione di questo tipo)
  2. Ambiente: produzione (live), stage o sul vostro ambiente locale di sviluppo
  3. Sezione: indicare la sezione specifica della piattaforma/sito, se presente
  4. Componente: indicare il componente, se è una cosa molto specifica
  5. Url: il link della pagina/sezione specifica dove si verifica il problema
  6. Doc: link alla documentazione di progetto
  7. Comportamento attuale: cosa accade attualmente quando si verifica il problema, includendo eventuali errori, comportamenti anomali o risultati indesiderati
  8. Comportamento atteso: il modo in cui la parte della piattaforma dovrebbe funzionare correttamente senza il bug
  9. Passaggi per riprodurre il bug: una sequenza specifica e ordinata di azioni che portano al verificarsi del bug
  10. Allegati: inserire un’immagine come cover o nei commenti per aiutare a capire il contesto (a parte nei casi dove non esiste)

Template: Bug fix | Esempio ➝ Private (https://app.clickup.com/t/8693ydwvr)

o usare documento di Private (https://app.clickup.com/2402546/docs/29a7j-49572/29a7j-239492)

Modifica su sviluppo esistente

Utilizzare questo template per le richieste di modifica di una pagina (testi, immagini, layout), di una funzionalità o di una integrazione specifica. Descrivere nel dettaglio la modifica ci aiuta a capirla e implementarla correttamente; fornire un quadro chiaro dello stato attuale aiuta il team di sviluppo a comprendere il contesto e la natura delle modifiche richieste. Quindi questi campi vanno raccolti e completati con attenzione nella creazione di un task:

  1. Piattaforma: alcuni progetti hanno più piattaforme al loro interno. Segnalare in quale tipo di piattaforma è stato segnalato il problema: admin, client.. (se presente una distinzione di questo tipo)
  2. Sezione: indicare la sezione specifica della piattaforma/sito, se presente
  3. Componente: indicare il componente, se è una cosa molto specifica
  4. Url: il link della pagina/sezione specifica dove si verifica il problema
  5. Doc: link alla documentazione di progetto
  6. Mockup: link al Figma - Dev Mode link (quando necessario)
  7. Stato Attuale: descrivere dettagliatamente come appare o funziona attualmente la sezione che richiede modifiche
  8. Stato Atteso: spiegare come vorrebbe che apparisse o funzionasse la sezione dopo che le modifiche richieste sono state apportate.
  9. Allegati: screenshot della sezione da modificare o altre cose da allegare

Template: Change Request | Esempio ➝ Private (https://app.clickup.com/t/8693ygg66)

Nuovo Sviluppo

Utilizzare questo template per le richieste di sviluppo di una nuova pagina, funzionalità o integrazione. Descrivere nel dettaglio la modifica ci aiuta a capirla e implementarla correttamente; fornire un quadro chiaro dello nuova richiesta aiuta il team di sviluppo a comprendere il contesto e la natura delle nuove implementazioni. Quindi questi campi vanno raccolti e completati con attenzione nella creazione di un task:

  1. Piattaforma: alcuni progetti hanno più piattaforme al loro interno. Segnalare in quale tipo di piattaforma è stato segnalato il problema: admin, client.. (se presente una distinzione di questo tipo)
  2. Sezione: indicare la sezione specifica della piattaforma/sito, se presente
  3. Doc: link alla documentazione di progetto
  4. Mockup: link al Figma - Dev Mode link (quando necessario)
  5. Descrizione dettagliata/use case: una spiegazione dettagliata della nuova funzionalità richiesta, comprese le sue caratteristiche principali e i requisiti specifici. Indicazioni sui tipi di utenti che utilizzeranno la nuova funzionalità e i relativi ruoli e autorizzazioni associati. Se la nuova funzionalità deve integrarsi con altre componenti o sistemi esistenti, fornirci informazioni dettagliate su tali integrazioni. Usare template di documento use case. Private (https://app.clickup.com/2402546/docs/29a7j-46192/29a7j-255992)
  6. Allegati: eventuali allegati (documenti, immagini etc.)

Template: Nuova implementazione | Esempio ➝ Private (https://app.clickup.com/t/8693ygg5z)

Task di Analisi

Per quanto riguarda i task di analisi e quotazioni, vedere: Private (https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-229532) per tutte le info che vanno fornite all’analista per permettere di fare le quotazioni.

Oltre a:

  • Progetto: esistente, nuovo?
  • Documentazione di progetto: se il progetto esiste già
  • Mockup: link al figma, se presente
  • Documento con tutte le informazioni raccolte per la quotazione

Template: Analisi & Quotazione | Esempio ➝ Private (https://app.clickup.com/t/8693yggag)

I template non devono essere mai modificati in autonomia ma solo dal COO.

Inoltre non vanno duplicati gli esempi forniti ma vanno applicati i template come da guida.

Space Amministrativi e Segreteria

Questa sezione è gestita da Franco

Data di inizio e fine: La data di inizio, se presente, indica che non bisogna iniziare quella task finchè non la si raggiunge; la data di fine, se presente, indica la scadenza entro quando deve essere completata. Ogni qual volta che una card scade, gli assegnatari del task sono tenuti a modificarne la data per spostarla indicando sempre nelle note o nella card il motivo del cambio di scadenza. Inoltre le date di scadenza valgono anche quando in task è in review perchè indicano entro quando la review deve essere completata, e vanno sempre inserite anche quando in pending come promemoria di quando fare un recall a coloro che ci tengono il task in pending. Le date di scadenza devono essere rispettate e sempre tenute aggiornate: è incarico di ogni addetto verifica ogni giorno eventuali task assegnati e scaduti.

Vedi anche:

Space Assistenza

Questa sezione è gestita da Andrea

Vedi anche:

Documentazione

Segue un elenco di tutti i vari tipi di documentazione che devono esserci in ogni progetto.

Documentazione tecnica

Schema di base: Private (https://app.clickup.com/2402546/docs/29a7j-46192/29a7j-196852)

  • * **info**: documenti che permettono di avere un quadro completo delle info tecniche del progetto (es. informazione su server, tecnologia, impostazioni progettuali, scelte tecniche, riferimenti repository, a come fare il deploy, no password); problemi tecnici noti e come risolverli;
    • scope: inserire una nuova persona nel progetto, recuperare informazioni base e link a repo, stage, prod etc, dare info al supporto tecnico in caso di problemi da risolvere

    • target: team interno (pm o sviluppatori), condivisa con il cliente

    • location: dentro alla doc shared pinnata alla cartella del cliente

    • responsabili (scrittura e aggiornamento): PM, Technical Lead, (Contributor)

Documentazione tecnica Github

  • * **info**: [read.me](http://read.me/), commenti, link a doc interna su clickup
    • scope: per l’avvio del progetto, per capire meglio determinate sezioni del codice

    • target: team interno (contributor, sviluppatori)

    • location: repo github

    • responsabili (scrittura e aggiornamento): Technical Lead, contributor

Documentazione sistemistica

  • * **info**: doc sistemistica per tecnici quando arrivano i ticket, link a clickup per doc tecnica
    • scope: per l’accesso alle macchine produttive, descrizione architetturale, stage e produzione

    • target: supporto tecnico interno

    • location: itglue

    • responsabili (scrittura e aggiornamento): Schwibbert, Technical Lead


Documentazione funzionale

Schema di base: Private (https://app.clickup.com/2402546/docs/29a7j-46192/29a7j-195932)

  • * **info**: use case con eventuali "dipendenze", change request, FAQ
    • scope: descrivere le funzionalità da sviluppare per i contributor e per il cliente, tracciare le change request e avere un posto con una lista di FAQ per il cliente o per rispondere al cliente

    • target: team interno, condivisa con il cliente

    • location: dentro alla doc shared pinnata alla cartella del cliente

    • responsabili (scrittura e aggiornamento): PM, Analista, Contributor, Tester

Manuale d’uso per l’utente finale

Esempio: Private (https://app.clickup.com/2402546/docs/29a7j-51352/29a7j-121822)

  • * **info**: doc o pdf che descrive schermata per schermata come usare il software/piatatforma
    • scope: dare una guida/manuale utente per utilizzare il software/piattaforma

    • target: utente finale

    • location: dentro alla doc shared pinnata alla cartella del cliente (ma extra da pagare a parte se il cliente la chiede)

    • responsabili (scrittura e aggiornamento): Tester

Documentazione interna

Schema di base: Private (https://app.clickup.com/2402546/v/dc/29a7j-41932)

  • * **info**: offerta commerciale, quotazione, eventuali condizioni o accordi con il cliente, oltre a tutti quei docs che non devono/possono essere condivisi con il cliente (come gli issue report)
    • scope: dare info al PM per la gestione del progetto (budget pattuito, data inizio, deadline etc.) e inserire le prime analisi e quotazioni fatte in fase di preventivo; inserire anche i nomi e i contatti dei referenti.

    • target: PM, Account e COO

    • location: pinnata allo space del cliente

    • responsabili (scrittura e aggiornamento): PM, Account, Technical Lead

Template

  • Doc condivisa (per cliente):
    • Per creare una doc condivisa per i clienti da zero da aggiungere alla cartella shared di un cliente
    • Contiene read.me e una sezione di progetto con doc funzionale, tecnica e info contrattuali
  • Doc condivisa (per progetto):
    • Per aggiungere una sezione di documentazione per un nuovo progetto dentro alla doc condivisa di un cliente
    • Contiene doc funzionale, tecnica e info contrattuali
  • Doc interna (per cliente):
    • Per creare una documentazione interna da zero nello space interno del cliente
    • Contiene doc interna + pagina con ino cliente e link alla cartella shared
  • Doc interna (per progetto):
    • Per aggiungere una sezione di documentazione per un nuovo progetto dentro alla doc interna di un cliente

    • Contiene doc interna di progetto

Allegati ai Task

Quando si allegano dei file ad un Task di Clickup bisogna utilizzare sempre file che sono stati preventivamente caricarica su di un SharePoint e condivisi con il link al file o con la funzione relativa Drive/sharepont

i file di lavoro non devo stare sul Drive Personale o su proprio disco rigido

MICROSOFT 365

Organizzazione riunioni e video call

descrivere come vanno pianificate le riunioni

as esempio: usare sempre (più possibile) i canali Teams del progetto e fissare a calendario del canale la riunione e la registrazione.

Calendari

definire le regole dell’uso dei calendari

PRODUZIONE

Vi invito ad aggiungere note o a chiamarmi ogni qual volta si presentasse un caso non previsto da quanto scritto nella documentazione, nel caso aveste dubbi al riguardo o notaste che manca qualcosa :)
Grazie!
@Greta Farnedi

Quotazioni

Gestione delle quotazioni, delle informazioni da raccogliere e da fornire.

Origine della Richiesta di preventivo per un Nuovo Progetto

Un nuovo progetto può essere avviato in seguito a tre scenari:

  • * Richiesta diretta da parte di un cliente già esistente
    • Richiesta diretta da parte di un nuovo cliente

    • Necessità interna a f.technology

Step per quotazione:

  1. Creazione preventivo su F.Suite: L’account crea un preventivo nel sistema di gestione F.suite, utilizzando un numero preventivo fornito dal sistema.

  2. Creazione task: Se la richiesta proviene da un cliente esistente di F.Technology, l’Account crea un task di quotazione all’interno dello Space del clie__nte, altrimenti crea un task nello Space Preventivi (2412131 (https://app.clickup.com/2402546/v/s/2412131)).

  3. Raccolta informazioni: l’Account raccoglie tutte le informazioni che servono per una quotazione puntuale del progetto all’interno di un documento ClickUp collegato alla card creata poi assegna la card al PM del cliente, se già presente, o al COO, per fare valutare il progetto. L’account deve richiedere al cliente una lista specifica di informazioni, puntuali e precise. (Vedere )

  4. Assegnazione: viene assegnata la card in fase di sprint planning a una o più persone interne al team per fare analisi e quotazione del progetto; se necessario, dovranno essere organizzate una o più call con il cliente, eventualmente con un referente tecnico o analista. La card di analisi non può essere più di un 0.5 SP se non concordato preventivamente il pagamento della stessa con il cliente. Se dovesse essere necessario più tempo/effort, avvertire il PM.

  5. Completamento stima: la/e persona/e assegnate al progetto creano un documento di analisi e quotazione in Sprint Point, e poi assegnano il task in review al PM. E’ cura del PM rivedere o meno la quotazione, aggiungere eventuali mancanze e prevedere all’interno della quotazione totale anche le ore svolte per la quotazione effettiva. Nel caso in cui non sia possibile fare una quotazione precisa per mancanza di informazioni, dovranno essere espresse nel documento tutte le informazioni mancanti e dovrà essere fornita una forbice di stima che verrà approfondita e fornita nella prima fase di analisi del progetto. La quotazione dovrà inoltre essere suddivisa in fasi e funzionalità con relativa quotazione specifica, che poi corrisponderanno alle liste nella cartella di progetto su clickup, con cui monitorare il lavoro e il controllo del budget, da parte del PM.

  6. Presentazione al cliente: una volta completata la quotazione, è compito dell’account rivederla e presentarla al cliente. La quotazione può essere tradotta da sprint point a ore o a costo, in base alla necessità. L’account può delegare il PM se lo ritiene necessario, ma il PM non dovrà essere responsabile di effettuare contrattazioni con il cliente ma potrà solo inviare e presentare la stima. Inoltre, se richiesto dal cliente, sarà suo compito restituire una data di inizio e fine prevista, dopo aver verificato con il COO le disponibilità del team.

Step successivi al rifiuto del preventivo:

  1. Fatturare le ore di quotazione al cliente, se possibile.

  2. Archiviare il preventivo e il task.

Step successivi all’accettazione del preventivo:

  • Se approvato, la segreteria operativa redige un contratto di progetto che il cliente deve firmare (utilizzando firma digitale online o commessa cliente per grandi imprese con proprio flusso di approvazione).

  • Viene creato un codice progetto nel sistema F.suite e comunicato al COO per la pianificazione del lavoro.

  • Vedere Private (https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-197372)

Lista info da richiedere al cliente per quotazioni

  1. Nuovo sito web/web application/prodotto (progetto a corpo)
    • Scadenze e tempistiche (data di inizio, eventuali scadenze o tempistiche specifiche per la consegna)
    • Descrizione dello scope del progetto (una panoramica dettagliata del progetto e degli obiettivi da raggiungere)
    • Budget indicativo (un’indicazione del budget disponibile, se presente)
    • Tecnologia (se si ha una preferenza)
    • Definizione problem statement (gli obiettivi attuali del prodotto, il problema che il cliente desidera affrontare e le richieste di miglioramento legate alle soluzioni proposte)
    • Definizione proto-personas (le tipologie di utenti che useranno l’applicativo, le loro user stories e le strategie per risolvere i loro problemi)
    • Definizione Features List (la lista di features da implementare, per soddisfare le esigenze del gruppo di utenti).
    • Eventuali integrazioni con altri servizi/sistemi di terze parti (con dettaglio, API, documentazione allegata o link esterno)
    • Eventuali requisiti tecnici specifici, come il supporto per determinate piattaforme o tecnologie.
    • Necessità o meno di progettazione di Design e UX Experience, nel caso in cui se ne occupi qualcun altro, definire chi. Fornire info anche su eventuale Design System già presente o meno.
  2. Nuovo sito (WordPress)
    • Descrizione del progetto: Una panoramica dettagliata del progetto e degli obiettivi che desiderate raggiungere con il software.
    • Requisiti funzionali: lista dettagliata dei requisiti funzionali, comprese le funzionalità chiave che dovrebbero essere incluse
    • Requisiti tecnici: Eventuali requisiti tecnici specifici, come il supporto per determinate piattaforme o tecnologie.
    • Integrazioni di Terze Parti: Se deve integrarsi con altri sistemi o servizi di terze parti
    • Requisiti di Sicurezza e Privacy: eventuali requisiti di sicurezza o privacy
    • Requisiti di accessibilità: eventuali requisiti di accessibilità
    • Customizzazione richiesta: lista delle sezioni che si vuole customizzare in autonomia all’interno del sito
    • Scadenze e tempistiche: data di inizio, eventuali scadenze o tempistiche specifiche per la consegna
    • Budget indicativo: un’indicazione del budget disponibile, se presente
    • Struttura del Sito: una panoramica della struttura del sito, inclusi il numero approssimativo di pagine e la loro organizzazione.
    • Wireframe e contenuti: fornire wireframe con informazioni sui contenuti che si desidera includere nel sito
    • Design: Necessità o meno di progettazione di Design e UX Experience, nel caso in cui se ne occupi qualcun altro, definire chi. Fornire info anche su eventuale Design System già presente o meno.
    • Ottimizzazione per i Motori di Ricerca (SEO): se si desidera includere servizi di ottimizzazione SEO per migliorare la visibilità del sito sui motori di ricerca.
    • Gestione dei Contenuti: se prevede di aggiornare e gestire autonomamente i contenuti del sito dopo il lancio, e se richiede un training specifico per l’utilizzo di WordPress.
  3. Refactor sito (WordPress)
    • Panoramica del Sito Attuale: Una breve descrizione del sito web esistente, comprese le sue funzionalità principali e i punti critici che richiedono intervento.
    • Obiettivi del Refactoring: I principali obiettivi che desidera raggiungere attraverso il refactoring del sito. Ad esempio, migliorare la velocità di caricamento, ottimizzare per i motori di ricerca, migliorare l’usabilità, ecc.
    • Link al sito attuale
    • Problemi Riscontrati: Qualsiasi problema o inefficienza attualmente riscontrati sul sito che desidera risolvere tramite il refactoring.
    • Contenuti e Struttura: indicazioni sui contenuti che desidera mantenere, modificare o eliminare dal sito. Se è necessario aggiungere nuovi contenuti o sezioni, gentilmente fornire dettagli.
    • Design e UX: Se si desidera apportare modifiche al design o allo stile del sito, inclusi colori, tipografia, layout, ecc. E all’esperienza utente finale.
    • Funzionalità Aggiuntive: Eventuali nuove funzionalità che desidera aggiungere al sito durante il refactoring, come un sistema di prenotazione, un modulo di contatto avanzato, integrazioni con servizi esterni, ecc.
    • Ottimizzazione per i Motori di Ricerca (SEO): se si desidera includere servizi di ottimizzazione SEO per migliorare la visibilità del sito sui motori di ricerca.
    • Scadenze e tempistiche: data di inizio, eventuali scadenze o tempistiche specifiche per la consegna
    • Budget indicativo: un’indicazione del budget disponibile, se presente
  4. Modifica/change request su Software Applicativo in gestione da noi
    • Link applicativo attuale
    • Screenshot della sezione relativa
    • Descrizione della Modifica: Una descrizione chiara e dettagliata della modifica o change request richiesta.
    • Impatto sul Sistema: L’effetto previsto della modifica sul sistema esistente, inclusi eventuali rischi o conflitti con altre funzionalità.
    • Priorità e Scadenze: Indicazioni sulla priorità della modifica e le eventuali scadenze da rispettare.
    • Integrazioni Esterne: Se la modifica richiesta comporta integrazioni con altri sistemi o servizi esterni, fornire informazioni su questi elementi e i requisiti di integrazione.
    • Test e Verifica: Eventuali requisiti relativi ai test di qualità e verifica per garantire che la modifica sia stata implementata correttamente e soddisfi i requisiti specifici.
    • Gestione dei Rischi: Eventuali rischi associati alla modifica e le strategie per mitigarli o affrontarli.
  5. Nuova feature su Software Applicativo in gestione da noi
    • Descrizione e obiettivo della funzionalità: Una spiegazione dettagliata della nuova funzionalità richiesta, comprese le sue caratteristiche principali e i requisiti specifici. Una descrizione chiara degli obiettivi che desidera raggiungere attraverso l’implementazione della nuova funzionalità.
    • Utenti e Ruoli: Indicazioni sui tipi di utenti che utilizzeranno la nuova funzionalità e i relativi ruoli e autorizzazioni associati.
    • User flow: Descrivere il flusso utente previsto per l’utilizzo della nuova funzionalità e le azioni che gli utenti dovranno compiere.
    • Integrazioni Esistenti: se la nuova funzionalità deve integrarsi con altre componenti o sistemi esistenti, fornirci informazioni dettagliate su tali integrazioni.
    • Priorità e Scadenze: Indicazioni sulla priorità della modifica e le eventuali scadenze da rispettare.

Avvio dei progetti

Step da seguire per l’avvio di un nuovo progetto, interno o commissionato esternamente.

Origine della Richiesta di Nuovo Progetto

Un nuovo progetto può essere avviato in seguito a tre scenari:

  • * Richiesta diretta da parte di un cliente, in seguito a una quotazione preventiva (vedere Private ([https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-229532](https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-229532)))
    • Richiesta diretta da parte di un cliente, con pacchetto a ore T&M

    • Necessità interna a f.technology.

Steps per Avviare un Nuovo Progetto interno:

  1. Assegnazione dell’Account: Viene designato un Account, un responsabile interno, all’interno di F.technology.

  2. Definizione dei Parametri Primari (PP):

    1. Data di inizio desiderata
    2. Data di fine desiderata
    3. Descrizione e scope del progetto
    4. Budget indicativo
  3. Approvazione della Direzione: Il benestare del progetto viene richiesto alla direzione, attualmente rappresentata da Franco Farnedi.

Steps per Avviare un Nuovo Progetto esterno:

  1. Assegnazione dell’Account e del PM: Viene designato un Account, solitamente il referente commerciale di F.Technology, e un PM. Se il cliente è già esistente, il progetto viene assegnato al PM già associato a quel cliente. Se il cliente è nuovo, viene scelto il PM di riferimento per questo nuovo cliente.
  2. Creazione progetto in F.Suite: la segreteria crea un codice progetto nel sistema F.suite e una cartella su sharepoint o teams, dove vanno caricati tutti i file legati al progetto.
  3. Passaggio di consegna al PM:
    • Se la richiesta proviene da un cliente esistente di F.Technology, l’Account ha il compito di creare una nuova sezione nella Documentazione Interna dello Space del Cliente, con tutte le informazioni del progetto (vedere )
    • Se il cliente è nuovo, l’account ha il compito di creare un nuovo space (usando il template “Space per clienti Produzione”) e poi completare tutte le sezioni relative nella documentazione interna e fornire tutte le informazioni del progetto. Quindi deve passare il punto seguente al PM di riferimento.
  4. Sistemazione dello Space di Progetto: Il PM rielabora la documentazione interna con le info fornite, organizza lo space, le cartelle e le liste di conseguenza (vedere Private (https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-198492)).
  5. Comunicazione con COO: il PM si coordina con il COO per pianificare il lavoro negli sprint della produzione (vedere Private (https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-198532)).
  6. Redazione Project Charter: Il PM redige un Project Charter.
  7. Assegnazioni: Il lavoro viene assegnato durante lo sprint planning, in base alle disponibilità delle risorse nel team. La persona che si è occupata di fare la prima analisi e quotazione in fase di preventivo diventa il responsabile tecnico del progetto.
  8. Creazione cartella shared:

Nei nostri processi, i progetti non sono vincolati alle singole persone, ma è essenziale che tutto il team sia in grado di lavorare su di essi e di sostituirsi a vicenda quando necessario. Inoltre, è importante che sia il responsabile PM che il responsabile tecnico del progetto abbiano sempre un supporto adeguato, in modo che se dovessero essere assenti, qualcun altro possa prendere il loro posto e garantire il corretto svolgimento delle attività.

Fatturazione & report

Procedure di Fatturazione e Report

Fatturazione al Cliente:

  • L’Account è responsabile della fatturazione al cliente, utilizzando esclusivamente le informazioni presenti nella lista shared e le ore registrate lì.

Possibilità 1 - Pacchetto Ore Prepagato:

  • Se il cliente ha acquistato un pacchetto ore in anticipo, il PM notifica all’Account quando le ore stanno per esaurirsi.
  • L’Account si mette in contatto con il cliente per discutere delle opzioni disponibili, quali l’acquisto di ulteriori ore o la sospensione temporanea dei lavori.

Possibilità 2 - Progetto a Corpo:

  • Se il progetto è a corpo, il PM verifica mensilmente lo stato del budget utilizzando lo space interno.
  • Se richiesto, l’Account fornisce al cliente un report dettagliato delle ore utilizzate, che deve richiedere preventivamente al PM, al bisogno.

Gestione delle Urgenze:

  • Le richieste urgenti da parte del cliente devono essere segnate con un tag apposito, in modo che l’Account possa considerarle durante il processo di fatturazione, come concordato nel contratto.

Guida per PM

Mansioni, responsabilità e compiti del Project Manager

Il Project Manager (PM) ha il compito di gestire efficacemente i progetti assegnati, coordinando tutte le attività e garantendo il raggiungimento degli obiettivi stabiliti. Di seguito sono elencate le principali responsabilità e compiti del PM:

Gestione degli Spazi e delle Cartelle per i Clienti:

  • * Creare e gestire gli space e le cartelle dei clienti seguendo le linee guida stabilite:[](https://app.clickup.com/2402546/v/dc/29a7j-24360/29a7j-198492?block=block-3cd19e90-5f17-4756-a6d7-7628b20e1c0d)
    • Creare e gestire le cartelle condivise con i clienti, secondo quanto stabilito:

Creazione e Gestione dei Task:

  • * Creare task dei progetti in modo completo e accurato, seguendo le procedure stabilite:[](https://app.clickup.com/2402546/v/dc/29a7j-24360/29a7j-198452?block=block-78666a47-d872-40b0-99c1-e1fca7368ee9)

Controllo del Budget e delle Ore:

  • * Il PM è responsabile della supervisione del budget dei progetti a corpo o delle ore totali dei pacchetti a ore. È tenuto a informare tempestivamente l'account quando si sta per raggiungere il limite definito. La frequenza di questo controllo varia in base alle esigenze specifiche del progetto o del cliente, potendo avvenire al termine di ogni sprint, settimanalmente o anche giornalmente.

Comunicazione con i Clienti:

  • * Rispondere alle email e interagire con i clienti in modo professionale e tempestivo, cercare di non fare attendere più di 2 giorni per rispondere. Le urgenze invece vanno gestite nel giro di poche ore.

Gestione delle Notifiche su ClickUp:

  • * È necessario un controllo frequente delle notifiche su ClickUp, più volte al giorno, per garantire una gestione efficace delle attività e una risposta tempestiva alle richieste del team.

Aggiornamento dei Task e dei Task Board:

  • * Monitorare i task all'interno degli sprint, aggiornare le scadenze e fornire informazioni necessarie al bisogno.

Aggiornamento della Documentazione:

  • * Assicurarsi che la documentazione sia costantemente aggiornata e verificare che tutti i membri del team seguano questa pratica.

Taggare i Task e Gestione delle Urgenze:

  • * È importante taggare i task seguendo le linee guida, sia sulla lista condivisa che su quella interna per gestire future contestazioni o richieste di report dall'Account. I task urgenti devono essere segnalati come tali per poter gestire la fatturazione diversa in base al contratto.

Segnalazione Informazioni Mancanti nei Progetti:

  • * Il PM è tenuto a segnalare all'account quando mancano informazioni rilevanti per il progetto, perchè possa fare il proprio lavoro in modo efficace.

Overview e Retrospective dei Progetti:

  • * Condurre riunioni di overview e retrospective dei progetti, fornendo una panoramica dettagliata del lavoro svolto e da svolgere.

Archiviazione dei Progetti Conclusi:

  • * Una volta conclusi, il PM deve archiviare cartelle e sprint di progetto per mantenere un ambiente di lavoro organizzato, come da linee guida.

Deleghe e sostituzioni:

  • * Designare una persona sostitutiva per controllare i progetti durante le sue assenze.
    • Avvisare i clienti in caso di assenza e presentare il sostituto.
    • Utilizzare anche altri colleghi per attività di QA, testing, documentazione e comunicazione con il cliente, per distribuire meglio il carico di lavoro

Automatizzazione delle Notifiche:

  • * È consigliabile attivare un'automazione per ricevere notifiche ogni volta che viene creato un nuovo task negli space dei propri progetti

Documentazione delle riunioni:

  • * Dopo le videocall con i clienti, il PM dovrebbe creare un task denominato "SAL {{data}}" o "Riunione \_\_\_ {{data}}" e redigere un documento riassuntivo del meeting.

Comunicazione con il cliente:

  • * Il PM dovrebbe scrivere al cliente tramite ClickUp utilizzando le card pertinenti nelle liste condivise.

Tracciamento delle Ore e Creazione di Task Specifici:

  • * Il PM dovrebbe cercare di tracciare le ore direttamente nei task seguiti e creare task specifici per le attività che lo richiedono, come riunioni, SAL e gestione su clickup del progetto, evitando l'uso di task troppo generici.

Gestione del Product Backlog

  • * Il PM è responsabile della gestione del Product Backlog, che include la raccolta dei requisiti, la definizione delle user stories e la valutazione delle priorità. Inoltre, redige use case per le nuove funzionalità da sviluppare.

Riunioni con il team

  • * Il PM collabora attivamente con il team di sviluppo, partecipando alle riunioni quotidiane, al planning dello sprint e alla retrospective.

Quality Assurance:

  • * Il PM deve verificare il lavoro svolto (QA) prima di mostrarlo al cliente finale.

Sprint

Organizzazione & guida agli Sprint del Team

Organizzazione degli Sprint

Questo documento fornisce linee guida sull’organizzazione degli sprint secondo la metodologia Agile, considerando la gestione di più progetti contemporaneamente.

Raccolta dei Task per lo Sprint Successivo

I task per lo sprint successivo devono essere forniti entro il venerdì precedente all’inizio dello sprint.

Call di Allineamento, Sprint Planning e Assegnazione dei Task

La call di allineamento, lo sprint planning e l’assegnazione dei task sono considerati come una singola riunione focalizzata sulla pianificazione dello sprint. Questo incontro si tiene ogni due settimane all’inizio dello sprint e coinvolge il team di sviluppo, i Project Manager e i Product Owner interni. Durante questa riunione, vengono discussi i task disponibili, quantificato l’effort in sprint point e assegnati i task ai membri del team per lo sprint in corso. Lo scopo principale è di mettere il team di sviluppo nelle condizioni di suddividere le attività in modo equilibrato, garantendo il raggiungimento degli obiettivi stabiliti per lo sprint. I task comunque non devono essere preventivamente assegnati ai membri del team ma si deve lasciare che vengano scelti, salvo urgenze, sovraccarico di una persona, o altro.

Stand Up

Le stand-up meetings si tengono ogni mattina alle 9:10 e durano circa 20 minuti. Durante queste riunioni, ogni membro del team aggiorna gli altri sul proprio progresso, eventuali problemi e i piani per la giornata.

E’ importante che i membri del team prendano appunti sulle attività che dovranno svolgere e sulle richieste di PM e COO, sia durante lo sprint planning che durante gli stand up.

Review/Retrospective

La retrospective si svolge l’ultimo venerdì dello sprint e coinvolge il team di sviluppo e i Project Manager. Durante questa sessione, i membri del team hanno l’opportunità di riflettere sullo sprint appena concluso, identificare le sfide incontrate e discutere di eventuali miglioramenti per il futuro. E’ un’occasione anche per presentare e rivedere i progetti conclusi o in avanzamento agli altri membri del team.

File di Sprint Planning su Teams

Il file di sprint planning su Teams è un documento Excel che elenca i progetti attivi con colonne per ogni sprint passato e futuro. Le celle indicano il numero di sprint point dedicati a quel progetto per lo sprint specifico, facilitando la visualizzazione e la pianificazione del lavoro. Questo file deve essere aggiornato prima dell’inizio di un nuovo sprint per permettere ai Pm di organizzare il lavoro e pianificare il numero di attività previste. Alla riunione di pianificazione partecipano Account, COO e PM. Il file va aggiornato prima del planning e dopo la retrospective ogni 2 settimane: programmazione sprint 2024.xlsx

Produzione <> Assistenza

Gestione dei Task tra Produzione e Assistenza

Passaggio di un Task dall’Assistenza alla Produzione

  • Identificare il cliente tra gli space su ClickUp

  • Creare un task nella lista Ticket

  • Inserire nel task tutte le informazioni necessarie [Vedere ➝ ]

  • Non assegnare il task a nessuno del team, ma esprimere un eventuale consiglio sull’assegnazione nei commenti, eventualmente.

  • Il PM del cliente ha un Automation sullo space per cui verrà automaticamente notificato della creazione del task.

  • Il PM è incaricato di duplicare il task nella cartella shared del cliente e ad attività conclusa, deve riportare le ore da fatturare nel task condiviso

  • Vedere per la gestione dei task shared e la comunicazione con il cliente

Passaggio di un Task dalla Produzione all’Assistenza

  • Scrivere task
  • Assegnarlo a una persona del team assistenza
  • Notificare su teams alla persona se è urgente da svolgere nei successivi due giorni
  • Ata alla persona avvisare se non riesce a rispettare la scadenza
  • Il PM è incaricato di duplicare il task nella cartella shared del cliente e ad attività conclusa, deve riportare le ore da fatturare nel task condiviso
  • Vedere Private (https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-195392) per dettagli

Figma

Guida all’utilizzo di Figma e al metodo, e alla strutturazione dei progetti

Introduzione

Questo documento fornisce linee guida sull’utilizzo di Figma, un’applicazione di progettazione e prototipazione collaborativa basata sul web. Seguire queste indicazioni per massimizzare l’efficienza e la collaborazione nel processo di progettazione e sviluppo.

Figma Dev

  • Integrazione con lo Sviluppo: Figma Dev consente di collegare direttamente il design agli asset di codice, facilitando la trasformazione del design in codice.

Styleguide

  • Griglie, Spacing, Typography, Colors: Definire e documentare regole e parametri relativi alle griglie, spaziatura, tipografia e colori per garantire coerenza e coesione nel design.

Naming

  • Convenzioni di Denominazione: Utilizzare una convenzione di denominazione coerente per organizzare e identificare facilmente i vari elementi del progetto.

Componenti e Varianti

  • Organizzazione: Creare componenti e varianti per facilitare il riutilizzo e la coerenza del design in tutto il progetto.

Auto Layout e Constraint

  • Auto Layout: Utilizzare Auto Layout per mantenere la flessibilità e l’adattabilità degli elementi del design in diverse dimensioni e orientamenti.

Handoff e Commenti nei Componenti

  • Handoff: Utilizzare la funzionalità di Handoff per comunicare con chiarezza le specifiche di design agli sviluppatori.
  • Commenti: Utilizzare i commenti nei componenti per fornire informazioni aggiuntive e istruzioni per la loro implementazione.

Variables

  • Variabili Globali: Definire e utilizzare variabili globali per semplificare la gestione e l’aggiornamento dei parametri di design.

Prototipi

  • User Flow, Wireframe, Design: Utilizzare Figma per creare prototipi che vanno dallo user flow, al wireframe, al design completo di pagine per l’approvazione.

Inserire Link a Figma Doc

  • Condivisione: Condividere link ai documenti Figma per consentire la collaborazione e il feedback da parte del team e degli stakeholder.

Uso delle Pagine

  • Organizzazione: Utilizzare le pagine per organizzare e strutturare il progetto in modo logico e accessibile.

Uso delle Dipendenze delle Librerie

  • Gestione delle Dipendenze: Utilizzare le dipendenze delle librerie per gestire e aggiornare facilmente i componenti condivisi all’interno del progetto.

Organizzazione dei Componenti

  • Struttura: Organizzare i componenti in modo logico e gerarchico per facilitare la ricerca e il riutilizzo.

Differenziare tra Componente di Design e di Sviluppo

  • Design vs Sviluppo: Distingui tra componenti utilizzati per il design e quelli utilizzati per lo sviluppo, garantendo una corretta comunicazione tra designer e sviluppatori.

Animazioni

  • Transizioni: Utilizzare le funzionalità di animazione di Figma per creare transizioni fluide e coinvolgenti tra le schermate.

Messaggi e Status di Errori e Successo

  • Feedback Utente: Progettare messaggi di errore e successo chiari e intuitivi per migliorare l’esperienza utente.

Fase di Analisi & Design

Step da seguire per la fase di analisi e design per i nuovi progetti

1. Problem statement

Si stabiliscono gli obiettivi attuali del prodotto, il problema che il cliente desidera affrontare e le richieste di miglioramento legate alle soluzioni proposte.

2. Proto-personas

SI definiscono le pro-personas, le user stories e le strategie per risolvere i problemi degli utenti.

3. Features List

Si descrive la lista di features da implementare, per soddisfare le esigenze del gruppo di utenti. 

4. User flow

Si definiscono diversi user flow che aiutino a descrivere il flusso applicativo. 

5. Wireframe

Si prosegue per produrre un primo wireframe (low-fidelity prototype). 

6. Styleguide

Si imposta una libreria di pattern e componentistica che codifica gli elementi interattivi, visivi e di contenuto dell’interfaccia utente. 

7. High Fidelity Prototype 

Si procede alla creazione di un primo prototipo high-fidelity per cominciare la fase di user testing.

Tech

Rinnovo certificati

es. cosa è stato fatto in questo task? Private (https://app.clickup.com/t/8693yva3f)

Pipeline & Actions

ASSISTENZA & HELPDESK

Responsabile: Andrea S. & Marta

A partire dal 01/03/2024 entrerà in vigore questo documento.

Una volta ricevuta una richiesta di supporto, è necessario esaminare la specifica situazione e procedere con il suo trattamento secondo il seguente schema:

Sono disponibili diversi punti di contatto per ricevere assistenza, principalmente gestiti dalla “Segreteria Operativa”. Tuttavia, questa divisione non limita il coinvolgimento attivo del “Tecnico” nel supportare direttamente gli attori sul campo; anzi, si incoraggia il Tecnico a partecipare attivamente alla gestione di tali punti di contatto.

Touchpoint : ovvero i tool da tenere sempre aperti e monitorati:

3CX ➝ Telefono + Chat

E-mail ➝ personale + shared email support@f.technology

ClickUP ➝ Notifiche su Task o notifiche via e-mail

Microsoft Teams ➝ generalmente usato solo per uso interno

Zendesk ➝ in dismissione entro fine anno

Form self-service: https://f.technology/form-richieste-supporto/

come verificare se esiste un PM e un contratto assegnato al cliente?

vedi capitolo Private (https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-235312)

come capire se il task è Assistenza o Produzione? e come gestirlo?

Di norma se la richiesta rientra in una delle categorie disponibili nello space ASSISTENZA lista Ticket ovvero :

ci troviamo davanti ad un attività da eseguire 9 volte su 10 dal team assvstenza.

L’assistenza ha altresì il compito di HelpDesk 1° livello anche per i ticket relativi a clienti di produzione. In sostanza se “la richiesta” può essere evasa dal team di assistenza è di sua competenza.

PREMESSA: OGNI cliente attivo con pacchetto ore o contra

Task di assistenza: Dove? : nello space del cliente ma SE non esiste lo SPACE CLIENTE in Assistenza>Ticket>Ticket

Creare o aggiornare il task e assegnarlo in base ai ruoli aziendali indicando scadenza , richiedente e priorità. SE il tecnico di Turno assegnato non riesce a rispettare il compito o la scadenza chiede aiuto ad un collega per la risoluzione e si accorda per il cambio assegnatario ( non va oatto in maniera selvaggla )

In taso si ravvisi un ALTA priorità ( o scadenza imminente ) avvisare un responsabile via teams (Franco/Andrea/PM).

Uso di indirizzi E-Mail personali (o diversi da support@) per le assistenze:

L’uso delle e-mail personali per l’assistenza è di norma vietato e deve essere disincentivato tramite opportune comunicazioni: ad es.

”Buongiorno Mario Rossi, in caso di richieste di assistenza ti inviamo a contattarci sempre all’indirizzo support@f.technology o aprire una richiesta sul nostro sito : https://f.technology/form-richieste-supporto/

Se il cliente scrive a una mail personale o a una mail diversa da support@f.technology, la richiesta deve essere inclusa nel flusso di assistenza. Il destinatario della comunicazione dovrà, previa verifica delle condizioni spiegate nel flow chart soprastante, inoltrare la mail all’indirizzo presente nella sezione “touchpoint e-mail” assicurandosi di inserire nell’oggetto della stessa l’id della card ClickUP relativa alla richiesta. Procederà quindi a rispondere al cliente dalla shared mailbox o direttamente dentro alla card clickup, sincerandosi di utilizza e l’indirizzo email condiviso support@

Modalità di lavoro Shared E-Mail:

La cassltta preposta deve essere cosi gestita:

INBOXi➝ a prescindere dallo ctatus ( letto/non letto) sono e-mail da gestire. E’ possibile usart TAG di pre assegnazione ( ANDREA,EUGENIO,MARTA,ETC.) per suddividerle logicamente.

Vige la legge della “INBOX ZERO” ovvero chi entra in contatto con questo touchpoint deve gestirlo ed inserirlo nel flusso.

IN GESTIONE ➝ sono E-mail/Thread relative a task ClickUP o comunque in corso di lavorazione. E’ possibile usare TAG ( da definire collegialmente) per suddividerle logicamente. Deve tendere allo ZERO MAILBOX. una volta terminata la card va spostato la conversazione in chiuse.

CHIUSE ➝ sono E-mail/Thread relativi a card chiuse. NON devono esserci email da leggere. se ci sono probabilmente entriamo nella casistica qui sotto descritta:

Zendesk ed Altri Touchpoint

Di base vige la regola dell’indirizzo e-mail personale. La richiesta va spostata/replicata e gestita in ClickUP e l’uso di email servirà eventualmente solo per comunicare al cliente lo status della lavorazione.

RISPOSTAvAL CLIENTE

E’ buona cosa scrivere al cliente (da mail support@ o direttamente da ClickUp), indicando che la richiesta è stata ricevuta e verrà presa in carico dal team inserendo nell’oggetto della mail #ID ClickUp : es di Oggetto:

#ABC123 - Richiesta di assistenza per problema a pc portatile/

Chiusura Lavorazione

una volta terminato il task, l’assegnatario deve metterlo in stato CLOSED. Da questo momento la gestione passa all amministrazione a cui deve essere passato il task con assegnazione o tag e commento del tecnico per procedere.

Per i ticket relativi a clienti di produzione. In sostanza se “la richiesta” può essere evasa dal team di assistenza è di sua competenza.

PREMESSA: OGNI cliente attivo con pacchetto ore o contra

Task di assistenza: Dove? : nello space del cliente ma SE non esiste lo SPACE CLIENTE in Assistenza>Ticket>Ticket

Creare o aggiornare il task e assegnarlo in base ai ruoli aziendali indicando scadenza , richiedente e priorità. SE il tecnico di Turno assegnato non riesce a rispettare il compito o la scadenza chiede aiuto ad un collega per la risoluzione e si accorda per il cambio assegnatario ( non va fatto in maniera selvaggia )

In caso si ravvisi un ALTA priorità ( o scadenza imminente ) avvisare un responsabile via teams (Franco/Andrea/PM).

Task di Produzione: generalmente per tutti i casi di BugFix software, Modifiche su progetti, nuove funzionalità.

Ogni cliente con contratto attivo di produzione ha uno Space assegnato con al suo interno una lista ticket. In questo caso il task va creato nell’apposita lista avendo cura di avvisare il PM della richiesta da gestire. qui le istruzioni dettagliate: Private (https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-198572) qualora non esista il posto giusto appoggiarli qui: 901201769937 (https://app.clickup.com/2402546/v/li/901201769937)901201769937 (https://app.clickup.com/2402546/v/li/901201769937)

Uso di indirizzi E-Mail personali (o diversi da support@) per le assistenze:

L’uso delle e-mail personali per l’assistenza è di norma vietato e deve essere disincentivato tramite opportune comunicazioni: ad es.

”Buongiorno Mario Rossi, in caso di richieste di assistenza ti inviamo a contattarci sempre all’indirizzo support@f.technology o aprire una richiesta sul nostro sito : https://f.technology/form-richieste-supporto/

Se il cliente scrive a una mail personale o a una mail diversa da support@f.technology, la richiesta deve essere inclusa nel flusso di assistenza. Il destinatario della comunicazione dovrà, previa verifica delle condizioni spiegate nel flow chart soprastante, inoltrare la mail all’indirizzo presente nella sezione “touchpoint e-mail” assicurandosi di inserire nell’oggetto della stessa l’id della card ClickUP relativa alla richiesta. Procederà quindi a rispondere al cliente dalla shared mailbox o direttamente dentro alla card clickup, sincerandosi di utilizzare l’indirizzo email condiviso support@

Modalità di lavoro Shared E-Mail:

La cassetta preposta deve essere cosi gestita:

INBOX ➝ a prescindere dallo status ( letto/non letto) sono e-mail da gestire. E’ possibile usare TAG di pre assegnazione ( ANDREA,EUGENIO,MARTA,ETC.) per suddividerle logicamente.

Vige la legge della “INBOX ZERO” ovvero chi entra in contatto con questo touchpoint deve gestirlo ed inserirlo nel flusso.

IN GESTIONE ➝ sono E-mail/Thread relative a task ClickUP o comunque in corso di lavorazione. E’ possibile usare TAG ( da definire collegialmente) per suddividerle logicamente. Deve tendere allo ZERO MAILBOX. una volta terminata la card va spostato la conversazione in chiuse.

CHIUSE ➝ sono E-mail/Thread relativi a card chiuse. NON devono esserci email da leggere. se ci sono probabilmente entriamo nella casistica qui sotto descritta:

Zendesk ed Altri Touchpoint

Di base vige la regola dell’indirizzo e-mail personale. La richiesta va spostata/replicata e gestita in ClickUP e l’uso di email servirà eventualmente solo per comunicare al cliente lo status della lavorazione.

RISPOSTA AL CLIENTE

E’ buona cosa scrivere al cliente (da mail support@ o direttamente da ClickUp), indicando che la richiesta è stata ricevuta e verrà presa in carico dal team inserendo nell’oggetto della mail #ID ClickUp : es di Oggetto:

#ABC123 - Richiesta di assistenza per problema a pc portatile/

Chiusura Lavorazione

una volta terminato il task, l’assegnatario deve metterlo in stato CLOSED. Da questo momento la gestione passa all amministrazione a cui deve essere passato il task con assegnazione o tag e commento del tecnico per procedere.

Varie

se un cliente deve prendere un appuntamento diretto con Andrea Schwibbert qui il calendario

https://f.technology/calendario-andrea-schwibbert/

selezionando assistenza da remoto od urgente c’è un modulo di pagamento associato,

la casistica MSP gia pagata è solo per i clienti MSP o pacchetto ad ore

la casistica call 30 minuti è tecnico/commerciale , no assistenza

verifica se esiste contratto

Per erogare assistenza serve un contratto

Verifica esistenza contratto:

Dove:

File matrice excel relativo a PM / progetti: https://fsites.sharepoint.com/:x:/s/PROGETTI/EexwjX7MqWNFlEdU_v5_AccBlsJTw5eKLO—INsmg5PwLQ?e=eaeZG4

FSUITE ➝ Clienti e fornitori ➝ selezionare il cliente ➝ Progetti

FSUITE ➝ Clienti e fornitori ➝ selezionare il cliente ➝ Servizi (per i WP-HELP)

Richiedi un nuovo contratto: ➝ Aprire un task ClickUp

Dove? : Preventivi&Contratti ➝ Hot

poi assegnare task a Franco e a Marta/Doha

riportare nel task il contenuto della mail e indicare nell’oggetto del task:

#IDCLICKUP - Nome cliente - Proposta Contratto

E’ necessario rispondere al cliente che, per poter ricevere assistenza, è necessario sottoscrivere un contratto di assistenza o di manutenzione. Riceverà una proposta dal nostro reparto commerciale – oggetto mail: ID ClickUp.

Se si ravvisa un Urgenza, sentire il responsabile per autorizzazioni straordinarie.

Task: casi particolari

alcuni task di assistenza possono essere assegnato in base al workload ad amministrazione (Alessandro / Doha) se rientra in una di queste casistiche:

  • attivazione / disattivazione account Google Workspace
  • attivazione / disattivazione account Microsoft 365
  • gestione licenze Adobe
  • rinnovi FileMaker

Task: ingresso e sospesi

Gestione di task in ingresso e sospesi:

  • la segreteria operativa durante il turno di presidio verifica regolarmente i touchpoint interfacciandosi attivamente con i tecnici disponibili per le nuove assegnazioni/segnalazioni

  • Regolarmente ( 1 volta al giorno ) verifica i task sospesi e/o scaduti per gestirne lo sblocco se possibile

Carico di Lavoro

BOZZA: manca custom field da definire con @Franco Farnedi e

dashboard Private (https://app.clickup.com/t/869418q04) : Private (https://app.clickup.com/2402546/v/wl/29a7j-50792)

nei task assegnati, la segreteria operativa deve popolare sempre:

AVANZAMENTO

SCADENZA

TEMPO STIMATO LAVORAZIONE

PRIORITA’

esempio corretto:

se durante la lavorazione cambia effort o timing : Aggiornarli !

Notificare vulnerabilità per siti NON WP-HELP

Notificare vulnerabilità ai non WP-HELP

Per notificare vulnerabilità a chi non sia a WP-HELP (specialmente nel caso di avvisi provenienti da Kinsta) utilizziamo Mailpoet sul sito f.technology.

Lista referenti

La lista Vulnerabilità siti viene integrata di volta in volta con le email da avvisare.

Se il sito xxx.com è vulnerabile e il referente è Tizio Caio, costui andrà aggiunto alla lista in questione e gli andrà assegnato un tag col dominio del sito: xxx.com.

Di base @Andrea Balestri sa chi sono i referenti perché nei mesi li ha contattati tutti.

Creazione email

Si crea una mail a partire da una segnalazione già inviata e si modifica di conseguenza.

Consiglio di prevedere sempre 2h massime oltre le quali si avverte il cliente. E’ quanto specificato anche nella pagina sul sito.

Questo è importante perché spesso si presentano altre vulnerabilità da risolvere, non segnalate da Kinsta…

Destinatari notifica

L’ideale sarebbe segmentare la Lista vulnerabilità ma non è sempre cosa veloce.

Come prassi attuale stiamo selezionando da Lista vulnerabilità i referenti coinvolti (purché non si siano cancellati dalla lista) assegnandoli a liste create per le segnalazioni su ogni plugin.

Non è infatti possibile assegnare tag in blocco e segmentare rapidamente.

Impostazioni

Il reply-to predefinito è support@f.technology .

Creazione Folder Assistenza

procedura da definire.. bozza

  • creare contratto codice su f.suite
  • fare fattura
  • creare Space ClickUp
  • Creare foder Clickup

Iubenda

In questo capitolo definiremo come useremo i servizi di Iubenda, in fase di:

Configurazione

Gestione Alert e Supporto

Configurazione

Come configurare Iubenda lato tecnico e lato commerciale

Gestione alert e supporto

come gestire i vari avvisi che arrivano da Iubenda e in particolare come gestire i casi in cui:

Cliente ha WP-HELP Unlimited

Decidere se prevede GDPR incluso (direi di si)

Cliente ha un altro contratto di manutenzione

Se prevede monitoraggio GDRP incluso

Tutti gli altri casi

Non prevede monitoraggio GDPR incluso

Chiusura Ticket senza Dashboard Shared

Private (https://app.clickup.com/t/86943qhv5)

Flusso assistenza a scalare e senza contratto

Esistono cinque casi di richiesta di assistenza tecnica:

  1. quelli senza contratto assistenza
  2. quelli con contratto di assistenza a scalare
  3. quelli con contratto di manutenzione
  4. quelli relativi a progetti in Sviluppo o in garanzia
  5. quelli che sono connessi a ordini di nuovi servizi o prodotti

1. Senza contratti di assistenza

Gli interventi senza contratto, fatto salvo accordi diversi che vi autorizzo io o Andrea, vanno sempre fatti firmare/approvare con un preventivo scritto (meglio se formalizzato su f.suite)

Quindi iter ordinario è:

  1. richiesta
  2. analisi
  3. preventivo
  4. accettazione
  5. intervento
  6. collaudo (+ Review)
  7. fattura

2. Con contratto assistenza a Scalare

In questo caso l’iter è più diretto

  1. richiesta

  2. intervento

    1. se minore di 2h - si procede
    2. se maggiore 2h:
      1. quotazione
      2. accettazione
      3. si procede
  3. collaudo (+ Review)

3. Con contratto di manutenzione

Se il cliente segnala la presenza di un contratto di manutenzione o vi è il dubbio da parte della segreteria che rientri in un contratto in essere, si procede così:

  1. richiesta

  2. intervento

    1. se incluso nel contratto - si procede
    2. se non incluso - si passa al PM o al Commerciale per quotazione e preventivo
  3. collaudo (+ review)

4. Progetti in sviluppo o in periodo di garanzia

  1. richiesta

  2. girare la richiesta a Produzione (PM del progetto o PMO)

5.Connesso a ordine o servizio hosting managed

Alcune richieste di assistenza sono connesse alla presenza di servizi già venduti che godono di supporto tecnico incluso o sono richieste di acquisto di nuove licenze (integrazioni a esistenti) o di nuovi prodotti

In questo caso chiedere supporto a Andrea o Franco


Procedure valide per tutti i casi

Apertura task/card in Clickup

Usare template specifico definito secondo questo schema (da completare)

Titolo chiaro e specifico

Standard field

Stima time

Data di consegna prevista

urgenza: flag

Custom field

Cliente:

Email cliente:

Telefono Cliente:

Tipo intervento:

Corpo Task

Descrizione richiesta cliente:

Sito/app/servizio: indicare chiaramente url, dominio o sistema.

Analisi dell’intervento preventiva: a cura del tecnico o dell’analista

Quotazione cliente: indicare come si è determinata la quotazione che andrà fatturata o scalata dal pacchetto ore

Eventuali Note importanti da cliente: da aggiungere durante l’intervento

Note tecniche per documentazione: inserire durante intervento qui poi da riportare eventualmente in documentazione

Link documentazione: qui

Note per fatturazione: eventuali note post intervento per fatturazione/addebito

File allegati

quando possibile usare link a file su Sharepoint in cartella cliente o Preventivo o Teams

Stima preventiva

La stima preventiva di un task va indicata nel budget ore di ClickUp e condivisa con il cliente nelle prime fasi di attività tecnica e dialogo con il cliente stesso. La stima è a cura del tecnico o del commerciale: non della segreteria

Sforamento stime

Se durante l’intervento la stima delle ore Billable superano la stima bisogna avvisare immediatamente il commerciale o il PM quando previsto.

Chiusura di un task di assistenza

Ogni task di assistenza andrebbe di norma assegnato ad un collega con adeguate competenze per una verifica finale (REVIEW) prima di essere chiuso.

Tale attività può essere svolta sia prima di confermare la chiusura dell’intervento da parte del cliente (attività che è in carico al tecnico che ha eseguito l’intervento) che eventualmente dopo aver comunicato al cliente il termine del lavoro.

Scopo di tale procedura è garantire l’alta qualità del lavoro svolto e la condivisione di know-how nel team. Chi effettua la REVIEW deve tracciare il proprio tempo.

Nel corso delle comunicazioni con il cliente il tecnico dovrebbe esimersi da indicare i tempi totali di esecuzione se sono interni al budget di stima fornito inizialmente.

Conferma o mini-collaudo

Al termine dell’intervento, il tecnico deve richiedere una formale conferma scritta del cliente che l’intervento è chiuso con successo e soddisfazione. Usare email interna di Clickup o email diretta con cc: Clickup il task relativo. Solo a ricevimento della conferma il task potrà essere passato in fatturazione.

Documentazione

Ogni task che comportati una variazione di configurazioni, setup o modifiche rilevanti, deve essere riportato in adeguata sezione di documentazione tecnica dal tecnico che ha eseguito l’intervento (Clickup Doc o ITglue)

Nel corso dello svolgimento del task se si eseguono commenti interni o con il cliente, rilevanti al fine della descrizione del task, bisogna riportarli dal thread dentro al corpo della card in maniera strutturata e sintetica.

Tracking Time

Tutto il tempo impiegato dal tecnico deve essere opportunamente tracciato su Clickup con il flag Billable e non Billable in accordo al contesto, e anche la gestione segreteria deve tracciare tutto il suo tempo dedicato alla pre-gestione del task ed a tutti i suoi interventi sucessivi come Billable

Quando è non Billable?

L’intervento è da indicare non Billable quando non è ritenuto corretto addebitarlo al cliente per problemi soggettivi, errori, o attività di contorno che si associano al task ma non sono direttamente connessi alla sua soluzione.

Addebito e fatturazione

Il tecnico che esegue e completa l’intervento deve indicare se ci sono tempi da non fatturare (da segnare diversificando quelli billable e quelli non billable) e se ci sono accordi particolari che scaturiscano dalla conversazione con il cliente durante l’esecuzione del lavoro e siano in difformità con quanto descritto nella card in termini di costi e addebiti.

Il commerciale può inserire in card particolari istruzioni straordinarie che escano dallo standard per l’esecuzione del flusso di gestione.

HOSTING E PRODOTTI

In generale, tutti i servizi che vengono attivati devo essere mappati su Filemaker, con dominio, cliente e servizio da fatturare generato come “elemento da fatturare”

Siti o servizi che non comportano addebito in fattura ma è utile tracciare

Vedi casi specifici nei rispettivi capitoli.

Rinnovo prodotti manuale

Alcuni prodotti hanno il rinnovo manuale, e pertanto vanno ordinati preventivamente, e di conseguenza, confermato il pagamento del cliente prima del rinnovo.

Il flusso da seguire è il seguente:

Verificare che il prodotto abbia il Flag Rinnovo Manuale sul catalogo F-Suite

Si emette proforma/fattura al cliente anticipata per farsi pagare

All emissione della stessa su F-Suite …

Register.it

Su Register alcuni clienti hanno il rinnovo manuale e quindi periodicamente bisogna verificare i prodotti in scadenza.

Private (https://app.clickup.com/t/2x5gaaz) scadenza vanno inviati a:

Franco

Alessandro

Andrea B.

valutare con Ale e Andrea come arrivano gli alert di rinnovo e altri alert di sicurezza.. ora ho impressione che vadano “persi” a volte su servizi@ perchè ci sono troppe cose.. meglio dividere per grado.. cose che devono essere viste.. contro cose che arrivano li e possono essere trovate..

AWS

Verifica periodicamente se ci sono dei servizi non mappati in F.suite

Kinsta

Quando si attiva un servizio di hosting su Kinsta si dividono due casi particolari:

  • cliente ordinario
  • cliente multi sito

Cliente ordinario

Dopo aver attivato il servizio sul Kinsta:

  • associare al sito un tag con codice cliente f.suite

  • Inserire il servizio attivato nell’elenco delle “Attività da fatturare” indicando: dominio, data attivazione, eventuali accordi contrattuali (costo, termini, preventivo, progetto)

  • attivare almeno una email del cliente al pannello e mandare invito ad accedere se è nuovo cliente attivato prima volta su Kinsta

Cliente multi sito

Dopo aver attivato il servizio su Kinsta procedere come segue:

  • associare al sito un tag con codice cliente f.suite

  • Inserire il servizio nell’elenco multi-site kinsta excel del cliente inserendo box colorato nel mese di attivazione
  • attivare almeno una email del cliente al pannello

SSL

All’acquisto e attivazione di un nuovo certificato SSL, dopo il suo censimento, viene creato un task su CU assegnato ad Alessandro in TICKET/Rinnovo servizi con ripetizione annuale e due date 15 giorni prima della scadenza del servizio in corso. Sarà poi sua cura creare un ticket Zendesk e assegnarlo ad Andrea per la gestione.

Una volta fatto, Andrea ripasserà il ticket ad Alessandro per concludere la gestione amministrativa.

SpinupWP

Per quanto riguarda i siti attivati sul server Spinup di un cliente, non è necessario tracciarne la presenza su Filemaker nell’area servizi.

Chiusura servizi scaduti/cancellati

Scopo di questo capitolo è definire le procedure da adottare quando un servizio deve essere cancellato e non rinnovato.

Casistiche di chiusura di servizio

Utente disdice il servizio

Quando il servizio viene cancellato dal cliente che richiede la sua disattivazione, si deve raccogliere una email (copia) e allegarla come prova nell’archivio servizi e descrivere in nota del servizio.

Si deve porre lo stato rinnovo in “Disdire fine Periodo” se la data si rinnovo è nel futuro, oppure in Cancellato se è passata.

In fine si deve predisporre la funzione “non rinnovare il servizio” sui servizi che lo prevedono.

Se non è possibile automatizzare questo processo, inserire un task su Clickup 901201837531 (https://app.clickup.com/2402546/v/li/901201837531) con la data di cancellazione (un giorno prima o giorno dopo) e assegnarlo alla Segreteria.

Utente non risponde alla richiesta di rinnovo o non paga

In questo caso si deve conservare come allegato nel servizio su f.suite una copia delle email che comprovino i tentativi di contatto con cliente e l’esito e descrivere in nota del servizio.

Poi si procede come sopra per la cancellazione.

Il servizio non è più rinnovabile per motivi tecnici

In questo caso si deve documentare con allegati email la comunicazione inviata al cliente, sue risposte e descrivere nelle note come si è deciso di procedere (sostituzione, cancellazione, trasferimento).

Per i tecnici

Quando si cancella un servizio di hosting a livello tecnico bisogna verificare (o farlo verificare alla segreteria) lo stato di rinnovo su archivio F.suite / Servizi e Hosting e aggiornare lo stato con “cancellato”

e scrive chiaramente nelle note del servizio cosa si è fatto per cancellare ed evitare che il servizio rimanga attivo e continui a costituire un costo.

Alcune casistiche concrete

Kinsta

Su Kinsta abbiamo 200 siti pagati di cui usati una parte.. mentre sullo spazio disco abbiamo dei limiti… quindi per quanto sia utile cancellare siti che occupano spazio inutilmente è a volte opportuno procedere con calma:

  • contrassegnare come detto in f.suite
  • aggiongere tag “cancellato” su Kinsta
  • segnalare alla direzione l’eventuale servizio da cancellare
  • se si ha tempo eseguire un backup del sito e caricarlo su NAS o Sharepoint del cliente
  • indicare l’azione e link del backup su scheda f.suite

Servizi hosting custom

DRAFT

Questo capitolo del PLAYBOOK affronta i casi in cui l’hosting venduto sia composto di numerosi servizi diversi che vengono venduti a corpo e spesso con incluso il costo di manutenzione: alcuni di questi casi potremmo definirli “hosting a valore aggiunto” oppure hosting full managed”.

Definizione diversi tipi di hosting

Hosting a valore aggiunto

E’ un servizio di hosting che include anche servizi tipici dei contratti di manutenzione, SLA speciali e altri servizi aggiuntivi. Il prezzo è custom e non esiste a listino ma è calcolato cliente per cliente e caso per caso.

Hosting full managed

L’hosting che acquista f.technology è quasi sempre di tipo managed (raramente lo vendiamo senza il nostro management ovvero di tipo naked e quando lo fosse è opportuno indicarlo nel nome o nella descrizione) pertanto si indica hosting full manged quando al servizio standard offerto dal fornitore aggiungiamo un supporto aggiuntivo incluso nel prezzo. Di norma l’hosting full managed non include tutti gli extra inclusi nell’hosting a valore aggiunto e quindi costa di meno ed è codificato a listino con un prezzo specifico.

Hosting standard

È l’hosting presente a listino e venduto secondo i termini del nostro produttore a cui di norma è abbinato un servizio di management standard offerto dal produttore stesso a cui il cliente può attingere direttamente tramite pannello di helpdesk autonomo. Qualora richieda supporto a nostro supporto tecnico le attività di manutenzione sono di norma (possono essere) addebitate.

Non sempre è possibile fornire al cliente un accesso al pannello help del provider che di norma è in inglese ed in questi casi il supporto self-service risulterebbe quindi impossibile per il cliente finale.

Hosting naked

È da intendere il servizio naked quando viene offerto senza supporto tecnico incluso (in genere anche da parte del fornitore che non dispone di un supporto managed) e di conseguenza tutte le attività sono a pagamento e soggette alle SLA del contratto di assistenza o manutenzione.

Tracciamento servizi su f.suite e scadenze

Facciamo un esempio pratico per definire meglio procedura

la fattura fatta da @Alessandro Zanotti ha lo scopo di monetizzare al più presto l’ordine del cliente è come tale può “mancare” di tutti gli “automatismi” e tag aziendali che dovranno poi essere inserite da @Franco Farnedi al momento opportuno e con i criteri che andremo definire qui di seguito.

Ecco come si presente al cliente:

La fattura fa riferimento ad un Nostro preventivo ed a un ordine cliente:

Per prassi @Alessandro Zanotti l’ordine cliente andrebbe messo in allegato al fine di permettere gli interessati un veloce accesso in caso di necessità come questa.

Per prassi l’ordine fornire andrebbe inserito qui in questo campo per una valorizzazione corretta nel XML e non nella causale mi pareva

Domanda per @Alessandro Zanotti : ma le fatture di EY non le spedivi solo via 2C per problemi su alcuni campi oppure è un mio ricordo sbagliato?

Perchè questa (2024-0052) è stata spedita?

Nostro preventivo

nel server su Sharepoint non ho trovato nessuna folder 2023-0575 dove mi aspettavo di trovare tutti i documenti dell’offerta ed i relativi ordini.

non no trovato neppure un documento 7000055793 che è l’ordine del cliente (facendo una ricerca testuale su sharepoint)

Alla fine li ho trovato nel 2024 qui:

Quindi presumo sia questo:

ma non quadrano i tempi visto che nella fattura si parla di servizi fino al 31/5/2024

@Franco Farnedi è proprio lui.. sono loro in ritardo di 15 giorni

@Andrea Schwibbert non mi è chiaro… qui parla di 31.12.2024 noi fatturiamo fino a maggio?!?

quindi mi serve una mano per capire dove sono i documenti e come vengono archiviati…

CONTRATTI MANUTENZIONE

WP-HELP

Condizioni commerciali

I contratti di manutenzione WP-HELP si applicano secondo le specifiche ed i costi indicati qui WP-Help » F.technology, pacchetti di manutenzione made easy

Ai chi acquista pacchetti multipli si applica sconto agenzia:

Sconto per Agency*:

0% per acquisto di meno di 5 pacchetti totali

-10% Se acquisti da 5 a 14

-15% Se acquisti da 15 a 30

-20% Se acquisti più di 30 pacchetti

*lo sconto viene applicato su tutti i rinnovi o acquisti successivi al raggiungimento target

Gestione Clickup e Timesheet

Nella gestione Clickup fare riferimento alla sezione Private (https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-198272) ed in particolare il fatto che in presenza di un contratto di Manutenzione sia sempre necessario avere uno Space designato per ogni cliente e una folder o list grigia dove segnare le attività programmate (incluse nel contratto) ed eventualmente altre attività on-demand (di norma viene venduto in abbinamento a un contratto di Assistenza)

Attività programmate e task

Ogni contratto di manutenzione di norma prevede delle attività programmate periodiche, che vanno inserite nella lista, pianificate e assegnate. Dove le attività hanno carattere di periodicità pianificare ricorrenza nel calendario task. Assegnarle ad un incaricato responsabile

Creare template di lista per ogni tipo di contratto

WP-HELP Monitor (non è un contratto di manutenzione)

Il contratto di tipo Monitor non prevede, a parte l’iniziale setup e il monitoring degli avvisi di sicurezza, attività incluse nel pacchetto e come tale, in passato, non è stato censito su Clickup.

Report automatico

Valutare il comportamento da adottare in futuro e l’opportunità di censirlo considerando che in genere viene abbinato a interventi on-demand

Attività comuni a tutti i WP-HELP Security e superiori

  • creare codice progetto su F.suite
  • creare fattura associata a progetto
  • creare Lista o Folder su Clickup
  • inserire link a Clickup dentro a F.suite
  • inserire dati del Contratto nelle note di Clickup
  • impostare data di fine contratto manutenione
  • associare il contratto a una persona o gruppo

WP-HELP Security e successivi

Fare report via WP Remote

WP-HELP Unlimited (standard e Pro)

Il contratto prevede una serie di attività periodiche programmate e una serie di attività on-demand.

elencare le attività pianificate ed i servizi da abilitare e fare un template da applicare ogni volta che si attivi un contratto

Strutture Cartelle: Private (https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-198492)

DOCUMENTAZIONE

Come redigere documentazione con ClickUp

Vedi capitolo Private (https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-198472) in sezione Clickup

Doc progetti (da revisionare)

Come gestire la documentazione progetti.

Nome dei documenti su Clickup e SharePoint:

esempio sbagliato di nome del documento:

il nome deve avere sempre il codice cliente e il dominio (quando esiste) del progetto.

Video

Come conservare i video di documentazione tecnica.

Dividere fra video uso interno, video con accesso riservato anche al cliente, video pubblici.

WordPress

Ogni progetto sviluppato con WordPress deve essere correlato di un file Doc su Figma di documentazione tecnica per sviluppatori

La documentazione tecnica per End-user può essere una opzione aggiuntiva

Private (https://app.clickup.com/t/2yt0m3k)

Private (https://app.clickup.com/t/2yt0m3z)

Filemaker

da completare

Altri progetti software

da completare

Invio/Ricezione credenziali

Password Pusher

Con l’obiettivo di migliorare la sicurezza e l’efficienza delle nostre operazioni quotidiane, vi invitiamo calorosamente ad adottare questo strumento in via esclusiva.

PW Push rappresenta una svolta nel modo in cui condividiamo e riceviamo le credenziali dei clienti. Con una semplice interfaccia e una robusta crittografia end-to-end, garantisce la massima protezione dei dati sensibili.

Per utilizzare PW Push, basta accedere al nostro nuovo portale dedicato all’indirizzo:

https://pwpush.f-service.site

Qui potrete inviare e ricevere credenziali in modo rapido e sicuro, riducendo al minimo il rischio di violazioni della sicurezza.

Le funzionalità chiave di PW Push includono:

  1. Crittografia Avanzata: Tutte le credenziali vengono crittografate utilizzando algoritmi avanzati, garantendo la protezione dei dati durante il trasferimento.

  2. Facile Utilizzo: L’interfaccia intuitiva rende semplice l’invio e la ricezione delle credenziali, riducendo al minimo il tempo necessario per completare le operazioni.

  3. Tracciabilità: Ogni transazione viene registrata e tracciata, consentendo una completa visibilità sullo storico delle operazioni.

  4. Accesso Multi-Dispositivo: PW Push è accessibile da qualsiasi dispositivo connesso a Internet, permettendovi di accedere alle credenziali in qualsiasi momento e da qualsiasi luogo.

Adottando PW Push, non solo miglioriamo la nostra sicurezza informatica, ma aumentiamo anche la nostra efficienza operativa. Non esitate a contattare il nostro team IT per ulteriori informazioni o supporto nell’utilizzo di questo strumento.

istruzioni pwpush

Inserire il testo da inviare in maniera sicura e selezionare le opzioni desiderate se differenti dai default proposti poi premere invia.

verrà generato un link da condividere con il cliente e vi verranno mostrate le opzioni di condivisione selezionate

Per aumentare ulteriormente la sicurezza vi suggerisco di utilizzare la funzione “blocco della passphrase” in questo modo per aprire il link servirà un ulteriore password, la quale andrebbe comunicata a voce/in un altro canale rispetto quello di invio del link ( 2 step verification)

Le funzionalità sono molto intuitive:

box le password: inserire testo da inviare in maniera crittografata, non supporta la formattazione avanzata (grassetti etc )

scadenza link: il numero di giorni e visualizzazioni dopo cui scadrà la password inviata. consiglio di usare valori consoni all utilizzo ( vedi default )

Recupera la password con click extra: consiglio sempre di usarlo al fine di evitare che gli antivirus facciano scadere la password

Blocco della passphrase: aggiungi una password davanti alle password ( 2 factor autentication in pratica)

genera password: tool di generazione password casuali

SEGRETERIA

Da completare

Preventivi

Procedura Generale valida per tutti i preventivi

La gestione di un preventivo richiede alcune fasi specifiche e comuni ad ogni casistica, e tali attività sono a carico della segreteria operativa.

  • Verificare se il cliente esiste già in F.suite e nel caso non esista raccogliere dati con form nuovo cliente Registrazione nuovo cliente » F.technology e inserire in anagrafica creando da subito un codice cliente
  • Creare nella sezione preventivi un nuovo preventivo e acquisire il numero di offerta
  • Creare la cartella su Teams nello spazio Preventivi con nome cliente e codice cliente e dentro inserire la cartella con numero offerta e titolo preventivo. Dentro a questa cartella conservare la documentazione rilevante del progetto (video, email importanti, allegati, file di preventivo)
  • Creare un task nella lista Preventivi di Clickup 2412131 (https://app.clickup.com/2402546/v/s/2412131)

Procedura per Progetti

Se il preventivo è relativo ad un progetto (a corpo o Agile) bisognerà passare il task a @Greta Farnedi che si occuperà di raccogliere i dati di progetto tramite apposito questionario tematico e produrrà una Stima da passare a @Franco Farnedi che finalizzerà il preventivo

Procedura per Assistenza e Manutenzione

In questo caso l’offerta viene prodotta direttamente da @Franco Farnedi o sotto sua direzione dalla segreteria.

Procedura per Hosting e Prodotti

In questa casistica il preventivo viene seguito dal reparto tecnico @Andrea Schwibbert o da @Franco Farnedi o dalla segreteria sulla base dei listini pubblici.


old

L’approvazione sui preventivi spetta al commerciale o al suo diretto sottoposto in caso di sua assenza.

Il PM stima con i tecnici e analisti, mette una contingency in base alla sua esperienza con quel cliente + una piccola % di project management affogato negli interventi (mediamente un 10%).

Le variabili da valutare sono due:

  • Storicità con il cliente (il rapporto è già definito?)
  • Grandezza del progetto in termini economici (definiamo arbitrariamente che fino ai 3 o 4 k sono piccoli)

Su progetti con clienti il cui rapporto è già definito e di importo piccolo il PM può essere più autonomo anche nell’invio del preventivo e può proporre al commerciale una stima in €.

Su progetti più grandi e clienti nuovi è meglio stimare a effort e poi confrontarsi con il commerciale per inserire il valore in €, il preventivo in questi casi lo invierà direttamente il commerciale.

L’approvazione da parte del commerciale è sempre obbligatoria su interventi che superano il valore di circa 1000€.

ATTIVITA’ DEL COMMERCIALE

  • Quando si realizza un nuovo preventivo come prima cosa si deve creare il cliente in F.suite, anagrafica (se non esiste già)
  • Poi si deve inserire ogni contatto utile del cliente nell’area CRM di F.suite (nomi, email e telefoni)
  • Si deve richiedere al cliente di compilare la scheda nuovo cliente Registrazione nuovo cliente - F.technology o si deve completare con lui i dati mancanti (se già presente)
  • opportuno produrre quanto prima una NDA e firmarla

ATTIVITA’ CHE SU PROGETTI PICCOLI PUO’ FARE IL PM

  • creare in f.suite un nuovo preventivo definendo numero e descrizione breve
  • creare una folder su Teams/Canale Preventivi con la struttura /NOME BREVE CLIENTE COD:CLIENTE /preventivo numero descrizione breve preventivo
  • raccogliere ogni elemento utile al preventivo come doc, video, link
  • creare una card in Clickup nello SPACE Preventivi 2412131 (https://app.clickup.com/2402546/v/s/2412131)
  • creare un DOC in Clickup con il nome strutturato in questo modo: COD.CLIENTE | [NOME BREVE CLIENTE] Preventivo Descrizione breve - si noti che il nome breve cliente è opzionale.
  • Mettere il tag “Preventivo”

Task e comunicazioni alla direzione

La segreteria esegue numerose attività di comunicazione e mansione per conto della direzione ed è molto importante tracciare tali attività su Clickup per fornire al richiedente un feedback di quanto svolto.

A questo scopo si ricordi che per le attività richieste dalla direzione è sempre opportuno fornire un riscontro di quanto eseguito secondo uno di questi due metodi (non si escludono l’un l’altro e talvolta possono essere applicati entrambi)

Se l’azione prevede l’invio di una email

  • Mettere fra i destinatari dell’email anche l’indirizzo del richiedente del task (in genere Franco) al fine di poter permettere di valutare sia l’esecuzione dell’attività che la forma, il contenuto e l’eventuale esito.

  • Mettere fra i destinatari l’email del task ClickUp al fine di poter tenere copia nel task

  • Utilizzare lo strumento integrato di ClickUp per inviare le email da dentro il task.

Planning periodico

Alessandro.. scrivi tu il piano periodico e poi nel caso lo commento e integro

Calendario Attività periodiche da eseguire

Giornaliero

entro le 10:30 - verifica su Sibill posizioni e aggiornamento, segnalazioni o interventi correttivi.

  • Rilevamento operazioni del giorno precedente (in particolare Credem, che presenta l’aggiornamento in tempo reale del saldo, ma non dei movimenti) con riconciliazione e attribuzione della tag dove assente;

  • Esecuzione dei pagamenti schedulati con la scadenza prevista, se sotto il nostro controllo (si considerano fuori dal nostro controllo a titolo di esempio: gli F24, gli SDD per utenze, mutui ecc. malgestiti dal creditore, i pagamenti a mezzo CBill il cui momento di gestione da parte della banca non è certo. In tali casi sarà necessario adeguare la scadenza);

  • Verifica dei pagamenti da clienti scaduti: effettuare un sollecito telefonico, ed impostare una nuova scadenza su Sibill ed FS sulla base delle indicazioni fornite dal debitore. In caso di scadenza già rinviata e non rispettata o di ripetute mancanze di rispetto degli impegni presi, segnalare alla Direzione che provvederà ad effettuare gli opportuni interventi commerciali col cliente.

KPI e segnali da tenere in osservazione

in questa sezione inserirà man mano i segnali che dovete verificare e correggere o comunicare alla direzione quando li verificate. E’ importante che il lavoro di chi si occupa di amministrazioni non sia un solo inserimento meccanico di dati ma ci sia la capacità di riconoscere i dati errati e intervenire prima che ve lo segnali io.

Sibill

  • Cashflow rosso nei prossimi 30gg

  • Scadenze non rispettate (clienti o fornitori)

  • Solleciti preventivi su scadenza prossima (2gg prima)

  • Registrazioni non allineate rispetto allo stato di CC

F.suite

  • Fatture definitive non spedite

  • Scadenze fatture cliente non saldate

Portafoglio Effetti

https://fsites.sharepoint.com/:x:/s/CONTABILITA/Ef9eiLcgmClBg3LBpBM9CaQBOS_yANvey2INpzLO9fAMWg?e=tQyEyH

  • Data ultimo update maggiore di 3gg

  • Fatture non incassate alla scadenza (presenza di totali nei mesi precedenti)

  • Fatture anticipate non Esinta

Fatturazione

La fatturazione definitiva con l’invio allo SDI è compito dell’ufficio Amministrativo, e nella fattispecie di Alessandro e Franco.

In particolare la stragrande maggioranza delle fatture definitive viene finalizzata da Franco, con una frequenza settimanale, mentre è compito di Alessandro l’invio allo SDI (delle fatture in attesa di invio).

In questa occasione Franco verifica anche complessivamente il cliente, lo stato dei pagamenti, decidi gli anticipi fatture, il rinnovo servizi e molto altro.

Solo in caso di emergenza Alessandro le finisce e spedisce direttamente lui, in caso di necessità espressa da un responsabile o di un cliente.

Ricapitolando

AttivitàDirettoreAmmSegretPMTecnici
Fatture temp-Xx
Fatture definitiveXo
Invio SDIxX
Sollecito pagamentiXoo
Attività fatturarexXxxX

Casi eccezionali ed eccezioni

Quando si realizzazione delle condizioni eccezionali e non è possibile interpellare la persona responsabile direttamente nell’immediato, è consentita la gestione di queste eccezioni:

Emissione di fattura definitiva in caso di ricezione pagamento

Se il cliente paga su preventivo o su proforma, @Alessandro Zanotti deve spedire la fattura definitiva con data pari al pagamento senza attendere che lo faccia @Franco Farnedi

Fatturazione Ticket assistenza

Quando un ticket di assistenza viene chiuso in Clickup passa all’amministrazione ed in particolare a @Franco Farnedi che ne controlla lo stato di fatturabilità e produce il flusso di fattura più conforme al caso.

In realtà quello che succede nel dettaglio è quanto segue:

  • verifica se il cliente non ha effettivamente un contratto
  • definisce se sia o meno opportuno il prezzo proposto dal tecnico e lo “emenda”
  • prova ad attivare azioni di upselling di servizi
  • sposta il ticket nello space più opportuno per fini statistici
  • emetto fattura e la predispongo per inviare a cliente
  • cambio stato in fatturato e inserisco numero fattura nel campo

Fatture TEMP-

Le fatture TEMP- sono documenti che si creano con lo scopo di inviare al cliente una nota spese non fiscale, prima di emettere il documento finale, allo scopo di verificare l’accettazione della spesa prevista.

Chi le può creare

Le può creare il PM, l’account e l’amministrazione.

Contenuti necessari

Per i report mensili, ricordarsi sempre di inserire una riga descrittiva in fattura, con il riferimento del mese o periodo di competenza delle ore indicate nel documento. Quindi una riga vuota e a zero con una descrizione sufficiente a far accettare al cliente quanto rendicontato.

come gestire i report mensili - vedi video

https://t2402546.p.clickup-attachments.com/t2402546/ec47be7a-83b2-4828-98bf-8f201db47312/screen-recording-2023-03-11-08%3A08.webm?open=true

Chi le invia al cliente

Le deve inviare chi inserisce le TEMP, salvo casi particolari, con lo scopo di avvisare cliente della imminente emissione del documento fiscale (in genere entro 7gg dall’invio), o come documentazione di una prossima SAL (sempre entro 7gg) e quindi lo invita a segnalare eventuali errori.

Chi le compila e invia deve lasciare una nota (vedi sotto) e deve anche indicare una causale prima di spedirla

Data del documento

La data del documento deve essere sempre inserita nelle TEMP e coerente con la data di fatturazione di fine mese - se si emette una TEMP- per errore in anticipo o con lo scopo di emetterla nel mese di competenza successivo, si indichi la data del mese successivo e una nota che chiarisce che quella TEMP- non va fatturata definitiva prima del mese indicato.

Chi le può trasformare in definitiva

La trasformazione in SAL o in FAT- è responsabilità esclusiva della direzione e/o dell’amministrazione: eventuali urgenze vanno richieste a uno di questi soggetti.

Uso delle note

Le fatture TEMP- devono contenere sempre Note che spieghino alla Direzione il loro scopo ed iter.

TEMP- create e non inviate

talvolta si creano delle TEMP come promemoria di una attività futura da fattura, ma non si spediscono al cliente: evitare !!! Esiste la voce “attività da fatturare” a questo scopo

Esempio di note interne che possono essere inserite:

  • Non inviare la TEMP perchè…
  • Ho parlato con Tizio, in attesa di suo riscontro, la invio entro il,…

Cosa fare quando il cliente contesta una TEMP-

Il cliente non deve essere nelle condizioni di contestare una rendicontazione. Se il cliente è gestito, contento e seguito solitamente non contesta.

Se il cliente contesta una TEMP-, chi riceve la contestazione:

  • se è una contestazione piccola la corregge e poi segnala sulla nota che è stata corretta e approvata da cliente (nota per amministrazione) mentre se l’errore/rettifica viene presa da Amministrazione (Alessandro) la trasforma subito in definitiva e invia.

  • se è una contestazione onerosa parlarne immediatamente con la Direzione.

CASO DI ADEGUAMENTO DI PREZZO DI UN SERVIZIO…

Documenti SAL

Note in fattura

Talvolta il cliente o il contratto, richiede particolari diciture in fattura.

L’abitudine di mettere la nota di fatturazione in scheda cliente, e trovarla fissa su tutte le fatture emesse in bozza, la trovo poco pratica e portatrice di errori.

Dobbiamo trovare una procedura più corretta, che leghi tale notazione all’ordine o al progetto e non al cliente, a meno che sia una nota automatica per tutte le fatture dell’anno ma non quasi mai così

Rilevamento fatture fornitori esterni freelance

  1. si usa come intestatario “Clienti Externi cod. 1023

  2. si carica nei documenti il pdf della fattura

  3. si indica numero fattura in descrizione

Registrazione fatture passive

nuova procedura in corso

Servizi hosting da non rinnovare

Troviamo una procedura che ci riduca gli errori…

Quando di un servizio viene richiesta la sua cancellazione, bisogna procedere secondo questa procedura:

Se il servizio ha un rinnovo automatico, disattivare il rinnnovo con il provider

Posizionare in Filemaker lo stato: da disabilitare o mettere adirittura “cancellato lo stato”

Se il servizio va disattivato, bisogna fare un task di disattivazione su clickup e mettere link nelle note di Filemaker del servizio.

Cashflow (Sibill)

REDAZIONE CASHFLOW

il documento che segue è stato redatto da @Alessandro Zanotti con lo scopo di documentare quanto fatto e con quali criteri.. non ha funzione di Playbook e verrà emendato… ho portato comunque in questo capitolo, con lo scopo di centralizzare la documentazione e di redigere al termine un nuovo capito di Playbook.

I commenti con omino viola sono io (Franco)

TME srl

ENTRATE

INCASSI DA CLIENTI: Ho previsto una media mensile di

incassi da F.TECH di € 25.000,00 + una quota variabile crescente di clienti

effettivi per € 5/10/20k nei mesi prossimi ipotizzando un progressivo passaggio

di contratti alla nuova società.

sinceramente non sono sicuro che abbia molta utilità avere un previsionale di entrate “sperato” o fittizio.. abbiamo la capacità di prevedere le uscite sulla base dello storico e del fatto che sono certe, ma le entrate “sperate” non so quanto ci possa aiutare a fare previsione a fronte del fatto che nascondano il problema della mancanza di disponibilità quando è troppo tardi per coprirla.

Credo che le antrate dovrebbero essere basate su fatture emesse e relative scadenze o al massimo su contratti firmati con fatture da emettere (eventualmente quindi dividere in sotto tag di questo tipo).

Ho anche qualche perplessità su di una voce F.technology esplicita.. visto che ci saranno le fatture emesse reali.. non so se sia utile distinguerle o meno…

USCITE

BANCHE: Al momento non avendo affidamenti ho previsto un aumento delle commissioni progressivo a 7k/10k/20k conseguente ad una maggiore quantità di movimenti in uscita. Le altre voci le ho previste costanti.

Non capisco il commento delle banche: 7K? ma se sono 20/30 € come fai a scrivere 7.000/10.000/20.000 € ?

Anche per i fornitori.. non inventarti delle spese fittizie.. metti quelle che sai che sono previste.. cosa sono i 500€ che hai inserito?

Idem generali…

Ribadisco.. mettiamo le spese che sono prevedibili e non un budget di spesa “presunto” ..

abbiamo uno storico di spesa nel 2023 e sappiamo quanto e cosa spendiamo di solito.. sulle spese “non prevedibili” basiamoci su fatture e non stime..

FORNITORI: Ho inserito F.TECHNOLOGY per le fatture saldate ad inizio mese. Per il resto, a parte i fornitori particolari legati alla contabilità e alle paghe non ho inserito nulla.

Quale scopo ha avere il totale delle spese di F.technology nel cashflow? - non credo che sia lo scopo dei tag = fornitore. Boh ci devo pensare.. ma forse tu hai uno scopo e me lo puoi spiegare…

FREELANCE: Pagamento seconda quota fattura Evelyn.

i freelance ha senso.. ma farei distinzione fra Freelance come Evelyn e Marco che sono fissi e quindi tutti i mesi da Freelance come Costo della produzione come potrebbe essere Benedetto che è variabile

GENERALI: Previsti nella voce “contabilità” € 1.500,00 costanti per fatture di Nicola.

ma Nicola ci costa 1.500 al mese su TME? e Quanto su F.technology? non mi quadra

MUTUI: Previsti in modo costante € 640,00 per i due mutui in essere con Credem.

STIPENDI: Buste paga di febbraio calcolate in € 8.436,00 sulla base dei cedolini ricevuti. Per marzo ho previsto una cifra di poco superiore, in quanto il personale a fine mese dovrebbe mantenersi circa simile. Poi incremento ad € 15k ad aprile e a 25k a maggio. Per la gestione paghe, detto che non abbiamo ancora ricevuto nessuna fattura da parte di Venturi, ho provato ad ipotizzare il costo mensile sulla base del listino e delle attività necessarie (€ 200,00 per febbraio e marzo, poi a crescere € 400 e 600. Fra le altre spese ho previsto la quota per la gestione della procedura per l’inserimento di Vedad e Doha + spese per visite mediche e corsi di formazione sulla sicurezza.

lo aggiusteremo meglio man mano che si spostano dipendenti

TASSE E TRIBUTI

CONTRIBUTI: I 7.705 di febbraio corrispondono all’F24 calcolato dallo studio. Per marzo ho previsto una cifra di poco superiore, poi un incremento a 12 e 20, proporzionato a quello delle buste.

lo aggiusteremo meglio man mano che si spostano dipendenti

IVA CORRENTE: Per questo mese non pagheremo nulla in quanto siamo a credito, ma poi ho previsto uscite per € 1.500, 3k e 10k in corrispondenza in un passaggio della clientela a TME.

RITENUTE D’ACCONTO: Previsti i 590 effettivi in pagamento il 16/02 + importi stimati fatture Nicola e Venturi. Ipotizzato un incremento costante con il passaggio progressivo del personale in TME.

CONCLUSIONI

Da questo prospetto si evince che se le previsioni verranno rispettate a maggio si avrà una disponibilità presunta di € 6k: ovviamente la bontà di questa previsione è fortemente condizionata dalla velocità con cui clienti, fornitori e personale verranno passati in TME.

temo che ci sia stato un fraintendimento sullo scopo dello strumento… fare previsioni sul “vorrei e potrei” non ci serve in questa fase.. scopo del tool cashflow in Sibill è fotografare la situazione certa e prevedibile con sicurezza (alta) e non prevista sulla base di “strategie” di business future o altro… per questo c’è Excel.

Aggiusterei le voci sulla base degli obiettivi di controllo di gestione…

F.TECHNOLOGY

ENTRATE

ANTICIPI SU FATTURE: Ho previsto un ammontare di anticipi di € 60.000 per febbraio (25 già presentati + 35 ipotizzando di andare vicini al riempimento dei castelletti RB e Credem), 40k per marzo (teoricamente in quel mese si dovrebbe liberare poco spazio), 70k per aprile (sono in scadenza svariate fatture di ESG che verranno rimpiazzate) e di nuovo 30k a maggio (stesso motivo di marzo, con in più il fatto che parte del presentato potrebbe essere stato portato in TME).

GIROCONTI: Non ho previsto cifre, in quanto il loro importo in D/A si dovrebbe elidere e non ha incidenza sul disponibile.

INCASSI DA CLIENTI: Previsti € 110k per febbraio (44 già avvenuti + 70 residui scadenziati in febbraio), 110 in marzo (come da scadenza naturale fatture emesse), 120 in aprile (100 previsti + nuove scadenze che potrebbero aggiungersi) e 50k in maggio (al momento non abbiamo fatture in scadenza per quel periodo). I valori sono stati tutti diminuiti di un 10% ipotizzando clienti ritardatari.

BANCHE

BOLLI: Per ogni mese sono previsti i bolli mensili della Credem di € 8,33, ai quali ad aprile aggiungiamo quelli trimestrali di Unicredit e RB (€ 25k per ogni conto, compreso quello di portafoglio)

COMMISSIONI: Previsti mediamente € 40/mese. Eventuali incrementi sostanziali possono essere causati da incassi tramite Stripe (vedi IBZ mese scorso). Le commissioni di RB non sono contemplate in quanto a parte qualche eccezione, i movimenti in addebito sono già contabilizzati al lordo.

COMPETENZE: Ipotizzato un incremento in febbraio rispetto a dicembre (da 818 a 900 causa questione Unicredit) e 350 su Credem.

FORNITORI

CARTA DI CREDITO: € 7.100,00 importo effettivo in addebito a febbraio. Per i mesi successivi ho previsto € 8.000,00 di media in considerazione di un eventuale passaggio di fatturazione a TME.

HOSTING: € 11.000,00 ca. effettivi nel mese di febbraio, poi € 10.000,00/mese + ulteriori 19k per Kinsta a marzo. In questa voce vengono convogliate le spese che vengono addebitate direttamente sul c/c (Computer Gross, Google, Kinsta rinnovo). Le altre spese di hosting da fornitori esteri sono comprese nella voce “Carta di Credito”.

MERCE: Ipottizati mediamente € 1.000,00/mese. In questa voce vengono convogliati gli acquisti di merce per la rivendita da fornitori diversi da Brevi, che viene compresa nella voce “hosting” (vedi mia mail di venerdì).

TME: Riportati i 25k/ mese di cui parlavo all’inizio.

FREELANCE: Nel mese di febbraio previsti € 13.800,00 per Mark pagato/da pagare + Extera; successivamente € 1.250/mese per Mark.

GENERALI

AFFITTO: Previsti € 9.500,00 per il pagamento a fine aprile della prossima fattura.

AMAZON: Previsti acquisti medi di € 300/mese.

ASSICURAZIONI: Non previsto nulla, in quanto la polizza dell’auto scade a giugno.

CONNETTIVITA’: Previsti in modo alternato € 100 e 700 (fatture WindTre e Zinca)

CONTABILITA’: Ipotizzate € 1200/mese per fatture di Nicola + ulteriori € 7.200 febbraio per nota proforma attività effettuate in novembre.

PULIZIE: € 380,00 per passaggi standard mensili Kito Servizi

UTENZE: € 900,00 per bollette Hera luce+acqua + a febbraio e maggio € 400 ulteriori per quota tariffa puntuale.

VIAGGI: Previsti € 150,00 medi comprensivi di Edenred e Autostrade. Altri fornitori (Bizaway, Trenitalia ecc. compresi negli acquisti carte di credito).

VIGILANZA: € 350,00 a febbraio e maggio (prossime quote trimestrali).

GIROCONTI: Non compilato (vedi voce analoga nelle entrate)

INCASSI DA CLIENTI: In questa voce raccolgo i bonifici effettuati a favore di clienti per rimborsi. Segnati 85€ per rimborso a Studio Bagli in febbraio.

LEASING: Le due fatture mensili di Banca Ifis per le pratiche aperte, tot. € 1.025/mese

MUTUI: € 2.300,00 dei 3 mutui ancora aperti (Credem + October) + ulteriori € 2.700,00 per Lumen (ex Credimi) al 31/03.

SOCI: Bonifici a Franco per compensi

STIPENDI: Bonifici di febbraio calcolati sull’effettivo (Elena acconto € 1500,00; considerata ultima rata Marco Brandi € 1.400,00). Per i mesi successivi considerati € 21.000 base + € 1.000,00 a salire per acconti TFR € 1.000,00)

SPESE PERSONALE: In questa voce si intendono corsi di

sicurezza, visite e simili a nostro carico. Non previsto nulla dal momento che

di desume non ne sosterremo per F.TECH.

STORNO ANTICIPI: Ho ipotizzato un 65% degli incassi previsti + € 10.000,00/mese per rientro Unicredit.

CONTRIBUTI: Ipotizzata la quota contributiva di € 9.000,00 per febbraio e marzo, per poi andare a scendere leggermente nei mesi successivi.

RITENUTE D’ACCONTO: Previsti i 222 come da calendario per il 16/02; per i mesi successivi previste ritenute su fatture di Nicola+Mark (€ 470,00) + solo per marzo ritenuta extra di Nicola per nota attività settembre.

CONCLUSIONI

Sulla base di queste ipotesi vi sarebbe un disavanzo a fine maggio di € 90k con sofferenza fin dal mese di marzo.

Gestione Sibill

Cash Flow

il Cashflow di Sibill va aggiornato quotidinamente, o al massimo ogni 2 giorni.

Ricordarsi di effettuare le associazioni di categoria delle scadenze ogni volta

Categorie

EntrateCategoria/sotto categoriaCasi
Giroconto Attivoper fatture da TME➝F.technology
Incassi da clientetutte le altre fatture emesse

Scadenze attive e passive in Sibill+FSuite

Analisi e relazione di Alessandro

REDAZIONE CASHFLOW

il documento che segue è stato redatto da @Alessandro Zanotti con lo scopo di documentare quanto fatto e con quali criteri.. non ha funzione di Playbook e verrà emendato… ho portato comunque in questo capitolo, con lo scopo di centralizzare la documentazione e di redigere al termine un nuovo capito di Playbook.

I commenti con omino viola sono io (Franco)

TME srl

ENTRATE

INCASSI DA CLIENTI: Ho previsto una media mensile di

incassi da F.TECH di € 25.000,00 + una quota variabile crescente di clienti

effettivi per € 5/10/20k nei mesi prossimi ipotizzando un progressivo passaggio

di contratti alla nuova società.

sinceramente non sono sicuro che abbia molta utilità avere un previsionale di entrate “sperato” o fittizio.. abbiamo la capacità di prevedere le uscite sulla base dello storico e del fatto che sono certe, ma le entrate “sperate” non so quanto ci possa aiutare a fare previsione a fronte del fatto che nascondano il problema della mancanza di disponibilità quando è troppo tardi per coprirla.

Credo che le antrate dovrebbero essere basate su fatture emesse e relative scadenze o al massimo su contratti firmati con fatture da emettere (eventualmente quindi dividere in sotto tag di questo tipo).

Ho anche qualche perplessità su di una voce F.technology esplicita.. visto che ci saranno le fatture emesse reali.. non so se sia utile distinguerle o meno…

USCITE

BANCHE: Al momento non avendo affidamenti ho previsto un aumento delle commissioni progressivo a 7k/10k/20k conseguente ad una maggiore quantità di movimenti in uscita. Le altre voci le ho previste costanti.

Non capisco il commento delle banche: 7K? ma se sono 20/30 € come fai a scrivere 7.000/10.000/20.000 € ?

Anche per i fornitori.. non inventarti delle spese fittizie.. metti quelle che sai che sono previste.. cosa sono i 500€ che hai inserito?

Idem generali…

Ribadisco.. mettiamo le spese che sono prevedibili e non un budget di spesa “presunto” ..

abbiamo uno storico di spesa nel 2023 e sappiamo quanto e cosa spendiamo di solito.. sulle spese “non prevedibili” basiamoci su fatture e non stime..

FORNITORI: Ho inserito F.TECHNOLOGY per le fatture saldate ad inizio mese. Per il resto, a parte i fornitori particolari legati alla contabilità e alle paghe non ho inserito nulla.

Quale scopo ha avere il totale delle spese di F.technology nel cashflow? - non credo che sia lo scopo dei tag = fornitore. Boh ci devo pensare.. ma forse tu hai uno scopo e me lo puoi spiegare…

FREELANCE: Pagamento seconda quota fattura Evelyn.

i freelance ha senso.. ma farei distinzione fra Freelance come Evelyn e Marco che sono fissi e quindi tutti i mesi da Freelance come Costo della produzione come potrebbe essere Benedetto che è variabile

GENERALI: Previsti nella voce “contabilità” € 1.500,00 costanti per fatture di Nicola.

ma Nicola ci costa 1.500 al mese su TME? e Quanto su F.technology? non mi quadra

MUTUI: Previsti in modo costante € 640,00 per i due mutui in essere con Credem.

STIPENDI: Buste paga di febbraio calcolate in € 8.436,00 sulla base dei cedolini ricevuti. Per marzo ho previsto una cifra di poco superiore, in quanto il personale a fine mese dovrebbe mantenersi circa simile. Poi incremento ad € 15k ad aprile e a 25k a maggio. Per la gestione paghe, detto che non abbiamo ancora ricevuto nessuna fattura da parte di Venturi, ho provato ad ipotizzare il costo mensile sulla base del listino e delle attività necessarie (€ 200,00 per febbraio e marzo, poi a crescere € 400 e 600. Fra le altre spese ho previsto la quota per la gestione della procedura per l’inserimento di Vedad e Doha + spese per visite mediche e corsi di formazione sulla sicurezza.

lo aggiusteremo meglio man mano che si spostano dipendenti

TASSE E TRIBUTI

CONTRIBUTI: I 7.705 di febbraio corrispondono all’F24 calcolato dallo studio. Per marzo ho previsto una cifra di poco superiore, poi un incremento a 12 e 20, proporzionato a quello delle buste.

lo aggiusteremo meglio man mano che si spostano dipendenti

IVA CORRENTE: Per questo mese non pagheremo nulla in quanto siamo a credito, ma poi ho previsto uscite per € 1.500, 3k e 10k in corrispondenza in un passaggio della clientela a TME.

RITENUTE D’ACCONTO: Previsti i 590 effettivi in pagamento il 16/02 + importi stimati fatture Nicola e Venturi. Ipotizzato un incremento costante con il passaggio progressivo del personale in TME.

CONCLUSIONI

Da questo prospetto si evince che se le previsioni verranno rispettate a maggio si avrà una disponibilità presunta di € 6k: ovviamente la bontà di questa previsione è fortemente condizionata dalla velocità con cui clienti, fornitori e personale verranno passati in TME.

temo che ci sia stato un fraintendimento sullo scopo dello strumento… fare previsioni sul “vorrei e potrei” non ci serve in questa fase.. scopo del tool cashflow in Sibill è fotografare la situazione certa e prevedibile con sicurezza (alta) e non prevista sulla base di “strategie” di business future o altro… per questo c’è Excel.

Aggiusterei le voci sulla base degli obiettivi di controllo di gestione…

F.TECHNOLOGY

ENTRATE

ANTICIPI SU FATTURE: Ho previsto un ammontare di anticipi di € 60.000 per febbraio (25 già presentati + 35 ipotizzando di andare vicini al riempimento dei castelletti RB e Credem), 40k per marzo (teoricamente in quel mese si dovrebbe liberare poco spazio), 70k per aprile (sono in scadenza svariate fatture di ESG che verranno rimpiazzate) e di nuovo 30k a maggio (stesso motivo di marzo, con in più il fatto che parte del presentato potrebbe essere stato portato in TME).

GIROCONTI: Non ho previsto cifre, in quanto il loro importo in D/A si dovrebbe elidere e non ha incidenza sul disponibile.

INCASSI DA CLIENTI: Previsti € 110k per febbraio (44 già avvenuti + 70 residui scadenziati in febbraio), 110 in marzo (come da scadenza naturale fatture emesse), 120 in aprile (100 previsti + nuove scadenze che potrebbero aggiungersi) e 50k in maggio (al momento non abbiamo fatture in scadenza per quel periodo). I valori sono stati tutti diminuiti di un 10% ipotizzando clienti ritardatari.

BANCHE

BOLLI: Per ogni mese sono previsti i bolli mensili della Credem di € 8,33, ai quali ad aprile aggiungiamo quelli trimestrali di Unicredit e RB (€ 25k per ogni conto, compreso quello di portafoglio)

COMMISSIONI: Previsti mediamente € 40/mese. Eventuali incrementi sostanziali possono essere causati da incassi tramite Stripe (vedi IBZ mese scorso). Le commissioni di RB non sono contemplate in quanto a parte qualche eccezione, i movimenti in addebito sono già contabilizzati al lordo.

COMPETENZE: Ipotizzato un incremento in febbraio rispetto a dicembre (da 818 a 900 causa questione Unicredit) e 350 su Credem.

FORNITORI

CARTA DI CREDITO: € 7.100,00 importo effettivo in addebito a febbraio. Per i mesi successivi ho previsto € 8.000,00 di media in considerazione di un eventuale passaggio di fatturazione a TME.

HOSTING: € 11.000,00 ca. effettivi nel mese di febbraio, poi € 10.000,00/mese + ulteriori 19k per Kinsta a marzo. In questa voce vengono convogliate le spese che vengono addebitate direttamente sul c/c (Computer Gross, Google, Kinsta rinnovo). Le altre spese di hosting da fornitori esteri sono comprese nella voce “Carta di Credito”.

MERCE: Ipottizati mediamente € 1.000,00/mese. In questa voce vengono convogliati gli acquisti di merce per la rivendita da fornitori diversi da Brevi, che viene compresa nella voce “hosting” (vedi mia mail di venerdì).

TME: Riportati i 25k/ mese di cui parlavo all’inizio.

FREELANCE: Nel mese di febbraio previsti € 13.800,00 per Mark pagato/da pagare + Extera; successivamente € 1.250/mese per Mark.

GENERALI

AFFITTO: Previsti € 9.500,00 per il pagamento a fine aprile della prossima fattura.

AMAZON: Previsti acquisti medi di € 300/mese.

ASSICURAZIONI: Non previsto nulla, in quanto la polizza dell’auto scade a giugno.

CONNETTIVITA’: Previsti in modo alternato € 100 e 700 (fatture WindTre e Zinca)

CONTABILITA’: Ipotizzate € 1200/mese per fatture di Nicola + ulteriori € 7.200 febbraio per nota proforma attività effettuate in novembre.

PULIZIE: € 380,00 per passaggi standard mensili Kito Servizi

UTENZE: € 900,00 per bollette Hera luce+acqua + a febbraio e maggio € 400 ulteriori per quota tariffa puntuale.

VIAGGI: Previsti € 150,00 medi comprensivi di Edenred e Autostrade. Altri fornitori (Bizaway, Trenitalia ecc. compresi negli acquisti carte di credito).

VIGILANZA: € 350,00 a febbraio e maggio (prossime quote trimestrali).

GIROCONTI: Non compilato (vedi voce analoga nelle entrate)

INCASSI DA CLIENTI: In questa voce raccolgo i bonifici effettuati a favore di clienti per rimborsi. Segnati 85€ per rimborso a Studio Bagli in febbraio.

LEASING: Le due fatture mensili di Banca Ifis per le pratiche aperte, tot. € 1.025/mese

MUTUI: € 2.300,00 dei 3 mutui ancora aperti (Credem + October) + ulteriori € 2.700,00 per Lumen (ex Credimi) al 31/03.

SOCI: Bonifici a Franco per compensi

STIPENDI: Bonifici di febbraio calcolati sull’effettivo (Elena acconto € 1500,00; considerata ultima rata Marco Brandi € 1.400,00). Per i mesi successivi considerati € 21.000 base + € 1.000,00 a salire per acconti TFR € 1.000,00)

SPESE PERSONALE: In questa voce si intendono corsi di

sicurezza, visite e simili a nostro carico. Non previsto nulla dal momento che

di desume non ne sosterremo per F.TECH.

STORNO ANTICIPI: Ho ipotizzato un 65% degli incassi previsti + € 10.000,00/mese per rientro Unicredit.

CONTRIBUTI: Ipotizzata la quota contributiva di € 9.000,00 per febbraio e marzo, per poi andare a scendere leggermente nei mesi successivi.

RITENUTE D’ACCONTO: Previsti i 222 come da calendario per il 16/02; per i mesi successivi previste ritenute su fatture di Nicola+Mark (€ 470,00) + solo per marzo ritenuta extra di Nicola per nota attività settembre.

CONCLUSIONI

Sulla base di queste ipotesi vi sarebbe un disavanzo a fine maggio di € 90k con sofferenza fin dal mese di marzo.

Scadenze attive

Definire come vanno gestite le scadenze fatture verso clienti, come inviare solleciti e quando… come gestire lo scadenzario e come regolare i rapporti con clienti in funzione dei diversi pagamenti.

Principi di base

  • Le scadenze vanno concordate con clienti e vanno fatte rispettate
  • Quando c’è una scadenza prossima si manda via Sibill email di avviso
  • Quando cliente non paga in tempo, si registra la cosa su F.tech nelle note Solleciti Pagamenti, e si sollecita cliente via email e poi si chiama al telefono e si sposta scadenza su Sibill
    • se cliente non rispetta la seconda scadenza si segnala a direzione con un task clickup e poi vediamo come gestire le future scadenze

Scadenze passive

Folder cartella Contabilità

Private (https://app.clickup.com/t/869430udm)

_______ AZIENDA

HR

Tracking del time

Guida al Tracking su ClickUp

Guida al tracking

  • Durante la giornata lavorativa riportare le ore impiegate sui task giornalieri.
  • Tracciare il tempo effettivo dedicato alla singola card, arrotondando alla mezz’ora nel caso si sia dedicato meno tempo.
  • Effettuare un controllo del tempo a fine giornata, al termine del lavoro o almeno ogni due giorni per assicurarsi di tenere traccia accurata delle ore lavorate.
  • Utilizzare la vista Timesheets nella barra laterale per verificare l’inserimento delle proprie ore giornaliero e settimanale:

  • Quando un collega vi chiede una mano su un suo task, tracciate le ore di supporto nel suo task anche se non vi è stato assegnato.

  • Quando si partecipa alle riunioni, creare card dedicate o chiederle al PM di riferimento o al COO in caso di call interne.

Un’accurato tracciamento delle ore ci permette di fatturare correttamente il lavoro ai clienti. Quindi è importante farci attenzione.

Ferie e Permessi

Procedura per Richiedere Permessi e Ferie

Procedura per Ferie e Permessi

  • Tutte le richieste di permessi e ferie devono essere inviate al COO in primis, poi comunicate alla Direzione, segnandole su:
    • Calendario personale su outlook
    • Excel su teams Ferie
    • Timesheet Filemaker?
  • Prima di richiedere permessi o ferie, è importante assicurarsi di avere una sostituzione adeguata per garantire la continuità del lavoro e la copertura delle responsabilità.
  • Prima di andare in ferie devono essere impostati i messaggi di assenza o gli inoltri su:
    • 3CX
    • Outlook
    • Teams

Esempio di messaggio da impostare:

Buongiorno,
Sarò fuori ufficio fino al X/X compreso. Riprenderò la regolare attività il X/X. In caso di urgenza potete inoltrare la vostra richiesta a XXX. Altrimenti sarà mia premura ricontattarvi al mio ritorno.
Cordialmente,
______

Non è necessario impostarli per dei permessi di qualche ora, ma per le giornate intere.

Governance Aziendale

Soci

L’impresa Technology Made Easy srl è di proprietà di un socio unico, che ne possiede il 100% e controllo completo.

NomeQuota
Franco Farnedi100%

Organi direttivi

La direzione dell’azienda è ad amministratore unico, nella persona di Franco Farnedi.

Management

Il management è composto dai membri dell’azienda che hanno ruoli di tipo direttivo/manageriali e come tali sono tenuti a prendere decisioni. Il management viene definito dalla proprietà.

Ne fanno parte:

NomeRuolo
Franco FarnediCEO, CFO, team Segreteria
Greta FarnediCOO, Scrum Master, PM, Responsabile UX & Design Team Produzione
Jacopo MarinelliTech Lead & Software Architect Team Produzione
Andrea SchwibbertCTO, team Assistenza tecnica, controller Contabilità e finanza
Alessandro Zanotticontabilità e amministrazione

Benefit

Siamo orgogliosi di informare i nostri dipendenti che la nostra azienda offre vantaggi significativi per il loro benessere finanziario e salute. Attraverso la convenzione con MetaSalute, i nostri dipendenti hanno accesso a servizi sanitari di qualità a tariffe convenienti, garantendo loro un’assistenza medica affidabile e accessibile. Inoltre, aderiamo al fondo Cometa per il trattamento di fine rapporto (TFR), assicurando la sicurezza economica dei nostri dipendenti anche al termine del loro impiego. Queste iniziative testimoniano il nostro impegno nel promuovere il benessere globale dei nostri collaboratori e nel fornire loro un ambiente lavorativo sostenibile e gratificante.

link iscrizione e dettagli copertura MetaSalute:

https://www.fondometasalute.it/

link iscrizione e dettagli per adesione fondo Cometa: c’è la possibilità di destinare TFR e stipulare una pensione integrativa:

https://www.cometafondo.it/

info: deducibilità fondo pensione fino al tetto massimo versato di 5.164,57 euro anno

https://www.propensione.it/approfondimenti/deducibilita-fiscale-la-pensione-integrativa-puoi-un-grande-risparmio-irpef-26305/#:~:text =Ogni%20anno%20%C3%A8%20possibile%20portare,a%20persona%2Fcontribuente%20che%20deduce

REGOLAMENTO AZIENDALE

Il presente regolamento costituisce accordo tra le parti e viene sottoscritto per presa visione.  Una versione aggiornata del regolamento è sempre disponibile sulla bacheca digital in intranet.

La trasgressione ripetuta di una o più norme indicate darà adito ad una procedura disciplinare che prevede un primo richiamo verbale, un successivo richiamo scritto ed in caso di trasgressione reiterata, il licenziamento per giusta causa.

La Direzione inoltre si riserva la facoltà di modificare in qualsiasi momento il presente regolamento al fine di migliorare l’operatività aziendale.

1. Strumenti aziendali

1.1 Auto

  1. La dotazione dell’auto aziendale (Ford Fiesta Van) è garantita per le attività lavorative e non per scopi personali ed utilizzi fuori dall’orario di lavoro, fatta eccezione espressa autorizzazione scritta da parte della Direzione.

  2. E’ responsabilità della Segreteria la manutenzione e cura del mezzo a spese dell’azienda.

  3. Il lavoratore che venisse trovato alla guida in stato di ubriachezza o sotto l’effetto di stupefacenti è passibile di licenziamento in tronco, previa procedura disciplinare.

  4. Le spese di carburante, autostrada e parcheggio sono a carico dell’azienda.

1.2 PC e accessori

  1. Il PC fornito in dotazione per il lavoro è di proprietà dell’azienda , e viene fornito al lavoratore ad esclusivo scopo lavorativo.
  2. il PC verrà periodicamente revisionato a livello tecnico da un incarico dell’ufficio e pertanto dovrà periodicamente essere riconsegnato alla direzione.
  3. l’utilizzo del PC è normato dalle leggi vigenti (copyright, sicurezza informatica, privacy) e la trasgressione di tali norme può comportare un primo richiamo formale ed costituire un successivo motivo di licenziamento.
  4. il software installato nel PC è solo quello autorizzato dalla direzione e con regolare licenza fornita dall’azienda
  5. E’ vietato utilizzare il PC per navigazione su siti non consentiti ed illegali secondo la norma italiana ed europea come:
    • siti di scaricamento illegale musica e film
    • siti di pedo-pornografia
    • siti di scaricamento software illegale
  6. il PC ed il suo contenuto va protetto con una password personale che deve essere conservata in un luogo sicuro ed accessibile alla direzione (Last Pass) e non condivisa con i colleghi o persone esterne all’impresa.
  7. il PC deve essere conservato in un luogo sicuro e non esposto a rischio furto o accesso non autorizzato
  8. il PC deve essere protetto da un antivirus
  9. il PC deve essere regolarmente sottoposto a procedura di backup su NAS dell’ufficio
  10. L’accesso ai contenuti del PC deve essere garantito in caso di necessità ed urgenza, tramite la password di sistema fornita alla direzione e tramite il backup centrale.
  11. La conservazione sul PC di documenti personali e di informazioni che possano ledere la privacy dei singoli utenti è vietata e la Direzione non si assume responsabilità qualora la trasgressione di tale norma possa portare all’esposizione di tali documenti.
  12. Il PC, se portatile, può essere portato a casa, dopo il lavoro, ma se ci si assenta per lunghi periodi (per assenza di malattia o per ferie) è opportuno concordare con la direzione la riconsegna in ufficio.
  13. il PC assegnato può essere utilizzato in via esclusiva o condiviso con colleghi ed attività periodiche: fiere, eventi, missioni.
  14. Non è consentito l’utilizzo del pc e degli altri strumenti assegnati per lo svolgimento di attività non inerenti al proprio incarico lavorativo, ai compiti assegnati e ai progetti in cui si è coinvolti.
  15. E’ vietato utilizzare durante l’orario di lavoro, strumenti di comunicazione personale come: posta elettronica non dell’ufficio o chat di comunicazioni con esclusione di quelle autorizzate (Microsoft Teams).

1.3 BYOD

  1. L’utilizzo di un dispositivo personale informatico (pc, tablet, smartphone) per le attività lavorative è di norma sconsigliato ma consentito a patto che si rispettino le norme aziendali di sicurezza e gestione dei dispositivi:

    1. la posta elettronica aziendale su PC può essere utilizzata attraverso l’app Outlook in versione desktop o web;
    2. Microsoft OneDrive e SharePoint possono essere installati e utilizzati sul proprio PC sia utilizzando l’app desktop che via web;
    3. documenti di lavoro devono essere conservati in copia locale su di un pc personale solo per il tempo strettamente necessario a svolgere il compito e poi archiviati su OneDrive/SharePoint.
    4. la posta aziendale su di un tablet o smartphone può essere installata solo con l’applicazione ufficiale (Microsoft Outlook) e con le modalità di sicurezza abilitate. Il dispositivo deve risultare “enrollment” per una possibile gestione da remoto;
    5. l’applicazione di telefonia 3CX deve essere installata e rimanere in funzione per mantenere la reperibilità da e verso l’esterno e l’interno negli orari d’ufficio in caso di indisponibilità di un telefono fisico VOIP configurato, o
  2. l’utilizzo di uno smartphone in ufficio per scopi personali, è da limitare allo stretto necessario per motivi di urgenza personale e familiare.

1.4 Telefono

A ciascun addetto viene fornita una linea interna appoggiata su applicazione di telefonia VOIP “3CX”. Tale applicazione è disponibile in versione desktop e mobile. All’interno degli

uffici inoltre vengono messi a disposizione dei telefoni VOIP configurati per l’utilizzo del servizio;

E’ fatto obbligo di installare l’app 3CX sul PC aziendale e/o altro dispositivo personale, in modo da permettere la reperibilità per le chiamate da e verso l’interno e l’esterno durante le fasce orarie lavorative;

L’utilizzo di funzionalità bloccanti le chiamate in ingresso (ad es. stato “Non disturbare”) deve essere concordato e motivato alla Direzione, e deve comunque avere una durata di tempo limitata

allo stretto necessario, compatibilmente con le motivazioni alla base di questa decisione.

2. Privacy e Controllo Accessi

  1. Le sedi di lavoro dell’azienda potranno essere dotate di sistema di videosorveglianza, utilizzate a norme di legge.

  2. Gli uffici sono dotati di un sistema di controllo verifica presenza che determinano anche l’ora di inizio e termine delle prestazioni lavorative.

  3. Tutti i documenti presenti su pc, su server e sui servizi online utilizzati dall’azienda, sono di proprietà dell’azienda e non vanno condivisi o utilizzati impropriamente.

  4. Ad ogni lavoratore si assegna una funzione aziendale ed è consentito l’accesso a determinate aree e documenti: l’accesso involontario a documenti non di propria competenza (vedi note in contratto integrativo personale) deve essere puntualmente segnalato alla direzione. L’accesso volontario a documenti non di propria pertinenza è espressamente vietato.

  5. La posta elettronica aziendale @f.technology è ospitata tramite i servizi di Microsoft 365 ed ogni email viene archiviata a scopo “probatorio”. Il server di Microsoft fornisce anche log di accesso e utilizzo dei servizi di posta che permettono di stabilire data e  l’IP di accesso al servizio. in caso di necessità è possibile accedere anche alle email (spedite e ricevute) se anche cancellate dall’utente.

  6. Quando un lavoratore si assenta per un lungo periodo per malattia o ferie è tenuto a “delegare” la propria posta ad un collega indicato dalla direzione, attraverso il servizio “delega” di Microsoft, che concede la possibilità di accedere all’interfaccia web delle email e di rispondere ai messaggi in arrivo, qualificandosi comunque sempre come delegato. La funzione delega non fornisce accesso alla piattaforma di Chat che rimane visibile solo da parte dell’utente titolare dell’account.

  7. Nel corso dell’esecuzione del proprio lavoro è possibile che venga richiesto di eseguire registrazioni audio, video e foto necessarie a documentare le attività di supporto, formazione o presenza durante corsi ed eventi. Il dipendente acconsente in via generale alla gestione, pubblicazione (anche tramite canali social aziendali) ed archiviazione di tale materiale sotto forma digitale, fatto salvo il diritto di poterne richiedere la cancellazione in qualunque momento e per giustificato motivo.

  8. NDA per progetti interni e dati dei clienti: ai tutti i collaboratori che possano entrare in contatto ed a conoscenza di informazioni di tipo riservato e personale, viene richiesta la firma di un patto di riservatezza che le tuteli.

 3. Orari Lavoro

  1. l’orario ordinario di lavoro è di 8 ore giornaliere: compreso tra le ore 8:30 am  e termina entro le 18:00 (con una pausa compresa tra minimo un’ora e massimo 2 ore, per il pranzo). Accordi diversi possono essere presi fra la direzione ed i singoli lavoratori, in funzione delle necessità dell’ufficio e personali.
  2. Ogni lavoratore deve:
    1. marcare l’orario di ingresso utilizzando lo strumento di presenza[1]
    2. segnalare preventivamente alla direzione eventuali ritardi
    3. marcare l’ora di uscita per pausa pranzo
    4. marcare l’ora di ingresso dalla pausa pranzo
    5. marcare l’ora di uscita dal lavoro
  3. i ritardi sull’ingresso in ufficio vanno segnalati alla direzione e possono essere recuperati alla fine della giornata lavorativa o segnati come Permesso sul cartellino (minimo 30 minuti)
  4. pause durante l’orario lavorativo
    1. Segnalare sempre la propria assenza dalla postazione di lavoro alla direzione o ad un responsabile
    2. evitare di lasciare l’ufficio ed i telefoni scoperto durante l’orario di lavoro.
    3. segnalare puntualmente quando si inizia a lavorare o quando si termina per pausa o fine giornata, tramite la chat generale (team/IN-OUT)
    4. Il marcatempo prevede la possibilità di registrare due pause extra durante l’orario di lavoro, per assentarsi dall’ufficio per motivi personali (una telefonata, pausa caffe/spuntino o sigaretta). Richiedere sempre l’autorizzazione ad un responsabile di reparto o alla direzione e anticipare la pausa tramite la chat generale (team/IN-OUT).
  5. il lavoratore è tenuto a registrare giornalmente le attività svolte, tramite software ClickUp.
  6. il lavoratore è tenuto a compilare periodicamente ed entro l’ultimo giorno del mese, il cartellino presenze, straordinari, rimborsi.

3.2 Pausa Pranzo

La pausa pranzo è prevista nella fascia oraria 12:30 - 14.30 (in funzione degli orari lavorativi) e non può essere inferiore ad 1 ora.

Chi preferisce andare a casa per la pausa pranzo può prendere una pausa da 1,5h a 2h.

E’ comunque vietato consumare i pasti alla propria postazione di lavoro.

3.3 Straordinari

  1. Gli straordinari vanno preventivamente autorizzati dalla direzione, in caso contrario non verranno retribuiti.

3.4 Ferie e Permessi

  1. Le ferie personali vanno pianificate preventivamente su base trimestrale. Variazioni richieste con un minor preavviso potranno essere rifiutate dalla direzione per motivi di organizzazione lavorativa.

  2. L’azienda si riserva il diritto di pianificare una settimana di chiusura estiva ed una natalizia.

  3. I lavoratori che accumulino più di 10 giorni di ferie arretrati sono tenuti a pianificare almeno 2 giorni di ferie il mese successivo.

  4. Le richieste di permesso vanno segnalate in anticipo alla direzione.

3.5 Malattia

Fermo restando valide le norme di legge per i contratti di lavoro privato, l’azienda in caso di malattia di un dipendente segue la seguente procedura:

  1. in caso di principio di malattia si consiglia il dipendente di avvisare tempestivamente l’ufficio e di rimanere a casa, al fine di evitare sia di peggiorare la propria condizione di malattia che il possibile contagio dei colleghi.
  2. Per questa assenza di un giorno dal luogo di lavoro non è necessario produrre un certificato medico ma è opportuno rispettare gli orari di reperibilità previsti per legge[2]. In alternativa il giorno di assenza potrà essere richiesto come permesso. Sul cartellino presenze indicare malattia senza certificato.
  3. Se la malattia perdura per più di un giorno è necessario recarsi dal medico che dovrà produrre in via telematica un certificato di malattia. Durante il periodo di degenza è opportuno rispettare gli orari di reperibilità. Sul cartellino presenze indicare malattia.
  4. Durante il periodo coperto da certificato medico è tassativo non presentarsi in ufficio e non svolgere attività alternative che possano pregiudicare il decorso della malattia.
  5. Infortunio sul lavoro: valgono le norme di legge
  6. Infortunio non sul lavoro: valgono le norme relative alla malattia.

In generale, l’azienda e il dipendente cercheranno di collaborare nel modo migliore per non influire negativamente sul decorso di guarigione e sulle attività lavorative.

4. Regole di comportamento in ufficio

4.1 Comportamento

Il lavoratore dovrà sempre mantenere davanti i colleghi e clienti un comportamento rispettoso e conforme alle comuni norme di pudore e decenza: quando si troverà all’interno dei locali dell’ufficio o quando ci si trovi presso la sede di clienti e durante eventi organizzati dall’azienda (cene, formazione, fiere).

4.2 Abbigliamento

L’abbigliamento che si adotterà in ufficio deve essere conforme alle norme di generale pudore e decenza, rispettare le condizioni climatiche e conforme ad un ambiente di ufficio aperto al pubblico.

I locali dell’ufficio di Cesena saranno mantenuti ad una temperatura media compresa fra i 19 ed i 21 gradi conforme di con le esigenze di abbigliamento necessarie per un ambiente lavorativo (ad esempio un vestito completo di giacca e cravatta) e pertanto si prega i lavoratori di vestirsi in accordo con le temperature indicate:

  • se si ha freddo si preveda un capo in più
  • se si ha caldo, si preveda un abbigliamento a strati che permetta di scoprirsi in caso

4.3 Sede Uffici

  1. Non è consentito gettare nel cestino dell’ufficio elementi diversi da carta o derivati.

  2. l’eventuale residuo alimentare deve essere gettato in apposito bidone.

  3. Non è consentito consumare alimenti o bevande alla postazione di lavoro, per motivi tecnici (danni alle attrezzature), igienici e di decoro. Qualora l’utilizzo di bevande come caffè o altri liquidi presso la postazione di lavoro producesse dei danni alle attrezzature informatiche dell’ufficio, il collaboratore dovrà risarcire completamente il valore o gli verrà decurtato dallo stipendio.

  4. In generale bevande ed i cibi vanno consumati nell’aree preposta nell’ufficio: area ristoro.

  5. Non è consentito l’utilizzo di auricolari per ascoltare la musica in ufficio. L’auricolare può altresì essere utilizzato per ascoltare corsi in video ed effettuare video-conferenze.

  6. Le scrivanie e gli spazi di lavoro vanno mantenuti in ordine e a fine giornata la scrivania deve essere ripulita da accessori, fogli e altro che ne possa impedire la pulizia.

  7. I portatili, se non vengono portati a casa, vanno riposti in apposito armadio

  8. il materiale tecnico di ufficio (dischi, accessori, cavi) deve essere inventariato e gestito per lo scarico e carico tramite apposita procedura.

  9. Le condizioni climatiche dell’ufficio (riscaldamento e condizionamento) e l’apertura delle finestre è regolato dalla direzione, coerentemente con il comfort di tutti.

    1. ogni singolo ufficio dispone di un regolatore di temperatura e potenza del termo ventilatore
    2. c’è un programma settimanale che accende alle 6:00 AM e spegne alle 18:00 PM l’impianto di ventilazione
  10. Durante l’orario di lavoro, salvo eccezionalità, l’attività dovrà essere svolta mantenendo la porta dell’ufficio chiusa per non disturbare il lavoro dei colleghi.

5. Attività personali non connesse ad ufficio

  1. La spedizione o ritiro di merce personale con corriere presso ufficio non è una attività ordinaria “consentita” - va autorizzata preventivamente  da direzione.

  2. l’organizzazione di “attività” personali in ufficio non connesse con il lavoro (di qualsiasi tipo) va autorizzate preventivamente.

6. DOVERI DEL LAVORATORE

Il presente regolamento deve essere osservato da tutti i dipendenti che in particolare dovranno prestare attenzione ad alcuni aspetti del mansionario che assume particolare rilevanza ai fini del corretto svolgimento del fine sociale e produttivo dell’azienda:

●      compilare a fine giornata e a fine settimana i timesheet di lavoro (che usiamo per emettere fatture e conteggiare i lavori svolti);

●      leggere periodicamente le e-mail e i task assegnati attraverso qualsiasi forma su base periodica minimo giornaliera, e gestire con la dovuta solerzia quelli più urgenti;

●      compilare opportunamente i rapportini di lavoro(gestione ticket su piattaforma) la cui errata o incompleta compilazione comporta un danno per il rapporto lavorativo con i clienti

●      segnalare la presenza in postazione (tramite apposito segnale informatico in cui si indica lo stato: presente, assente, fuori per missione, fuori per pranzo)

●      assentarsi dall’ufficio senza autorizzazione o motivo (per fumare o fare telefonate personali)

●      assenza ingiustificata dal lavoro (mancanza di certificato medico o motivo oggettivo non derogabile)

●      mancanza reperibilità in orario di lavoro per i tele-lavoratori (verificabile tramite chiamata su telefono aziendale che viene fornito ai tele-lavoratori)

Si ricorda che in caso di reiterata violazione del regolamento si procederà come da art. 46 del contratto di lavoro di cui allego un estratto.

Estratto del ccn COMUNICAZIONE ARTIGIANATO aggiornare nuovo contratto

Art. 46 (Disciplina del lavoro)

Per infrazioni disciplinari l’impresa potrà applicare i seguenti provvedimenti:

- rimprovero verbale o rimprovero scritto;

- multa sino a tre ore di lavoro normale;

- sospensione dal lavoro fino a tre giorni;

- licenziamento senza preavviso.

Nelle sottoelencate mancanze, al lavoratore potranno essere inflitti: il rimprovero verbale o scritto, nel caso di prima mancanza; la multa nei casi di recidiva; la sospensione nei casi di recidiva in mancanze già punite con la multa nei sei mesi precedenti.

Nel caso le mancanze, tuttavia, rivestano carattere di maggiore gravità, anche in relazione alle mansioni esplicate, potrà essere direttamente inflitta la multa o la sospensione quando il lavoratore:

a) non si presenti al lavoro o abbandoni il posto di lavoro senza giustificato motivo oppure non comunichi l’assenza o la prosecuzione della stessa secondo la procedura prevista dall’art. 40, salvo il caso di impedimento giustificato;

b) ritardi l’inizio del lavoro o lo sospenda o ne anticipi la cessazione;

c) non esegua il lavoro secondo le istruzioni ricevute oppure lo esegua con negligenza;

d) arrechi per disattenzione anche lievi danni alle macchine o ai materiali in lavorazione; ometta di avvertire tempestivamente il suo capo diretto di eventuali guasti al macchinario in genere o di evidenti irregolarità nell’andamento del macchinario stesso;

e) sia trovato addormentato;

f) fumi nei locali ove è fatto espresso divieto o introduca senza autorizzazione bevande alcoliche nello stabilimento;

g) si presenti o si trovi sul lavoro in stato di ubriachezza o sotto l’effetto di sostanze stupefacenti. In tal caso, inoltre, l’operaio verrà allontanato;

h) alterchi anche con vie di fatto purché non assumano carattere di rissa;

i) proceda alla lavorazione o costruzione nell’interno dello stabilimento, senza autorizzazione della impresa, di oggetti per proprio uso o per conto terzi, allorché si tratti di lavorazione o costruzione di lieve rilevanza;

l) in qualunque modo trasgredisca alle disposizioni del regolamento interno all’azienda o commetta qualunque atto che porti pregiudizio alla morale o all’igiene.

Potrà essere licenziato senza preavviso il lavoratore colpevole di:

  1. lavorazione o costruzione all’interno dello stabilimento senza autorizzazione dell’impresa di oggetti per proprio uso o per conto terzi, nei casi non previsti dal precedente punto i), salvo però il diritto dell’azienda di operare sull’indennità, e fino alla concorrenza dell’indennità stessa, le trattenute dovute a titolo di risarcimento danni;

  2. introduzione nello stabilimento di persone estranee senza regolare permesso della impresa, salvo il caso in cui la mancanza in concreto abbia carattere di minore gravità, nella quale ipotesi potranno applicarsi i provvedimenti disciplinari di cui sopra;

  3. recidiva nella medesima mancanza che abbia dato luogo già a sospensione nei sei mesi precedenti, oppure quando si tratti di recidiva nella identica mancanza che abbia già dato luogo a due sospensioni;

  4. reati per i quali siano intervenute condanne penali definitive e per i quali, data la loro essenza, si renda incompatibile la prosecuzione del rapporto di lavoro;

  5. prestare la propria opera presso aziende che svolgono attività similari a quella presso la quale è occupato, o comunque esercitare attività in concorrenza diretta con la medesima;

  6. insubordinazione grave ai superiori;

  7. furto;

  8. danneggiamento volontario o con colpa grave del materiale dello stabilimento o del materiale in lavorazione;

  9. risse nell’azienda;

  10. reati di cui al punto 4 commessi nell’ambito aziendale;

  11. trafugamento di schizzi, disegni o documenti, di procedimenti di lavorazione o di fabbricazione o di riproduzione degli stessi;

  12. assenza ingiustificata per tre giorni di seguito, salvo che la giustificazione dell’assenza non sia potuta pervenire all’azienda in tempo utile a causa di comprovati motivi di forza maggiore.


[1] il dispositivo di rilevamento presenza è predisposto dall’azienda e indicato al lavoratore nella scheda tecnica di procedure eseguite. I lavoratori in homeworking dovranno indicare manualmente le ore attraverso il timesheet in Fsuite.

[2] orari di reperibilità sono 10-12 e 17-19

2FA gestione

Tutti gli account ad uso comune devono avere il 2FA memorizzato in modo raggiungibile da tutti i membri del team.

metodi di archiviazione

LastPass

Creare un oggetto di tipo Note, e memorizzare in allegato i file di qr-code e codice univoco e codici di emergenza.

ITglue

Come file

Credenziali clienti

Le credenziali si possono trovare su LastPass se esclusive nostre.

Su ITGlue se sono del cliente.

Ruoli e compiti

Da una recente analisi mi sono reso conto che avere tutti i ruoli di un progetto concentrati in una unica persona è controproducente in taluni casi.

Pertanto

Nelle sotto sezioni trovi i diversi ruoli presenti in un progetto ed i rispettivi compiti

+ cliente

AttivitàPMAccountPOSCRUM
Analyst
Cliente
Scelta del Team che esegue lavorox
Analisi tecnica e quantificare preventivoxxxx
Preventivo economicox
Redigere contrattox
Predisporre Ganttx
Redigere documento tecnico preliminarexx
Redigere documentazione finalexx
Scrive le use case (Stories)x
Scrivere i task (card)ox
Controllare il budget progetto e di fasexx
SALx

Panoramica gestione progetti

Ogni progetto è caratterizzato da alcuni attributi fondamentali che vanno inseriti a cura del PM secondo questo mansionario: Private (https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-60520)

Se il progetto è sviluppo conto terzi, indicare il committente e se l’azienda per cui si lavora ha più referenti, indicare il nome e cognome referente.

Assegnare i Tag del tipo cliente (Agenct, Startup, B2C) e tipologia (a corpo, tm o contratto)

altri campi importanti da compilare:

Ruoli da definire per ogni progetto.

Il successo di un progetto è frutto di un lavoro congiunto di questi 4 attori e loro è la responsabilità.

il quality manager nello sviluppo software, quale funzione ha questa persona in azienda?

Il Quality Manager nel contesto dello sviluppo software ha la funzione di garantire la qualità del prodotto software sviluppato dall’azienda. Le sue responsabilità includono la definizione e l’applicazione di metodologie e processi per garantire che il prodotto software rispetti gli standard di qualità stabiliti dall’azienda, l’identificazione e la gestione dei rischi di qualità, la definizione di metriche per la valutazione della qualità del prodotto e la formazione del personale dell’azienda sulle best practices per garantire la qualità del prodotto software. Inoltre, il Quality Manager collabora con il team di sviluppo per identificare e risolvere eventuali problemi di qualità del prodotto durante il processo di sviluppo e verifica che il prodotto software sia conforme alle specifiche e ai requisiti dei clienti.

come si chiama la figura professionale che nell’ambito dello sviluppo software svolge il ruolo di controllo di qualità del prodotto software realizzato dal team?

La figura professionale che si occupa del controllo di qualità del prodotto software sviluppato dal team è generalmente denominata Quality Assurance (QA) Engineer. Questa figura professionale ha il compito di definire le metodologie e le attività di controllo di qualità necessarie per garantire che il prodotto software rispetti gli standard di qualità stabiliti dall’azienda e sia conforme alle specifiche e ai requisiti dei clienti. Il QA Engineer lavora a stretto contatto con il team di sviluppo per garantire che il prodotto software sia testato in modo completo ed efficace e che i problemi di qualità vengano identificati e risolti in modo tempestivo. Inoltre, il QA Engineer è responsabile della definizione delle metriche per la valutazione della qualità del prodotto software e della generazione dei report sulle attività di controllo di qualità svolte.

Definisci il ruolo della figura identificata come Product Owner in un team di sviluppo software

Il Product Owner (PO) è una figura chiave in un team di sviluppo software, responsabile della gestione del prodotto software sviluppato dal team. In particolare, il PO ha il compito di definire le caratteristiche e le funzionalità del prodotto software, di stabilire le priorità delle attività di sviluppo e di fornire la visione complessiva del prodotto al team di sviluppo.

Il PO interagisce con gli stakeholder del prodotto, come ad esempio i clienti, gli utenti finali, gli esperti di settore e altri membri dell’azienda, per comprendere le loro esigenze e tradurle in requisiti specifici per il prodotto. In base a queste esigenze, il PO definisce la lista delle attività di sviluppo da svolgere, organizzandole in un backlog prioritizzato in cui le attività più importanti e urgenti sono in cima alla lista.

Durante il processo di sviluppo, il PO lavora a stretto contatto con il team di sviluppo per assicurarsi che le attività di sviluppo siano allineate agli obiettivi del prodotto. Il PO partecipa alle sprint review per verificare che le funzionalità sviluppate soddisfino i requisiti dei clienti e degli utenti finali, e aiuta il team di sviluppo a prendere decisioni riguardanti il prodotto. Infine, il PO è responsabile del successo del prodotto e si assicura che il prodotto soddisfi le esigenze degli stakeholder e raggiunga gli obiettivi prefissati.

Definisci il ruolo della figura Product manager in un team di sviluppo software

Il Product Manager (PM) è una figura strategica in un team di sviluppo software, responsabile della gestione del prodotto software in tutti i suoi aspetti, dalla concezione all’uscita sul mercato. Il PM ha la responsabilità di definire la strategia di prodotto, di coordinare le attività di sviluppo e di assicurare il successo del prodotto.

In particolare, il PM si occupa di definire la visione di prodotto e di identificare le opportunità di mercato, analizzando le tendenze del settore e le esigenze dei clienti. In base a queste informazioni, il PM definisce il piano di prodotto, che include il posizionamento del prodotto sul mercato, la definizione del pubblico target, la definizione dei requisiti di prodotto e la roadmap di sviluppo.

Durante il processo di sviluppo, il PM lavora a stretto contatto con il team di sviluppo per assicurarsi che le attività di sviluppo siano allineate alla strategia di prodotto e che il prodotto soddisfi i requisiti definiti. Inoltre, il PM è responsabile della definizione delle funzionalità del prodotto, della gestione del backlog di prodotto e della priorizzazione delle attività di sviluppo in base alle esigenze del mercato.

Infine, il PM è responsabile del successo del prodotto sul mercato, monitorando le metriche di prodotto e il feedback dei clienti, identificando eventuali problematiche e definendo le attività di miglioramento del prodotto. Il PM è anche responsabile del pricing del prodotto, della gestione del budget di prodotto e del lancio sul mercato del prodotto, coordinando le attività di marketing e di vendita.

Account

Cosa fa l’account di un progetto

  • Fa il preventivo (con ausilio del PM che dovrà fornire un dettagliato capitolato tecnico che a sua volta si affida ai tecnici del team) sulla base dell’analisi delle richieste del PO.

  • Il preventivo deve essere finalizzato a macro task (fasi) direttamente misurabili e quantificate.

  • Su segnalazione del PM, se ci sono degli scostamenti di budget, deve proporre integrazioni al preventivo o autorizzare lo scostamento.

  • redigere il contratto e farlo firmare al cliente

  • definisce con il cliente il referente che autorizza i report di fatturazione e lo indica nel gestionale e lo comunica con il PM

  • definisce con il PM il flusso di generazione delle fatture pro-forma, indicando se i report/proforma vanno inviati a lui o al Referente Cliente.

  • essere coinvolto se ci sono problemi su pagamenti, contestazioni o ritardi sulla consegna o sulle procedure di lavoro con il cliente.

  • E’ responsabile, globalmente, della redditività di un cliente

  • Di norma ogni cliente ha un account designato

  • designa il Team che farà lavoro

quando possibile evitare di essere Account di amici che si frequenta fuori dal contesto lavorativo, per ridurre gli effetti “concorrenti” di queste due condizioni.

Alcuni documenti e step che ogni progetto dovrebbe avere:

  • tipologia progetto (T&M o Corpo)

  • tempi (Gantt) con step di rilascio e pagamento

  • costi a fine progetto (manutenzione canoni)

  • costi di hosting

  • contratti (per hosting, progetto, manutenzione)

  • un piano di lavoro con tempi e accordi con il cliente

tutta la documentazione deve essere raggiungibile via F.suite tramite il link

Campi da compilare per cliente e progetto a cura del Account

Referente del progetto a cui comunicare gli stati avanzamento SAL

Referente alternativo a quello amministrativo dell’azienda, per invio report e pro-forma.

Chi può essere account in F.technology

In generale chi porta il cliente può richiedere di essere l’account. Anche chi porta un progetto in vendita può essere account.

Gli account in genere sono persone con esperienza e capacità di gestire le obiezioni e lamentele del cliente

Gli account hanno autonomia di sforamento di budget, ma ne sono responsabili su base annuale.

Chi ha subito numerosi sforamenti di budget può essere revocato dallo stato di account di un cliente o in generale dal ruolo

Alcuni degli account attualmente accreditati in Azienda

Franco Farnedi
Massimo Maioli
Elena Brigliadori
Andrea Schwibbert
Roberto Betti
Antonio

PO

Il PO (product Owner) può essere interno a F.technology o una figura di riferimento del cliente (PM dell’agenzia ad esempio).

Ruolo del PO è scrivere le specifiche di progetto e definisce le scadenze (requirement) definendo un Gantt che concorderà con il PM, il PO deve validare le feature dopo la il rilascio, prima di essere mostrate al cliente/utilizzatore finale. Deve ricevere un report dal PM sul raggiungimento degli obiettivi prefissati.

Se ci sono scostamenti (su tempi o budget ore), deve autorizzare lo sforamento, eventuale dopo aver ricevuto una autorizzazione dall’account in caso di modifiche su tempi e costi.

chi è?

figure con sufficienti esperienza tecnica per descrivere i macro task di un progetto

Franco Farnedi
Massimo Maioli
Elena Brigliadori
Andrea Schwibbert
Roberto Betti
Antonio
Leonardo ?

PM

Private (https://app.clickup.com/2402546/docs/29a7j-24360/29a7j-198612)

CTO

Il CTO in azienda è Andrea Schwibbert di base ecco i ruoli assegnati:

  1. Sviluppo tecnologico: Il CTO è responsabile della guida dello sviluppo e dell’implementazione delle tecnologie necessarie per supportare le operazioni aziendali e raggiungere gli obiettivi strategici.
  2. Gestione del team tecnico: Il CTO supervisiona il team tecnico, che può includere sviluppatori software, ingegneri, e altri professionisti IT. Si occupa di assumere, formare e gestire questo team per garantire che le competenze e le risorse siano allineate con gli obiettivi aziendali.
  3. Pianificazione strategica: Il CTO contribuisce alla pianificazione strategica dell’azienda, identificando le tecnologie chiave e le iniziative necessarie per mantenere la competitività nel mercato.
  4. Sicurezza informatica: Assicura che vengano implementate misure di sicurezza informatica adeguate per proteggere i dati sensibili dell’azienda e dei clienti.
  5. Gestione dei progetti tecnologici: Supervisiona la gestione dei progetti tecnologici, garantendo che vengano rispettati i tempi, i budget e gli obiettivi di qualità.
  6. Collaborazione interfunzionale: Collabora con altri dirigenti e dipartimenti per garantire che le soluzioni tecnologiche supportino le esigenze aziendali complessive.

In sostanza, il CTO ha il compito di guidare lo sviluppo e l’implementazione delle tecnologie necessarie per il successo dell’azienda, nonché di garantire che le risorse e le competenze tecnologiche siano allineate con gli obiettivi aziendali.

CFO

da completare: al momento copre il ruolo Franco

COO

Ufficio e Foresteria

Regole ufficio e cucina

(da scrivere riportando da regolamento9

Regole Foresteria

Per Residenti

Lavaggio delle lenzuola stanza ospiti

quando uno dei colleghi si ferma per una o più notti è compito dei residenti lavare le lenzuola usate dal collega per averle pronte per successivo utilizzo.

Per Ospiti

BUSINESS MODEL

Business model 2024-2025

Vendita tramite contratto di:

Progetti software personalizzati

Sviluppo di soluzioni software su misura o supporto allo sviluppo di moduli e componenti per software personalizzati, impiegando le competenze e gli stack tecnologici sui quali abbiamo deciso di concentrare il nostro investimento di risorse e know-how:

  • web App con i framework React & Node.js

  • siti web con CMS WordPress

  • siti web con il framework Astro

  • app iOS native sviluppate con Xcode e linguaggio Swift

  • app mobili ibride e progressive web app sviluppate con React Native

  • business app sviluppate con il low-code Claris

Abbiamo avuto esperienze in passato con le seguenti tecnologie che al momento abbiamo deciso di non usare più per nuovi progetti:

  • Angular

  • Flutter

  • Unity

  • Symfony

I progetti vengono venduto con due modalità di contratti: Waterfall o Agile a budget controllato.


Contratti di assistenza software e assistenza tecnica

Forniamo supporto tecnico a chiamata (ticket) su diverse tecnologie e linguaggi di sviluppo software, attraverso l’acquisto di un pacchetto orario da consumare entro 12 mesi e pagamento programmato secondo accordi commerciali.

Le attività di supporto sono svolte sulle tecnologie sopra esposte (dove eseguiamo anche lo sviluppo dei progetti) ma anche su:

  • WordPress low-code

  • Unix hosting management

  • GDPR tech

  • Cyber Security IT

  • MacOS IT support

  • Microsoft IT support

Per usufruire del supporto tecnico è necessario pre-acquistare un pacchetto ore il cui costo è proporzionalmente ridotto all’aumentare delle ore acquistate

I contratti di assistenza non dispongono di SLA specifiche ma sono basate sul metodo FIFO, fatto salvo la prenotazione preventiva di risorse sul calendario o la sottoscrizione di un Contratto di Manutenzione.


Contratti di manutenzione

I contratti di manutenzione sono accordi che prevedono il pagamento di una fee mensile su base di contratto tipicamente annuale, a fronte di un servizi fornito in modo forfettizzato e quindi a costo fisso.

(qui aggiungere le casistiche)

Sui software sviluppati da noi un contratto di manutenzione ha un costo minimo pari al 10% del valore del software realizzato e può raggiungere fino al 20% in caso di servizi extra inseriti nel contratto.

Tra le altre cose, molto importanti, garantisce la disponibilità di un team tecnico in grado di operare sulla tecnologia usata nel progetto.

un esempio di contratti di manutenzione sono:


Contratti di fornitura hosting managed

Forniamo servizi di hosting tramite provider cloud che rivendiamo e su cui aggiungiamo la nostra gestione, competenza e manutenzione. Spesso sono venduti in tandem con contratti di manutenzione, o pacchetti di assistenza tecnica.


Fornitura di prodotti hardware e software

Siamo partner di alcuni brand IT di cui rivendiamo prodotti e servizi:

  • Claris

  • Adobe

  • Microsoft

  • Google

  • Synology

  • Apple

In media teniamo un margine fra il 10% e 20% ma vendiamo solo se in abbinamento con contratti di Assistenza o Manutenzione.


Produzione software proprietario venduto SaaS o Licenza

Dal 2024 incominciamo a commercializzare software standard o con personalizzazione partendo da prodotto standard, sulla base dei diversi progetti realizzari negli ultimi 5 anni e anche su nuove idee di prodotto.

I doftware posonno essere venduti come SaaS, come Prodotto a licenza + manutenzione, come mudulo o plugin per marketplance e come progetto di StartUp e piattaforma.

Alcune idee

Software GESTO per Compagnie Teatrali e Operatori dello Spettacolo

Venduto in SaaS con canone di 300€ al mese a partire da settembre 2024

Modulo FM Cassetto Fiscale

Modulo che si interfaccia con il cassetto fiscale di AE e scarica le fatture passive e attive (vedi Sibill)

  • Modulo FM fatture elettroniche Attive

  • Modulo FM fatture elettroniche Passive

  • Modulo FM x 2C

  • WineApp “evolution”

  • Photo DAM

  • myDinnerClub

  • ????

Tariffa oraria o SP

Un paio di note sull’aspetto SP e sul pair programming, nonché sul lavoro “in coppia” in generale.

Il lavoro con il cliente

Lavorare fianco a fianco con il cliente per 4 ore al fine di “fare analisi e prendere decisioni” insieme è una pratica che comprendo. Nasce dalla disponibilità di Elena e Max: si dedicava tempo comune per affrontare e risolvere i problemi emersi durante la settimana.

Per noi, questo metodo non è ottimale e lo usiamo solo in pochi casi e con un aggravio di costi

Mi spiego meglio:

Nel 2023, un altro cliente (Nolpal) ha richiesto questo tipo di “mentoring” e formazione live del team. Abbiamo già avuto esperienze simili con altri clienti. Tuttavia, non funziona bene ed è sbagliato. Ecco perché:

  • Improvvisare risposte ai problemi dei clienti è complesso; non siamo in un quiz o in un gioco a premi.

  • Ogni persona ha propri tempi e modi di lavoro… Avere il cliente che aspetta risposte immediate è molto stressante e poco produttivo: non dobbiamo dimostrare conoscenza e capacità rispondendo alle domande in tempo reale.

  • Non possiamo chiedere supporto ai colleghi o fare ricerche approfondite.

  • Alcuni di noi sono bravi in questo “gioco”, ma non sempre sono i più esperti o quelli con le risposte giuste… Io e Max, ad esempio, abbiamo gestito questa pressione per anni, improvvisando e apparendo credibili… ma non tutti amano farlo e, ripeto, così non si ricevono le risposte migliori!

Come lavorare meglio?

  • Porre domande durante la settimana via Clickup, email o ticket e confrontarsi dal vivo solo quando le soluzioni sono state analizzate e ci sono risposte certe.

  • Incontrarsi occasionalmente per qualche ora per analizzare, discutere e valutare.

  • Organizzare incontri per formazione e per spiegazioni su come utilizzare certi strumenti.

Questo tipo di attività dal vivo è fatturata a tariffa oraria e non è inclusa nel costo dei task/card che viene espresso in SP. Va considerata come consulenza/analisi/formazione con una specifica tariffa oraria.

Differenziamo le quotazioni

La quotazione a corpo comporta un’analisi e un preventivo omnicomprensivo, quindi c’è un rischio d’impresa. Evitiamo preventivi a corpo per lavori sotto i 1.000€ o meno di 2 SP. Preferiamo proporre almeno 1SP per l’analisi preliminare. Il cliente paga questa fase, ma può interrompere se il preventivo finale non soddisfa.

Senza analisi, anche per lavori piccoli, chiediamo da 500€ a una media di 1.000/1.500€.

Quindi, è sempre meglio fare analisi e quotare dopo aver investito tempo nell’iniziale.

La quotazione Agile in SP è dinamica e basata su unità di lavoro e complessità che definiamo SP: sprint point. Ogni SP corrisponde a un equivalente di ore in tariffa oraria/contratto assistenza:

  • 1SP = 8 ore = 400€

  • 0.5SP = 4 ore = 200€

  • 0.1SP = 1 ora = 50€

I SP vengono assegnati a ogni task/ticket all’inizio e condivisi pubblicamente dal PM con il cliente, che può sospendere il lavoro se non concorda con il budget. Gli SP riflettono il valore e la complessità dell’attività, non il tempo effettivo. Includono correzione dei bug e controllo qualità interni. Sono indipendenti dall’esperienza del tecnico che esegue il lavoro.

Riteniamo l’approccio SP più adatto allo sviluppo software moderno e più equo rispetto al semplice conteggio delle ore lavorative.

Infine, la quotazione T&M, o body renting, valorizza il tempo dedicato piuttosto che il risultato. Vorremmo limitarlo alle attività dal vivo, alla formazione e alla consulenza dove il risultato dipende da molti fattori fuori dal nostro controllo.

Ad esempio, se il cliente desidera incontri periodici o vuole lavorare in coppia, questo tipo di attività va contrattualizzato in base alle ore impiegate, con costi variabili a seconda del ruolo e della qualifica del personale.

Prenotazione risorse

The text is talking about a concept of reserving software development resources for future weeks. It says that even if the resources are not used, they still need to be paid for. The best case scenario is that there is a reservation fee which is deducted from the cost if the resources are used, and kept if they are not used.

The problem is that there are limited technical resources available at f.technology, both in terms of number and expertise. Normally, work is planned in two-week sprints, during which the planned work is carried out.

If a client wants a certain work to be done before others, they need to reserve the resources in advance. They can also change the scope of the work during the sprint, following certain rules (like informing 2 days in advance, etc.).

Il testo parla di un concetto di riservare risorse per lo sviluppo di software per le settimane future. Si dice che anche se le risorse non vengono utilizzate, devono comunque essere pagate. Il caso migliore è che ci sia una tassa di prenotazione che viene detratta dal costo se le risorse vengono utilizzate e mantenuta se non vengono utilizzate.

Il problema è che ci sono risorse tecniche limitate disponibili su f.technology, sia in termini di numero che di competenze. Normalmente, il lavoro viene pianificato in sprint di due settimane, durante i quali viene svolto il lavoro pianificato.

Se un cliente desidera che un certo lavoro venga svolto prima degli altri, deve riservare le risorse in anticipo. Possono anche modificare l’ambito del lavoro durante lo sprint, seguendo determinate regole (come informare con 2 giorni di anticipo, ecc.).

CORPORATE IDENTITY

qui vanno link loghi, template e altri strumenti di comunicazioni aziendale

_______ BP

MARKETING

WORDPRESS

Staging

sui vari sistemi dove è possibile usare lo stage per wordpress va applicata questa best practice:

  1. staging quando non si usa da un po di tempo ma ci serve tenere attivo deve essere protetto con password… a volte conviene non avere password quando si lavora ma se si mantiene senza usare meglio metterla
  2. dopo 1 mese che il sito è online lo staging va cancellato - ci sono stage dimenticati on da mesi
  3. lo stage non è area di dev… quindi non ci deve essere una versione su stage unica di sviluppo o di contenuti  - se lo è - va evidenziato e va fatto un backup off-site

ricordo che stage è oltre che su kinsta, su cloudways e spinup

SMTP siti WordPress

Plugin

Di base per i siti WP utilizziamo sempre Post SMTP

https://wordpress.org/plugins/post-smtp/

Estensione Microsoft Office 365

https://postmansmtp.com/microsoft-365-wordpress-integration/

Impostazione lato Azure

https://postmansmtp.com/office-365-for-wordpress/

Nel caso di caselle mittenti condivise, l’utente (col quale si connette il plugin a Office365) deve essere membro e avere privilegi di: read and manage + send as.

Total themes

Purchase codes

Authors may ask you for a purchase code to verify that you’ve purchased this item.

  • f6421ad9-5679-44ea-b53e-c8987c89fd11 - 11 Jun 2021 REGULAR LICENSE
  • 8dfb729c-20c1-40ad-917d-92c2ba052fa5 - 9 Apr 2020 REGULAR LICENSE
  • 426575f6-272a-4430-aad8-fc8e027d95fc - 25 Sep 2018 REGULAR LICENSE
  • dde2ffba-d2d6-4f6c-be42-ffe1fa4dca6f - 25 Sep 2018 REGULAR LICENSE
  • 56739470-3034-46b3-9128-605d5ee76016 - 25 Sep 2018 REGULAR LICENSE
  • 5477d51d-d747-40b8-9162-75f24d408368 - 25 Sep 2018 REGULAR LICENSE
  • 7b56e006-ba4b-4033-9b27-8f992cac0fc7 - 25 Sep 2018 REGULAR LICENSE
  • 5ec9c691-1ec6-44b3-94d4-c863d9ca86a0 - 25 Nov 2017 REGULAR LICENSE
  • 33b7e6d0-1ebd-4605-abee-3c4b1595373e - 25 Nov 2017 REGULAR LICENSE
  • 9fb87b5f-f107-4c7f-b1a5-e4cf056e7b66 - 25 Nov 2017 REGULAR LICENSE
  • 62923e71-90ab-4fcb-9702-1df0a8c523e5 - 25 Nov 2017 REGULAR LICENSE
  • f9cd959a-fa9b-4779-804d-cbff72b1fe99 - 25 Nov 2017 REGULAR LICENSE
  • 25d016dc-4497-4289-b2d4-f75a43fc19b8 - 25 Nov 2017 REGULAR LICENSE
  • 089d6a35-ba10-476c-9c05-a7504a6c2e4e - 25 Nov 2017 REGULAR LICENSE
  • a3867b46-822b-425c-b8ae-9a104f1173c3 - 21 May 2017 REGULAR LICENSE
  • 5d93b297-fafd-41b6-b956-c3fc264d7284 - 14 Apr 2016 REGULAR LICENSE

Analytics tools

Elementor

Retina Display

a quanto pare Elementor non supporta nativamente il retina display e non ottimizza le immagini in modo autormatico quando inserite nella pagina.

Approfondire.

ANALYTICS

Non so se è corretto inserirlo in questa DOC… Intanto incominciamo.

GTM e Analytics

Documentazione in lavorazione

In generale creare tag più dinamici possibili… Non bisogna rimetterci mano ad ogni modifica del sito.

Per esempio ha senso un solo tag di contatto con parametro che distingue email e telefono:

Per la lingua creare variabile apposita riutilizzabile:

Molto utile! Per ricavare classe del pulsante Elementor:

function () {
var el = {{Click Element}};
var ret = "";
do {
el = el.parentNode;
} while ( !el.matches('.elementor-widget-button') && el !== document.body );
if (el && el !== document.body) {
var lista = el.classList;
for (var i = 0; i < lista.length; i++) {
var item = lista[i];
if(item.startsWith("cta-")){
ret = item;
break;
}
}
}
return ret;
}

Per ID GA4 creare sempre costante.

Per ricavare valore da modulo si usa dataLayer:

Per YouTube:

CLARIS

Sicurezza e Accessi

ogni file deve avere:

  • * un utente Full\_access riservato allo sviluppo (normalmente admin). A seconda delle tipologie ci può essere una password unica per più progetti o una password diversa per ciascuno, con una gestione delle pwd a livello di PM/Security. Altri utenti Full Access servono solo nel caso in cui si voglia tenere traccia delle attività di ogni singolo developer, in caso contrario entrano tutti con lo stesso utente. È possibile usare un utente con le stesse credenziali dell'accesso al sisteme solo a livello di gruppo LDAP/OD o mediante creazione manuale OAUTH. La lunghezza/complessità della password è relativamente inutile. Nel caso il cliente abbia accesso al sistema, creare un altro utente full access, con una password elementare (123456) con l'obbligo di cambiarla al primo accesso, specificando che nel caso venga cancellato/modificato/disabilitato l'utente full-access riservato allo sviluppo non saremo in grado di accedere alla soluzione.
    • un set privilegi DAPI unicamente per data API/Odata[ODBC], ovvero per tutte le attività che non richiedono un accesso mediante interfaccia utente (FMPRO o WEbDirect)

    • normalmente non servono profili specifici Web (lo sviluppo dovrebbe essere fruibile in maniera trasparente sulle diverse piattaforme, che vendono ricavate mediante funzione nel corso delle sessioni)

    • meglio usare set privilegi personalizzati che lo standard di FM. per gli altri utenti. Abilitare i privilegi estesi fmapp, fmurlscript, fmwebdirect, e la mossibilità di modifica della propria password. Le altre opzioni dipendono da cosa l’utente deve fare. La creazione di utenti dovrebbe essere gestita via script (con accesso completo) a meno che non si tratti di Oauth o OD/LDAP (in quel caso dipende da cliente e procedura)

versione precedente:

  • cancellare tutti gli altri utenti Full-Access ed attivare come Full-Access quelli in SSO (visto che è su nostro server ed è attivo, usiamo SSO per fare le attività di sviluppo). @Andrea Schwibbert questo potrebbe creare problemi con il flusso CI/CD e Otto Sync?
  • assegnare al cliente utenti di livello Data Entry Only o custom Privilege Set
    • norma
  • l’utente Webuser a cosa serve in questo progetto? Documentare se usato e come
  • Se cliente ha possesso del codice assegnare anche a lui un utente Full locale con password molto complessa e conservare in ITglue (potrebbe comunque essere quello creato prima)
  • se utente deve poter creare accessi e utenti, fare Privilege Set dedicato con accessi a menu sicurezza ma non Full Access

Gestione immagini

Questo capitolo è una prima bozza su alcuni aspetti relativi alla gestione immagini in filemaker come campi Contenitori.

Setup importanti da ricordare

Ci sono alcuni setup da considerare quando si usa un campo contenitore e si memorizzano immagini:

Manage Containers

è una funzione importare da configurare quando si deve rimappare la directory di riferimento dei file salvati su Server (in caso di spostamento o utilizzo di un volume diverso da quello principale)

Il cambio di directory non può essere eseguito su di un file shared via server ma va fatto da Client su file “locale”

E la funzione che crea delle anteprime delle immagini, per velocizzare il caricamento da server.

valutare in quali casi sia meglio la opzione storage permanente e quella temporanea

Ppzione di memorizzazione campo

Ricordarsi di valutare quale sia l’opzione migliore nei vari casi:

memorizzazione dati esterni e sicuri

PROJECT MANAGEMENT

La progettazione di un software coinvolge diverse fasi, ognuna con un ruolo specifico nel ciclo di vita del progetto. Ecco una panoramica delle fasi operative:

  1. Analisi dei Requisiti:
    • Inizia con l’intervista al cliente per comprendere le sue esigenze e i requisiti del software.
    • Si definiscono i requisiti funzionali (cosa il software deve fare) e i requisiti non funzionali (come deve farlo).
    • Questa fase è cruciale per stabilire una base solida per il progetto.
  2. Progettazione:
    • Durante questa fase, si crea un piano dettagliato per il software.
    • Si definiscono l’architettura, i componenti, i moduli e le interazioni tra di essi.
    • Si pianifica anche l’interfaccia utente e la struttura del database.
  3. Programmazione:
    • Qui inizia lo sviluppo effettivo del software.
    • I programmatori scrivono il codice seguendo le specifiche progettuali.
    • Si utilizzano linguaggi di programmazione e framework appropriati.
  4. Collaudo e Testing:
    • Il software viene testato per verificare che funzioni correttamente.
    • Si eseguono test funzionali, di integrazione e di sistema.
    • Eventuali bug vengono individuati e corretti.
  5. Deploying (Distribuzione):
    • Il software viene installato e reso disponibile agli utenti finali.
    • Può essere distribuito su server locali o cloud.
    • Si configura l’ambiente di produzione.
  6. Manutenzione:
    • Dopo il rilascio, il software richiede manutenzione continua.

    • Si monitorano prestazioni, sicurezza e bug.

    • Eventuali aggiornamenti o correzioni vengono apportati.

Cosa si intende per progettazione di un software?

Cosa vuol dire progettare un software? Sembra un’impresa titanica, qualcosa di molto complicato, perché un software è un’entità talvolta molto complessa e va d sé che anche progettarne sia un’attività estremamente articolata.

Ma niente panico, siamo qui per chiarirti le idee su come avviene il progetto di un software.

La digitalizzato oggi sta penetrando in tutti i settori e spesso le aziende si rendono conto di aver bisogno di software personalizzati, che possano soddisfare esigenze specifiche e che abbiano particolari caratteristiche.

La richiesta di piattaforme custom è sempre maggiore, tutti si immergono nell’avventura di progettazione di un software. Tuttavia, capita spesso di trovarsi impreparati ad affrontare in modo adeguato tutto le fasi, o perché si tende a saltare qualche passaggio fondamentale di analisi passando direttamente alla pratica, o ancora perché si insiste troppo poco sul collaudo del software. Ciò che è certo è che, se si vogliono raggiungere dei risultati concreti, è necessario affidarsi ad una software house specializzata in questo settore: solo un team di professionisti è in grado di seguire in modo preciso e scrupoloso tutte le fasi di progetto.

Dunque, quali sono le fasi di progettazione di un software? Sono 6 e tutte sono propedeutiche tra di loro, eccole di seguito.

  1. Analisi de requisiti
  2. Progettazione
  3. Programmazione
  4. Collaudo e testing
  5. Deploying
  6. Manutenzione

Le fasi del ciclo di vita di un software

Fase preliminare

Prima di entrare nel vivo delle fasi di sviluppo di un software vero e proprio, è necessario porre l’accento su una fase preliminare che ha l’obiettivo di contestualizzare il prodotto che si svilupperà in termini di vantaggi utilizzo, di descrizione del problema che questo software andrà a risolvere, nonché degli obiettivi che giustificano la sua esistenza.

A tal fine, è necessario fare un resoconto delle specifiche iniziali del software, ossia:

  • requisiti funzionali, features che il programma deve avere obbligatoriamente;
  • requisiti non funzionali, caratteristiche opzionali.

Uno strumento molto utile per schematizzare queste fase è la tabella MoSCow, che assegna a tutte le caratteristiche pensate per il software le etichette Must Have o Should Have per esprimere l’obbligatorietà di una funzionalità prevista.

Ciò che ti illustrerò è il più tradizionale e utilizzato modello di sviluppo e prende il nome di modello a cascata. Prevede che le fasi si susseguano in una sequenza lineare.

1. Analisi dei requisiti

Nello specifico, questa fase riguarda:

  • Il dominio applicativo, cioè il contesto in cui il software è destinato ad operare.
  • Le informazioni sull’applicazione, come lo scopo, definizioni, panoramica del sistema, riferimenti.
  • Le funzioni che svolgerà, caratteristiche degli utenti, vincoli o eventuali dipendenza.
  • requisiti relativi alle prestazioni.
  • Le specificità dell’interfaccia utente.
  • requisiti del database.

Questa è la fase più importante dell’ingegneria del software, poiché sbagliare in questo frangente può comportare sgradevoli perdite di tempo, col rischio di tornare ad aprire temi già affrontati e chiusi in precedenza.

Errori del genere comportano anche perdite economiche non indifferenti, dal momento che una descrizione approssimativa potrebbe portare al malfunzionamento finale del software.

Per tutti questi motivi è fondamentale affrontare questa fase di raccolta, descrizione e specifica dei requisiti che l’applicazione deve avere con attenzione maniacale, per non incorrere in gravi errori nelle fasi successive.

2. Progettazione

Questa è la fase in cui vengono definite le strutture di dati, le funzioni e i comportamenti in base ai vincoli imposti dai requisiti protagonisti della fase precedente. In pratica, si definisce l’architettura e la struttura dei singoli componenti del sistema.

Più in dettaglio, si tratta di definire le istruzioni operative per la fase di implementazione. Queste istruzioni devono essere adeguatamente dettagliate, raccolte in un documento ben strutturato e comprensibile. Questa, dunque, è anche la fase dedicata all’individuazione la migliore soluzione implementativa rispetto ai requisiti funzionali definiti, a quelli non funzionali e ai vincoli.

Le micro-attività di questa fase possono essere svolte con tempi e risultati diversi, ma come risultato della progettazione si ottiene l’architettura del sistema, ossia la sua organizzazione strutturale, contenente i componenti software, l’interfaccia dei componenti (ossia le proprietà visibili all’utente), la relazioni tra le varie parti.

La fase di progettazione prende in considerazione anche i fattori legati all’utilizzo di una tecnologia concreta, ecco perché la fase di progettazione non può prescindere dalle tecnologie utilizzate, a differenza della fase di analisi dei requisiti. Per questo motivo, durante la progettazione si definiscono anche tutti gli aspetti dell’implementazione.

Esistono degli strumenti molto validi che possono darci un grande aiuto in questo processo, come ad esempio il linguaggio di progettazione OCL (Object Constraint Language), ma è possibile anche ricorrere alla rete di Petri o al diagramma delle classi, i diagrammi di flusso (Gannt) o la sua evoluzione, l’UML activity diagram.

3. Programmazione

Finalmente si può passare alla stesura del codice, attività che è bene accompagnare con una dettagliata documentazione, per far sì che anche altri professionisti possano eventualmente mettere mano all’elaborato.

Poiché spesso questa fase della progettazione di software deve rispettare tempistiche ristrette, è necessario ricorrere a programmi dotati di tutti gli strumenti di facilitazione in un’unica soluzione per la scrittura del codice sorgente, un Integrated Development Enviroment (IDE), ossia un software che supporta i programmatori nello sviluppo del codice, dotato di un editor, un compilatore, uno strumento di building automatico e un debugger.

Sebbene la fase di analisi e di progettazione siano fondamentali, la scrittura del codice di programmazione costituisce senza dubbio la fase fondamentale: anche se analisi e progettazione sono state svolte al meglio, se il codice contiene errori, tutto il progetto può essere compromesso.

Durante la stesura del codice dovrebbe avere luogo anche il primo debugging, cioè l’eliminazione degli errori di sintassi più evidenti e grossolani, che possono danneggiare il funzionamento globale del programma. Di fatto, gli IDE più avanzati hanno efficienti sistemi di live debug che evidenziano in real time le porzioni di codice inutili, ripetuti, variabili non necessari ecc.

4. Testing

Terminata la fase di programmazione e del primo debugging, è fondamentale verificare che il funzionamento del software sia conforme alle specifiche definite nella fase di analisi dei requisiti. Questo tipo di errori sono più difficili da individuare rispetto a quelli evidenti della fase di live debugging: di solito, non si tratta tanto di errori di sintassi ma di errori concettuali o logici.

Quindi, durante la fase di test ci si accerta che l’applicazione si comporti effettivamente come era stato previsto e si segnalano le discrepanze di comportamento ai programmatori, i quali devono investigare per poi procedere alla rimozione degli elementi che causano queste discrepanze.

5. Deployment

Fatti tutti i test necessari, raggiunto un efficace livello di qualità, il software è pronto per andare in produzione.

“Andare in produzione” assume accezioni diverse in base al tipo di software realizzato. Se si tratta di programmi destinati alla vendita o alla distribuzione (software gratuiti), la produzione equivale al momento in cui il prodotto viene rilasciano sul mercato. Se, invece, si tratta di un programma realizzato e personalizzato per un cliente, questa fase equivale all’installazione e al collaudo presso la sede del cliente. Infine, nel caso delle web application, la produzione rappresenta l’installazione e il collaudo sul web server e il tuning di quest’ultimo.

In questo momento inizia la vita operativa del software creato, periodo in cui svolge il compito per cui è stato progettato e sviluppato.

6. Manutenzione

Per garantire il buon funzionamento nel software nel corso del tempo, è necessario aggiornarlo periodicamente, fornendo un pronto e costante supporto a coloro che utilizzano il programma quotidianamente.

Inoltre, durante la vita di un software in produzione, possono rendersi necessari degli interventi correttivi o di aggiornamento sull’applicazione, che possono anche prevedere nuove fasi di progettazione, sviluppo e test. Queste tipologie di interventi possono essere raggruppate in due famiglie:

  • Manutenzione ordinaria: si tratta di interventi correttivi giustificati da eventuali errori passati inosservati durante i test o causati dall’uso del programma in condizioni non previste durante la fase di progettazione.
  • Manutenzione evolutiva: in questo caso gli interventi hanno lo scopo di modificare o arricchire il software con nuove funzionalità, in questo caso giustificate da nuove necessità operative.

Generalmente, ogni programma è soggetto, durante la sua vita operativa, ad interventi correttivi ed evolutivi.

Le fasi appena descritte, come anticipato all’inizio, possono essere ascrivibili al modello di sviluppo a cascata. Si tratta di un modello sì molto comune e facilmente adattabile a diverse tipologie di progetto, ma talvolta può risultare poco flessibile: di fatto, tutte le fasi devono essere affrontate in modo lineare e diventa molto complicato andare a ritroso fra una fase e l’altra, ogni variazione all’interno di una delle fasi può provocare ritardi e slittamenti sulla tabella di marcia e portare inevitabilmente a ritardare la data di consegna, giorno intorno al quale ruotano tutte le fasi.

Altri modelli di sviluppo software

Una piccola panoramica di quali sono i modelli di sviluppo usati può essere utile a capire come anche la scelta del modello di sviluppo può influenzare le varie fasi.

Inoltre, ogni team di sviluppo può avere il proprio metodo e, soprattutto, ogni singolo progetto può richiedere delle modifiche o degli adattamenti al metodo abituale.

Ogni metodo di sviluppo ha i suoi pro e contro e non esiste un modello di riferimento, ecco quali sono oggi i modelli di sviluppo più utilizzati.

Modello evolutivo

Novità di questo metodo è il concetto di prototipazione, grazie al quale è possibile accelerare i tempi di verifica del software poiché viene prodotta una versione semplificata di esso.

Si basa su cicli composti da 4 fasi:

  1. Costruzione del prototipo
  2. Consegna del prototipo al cliente
  3. Feedback del cliente e conseguenti considerazioni
  4. Eventuali modifiche al prototipo in base alle osservazioni ricevute.

Il prototipo può anche essere un semplice mockup, ossia una basilare interfaccia, una sorta di schizzo, che nonprevede un effettivo funzionamento del programma ma che ha comunque il vantaggio di ridurre i tempi di valutazione dei requisiti funzionali ed può essere utile per fare ulteriori considerazioni sugli aspetti di progettazione prima passare all’implementazione del codice. Non porta ad alcun miglioramento, invece, dal punto di vista della programmazione vera e propria.

Modello a spirale

Questo modello prevede non più uno sviluppo in fasi lineari, ma un ciclo continuo e ripetuto delle fasi di creazioni del software, fino alla conclusione.

Può definirsi anche un “meta modello” perché si può anche applicare agli altri modelli e può essere considerato una sorta di framework, uno schema di step da seguire.

Tipica di questo modello è la valutazione dei rischi che va inserita in ogni ciclo di sviluppo.

Metodologia Agile

SI tratta del modello ormai più diffuso non solo in ambito di progettazione software ma anche nel project management.

Obiettivo principale di questa metodologia è la soddisfazione del cliente, che vede il suo software crescere piano piano grazie ai rilasci rapidi di modifiche al software.

Bisogna precisare, però, che la metodologia agile non è un vero e proprio modello di sviluppo, ma un insieme di operazioni che consentono di sviluppare un prodotto efficiente in tempi rapidi, con gruppi di lavoro autonomi e facili interazioni col cliente.

Hai in mente un progetto interessate? Oppure hai bisogno di un software personalizzato per la tua azienda? Scopri i nostri servizi e non esitare a contattarci per qualsiasi dubbio o chiarimento.