“Laporan itu tidak berhak membosankan”: wawancara dengan Baruch Sadogursky tentang pidato di konferensi

Baruch Sadogursky adalah Advokat Pengembang di JFrog, salah satu penulis buku "Liquid Software", seorang pembicara TI terkenal.

Dalam sebuah wawancara, Baruch menceritakan bagaimana dia mempersiapkan laporan, bagaimana konferensi asing berbeda dari konferensi Rusia, mengapa peserta pergi ke sana dan mengapa mereka harus berbicara dengan kostum katak.

“Laporan itu tidak berhak membosankan”: wawancara dengan Baruch Sadogursky tentang pidato di konferensi

Mari kita mulai dengan yang paling sederhana. Bagaimana menurut Anda, mengapa berbicara di konferensi?

Sebenarnya berbicara di konferensi adalah pekerjaan bagi saya. Jika Anda menjawab secara lebih global untuk pertanyaan "Mengapa pekerjaan saya?", maka ini agar (setidaknya untuk JFrog) mencapai dua tujuan. Pertama, untuk menjalin kontak dengan pengguna dan pelanggan kami. Artinya, ketika saya berbicara di konferensi, saya tersedia sehingga setiap orang yang memiliki beberapa pertanyaan, semacam umpan balik tentang produk dan perusahaan kami, dapat berbicara dengan saya, entah bagaimana saya dapat membantu mereka dan meningkatkan pengalaman mereka dalam bekerja dengan produk kami.

Kedua, perlu untuk meningkatkan kesadaran merek. Yaitu, jika saya memberi tahu beberapa hal menarik, maka orang-orang tertarik dengan JFrog seperti apa ini, dan akibatnya jatuh ke corong hubungan pengembang kami, yang akhirnya masuk ke corong pengguna kami, yang akhirnya masuk ke corong pelanggan kami.

Tolong beri tahu kami, bagaimana Anda mempersiapkan pertunjukan? Apakah ada algoritma pelatihan?

Ada empat tahap persiapan yang kurang lebih standar. Yang pertama adalah inception, seperti di film-film. Pasti ada ide. Sebuah ide muncul, dan kemudian menjadi matang untuk beberapa waktu. Menjadi dewasa, Anda memikirkan cara terbaik untuk mempresentasikan ide ini, dalam kunci apa, dalam format apa, apa yang bisa dikatakan tentang ini. Ini adalah tahap pertama.

Tahap kedua adalah penulisan rencana tertentu. Anda punya ide, dan itu mulai berkembang menjadi detail tentang bagaimana Anda akan mempresentasikannya. Biasanya ini dilakukan dalam format semacam peta pikiran, ketika segala sesuatu yang berhubungan dengan laporan muncul di sekitar ide: argumen pendukung, pengantar, beberapa cerita yang ingin Anda ceritakan. Ini adalah tahap kedua - rencananya.

Tahap ketiga adalah menulis slide sesuai rencana ini. Anda menggunakan beberapa ide abstrak yang muncul di slide dan mendukung cerita Anda.

Tahap keempat adalah run-through, latihan. Pada tahap ini, penting untuk memastikan bahwa alur cerita ternyata, bahwa ceritanya koheren, untuk memastikan semuanya baik-baik saja pada waktunya. Setelah itu, laporan dapat dinyatakan siap.

Bagaimana Anda memahami bahwa "topik ini" perlu ditangani? Dan bagaimana Anda mengumpulkan bahan untuk laporan?

Saya tidak tahu bagaimana menjawabnya, entah bagaimana itu datang dengan sendirinya. Entah itu "Oh, betapa kerennya kami melakukannya di sini", atau "Oh, tidak ada orang di sekitar yang benar-benar tahu atau mengerti tentang ini" dan ada kesempatan untuk memberi tahu, menjelaskan, dan membantu. Salah satu dari dua opsi ini.

Pengumpulan materi sangat bergantung pada laporan. Jika ini adalah laporan tentang beberapa topik abstrak, maka ini lebih merupakan literatur, artikel. Jika ini sesuatu yang praktis, maka itu akan menjadi menulis kode, beberapa demo, menemukan potongan kode yang tepat dalam produk, dan sebagainya.

