"Laporan itu tidak berhak membosankan": sebuah wawancara dengan Baruch Sadogursky tentang berbicara di konferensi

Baruch Sadogursky - Pengembang Advokat di JFrog, penulis bersama Liquid Software, seorang pembicara IT yang terkenal.

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



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

Sebenarnya, bagi saya, berbicara di konferensi adalah pekerjaan. Jika Anda menjawab lebih global untuk pertanyaan "Kenapa pekerjaan saya?", Maka ini untuk itu (setidaknya untuk JFrog) untuk mencapai dua tujuan. Pertama, untuk menjalin kontak dengan pengguna dan pelanggan kami. Yaitu, ketika saya berbicara di konferensi, saya tersedia sehingga setiap orang yang memiliki beberapa pertanyaan, beberapa umpan balik mengenai produk dan perusahaan kami, dapat berbicara kepada saya, saya dapat membantu mereka dan meningkatkan pengalaman mereka. dalam bekerja dengan produk kami.

Kedua, perlu untuk meningkatkan kesadaran merek. Artinya, jika saya memberi tahu Anda beberapa hal menarik, orang-orang tertarik pada jenis JFrog apa itu, dan sebagai hasilnya ia masuk ke corong hubungan pengembang kami, yang akhirnya masuk ke corong pengguna kami, yang akhirnya masuk ke corong pelanggan kami.

Katakan, tolong, bagaimana Anda mempersiapkan pertunjukan Anda? Apakah ada algoritma persiapan?

Ada empat langkah persiapan standar kurang lebih. Yang pertama adalah awal, seperti di film. Beberapa ide harus muncul. Sebuah ide muncul, dan kemudian matang untuk waktu yang agak lama. Itu matang, Anda berpikir bagaimana lebih baik untuk menyajikan ide ini, dalam nada apa, dalam format apa, apa yang bisa dikatakan tentang ini. Ini adalah tahap pertama.

Tahap kedua adalah menulis rencana spesifik. Anda punya ide, dan itu mulai tumbuh menjadi rincian tentang bagaimana Anda akan mempresentasikannya. Biasanya ini dilakukan dalam format semacam mind-map, ketika segala sesuatu yang terkait 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 untuk rencana ini. Anda menggunakan beberapa ide abstrak yang muncul di slide dan mendukung cerita Anda.

Tahap keempat adalah lari, latihan. Pada tahap ini, penting untuk memastikan bahwa lengkungan cerita telah berubah, bahwa cerita terhubung, untuk memastikan bahwa semuanya normal dalam waktu. Setelah itu, laporan dapat dinyatakan siap.

Bagaimana Anda memahami bahwa "topik ini" perlu ditangani? Dan bagaimana Anda mengetik materi untuk laporan?

Saya tidak tahu bagaimana menjawab, itu sendiri entah bagaimana datang. Atau "Oh, betapa kerennya itu berubah di sini", atau "Oh, tidak ada yang benar-benar tahu dan mengerti tentang hal itu" dan ada peluang untuk memberi tahu, menjelaskan, dan membantu. Salah satu dari dua opsi ini.

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

Kinerja Baruch di DevOps Summit Amsterdam 2019 baru-baru ini

Ketakutan akan pertunjukan dan kegembiraan adalah beberapa alasan paling umum mengapa orang tidak naik ke panggung. Bisakah Anda memberi saran kepada mereka yang khawatir selama pertunjukan? Apakah Anda khawatir dan bagaimana Anda menghadapinya?

Ya, saya memilikinya, itu harus, dan, mungkin, pada saat saya berhenti khawatir sama sekali, ini adalah kesempatan untuk mengikat dengan masalah ini.

Menurut saya ini benar-benar normal ketika Anda naik panggung dan ada banyak orang di depan Anda. Anda khawatir karena itu adalah tanggung jawab besar, itu wajar.

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

