„Raport nie ma prawa być nudny”: wywiad z Baruchem Sadogurskim o wystąpieniach na konferencjach

Baruch Sadogursky – Developer Advocate w JFrog, współautor książki „Liquid Software”, znany mówca branży IT.

W wywiadzie Baruch wyjaśnił, jak przygotowuje się do swoich raportów, czym różnią się konferencje zagraniczne od rosyjskich, dlaczego uczestnicy powinni w nich uczestniczyć i dlaczego powinni przemawiać w kostiumie żaby.

„Raport nie ma prawa być nudny”: wywiad z Baruchem Sadogurskim o wystąpieniach na konferencjach

Zacznijmy od najprostszego. Jak myślisz, po co w ogóle przemawiać na konferencjach?

Tak naprawdę przemawianie na konferencjach to dla mnie praca. Jeśli odpowiemy szerzej na pytanie „Dlaczego moja praca?”, to służy to (przynajmniej dla firmy JFrog) osiągnięciu dwóch celów. Po pierwsze, aby nawiązać kontakt z naszymi użytkownikami i klientami. Oznacza to, że gdy przemawiam na konferencjach, jestem do dyspozycji, aby każdy, kto ma jakiekolwiek pytania, uwagi na temat naszych produktów i firmy, mógł ze mną porozmawiać, mogę im w jakiś sposób pomóc i poprawić ich doświadczenie w pracy z naszymi produktami.

Po drugie, jest to konieczne, aby zwiększyć świadomość marki. Oznacza to, że jeśli opowiem jakieś ciekawe rzeczy, ludzie zainteresują się, jaki to JFrog, i w rezultacie trafią do naszej ścieżki relacji z programistami, która ostatecznie trafia do ścieżki naszych użytkowników, która ostatecznie trafia do lejek naszych klientów.

Opowiedz nam, jak przygotowujesz się do występów? Czy istnieje jakiś algorytm przygotowania?

Istnieją cztery mniej więcej standardowe etapy przygotowania. Pierwsza to incepcja, jak w filmach. Musi pojawić się jakiś pomysł. Pojawia się pomysł, który potem dojrzewa dość długo. Dojrzewa, zastanawiasz się, jak najlepiej tę ideę przedstawić, w jakiej tonacji, w jakim formacie, co można o tym powiedzieć. To jest pierwszy etap.

Drugi etap to napisanie konkretnego planu. Masz pomysł, a on zaczyna poznawać szczegóły dotyczące tego, jak go zaprezentujesz. Zwykle robi się to w formie mapy myśli, gdzie wszystko, co jest związane z raportem, pojawia się wokół pomysłu: argumenty wspierające, wprowadzenie, niektóre historie, które chcesz o nim opowiedzieć. To jest drugi etap – plan.

Trzeci etap to pisanie slajdów według tego planu. Wykorzystujesz abstrakcyjne pomysły, które pojawiają się na slajdach i wspierają Twoją historię.

Czwarty etap to przeróbki i próby. Na tym etapie ważne jest, aby upewnić się, że fabuła została ukończona, że ​​jest spójna i że wszystko jest w porządku pod względem czasu. Następnie raport można uznać za gotowy.

Jak rozumiesz, że „tym tematem” należy się zająć? A jak zbieracie materiał do raportów?

Nie wiem, jak odpowiedzieć, samo przychodzi jakoś. Albo „Och, jak fajnie tu wyszło”, albo „Och, nikt tak naprawdę o tym nie wie i nie rozumie” i istnieje możliwość opowiedzenia, wyjaśnienia i pomocy. Jedna z tych dwóch opcji.

Gromadzenie materiału jest w dużym stopniu zależne od raportu. Jeśli jest to raport na jakiś abstrakcyjny temat, to jest to raczej literatura, artykuły. Jeśli jest to coś praktycznego, będzie to pisanie kodu, kilka wersji demonstracyjnych, znajdowanie odpowiednich fragmentów kodu w produktach i tak dalej.