Pidato Baruch di DevOps Summit Amsterdam 2019 baru-baru ini

Ketakutan akan pertunjukan dan kecemasan adalah salah satu alasan paling umum mengapa orang tidak naik ke atas panggung. Apakah Anda punya saran untuk mereka yang merasa gugup saat tampil? Apakah Anda khawatir dan bagaimana Anda mengatasinya?

Ya, saya memilikinya, seharusnya begitu, dan, mungkin, pada saat saya berhenti khawatir sama sekali, ini adalah alasan untuk terikat dengan masalah ini.

Menurut saya, ini adalah fenomena yang sangat normal ketika Anda naik ke atas panggung dan ada banyak orang di depan Anda. Anda khawatir karena itu adalah tanggung jawab yang besar, itu wajar.

Bagaimana cara menghadapinya? Ada berbagai cara. Saya tidak pernah memilikinya pada level yang Anda butuhkan untuk bertarung secara langsung, jadi sulit bagi saya untuk mengatakannya.

Hal terpenting, yang juga membantu saya, adalah wajah yang ramah - semacam wajah yang akrab di antara penonton. Jika Anda meminta seseorang yang Anda kenal untuk datang ke presentasi Anda, duduklah di barisan depan di tengah sehingga Anda selalu dapat melihatnya, dan orang tersebut akan bersikap positif, akan tersenyum, mengangguk, mendukung, menurut saya ini sangat besar, bantuan besar. . Saya tidak secara khusus bertanya kepada siapa pun tentang hal ini, tetapi jika kebetulan ada wajah yang akrab di antara penonton, itu sangat membantu, menghilangkan stres. Ini adalah nasihat yang paling penting.

Anda banyak berbicara di konferensi Rusia dan internasional. Apakah Anda melihat perbedaan antara laporan di konferensi Rusia dan luar negeri? Apakah ada perbedaan pada penonton? Dalam organisasi?

Saya melihat dua perbedaan besar. Jelas bahwa konferensi berbeda baik di Rusia maupun di luar negeri, tetapi jika kita mengambil rata-rata untuk rumah sakit, maka di Rusia konferensi lebih bersifat teknis dalam hal kedalaman laporan, dalam hal hardcore. Inilah yang biasa dilakukan orang, mungkin berkat konferensi besar seperti Joker, JPoint, Highload, yang selalu didasarkan pada pembicaraan hardcore. Dan itulah yang orang harapkan dari konferensi. Dan bagi banyak orang ini merupakan indikator apakah ini konferensi yang baik atau buruk: ada banyak daging dan hardcore atau ada banyak air.

Sejujurnya, mungkin karena saya sering berbicara di konferensi luar negeri, saya tidak setuju dengan pendekatan ini. Saya percaya bahwa laporan tentang soft skill, "laporan semi-kemanusiaan", tidak kurang, dan bahkan mungkin lebih penting untuk konferensi. Karena beberapa hal teknis pada akhirnya dapat dibaca di buku, Anda dapat memahami manual pengguna, tetapi untuk soft skill, untuk psikologi, untuk komunikasi, tidak ada tempat untuk mengambil semua ini, setidaknya mudah, dapat diakses, dan dapat dimengerti. Menurut saya ini tidak kalah pentingnya dengan komponen teknis.

Ini sangat penting untuk konferensi DevOps seperti DevOpsDays karena DevOps sama sekali bukan tentang teknologi. DevOps hanya tentang komunikasi, ini hanya tentang cara bekerja sama dengan orang-orang yang belum pernah bekerja sama sebelumnya. Ya, ada komponen teknis, karena otomatisasi sangat penting untuk DevOps, tetapi ini hanyalah salah satunya. Dan ketika sebuah konferensi tentang DevOps, alih-alih berbicara tentang DevOps, berbicara tentang keandalan situs atau tentang otomatisasi, atau tentang saluran pipa, maka konferensi ini, meskipun sangat hardcore, menurut saya, hanya melewatkan esensi DevOps dan menjadi konferensi tentang administrasi sistem, bukan tentang DevOps.