Hal terpenting yang juga membantu saya adalah wajah ramah - wajah yang akrab di antara hadirin. Jika Anda meminta seseorang yang Anda kenal untuk datang ke laporan Anda, untuk duduk di barisan depan di tengah sehingga Anda selalu dapat melihatnya, dan orang itu akan positif, akan tersenyum, mengangguk, mendukung, saya pikir ini sangat, sangat membantu . Saya tidak secara khusus bertanya kepada siapa pun tentang hal ini, tetapi jika itu terjadi bahwa ada wajah yang akrab di antara hadirin, itu sangat membantu dan mengurangi stres. Ini adalah saran yang paling penting.

Anda banyak berbicara di konferensi Rusia dan internasional. Apakah Anda melihat perbedaan antara laporan di konferensi Rusia dan asing? Apakah ada perbedaan audiens? Di 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 teknis dalam hal kedalaman laporan, dalam hal hardcore. Inilah yang biasa dilakukan orang, mungkin berkat konferensi besar seperti Joker, JPoint, Highload, yang selalu berdasarkan pada presentasi yang keras. Dan orang-orang berharap dari konferensi persis ini. Dan bagi banyak orang, ini merupakan indikator apakah konferensi itu baik atau buruk: ada banyak daging dan hardcore di sana atau ada banyak air.

Sejujurnya, mungkin karena saya banyak berbicara di konferensi asing, saya tidak setuju dengan pendekatan ini. Saya percaya bahwa laporan tentang soft skill, “laporan semi-kemanusiaan” tidak kurang, dan mungkin bahkan lebih penting untuk konferensi. Karena Anda dapat membaca beberapa hal teknis dalam buku-buku, Anda dapat mengetahui manualnya, tetapi berkenaan dengan soft skill, berkenaan dengan psikologi, berkenaan dengan komunikasi, tidak ada tempat untuk mengambil semuanya, setidaknya mudah, mudah diakses, dan dimengerti. Tampak bagi saya bahwa ini tidak kalah pentingnya dengan komponen teknis.

Ini sangat penting untuk konferensi di DevOps, seperti DevOpsDays, karena DevOps sama sekali bukan tentang teknologi. DevOps hanya tentang komunikasi, ini tentang cara untuk bekerja bersama untuk orang-orang yang tidak bekerja bersama sebelumnya. Ya, ada komponen teknis di sana, karena otomatisasi sangat penting untuk DevOps, tetapi ini hanya salah satunya. Dan ketika konferensi DevOps, alih-alih berbicara tentang DevOps, berbicara tentang keandalan atau otomasi situs, atau tentang saluran pipa, konferensi ini, terlepas dari kenyataan bahwa itu sangat hardcore, menurut pendapat saya, hanya melewatkan esensi dari DevOps dan menjadi konferensi tentang administrasi sistem, bukan tentang DevOps.

Perbedaan kedua adalah persiapan. Sekali lagi, saya mengambil rata-rata untuk rumah sakit dan kasus umum, bukan yang pribadi. Di luar negeri, diasumsikan bahwa sebagian besar orang telah menjalani pelatihan berbicara di depan umum dalam kehidupan mereka. Setidaknya di Amerika, itu adalah bagian dari pendidikan tinggi. Jika seseorang lulus dari perguruan tinggi, maka dia sudah memiliki pengalaman yang cukup dalam berbicara di depan umum. Oleh karena itu, setelah panitia program melihat rencana tersebut dan menyadari akan seperti apa laporan itu, tidak ada lagi pelatihan pidato untuk pembicara, karena diyakini bahwa ia kemungkinan besar tahu caranya.

Di Rusia, asumsi semacam itu tidak dibuat, karena sedikit orang yang memiliki pengalaman berbicara di depan umum, dan karena itu penuturnya jauh lebih terlatih. Sekali lagi, dalam kasus umum, ada kursus berjalan, ada kelas dengan pembicara, ada kursus berbicara di depan umum untuk membantu pembicara.

