Domanda:
Come posso evitare di essere "quello negativo" nel dare un feedback sulle statistiche?
user2390246
2017-01-16 23:53:45 UTC
view on stackexchange narkive permalink

I risultati vengono inviati a un gruppo di collaboratori biologici per il feedback. Commenti tornano dai membri anziani del gruppo circa le implicazioni dei risultati, possibili estensioni, ecc guardo i risultati e tendono a non essere buona la roba "big picture" (io sono un membro relativamente minore della squadra), ma sono abbastanza bravo con le statistiche (e questo è il mio ruolo principale), quindi guardo i dettagli.

A volte penso tra me e me "Non credo che queste conclusioni siano minimamente giustificate dai dati". Come faccio a dare un feedback onesto in un modo che non venire attraverso come eccessivamente negativo? che posso suggerire, approcci più valida alternativa, ma se quelli dare la risposta "E 'solo rumore", sono versando acqua fredda su tutto.

Forse considera che farà molto meno male venire da un collega piuttosto che da un recensore. Certo, non vi è alcuna garanzia che il documento venga assegnato a un revisore con una mentalità statistica, ma è comunque meglio migliorare il documento prima di provare a pubblicare. Se i risultati non sono supportati dalle statistiche, è probabile che vadano a pezzi sotto un ulteriore esame e non si vorrebbe costruire un programma di ricerca su una falsa scoperta.
Si applica anche quando si sostituisce "statistiche" con "scelta delle mappe di colori" ;-)
Le "parole magiche" per questo non sono "per favore" e "grazie" che hai imparato da bambino, ma "non capisco perché * blah blah blah *". Se ti piace la spiegazione che ottieni, la persona che le dà si sentirà bene per essere più intelligente di te, e se non ti piace, l'altro ragazzo ha iniziato il dibattito tecnico, non tu, e non l'hai mai * accusato * essere "sbagliato".
@alephzero Quando il mio supervisore dice * Non capisco perché fai X *, tendo a interpretarlo come * X è sbagliato *, ma probabilmente c'è un certo effetto di impostore in quell'interpretazione.
Come studente sul campo chiedi al professore di spiegare in modo più dettagliato il loro insegnamento in modo da acquisire comprensione. Come professore, chiedi allo studente di spiegare le loro risposte in modo che acquisiscano comprensione ...
A sostegno del commento di @alephzero's, nei corsi di pedagogia / comunicazione mi sono imbattuto nel termine messaggio I, che mi piace molto. Si tratta di: "Non capisco perché ..." vs. "Devi sbagliarti ...". Vedi qui per ulteriori informazioni: https://en.wikipedia.org/wiki/I-message
Cosa c'è di sbagliato in "Non credo che queste conclusioni siano realmente giustificate dai dati attualmente"?
@Trilarion Alcune persone hanno dedicato molte ore a formare quelle conclusioni e vengono respinte senza alcuna domanda su come (e perché) l'hanno fatto? Domanda "Come hai concluso la [rivendicazione] dai [dati]?" è molto meglio: mostri il nostro interesse per la comprensione, non per il rifiuto, e ti permette di capire perché la [affermazione] non è giustificata dai [dati].
@Crowley Sono d'accordo che chiedere è la tattica migliore, ma per me la differenza tra i due approcci è piuttosto piccola. Affermare la tua opinione usando sembra / potrebbe / potrebbe ... non è la stessa cosa di un rifiuto totale e quasi lo stesso come chiedere. Nel corso della conversazione potresti comunque essere costretto a formulare la tua opinione per poter procedere.
@Trilarion Se viene detto durante il giorno, 2 ore di discussione su quell'argomento e cercando di capirlo, è completamente diverso dall'affermare solo quella domanda.
@alephzero, pur mantenendo la stessa idea di base, potresti essere meno autoironico con ad es. "Non vedo come i dati supportino questa conclusione", o un po 'più fermamente con "Non vedo * che * i dati supportano quella conclusione".
Ero solo a una conferenza in cui il sacchetto di malloppo includeva una morbida palla di schiuma. Ci è stato detto che ogni volta che sentivamo che un presentatore stava dicendo cazzate, dovevamo lanciargli la palla. Puoi lanciare una palla al tuo collega?
Dodici risposte:
BarbalatsDilemma
2017-01-17 01:22:30 UTC
view on stackexchange narkive permalink

