Mercato: come saranno gestite le situazioni di fallimento del prodotto dopo un aggiornamento della build? - pagina 3
Ti stai perdendo delle opportunità di trading:
- App di trading gratuite
- Oltre 8.000 segnali per il copy trading
- Notizie economiche per esplorare i mercati finanziari
Registrazione
Accedi
Accetti la politica del sito e le condizioni d’uso
Se non hai un account, registrati
+1
Se questo è il concetto, non dovresti agitare i pugni.
Hai frainteso la "singolarità" dell'opzione. Era l'unico all'epoca in cui ne ho scritto. Ora c'è già una versione modificata e anche altre varianti. Il treno della "singolarità" è già partito. :)
OK, supponiamo che ogni opinione sia l'unica al momento in cui è stata scritta :) L'unico per l'autore del parere :) Ironia, naturalmente.
Il lavoro continua anche dopo che il prodotto è stato messo sul mercato. E non ci vorrà molto per testarlo su una nuova build.
Siete sicuri che tutti scrivono programmi con tutti i moduli in uso tutto il tempo e immediatamente? E che nessuno ha moduli che vengono inseriti una volta ogni due settimane o una volta al mese. Con questo tipo di codice, i bug possono non essere scoperti "man mano" subito, ed è dai clienti.
OK, supponiamo che ogni opinione sia l'unica nel momento in cui viene scritta :) L'unico per l'autore del parere :) Ironia, naturalmente.
Siete sicuri che tutti scrivono programmi, tutti i moduli dei quali sono usati costantemente e immediatamente? E che nessuno ha moduli che vengono inseriti ogni quindici giorni o ogni mese. In un codice del genere, i bug possono essere rilevati "in corso d'opera" lontano da subito, e dai clienti.
La decisione sarà presa dagli sviluppatori del terminale di trading. Prima di realizzarlo, considereranno la questione da così tanti punti di vista che noi non potremmo nemmeno sognare. Alla fine, tutto può rimanere com'è. :)
Avete qualche variante di soluzione di questa domanda? O quale delle opzioni proposte pensate sia più vicina a quello che dovrebbe essere?
Vi ho dato un esempio di ciò che un acquirente leggerebbe se ci fossero le parole NESSUNA RESPONSABILITÀ nella frase.
Nel caso, lasciate che vi ricordi che la percezione umana è selettiva. Un fatto noto del cinema: se il film non interessa il pubblico nei primi 20 minuti, allora può essere qualsiasi cosa, qualsiasi acrobazia sconcertante e in generale la bellezza celestiale, ma il cinema in questo momento è vuoto, controllare questa bellezza nessuno.
Lo stesso vale per le vendite, il noto nel nostro paese marchio Zhiguli, in Italia ha dovuto essere rinominato Lada, in quanto ricorda molto gigolo, beh, che tipo di vendite ci possono essere se un acquirente arriva e gli viene offerta una "macchina moderna molto cool" con il nome gigolo :) poi come cavalcarlo che? Posso immaginare le esclamazioni eccitate degli italiani, guarda, guarda, è arrivato un gigolò :)
È solo sorprendente che la maggior parte di loro veda il problema solo da un lato. E da un argomento all'altro. Lasciatemi spiegare un caso specifico.
C'era un autore del programma, c'era il programma, c'era un cliente. Il programma ha funzionato bene per un po', ma poi un bug in MQ lo ha fatto smettere di funzionare. Cos'è una conclusione imparziale? - Questo è corretto, se MQ era la fonte del problema, è responsabile, e i problemi dovrebbero essere affrontati da quella prospettiva. Cosa fa la maggior parte delle persone? - Cominciano, in un modo o nell'altro, a dividere i doveri e gli interessi dell'autore e dell'acquirente, e propongono variazioni in base alla relazione tra l'autore e l'acquirente. In altre parole, si lasciano alle spalle la ragione. Per risolvere un problema e offrire varianti è necessario procedere dalla ragione di un argomento, invece che dalle conseguenze della ragione per l'autore e il compratore...
Clausola speciale: nessuna deviazione dal tema.
Yedelkin, smetti di mescolare la discussione sulla tua personalità e i suggerimenti sull'argomento nel tuo post.
Non ho la libertà di cancellare il tuo post nella sua interezza, ha frasi in tema. Né posso cancellare singole frasi di un post fuori tema.
Ti è già stato dato un avvertimento: non girare l'argomento sulla tua personalità.
Avete qualche opzione per affrontare questo problema? O quale opzione pensate che si avvicini di più a quello che dovrebbe essere?
A giudicare dal numero di post, le accuse di trollaggine stanno per arrivare :)
... La prima opzione, come si dice "al volo", ha già dichiarato. Se pensate che una discussione costruttiva sia possibile solo se ci sono un mucchio di opzioni diverse - ora penserò. Anche se il vettore di pensiero indicato sopra.
Yedelkin, smetti di mescolare la discussione sulla tua personalità e i suggerimenti sull'argomento nel tuo post.
Non ho la libertà di cancellare il tuo post nella sua interezza, ha frasi in tema. Né posso cancellare singole frasi di un post fuori tema.
Ti è già stato dato un avvertimento: non girare l'argomento sulla tua personalità.
OK, io cancello il post "incasinato" che ho fatto, tu cancelli il post che ho citato e il post attuale. D'accordo?
Per quanto riguarda gli "avvertimenti" - sei stato tu a spostare il thread sulla mia identità. Anche se poi tu stesso hai cancellato quel post. Quindi non giochiamo al gioco dell'avvertimento.
Avete qualche opzione per affrontare questo problema? O quale opzione pensate che si avvicini di più a quello che dovrebbe essere?
Opzione 2. Se c'è il desiderio di formalizzare le relazioni secondo la legge russa, è necessario invitare esperti sulla parte 4 del Codice Civile della Federazione Russa per risolvere il problema. Vedi, per esempio, l'articolo 1296 del Codice Civile "Programmi per computer e banche dati create per ordine". Per come la vedo io, se l'acquirente ha iniziato a usare il programma, non c'è nulla da pretendere dal programmatore - tutti i reclami sono contro MQ come fonte di un possibile bug. Se MQ è in grado di respingere una tale richiesta è una questione che riguarda loro. ...Forse altri vedranno una soluzione diversa nel codice civile.
Opzione 3. L'acquirente del Marketplace non solo dovrebbe essere informato della disponibilità di una nuova build, ma allo stesso tempo "nello stesso flusso di informazioni" per rendere tale acquirente consapevole che questa build è approvata/non approvata dall'autore del programma. Se la build non è approvata dall'autore del programma - non permettere che questa build sia scaricata a livello di terminale sul computer dell'acquirente del Market (o non permettere che il programma del Market sia caricato con la nuova build). Questo si tradurrà in:
===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.
(c2) se l'autore non si impegna a mantenere il prodotto sul mercato quando vengono rilasciate nuove build
questo è il punto in questione.
le regole e anche ipoteticamente meta-citazioni non ha incluso una tale clausola nell'accordo di mercato. Questo implica che le nuove costruzioni non possono influenzare il funzionamento del prodotto MQL5. E non è così nei prodotti reali.
E questo è essenziale. Poiché le prestazioni del prodotto dopo il rilascio dipenderanno dagli sviluppatori, non dal programmatore mql.
questa è la clausola in questione.
nelle regole e anche ipoteticamente le meta-citazioni non hanno messo una tale clausola nell'accordo di mercato. Implica che le nuove costruzioni non possono influenzare il funzionamento del prodotto MQL5. E non è così nei prodotti reali.
E questo è essenziale.
Non ero a conoscenza di tali sottigliezze. Cioè, attualmente è MQ che (volente o nolente) ha assunto tutta la responsabilità in questa parte, vero?
Per quanto riguarda l'accordo, non è una fondazione in cemento armato, è soggetto a miglioramenti :) Se questo punto è così importante per gli autori dei prodotti - si dovrebbe porre l'accento anche su di esso per arrivare a una soluzione accettabile per entrambi.
Inoltre, gli avvocati civili hanno questo approccio... In poche parole: il produttore può dare la sua garanzia su una parte di alcuni obblighi e il negozio può integrare questa garanzia. Beh, ricordate Mvideo, per esempio? - Lì danno una garanzia di scambio gratuito per 2-3 anni per 100-200 dollari. Quindi, il punto è che il produttore del prodotto è responsabile solo per la parte degli obblighi che si è assunto, il negozio - per il resto.
Quindi, se fossi l'autore del programma, cercherei di usare la prima opzione, vale a dire: nella pubblicità il prodotto indicherebbe che è responsabile solo per "così e così", "così e così" e "così e così" (lista lunga). Ma non sono responsabile di "questo" (la lista breve). E se le regole del mercato rimangono invariate, allora la responsabilità del prodotto al di là dei doveri che copro sarà dell'amministrazione del negozio (perché le loro regole sono così).