Akibatnya, penutur yang lemah yang berbicara buruk, tersingkir, atau dibantu untuk menjadi penutur yang lebih kuat. Fakta bahwa berbicara di muka umum di Barat dianggap sebagai keterampilan yang oleh banyak orang berdampak sebaliknya, karena anggapan ini seringkali ternyata salah, keliru, dan orang-orang yang tidak tahu bagaimana berbicara di depan umum secara terbuka mengacau di panggung dan mendapatkan laporan yang menjijikkan. Dan di Rusia, di mana diyakini tidak ada pengalaman berbicara di depan umum, hasilnya jauh lebih baik, karena mereka dilatih, diuji, dipilih yang baik, dan sebagainya.

Inilah dua perbedaan.

Anda pernah ke DevOpsDays di negara lain? Menurut Anda bagaimana mereka berbeda dari konferensi lain? Apakah ada fitur?

Saya mungkin berada di beberapa lusin konferensi DevOpsDays di seluruh dunia: di Amerika, dan di Eropa, dan di Asia. Waralaba konferensi ini cukup unik karena memiliki format yang kurang lebih mapan yang dapat Anda harapkan dari konferensi mana pun. Formatnya begini: ada relatif sedikit presentasi konferensi front-end, dan banyak waktu dikhususkan untuk format ruang terbuka.

Ruang terbuka adalah format di mana topik yang dipilih banyak orang dibahas dengan peserta lain. Orang yang mengusulkan topik ini - dia adalah tuan rumah, dia memulai diskusi. Ini adalah format yang luar biasa, karena, seperti kita ketahui, komunikasi dan jaringan tidak kalah penting dari konferensi mana pun selain laporan. Dan ketika konferensi meletakkan sebagian waktunya di bawah format jaringan - ini sangat keren.

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

Ada DevOpsDays lebih teknis, ada yang dirancang khusus untuk apa DevOps adalah: proses, kolaborasi, ini adalah hal-hal. Ini menarik baik itu dan yang lain, dan itu menarik ketika ada keduanya, dan yang lain. Menurut saya, hari ini, ini adalah salah satu waralaba konferensi terbaik tentang DevOps.

Banyak pertunjukan Anda mirip dengan pertunjukan atau pertunjukan: kemudian Anda memberi tahu laporan dalam bentuk tragedi Yunani, kemudian Anda memainkan peran Sherlock, lalu Anda bertindak dalam kostum katak. Bagaimana Anda menemukan mereka? Apakah ada tujuan tambahan selain membuat laporannya membosankan?

Tampaknya bagi saya bahwa laporan itu tidak memiliki hak untuk menjadi membosankan, karena, pertama, saya menghabiskan waktu untuk siswa saya, mereka kurang terlibat dalam laporan membosankan, mereka telah belajar lebih sedikit, mereka telah belajar lebih sedikit, dan ini bukan buang-buang waktu terbaik mereka. Kedua, tujuan saya belum tercapai: mereka tidak memikirkan hal baik tentang saya, mereka tidak memikirkan hal baik tentang JFrog, dan bagi saya itu semacam kegagalan.

Karena itu, laporan yang membosankan tidak memiliki hak untuk ada, setidaknya untuk saya. Saya mencoba membuatnya menarik, menarik dan berkesan. Pertunjukan adalah satu arah. Dan, sebenarnya, metode ini cukup mudah. Semua yang diperlukan adalah menghasilkan beberapa format yang menarik, dan kemudian pemikiran yang sama yang disajikan dalam bentuk laporan reguler, ditetapkan dalam format yang tidak biasa.

Bagaimana saya membuat ini? Itu terjadi dalam berbagai cara. Terkadang beberapa ide yang muncul di benak saya, kadang-kadang beberapa ide yang mereka berikan kepada saya ketika saya berlari atau membagikan pemikiran saya tentang laporan dan mereka berkata kepada saya: "Oh, itu bisa dilakukan seperti ini!" ini terjadi secara berbeda. Ketika sebuah ide muncul, itu selalu sangat menyenangkan dan keren, yang berarti bahwa laporan yang lebih menarik dan terlibat dapat dibuat.



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