Suggerirei di avvicinarsi al tuo collega in modo umile e curioso (soprattutto visto che sei un membro junior del team). Se inizi la conversazione con "le tue conclusioni sono sbagliate ed ecco perché" imposterai un tono combattivo per il resto della riunione. Potrebbero esserci ragioni per cui hanno interpretato i dati nel modo in cui non sei a conoscenza.

Prova invece ad affrontare la situazione con qualcosa di simile a "Ho guardato i dati e sono giunto a questa interpretazione, posso mi spieghi la tua interpretazione? " Sei un ricercatore a pieno titolo, quindi junior o no la tua opinione dovrebbe essere valutata. Ma almeno con questo approccio indichi di essere aperto all'idea di sbagliare, e si spera che inizi una conversazione costruttiva in cui puoi discutere i meriti dell'analisi di tipo A rispetto al tipo B, ecc.

Sono venuto qui per interesse per questa domanda e questa risposta mi sembra sbagliata. Ho provato l'equivalente del paragrafo 2 e ho ottenuto come risposta alla domanda iniziale qualcosa di evidentemente infondato, in pratica una ripetizione dello stesso errore. Eppure cerco come evitare esattamente questo.
@Joshua l'idea è di iniziare la conversazione come ho suggerito, quindi prenderla da lì. Ad esempio, se dicono "Ho usato il metodo di Foo per risolvere il widget" e pensi che il metodo di Foo non si applichi a questa situazione, diglielo e guarda qual è la loro giustificazione. Non posso prevedere tutto ciò che accadrà nella conversazione, ma se la affronti con la mentalità giusta puoi discutere le tue divergenze di opinione finché non emerge la verità
Se non forniscono alcuna giustificazione per i metodi di analisi che hanno utilizzato e si rifiutano di discuterne con te, allora non c'è molto altro da fare. Dopotutto è la loro ricerca (a meno che tu non stia scrivendo un articolo con loro, nel qual caso il tuo nome è sopra così puoi spingere molto più forte per le risposte)
Dirk
2017-01-17 02:34:57 UTC
view on stackexchange narkive permalink

Si applicano regole generali per il feedback.

Eccone alcune:

  • Non è necessario criticare nessuno.
  • Attieniti ai fatti.
  • Descrivi, in particolare descrivi cosa pensi delle cose, ad esempio non scrivere "l'affermazione non è giustificata dai dati" ma "Non riesco a vedere come questo sia spiegato dai dati" (e probabilmente fornisco un esempio di qualche affermazione che trovi ugualmente "inspiegabile" dai dati).
  • Non essere negativo. Invece, dai un suggerimento per qualcosa di meglio.
  • Se non conosci un miglioramento, fai una domanda (ad esempio "Non sono riuscito a capire, come è stata tratta questa conclusione, potresti chiarire / fornire ulteriori spiegazioni" ).

Ultimo suggerimento: inserisci le tue critiche, cioè inizia con qualcosa di buono, finisci con qualcosa di buono e metti la carne in mezzo.

Google "regole di feedback" o "come fornire feedback", ma ci sono alcune regole / suggerimenti che potrebbero non essere applicabili ...)

