Барух Садагурскі - Developer Advocate у кампаніі JFrog, суаўтар кнігі "Liquid Software", вядомы IT-спікер.
У інтэрв'ю Барух расказаў, як ён рыхтуецца да дакладаў, чым замежныя канферэнцыі адрозніваюцца ад расійскіх, навошта ўдзельнікам хадзіць на іх і навошта выступаць у касцюме жабы.
Пачнём з самага простага. Як табе здаецца, навошта ўвогуле выступаць на канферэнцыях?
Насамрэч, для мяне выступаць на канферэнцыях - гэта праца. Калі адказваць больш глабальна на пытанне "Навошта мая праца?", то гэта для таго (прынамсі для кампаніі JFrog), каб дасягнуць двух мэт. Па-першае, каб усталяваць кантакт з нашымі карыстальнікамі і кліентамі. Гэта значыць, калі я выступаю на канферэнцыях, я даступны для таго, каб усе, у каго ёсць нейкія пытанні, нейкі фідбек па нашых прадуктах і кампаніі, маглі са мной пагаварыць, я мог ім неяк дапамагчы і палепшыць іх экспірыенс. у рабоце з нашымі прадуктамі.
Па-другое, гэта трэба для павышэння пазнавальнасці брэнда. То бок, калі я расказваю нейкія цікавыя рэчы, то народ цікавіцца, што гэта за JFrog такі, і ў выніку трапляе ў нашу варонку developer relations, якая ў выніку пераходзіць у варонку нашых карыстальнікаў, якая ў выніку пераходзіць у варонку нашых пакупнікоў.
Раскажы, калі ласка, як ты рыхтуешся да выступаў? Ёсць нейкі алгарытм падрыхтоўкі?
Ёсць чатыры больш-менш стандартныя этапы падрыхтоўкі. Першы - гэта inception, як у кіно. Павінна зьявіцца нейкая ідэя. З'яўляецца ідэя, і надалей яна даволі доўга спее. Яна спее, ты думаеш, як гэтую ідэю лепш падаць, у якім ключы, у якім фармаце, што на гэты конт можна сказаць. Гэта першы этап.
Другі этап - гэта напісанне канкрэтнага плана. У цябе ёсць ідэя, і яна пачынае абрастаць дэталямі аб тым, як ты яе будзеш падаваць. Звычайна гэта робіцца ў фармаце якога-небудзь mind-map, калі вакол ідэі з'яўляецца ўсё, што звязана з дакладам: якія падтрымліваюць аргументы, уступленне, нейкія гісторыі, якія ты хочаш пра гэта расказаць. Гэта другі этап - план.
Трэці этап - гэта напісанне слайдаў па гэтым плане. Ты выкарыстоўваеш нейкія абстрактныя ідэі, якія з'яўляюцца на слайдах і падтрымліваюць тваю гісторыю.
Чацвёрты этап - гэта прагоны, рэпетыцыі. На гэтым этапе важна пераканацца, што сюжэтная арка атрымалася, што аповед сувязны, пераканацца, што па часе ўсё нармальна. Пасля гэтага даклад можна аб'яўляць гатовым.
Як ты разумееш, што "вось з гэтай тэмай" трэба выступіць? І як набіраеш матэрыял для дакладаў?
Я не ведаю, як адказаць, яно само неяк прыходзіць. Ці гэта "Ой, як крута ў нас тут атрымалася", ці гэта "Ой, вакол пра гэта толкам ніхто не ведае і не разумее" і ёсць магчымасць распавесці, растлумачыць і дапамагчы. Адзін з гэтых двух варыянтаў.
Збор матэрыялу вельмі залежыць ад даклада. Калі гэта даклад па нейкай абстрактнай тэме, то гэта большая літаратура, артыкулы. Калі гэта нешта практычнае, то гэта будзе напісанне кода, нейкія дэмкі, пошук правільных кавалкаў кода ў прадуктах і гэтак далей.
Страх выступаў і хваляванне - адны з самых частых прычын, чаму людзі не выходзяць на сцэну. Можаш даць нейкія парады тым, хто хвалюецца падчас выступаў? Ці хвалюешся ты сам і як спраўляешся?
Так, у мяне гэта ёсць, гэта павінна быць, і, напэўна, у той момант, калі я ўвогуле перастану хвалявацца, гэта нагода з гэтай справай завязваць.
Мне здаецца, гэта зусім нармальная з'ява, калі ты выходзіш на сцэну і перад табой шмат народа. Ты хвалюешся, таму што гэта вялікая адказнасць, гэта натуральна.
Як з гэтым дужацца? Існуюць розныя спосабы. У мяне гэта ніколі не было на такім узроўні, што трэба проста змагацца, таму мне складана сказаць.
Самае галоўнае, што і мне таксама дапамагае, гэта friendly face - нейкі знаёмы твар у аўдыторыі. Калі папрасіць кагосьці, каго ты ведаеш, прыйсці на твой даклад, сесці ў першых шэрагах пасярэдзіне, каб заўсёды можна было на яго глядзець, і чалавек будзе пазітыўна настроены, будзе ўсміхацца, ківаць, падтрымліваць, мне здаецца, гэта вялізная-вялізная дапамога . Адмыслова я пра гэта нікога не прашу, але калі так бывае, што ёсць знаёмая асоба ў аўдыторыі, гэта вельмі выдатна дапамагае, здымае стрэс. Гэта самая галоўная рада.
Ты шмат выступаеш на расейскіх і міжнародных канферэнцыях. Ці бачыш ты розніцу паміж дакладамі на расійскіх і замежных канферэнцыях? Ці ёсць розніца ў аўдыторыі? У арганізацыі?
Я бачу дзве вялікія розніцы. Зразумела, што канферэнцыі розныя і ў Расіі, і за мяжой, але калі браць сярэдняе па бальніцы, то ў Расіі канферэнцыі больш тэхнічныя ў плане глыбіні дакладаў, у плане хардкора. Гэта тое, да чаго людзі абвыклі, магчыма, дзякуючы такім найбуйным канферэнцыям як Joker, JPoint, Highload, у аснове якіх заўсёды ляжалі хардкорныя даклады. І народ чакае ад канферэнцый менавіта гэтага. І для вельмі многіх гэта з'яўляецца паказчыкам таго, добрая гэта канферэнцыя ці дрэнная: шмат там мяса і хардкора ці там шмат вады.
Я, сапраўды кажучы, можа быць з-за таго, што шмат выступаю на замежных канферэнцыях, не згодзен з гэтым падыходам. Я лічу, што даклады пра soft skills, “напаўгуманітарныя даклады”, ня менш, а можа нават больш важныя для канфэрэнцый. Таму што нейкія тэхнічныя рэчы можна ў выніку прачытаць у кніжках, можна разабрацца па user manual, а вось тое, што датычыцца soft skills, тое, што тычыцца псіхалогіі, тое, што тычыцца зносін, гэтага ўсяго ўзяць няма дзе, прынамсі, лёгка, даступна і зразумела. Мне здаецца, што гэта не менш важна, чым тэхнічны складнік.
Гэта асабліва важна для канферэнцый па DevOps, такі, як DevOpsDays, таму што DevOps - ён жа наогул не пра тэхналогіі. DevOps якраз пра камунікацыі, ён якраз пра спосабы працаваць разам людзям, якія раней разам не працавалі. Так, там ёсць тэхнічны складнік, таму што аўтаматызацыя крытычная для DevOps, але гэта ўсяго толькі адна з. І калі канферэнцыя па DevOps замест таго, каб распавядаць пра DevOps, распавядае пра site reliability ці пра аўтаматызацыю, ці пра пайплайны, то гэтая канферэнцыя, нягледзячы на тое, што яна вельмі хардкорная, на мой погляд, як раз прапускае саму сутнасць DevOps і становіцца канферэнцый пра сістэмнае адміністраванне, а не пра DevOps.
Другая розніца - у падрыхтоўцы. Ізноў жа, я бяру сярэдняе па лякарні і агульныя выпадкі, а не дзелі. За мяжой зыходзяць з таго, што большасць людзей прайшлі пэўны трэнінг публічных выступаў у сваім жыцці. Прынамсі ў Амерыцы - гэта частка вышэйшай адукацыі. Калі чалавек скончыў каледж, то ў яго ўжо ёсць немаленькі досвед публічных выступаў. Таму пасля таго, як праграмны камітэт паглядзеў на план і зразумеў, пра што будзе даклад, больш ніякіх трэнінгаў па выступах для спікера не робіцца, бо лічыцца, што ён, хутчэй за ўсё, і так гэта ўмее.
У Расіі такіх здагадак не робяць, таму што досвед публічных выступаў мала ў каго ёсць, і таму спікераў нашмат больш трэніруюць. Ізноў жа, у агульным выпадку, ёсць прагоны, ёсць заняткі са спікерамі, ёсць курсы публічных выступаў для дапамогі спікерам.
У выніку слабыя дакладчыкі, якія дрэнна расказваюць, адсяюцца, або ім дапамагаюць стаць больш моцнымі дакладчыкамі. Тое, што на Захадзе public speaking лічыцца скілам, які шмат у каго ёсць, у выніку атрымлівае адваротны эфект, таму што гэтая здагадка часта аказваецца ілжывай, памылковай, і людзі, якія не ўмеюць гаварыць на публіцы, адкрыта лажаюць на сцэне і атрымліваюцца агідныя даклады. А ў Расіі, дзе лічыцца, што досведу публічных выступаў няма, у выніку атрымліваецца нашмат лепш, таму што іх трэніравалі, іх праверылі, абралі добрае і гэтак далей.
Вось такія дзве розніцы.
Ты бываў на DevOpsDays у іншых краінах? Як табе здаецца, чым яны адрозніваюцца ад іншых канферэнцый? Ёсць нейкія асаблівасці?
Я быў, напэўна, на некалькіх дзясятках канферэнцый DevOpsDays па ўсім свеце: і ў Амерыцы, і ў Еўропе, і ў Азіі. Гэтая франшыза канферэнцыі даволі ўнікальная тым, што ў яе існуе больш-менш які склаўся фармат, які ты можаш чакаць у любым месцы, ад любой з гэтых канферэнцый. Фармат такі: ёсць адносна крыху франтальных канферэнцыйных дакладаў, і шмат часу надаецца фармату open spaces.
Open spaces - гэта такі фармат, у якім тэма, за якую больш за ўсё чалавек прагаласавалі, абмяркоўваецца разам з іншымі ўдзельнікамі. Той, хто гэтую тэму прапанаваў - ён вядучы, ён робіць так, каб дыскусія пачалася. Гэта выдатны фармат, таму што, як мы ведаем, зносіны і нетворкінг — гэта не менш важная частка любой канферэнцыі, чым даклады. І калі канферэнцыя закладвае палову свайго часу пад нетворкінг-фармат - гэта вельмі крута.
Плюс на DevOpsDays часта праводзяць Lightning Talks - гэта кароткія даклады па пяць хвілін, якія дазваляюць пра многае даведацца і адкрыць вочы на нейкія новыя рэчы ў нянудным фармаце. І калі ў сярэдзіне звычайнага дакладу ты зразумеў, што гэта не твой, той час страчаны, 30-40 хвілін твайго жыцця знікла, то тут гаворка ідзе пра даклады на пяць хвілін. І калі вам нецікава, тое гэта хутка скончыцца. "Раскажы нам, але хуценька" - гэта таксама вельмі добры фармат.
Ёсць больш тэхнічныя DevOpsDays, ёсць тыя, якія заменчаны спецыяльна пад тое, чым з'яўляецца DevOps: працэсы, калабарацыя, вось такія штукі. Цікава і тое, і іншае, і цікава, калі ёсць і тое, і іншае. Мне здаецца, на сённяшні дзень, гэта адна з лепшых франшызы канферэнцый пра DevOps.
Многія твае выступленні падобныя на перформансы або спектаклі: то ты расказваеш даклад у форме грэчаскай трагедыі, то ты ў ролі Шэрлака, то выступаеш у касцюме жабы. Як ты іх прыдумляеш? Ці ёсць нейкія дадатковыя мэты, акрамя таго, каб даклад не быў сумным?
Мне здаецца, што даклад не мае права быць сумным, таму што, па-першае, я марную час слухачоў, на сумным дакладзе яны менш уцягнутыя, яны менш вывучылі, яны менш новага даведаліся, і гэта не лепшае марнаванне іх часу. Па-другое, мае мэты таксама не дасягнуты: яны нічога добрага не думаюць пра мяне, нічога добрага не думаюць пра JFrog, і для мяне гэта нейкі фэйл.
Таму сумныя даклады не маюць права на існаванне, прынамсі, у мяне. Я стараюся зрабіць іх цікавымі, прывабнымі і запамінальнымі. Перформансы - гэта адзін са спосабаў. І, насамрэч, спосаб досыць лёгкі. Усё, што трэба, гэта прыдумаць нейкі цікавы фармат, і надалей тыя ж думкі, якія выкладаюцца ў выглядзе звычайнага дакладу, выкласці ў незвычайным фармаце.
Як я гэта прыдумляю? Бывае па-рознаму. Часам гэта нейкія ідэі, якія мне прыходзяць у галаву, часам гэта нейкія ідэі, якія мне падаюць, калі я ўладкоўваю прагоны ці дзялюся думкамі пра даклад і мне кажуць: "О, гэта ж можна зрабіць вось так!" Па-рознаму бывае. Калі ідэя з'яўляецца, то гэта заўсёды вельмі радасна і клёва, гэта значыць, што можна зрабіць цікавейшы і ўцягнуты даклад.
Чые выступы з IT-сферы падабаюцца асабіста табе? Ёсць такія спікеры? І чаму?
Ёсць два віды дакладчыкаў, чые выступленні мне падабаюцца. Першы - гэта дакладчыкі, на якіх я стараюся быць падобным. Яны расказваюць цікава і ўцягнута, імкнуцца зрабіць так, каб усім было цікава і ўсё слухалі.
Другі выгляд дакладчыкаў - гэта тыя, хто ўмеюць вельмі цікава і захапляльна распавесці пра ўсякі звычайна сумны хардкор.
З імёнаў у другой катэгорыі - гэта Аляксей Шэпелеў, які распавядае пра нейкі глыбокі performance garbage collection і вантробы java virtual machine цікава і з гумарам. Яшчэ адкрыццё апошняга DevOops – Сяргей Фёдараў з кампаніі Netflix. Ён расказваў чыста тэхнічную рэч, як яны аптымізавалі свой content delivery network, і расказваў ён гэта вельмі цікава.
З першай катэгорыі — гэта Jessica Deen, Антон Вайс, Раман Шапашнік. Гэта тыя спікеры, якія расказваюць цікава, з гумарам, і заслужана атрымліваюць высокія рэйтынгі.
Напэўна, запрашэнняў выступіць на канферэнцыях у цябе больш, чым часу на гэта. Як ты выбіраеш, куды паедзеш, а куды не?
Канферэнцыі і спікеры, як і амаль усё астатняе, рэгулююцца рынкавымі адносінамі попыту і прапановы і каштоўнасці аднаго ад другога. Ёсць канферэнцыі, якія, ну так скажам, жадаюць мяне больш, чым яны мне патрэбныя. У плане аўдыторыі, якую я чакаю там сустрэць, і ўплыву, які я чакаю там нанесці. Ёсць канферэнцыі, на якія, наадварот, я хачу патрапіць значна больш, чым я ім патрэбен. Па памеры каштоўнасці для мяне я вырашаю, куды ехаць.
То бок, калі гэта, напрыклад, нейкая геаграфія, куды мне стратэгічна трэба патрапіць, гэта вялікая вядомая канферэнцыя, у якой добрая рэпутацыя, і на якую пойдуць людзі, то, відавочна, яна мне моцна патрэбная. І я ўпадабаю яе іншым канферэнцыям.
Калі гэта нейкая маленькая рэгіянальная канферэнцыя, і, магчыма, там, дзе нам не вельмі цікава, то можа быць, што паездка туды і не апраўдвае выдаткі на час, якія будуць закладзеныя на гэтую справу. Нармальныя рынкавыя адносіны попыту, прапановы і каштоўнасці.
Добрая геаграфія, добрая дэмаграфія, патэнцыйна добрыя кантакты, зносіны - залог таго, што канферэнцыя будзе мне цікавая.
У адным са сваіх інтэрв'ю ты згадаў, што за год выступаеш прыкладна на сарака канферэнцыях. Як ты паспяваеш працаваць і рыхтавацца да выступленняў? І ці ўдаецца табе пры такім графіку выконваць work/life balance? Падзяліся сакрэтамі?
Ездзіць па канферэнцыях - гэта ільвіная частка маёй працы. Безумоўна, ёсць усё астатняе: ёсць падрыхтоўка да дакладаў, падтрыманне сябе ў тэхнічнай форме, напісанне кода, вывучэнне новых рэчаў. Гэта ўсё робіцца паралельна з канферэнцыямі: вечарамі, у самалёце, за дзень да, калі ўжо прыляцеў на канферэнцыю, і яна заўтра. Неяк так.
Цяжка, вядома, прытрымлівацца work/life balance, калі столькі часу ў камандзіроўках. Але я імкнуся гэта кампенсаваць тым, што, прынамсі, калі я не ў камандзіроўцы, я на 100% з сям'ёй, я не адказваю на емейлы па вечарах, стараюся не ўдзельнічаць ні ў якіх сазвонах па вечарах і па выходных. Калі я не ў камандзіроўцы і гэты сямейны час, то гэта сапраўды сямейны час на 100%. Ці працуе гэта і ці вырашае гэта праблему? Не. Але я спадзяюся, што гэта нейкім чынам кампенсуе маёй сям'і ўвесь той час, які я адсутнічаю.
Пры такім цвёрдым графіку ты паспяваеш падтрымліваць тэхнічны ўзровень ці ўжо адышоў ад праграмавання?
Я стараюся рабіць нейкія тэхнічныя рэчы падчас падрыхтоўкі да маіх дакладаў ды іншых актыўнасьцяў на канферэнцыі. Гэта ўсякія тэхнічныя дэмкі, нейкія міні-даклады, якія мы праводзім на стэндах. Гэта не праграмаваньне-праграмаваньне, гэта больш інтэграцыя, але гэта хоць нейкая тэхнічная праца, якую я стараюся рабіць. Такім чынам я падтрымліваю веды аб нашых прадуктах, новых фічах і гэтак далей.
Безумоўна, сказаць, што я зараз такі ж хардкор-кодэр, які быў 7 гадоў таму, ужо, напэўна, нельга. Ня ўпэўнены, што гэта дрэнна. Мусіць, гэта нейкая натуральная эвалюцыя. Гэта і мне менш цікава, і часу менш ёсць, так што, мабыць, і Бог з ім.
Я ўсё яшчэ лічу сябе моцным тэхнічным спецыялістам, я ўсё яшчэ ў курсе таго, што адбываецца, трымаю сябе ў тонусе. Вось такая ў мяне гібрыдная сітуацыя на сённяшні дзень.
Раскажы, калі ласка, парачку смешных гісторый ці экстрэмальных сітуацый, якія здараліся з табой: спазніўся на самалёт/выдаліў прэзентацыю/адключылі электрычнасць падчас дакладу/не прыляцеў багаж?
Са смешных сітуацый больш за ўсё мне запамінаюцца ўсякія кашмарныя фейлы, якія здараліся на дакладах. Натуральна, таму што гэта самая стрэсавая сітуацыя, таму што гэта публіка, час, і трэба зрабіць так, каб яны не дарма яго патрацілі.
У мяне быў "blue screen of death" і на Windows, і на Mac падчас дакладу. На Windows было адзін раз, на Mac пару разоў. Гэта, вядома, стрэсава, але мы гэтае пытанне неяк вырашаем, кампутар перазагружаецца, я працягваю тым часам нешта распавядаць, але стрэс гэта велізарны.
Мусіць, самая смешная сітуацыя была ў мяне на канферэнцыі па Groovy. Я не памятаю, дзе дакладна праходзіла канферэнцыя, здаецца, у гатэлі, і насупраць гэтага гатэля ішла нейкая будоўля ці рамонт. І вось я расказваў пра нейкі код, які я напісаў, гэта была дэмка. Гэта была першая ітэрацыя дэмкі, якая была зразумелая, але, можа, не лепшым чынам напісана. І я збіраўся якраз яе рэфактарыць і паляпшаць, і згадаў нейкую фразу тыпу "self deprecating" пра тое, што гэта "shitty code". Справа была на другім паверсе, і тым часам кран на будоўлі насупраць як раз паднімаў пераносны туалет. А сцэна была насупраць акна. Гэта значыць я гляджу ў гэтае акно, кажу "shitty code", а за акном праплывае туалет. І я кажу ўсім: "Развярніцеся, у нас тут ілюстрацыя". Напэўна, гэта быў самы лепшы слайд маіх думак - лятаючы туалет у маім дакладзе, калі я расказваў пра shitty code.
З гісторый тыпу не прыйшоў багаж - гэта, у прынцыпе, нармальная гісторыя, пра гэта няма чаго нават казаць. Можам задаволіць асобнае інтэрв'ю пра ўсякія travel tips, дзе можна пагаварыць пра не які прыйшоў багаж, але нічога крытычнага не было.
Я вельмі стараюся што б там ні было заўсёды прылятаць, прыходзіць і прысутнічаць на ўсіх канферэнцыях, на якіх я абяцаў, паколькі, зноў жа, час людзей. Час людзей бясцэнны, таму што гэта такі крэдыт даверу, які яны табе даюць. І калі гэты крэдыт прафукаць, дык яго потым назад ніяк не атрымаць.
Калі чалавек патраціў час, прыйшоў на канферэнцыю, каб паслухаць мой даклад, а я ўзяў і не прыйшоў, гэта дрэнна, бо час гэтаму чалавеку ніяк не вярнуць. Таму для мяне супер важнае ўсе мае абяцанні ў гэтым плане стрымліваць, і пакуль што ўсё атрымліваецца.
Многія думаюць так: «Навошта ўвогуле хадзіць на канферэнцыі? Відэа можна паглядзець на ютубе, а пагутарыць заўсёды можна анлайн». Як лічыш, навошта трэба хадзіць на канферэнцыі ўдзельнікам?
Выдатнае пытанне! На канферэнцыі трэба хадзіць дзеля нетворкінгу. Гэта бясцэнна і па-іншаму не атрымаць ніяк. Я ўжо згадваў важнасць зносін, камунікацый і soft skills. Прагляд відасіку на ютубе, нажаль, не дае досведу ў soft skills. Таму на канферэнцыі трэба хадзіць дзеля зносін.
Акрамя таго, прынамсі ў мяне, пры праглядзе ролікаў на ютубе ўцягнутасць зусім іншая, і матэрыял заходзіць і запамінаецца нашмат горш. Можа быць, гэта чыста ў мяне, але я падазраю, што быць у зале на дакладзе і глядзець ролік на ютубе - гэта зусім розныя рэчы. Асабліва, калі даклад добры, мне здаецца, нашмат-нашмат лепш пачуць яго жыўцом. Гэта як паслухаць жывы канцэрт і кружэлку.
І яшчэ раз паўтару: нетворкінг і зносіны - гэта не ўзяць з ютуба.
Дай, калі ласка, нейкае пажаданне тым, хто толькі збіраецца стаць спікерам ці толькі пачаў выступаць?
Пашукайце лакальныя мітапы. Лакальныя мітапы - гэта выдатная штука для пачатку спікерскай кар'еры па некалькіх прычынах. Па-першае, лакальныя мітапы заўсёды шукаюць дакладчыкаў. Можа быць, што без досведу і не будучы знакамітым спікерам, вам будзе цяжка падацца на нейкую вядомую канферэнцыю, ці праграмны камітэт пасля зносін з вамі зразумее, што, можа быць, вам яшчэ трошкі ранавата. У адрозненне ад гэтага, лакальныя мітапы заўсёды шукаюць спікераў і планка ўваходжання туды нашмат-нашмат ніжэй, таму туды нашмат лягчэй патрапіць.
Акрамя таго, узровень стрэсу зусім іншы. Калі прыходзяць 10-15-30 чалавек - гэта зусім не тое, чым калі ў зале 150-200-300 чалавек, таму нашмат лягчэй.
Ізноў жа, на лакальны мітап выдаткі нашмат менш: не трэба нікуды ляцець, не трэба марнаваць дні, можна проста прыйсці ўвечар. Узгадваючы маю параду аб тым, што важна мець сяброўскую асобу сярод публікі, на лакальны мітап значна лягчэй прыйсці з кімсьці, таму што гэта не каштуе грошай. Калі вы выступаеце на канферэнцыі, вы як спікер прыходзьце бясплатна, але вось гэтаму вашаму +1, які будзе сяброўская асоба ў публіцы, трэба купляць білет. Калі вы выступаеце на мітапе, такой праблемы няма, вы можаце прывезці з сабой аднаго-двух-трох сяброў, якія будуць сяброўскай асобай у зале.
І дадатковы плюс - у арганізатараў мітапаў нашмат больш магчымасцяў вам дапамагчы. Бо ў арганізатараў канферэнцый будзе, напрыклад, 60 дакладаў, якія трэба прагледзець, адтрэніраваць і падрыхтаваць. А ў арганізатараў мітапаў - адзін, два ці тры, таму вам, натуральна, будзе надавацца нашмат больш увагі.
Акрамя таго, з лакальных мітапаў значна лягчэй атрымаць фідбэк. Вы скончылі ваш даклад і вось вы і публіка ўжо маеце зносіны і абмяркоўваеце нешта, што звязана з вашым дакладам. Для вялікіх канферэнцый гэта часта не так. Вы зрабілі даклад і ўсё. Публіка, якая ў вас была шэрай масай падчас дакладу, сышла, і вы больш нічога пра іх не ведаеце, не чуеце, ніякага фідбэка не атрымаеце.
Як ні круці, лакальныя мітапы - гэта выдатная тэма наогул і для пачаткоўцаў у прыватнасці.
7 снежня Барух выступіць на канферэнцыі . У дакладзе Барух прааналізуе рэальныя фэйлы, якія штодня і паўсюдна адбываюцца пры абнаўленні софту. Ён пакажа, як разнастайныя DevOps-патэрны кладуцца на розныя сцэнары і як правільнае іх ужыванне змагло б, магчыма, вас выратаваць.
Яшчэ ў праграме: Аляксандр Чысцякоў (vdsina.ru), Міхаіл Чынкоў (AMBOSS), Раман Бойка (AWS), Павел Селіванаў (Southbridge), Радзіён Нагорнаў (Лабараторыя Касперскага), Андрэй Шорын (кансультант па DevOps).
Прыходзьце знаёміцца!
Крыніца: habr.com