Mercato: come saranno gestite le situazioni di fallimento del prodotto dopo un aggiornamento della build? - pagina 4

Nuovo commento
 
papaklass:

È dannatamente semplice.

Prima che una nuova build sia rilasciata, il MC dà agli sviluppatori di software i cui prodotti sono sul mercato un periodo di prova di una settimana. Questo è tutto.

Non è così semplice. Ho già riflettuto su questo problema all'inizio del thread. Ripeterò (ironicamente): non c'è niente di meglio per gli autori dei prodotti che passare settimane "gratuitamente" a testare ogni nuova build per i bugs....Se qualcuno vuole farlo in modo specifico allora va bene, ma non è molto carino mettere tutti nella stessa scala. Con questo approccio i programmatori professionisti che hanno abbastanza progetti in corso non saranno soddisfatti... O tutti loro dovranno mettere il prezzo della cattura dei bug in anticipo, alzando la soglia di disponibilità dei loro prodotti.
 
papaklass:

Durante questa settimana, la nuova build sarà disponibile solo per gli sviluppatori per testare il loro software su questa build. Se trovano dei bug, li segnaleranno a servicedeck. Dopo questa settimana di test, se l'MC decide che non ci sono bug gravi, una nuova build sarà ufficialmente rilasciata (disponibile per tutti).

È fottuto e stronzo. Soprattutto al ritmo con cui appaiono le costruzioni ora.

Il problema non è risolvibile, abbiamo solo bisogno di un posto dove l'utente può assolutamente scrivere normalmente "plea, non funziona!", lo sviluppatore prenderà comunque tutti gli intoppi.

 
papaklass:

Ancora una volta la preoccupazione non è per coloro che pagano il prodotto (servizio), ma per i poveri programmatori.

Lei ha cercato di occuparsi delle pecore e dei lupi allo stesso tempo. Ti ho semplicemente spiegato che c'è un grave difetto in questa logica. E cosa ha a che fare con il "prendersi cura dei poveri programmatori"? Soprattutto, se si considera che si è occupato solo delle pecore (continuando figurativamente il proprio pensiero).

...E il fatto che si proceda dalle condizioni esistenti non nega affatto la possibilità di cambiare/migliorare queste stesse condizioni.

 
papaklass:

Lei propone un sistema in cui l'acquirente dovrà pagare di nuovo tutto. Questo non è giusto.

No. Leggete attentamente. L'acquirente paga solo ciò che accetta di pagare. Paga sempre i termini che ha scelto, questo è sicuro.
 
C-4:

Tuttavia, il concetto di integrità non è contraddetto dall'avere una funzione di backup di rollback.

Non è contro il concetto di integrità se si fa il rollback di tutto: terminale, server, cloud e chissà cos'altro.
 
Yedelkin:

...

    ===I dettagli possono sempre essere chiariti/aggiunti. Ve lo dico subito: mi sono state chieste delle opzioni - le ho generate. Spero che l'idea sia chiara. Suggerito quello che mi è venuto in mente ora. Alle domande "come si immagina una tale implementazione" non può rispondere. Sicuramente non difendere le opzioni, sulla base di esperienza sfortunata.

    Quindi immediatamente. :) Qui ci sono più opzioni. C'è qualcosa su cui costruire (non noi). E l'esperienza non dovrebbe essere triste ma gioiosa. Anche se i momenti tristi a volte portano idee interessanti... In generale, bisogna gioire di tutto. )))
     
    Yedelkin:
    L'acquirente paga solo ciò che accetta di pagare. L'acquirente paga solo le condizioni che ha scelto, questo è sicuro.
    Mentre sognavo, mi è venuta questa idea successiva: ci sono almeno due versioni dello stesso prodotto sul mercato, con prezzi diversi. Questa versione, che è 2 volte più costosa, significa che il venditore garantisce il supporto di n-future builds. Versione più economica, ha la garanzia di funzionare con la build corrente, più la possibilità di pagare soldi extra al creatore per il tweaking alle nuove build (per controllare le nuove build). L'opzione più economica significa che l'acquirente deciderà se passare alla nuova costruzione per conto proprio "a proprio rischio e pericolo", o chiedere consiglio all'autore a pagamento.
     

    Cerchi costantemente di risolvere il problema dall'interno. Di conseguenza, si arriva a soluzioni che sono deliranti nell'attuazione.

    Il programmatore deve farlo?

    Non ce n'è uno. È andato a conquistare la taiga per tre mesi e a cacciare i taimen. E allora? Togliere la merce dagli scaffali? Su quali basi?

    Mettere una veglia permanente in attesa di una nuova legge? E il periodo di una settimana per catturare gli insetti? Non c'è più un programmatore, ora sarà un impiegato del Mercato.

    Inoltre, se uno dei venditori si unirà a questa schiavitù, la includerà nel costo delle merci. Ma il numero di vendite di questi beni scenderà a un livello che non è redditizio per i programmatori.

    Ci sono pochi venditori ora e ognuno ha una media di un prodotto. Ma bisogna mettere le cose in prospettiva. Quindi il venditore medio ha due dozzine e mezzo di prodotti. E allora? Avere il tempo di ripararlo in una settimana, per i soldi che ha ricevuto e speso molto tempo fa?

    L'acquirente non ha nulla a che fare con questo. Pagato, ricevuto. Deve funzionare. Deve funzionare. Il mercato dove gli utenti dovrebbero scrivere delle nuove costruzioni e degli EA che non funzionano, per ogni lettera del genere, ci saranno altre nove lettere che dicono che l'EA acquistato nel mercato ha prosciugato il deposito invece del milione previsto.

    Non ho suggerimenti, ma non dimenticare le leggi del mercato dei servizi.

     
    Mischek:

    Cerchi costantemente di risolvere il problema dall'interno. Di conseguenza, si arriva a soluzioni che sono deliranti da attuare.

    Una domanda chiarificatrice: questo messaggio è indirizzato a tutti i panelisti contemporaneamente (come una sorta di generalizzazione della tua comprensione della situazione), o a qualcuno in particolare?
     
    Yedelkin:
    Una domanda chiarificatrice: questo messaggio è indirizzato a tutti i panelisti contemporaneamente o a qualcuno in particolare?
    Tutti tranne te, per ridurre le chiacchiere
    1234567891011
    Nuovo commento