Aggiungerei anche: sii aperto all'opinione degli altri e renditi conto che è possibile che ti sbagli, indipendentemente dal background e dalle qualifiche.
Devo contestare il penultimo punto ("Non essere negativo. Invece, dai un suggerimento per qualcosa di meglio"). Dire "Perché non provi X" quando intendi "Y non funziona" è molto confuso (sono stato su entrambe le estremità di questo scambio).
"Non riesco a vedere come questo sia spiegato dai dati" non è lo stesso di "l'affermazione non sembra essere giustificata dai dati"? L'uso di potrebbe, potrebbe, sembra, forse, ... dovrebbe essere sufficiente per indicare che anche tu potresti sbagliarti. Ovviamente non fa mai male essere il più educati possibile.
In qualità di ex biostatista, mi dispiace dire che questo * non * è il modo per affrontare questo problema. I progetti bio hanno molti soldi alle spalle, creando una pressione estremamente intensa per risultati positivi. Le cattive statistiche sono spesso il risultato del tentativo di "volere" un risultato positivo. Non essere negativo e mettere insieme le critiche è un modo sicuro per ignorare le tue intuizioni in queste situazioni.
Questa è una cattiva notizia dalla comunità dei biostatici (voglio dire, ignorare il feedback se è inserito o formulato in modo amichevole).
@Dirk: essere un biostatistico può essere molto difficile. Fare le cose correttamente non ti rende sempre molti amici, anche se dipende molto dal laboratorio.
@CharlesStaats Posso riferirmi a questo, "Perché non hai usato X?" può anche essere una domanda piuttosto difficile / che richiede tempo a cui rispondere se la persona che riceve il feedback non ha familiarità con X e il resto della configurazione è complesso. È più educato essere positivi, ma è un percorso molto più lungo verso il vero problema di "Y non funziona" o peggio ancora "Non dipendere da Y, nel tuo caso è un falso positivo perché ..." (Nota : Il mio campo è legato all'informatica)
Jeff
2017-01-17 02:52:39 UTC
view on stackexchange narkive permalink

Sarebbe bello se le statistiche riguardassero sempre la verità e ci fosse una risposta o un metodo giusto per ogni domanda. Tuttavia, semplicemente non è così, e molti elementi hanno spazio per il dibattito. Sono un economista e l'ho visto in prima persona in tre diverse aree.

Innanzitutto, ho svolto una ricerca empirica interdisciplinare in cui ho lavorato con un sociologo per un mentre. Mi ha colpito come le nostre supposizioni andassero in contrasto tra loro; alcune volte ho suggerito cose che erano completamente standard nel campo dell'economia, solo per scoprire che non riusciva a capire perché lo avremmo fatto in quel modo. Poi almeno tre volte è stato lui a proporre metodi standard in sociologia che io non riuscivo a capire.

In secondo luogo, sono passato al campo della ricerca politica . Vacca sacra, il settore politico fa cose con statistiche ed econometria che farebbero rotolare un econometrico nella sua tomba, mentre erano ancora in vita.

E poi è appena arrivato peggio, perché ho iniziato a lavorare insieme ad alcuni data scientist . Non inizierò nemmeno, se non per dire che hanno accettato come cose del tutto normali che mi hanno fatto rotolare me nella tomba.

Il mio scopo nel condividere i miei aneddoti è suggerire un approccio più umile di "Non penso che queste conclusioni siano minimamente giustificate dai dati". Offrire critiche, certamente, ma non essere la persona del dipartimento che è un pedante completo su ogni dettaglio statistico. I miei punti riguardavano principalmente ciò in cui mi imbattevo quando mi avventuravo al di fuori del mio campo, ma penso che la lezione sia ancora rilevante nel tuo campo primario. Sii particolarmente cauto riguardo alle cose a cui trovi obiezioni che sono, a prescindere, ampiamente utilizzate nel tuo campo.

Niente di tutto ciò significa che dovresti semplicemente ignorare le cose che trovi errate. Piuttosto, prova affermazioni come:

  • "Ho familiarità con l'utilizzo del metodo A come hai fatto tu qui. Le questioni sollevate in (qualche giornale, qualche anno) sembrano forse pertinenti, quindi potresti voler affrontare anche i loro punti qui."
  • " Cosa ti ha fatto decidere di utilizzare il metodo A rispetto al metodo B? Forse il metodo B sarebbe un buon controllo di robustezza? "
  • " Una o due righe su come hai verificato che i dati corrispondono al presupposto X potrebbero essere utili qui. "

In breve, affrontalo come se presumessi che loro sappiano cosa stanno facendo , quindi ponendo domande utili per portarli punti desiderati.

Essere un pedante completo è in realtà la cosa giusta da fare, specialmente. nelle statistiche. Ciò non significa essere un completo idiota. Significa che qualsiasi ipotesi aggiuntiva dovrebbe essere dichiarata e solo le affermazioni che derivano realmente dai dati e dai teoremi utilizzati sono valide. Anche quella leggera generalizzazione, che sembra davvero ragionevole, può essere solo un'ipotesi o una potenziale spiegazione (che vale comunque la pena includere in un articolo), ma non un risultato.
Penso che questa sia una buona risposta: in pratica, se i dati giustificano la conclusione ha una forte componente accademico-culturale. Ciò significa che puoi sembrare un idiota ignorante se entri nella stanza e presumi di avere ragione e tutti gli altri hanno torto. Ovviamente, se i dati giustifichino le conclusioni è * anche * una questione statistica. Quindi penso che l'obiettivo del PO dovrebbe essere quello di cercare di contribuire alla discussione sulla validità dei risultati in modo utile. (Sembra improbabile che il ruolo sarà quello di convincere il resto del gruppo a tornare al tavolo da disegno ...)
@dtldarek C'è una differenza tra essere pedanti ed essere accurati e corretti nel proprio lavoro. E poiché la domanda dell'OP era su come interagire al meglio con i suoi colleghi, è una differenza importante.
@Jeff Potrebbe fare un esempio che fa la distinzione tra essere pedante ed essere accurato? Uno a cui riesco a pensare è se verificare la validità di alcuni lavori ampiamente accettati su cui ci basiamo, ma in alcuni casi anche essere accurati significherebbe approfondire anche questo, quindi non ne sono sicuro. In particolare, se quel lavoro fa qualche presupposto implicito (ad esempio, altrimenti alcuni teoremi usati dagli autori non funzionano), allora dovremmo includere quell'assunzione nel nostro articolo (ad esempio, analogamente a [42], perché il Teorema 7 funzioni, assumiamo che XYZ). Se non lo fai, ottieni solo un mucchio di falsi risultati.
@dtldarek Pedantic è un termine peggiorativo. Implica, ad esempio, arroganza o superiorità nel tuo approccio.
@Jeff Mi trovo corretto. Sapevo che "pedante" è un termine peggiorativo, ma lo capivo come "_eccessivamente_ interessato al formalismo, all'accuratezza e alla precisione" (citato da Wikipedia) e questo era il mio significato inteso (ho detto di non essere un idiota). Solo ora ho verificato che c'è un altro significato che probabilmente è quello che intendevi (uno che fa una dimostrazione di apprendimento ostentato e arrogante; anche da Wikipedia, ma molti dizionari sono d'accordo).
In quanto "scienziato dei dati", questa risposta mi ha fatto ridere.
sessej
2017-01-18 23:44:40 UTC
view on stackexchange narkive permalink