Przemówienie Barucha na niedawnym szczycie DevOps w Amsterdamie 2019

Strach przed występem i niepokój to najczęstsze powody, dla których ludzie nie wychodzą na scenę. Czy masz jakąś radę dla tych, którzy czują się zdenerwowani podczas występów? Martwisz się i jak sobie radzisz?

Tak, mam, powinno być i pewnie w momencie, kiedy przestanę się już w ogóle martwić, jest to powód, aby porzucić tę sprawę.

Wydaje mi się, że jest to zupełnie normalne zjawisko, kiedy wychodzisz na scenę, a przed tobą stoi mnóstwo ludzi. Martwisz się, bo to duża odpowiedzialność, to naturalne.

Jak sobie z tym poradzić? Istnieją różne sposoby. Nigdy nie grałem na takim poziomie, że musiałbym z tym walczyć bezpośrednio, więc trudno mi powiedzieć.

Najważniejszą rzeczą, która również mi pomaga, jest przyjazna twarz - jakaś znajoma twarz na widowni. Jeśli poprosisz kogoś znajomego, aby przyszedł na Twoje wystąpienie, usiądź w pierwszym rzędzie pośrodku, abyś zawsze mógł na niego spojrzeć, a ta osoba będzie pozytywnie nastawiona, uśmiechnie się, skinie głową, udzieli wsparcia, myślę, że to ogromne, ogromna pomoc. Nie proszę nikogo specjalnie o to, ale jeśli zdarzy się, że na widowni pojawi się znajoma twarz, bardzo to pomaga i łagodzi stres. To najważniejsza rada.

Dużo przemawiasz na konferencjach rosyjskich i międzynarodowych. Czy widzisz różnicę pomiędzy raportami na konferencjach rosyjskich i zagranicznych? Czy jest różnica w widowni? W organizacji?

Widzę dwie duże różnice. Oczywiste jest, że konferencje różnią się zarówno w Rosji, jak i za granicą, ale jeśli weźmiemy średnią dla szpitala, to w Rosji konferencje są bardziej techniczne pod względem głębi raportów, pod względem hardkoru. Ludzie są do tego przyzwyczajeni, być może dzięki tak poważnym konferencjom jak Joker, JPoint, Highload, które zawsze opierały się na hardcorowych prezentacjach. I tego właśnie ludzie oczekują od konferencji. I dla wielu osób jest to wyznacznik tego, czy ta konferencja jest dobra, czy zła: jest dużo mięsa i hardcoru, albo jest dużo wody.

Szczerze mówiąc, być może ze względu na to, że dużo wypowiadam się na konferencjach zagranicznych, nie zgadzam się z takim podejściem. Wierzę, że raporty dotyczące umiejętności miękkich, „raporty półhumanitarne” są nie mniej, a może nawet ważniejsze dla konferencji. Ponieważ o niektórych kwestiach technicznych w końcu można przeczytać w książkach, można je zrozumieć, korzystając z instrukcji obsługi, ale jeśli chodzi o umiejętności miękkie, jeśli chodzi o psychologię, jeśli chodzi o komunikację, to przynajmniej nie ma gdzie tego wszystkiego dostać łatwe, dostępne i zrozumiałe. Wydaje mi się, że jest to nie mniej ważne niż element techniczny.

Jest to szczególnie ważne w przypadku konferencji DevOps takich jak DevOpsDays, ponieważ DevOps w ogóle nie dotyczy technologii. DevOps to tylko komunikacja, to tylko sposoby na współpracę osób, które wcześniej ze sobą nie współpracowały. Tak, istnieje element techniczny, ponieważ automatyzacja ma kluczowe znaczenie dla DevOps, ale to tylko jeden z nich. I kiedy konferencja DevOps, zamiast mówić o DevOps, mówi o niezawodności witryn albo automatyzacji czy potokach, to ta konferencja, pomimo tego, że jest moim zdaniem bardzo hardcorowa, pomija samą istotę DevOps i staje się konferencjami o administrowaniu systemami , nie o DevOps.

