{"id":96751,"date":"2023-10-13T16:21:55","date_gmt":"2023-10-13T14:21:55","guid":{"rendered":"https:\/\/artigianodelsoftware.it\/blog\/?p=96751"},"modified":"2023-10-13T16:21:57","modified_gmt":"2023-10-13T14:21:57","slug":"team-managed-vs-company-managed","status":"publish","type":"post","link":"https:\/\/artigianodelsoftware.it\/blog\/2023\/10\/13\/team-managed-vs-company-managed\/","title":{"rendered":"Team managed Vs Company Managed"},"content":{"rendered":"
\"image_pdf\"<\/a><\/a><\/div>\n

Sono sempre stato leggerissimamente scettico dei progetti Team Managed. In questo articolo provo a spiegare come mai lo sono e perch\u00e9, sempre secondo la mia modestissima personale opinione, \u00e8 sempre preferibile creare dei progetti Company Managed. In qualsiasi caso<\/p>\n\n\n\n

\"\"
Esplorazione alchemica in corso<\/figcaption><\/figure>\n\n\n\n

Le ragioni che porto sempre con me<\/h2>\n\n\n\n

La prima cosa che indico come difetto di tali progetti \u00e8 il fatto di avere una configurazione molto molto (in alcuni casi uso anche il termine TERRIBILMENTE) limitata. Questo fa si che sia molto semplice configurare un progetto siffatto. Tuttavia non sempre questo pu\u00f2 risultare una arma vincente. Infatti se mettimao a confronto le due possibili configurazioni che abbiamo<\/p>\n\n\n\n

\"\"
Il confronto che troviamo quando generiamo nuovi progetti<\/figcaption><\/figure>\n\n\n\n
\n
\n
\"\"
Team Managed configuration<\/figcaption><\/figure>\n<\/div>\n\n\n\n
\n
\"\"
Company Managed configuration<\/figcaption><\/figure>\n<\/div>\n<\/div>\n\n\n\n

La prima cosa che notiamo \u00e8 che le opzioni sono limitate per i Team Managed. I Company managed, per quanto pi\u00f9 complicati, sono sempre pi\u00f9 completi nella configurazione e nella gestione. Questo sicuramente ci aiuta (per citare un vecchio adagio che ho imparato nella meravigliosa citt\u00e0 di Lucca: Nel pi\u00f9 c’\u00e8 il meno<\/strong>).<\/p>\n\n\n\n

In aggiunta, nei Team managed ho notato una cosa molto grave (secondo sempre il mio modesto parere): Non possiamo usare le risorse condivise. In alcuni casi mi sono trovato costretto ad una trasformazione di un progetto da TEAM a COMPANY perch\u00e9 non c’era alcuna possibilit\u00e0 di poter espandere tali progetti e sopratutto gli utenti erano stati costretti a replicare all’infinito (copiando manualmente e non assegnando una configurazione preesistente).<\/p>\n\n\n\n

In aggiunta, non sempre gli addon sono usabili anche su tali progetti. Ho rilevato che alcuni di essi non rispondono correttamente quando si prova ad applicarli. <\/p>\n\n\n\n

Il mio dubbio \u00e8 che questa tipologia di progetti, per quanto comodi, semplici e rapidi, non presentino delle strutture condivise e standard. Di conseguenza, occorre un qualcosa ad hoc per poter loro agganciare delle funzionalit\u00e0 standard.<\/p>\n\n\n\n

Un progetto Company Managed, per quanto sia complicato, hai comunque il controllo completo della configurazione e riesci sempre a cadere in piedi. Mi permetto di condividere un meme che ho visto qualche tempo f\u00e0 ed esprime esattamente dei concetti molto importanti:<\/p>\n\n\n\n

\"\"
Direi che l’immagine si commenta da sola<\/figcaption><\/figure>\n\n\n\n

In questo caso \u00e8 come disporre di un Linux e della sua splendida POTENZA.<\/p>\n\n\n\n

Conclusioni<\/h2>\n\n\n\n

Quello che continuer\u00f2 a suggerire, consigliare, fare presente e ribadire sotto tutti i punti di vista \u00e8 che un progetto Team Managed va bene per fare cose molto semplici. Se si prevede nel futuro di fare qualcosa di pi\u00f9, partite subito con un progetto Company Managed.<\/p>\n\n\n\n

A tale proposito, vi chiedo di visionare questo video di Monika Rani, che spiega in maniera molto chiara e semplice la differenza tra i due tipi di progetti:<\/p>\n\n\n\n

\n