"Se fossi un revisore ..."

Il modo più semplice per farlo è inquadrare la critica come qualcosa che un revisore vorrebbe sapere. In questo modo, ti stai posizionando come un giocatore di squadra molto prezioso, che protegge la squadra da un immaginario revisore avversario. Do spesso critiche come questa:

"se fossi un revisore, vorrei la prova che questo non potrebbe essere il risultato di [modello nullo X / ipotesi di modello violata Y]."

o

"Immagino che un revisore desideri [un controllo di robustezza] - eseguiamolo"

o

"se otteniamo un revisori in [sottocomunità accademica], probabilmente vorrebbero [qualche tecnica più rigorosa] "

Tutti amano odiare i revisori e anticipare tutte le cose orribili di cui si lamentano è generalmente visto come un contributo prezioso e utile . (Per inciso, è un buon esercizio anche porre queste domande a se stessi. È facile rimanere bloccati in una prospettiva sulla ricerca e può essere una buona abilità entrare in empatia con un lettore scettico.)

John Feltz
2017-01-17 00:07:37 UTC
view on stackexchange narkive permalink

La scienza riguarda la verità, non i sentimenti feriti. Se i dati non supportano la conclusione, dillo. Non stai facendo alcun favore a nessuno ballando intorno all'argomento.