Druga różnica polega na przygotowaniu. Ponownie biorę pod uwagę przypadki przeciętne i ogólne, a nie konkretne. Za granicą zakłada się, że większość ludzi przeszła w życiu jakiś kurs wystąpień publicznych. Przynajmniej w Ameryce jest to część szkolnictwa wyższego. Jeśli dana osoba ukończyła studia, ma już duże doświadczenie w wystąpieniach publicznych. Dlatego po zapoznaniu się przez komitet programowy z planem i zrozumieniu, czego będzie dotyczył raport, nie przeprowadza się już szkoleń z wypowiadania się w imieniu mówcy, ponieważ uważa się, że on najprawdopodobniej wie, jak to zrobić.

W Rosji nie przyjmuje się takich założeń, ponieważ niewiele osób ma doświadczenie w wystąpieniach publicznych, dlatego też mówcy są szkoleni znacznie częściej. I znowu, ogólnie rzecz biorąc, są przeróbki, są zajęcia z prelegentami, są kursy wystąpień publicznych, które pomagają mówcom.

W rezultacie słabi mówcy, którzy słabo się komunikują, są eliminowani lub pomaga się im stać się silniejszymi prezenterami. Fakt, że na Zachodzie wystąpienia publiczne uznawane są za umiejętność, którą posiada wiele osób, ostatecznie przynosi odwrotny skutek, gdyż założenie to często okazuje się fałszywe, błędne, a osoby nieumiejące wypowiadać się publicznie otwarcie schrzanią sprawę. wystawiają i publikują obrzydliwe raporty. A w Rosji, gdzie uważa się, że nie ma doświadczenia w wystąpieniach publicznych, ostatecznie okazuje się, że jest znacznie lepiej, bo zostali przeszkoleni, przetestowani, wybrali dobrego i tak dalej.

To są dwie różnice.

Czy byłeś na DevOpsDays w innych krajach? Czym, Twoim zdaniem, różnią się one od innych konferencji? Czy są jakieś specjalne funkcje?

Prawdopodobnie byłem na kilkudziesięciu konferencjach DevOpsDays na całym świecie: w Ameryce, Europie i Azji. Ta franczyza konferencji jest dość wyjątkowa, ponieważ ma mniej więcej ustalony format, którego można się spodziewać w dowolnym miejscu na każdej z tych konferencji. Format jest następujący: prezentacji konferencyjnych z pierwszej linii frontu jest stosunkowo niewiele, a dużo czasu poświęca się formatowi open space.

Otwarte przestrzenie to format, w którym temat, na który głosowało najwięcej osób, omawiany jest wspólnie z innymi uczestnikami. Ten, kto zaproponował ten temat, jest liderem, on pilnuje, aby dyskusja się rozpoczęła. To świetny format, ponieważ, jak wiemy, komunikacja i networking są nie mniej ważnymi elementami każdej konferencji niż prezentacje. A kiedy konferencja poświęca połowę swojego czasu na format networkingowy, jest to bardzo fajne.

Dodatkowo na DevOpsDays często odbywają się Lightning Talks - są to krótkie, pięciominutowe raporty, które w nienudnej formie pozwalają dowiedzieć się wiele o wielu sprawach i otworzyć oczy na nowe rzeczy. A jeśli w trakcie regularnego raportu zorientujesz się, że to nie jest twoje, to marnujesz czas, marnujesz 30-40 minut twojego życia, to tutaj mówimy o raportach przez pięć minut. A jeśli nie jesteś zainteresowany, to wkrótce się skończy. „Powiedz nam, ale szybko” to także bardzo dobry format.

Istnieją bardziej techniczne DevOpsDays i są takie, które są dostosowane specjalnie do tego, czym jest DevOps: procesy, współpraca i tym podobne. Interesujące jest mieć jedno i drugie. Interesujące jest mieć jedno i drugie. Myślę, że jest to obecnie jedna z najlepszych franczyz konferencji DevOps.