Perbedaan kedua adalah dalam persiapan. Sekali lagi, saya mengambil rata-rata rumah sakit dan kasus umum, bukan kasus individu. Di luar negeri, mereka melanjutkan dari fakta bahwa kebanyakan orang telah menjalani pelatihan berbicara di depan umum dalam hidup mereka. Setidaknya di Amerika, itu adalah bagian dari pendidikan tinggi. Jika seseorang lulus kuliah, maka ia sudah memiliki banyak pengalaman berbicara di depan umum. Oleh karena itu, setelah panitia acara melihat rencana dan memahami laporannya tentang apa, maka tidak ada lagi pelatihan berbicara untuk pembicara, karena diyakini kemungkinan besar sudah tahu bagaimana melakukannya.

Di Rusia, asumsi seperti itu tidak dibuat, karena hanya sedikit orang yang memiliki pengalaman berbicara di depan umum, dan oleh karena itu pembicara lebih terlatih. Sekali lagi, pada umumnya ada run-through, ada kelas dengan pembicara, ada kursus public speaking untuk membantu pembicara.

Akibatnya, penutur lemah yang tidak pandai berbicara tersingkir, atau terbantu untuk menjadi penutur yang lebih kuat. Fakta bahwa di Barat berbicara di depan umum dianggap sebagai keterampilan yang dimiliki banyak orang, pada akhirnya justru berdampak sebaliknya, karena anggapan ini seringkali ternyata salah, keliru, dan orang yang tidak tahu bagaimana berbicara di depan umum secara terus terang. mengacau di atas panggung dan mendapatkan laporan menjijikkan. Dan di Rusia, yang diyakini tidak memiliki pengalaman berbicara di depan umum, pada akhirnya ternyata jauh lebih baik, karena mereka dilatih, diuji, dipilih yang bagus, dan seterusnya.

Berikut perbedaan keduanya.

Apakah Anda pernah ke DevOpsDays di negara lain? Bagaimana menurut Anda mereka berbeda dari konferensi lain? Apakah ada fitur?

Saya mungkin pernah menghadiri beberapa lusin konferensi DevOpsDays di seluruh dunia: di Amerika, Eropa, dan Asia. Waralaba konferensi ini cukup unik karena memiliki format yang kurang lebih mapan yang dapat Anda harapkan di mana saja dari salah satu konferensi ini. Formatnya begini: laporan konferensi frontal relatif sedikit, dan banyak waktu dihabiskan untuk format ruang terbuka.

Ruang terbuka adalah format di mana topik yang paling banyak dipilih orang didiskusikan bersama dengan peserta lain. Yang mengusulkan topik ini adalah pemimpinnya, dia memastikan diskusi dimulai. Ini adalah format yang bagus, karena, seperti yang kita ketahui, komunikasi dan jaringan adalah bagian yang tidak kalah pentingnya dari konferensi mana pun daripada laporan. Dan ketika sebuah konferensi mencurahkan separuh waktunya untuk format jaringan, itu sangat keren.

Selain itu, Lightning Talks sering diadakan di DevOpsDays - ini adalah laporan singkat berdurasi lima menit yang memungkinkan Anda mempelajari banyak hal dan membuka mata terhadap beberapa hal baru dalam format yang tidak membosankan. Dan jika di tengah laporan rutin Anda menyadari bahwa itu bukan untuk Anda, maka waktu hilang, 30-40 menit hidup Anda hilang, maka di sini kita berbicara tentang laporan selama lima menit. Dan jika Anda tidak tertarik, itu akan segera berakhir. "Beri tahu kami, tapi cepat" juga merupakan format yang sangat bagus.

Ada DevOpsDays yang lebih teknis, ada yang dirancang khusus untuk DevOps: proses, kolaborasi, hal-hal seperti itu. Keduanya menarik, dan menarik bila ada keduanya. Saya pikir ini adalah salah satu waralaba konferensi DevOps terbaik saat ini.