Non so se ci sia la politica dell'ufficio o qualcos'altro coinvolto qui, o se questo è il tuo primo vero lavoro e hai problemi a trovare il tuo posto nella gerarchia. Fa parte del problema? Prova a parlare con uno dei collaboratori, faccia a faccia, e chiedi come sollevare le tue preoccupazioni in modo appropriato.

Solo perché "la scienza riguarda la verità, non i sentimenti feriti" non significa che dovresti ignorare i sentimenti degli altri solo perché pensi di avere ragione. La scienza riguarda anche la collaborazione e la cooperazione; cerca di lavorare con le persone, non contro di loro. Inoltre, l'OP vuole chiaramente dire loro che la loro interpretazione è sbagliata, vogliono solo presentarla in una luce il più costruttiva possibile. Se riesci a criticare la loro ricerca * ed * evitare che qualcuno si arrabbi, allora è un vantaggio per tutti
Un modo potrebbe essere quello di suggerire che la sezione sulle statistiche potrebbe essere fraintesa da un lettore di mentalità statistica. E, offriti di tenere un breve seminario sulle tecniche statistiche, utilizzando i vari documenti inviati come esempi di come descrivere le statistiche o fare le statistiche in modo chiaro e difendibile. Non essere lo scettico, insegna loro nel modo giusto.
@Jon Penso che, dato il contesto in cui l'OP è un junior e le persone con cui non sono d'accordo sono membri senior del gruppo, l'offerta di tenere un seminario per insegnare loro le statistiche potrebbe essere considerata piuttosto presuntuosa. Dovrebbe essere sufficiente per spiegare loro il tuo ragionamento, non dovresti assolutamente implicare che hanno bisogno di riapprendere le statistiche
La scienza riguarda la verità, ma la parola riguarda impressioni e sentimenti.
Peteris
2017-01-17 02:56:14 UTC
view on stackexchange narkive permalink

Aiutali a dimostrare la verità

Fai parte della loro squadra, quindi per non sembrare "troppo negativo", comportati come se fossi nella loro squadra: aiutali.

Per lavori in corso, una conclusione preliminare sarà spesso un'ipotesi che non è ancora completamente coperta dall'analisi o anche dai dati disponibili. "Non credo che queste conclusioni siano minimamente giustificate dai dati" sarebbe qualcosa che un revisore può ragionevolmente dire su un articolo finito. Tuttavia, non sei un revisore per questo e il documento non è finito: ciò che dovresti fare invece è usare la tua conoscenza delle statistiche e descrivere in termini molto specifici quali analisi e metriche sarebbero necessarie per supportare o negare adeguatamente l'ipotesi a cui si rivolgono.

È possibile che ciò richieda dati aggiuntivi. Può darsi che ciò richieda semplicemente un'analisi più approfondita. Può darsi che questa particolare ipotesi non possa mai essere verificata con il processo e il tipo di dati che stai raccogliendo, quindi devono esserci cambiamenti significativi - in ogni caso, è meglio iniziare a gestirla presto, invece di aspettare un formale recensione.