Wiele Twoich występów ma charakter performansów lub przedstawień teatralnych: czasem wygłaszasz przemówienie w formie tragedii greckiej, czasem wcielasz się w rolę Sherlocka, czasem występujesz w kostiumie żaby. Jak je wymyślasz? Czy oprócz tego, że raport nie jest nudny, są jakieś dodatkowe cele?

Wydaje mi się, że reportaż nie ma prawa być nudny, bo po pierwsze marnuję czas słuchaczy, w nudny reportaż są mniej zaangażowani, mniej się nauczyli, mniej nowych rzeczy się dowiedzieli, a to nie jest najlepszą stratą czasu. Po drugie, moje cele też nie zostały osiągnięte: nie myślą o mnie nic dobrego, nie myślą nic dobrego o JFrogu, a dla mnie jest to pewnego rodzaju porażka.

Dlatego nudne reportaże nie mają prawa istnieć, przynajmniej dla mnie. Staram się, aby były ciekawe, atrakcyjne i zapadające w pamięć. Występy są jednym ze sposobów. W rzeczywistości metoda jest dość łatwa. Wystarczy wymyślić jakiś ciekawy format, a następnie przedstawić te same przemyślenia, które prezentowane są w formie regularnego raportu w nietypowej formie.

Jak na to wpadłem? Nie zawsze jest tak samo. Czasami przychodzą mi do głowy takie pomysły, czasami są to pomysły, które podsuwają mi się, gdy przeglądam lub dzielę się przemyśleniami na temat raportu i mówią mi: „Och, da się to zrobić w ten sposób!” Dzieje się inaczej. Kiedy pojawia się pomysł, zawsze jest on bardzo radosny i fajny, to znaczy, że można zrobić ciekawszą i bardziej zaangażowaną relację.

„Raport nie ma prawa być nudny”: wywiad z Baruchem Sadogurskim o wystąpieniach na konferencjach

Czyje wystąpienia z branży IT lubisz osobiście? Czy są takie głośniki? I dlaczego?

Są dwa typy mówców, których prezentacje sprawiają mi przyjemność. Po pierwsze, to głośniki, którymi staram się być. Opowiadają w sposób ciekawy i zaangażowany, starając się, aby wszyscy byli zainteresowani i wszyscy słuchali.

Drugi typ głośników to ci, którzy w bardzo ciekawy i ekscytujący sposób potrafią opowiedzieć o każdym, zwykle nudnym hardcorzie.

Spośród nazwisk z drugiej kategorii jest to Alexey Shepelev, który w ciekawy i humorystyczny sposób opowiada o pewnym rodzaju głębokiego zbierania śmieci i wnętrzu wirtualnej maszyny Java. Kolejnym odkryciem najnowszego DevOops jest Sergey Fedorov z Netfliksa. Opowiedział czysto techniczną kwestię o tym, jak zoptymalizowali swoją sieć dostarczania treści, i powiedział to w bardzo interesujący sposób.

Z pierwszej kategorii – są to Jessica Deen, Anton Weiss, Roman Shaposhnik. To prelegenci, którzy wypowiadają się ciekawie, z humorem i zasłużenie otrzymują wysokie oceny.

Prawdopodobnie masz więcej zaproszeń do wystąpień na konferencjach niż czasu, aby to zrobić. Jak wybierasz, dokąd pójdziesz, a gdzie nie?

Konferencje i prelegenci, jak prawie wszystko inne, podlegają rynkowym relacjom podaży i popytu oraz wartości jednego od drugiego. Są konferencje, które, powiedzmy, chcą mnie bardziej, niż ich potrzebuję. Jeśli chodzi o publiczność, której spodziewam się tam spotkać i wpływ, jaki tam wywrę. Są konferencje, na które wręcz przeciwnie, chcę pojechać o wiele więcej, niż mnie potrzebują. Na podstawie wartości dla mnie decyduję, dokąd się udać.

