Baruch Sadogursky è Developer Advocate presso JFrog, coautore del libro "Liquid Software", noto relatore IT.
In un'intervista, Baruch ha raccontato come si prepara per i rapporti, in che modo le conferenze straniere differiscono da quelle russe, perché i partecipanti vanno da loro e perché dovrebbero parlare con un costume da rana.
Iniziamo con il più semplice. Cosa ne pensi, perché parlare alle conferenze?
In realtà parlare alle conferenze è un lavoro per me. Se rispondi in modo più globale alla domanda "Perché il mio lavoro?", allora questo è per (almeno per JFrog) raggiungere due obiettivi. In primo luogo, stabilire un contatto con i nostri utenti e clienti. Cioè, quando parlo alle conferenze, sono disponibile in modo che tutti coloro che hanno domande, qualche tipo di feedback sui nostri prodotti e aziende possano parlare con me, posso in qualche modo aiutarli e migliorare la loro esperienza nel lavorare con i nostri prodotti.
In secondo luogo, è necessario aumentare la brand awareness. Cioè, se dico alcune cose interessanti, allora le persone sono interessate a che tipo di JFrog sia, e di conseguenza cade nella nostra canalizzazione delle relazioni con gli sviluppatori, che alla fine va nella canalizzazione dei nostri utenti, che alla fine entra nella canalizzazione dei nostri clienti.
Dicci, per favore, come ti prepari per le esibizioni? Esiste un algoritmo di addestramento?
Ci sono quattro fasi di preparazione più o meno standard. Il primo è l'inizio, come nei film. Ci deve essere qualche idea. Appare un'idea, e poi matura per un bel po' di tempo. Matura, pensi a come presentare al meglio questa idea, in quale chiave, in quale formato, cosa si può dire al riguardo. Questa è la prima fase.
La seconda fase è la stesura di un piano specifico. Hai un'idea e inizia a trasformarsi in dettagli su come la presenterai. Di solito questo viene fatto sotto forma di una sorta di mappa mentale, quando tutto ciò che riguarda il rapporto appare attorno all'idea: argomentazioni di supporto, un'introduzione, alcune storie che vuoi raccontare al riguardo. Questa è la seconda fase: il piano.
La terza fase è scrivere diapositive secondo questo piano. Usi alcune idee astratte che appaiono sulle diapositive e supportano la tua storia.
La quarta fase sono le prove, le prove. In questa fase, è importante assicurarsi che l'arco della storia sia andato a buon fine, che la storia sia coerente, per assicurarsi che tutto vada bene nel tempo. Successivamente, il rapporto può essere dichiarato pronto.
Come capisci che "questo argomento" deve essere affrontato? E come si raccoglie il materiale per i report?
Non so come rispondere, in qualche modo viene da sé. O è "Oh, che bello l'abbiamo fatto qui", o è "Oh, nessuno in giro lo sa o lo capisce davvero" e c'è un'opportunità per raccontare, spiegare e aiutare. Una di queste due opzioni.
La raccolta del materiale dipende molto dal rapporto. Se questo è un rapporto su un argomento astratto, allora è più letteratura, articoli. Se questo è qualcosa di pratico, sarà scrivere codice, alcune demo, trovare i pezzi di codice giusti nei prodotti e così via.
La paura delle esibizioni e l'ansia sono uno dei motivi più comuni per cui le persone non salgono sul palco. Hai qualche consiglio per chi si innervosisce mentre si esibisce? Sei preoccupato e come stai affrontando?
Sì, ce l'ho, dovrebbe essere, e, probabilmente, nel momento in cui smetto di preoccuparmi, questo è un motivo per chiudere la questione.
Mi sembra che questo sia un fenomeno del tutto normale quando sali sul palco e ci sono molte persone davanti a te. Sei preoccupato perché è una grande responsabilità, è naturale.
Come affrontarlo? Ci sono modi diversi. Non l'ho mai avuto a un livello tale da dover combattere direttamente, quindi è difficile per me dirlo.
La cosa più importante, che aiuta anche me, è una faccia amica, una specie di faccia familiare tra il pubblico. Se chiedi a qualcuno che conosci di venire alla tua presentazione, siediti in prima fila al centro in modo da poterlo sempre guardare, e la persona sarà positiva, sorriderà, annuirà, sosterrà, penso che questo sia un enorme, grande aiuto. . Non chiedo specificamente a nessuno di questo, ma se capita che ci sia un volto familiare tra il pubblico, aiuta molto, allevia lo stress. Questo è il consiglio più importante.
Parli molto alle conferenze russe e internazionali. Vedi la differenza tra i rapporti alle conferenze russe e straniere? C'è differenza nel pubblico? Nell'organizzazione?
Vedo due grandi differenze. È chiaro che le conferenze sono diverse sia in Russia che all'estero, ma se prendiamo la media per un ospedale, allora in Russia le conferenze sono più tecniche in termini di profondità dei rapporti, in termini di hardcore. Questo è ciò a cui le persone sono abituate, forse grazie a conferenze importanti come Joker, JPoint, Highload, che sono sempre state basate su discorsi hardcore. Ed è quello che la gente si aspetta dalle conferenze. E per molte persone questo è un indicatore del fatto che questa sia una conferenza buona o cattiva: c'è molta carne e hardcore o c'è molta acqua.
Ad essere onesti, forse perché parlo molto alle conferenze estere, non sono d'accordo con questo approccio. Credo che i rapporti sulle competenze trasversali, i "rapporti semi-umanitari", non siano da meno, e forse anche più importanti per le conferenze. Perché alcune cose tecniche alla fine possono essere lette nei libri, puoi capire il manuale dell'utente, ma per quanto riguarda le competenze trasversali, come per la psicologia, come per la comunicazione, non c'è nessun posto dove portare tutto questo, almeno facile, accessibile e comprensibile. Mi sembra che questo non sia meno importante della componente tecnica.
Ciò è particolarmente importante per le conferenze DevOps come DevOpsDays perché DevOps non riguarda affatto la tecnologia. DevOps riguarda solo la comunicazione, si tratta solo di modi per lavorare insieme a persone che non hanno mai lavorato insieme prima. Sì, c'è una componente tecnica, perché l'automazione è fondamentale per DevOps, ma questa è solo una di queste. E quando una conferenza su DevOps, invece di parlare di DevOps, parla di affidabilità del sito o di automazione, o di pipeline, allora questa conferenza, nonostante sia molto hardcore, secondo me, perde solo l'essenza stessa di DevOps e diventa conferenze sull'amministrazione del sistema, non su DevOps.
La seconda differenza è nella preparazione. Ancora una volta, sto prendendo le medie ospedaliere e i casi generali, non i casi individuali. All'estero, procedono dal fatto che la maggior parte delle persone ha seguito una formazione nel parlare in pubblico nella propria vita. Almeno in America, fa parte dell'istruzione superiore. Se una persona si è laureata al college, ha già molta esperienza nel parlare in pubblico. Pertanto, dopo che il comitato del programma ha esaminato il piano e compreso di cosa tratterà il rapporto, non viene più effettuata alcuna formazione per parlare per l'oratore, perché si ritiene che, molto probabilmente, sappia già come farlo.
In Russia, tali ipotesi non vengono fatte, perché poche persone hanno esperienza di parlare in pubblico e quindi gli oratori sono formati molto di più. Ancora una volta, in generale, ci sono esercitazioni, ci sono lezioni con relatori, ci sono corsi di parlare in pubblico per aiutare i relatori.
Di conseguenza, gli oratori deboli che non parlano bene vengono eliminati o aiutati a diventare oratori più forti. Il fatto che in Occidente parlare in pubblico sia considerata un'abilità che molti hanno, alla fine, fa l'effetto opposto, perché spesso questo presupposto si rivela falso, errato, e le persone che non sanno parlare in pubblico con franchezza rovinare sul palco e ottenere rapporti disgustosi. E in Russia, dove si ritiene che non ci sia esperienza nel parlare in pubblico, alla fine risulta molto meglio, perché sono stati formati, sono stati testati, hanno scelto quelli buoni e così via.
Ecco le due differenze.
Sei stato a DevOpsDays in altri paesi? In cosa pensi che differiscano dalle altre conferenze? Ci sono caratteristiche?
Probabilmente sono stato a diverse dozzine di conferenze DevOpsDays in tutto il mondo: in America, in Europa e in Asia. Questo franchising di conferenze è piuttosto unico in quanto ha un formato più o meno consolidato che puoi aspettarti ovunque da una qualsiasi di queste conferenze. Il formato è questo: ci sono relativamente pochi resoconti di conferenze frontali e molto tempo è dedicato al formato degli spazi aperti.
Gli spazi aperti sono un formato in cui l'argomento per il quale le persone hanno votato di più viene discusso insieme ad altri partecipanti. Colui che ha proposto questo argomento è il leader, si assicura che la discussione abbia inizio. Questo è un ottimo formato, perché, come sappiamo, la comunicazione e il networking non sono una parte meno importante di qualsiasi conferenza rispetto ai rapporti. E quando una conferenza dedica metà del suo tempo a un formato di networking, è molto bello.
Inoltre, durante i DevOpsDays si tengono spesso i Lightning Talks: si tratta di brevi report di cinque minuti che ti consentono di imparare molto e aprire gli occhi su alcune cose nuove in un formato non noioso. E se nel bel mezzo di un rapporto regolare ti sei reso conto che non era per te, allora il tempo è perso, 30-40 minuti della tua vita sono andati, allora qui stiamo parlando di rapporti per cinque minuti. E se non sei interessato, presto sarà finita. "Dicci, ma velocemente" è anche un ottimo formato.
Ci sono DevOpsDay più tecnici, ci sono quelli che sono fatti su misura per ciò che è DevOps: processi, collaborazione, cose del genere. Entrambi sono interessanti, ed è interessante quando ci sono entrambi. Penso che questo sia uno dei migliori franchise di conferenze DevOps oggi.
Molte delle tue esibizioni sono come spettacoli o spettacoli: o racconti un rapporto sotto forma di tragedia greca, o sei nel ruolo di Sherlock, o ti esibisci in un costume da rana. Come ti vengono in mente? Ci sono altri obiettivi oltre a rendere il report non noioso?
Mi sembra che la relazione non abbia il diritto di essere noiosa, perché, in primo luogo, spreco il tempo degli ascoltatori, sono meno coinvolti in una relazione noiosa, hanno imparato meno, hanno imparato meno cose nuove, e questo non è il massimo spreco del loro tempo. In secondo luogo, anche i miei obiettivi non vengono raggiunti: non pensano niente di buono su di me, non pensano niente di buono su JFrog, e per me questo è una specie di fallimento.
Pertanto, i rapporti noiosi non hanno il diritto di esistere, almeno per me. Cerco di renderli interessanti, attraenti e memorabili. Le performance sono a senso unico. E, in effetti, il metodo è abbastanza semplice. Tutto ciò che serve è trovare un formato interessante e poi mettere gli stessi pensieri che vengono presentati sotto forma di un rapporto regolare in un formato insolito.
Come mi viene in mente questo? Non è sempre lo stesso. A volte queste sono alcune idee che mi vengono in mente, a volte queste sono alcune idee che mi vengono date quando organizzo corse o condivido pensieri sul rapporto e mi dicono: "Oh, puoi farlo così!" Succede diversamente. Quando viene fuori un'idea, è sempre molto gioiosa e interessante, il che significa che puoi fare un rapporto più interessante e coinvolgente.
Quali prestazioni della sfera IT ti piacciono personalmente? Ci sono tali altoparlanti? E perché?
Ci sono due tipi di oratori i cui discorsi mi piacciono. Il primo sono gli altoparlanti, a cui cerco di assomigliare. Raccontano storie in modo interessante e coinvolgente, cercando di assicurarsi che tutti siano interessati e che tutti ascoltino.
Il secondo tipo di relatori sono quelli che sono in grado di raccontare in modo molto interessante ed eccitante qualsiasi hardcore solitamente noioso.
Dei nomi nella seconda categoria, questo è Alexey Shepelev, che parla di una sorta di raccolta dei rifiuti ad alte prestazioni e degli interni di una macchina virtuale Java in un modo interessante e divertente. Un'altra scoperta dell'ultimo DevOops è Sergey Fedorov di Netflix. Ha raccontato una cosa puramente tecnica, come hanno ottimizzato la loro rete di distribuzione dei contenuti, e l'ha raccontata in un modo molto interessante.
Dalla prima categoria - questa è Jessica Deen, Anton Weiss, Roman Shaposhnik. Questi sono gli oratori che raccontano storie interessanti, con umorismo, e meritatamente ricevono voti alti.
Probabilmente hai più inviti a parlare alle conferenze di quanti ne hai il tempo. Come scegli dove andare e dove no?
Conferenze e relatori, come quasi tutto il resto, sono governati dai rapporti di mercato della domanda e dell'offerta e dal valore dell'uno rispetto all'altro. Ci sono conferenze che, diciamo, mi vogliono più di quanto io ne abbia bisogno. In termini di pubblico che mi aspetto di incontrare lì e di impatto che mi aspetto di avere lì. Ci sono conferenze a cui, al contrario, voglio partecipare molto più di quanto abbiano bisogno di me. In base al valore per me, decido dove andare.
Cioè, se questo è, ad esempio, un qualche tipo di geografia in cui devo strategicamente andare, questa è una grande conferenza ben nota che ha una buona reputazione e alla quale le persone andranno, allora, ovviamente, ne ho davvero bisogno. E lo preferirò ad altre conferenze.
Se questa è una specie di piccola conferenza regionale e, forse, dove non siamo molto interessati, allora potrebbe essere che un viaggio lì non giustifichi il tempo dedicato a questo argomento. Normali rapporti di mercato di domanda, offerta e valore.
Buona geografia, buona demografia, contatti potenzialmente buoni, comunicazione sono la garanzia che la conferenza sarà di mio interesse.
In una delle tue interviste, hai detto che parli a una quarantina di conferenze all'anno. Come riesci a lavorare e prepararti per le esibizioni? E riesci a mantenere l'equilibrio tra lavoro e vita privata con un programma del genere? Condividere i tuoi segreti?
Viaggiare per le conferenze è la parte del leone del mio lavoro. Certo, c'è tutto il resto: c'è la preparazione per i rapporti, mantenersi in forma tecnica, scrivere codice, imparare cose nuove. Tutto questo si fa in parallelo con i convegni: la sera, in aereo, il giorno prima, quando sei già arrivato al convegno, ed è domani. Qualcosa come questo.
È difficile, ovviamente, mantenere un equilibrio tra lavoro e vita privata quando si ha così tanto tempo per i viaggi di lavoro. Ma cerco di compensare con il fatto che, almeno quando non sono in viaggio di lavoro, sono al 100% con la mia famiglia, non rispondo alle mail la sera, cerco di non partecipare a nessuna telefonata la sera e nei fine settimana. Quando non sono in viaggio d'affari ed è tempo di famiglia, è davvero tempo di famiglia al 100%. Funziona e risolve il problema? NO. Ma spero che in qualche modo compensi la mia famiglia per tutto il tempo che sono via.
Con un calendario così serrato, riesci a mantenere un livello tecnico o ti sei già allontanato dalla programmazione?
Cerco di fare alcune cose tecniche mentre mi preparo per i miei discorsi e altre attività alla conferenza. Questi sono tutti i tipi di demo tecniche, una sorta di mini-report che teniamo sugli spalti. Non è programmazione-programmazione, è più integrazione, ma è almeno un lavoro tecnico che cerco di fare. In questo modo, mantengo la conoscenza dei nostri prodotti, delle nuove funzionalità e così via.
Ovviamente, dire che ora sono lo stesso programmatore hardcore che ero 7 anni fa è probabilmente impossibile. Non sono sicuro se questo è un male. Probabilmente una sorta di evoluzione naturale. Questo è meno interessante per me e c'è meno tempo, quindi, probabilmente, Dio lo benedica.
Mi considero ancora un forte specialista tecnico, sono ancora consapevole di ciò che sta accadendo, mi tengo in buona forma. Questa è la mia attuale situazione ibrida.
Raccontaci un paio di storie divertenti o situazioni estreme che ti sono capitate: hai perso l'aereo / cancellato la presentazione / tagliata l'elettricità durante il rapporto / bagagli non arrivati?
Tra le situazioni divertenti, ricordo soprattutto tutti i tipi di fallimenti da incubo accaduti ai rapporti. Naturalmente, perché questa è la situazione più stressante, perché questo è il pubblico, il tempo e devi assicurarti che non lo sprechino invano.
Durante il discorso ho avuto una "schermata blu della morte" sia su Windows che su Mac. Su Windows è successo una volta, su Mac un paio di volte. Questo, ovviamente, è stressante, ma in qualche modo risolviamo questo problema, il computer si riavvia, continuo a raccontare qualcosa in questo momento, ma lo stress è enorme.
Probabilmente la situazione più divertente che abbia mai avuto è stata a una conferenza Groovy. Non ricordo esattamente dove si tenne la conferenza, penso che fosse in un hotel, e di fronte a questo hotel erano in corso lavori di costruzione o ristrutturazione. E quindi stavo parlando di un codice che ho scritto, era una demo. Questa è stata la prima iterazione di una demo comprensibile ma forse non ben scritta. E stavo solo per refactoring e migliorarlo, e ho menzionato alcune frasi come "autoironico" sul fatto che questo è "codice di merda". Era al secondo piano e in quel momento la gru del cantiere di fronte stava solo sollevando una toilette portatile. E il palco era di fronte alla finestra. Cioè, guardo fuori da questa finestra, dico "codice di merda" e un gabinetto galleggia fuori dalla finestra. E dico a tutti: "Voltati, abbiamo un'illustrazione qui". Questa è stata probabilmente la migliore diapositiva dei miei pensieri: una toilette volante nel mio rapporto, quando ho parlato di codice di merda.
I bagagli non provengono da storie come questa: questa è, in linea di principio, una storia normale, non c'è nemmeno niente di cui parlare. Possiamo organizzare un'intervista separata su tutti i tipi di consigli di viaggio, in cui puoi parlare del bagaglio che non è arrivato, ma non c'era nulla di critico.
Mi sforzo molto di arrivare sempre in volo, di venire ed essere presente a tutte le conferenze che ho promesso, perché, ancora una volta, è il momento delle persone. Il tempo delle persone non ha prezzo, perché è un tale credito di fiducia che ti danno. E se questo prestito viene sperperato, non c'è modo di riaverlo in seguito.
Se una persona ha trascorso del tempo, è venuta alla conferenza per ascoltare il mio rapporto, e io l'ho preso e non sono venuto, questo è un male, perché non c'è modo di restituire il tempo a questa persona. Pertanto, è estremamente importante per me mantenere tutte le mie promesse al riguardo, e finora tutto sta funzionando.
Molte persone la pensano in questo modo: “Perché andare alle conferenze? Puoi guardare il video su YouTube e puoi sempre chattare online. Perché pensi che i partecipanti debbano partecipare alle conferenze?
Ottima domanda! Devi andare alle conferenze per motivi di networking. Non ha prezzo e non c'è altro modo per ottenerlo. Ho già accennato all'importanza della comunicazione, della comunicazione e delle competenze trasversali. Guardare un video su YouTube, purtroppo, non dà esperienza nelle competenze trasversali. Pertanto, si dovrebbe andare alle conferenze per motivi di comunicazione.
Inoltre, almeno per me, quando guardo i video su YouTube, il coinvolgimento è completamente diverso e il materiale arriva e viene ricordato molto peggio. Forse è puramente per me, ma sospetto che essere in sala a un servizio e guardare un video su YouTube siano cose completamente diverse. Soprattutto se il rapporto è buono, penso che sia molto, molto meglio ascoltarlo dal vivo. È come ascoltare un concerto dal vivo e un disco.
E lo ripeto ancora una volta: il networking e la comunicazione non si prendono da YouTube.
Puoi per favore dare alcune parole di commiato a coloro che stanno per diventare oratori o hanno appena iniziato a parlare?
Cerca incontri locali. I meetup locali sono un ottimo modo per iniziare la tua carriera di relatore per diversi motivi. In primo luogo, i meetup locali sono sempre alla ricerca di relatori. Può darsi che senza esperienza e senza essere un eminente relatore, ti sarà difficile candidarti a qualche noto convegno, oppure il comitato di programma, dopo aver parlato con te, capirà che forse è un po' troppo presto per te. Al contrario, i meetup locali sono sempre alla ricerca di relatori e la barra di ingresso è molto, molto più bassa, quindi è molto più facile arrivarci.
Inoltre, il livello di stress è completamente diverso. Quando vengono 10-15-30 persone, non è affatto come quando ci sono 150-200-300 persone in sala, quindi è molto più facile.
Ancora una volta, i costi per un meetup locale sono molto più bassi: non devi volare da nessuna parte, non devi passare giorni, puoi venire solo la sera. Ricordando il mio consiglio sull'importanza di avere una faccia amica tra la folla, è molto più facile venire a un incontro locale con qualcuno perché non costa denaro. Se parli a una conferenza, tu come relatore vieni gratis, ma questo tuo +1, che sarà una faccia amica nel pubblico, deve comprare un biglietto. Se ti esibisci a un meetup, non ci sono problemi del genere, puoi portare con te uno o due o tre amici che saranno una faccia amica nella sala.
E un ulteriore vantaggio è che gli organizzatori di meetup hanno molte più opportunità di aiutarti. Perché gli organizzatori di conferenze avranno, ad esempio, 60 relazioni che devono essere riviste, praticate e preparate. E gli organizzatori dei meetup ne hanno uno, due o tre, quindi, naturalmente, ti verrà prestata molta più attenzione.
Inoltre, è molto più facile ottenere feedback dai meetup locali. Hai finito il tuo rapporto e ora tu e il pubblico state già comunicando e discutendo qualcosa relativo al vostro rapporto. Per le grandi conferenze, spesso non è così. Hai fatto una denuncia e basta. Il pubblico che avevi come massa grigia durante il reportage se n'è andato, e non ne sai più niente, non senti, non avrai nessun feedback.
Qualunque cosa si possa dire, i meetup locali sono un ottimo argomento in generale e per i principianti in particolare.
7 dicembre Baruch parlerà alla conferenza . Nel rapporto, Baruch analizzerà i veri errori che si verificano quotidianamente e ovunque durante l'aggiornamento del software. Ti mostrerà come diversi modelli DevOps si adattano a diversi scenari e come applicarli correttamente potrebbe salvarti.
In programma anche: Alexander Chistyakov (vdsina.ru), Mikhail Chinkov (AMBOSS), Roman Boyko (AWS), Pavel Selivanov (Southbridge), Rodion Nagornov (Kaspersky Lab), Andrey Shorin (consulente DevOps).
Vieni a conoscere!
Fonte: habr.com