Penso che questa sia una buona risposta. Aggiungerò che ho avuto fortuna nel descrivere le mie obiezioni come potenziali obiezioni di un revisore. Qualcosa del tipo: "Allo stato attuale, penso che un revisore potrebbe dire X su Y. Penso che potremmo superare questa obiezione facendo Z."
"in modo da non apparire" troppo negativo "" Il modo per non apparire troppo negativo senza ignorare gli errori sarebbe: "Ehi, ho scoperto dei difetti nel progetto, ma spero che possiamo risolverli".
Jim
2017-01-17 02:29:55 UTC
view on stackexchange narkive permalink

Se il tuo ruolo principale è fornire una prospettiva statistica al processo di revisione, devi valutare. Immagina cosa accadrebbe se una recensione esterna per la pubblicazione tornasse con conclusioni negative che ci si sarebbe potuti aspettare di identificare in un revisione interna.

Politica a parte, presumo che i collaboratori vogliano i loro nomi su un giornale ben accolto e apprezzeranno il fatto che tu stia facendo uno sforzo per entrare nel vivo del lavoro con loro. Se inizi senza dare per scontato che qualcuno abbia commesso errori fondamentali o concettuali, farai in modo che ti ascoltino più facilmente.

Tieni presente che, in generale, quando non arrivi alla stessa conclusione a cui è venuto il tuo collega, potrebbe essere altrettanto probabile a causa di una scelta sbagliata nel modo in cui il materiale è stato presentato piuttosto che a un errore fondamentale nel pensiero. Ciò è particolarmente vero in una revisione interna prima della pubblicazione. Presumo che tu fornisca una serie di occhi che sono imparziali dall'essere stati sepolti nella produzione del documento e, come revisore, puoi trovare aree in cui la comunicazione dei concetti è stata interrotta, se questo è il caso .

Se possibile, dovresti concordare di discuterne con il collaboratore che è più vicino al problema che ti interessa. Quella persona dovrebbe essere già consapevole che hai esperienza in statistica. (In caso contrario, potrebbe essere necessario introdurre loro questo punto.) Potresti suggerire che questo potrebbe essere presentato in un modo a cui non sei abituato (che può essere vero o no) e che di conseguenza non sei stato in grado di disegnare le stesse conclusioni. Lascia che abbiano la possibilità di presentare il loro concetto mentre fai domande relative alla tua esperienza.

Se quella persona non è disponibile a discuterne, assicurati almeno di avergli comunicato che hai domande specifiche sulle statistiche e su come vengono presentate . Quindi prova a discuterne con uno degli altri collaboratori allo stesso modo. (Fallo in questo ordine per evitare qualsiasi obiezione che hai aggirato il collaboratore chiave sulla questione.)

StrongBad
2017-01-17 00:32:16 UTC
view on stackexchange narkive permalink

Come posso fornire un feedback onesto in un modo che non risulti eccessivamente negativo

Non essere eccessivamente negativo. Per una revisione interna, dovresti concentrarti sui punti di forza e di debolezza del manoscritto, non solo sui punti deboli. Ovviamente, vuoi che i tuoi colleghi sappiano cosa deve essere migliorato, ma è anche utile sapere quali sono i punti di forza degli altri.

Devi anche stare attento a come dici le cose. Invece di dire qualcosa come

Non credo che queste conclusioni siano minimamente giustificate dai dati

che considero molto negativi, potresti lasciare che il l'autore sa che non ti ha convinto delle conclusioni per i motivi x, yez.

Crowley
2017-01-18 20:59:13 UTC
view on stackexchange narkive permalink

tl; dr : non mirare a dimostrare la loro strada sbagliata; cerca invece di trovare la strada giusta.

Non trasformarti in un verificatore remoto o qualcosa del genere.

Se scrivi non credo che queste conclusioni siano minimamente giustificate dai dati. Stai affermando che il loro approccio è sbagliato. Periodo. Non è nemmeno necessario racchiuderlo in belle parole.