Oznacza to, że jeśli jest to na przykład jakiś obszar geograficzny, do którego strategicznie muszę się udać, jest to duża, dobrze znana konferencja, która cieszy się dobrą reputacją i na którą ludzie przychodzą, to oczywiście naprawdę jej potrzebuję. I wolę to od innych konferencji.

Jeśli jest to jakaś mała konferencja regionalna i być może nie jesteśmy zbyt zainteresowani, to może się zdarzyć, że wyjazd tam nie uzasadnia czasu poświęconego tej sprawie. Normalne rynkowe relacje popytu, podaży i wartości.

Dobra geografia, dobra demografia, potencjalnie dobre kontakty, komunikacja to gwarancja, że ​​konferencja będzie dla mnie interesująca.

W jednym z wywiadów wspomniałeś, że rocznie występujesz na około czterdziestu konferencjach. Jak radzisz sobie z pracą i przygotowaniami do występów? A czy przy takim harmonogramie udaje Ci się zachować równowagę między pracą a życiem prywatnym? Podzielisz się swoimi sekretami?

Podróże na konferencje to lwia część mojej pracy. Oczywiście jest wszystko inne: przygotowanie do raportów, utrzymanie formy technicznej, pisanie kodu, nauka nowych rzeczy. Wszystko to odbywa się równolegle z konferencjami: wieczorami, w samolocie, dzień wcześniej, kiedy już przyleciałeś na konferencję, a jest to jutro. Coś takiego.

Oczywiście trudno jest zachować równowagę między pracą a życiem prywatnym, gdy tak dużo czasu spędza się w podróżach służbowych. Ale staram się to rekompensować faktem, że przynajmniej gdy nie jestem w podróży służbowej, jestem w 100% z rodziną, wieczorami nie odpowiadam na maile, staram się nie brać udziału w żadnych dzwoni wieczorami i w weekendy. Kiedy nie jestem w podróży służbowej i jest to czas dla rodziny, jest to naprawdę czas w 100% rodzinny. Czy to działa i czy rozwiązuje problem? NIE. Mam jednak nadzieję, że to w jakiś sposób zrekompensuje mojej rodzinie całą moją nieobecność.

Jeden z raportów Barucha brzmi: „Mamy DevOps. Zwolnijmy wszystkich testerów”.

Czy przy tak napiętym harmonogramie udaje Ci się utrzymać poziom techniczny, czy może już odszedłeś od programowania?

Przygotowując się do wystąpień i innych zajęć na konferencji, staram się zająć sprawami technicznymi. To różnego rodzaju dema techniczne, jakieś mini-raporty, które dajemy na stoiskach. To nie jest programowanie-programowanie, to jest bardziej integracja, ale to jest przynajmniej część pracy technicznej, którą próbuję wykonać. W ten sposób utrzymuję wiedzę na temat naszych produktów, nowych funkcji i tak dalej.

Oczywiście nie da się chyba powiedzieć, że jestem teraz tym samym hardkorowym programistą, co 7 lat temu. Nie jestem pewien, czy to coś złego. Prawdopodobnie jest to swego rodzaju naturalna ewolucja. To jest dla mnie mniej interesujące i mam mniej czasu, więc prawdopodobnie niech Bóg go błogosławi.

Nadal uważam się za silnego specjalistę technicznego, cały czas jestem na bieżąco, trzymam rękę na pulsie. Oto moja dzisiejsza sytuacja hybrydowa.

Opowiedz nam kilka zabawnych historii lub ekstremalnych sytuacji, które Ci się przytrafiły: spóźniłeś się na samolot/skasowałeś prezentację/odcięto prąd w trakcie zgłoszenia/bagaż nie dotarł?

Z zabawnych sytuacji najbardziej pamiętam wszelkiego rodzaju straszne niepowodzenia, które miały miejsce podczas raportów. Naturalnie, bo to najbardziej stresująca sytuacja, bo to publiczność, czas i trzeba uważać, żeby go nie zmarnować.

