<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">2016-03-15 18:22 GMT+00:00 Carlos Catucci <span dir="ltr"><<a href="mailto:carlos.catucci@gmail.com" target="_blank">carlos.catucci@gmail.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Questione di scala Enrico.</blockquote></div><br><div class="gmail_extra">A me verrebbe dire anche questione di business, piuttosto. O se vuoi, del tipo di business e del modello di deploy che hai.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Per esempio se fai sw "boxed" i rilasci sono costosissimi e vuoi certamente dell'infrastruttura massiccia di QA. D'altra parte per la maggior parte dei sw l'utente si aspetta che ci siano dei bachi. Insomma, Word (o chi per lui) ogni tanto crasha. Lo sappiamo tutti e continuiamo ad usarlo (magari usiamo il "chi per lui", che a sua volta ogni tanto va giu'). Pero' grosso modo e' su... il motivo e' che di fatto l'infrastruttura e' interamente in mano all'utente. Che d'altra parte vuole dire che determinati tipi di testing diventano molto piu' complicati. Il caso "pessimo" e' quello dei giochi che magari hanno bachi nei motori grafici che sono triggerati solo da certe combinazioni di un certo modello di scheda video con una certa versione dei driver su una certa versione di un certo sistema operativo.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Se c'e' un baco, si considera ok aspettare qualche mese per avere una minor version che lo aggiusta. Inoltre, se si introduce un baco, basta dare un buon modo all'utente di usare la vecchia versione e probabilmente gli si da solo un fastidio marginale. Non solo... certi utenti si aspettano che la nuova versione abbia bachi e prima di "adottarla" la testano. Pochi, eh... ma spesso quelli per cui e' veramente critico lo fanno.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Il modello dei servizi web e' opposto. Ci si aspettano rilasci brevi. Ci si aspetta che il software sia sempre su. I bachi sono una cosa statistica: ovvero sappiamo che per qualche utente ci saranno dei problemi, ma fintanto che il singolo utente non ha problemi troppo spesso si puo' tollerare. Poi ci sono un mucchio di cose che sappiamo che andranno storte... quindi via di retry. Che so... se faccio una chiamata ad un servizio, puo' andare male anche solo per questioni di rete o del momento in cui succede. Ma magari il servizio di per se e' su e non c'e' davvero un "baco" nel codice. Riprovo tutto e vado. Magari l'utente stesso e' disposto di tanto in tanto a ricaricare la pagina per aggiustare una situazione.</div><div class="gmail_extra"><br></div><div class="gmail_extra">E anche qui... e' diverso fare un servizio che "vendi" ad un'azienda il cui business ne dipende. Se "vendo" un servizio di billing per ecommerce e io sono giu', i miei clienti non possono fatturare. Non saranno tolleranti. Se fallisco una transazione su 100, non saranno contenti. Se a mia volta il mio servizio e' un ecommerce, gli stessi problemi sopra descritti possono volere dire meno vendite e meno soldi. Downtime vuole dire perdite monetarie quantificabili immediatamente. Non solo... non posso nemmeno facilmente testare il mio codice in produzione (ovvero, iniziare a deployare timidamente e sperare che funzioni tutto). Viceversa se sto facendo un servizio per condividere una bacheca di puttanate con i miei amici, posso: 1) fallire di tanto in tanto, inoltre, siccome molti fanno sta roba dal cellulare, potrebbero addirittura pensare che non sono io a fallire, ma che e' la connessione che e' singhiozzante; 2) testare feature su pochi clienti alla volta... posso anche convincerli di essere fortunati a starmi facendo da beta tester a gratis. Un celebre servizio di microblogging aveva problemi immensi di availability eppure si e' comunque espanso.</div><div class="gmail_extra"><br></div><div class="gmail_extra">Comunque a prescindere da quale situazione sia, in generale "non so chi sono i miei clienti". Ovvero sono tanti, continuano ad entrare e, potenzialmente, ad uscire. Mi possono abbandonare probabilmente con un costo limitato. La mia reputazione e' una cosa globale, invece: qualche post su twitter di persone chiave puo' crearmi grossissimi problemi. Tutti sanno chi sono (o per lo meno, tutti quelli che sono interessati al tipo di servizio che sto vendendo/proponendo).</div><div class="gmail_extra"><br></div><div class="gmail_extra">Se quello che fai e' invece offrire soluzioni "individuali" per clienti, e' un mercato ancora diverso. C'e' un rapporto piu' stretto. I tempi in qualche modo li da il cliente (mentre se faccio servizi web i tempi li da "il mercato" -- se siamo i secondi a rilasciare questa feature abbiamo perso la battaglia -- oppure essere quasi interno -- rilascio questa feature quando e' pronta, o ancora, rilascio tutte le settimane, ma includo nel rilascio solo quello che e' pronto). E poi dipendera' di volta in volta come vengono fatti deployment, aggiornamenti, new release; se le macchine sono mie o del cliente, quanta gestione ho sulle macchine, etc etc etc.</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br></div><div class="gmail_extra">Questo solo per dire che siccome i modelli di business sono davvero diversi, non e' affatto detto che una strategia completamente accettabile in una situazione sia completamente suicida in un'altra.</div><div><br></div><div><br></div>-- <br><div> .<br>..: -enrico-</div>
</div></div>