Posso leggere dalla tua domanda che sei stato assunto per migliorare l'utilizzo degli strumenti statistici nel tuo team. Fai il tuo lavoro.

  1. Non essere scortese.
    Esprimi le tue preoccupazioni e i tuoi punti senza deriderli o usare parole scortesi tec. Durante le chiacchiere puoi menzionare dove hai sbagliato, ecc. Alcune persone si offendono quando usi un linguaggio troppo educato e difensivo - vogliono fatti concreti, non tirandoli fuori da 2 ore di monolega. Alcune persone sono schiacciate da fatti privi di emozioni: hanno preso il loro lavoro sul personale. Cerca sempre di trovare qualcosa di giusto e menzionalo.
  2. Cerca di capire.
    Chiedi loro di spiegarti il ​​loro lavoro. Scoprirete tutti perché giungono a quella conclusione, che la conclusione è sbagliata, perché è sbagliata e potete suggerire un approccio diverso. Poni le domande appropriate: "Cosa significa ..." "Perché questo parametro è stato trascurato?"
  3. Aiutali.
    Suggerisci approcci e metodi diversi. Offri loro la tua assistenza con tali strumenti.
  4. Sii aperto.
    Sii pronto a dire che non hai ottenuto la loro immagine o che hai preso una conclusione sbagliata. A volte la discussione più approfondita rivela tutti i punti nascosti che mancavano nel testo, perché pensavano che "è facile da vedere", ma non lo è.

Dall'altro Tuttavia, se vuoi aiutarli a prepararsi per una conferenza, le domande e gli appunti più freddi e cattivi che hai, meglio saranno preparati per le domande reali del pubblico.

"Fai il tuo lavoro." A volte questo significa essere portatore di cattive notizie, se ad esempio si cerca di capire e finalmente si arriva alla conclusione che c'è davvero qualcosa di sbagliato che non può essere corretto. Comunicarlo sarebbe probabilmente un compito molto spiacevole.
@Trilarion Se dimostri perché hanno torto, è meno spiacevole che affermare che hanno torto. E offrire aiuto e assistenza migliorerà anche lo spazio di lavoro.
MonkeyZeus
2017-01-19 20:43:59 UTC
view on stackexchange narkive permalink

Salve Senior Member Bob,

Ho lavorato per migliorare le mie capacità di riconciliare i dati per trarre conclusioni accurate, ma continuo a rimanere bloccato alla conclusione XYZ per questo set di dati. Questo mi turba perché vedo che hai concluso QRS. Hai qualche minuto per mostrarmi come arrivare a QRS?

Ora, lascia parlare Bob e cerca di non intervenire. Se è professionale, vorrà ascoltarti su XYZ dopo che lo avrai ascoltato.

Questo è un classico esempio di "cerca prima di capire e poi di essere capito"

+1, ma penso che la prima clausola suoni un po 'forzata. OP non dovrebbe fingere di essere completamente all'oscuro. Che ne dici di "provare a trarre conclusioni XYZ dai dati come hai fatto tu, ma continuo a rimanere bloccato". ?
@einpoklum D'accordo, OP dovrebbe assolutamente modificarlo per adattarlo alla propria situazione e personalità. Volevo principalmente mostrare un modo non combattivo per convincere qualcuno a elaborare. Lavorando nell'IT, trovo che il semplice tentativo di convincere qualcuno a riprodurre il loro "problema" di fronte a me risolve il problema perché ha perso un passaggio, quindi ** SE ** OP è corretto e la conclusione QRS è sbagliata, si spera che venga scoperto mentre il membro anziano esprime il proprio processo di conclusione.
einpoklum
2017-01-20 04:22:29 UTC
view on stackexchange narkive permalink

Ho - sfortunatamente - scoperto che in molti casi le persone tendono a essere molto resistenti alle conclusioni che tu hai fatto e le stai offrendo, quasi universalmente, pur essendo molto più propense ad accettare esattamente le stesse conclusioni se dai loro la possibilità di fare gli ultimi passi retorici. In altre parole:

B è vero? Sì. Ciò è dovuto al fatto che A-> B e A.