Podczas rozmowy miałem „niebieski ekran śmierci” zarówno na Windowsie, jak i na Macu. W systemie Windows zdarzyło się to raz, na komputerze Mac kilka razy. Jest to oczywiście stresujące, ale jakoś rozwiązujemy ten problem, komputer uruchamia się ponownie, w tej chwili dalej coś opowiadam, ale stres jest ogromny.

Prawdopodobnie najzabawniejsza sytuacja, jaką miałem, miała miejsce na konferencji Groovy. Nie pamiętam dokładnie, gdzie odbyła się konferencja, zdaje się, w hotelu, a naprzeciwko tego hotelu trwała jakaś budowa lub remont. Mówiłem więc o kodzie, który napisałem, to było demo. To była pierwsza iteracja dema, która była zrozumiała, ale być może niezbyt dobrze napisana. Właśnie miałem zamiar go zrefaktoryzować i ulepszyć, i wspomniałem o frazie typu „samodeprecjonowanie” na temat faktu, że jest to „gówniany kod”. Było to na drugim piętrze i w tym czasie dźwig na placu budowy naprzeciwko podnosił właśnie przenośną toaletę. A scena była naprzeciwko okna. To znaczy, patrzę przez to okno, mówię „gówniany kod”, a za oknem płynie toaleta. I mówię wszystkim: „Odwróćcie się, mamy tu ilustrację”. To był chyba najlepszy slajd, jaki przyszedł mi do głowy – latająca toaleta w moim raporcie, kiedy mówiłem o gównianym kodzie.

Z historii takich jak bagaż nie wyszedł - to w zasadzie zwykła historia, nie ma nawet o czym rozmawiać. Możemy umówić się na osobną rozmowę na temat wszelkiego rodzaju wskazówek dotyczących podróży, podczas której porozmawiamy o bagażu, który nie dotarł, ale nie było nic krytycznego.

Za wszelką cenę staram się latać, przyjeżdżać i uczestniczyć we wszystkich konferencjach, na które obiecałem, bo znowu nadszedł czas ludzi. Czas ludzi jest bezcenny, bo to taki kredyt zaufania, jakim ci dają. A jeśli ta pożyczka zostanie zmarnowana, to nie ma możliwości jej późniejszego odzyskania.

Jeśli ktoś poświęcił czas, przyszedł na konferencję, żeby wysłuchać mojego raportu, a ja to przyjąłem i nie przyszedłem, to jest to złe, bo nie ma możliwości odzyskania czasu tej osoby. Dlatego bardzo ważne jest dla mnie, aby dotrzymać wszystkich obietnic w tym zakresie i jak na razie wszystko się układa.

Wiele osób myśli w ten sposób: „Po co w ogóle chodzić na konferencje? Film możesz obejrzeć na YouTube i zawsze możesz porozmawiać online.” Jak myślisz, dlaczego uczestnicy powinni jeździć na konferencje?

Świetne pytanie! Powinieneś chodzić na konferencje, aby nawiązać kontakty. To jest bezcenne i nie ma innego sposobu, żeby to zdobyć. Wspomniałam już, jak ważna jest komunikacja, komunikacja i umiejętności miękkie. Oglądanie filmu na YouTubie niestety nie zapewnia doświadczenia w zakresie umiejętności miękkich. Dlatego musisz chodzić na konferencje ze względu na komunikację.

Poza tym, przynajmniej u mnie, oglądając filmy na YouTubie zaangażowanie jest zupełnie inne, a materiał zostaje zapamiętany i zapamiętany znacznie słabiej. Może to tylko moje wrażenie, ale podejrzewam, że bycie na sali podczas rozmowy i oglądanie filmu na YouTubie to zupełnie różne rzeczy. Zwłaszcza jeśli raport jest dobry, wydaje mi się, że dużo, dużo lepiej jest go usłyszeć na żywo. To jakby słuchać koncertu na żywo i płyty.