Banyak dari penampilan Anda seperti pertunjukan atau pertunjukan: baik Anda menceritakan laporan dalam bentuk tragedi Yunani, atau Anda berperan sebagai Sherlock, atau Anda tampil dengan kostum katak. Bagaimana Anda datang dengan mereka? Apakah ada tujuan tambahan selain membuat laporan tidak membosankan?

Bagi saya, laporan itu tidak berhak membosankan, karena, pertama, saya menyia-nyiakan waktu pendengar, mereka kurang terlibat dalam laporan yang membosankan, mereka belajar lebih sedikit, mereka belajar lebih sedikit hal baru, dan ini bukan yang terbaik. membuang-buang waktu mereka. Kedua, tujuan saya juga tidak tercapai: mereka tidak memikirkan hal baik tentang saya, mereka tidak memikirkan hal baik tentang JFrog, dan bagi saya ini semacam kegagalan.

Oleh karena itu, laporan yang membosankan tidak berhak ada, setidaknya untuk saya. Saya mencoba membuatnya menarik, menarik, dan berkesan. Pertunjukan adalah salah satu cara. Dan ternyata, caranya cukup mudah. Yang diperlukan hanyalah memunculkan beberapa format yang menarik, lalu menuangkan pemikiran yang sama yang disajikan dalam bentuk laporan reguler dalam format yang tidak biasa.

Bagaimana saya memikirkan ini? Itu tidak selalu sama. Terkadang ini adalah beberapa ide yang muncul di benak saya, terkadang ini adalah beberapa ide yang diberikan kepada saya ketika saya mengatur lari atau berbagi pemikiran tentang laporan dan mereka berkata kepada saya: "Oh, kamu bisa melakukannya seperti ini!" Itu terjadi secara berbeda. Ketika sebuah ide muncul, itu selalu sangat menyenangkan dan keren, artinya Anda bisa membuat laporan yang lebih menarik dan terlibat.

“Laporan itu tidak berhak membosankan”: wawancara dengan Baruch Sadogursky tentang pidato di konferensi

Penampilan siapa dari bidang TI yang Anda sukai secara pribadi? Apakah ada pembicara seperti itu? Dan mengapa?

Ada dua jenis pembicara yang pidatonya saya suka. Yang pertama adalah speaker, yang saya coba seperti itu. Mereka bercerita dengan cara yang menarik dan menarik, berusaha memastikan bahwa semua orang tertarik dan semua orang mendengarkan.

Jenis pembicara kedua adalah mereka yang mampu menceritakan dengan cara yang sangat menarik dan mengasyikkan tentang hardcore yang biasanya membosankan.

Dari nama-nama di kategori kedua, ini adalah Alexey Shepelev, yang berbicara tentang semacam pengumpulan sampah kinerja mendalam dan bagian dalam mesin virtual java dengan cara yang menarik dan lucu. Penemuan lain dari DevOops terbaru adalah Sergey Fedorov dari Netflix. Dia menceritakan hal yang murni teknis, bagaimana mereka mengoptimalkan jaringan pengiriman konten mereka, dan dia menceritakannya dengan cara yang sangat menarik.

Dari kategori pertama - ini adalah Jessica Deen, Anton Weiss, Roman Shaposhnik. Inilah pembicara yang menceritakan kisah-kisah menarik, dengan humor, dan pantas mendapat peringkat tinggi.

Anda mungkin memiliki lebih banyak undangan untuk berbicara di konferensi daripada waktu yang Anda miliki untuk itu. Bagaimana Anda memilih ke mana Anda pergi dan ke mana Anda tidak pergi?

Konferensi dan pembicara, seperti hampir semua hal lainnya, diatur oleh hubungan penawaran dan permintaan pasar dan nilai satu sama lain. Ada konferensi yang, katakanlah, menginginkan saya lebih dari yang saya butuhkan. Dalam hal audiens yang saya harapkan untuk bertemu di sana dan dampak yang saya harapkan di sana. Ada konferensi yang, sebaliknya, ingin saya hadiri lebih dari yang mereka butuhkan. Menurut nilai bagi saya, saya memutuskan ke mana harus pergi.

