Conviene o è solo una rogna mettere su un sistema di ticketing open source per un team di 8 persone?

Calcolate il costo orario del vostro sviluppatore. Anche se dedicasse solo 4 ore al mese a installare, configurare e risolvere problemi di questo sistema, il costo interno aziendale pareggerebbe già la licenza cloud annuale. E se un giorno se ne va, chi ci mette le mani su quel server? Andate dritti su una soluzione cloud già pronta.

Non fatevi prendere dal fanatismo per l'open source. Agli sviluppatori piace far girare tutto sui propri server perché lo vedono come un giocattolo divertente. Ma quando le email dei clienti finiscono nello spam o il server va giù il conto lo pagate voi. Se il core business dell'azienda non è gestire server, il ticketing open source è solo un peso inutile.

Noi nella nostra agenzia di 10 persone abbiamo provato l'open source. Il primo anno, tra crash del server, sincronizzazione della posta saltata e problemi con gli aggiornamenti, il supporto si è bloccato completamente per 3 volte. Che figuracce con i clienti. Alla fine siamo passati a un sistema cloud già pronto: paghiamo 200 EUR al mese ma sono due anni che abbiamo la testa libera.

ma invece di installare il sistema open source da soli, se prendessimo un pacchetto già pronto con hosting gestito, l'onere della manutenziione rimarrebbe comunque nostro?

Fate benissimo a togliere di mezzo la casella condivisa, gestire le email in 8 persone è un delirio... Però ci sono i piani base dei sistemi pronti all'uso, con 12-15 EUR a testa risolvete il problema. Mettete a budget 100-120 EUR al mese per 8 persone e toglietevi il pensiero.

in germania le sanzioni sulla privacy sono pesantissime. se non configurate a dovere il sistema open source e vi scappa fuori qualche conversazione coi clienti son guai seri. i sistemi clooud hanno già tutte le conformità a posto.

In sintesi il punto comune di tutti è chiaro: anche se il software open source è gratuito, i costi di gestione operativa e manutenzione superano quelli dei sistemi cloud già pronti. Se il vostro core business non è l'amministrazione dei server, la scelta più logica è una soluzione pronta.

Tre cose da controllare mentre lo fai. Introdurre un processo per le richieste di modifica non rallenta il lavoro, lo accelera.

Nessun processo migliora senza tracciamento, perché non sai cosa correggere. Correggetemi se sbaglio.

Su questo punto non sono d'accordo. Se lo scope cresce, devono crescere o i tempi o il budget. Non c'è una terza opzione.

Assolutamente. Se devo aggiungere qualcosa: Quando prendete una decisione, scrivete anche lo scenario peggiore, non solo quello migliore.

È tutto, scusate se mi sono dilungato.

Grazie per aver scritto.

ho vissuto la steessa cosa.

L'anno scorso abbiamo vissuto quasi la stessa cosa. Se lo scope cresce, devono crescere o i tempi o il budget. Non c'è una terza opzione.

Nei sistemi ereditati, la cosa più costosa sono le dipendenze sconosciute. Se scrivete qui il risultato, sarà utile anche ad altri.

Preso nota, grazie. Da noi la cosa che faceva perdere più tempo era non sapere chi decidesse.

Cercare di farlo da soli è la strada più costosa.

Se scendiamo nei dettagli: Se è la prima volta, inizia in piccolo, il ridimensionamento viene dopo.

I primi tre mesi vanno bene, i problemi emergono al quarto mese. Questa è la mia opinione, non la scrivo come verità assoluta.

Ho un'obiezione qui. Il calendario dei pagamenti va legato alle fasi del lavoro, non alle date.

Questa è la mia opinione, non la scrivo come verità assoluta.

La risposta sopra ha colto l'essenza della questione. Chiunque abbia fretta su sistema di ticketing open source si blocca nello stesso punto.

Ogni "ci pensiamo dopo" in riunione significa lavoro non preventivato. Questa è la mia opinione, non la scrivo come verità assoluta.

L'anno scorso abbiamo vissuto quasi la stessa cosa. Più è difficile tornare indietro su una decisione, più lentamente dovreste prenderla.

Confermato dall'esperienza.