probabilmente riceveranno risposte come:

  • "Come puoi dire qualcosa del genere? "
  • " Sei eccessivamente critico "
  • " Ecco di nuovo OP con le sue affermazioni stravaganti. "
  • " Tu sto solo dicendo che, perché C "
  • " Sei un terrorista / comunista / sciovinista, dovremmo espellerti / licenziarti "

mentre se tu scrivi, o dì, qualcosa come:

Quindi, ho pensato alla questione di B. Penso che il fatto che A sia qualcosa che dobbiamo prendere in considerazione.
. ..
Stavo parlando con X della domanda B e lei mi ha ricordato che A-> B vale. Penso che abbia un buon punto. Ma dove ci porta?

e poi ottieni:

  • "oh, oh, aspetta! Ho capito! B! B! Lo sapevo da sempre! "
  • " Sai, visto che siamo bloccati, proviamo ad assumere B e vediamo cosa succede. "
  • " Hmm, io supponiamo che B possa essere un'opzione "
  • " Ho sempre saputo che B, e l'ho detto sempre. "

tipo di risposte. Sembra stupido ma succede spesso quando B è qualcosa che non è facile da digerire - socialmente, psicologicamente, politicamente ecc.

Ora applica questo al tuo caso specifico :-)

Andrew B
2017-08-02 20:17:39 UTC
view on stackexchange narkive permalink

Sono stato su una barca simile (studente di dottorato che lavora con la facoltà), su un progetto a cui stavo lavorando. Stava lavorando con un collega con un background disciplinare diverso, con norme diverse su ciò che era considerato una prova convincente. Sulla base degli standard a cui ero abituato, non ero convinto dei risultati e non pensavo che lo sarebbero stati nemmeno revisori con background come il mio. Ho usato un po 'l'argomento del futuro revisore, ma dovevo anche dire che non ero ancora a mio agio a mettere il mio nome sulla carta - che avrei dovuto vedere X, Y e Z. Ho dovuto fare molte cose da solo. Una cosa che volevo sapere era se la selezione dei controlli avesse guidato i risultati (di uno studio d'archivio), poiché c'erano molti gradi di libertà per i ricercatori. Ho dovuto scrivere un programma per eseguire i modelli con ogni possibile combinazione di variabili di controllo per convincermi che non avevamo solo inconsciamente giocato con le combinazioni fino a quando non abbiamo ottenuto qualcosa che ci piaceva (in realtà ero sorpreso di quanto fossero robusti i risultati, anche se di certo che non è una prova, ma esclude una preoccupazione). Il mio coautore ha effettivamente proposto di aggiungere un esperimento allo studio, il che ha reso i risultati ancora più convincenti. Penso che niente di meno che esprimere il mio disagio nel mettere il mio nome sulla versione precedente avrebbe prodotto il risultato con cui ora mi trovo a mio agio.

Un'altra cosa che ho fatto, per darmi legittimità: ho dovuto imparare molto di più sui metodi che aveva applicato, il che non è stato facile. Alcuni dei comandi facevano parte di una macro ampiamente utilizzata (nel suo campo) che incorporava algoritmi basati su alcuni documenti di metodi più vecchi. Ho dovuto tornare indietro e leggere molti di quei documenti finché non ho capito cosa stavano facendo gli algoritmi (e sembrava qualcosa che potesse essere utile nel mio campo, con maggiore trasparenza). Era necessaria una comprensione dettagliata per esprimere il motivo per cui non ero ancora convinto. È facile dire: "Non ne sono convinto". È più convincente per gli altri se puoi spiegare quali fonti esplicite di pregiudizi esistono o quali presupposti specifici vengono violati.



Questa domanda e risposta è stata tradotta automaticamente dalla lingua inglese. Il contenuto originale è disponibile su stackexchange, che ringraziamo per la licenza cc by-sa 3.0 con cui è distribuito.
Loading...