Artinya, jika ini, misalnya, semacam geografi yang secara strategis harus saya tuju, ini adalah konferensi besar yang terkenal yang memiliki reputasi baik dan akan dikunjungi orang, maka, jelas, saya sangat membutuhkannya. Dan saya akan lebih memilihnya daripada konferensi lainnya.

Jika ini semacam konferensi regional kecil, dan, mungkin, di mana kami tidak terlalu tertarik, mungkin perjalanan ke sana tidak membenarkan waktu yang dihabiskan untuk masalah ini. Hubungan pasar normal permintaan, penawaran dan nilai.

Geografi yang bagus, demografi yang bagus, kontak yang berpotensi bagus, komunikasi adalah jaminan bahwa konferensi akan menarik bagi saya.

Dalam salah satu wawancara Anda, Anda menyebutkan bahwa Anda berbicara di sekitar empat puluh konferensi setahun. Bagaimana Anda mengatur untuk bekerja dan mempersiapkan pertunjukan? Dan apakah Anda berhasil mempertahankan keseimbangan kerja/hidup dengan jadwal seperti itu? Bagikan rahasia Anda?

Bepergian ke konferensi adalah bagian terbesar dari pekerjaan saya. Tentu saja, ada yang lainnya: ada persiapan untuk laporan, menjaga diri Anda dalam kondisi teknis, menulis kode, mempelajari hal-hal baru. Ini semua dilakukan bersamaan dengan konferensi: di malam hari, di pesawat, sehari sebelumnya, ketika Anda sudah tiba di konferensi, dan besok. Sesuatu seperti ini.

Sulit, tentu saja, untuk mempertahankan keseimbangan kerja/hidup ketika Anda memiliki begitu banyak waktu dalam perjalanan bisnis. Tetapi saya mencoba untuk mengkompensasi fakta bahwa, setidaknya ketika saya tidak dalam perjalanan bisnis, saya 100% bersama keluarga saya, saya tidak menjawab email di malam hari, saya mencoba untuk tidak berpartisipasi dalam panggilan telepon apa pun. di malam hari dan di akhir pekan. Ketika saya tidak dalam perjalanan bisnis dan ini adalah waktu keluarga, itu benar-benar 100% waktu keluarga. Apakah itu berhasil dan apakah itu menyelesaikan masalah? TIDAK. Tapi saya berharap entah bagaimana itu memberi kompensasi kepada keluarga saya selama saya pergi.

Salah satu laporan Baruch adalah “Kami memiliki DevOps. Mari kita pecat semua penguji"

Dengan jadwal yang begitu padat, apakah Anda berhasil mempertahankan tingkat teknis atau apakah Anda sudah beralih dari pemrograman?

Saya mencoba melakukan beberapa hal teknis sambil mempersiapkan pembicaraan saya dan kegiatan lain di konferensi. Ini semua adalah demo teknis, semacam laporan mini yang kami pegang di tribun. Ini bukan pemrograman-pemrograman, ini lebih merupakan integrasi, tetapi setidaknya beberapa pekerjaan teknis yang saya coba lakukan. Dengan cara ini, saya menjaga pengetahuan tentang produk kami, fitur baru, dan sebagainya.

Tentu saja, untuk mengatakan bahwa saya sekarang adalah pembuat kode hardcore yang sama dengan saya 7 tahun yang lalu mungkin tidak mungkin. Tidak yakin apakah ini buruk. Mungkin semacam evolusi alami. Ini kurang menarik bagi saya, dan waktu yang ada lebih sedikit, jadi, mungkin, Tuhan memberkati dia.

Saya masih menganggap diri saya spesialis teknis yang kuat, saya masih sadar akan apa yang terjadi, saya menjaga diri saya dalam kondisi yang baik. Ini adalah situasi hibrida saya saat ini.

Tolong beritahu kami beberapa cerita lucu atau situasi ekstrem yang terjadi pada Anda: ketinggalan pesawat / menghapus presentasi / mematikan listrik selama laporan / bagasi tidak tiba?

