Tanti progetti, un solo team: accessi e fatturazione quando la localizzazione supera una sola app

La maggior parte dei setup di localizzazione nasce semplice: un’app, un progetto, tre persone che si conoscono tutte. Niente di questo articolo si applica a quel caso, e se siete lì, il resto è prematuro.

Cambia con la seconda app. Poi arrivano un client mobile, un sito marketing, un portale clienti, uno strumento di amministrazione interno. Ognuno è legittimamente un progetto a sé: ritmo di rilascio proprio, lingue proprie, piano proprio. E da qualche parte tra il secondo e il quinto, il lavoro smette di essere traduzione e diventa amministrazione.

Cosa si rompe davvero quando arriva il secondo progetto

Gli stessi inviti, ancora e ancora. Otto colleghi, cinque progetti, quaranta inviti, e ogni nuovo assunto ripete il rituale. È noioso più che pericoloso, ed è esattamente per questo che nessuno lo sistema finché non va storto qualcos’altro.

L’offboarding diventa un gioco di memoria. Una persona lascia l’azienda, o passa a un team che con il portale non c’entra più nulla. Ora la domanda è a quali progetti fosse stata aggiunta. Se la risposta vive solo nella lista utenti di ogni progetto, revocare l’accesso significa ricordarsi di ogni progetto esistente, e il prezzo di dimenticarne uno è una persona che mesi dopo modifica ancora i vostri testi in produzione. È il momento in cui una seccatura amministrativa diventa un rilievo di sicurezza.

La fattura si frammenta. Cinque progetti, cinque abbonamenti, cinque date di rinnovo, cinque documenti da riconciliare. L’amministrazione chiede perché un’azienda paga cinque volte un fornitore di localizzazione, e la risposta onesta è che lo strumento non aveva alcun concetto di azienda.

Gli esterni ottengono più accesso del previsto. La traduttrice freelance ha bisogno dell’italiano sul sito marketing. La strada più breve le dà un ruolo che arriva più lontano di così, perché restringerlo progetto per progetto è lavoro. Moltiplicate per ogni collaboratore esterno e ogni contatto di agenzia nel giro di qualche anno.

Nessuno sa dire chi ha accesso a cosa. Non perché manchi il dato, ma perché è sparso su N liste utenti di progetto senza un posto che le aggreghi. La prima volta che quella domanda viene posta sul serio, di solito arriva da un auditor, da un questionario di sicurezza di un cliente o da un incidente.

Perché le soluzioni di ripiego non reggono

Un unico grande progetto con i namespace. Allettante, perché dissolve il problema amministrativo all’istante. Dissolve però anche tutto ciò per cui avevate separato le app: un namespace è una fetta di contenuto dentro un progetto, quindi ne condivide le versioni, la pubblicazione, il piano e le regole di accesso. Due prodotti rilasciati in giorni diversi non possono condividere un ritmo di rilascio, e "lo stagista può modificare i testi marketing ma non il checkout" non è esprimibile in una struttura in cui entrambi sono namespace della stessa cosa.

Un login condiviso. Risolve il problema degli inviti distruggendo la tracciabilità, rende l’autenticazione a due fattori priva di senso e trasforma ogni uscita in una rotazione di password. Compare più spesso di quanto chiunque ammetta.

Un foglio di calcolo di chi ha cosa. Corretto il giorno in cui viene scritto. Nel momento in cui un accesso viene concesso da qualche parte senza aggiornarlo, è peggio di niente, perché ora è un documento che afferma con sicurezza qualcosa di falso.

Come dovrebbe essere fatta la struttura

Lo schema che regge è un livello account sopra i progetti, che possiede le due cose che sono fatti sull’azienda e non su una app: le persone e la fattura. Quattro proprietà lo fanno funzionare.

Un team, ereditato in ogni progetto. Invitate un collega una volta sola, sull’account, con il ruolo che deve avere in tutta l’azienda. Compare in ogni progetto di quell’account con quel ruolo. Si concede in un posto, si revoca in un posto. È questo che rende l’offboarding un’azione unica invece di una ricerca.

Due tipi di ruolo, e solo uno viene ereditato alla cieca. I ruoli che governano l’account (amministrazione e fatturazione) appartengono all’account e per definizione arrivano ovunque. Anche i ruoli operativi (gestire, pubblicare, tradurre) vengono ereditati, ma un progetto deve poter dire "questa persona qui no": restringerla a una sola lingua su quel progetto, o bloccarla del tutto. Senza questa eccezione un team ereditato è troppo grossolano da usare, e si torna agli inviti progetto per progetto.