I powtarzam jeszcze raz: networking i komunikacja to nie jest coś, co można zabrać z YouTube.

Wspólny raport z Leonidem Igolnikiem na DevOpsCon

Proszę, powiedz kilka słów na pożegnanie tym, którzy dopiero planują zostać mówcami lub dopiero zaczęli przemawiać?

Poszukaj lokalnych spotkań. Spotkania lokalne to świetny sposób na rozpoczęcie kariery mówcy z kilku powodów. Po pierwsze, lokalne spotkania zawsze szukają prelegentów. Może się zdarzyć, że bez doświadczenia i bez bycia sławnym mówcą będzie Ci trudno aplikować na jakąś znaną konferencję, albo komitet programowy po rozmowie z Tobą zrozumie, że może jest jeszcze dla Ciebie trochę za wcześnie. Dla kontrastu, lokalne spotkania zawsze szukają prelegentów, a poprzeczka przed wejściem jest znacznie, znacznie niższa, więc znacznie łatwiej się tam dostać.

Zupełnie inny jest też poziom stresu. Kiedy przychodzi 10-15-30 osób, to zupełnie nie to samo, co gdy na sali jest 150-200-300 osób, więc jest dużo łatwiej.

Ponownie koszty lokalnego spotkania są znacznie niższe: nie musisz nigdzie lecieć, nie musisz spędzać dni, możesz po prostu przyjść wieczorem. Pamiętając o mojej radzie o tym, jak ważne jest posiadanie przyjaznej twarzy na widowni, znacznie łatwiej jest przyjść z kimś na lokalne spotkanie, ponieważ nie kosztuje to pieniędzy. Jeśli przemawiasz na konferencji, jako prelegent przychodzisz za darmo, ale ten Twój +1, który będzie przyjazną twarzą w społeczeństwie, musi kupić bilet. Jeśli przemawiasz na spotkaniu, nie ma takiego problemu, możesz zabrać ze sobą jednego, dwóch lub trzech znajomych, którzy będą przyjazną twarzą na sali.

Dodatkowym plusem jest to, że organizatorzy spotkań mają znacznie więcej możliwości, aby Ci pomóc. Bo organizatorzy konferencji będą mieli np. 60 prezentacji, które trzeba przejrzeć, przećwiczyć i przygotować. A organizatorzy spotkań mają jednego, dwóch lub trzech, więc naturalnie otrzymasz znacznie więcej uwagi.

Ponadto znacznie łatwiej jest uzyskać informację zwrotną na lokalnych spotkaniach. Skończyłeś swój raport, a teraz ty i odbiorcy już komunikujesz się i omawiasz coś związanego z twoim raportem. W przypadku dużych konferencji często tak nie jest. Złożyłeś raport i tyle. Publiczność, która w Twoim raporcie była szarą masą, odeszła, a ty już nic o niej nie wiesz, nie słyszysz, nie otrzymujesz żadnej informacji zwrotnej.

Cokolwiek by nie powiedzieć, lokalne spotkania to świetny temat w ogóle, a zwłaszcza dla początkujących.

Baruch będzie przemawiał na konferencji 7 grudnia DevOpsDays w Moskwie. W swoim raporcie Baruch przeanalizuje rzeczywiste awarie, które zdarzają się codziennie i wszędzie podczas aktualizacji oprogramowania. Pokaże, jak różne wzorce DevOps pasują do różnych scenariuszy i jak prawidłowe ich zastosowanie może potencjalnie zaoszczędzić.

W programie także: Alexander Chistyakov (vdsina.ru), Michaił Chinkow (AMBOSS), Roman Boyko (AWS), Pavel Selivanov (Southbridge), Rodion Nagornov (Kaspersky Lab), Andrey Shorin (konsultant DevOps).

Przyjdź się zapoznać!

Źródło: www.habr.com

Dodaj komentarz