Dari situasi lucu, saya ingat hampir semua jenis kegagalan mimpi buruk yang terjadi di laporan. Wajar saja karena ini adalah situasi yang paling menegangkan, karena ini adalah penonton, waktu, dan Anda perlu memastikan bahwa mereka tidak menyia-nyiakannya dengan sia-sia.

Saya mengalami "layar biru kematian" di Windows dan Mac selama pembicaraan. Di Windows hal itu terjadi sekali, di Mac beberapa kali. Ini, tentu saja, membuat stres, tetapi entah bagaimana kami menyelesaikan masalah ini, komputer restart, saya terus mengatakan sesuatu saat ini, tetapi stresnya sangat besar.

Mungkin situasi paling lucu yang pernah saya alami adalah di konferensi Groovy. Saya tidak ingat persis di mana konferensi itu diadakan, saya pikir itu di sebuah hotel, dan di seberang hotel ini ada semacam konstruksi atau renovasi. Jadi saya berbicara tentang beberapa kode yang saya tulis, itu adalah demo. Ini adalah iterasi pertama dari demo yang dapat dimengerti tetapi mungkin tidak ditulis dengan baik. Dan saya baru saja akan memfaktorkan ulang dan memperbaikinya, dan saya menyebutkan beberapa frasa seperti "mencela diri sendiri" tentang fakta bahwa ini adalah "kode yang menyebalkan". Letaknya di lantai dua, dan saat itu derek di seberang lokasi konstruksi baru saja mengangkat toilet portable. Dan panggungnya berada di seberang jendela. Artinya, saya melihat keluar jendela ini, mengatakan "kode menyebalkan", dan toilet mengapung di luar jendela. Dan saya memberi tahu semua orang: "Berbalik, kami punya ilustrasi di sini." Ini mungkin slide terbaik dari pemikiran saya - toilet terbang dalam laporan saya, ketika saya berbicara tentang kode yang menyebalkan.

Bagasi tidak berasal dari cerita seperti ini - ini, pada prinsipnya, cerita biasa, bahkan tidak ada yang perlu dibicarakan. Kami dapat mengatur wawancara terpisah tentang semua jenis tip perjalanan, di mana Anda dapat berbicara tentang barang bawaan yang tidak sampai, tetapi tidak ada yang kritis.

Saya berusaha sangat keras untuk selalu terbang, datang dan hadir di semua konferensi yang saya janjikan, karena, sekali lagi, ini adalah waktu rakyat. Waktu orang tak ternilai harganya, karena itu adalah penghargaan kepercayaan yang mereka berikan kepada Anda. Dan jika pinjaman ini disia-siakan, maka tidak ada cara untuk mendapatkannya kembali nanti.

Jika seseorang menghabiskan waktu, datang ke konferensi untuk mendengarkan laporan saya, dan saya mengambilnya dan tidak datang, ini buruk, karena tidak ada cara untuk mengembalikan waktu orang tersebut. Oleh karena itu, sangat penting bagi saya untuk menepati semua janji saya dalam hal ini, dan sejauh ini semuanya berhasil.

Banyak orang berpikir seperti ini: “Mengapa pergi ke konferensi? Anda dapat menonton videonya di YouTube, dan Anda selalu dapat mengobrol secara online.” Menurut Anda mengapa peserta perlu menghadiri konferensi?

Pertanyaan bagus! Anda harus pergi ke konferensi demi jaringan. Itu tak ternilai harganya dan tidak ada cara lain untuk mendapatkannya. Saya sudah menyebutkan pentingnya komunikasi, komunikasi dan soft skill. Menonton video di YouTube, sayangnya, tidak memberikan pengalaman soft skill. Karena itu, seseorang harus pergi ke konferensi demi komunikasi.

Selain itu, setidaknya bagi saya, saat menonton video di YouTube, keterlibatannya sangat berbeda, dan materinya masuk dan diingat jauh lebih buruk. Mungkin ini murni untuk saya, tetapi saya curiga bahwa berada di aula untuk laporan dan menonton video di YouTube adalah hal yang sangat berbeda. Apalagi kalau reportnya bagus, menurut saya jauh lebih enak didengarkan secara live. Ini seperti mendengarkan konser langsung dan rekaman.

