Baruch Sadogursky - Developer Advocate chez JFrog, co-auteur de Liquid Software, un conférencier informatique bien connu.
Dans une interview, Baruch a expliqué comment il se prépare pour les rapports, comment les conférences étrangères diffèrent des conférences russes, pourquoi les participants devraient y assister et pourquoi parler en costume de grenouille.
Commençons par le plus simple. Que pensez-vous, pourquoi même parler lors de conférences?
En fait, pour moi, parler lors de conférences est un travail. Si vous répondez plus globalement à la question «Pourquoi mon travail?», Alors c'est pour ça (au moins pour JFrog) afin d'atteindre deux objectifs. Premièrement, pour établir le contact avec nos utilisateurs et clients. C'est-à-dire que lorsque je parle lors de conférences, je suis disponible pour que tous ceux qui ont des questions, des commentaires sur nos produits et nos entreprises puissent me parler, je peux en quelque sorte les aider et améliorer leur expérience en travaillant avec nos produits.
Deuxièmement, il est nécessaire d'accroître la notoriété de la marque. Autrement dit, si je vous dis des choses intéressantes, les gens sont intéressés par le type de JFrog, et en conséquence, il entre dans notre entonnoir de relations avec les développeurs, qui finit par aller dans l'entonnoir de nos utilisateurs, qui finit par aller dans l'entonnoir de nos clients.
Dites-moi, s'il vous plaît, comment vous préparez-vous pour vos performances? Existe-t-il un algorithme de préparation?Il y a quatre étapes de préparation plus ou moins standard. Le premier est la création, comme dans un film. Une idée devrait venir. Une idée apparaît, puis elle mûrit assez longtemps. Il mûrit, vous pensez qu'il vaut mieux présenter cette idée, dans quelle veine, sous quel format, que dire de cela. Ceci est la première étape.
La deuxième étape consiste à rédiger un plan spécifique. Vous avez une idée, et elle commence à devenir des détails sur la façon dont vous la présenterez. Habituellement, cela se fait sous la forme d'une sorte de carte mentale, lorsque tout ce qui concerne le rapport apparaît autour de l'idée: arguments à l'appui, introduction, quelques histoires que vous voulez en dire. Ceci est la deuxième étape - le plan.
La troisième étape consiste à rédiger des diapositives pour ce plan. Vous utilisez des idées abstraites qui apparaissent sur les diapositives et soutenez votre histoire.
La quatrième étape est les runs, les répétitions. À ce stade, il est important de s'assurer que l'arche de l'histoire s'est bien déroulée, que l'histoire est connectée, pour s'assurer que tout est normal dans le temps. Après cela, le rapport peut être déclaré prêt.
Comment comprenez-vous que «ce sujet» doit être abordé? Et comment saisissez-vous du matériel pour les rapports?Je ne sais pas comment répondre, ça vient en quelque sorte. Ou c'est «Oh, comme c'est cool ici», ou c'est «Oh, personne ne le sait vraiment et ne le comprend» et il y a une opportunité de le dire, de l'expliquer et de l'aider. L'une de ces deux options.
La collecte de matériel est très dépendante du rapport. S'il s'agit d'un rapport sur un sujet abstrait, alors c'est plus de littérature, d'articles. Si c'est quelque chose de pratique, il s'agira d'écrire du code, des démos, de trouver les bons morceaux de code dans les produits, etc.
La performance de Baruch au récent DevOps Summit Amsterdam 2019La peur des performances et l'excitation sont quelques-unes des raisons les plus courantes pour lesquelles les gens ne montent pas sur scène. Pouvez-vous donner quelques conseils à ceux qui sont inquiets lors des représentations? Êtes-vous inquiet et comment gérez-vous?Oui, je l'ai, ça devrait l'être, et, probablement, au moment où j'arrête de m'inquiéter, c'est l'occasion de m'attacher à cette affaire.
Il me semble que c'est absolument normal quand tu montes sur scène et qu'il y a beaucoup de monde devant toi. Vous vous inquiétez car c'est une grande responsabilité, c'est naturel.
Comment y faire face? Il existe différentes manières. Je ne l'ai jamais eu à un niveau tel que je dois me battre directement, donc c'est difficile pour moi de le dire.
La chose la plus importante qui m'aide aussi est le visage amical - un visage familier dans le public. Si vous demandez à quelqu'un que vous connaissez de venir à votre rapport, de s'asseoir au premier rang au milieu afin que vous puissiez toujours le regarder, et la personne sera positive, sourira, hochera de tête, soutiendra, je pense que c'est une aide énorme, énorme . Je n’interroge spécifiquement personne à ce sujet, mais s’il arrive qu’il y ait un visage familier dans le public, cela aide beaucoup et soulage le stress. C'est le conseil le plus important.
Vous parlez beaucoup lors de conférences russes et internationales. Voyez-vous la différence entre les rapports des conférences russes et étrangères? Y a-t-il une différence d'audience? Dans l'organisation?Je vois deux grandes différences. Il est clair que les conférences sont différentes à la fois en Russie et à l'étranger, mais si nous prenons la moyenne pour l'hôpital, alors en Russie, les conférences sont plus techniques en termes de profondeur des rapports, en termes de hardcore. C'est ce à quoi les gens sont habitués, peut-être grâce à des conférences majeures comme Joker, JPoint, Highload, qui étaient toujours basées sur des présentations hardcore. Et les gens attendent des conférences exactement cela. Et pour beaucoup, c'est un indicateur de savoir si c'est une bonne ou une mauvaise conférence: il y a beaucoup de viande et de hardcore ou il y a beaucoup d'eau.
Pour être honnête, peut-être parce que je parle beaucoup lors de conférences à l'étranger, je ne suis pas d'accord avec cette approche. Je pense que les rapports sur les compétences générales, les «rapports semi-humanitaires» ne sont pas moins, et peut-être encore plus importants pour les conférences. Parce que vous pouvez lire certaines choses techniques dans les livres, vous pouvez comprendre le manuel d'utilisation, mais en ce qui concerne les compétences générales, en psychologie, en communication, il n'y a nulle part où tout prendre, au moins facile, accessible et compréhensible. Il me semble que ce n'est pas moins important que le volet technique.
Ceci est particulièrement important pour les conférences sur DevOps, telles que DevOpsDays, car DevOps n'est pas du tout une question de technologie. DevOps est juste une question de communication, il s'agit de façons de travailler ensemble pour des personnes qui ne travaillaient pas ensemble auparavant. Oui, il y a un composant technique, car l'automatisation est essentielle pour DevOps, mais ce n'est que l'un d'entre eux. Et lorsque la conférence DevOps, au lieu de parler de DevOps, parle de fiabilité ou d'automatisation du site, ou de pipelines, cette conférence, malgré le fait qu'elle soit très hardcore, à mon avis, manque simplement l'essence même de DevOps et devient des conférences sur l'administration système, pas sur DevOps.
La deuxième différence est en préparation. Encore une fois, je prends la moyenne pour l'hôpital et les cas généraux, pas les cas privés. À l'étranger, on suppose que la plupart des gens ont suivi une formation de prise de parole en public au cours de leur vie. Au moins en Amérique, il fait partie de l'enseignement supérieur. Si une personne est diplômée de l'université, elle possède déjà une expérience considérable de la prise de parole en public. Par conséquent, après que le comité de programme eut examiné le plan et compris le contenu du rapport, il n'y a plus de formation sur les discours pour l'orateur, car on pense qu'il sait très probablement comment.
En Russie, de telles hypothèses ne sont pas formulées, car peu de personnes ont de l'expérience en prise de parole en public, et donc les locuteurs sont beaucoup plus formés. Encore une fois, dans le cas général, il y a des courses, il y a des cours avec des conférenciers, il y a des cours de prise de parole en public pour aider les conférenciers.
Par conséquent, les locuteurs faibles qui parlent mal, sont exclus ou sont aidés à devenir des locuteurs plus forts. Le fait qu'en Occident, parler en public est considéré comme une compétence que beaucoup ont en conséquence obtient l'effet inverse, car cette hypothèse se révèle souvent fausse, erronée et les personnes qui ne savent pas parler en public se trompent ouvertement sur scène et reçoivent des rapports dégoûtants. Et en Russie, où l'on pense qu'il n'y a pas d'expérience en matière de prise de parole en public, le résultat est bien meilleur, car ils ont été formés, testés, bien choisis, etc.
Ce sont les deux différences.
Avez-vous été à DevOpsDays dans d'autres pays? En quoi pensez-vous qu'ils diffèrent des autres conférences? Y a-t-il des fonctionnalités?J'étais probablement à plusieurs dizaines de conférences DevOpsDays à travers le monde: en Amérique, en Europe et en Asie. Cette franchise de conférence est tout à fait unique en ce qu'elle a un format plus ou moins établi que vous pouvez attendre de n'importe laquelle de ces conférences. Le format est le suivant: il y a relativement peu de présentations de conférence front-end, et beaucoup de temps est consacré au format des espaces ouverts.
Les espaces ouverts sont un format dans lequel le sujet pour lequel la plupart des gens ont voté est discuté avec d'autres participants. Celui qui a proposé ce sujet - il est l'hôte, il fait commencer la discussion. Il s'agit d'un excellent format, car, comme nous le savons, la communication et le réseautage ne sont pas moins importants dans une conférence que les rapports. Et lorsque la conférence consacre la moitié de son temps au format de réseautage - c'est très cool.
De plus, DevOpsDays héberge souvent des Lightning Talks - ce sont de courts rapports de cinq minutes qui vous permettent d'en apprendre beaucoup sur les choses et d'ouvrir vos yeux sur de nouvelles choses dans un format ennuyeux. Et si au milieu d'un rapport régulier vous vous rendez compte que ce n'est pas le vôtre, alors du temps est perdu, 30 à 40 minutes de votre vie sont perdues, alors nous parlons ici de rapports pendant cinq minutes. Et si vous n'êtes pas intéressé, cela se terminera bientôt. «Dites-nous, mais rapidement», est également un très bon format.
Il y a des DevOpsDays plus techniques, il y en a qui sont spécialement adaptés à ce qu'est DevOps: les processus, la collaboration, ce sont les choses. C'est intéressant à la fois cela et un autre, et c'est intéressant quand il y a à la fois cela et un autre. Il me semble, aujourd'hui, que c'est l'une des meilleures franchises de conférences sur DevOps.
Beaucoup de vos performances sont similaires à des performances ou des performances: ensuite vous racontez un rapport sous la forme d'une tragédie grecque, puis vous jouez le rôle de Sherlock, puis vous agissez en costume de grenouille. Comment les proposez-vous? Y a-t-il d'autres objectifs en plus de rendre le rapport ennuyeux?Il me semble que le rapport n'a pas le droit d'être ennuyeux, car, premièrement, je passe du temps avec mes élèves, ils sont moins impliqués dans un rapport ennuyeux, ils ont moins appris, ils ont moins appris, et ce n'est pas la meilleure perte de leur temps. Deuxièmement, mes objectifs n'ont pas été atteints non plus: ils ne pensent rien de bon à mon sujet, ils ne pensent rien de bon à JFrog, et pour moi, c'est une sorte d'échec.
Par conséquent, les rapports ennuyeux n'ont pas le droit d'exister, du moins pour moi. J'essaie de les rendre intéressants, attrayants et mémorables. Les performances sont à sens unique. Et, en fait, la méthode est assez simple. Il suffit de trouver un format intéressant, puis les mêmes réflexions qui sont présentées sous la forme d'un rapport régulier, présentées dans un format inhabituel.
Comment puis-je trouver ça? Cela se produit de différentes manières. Parfois, ce sont des idées qui me viennent à l’esprit, parfois ce sont des idées qu’elles me donnent lorsque je fais des essais ou que je partage mes réflexions sur le rapport et qu’elles me disent: «Oh, ça peut être fait comme ça!» ça se passe différemment. Lorsqu'une idée apparaît, elle est toujours très joyeuse et cool, ce qui signifie qu'un rapport plus intéressant et impliqué peut être fait.
Quelles sont les apparences de la sphère informatique que vous aimez personnellement? Y a-t-il de tels orateurs? Et pourquoi?Il existe deux types d'orateurs dont j'aime les apparences. Le premier, ce sont les enceintes auxquelles j'essaie de ressembler. Ils racontent des choses intéressantes et impliquées, essaient de faire en sorte que tout le monde s'intéresse et écoute.
Le deuxième type d'enceintes est celui qui peut raconter de façon très intéressante et passionnante tout hardcore habituellement ennuyeux.
Parmi les noms de la deuxième catégorie, il s'agit d'Aleksey Shepelev, qui parle de la collecte des ordures en profondeur et de l'intérieur de la machine virtuelle java, ce qui est intéressant et humoristique. Une autre ouverture du dernier DevOops est Sergey Fedorov de Netflix. Il a dit une chose purement technique sur la façon dont ils ont optimisé leur réseau de diffusion de contenu, et il l'a dit de manière très intéressante.
De la première catégorie sont Jessica Deen, Anton Weiss, Roman Shaposhnik. Ce sont ces haut-parleurs qui racontent de façon intéressante, avec humour, et méritent à juste titre des notes élevées.
Vous avez sûrement plus d'invitations à prendre la parole lors de conférences que de temps pour cela. Comment choisissez-vous où vous allez et où non?Les conférences et les intervenants, comme presque tout le reste, sont régis par les relations de marché entre l'offre et la demande et la valeur les unes des autres. Il y a des conférences qui, pour ainsi dire, me veulent plus que je n'en ai besoin. En termes d'audience que je m'attends à y rencontrer et d'impact que je m'attends à y apporter. Il y a des conférences qui, au contraire, je veux obtenir bien plus qu'elles n'ont besoin de moi. En termes de valeur pour moi, je décide où aller.
C'est-à-dire, si c'est, par exemple, une sorte de géographie, où j'ai stratégiquement besoin d'entrer, c'est une grande conférence bien connue, qui a une bonne réputation, et à laquelle les gens assisteront, alors évidemment j'en ai vraiment besoin. Et je le préférerais à d'autres conférences.
S'il s'agit d'une sorte de petite conférence régionale, et peut-être que nous ne sommes pas très intéressés, alors il se peut qu'un voyage là-bas ne justifie pas les coûts de temps qui seront imposés à cette entreprise. Relations normales de marché entre la demande, l'offre et la valeur.
Bonne géographie, bonne démographie, contacts potentiellement bons, communication - la clé du fait que la conférence sera intéressante pour moi.
Dans l'une de vos entrevues, vous avez mentionné qu'au cours de l'année, vous vous exprimez lors d'une quarantaine de conférences. Comment arrivez-vous à travailler et à vous préparer aux représentations? Et parvenez-vous à maintenir l'équilibre travail / vie personnelle avec un tel calendrier? Partager des secrets?Voyager à des conférences est la part du lion de mon travail. Bien sûr, il y a tout le reste: il y a la préparation des rapports, la maintenance technique, l'écriture de code, l'apprentissage de nouvelles choses. Tout cela se fait en parallèle avec les conférences: le soir, dans l'avion, la veille, quand je suis déjà arrivé à la conférence, et ce sera demain. Quelque chose comme ça.
Bien sûr, il est difficile de maintenir l'équilibre travail / vie personnelle quand il y a tellement de temps en voyage d'affaires. Mais j'essaie de compenser cela par le fait que, au moins lorsque je ne suis pas en voyage d'affaires, je suis à 100% avec ma famille, je ne réponds pas aux e-mails le soir, j'essaie de ne participer à aucun appel téléphonique le soir et le week-end. Quand je ne suis pas en voyage d'affaires et que c'est du temps en famille, c'est vraiment du temps 100% familial. Est-ce que cela fonctionne et résout-il le problème? Non. Mais j'espère que cela compensera en quelque sorte ma famille pendant tout le temps que je serai absent.
L'un des rapports de Baruch est «Nous avons DevOps. Tirons tous les testeurs »Avec un calendrier aussi serré, parvenez-vous à maintenir un niveau technique ou vous êtes-vous déjà éloigné de la programmation?J'essaie de faire des choses techniques tout en préparant mes rapports et autres activités lors de la conférence. Ce sont toutes sortes de démos techniques, quelques mini-reportages que nous tenons sur les stands. Ce n'est pas de la programmation, c'est plus d'intégration, mais c'est au moins du travail technique que j'essaie de faire. De cette façon, je maintiens la connaissance de nos produits, de nos nouvelles fonctionnalités, etc.
Bien sûr, dire que je suis maintenant le même encodeur hardcore que je l'étais il y a 7 ans, c'est probablement déjà impossible. Je ne sais pas si c'est mauvais. Il s'agit probablement d'une sorte d'évolution naturelle. C'est moins intéressant pour moi, et il y a moins de temps, alors, probablement, que Dieu soit avec lui.
Je me considère toujours comme un solide spécialiste technique, je suis toujours au courant de ce qui se passe, je me maintiens en forme. Voici ma situation hybride aujourd'hui.
Veuillez me raconter quelques histoires amusantes ou des situations extrêmes qui vous sont arrivées: vous étiez en retard pour l'avion / avez supprimé la présentation / avez coupé l'électricité pendant le rapport / vous n'êtes pas arrivé de bagages?Parmi les situations amusantes, je me souviens de la plupart des échecs de toutes sortes qui ont eu lieu sur les rapports. Naturellement, parce que c'est la situation la plus stressante, parce que c'est le public, le temps, et vous devez vous assurer qu'ils ne le gaspillent pas en vain.
J'ai eu un «écran bleu de la mort» sur Windows et Mac pendant la conversation. Sur Windows, c'était une fois, sur le Mac à quelques reprises. Bien sûr, cela est stressant, mais nous résolvons en quelque sorte ce problème, l'ordinateur redémarre, je continue de dire quelque chose à ce moment, mais le stress est énorme.
Probablement la situation la plus drôle que j'ai eue à la conférence Groovy. Je ne me souviens pas exactement où la conférence a eu lieu, semble-t-il, dans un hôtel, et devant cet hôtel il y avait une sorte de construction ou de réparation. Et donc je parlais d'une sorte de code que j'ai écrit, c'était une démo. Ce fut la première itération de la démo, ce qui était compréhensible, mais peut-être pas écrit de la meilleure façon. Et j'allais juste refactoriser et l'améliorer, et j'ai mentionné une sorte de phrase comme «auto-dépréciation» sur le fait que c'est du «code merdique». C'était au deuxième étage, et à ce moment-là, la grue du chantier de construction en face ne faisait que soulever les toilettes portables. Et la scène était en face de la fenêtre. Autrement dit, je regarde à travers cette fenêtre, dis «code merdique», et une toilette flotte à l'extérieur de la fenêtre. Et je dis à tout le monde: "Retournez-vous, nous avons une illustration ici." C'était probablement la meilleure diapositive de mes pensées - les toilettes volantes dans mon discours quand j'ai parlé de code de merde.
Les bagages ne sont pas venus d'histoires comme celle-ci - en principe, c'est une histoire normale, il n'y a rien à dire. Nous pouvons organiser un entretien séparé sur toutes sortes de conseils de voyage, où vous pouvez parler des bagages qui ne sont pas arrivés, mais il n'y avait rien de critique.
Je m'efforce à tout prix de toujours voler, de venir assister à toutes les conférences que j'ai promises, car, encore une fois, il est temps pour les gens. Le temps des gens est inestimable car c'est le genre de crédit de confiance qu'ils vous accordent. Et si ce prêt est dupe, vous ne pourrez pas le récupérer à ce moment-là.
Si une personne a pris le temps, est venue à la conférence pour écouter mon rapport, mais je l'ai pris et je ne suis pas venu, c'est mauvais, car il n'y a aucun moyen de rendre le temps à cette personne. , .
: « ? , ». , ?! . - . , soft skills. , , soft skills. .
, , , . , , , — . , , , - . .
: — .
DevOpsCon, , - , ?. — . -, . , , - , , , , . , - , .
, . 10-15-30 — , 150-200-300 , .
, : , , . , , -, . , , +1, , . , , -- , .
— . , , 60 , , . — , , , , .
, . -, . . . , , , , , .
, — .
Le 7 décembre, Baruch prendra la parole lors de la conférence DevOpsDays Moscou . Dans le rapport, Baruch analysera les vrais échecs qui se produisent quotidiennement et partout lors de la mise à jour du logiciel. Il montrera comment toutes sortes de modèles DevOps s'intègrent dans différents scénarios et comment leur application appropriée pourrait éventuellement vous sauver.
Également au programme: Alexander Chistyakov (vdsina.ru), Mikhail Chinkov (AMBOSS), Roman Boyko (AWS), Pavel Selivanov (Southbridge), Rodion Nagornov (Kaspersky Lab), Andrey Shorin (consultant DevOps).
Venez faire connaissance!