Ada dua jenis speaker yang penampilannya saya suka. Yang pertama adalah pembicara yang saya coba menjadi. Mereka bercerita menarik dan terlibat, mencoba membuat semua orang tertarik dan mendengarkan.

Tipe kedua dari speaker adalah mereka yang dapat mengatakan dengan sangat menarik dan mengasyikkan tentang hardcore yang biasanya membosankan.

Dari nama-nama dalam kategori kedua, ini adalah Aleksey Shepelev, yang berbicara tentang beberapa pengumpulan sampah kinerja mendalam dan bagian dalam mesin virtual java, yang menarik dan lucu. Pembukaan DevOops terbaru lainnya adalah Sergey Fedorov dari Netflix. Dia mengatakan hal yang murni teknis tentang bagaimana mereka mengoptimalkan jaringan pengiriman konten mereka, dan dia mengatakannya dengan sangat menarik.

Dari kategori pertama adalah Jessica Deen, Anton Weiss, Roman Shaposhnik. Mereka adalah pembicara yang menceritakan dengan menarik, dengan humor, dan pantas menerima peringkat tinggi.

Tentunya Anda memiliki lebih banyak undangan untuk berbicara di konferensi daripada waktu untuk ini. Bagaimana Anda memilih ke mana Anda pergi dan ke mana tidak?

Konferensi dan pembicara, seperti hampir semua yang lain, diatur oleh hubungan pasar penawaran dan permintaan dan nilai satu sama lain. Ada beberapa konferensi yang, lebih tepatnya, menginginkan saya lebih daripada yang saya butuhkan. Dari segi audiensi yang saya harapkan akan bertemu di sana, dan dampak yang saya harapkan untuk bawa ke sana. Ada konferensi yang, sebaliknya, saya ingin mendapatkan lebih dari yang mereka butuhkan. Dalam hal nilai bagi saya, saya memutuskan ke mana harus pergi.

Yaitu, jika ini, misalnya, adalah semacam geografi, di mana saya perlu secara strategis untuk masuk, ini adalah konferensi besar yang terkenal, yang memiliki reputasi baik, dan yang akan dihadiri orang, maka jelas saya benar-benar membutuhkannya. Dan saya lebih suka ke konferensi lain.

Jika ini adalah semacam konferensi regional kecil, dan mungkin di mana kita tidak terlalu tertarik, maka mungkin perjalanan di sana tidak membenarkan biaya waktu yang akan dimasukkan ke dalam bisnis ini. Hubungan permintaan, penawaran, dan nilai pasar yang normal.

Geografi yang baik, demografi yang baik, kontak yang berpotensi bagus, komunikasi - kunci fakta bahwa konferensi itu akan menarik bagi saya.

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

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

Tentu saja sulit untuk menjaga keseimbangan kerja / hidup ketika ada begitu banyak waktu dalam perjalanan bisnis. Tetapi saya mencoba untuk mengkompensasi hal ini dengan fakta bahwa, setidaknya ketika saya tidak dalam perjalanan bisnis, saya 100% dengan keluarga saya, saya tidak menjawab email di malam hari, saya mencoba untuk tidak berpartisipasi dalam panggilan telepon di malam hari dan di akhir pekan. Ketika saya tidak dalam perjalanan bisnis dan ini adalah waktu keluarga, maka ini benar-benar 100% waktu keluarga. Apakah ini berhasil dan apakah itu menyelesaikan masalah? Tidak. Tetapi saya berharap bahwa ini entah bagaimana memberikan kompensasi bagi keluarga saya selama saya tidak hadir.

Salah satu laporan Baruch adalah "Kami memiliki DevOps. Ayo tembak semua penguji ”

Dengan jadwal yang begitu ketat, apakah Anda berhasil mempertahankan level teknis atau sudah pindah dari pemrograman?