Dan saya ulangi sekali lagi: jaringan dan komunikasi tidak diambil dari YouTube.

Pembicaraan bersama dengan Leonid Igolnik di DevOpsCon

Bisakah Anda memberikan beberapa kata perpisahan kepada mereka yang baru akan menjadi pembicara atau baru mulai berbicara?

Cari pertemuan lokal. Pertemuan lokal adalah cara yang bagus untuk memulai karir pembicara Anda karena beberapa alasan. Pertama, pertemuan lokal selalu mencari pembicara. Mungkin tanpa pengalaman dan tanpa menjadi pembicara terkemuka, akan sulit bagi Anda untuk mendaftar ke beberapa konferensi terkenal, atau panitia program, setelah berbicara dengan Anda, akan mengerti bahwa mungkin ini terlalu dini untuk Anda. Sebaliknya, pertemuan lokal selalu mencari pembicara dan bilah entri jauh lebih rendah, sehingga jauh lebih mudah untuk sampai ke sana.

Juga, tingkat stresnya sangat berbeda. Ketika 10-15-30 orang datang, sama sekali tidak sama dengan ketika ada 150-200-300 orang di aula, jadi jauh lebih mudah.

Sekali lagi, biaya pertemuan lokal jauh lebih rendah: Anda tidak perlu terbang ke mana pun, Anda tidak perlu menghabiskan waktu berhari-hari, Anda bisa datang di malam hari. Mengingat nasihat saya tentang pentingnya memiliki wajah yang ramah di tengah keramaian, jauh lebih mudah untuk datang ke pertemuan lokal dengan seseorang karena tidak memerlukan biaya. Jika Anda berbicara di sebuah konferensi, Anda sebagai pembicara datang secara gratis, tetapi +1 Anda ini, yang akan menjadi wajah ramah di depan umum, perlu membeli tiket. Jika Anda tampil di pertemuan, tidak ada masalah seperti itu, Anda dapat membawa satu atau dua atau tiga teman yang akan menjadi wajah ramah di aula.

Dan nilai tambah lainnya adalah penyelenggara pertemuan memiliki lebih banyak kesempatan untuk membantu Anda. Karena penyelenggara konferensi akan memiliki, misalnya, 60 laporan yang perlu ditinjau, dipraktikkan, dan disiapkan. Dan penyelenggara pertemuan memiliki satu, dua atau tiga, jadi, tentu saja, lebih banyak perhatian akan diberikan kepada Anda.

Selain itu, mendapatkan umpan balik dari pertemuan lokal jauh lebih mudah. Anda telah menyelesaikan laporan Anda dan sekarang Anda dan audiens sudah berkomunikasi dan mendiskusikan sesuatu yang berkaitan dengan laporan Anda. Untuk konferensi besar, seringkali tidak demikian. Anda membuat laporan dan hanya itu. Audiens yang Anda miliki sebagai massa abu-abu selama laporan telah pergi, dan Anda tidak tahu apa-apa lagi tentang mereka, Anda tidak mendengar, Anda tidak akan mendapat umpan balik.

Apa pun yang dikatakan orang, pertemuan lokal adalah topik yang bagus secara umum dan khususnya untuk pemula.

7 Desember Baruch akan berbicara di konferensi DevOpsDays Moskow. Dalam laporannya, Baruch akan menganalisis kegagalan nyata yang terjadi setiap hari dan di mana saja saat memperbarui perangkat lunak. Ini akan menunjukkan kepada Anda bagaimana pola DevOps yang berbeda cocok dengan skenario yang berbeda dan bagaimana menerapkannya dengan benar dapat menyelamatkan Anda.

Juga di program: Alexander Chistyakov (vdsina.ru), Mikhail Chinkov (AMBOSS), Roman Boyko (AWS), Pavel Selivanov (Southbridge), Rodion Nagornov (Kaspersky Lab), Andrey Shorin (konsultan DevOps).

Ayo berkenalan!

Sumber: www.habr.com

Tambah komentar