Gli esterni restano sul progetto. Il team dell’account è per le vostre persone. Una traduttrice freelance o un contatto di agenzia riceve un permesso esattamente sul progetto su cui lavora, e non vede mai che il resto dell’account esiste. Questa singola regola è ciò che rende sicura l’ereditarietà: tutto ciò che sta nel team dell’account vale deliberatamente per tutta l’azienda, quindi tutto ciò che non deve valere per tutta l’azienda non ci sta dentro.

Un account, un abbonamento, una fattura. Ogni progetto si fattura dentro il suo account. Quando un reparto ha davvero bisogno di una fattura propria, di un metodo di pagamento proprio o di un insieme di persone proprio, quel reparto è un secondo account e non un caso particolare dentro il primo. Il tentativo di esprimere due fatture dentro un solo account è il punto in cui questi modelli diventano di solito qualcosa che nessuno riesce più a ragionare.

Oltre a questo, alcune cose hanno senso solo a livello di account: il single sign-on (un identity provider è un fatto sull’azienda, non su una app), l’autenticazione a due fattori imposta e un registro di audit di cosa è stato concesso e revocato a chi. Configurarle progetto per progetto è insieme lavoro ripetitivo e un ottimo modo per ritrovarsi con cinque diverse posture di sicurezza nella stessa azienda.

Come funziona in Locize

Questa è la forma delle organizzazioni in Locize, e la ragione per cui le abbiamo costruite.

La vostra organizzazione è il livello account. La ottenete automaticamente con il primo progetto, con il nome della vostra azienda, e potete rinominarla quando volete. Tutto quanto sopra è il suo comportamento:

• Il team vive sulla pagina dell’organizzazione. I membri vengono invitati una volta ed ereditano in ogni progetto, con un badge "via organization" nella lista utenti di ogni progetto, così distinguete sempre un accesso ereditato da uno diretto. Un permesso diretto sul progetto vince per i ruoli operativi, quindi potete restringere o bloccare qualcuno su un singolo progetto, e "inherit" lo restituisce alla regola dell’organizzazione. Dettagli nella gestione utenti.
• Admin e contabile esistono solo sull’organizzazione. I permessi di progetto si fermano a manager. È questo che rende vera la storia dell’offboarding: non c’è modo di accumulare potere valido in tutta l’azienda un progetto alla volta.
• La fatturazione è dell’organizzazione. Il primo progetto che sottoscrive crea l’abbonamento, e ogni progetto successivo vi si unisce: una fattura, mentre ogni progetto mantiene il proprio piano e i propri limiti. La fattura condivisa è inclusa in tutti i piani.
• Una fattura separata è un’organizzazione separata. Potete crearne una direttamente dal modulo di aggiunta progetto, e spostare un progetto esistente con un codice di trasferimento monouso: l’admin che riceve vede quale progetto arriva e da chi prima di confermare. Tenant e branch seguono automaticamente il progetto padre (multi-tenant).
• L’SSO è addebitato una volta per abbonamento, indipendentemente da quanti progetti lo usano. L’autenticazione a due fattori imposta si imposta per tutta l’organizzazione, e un progetto può rafforzarla ma mai indebolirla. Gli admin dell’organizzazione possono scaricare il registro di audit delle modifiche a membri e inviti, nei piani che lo includono.

Se usavate già la fatturazione collettiva, niente di tutto questo vi ha chiesto qualcosa: il vostro gruppo di fatturazione è diventato la vostra organizzazione, i suoi admin sono diventati admin dell’organizzazione, tutti hanno mantenuto i progetti che avevano, e la fattura è rimasta uguale o è diventata leggermente più economica, dato che l’SSO ora è addebitato una volta per abbonamento invece che una volta per progetto.

Quando non vi serve niente di tutto questo

Una app, una o due persone, nessun traduttore esterno, nessuna domanda di conformità: lasciate stare. Un singolo progetto con un paio di permessi diretti è la struttura giusta, e aggiungerci sopra un livello account non porta nulla. I segnali che è il momento sono concreti e li riconoscerete: il terzo progetto, la prima persona da rimuovere da più progetti insieme, la prima domanda dell’amministrazione sulla fattura, il primo questionario di sicurezza che chiede come vengono concessi e revocati gli accessi, o il primo collaboratore esterno a cui avete dovuto dare più accesso di quanto voleste.

Il senso del livello account non è che gestisce le vostre traduzioni. È che impedisce all’amministrazione attorno a esse di crescere con ogni prodotto che rilasciate.

Se più di uno di questi segnali vi suona familiare, il modo più rapido per vedere la struttura è guardare il vostro setup: la pagina dell’organizzazione elenca ogni progetto, chi vi accede e quanto costa in questo periodo. Iniziate gratis con Locize, oppure leggete prima la documentazione sulle organizzazioni se preferite vedere il modello prima del prodotto.