Saya mencoba melakukan beberapa hal teknis sambil mempersiapkan laporan dan kegiatan lainnya di konferensi. Ini semua jenis demo teknis, beberapa laporan mini yang kami pegang di stan. Ini bukan pemrograman, ini lebih integrasi, tapi ini setidaknya beberapa pekerjaan teknis yang saya coba lakukan. Dengan cara ini, saya mempertahankan pengetahuan tentang produk kami, fitur-fitur baru, dan sebagainya.

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

Saya masih menganggap diri saya sebagai spesialis teknis yang kuat, saya masih sadar apa yang terjadi, saya menjaga diri saya dalam kondisi yang baik. Inilah situasi hibrida saya hari ini.

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

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

Saya memiliki "layar biru kematian" pada Windows dan Mac selama pembicaraan. Di Windows dulu, di Mac beberapa kali. Ini, tentu saja, sangat menegangkan, tetapi kami entah bagaimana menyelesaikan masalah ini, komputer restart, saya terus mengatakan sesuatu saat ini, tetapi stresnya sangat besar.

Mungkin situasi terlucu yang saya miliki di konferensi Groovy. Saya tidak ingat persis di mana konferensi itu diadakan, tampaknya, di sebuah hotel, dan di depan hotel ini ada semacam konstruksi atau perbaikan. Jadi saya berbicara tentang semacam kode yang saya tulis, itu demo. Ini adalah iterasi pertama dari demo, yang bisa dimengerti, tapi mungkin tidak ditulis dengan cara terbaik. Dan saya akan hanya refactor dan memperbaikinya, dan menyebutkan semacam frase seperti "mencela diri sendiri" tentang fakta bahwa ini adalah "kode menyebalkan". Itu di lantai dua, dan saat ini derek di lokasi konstruksi di seberang hanya mengangkat toilet portabel. Dan pemandangan itu di seberang jendela. Yaitu, saya melihat melalui jendela ini, mengatakan "kode menyebalkan", dan toilet mengapung di luar jendela. Dan saya memberi tahu semua orang: "Berbalik, kami punya ilustrasi di sini." Itu mungkin slide terbaik dari pikiran saya - toilet terbang dalam pembicaraan saya ketika saya berbicara tentang kode menyebalkan.

Bagasi tidak berasal dari kisah-kisah seperti ini - pada prinsipnya, ini adalah cerita normal, tidak ada yang bisa dibicarakan. Kami dapat mengatur wawancara terpisah tentang semua jenis kiat perjalanan, di mana Anda dapat berbicara tentang bagasi yang tidak tiba, tetapi tidak ada yang penting.

Saya berusaha keras dengan segala cara untuk selalu terbang, datang dan menghadiri semua konferensi yang saya janjikan, karena, sekali lagi, sudah waktunya bagi orang-orang. Waktu orang sangat berharga karena itu adalah jenis kepercayaan yang mereka berikan kepada Anda. Dan jika pinjaman ini dibodohi, maka Anda tidak bisa mendapatkannya saat itu.

Jika seseorang meluangkan waktu, datang ke konferensi untuk mendengarkan laporan saya, tetapi saya mengambilnya dan tidak datang, ini buruk, karena tidak ada cara untuk mengembalikan waktu kepada orang ini. , .

: « ? , ». , ?

! . - . , soft skills. , , soft skills. .

, , , . , , , — . , , , - . .

: — .

DevOpsCon

, , - , ?

. — . -, . , , - , , , , . , - , .

, . 10-15-30 — , 150-200-300 , .

, : , , . , , -, . , , +1, , . , , -- , .

— . , , 60 , , . — , , , , .

, . -, . . . , , , , , .

, — .

Pada 7 Desember, Baruch akan berbicara di konferensi Moskow DevOpsDays . Dalam laporan tersebut, Baruch akan menganalisis kegagalan nyata yang terjadi setiap hari dan di mana-mana saat memperbarui perangkat lunak. Dia akan menunjukkan bagaimana semua jenis pola DevOps masuk ke dalam skenario yang berbeda dan bagaimana aplikasi yang tepat bisa menyelamatkan Anda.

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

Ayo berkenalan!