Baruch Sadogursky - Developer Advocate tại JFrog, đồng tác giả cuốn sách “Liquid Software”, diễn giả CNTT nổi tiếng.
Trong một cuộc phỏng vấn, Baruch giải thích cách ông chuẩn bị cho các báo cáo của mình, các hội nghị nước ngoài khác với các hội nghị ở Nga như thế nào, tại sao những người tham gia nên tham dự và tại sao họ nên phát biểu trong trang phục ếch.
Hãy bắt đầu với cách đơn giản nhất. Tại sao bạn lại nghĩ đến việc phát biểu tại các hội nghị?
Trên thực tế, phát biểu tại các hội nghị là một công việc đối với tôi. Nếu chúng ta trả lời một cách tổng quát hơn câu hỏi “Tại sao công việc của tôi là vậy?”, thì điều này (ít nhất là đối với công ty JFrog) là đạt được hai mục tiêu. Đầu tiên, để thiết lập mối liên hệ với người dùng và khách hàng của chúng tôi. Nghĩa là, khi tôi phát biểu tại các hội nghị, tôi sẵn sàng để mọi người có bất kỳ câu hỏi nào, một số phản hồi về sản phẩm và công ty của chúng tôi, có thể nói chuyện với tôi, bằng cách nào đó tôi có thể giúp họ và cải thiện trải nghiệm của họ khi làm việc với các sản phẩm của chúng tôi.
Thứ hai, điều này là cần thiết để nâng cao nhận thức về thương hiệu. Nghĩa là, nếu tôi kể một số điều thú vị, thì mọi người sẽ quan tâm xem đây là loại JFrog nào và kết quả là họ sẽ đến kênh quan hệ nhà phát triển của chúng tôi, kênh này cuối cùng sẽ đi vào kênh người dùng của chúng tôi, kênh này cuối cùng sẽ đi vào kênh kênh người mua của chúng tôi.
Hãy cho chúng tôi biết bạn chuẩn bị cho buổi biểu diễn như thế nào? Có một số loại thuật toán chuẩn bị?
Có bốn giai đoạn chuẩn bị ít nhiều tiêu chuẩn. Đầu tiên là sự khởi đầu, giống như trong phim. Một ý tưởng nào đó phải xuất hiện. Một ý tưởng xuất hiện và sau đó nó trưởng thành trong một thời gian khá dài. Nó đang trưởng thành, bạn đang suy nghĩ về cách tốt nhất để trình bày ý tưởng này, bằng chìa khóa nào, ở hình thức nào, có thể nói gì về nó. Đây là giai đoạn đầu tiên.
Giai đoạn thứ hai là viết một kế hoạch cụ thể. Bạn có một ý tưởng và nó bắt đầu thu thập thông tin chi tiết về cách bạn sẽ trình bày ý tưởng đó. Điều này thường được thực hiện dưới dạng bản đồ tư duy nào đó, khi mọi thứ liên quan đến báo cáo đều xuất hiện xung quanh ý tưởng: các lập luận hỗ trợ, phần giới thiệu, một số câu chuyện mà bạn muốn kể về nó. Đây là giai đoạn thứ hai - kế hoạch.
Giai đoạn thứ ba là viết slide theo kế hoạch này. Bạn sử dụng một số ý tưởng trừu tượng xuất hiện trên các slide và hỗ trợ cho câu chuyện của mình.
Giai đoạn thứ tư là chạy thử và diễn tập. Ở giai đoạn này, điều quan trọng là phải đảm bảo rằng cốt truyện đã diễn ra, câu chuyện mạch lạc và đảm bảo rằng mọi thứ đều ổn về mặt thời gian. Sau đó, báo cáo có thể được tuyên bố sẵn sàng.
Làm thế nào để bạn hiểu rằng “chủ đề này” cần được giải quyết? Và làm thế nào để bạn thu thập tài liệu cho các báo cáo?
Tôi không biết trả lời thế nào, nó chỉ đến bằng cách nào đó. Hoặc là “Ồ, mọi chuyện ở đây thật tuyệt vời làm sao” hoặc là “Ồ, không ai thực sự biết hoặc hiểu về điều này” và có cơ hội để kể, giải thích và giúp đỡ. Một trong hai lựa chọn này.
Việc thu thập tài liệu phụ thuộc rất nhiều vào báo cáo. Nếu đây là một báo cáo về một chủ đề trừu tượng nào đó thì đó là tài liệu, bài báo nhiều hơn. Nếu đây là điều gì đó thiết thực thì đó sẽ là viết mã, một số bản demo, tìm đoạn mã phù hợp trong sản phẩm, v.v.
Sợ biểu diễn và lo lắng là một số lý do phổ biến nhất khiến mọi người không lên sân khấu. Bạn có lời khuyên nào dành cho những người cảm thấy lo lắng khi biểu diễn không? Bạn đang lo lắng và làm thế nào để đối phó?
Vâng, tôi có nó, lẽ ra phải như vậy, và có lẽ, vào thời điểm tôi không còn lo lắng nữa, đây là lý do để từ bỏ vấn đề này.
Đối với tôi, đây là hiện tượng hoàn toàn bình thường khi bạn lên sân khấu và có rất nhiều người đứng trước mặt. Bạn lo lắng vì đó là trách nhiệm lớn lao, đó là điều đương nhiên.
Làm thế nào để đối phó với điều này? Có nhiều cách khác nhau. Tôi chưa bao giờ gặp phải nó ở mức độ mà tôi cần phải chiến đấu trực tiếp với nó, vì vậy thật khó để tôi nói.
Điều quan trọng nhất cũng giúp ích cho tôi đó là một gương mặt thân thiện - một gương mặt quen thuộc nào đó trong khán giả. Nếu bạn nhờ ai đó bạn biết đến nói chuyện với bạn, hãy ngồi ở hàng ghế đầu ở giữa để bạn luôn có thể nhìn anh ấy, và người đó sẽ tích cực, sẽ mỉm cười, gật đầu, ủng hộ, tôi nghĩ đây là một điều rất lớn, sự giúp đỡ rất lớn. Tôi không đặc biệt yêu cầu ai làm việc này, nhưng nếu tình cờ có một gương mặt quen thuộc trong khán giả thì điều đó sẽ giúp ích rất nhiều và giảm bớt căng thẳng. Đây là lời khuyên quan trọng nhất.
Bạn nói rất nhiều tại các hội nghị của Nga và quốc tế. Bạn có thấy sự khác biệt giữa các báo cáo tại các hội nghị của Nga và nước ngoài không? Có sự khác biệt về khán giả? Trong tổ chức?
Tôi thấy có hai sự khác biệt lớn. Rõ ràng là các hội nghị ở Nga và nước ngoài đều khác nhau, nhưng nếu chúng ta lấy mức trung bình cho bệnh viện, thì ở Nga các hội nghị mang tính kỹ thuật hơn về độ sâu của báo cáo, về mặt chuyên môn. Đây là điều mà mọi người đã quen, có lẽ nhờ vào những hội nghị lớn như Joker, JPoint, Highload, những hội nghị luôn dựa trên những bài thuyết trình khó tính. Và đây chính xác là những gì mọi người mong đợi từ các hội nghị. Và đối với nhiều người, đây là dấu hiệu cho thấy hội nghị này tốt hay xấu: có nhiều thịt và thịt cứng hay có nhiều nước.
Thành thật mà nói, có lẽ do tôi phát biểu nhiều ở các hội nghị nước ngoài nên tôi không đồng tình với cách làm này. Tôi tin rằng các báo cáo về kỹ năng mềm, “báo cáo bán nhân đạo” cũng không kém cạnh và có lẽ còn quan trọng hơn đối với các hội nghị. Bởi vì một số vấn đề kỹ thuật cuối cùng có thể được đọc trong sách, bạn có thể tìm ra chúng bằng cách sử dụng sách hướng dẫn sử dụng, nhưng khi nói đến kỹ năng mềm, khi nói đến tâm lý học, khi nói đến giao tiếp, thì không có nơi nào có được tất cả những điều này, ít nhất là dễ dàng, dễ tiếp cận và dễ hiểu. Đối với tôi, có vẻ như điều này không kém phần quan trọng so với thành phần kỹ thuật.
Điều này đặc biệt quan trọng đối với các hội nghị DevOps như DevOpsDays, vì DevOps hoàn toàn không phải về công nghệ. DevOps chỉ là về giao tiếp, nó chỉ là về cách để những người chưa từng làm việc cùng nhau trước đây có thể làm việc cùng nhau. Đúng, có một thành phần kỹ thuật, vì tự động hóa rất quan trọng đối với DevOps, nhưng đây chỉ là một trong số đó. Và khi một hội nghị DevOps, thay vì nói về DevOps, lại nói về độ tin cậy của trang web, tự động hóa hoặc quy trình, thì hội nghị này, mặc dù thực tế là rất khó, theo ý kiến của tôi, đã bỏ lỡ bản chất cốt lõi của DevOps và trở thành hội nghị về quản trị hệ thống , không phải về DevOps.
Sự khác biệt thứ hai là ở sự chuẩn bị. Một lần nữa, tôi lấy trường hợp trung bình của bệnh viện và các trường hợp chung, không phải trường hợp cụ thể. Ở nước ngoài, họ cho rằng hầu hết mọi người đều đã trải qua một số hình thức đào tạo nói trước công chúng trong đời. Ít nhất ở Mỹ, nó là một phần của giáo dục đại học. Nếu một người đã tốt nghiệp đại học thì người đó đã có kinh nghiệm đáng kể về diễn thuyết trước công chúng. Vì vậy, sau khi ban chương trình đã xem xét kế hoạch và hiểu nội dung của báo cáo, họ sẽ không đào tạo thêm về cách nói cho diễn giả nữa, vì người ta tin rằng rất có thể người đó sẽ biết cách thực hiện.
Ở Nga, những giả định như vậy không được đưa ra vì ít người có kinh nghiệm nói trước đám đông và do đó các diễn giả được đào tạo nhiều hơn. Một lần nữa, nói chung, có những khóa học xuyên suốt, có những lớp học với diễn giả, có những khóa học nói trước công chúng để hỗ trợ các diễn giả.
Kết quả là, những người nói yếu và giao tiếp kém sẽ bị loại hoặc họ được giúp đỡ để trở thành người thuyết trình giỏi hơn. Việc ở phương Tây nói trước công chúng được coi là một kỹ năng mà nhiều người có được, cuối cùng lại gây tác dụng ngược, bởi giả định này thường tỏ ra sai lầm, sai lầm và những người không biết cách nói chuyện trước công chúng sẽ mắc sai lầm một cách công khai. sân khấu và đưa ra những báo cáo kinh tởm. Và ở Nga, nơi người ta tin rằng không có kinh nghiệm nói trước công chúng, cuối cùng thì mọi việc lại tốt hơn nhiều, bởi vì họ đã được đào tạo, họ đã được kiểm tra, họ đã chọn được người giỏi, v.v.
Đây là hai điểm khác biệt.
Bạn đã từng tham dự DevOpsDays ở các quốc gia khác chưa? Bạn nghĩ chúng khác với những hội nghị khác như thế nào? Có tính năng đặc biệt nào không?
Có lẽ tôi đã từng tham dự vài chục hội nghị DevOpsDays trên khắp thế giới: ở Mỹ, Châu Âu và Châu Á. Nhượng quyền hội nghị này khá độc đáo ở chỗ nó có một định dạng ít nhiều đã được thiết lập mà bạn có thể mong đợi ở bất kỳ đâu từ bất kỳ hội nghị nào trong số này. Hình thức như sau: tương đối ít bài thuyết trình hội nghị tuyến đầu và dành nhiều thời gian cho hình thức không gian mở.
Không gian mở là một hình thức trong đó chủ đề được nhiều người bình chọn nhất sẽ được thảo luận cùng với những người tham gia khác. Người đề xuất chủ đề này là người lãnh đạo, anh ta đảm bảo rằng cuộc thảo luận sẽ bắt đầu. Đây là một định dạng tuyệt vời vì như chúng ta biết, giao tiếp và kết nối mạng là những phần không kém phần quan trọng của bất kỳ hội nghị nào so với các bài thuyết trình. Và khi một hội nghị dành một nửa thời gian cho hình thức kết nối mạng, điều đó thật tuyệt.
Ngoài ra, Lightning Talks thường được tổ chức tại DevOpsDays - đây là những báo cáo ngắn năm phút cho phép bạn tìm hiểu nhiều điều và mở mang tầm mắt về một số điều mới ở định dạng không nhàm chán. Và nếu ở giữa một bản báo cáo thông thường mà bạn nhận ra rằng đây không phải là của mình, thì thời gian sẽ bị lãng phí, 30-40 phút cuộc đời bạn bị lãng phí, thì ở đây chúng ta đang nói về những bản báo cáo dài XNUMX phút. Và nếu bạn không quan tâm, nó sẽ kết thúc sớm. “Hãy cho chúng tôi biết, nhưng nhanh lên” cũng là một định dạng rất hay.
Có nhiều DevOpsDays kỹ thuật hơn và có những DevOpsDay được thiết kế riêng cho DevOps là gì: quy trình, cộng tác, những thứ tương tự. Thật thú vị khi có cả hai và thật thú vị khi có cả hai. Tôi nghĩ đây là một trong những thương hiệu hội nghị DevOps tốt nhất hiện nay.
Nhiều màn trình diễn của bạn tương tự như các buổi biểu diễn hoặc vở kịch: đôi khi bạn diễn thuyết dưới dạng một vở bi kịch Hy Lạp, đôi khi bạn đóng vai Sherlock, đôi khi bạn biểu diễn trong trang phục ếch. Làm thế nào để bạn nghĩ ra chúng? Ngoài mục đích làm cho báo cáo không nhàm chán, bạn còn có mục tiêu nào khác nữa không?
Đối với tôi, dường như một bản báo cáo không có quyền nhàm chán, bởi vì, thứ nhất, tôi lãng phí thời gian của người nghe, trong một bản báo cáo nhàm chán, họ ít tham gia hơn, họ học được ít hơn, họ học được ít điều mới hơn, và điều này không phải vậy. sự lãng phí thời gian tốt nhất của họ. Thứ hai, mục tiêu của tôi cũng chưa đạt được: họ không nghĩ gì tốt về tôi, họ không nghĩ gì tốt về JFrog, và đối với tôi đây là một kiểu thất bại.
Vì vậy, những báo cáo nhàm chán không có quyền tồn tại, ít nhất là đối với tôi. Tôi cố gắng làm cho chúng thú vị, hấp dẫn và đáng nhớ. Biểu diễn là một cách. Và trên thực tế, phương pháp này khá dễ dàng. Tất cả những gì bạn cần là nghĩ ra một số định dạng thú vị và sau đó trình bày những suy nghĩ tương tự được trình bày dưới dạng một báo cáo thông thường ở một định dạng khác thường.
Làm thế nào để tôi nghĩ ra điều này? Nó không phải lúc nào cũng giống nhau. Đôi khi đây là một số ý tưởng chợt đến trong đầu tôi, đôi khi đây là một số ý tưởng nảy ra trong đầu tôi khi tôi xem xét kỹ lưỡng hoặc chia sẻ suy nghĩ về một báo cáo và họ nói với tôi: “Ồ, có thể làm được như thế này!” Nó xảy ra khác nhau. Khi một ý tưởng xuất hiện, nó luôn rất vui vẻ và thú vị, điều này có nghĩa là bạn có thể thực hiện một báo cáo thú vị và hấp dẫn hơn.
Cá nhân bạn thích bài phát biểu của ai trong lĩnh vực CNTT? Có những chiếc loa như vậy? Và tại sao?
Có hai loại diễn giả mà tôi thích thuyết trình. Đầu tiên là những chiếc loa mà tôi cố gắng trở thành. Họ nói chuyện một cách thú vị và hấp dẫn, cố gắng đảm bảo rằng mọi người đều quan tâm và lắng nghe.
Loại diễn giả thứ hai là những người có thể nói về bất kỳ người khó tính nào thường nhàm chán một cách rất thú vị và hấp dẫn.
Trong số những cái tên thuộc loại thứ hai, đây là Alexey Shepelev, người nói về một số loại bộ sưu tập rác hiệu suất sâu và nội dung bên trong của máy ảo java một cách thú vị và hài hước. Một khám phá khác về DevOops mới nhất là Sergey Fedorov từ Netflix. Anh ấy kể một điều thuần túy mang tính kỹ thuật về cách họ tối ưu hóa mạng phân phối nội dung của mình và anh ấy kể điều đó theo một cách rất thú vị.
Từ hạng mục đầu tiên - đó là Jessica Deen, Anton Weiss, Roman Shaposhnik. Đây là những diễn giả nói chuyện thú vị, hài hước và xứng đáng nhận được đánh giá cao.
Bạn có thể nhận được nhiều lời mời phát biểu tại các hội nghị hơn là thời gian để làm điều đó. Làm thế nào để bạn chọn nơi bạn sẽ đi và nơi không?
Các hội nghị và diễn giả, giống như hầu hết mọi thứ khác, bị chi phối bởi các mối quan hệ thị trường giữa cung và cầu cũng như giá trị của cái này với cái kia. Có những hội nghị mà, có thể nói, muốn tôi nhiều hơn là tôi cần chúng. Về mặt khán giả, tôi mong đợi được gặp ở đó và tác động mà tôi mong đợi sẽ tạo ra ở đó. Có những hội nghị, ngược lại, tôi muốn tham dự nhiều hơn mức họ cần tôi. Dựa trên giá trị đối với tôi, tôi quyết định nơi để đi.
Nghĩa là, chẳng hạn, nếu đây là một loại địa lý nào đó mà tôi cần đến một cách chiến lược, thì đây là một hội nghị lớn, nổi tiếng, có danh tiếng tốt và mọi người sẽ đến dự, thì rõ ràng là tôi thực sự cần nó. Và tôi thích nó hơn các hội nghị khác.
Nếu đây là một loại hội nghị khu vực nhỏ nào đó, và có lẽ, nơi chúng tôi không quan tâm lắm, thì có thể chuyến đi đến đó không phù hợp với thời gian dành cho vấn đề này. Quan hệ thị trường bình thường về cung, cầu và giá trị.
Địa lý tốt, nhân khẩu học tốt, khả năng liên lạc tốt, khả năng giao tiếp là những đảm bảo rằng hội nghị sẽ rất thú vị đối với tôi.
Trong một cuộc phỏng vấn, bạn đã đề cập rằng bạn phát biểu tại khoảng XNUMX hội nghị mỗi năm. Bạn làm việc và chuẩn bị cho buổi biểu diễn như thế nào? Và bạn có thể duy trì được sự cân bằng giữa công việc và cuộc sống với lịch trình như vậy không? Chia sẻ bí mật của bạn?
Đi dự các hội nghị là phần lớn công việc của tôi. Tất nhiên, còn có mọi thứ khác: chuẩn bị cho các báo cáo, giữ vững kỹ thuật, viết mã, học hỏi những điều mới. Tất cả điều này được thực hiện song song với các hội nghị: vào buổi tối, trên máy bay, ngày hôm trước, khi bạn đã đến dự hội nghị và đó là ngày mai. Một cái gì đó như thế này.
Tất nhiên, thật khó để duy trì sự cân bằng giữa công việc và cuộc sống khi bạn dành quá nhiều thời gian cho những chuyến công tác. Nhưng tôi cố gắng bù đắp điều này bằng việc, ít nhất là khi không đi công tác, tôi dành 100% cho gia đình, không trả lời email vào buổi tối, tôi cố gắng không tham gia bất kỳ hoạt động nào. cuộc gọi vào buổi tối và cuối tuần. Khi tôi không đi công tác và đó là thời gian dành cho gia đình, đó thực sự là thời gian dành cho gia đình 100%. Điều này có hiệu quả và nó có giải quyết được vấn đề không? KHÔNG. Nhưng tôi hy vọng rằng điều này sẽ phần nào bù đắp cho gia đình tôi trong suốt thời gian tôi xa nhà.
Với một lịch trình chặt chẽ như vậy, bạn có thể duy trì trình độ kỹ thuật của mình hay bạn đã rời bỏ công việc lập trình?
Tôi cố gắng thực hiện một số vấn đề kỹ thuật trong khi chuẩn bị cho bài nói chuyện của mình và các hoạt động khác tại hội nghị. Đây là tất cả các loại trình diễn kỹ thuật, một số báo cáo nhỏ mà chúng tôi đưa ra tại khán đài. Đó không phải là lập trình mã hóa, mà là sự tích hợp nhiều hơn, nhưng ít nhất đó là một số công việc kỹ thuật mà tôi cố gắng thực hiện. Bằng cách này, tôi duy trì được kiến thức về sản phẩm của chúng tôi, các tính năng mới, v.v.
Tất nhiên, có lẽ không thể nói rằng bây giờ tôi vẫn là một lập trình viên hạng nặng như 7 năm trước. Không chắc đó có phải là điều xấu không. Đây có lẽ là một loại tiến hóa tự nhiên. Điều này đối với tôi kém thú vị hơn và tôi có ít thời gian hơn, vì vậy, có lẽ, Chúa phù hộ cho anh ấy.
Tôi vẫn coi mình là một chuyên gia kỹ thuật giỏi, tôi vẫn bám sát những gì đang diễn ra, tôi luôn cảnh giác. Đây là tình huống lai của tôi ngày hôm nay.
Hãy kể cho chúng tôi một vài câu chuyện hài hước hoặc những tình huống cực đoan đã xảy ra với bạn: lỡ chuyến bay/xóa bài thuyết trình/cắt điện khi báo cáo/hành lý không đến?
Trong số những tình huống hài hước, điều tôi nhớ nhất là tất cả những thất bại khủng khiếp xảy ra trong quá trình báo cáo. Đương nhiên, vì đây là tình huống căng thẳng nhất, vì đó là khán giả, thời gian và bạn cần đảm bảo rằng họ không lãng phí nó.
Tôi gặp phải “màn hình xanh chết chóc” trên cả Windows và Mac trong buổi nói chuyện. Trên Windows nó xảy ra một lần, trên Mac một vài lần. Tất nhiên, điều này rất căng thẳng, nhưng bằng cách nào đó chúng tôi giải quyết được vấn đề này, máy tính khởi động lại, tôi tiếp tục nói điều gì đó vào lúc này, nhưng sự căng thẳng là rất lớn.
Có lẽ tình huống hài hước nhất mà tôi gặp phải là tại hội nghị Groovy. Tôi không nhớ chính xác hội nghị được tổ chức ở đâu, có vẻ như trong một khách sạn và đối diện khách sạn này đang có một công trình xây dựng hoặc cải tạo nào đó đang diễn ra. Và vì vậy tôi đã nói về một số mã mà tôi đã viết, đó là bản demo. Đây là lần lặp lại đầu tiên của bản demo, điều này có thể hiểu được nhưng có lẽ được viết không tốt. Và tôi vừa định cấu trúc lại và cải thiện nó, đồng thời tôi đã đề cập đến một số cụm từ như “tự ti” về thực tế rằng đây là “mã rác rưởi”. Nó ở trên tầng hai, lúc đó có một chiếc cần cẩu ở công trường đối diện vừa nâng một nhà vệ sinh di động. Và sân khấu thì đối diện với cửa sổ. Tức là tôi nhìn ra ngoài cửa sổ này, nói “mã chết tiệt” và một cái bồn cầu bay ngang qua cửa sổ. Và tôi nói với mọi người: “Quay lại, chúng ta có hình minh họa ở đây.” Đây có lẽ là slide hay nhất trong suy nghĩ của tôi - cái toilet bay trong báo cáo của tôi khi tôi nói về những dòng code vớ vẩn.
Từ những câu chuyện như hành lý không đến - về nguyên tắc, đây là một câu chuyện bình thường, thậm chí không có gì để nói. Chúng ta có thể sắp xếp một cuộc phỏng vấn riêng về tất cả các mẹo du lịch, nơi chúng ta có thể nói về hành lý chưa đến nơi nhưng không có gì quan trọng.
Tôi cố gắng hết sức bằng mọi giá để luôn bay, đến và tham dự tất cả các hội nghị mà tôi đã hứa, bởi vì, một lần nữa, đã đến lúc của mọi người. Thời gian của mọi người là vô giá vì đó là niềm tin mà họ dành cho bạn. Và nếu khoản vay này bị lãng phí thì sau này không có cách nào lấy lại được.
Nếu một người dành thời gian đến hội nghị để nghe báo cáo của tôi, tôi lấy mà không đến thì thật tệ, vì không có cách nào lấy lại được thời gian của người này. Vì vậy, điều cực kỳ quan trọng đối với tôi là phải giữ mọi lời hứa của mình về vấn đề này và cho đến nay mọi thứ vẫn ổn.
Nhiều người nghĩ như thế này: “Sao lại đi dự hội nghị? Bạn có thể xem video trên YouTube và bạn luôn có thể trò chuyện trực tuyến ”. Tại sao bạn nghĩ người tham gia cần phải đi dự hội nghị?
Câu hỏi tuyệt vời! Bạn nên đến các hội nghị để kết nối mạng. Điều này là vô giá và không có cách nào khác để có được nó. Tôi đã đề cập đến tầm quan trọng của giao tiếp, giao tiếp và kỹ năng mềm. Thật không may, việc xem video trên YouTube không mang lại trải nghiệm về kỹ năng mềm. Vì vậy, bạn cần phải đến các hội nghị để giao tiếp.
Ngoài ra, ít nhất đối với tôi, khi xem video trên YouTube, mức độ tương tác hoàn toàn khác, nội dung được ghi nhớ và ghi nhớ kém hơn rất nhiều. Có lẽ chỉ có tôi, nhưng tôi nghi ngờ rằng việc ở trong phòng nói chuyện và xem video trên YouTube là những việc hoàn toàn khác nhau. Đặc biệt nếu bản báo cáo hay, đối với tôi, có vẻ như việc nghe nó trực tiếp sẽ tốt hơn rất nhiều. Nó giống như nghe một buổi hòa nhạc trực tiếp và một bản thu âm.
Và tôi nhắc lại một lần nữa: kết nối mạng và giao tiếp không phải là thứ bạn có thể lấy được từ YouTube.
Xin gửi đôi lời chia tay đến những người mới có ý định làm diễn giả hoặc mới bắt đầu phát biểu?
Tìm kiếm các cuộc gặp gỡ địa phương. Những cuộc gặp gỡ tại địa phương là một cách tuyệt vời để bắt đầu sự nghiệp diễn thuyết của bạn vì nhiều lý do. Thứ nhất, các cuộc gặp gỡ địa phương luôn tìm kiếm diễn giả. Có thể nếu không có kinh nghiệm và không phải là diễn giả nổi tiếng, bạn sẽ khó nộp đơn tham gia một hội nghị nổi tiếng nào đó, hoặc ban tổ chức chương trình sau khi trao đổi với bạn sẽ hiểu rằng có thể vẫn còn hơi sớm đối với bạn. Ngược lại, các cuộc gặp mặt ở địa phương luôn tìm kiếm diễn giả và yêu cầu đầu vào thấp hơn rất nhiều, vì vậy việc đến đó sẽ dễ dàng hơn nhiều.
Ngoài ra, mức độ căng thẳng là hoàn toàn khác nhau. Khi 10-15-30 người đến, không giống như khi có 150-200-300 người trong hội trường nên dễ dàng hơn nhiều.
Một lần nữa, chi phí cho một cuộc gặp mặt ở địa phương thấp hơn nhiều: bạn không cần phải bay đi đâu cả, không cần phải mất nhiều ngày, bạn chỉ cần đến vào buổi tối. Hãy nhớ lời khuyên của tôi về tầm quan trọng của việc có một gương mặt thân thiện trước khán giả, việc đến gặp ai đó ở địa phương sẽ dễ dàng hơn nhiều vì điều đó không tốn tiền. Nếu bạn phát biểu tại một hội nghị, bạn với tư cách là diễn giả sẽ đến miễn phí, nhưng +1 này của bạn, người sẽ là gương mặt thân thiện trước công chúng, cần phải mua vé. Nếu bạn đang phát biểu tại một cuộc gặp mặt, không có vấn đề gì như vậy, bạn có thể dẫn theo một hoặc hai hoặc ba người bạn, những người sẽ là gương mặt thân thiện trong phòng.
Và một điểm cộng nữa là người tổ chức Meetup có nhiều cơ hội hơn để giúp đỡ bạn. Bởi vì những người tổ chức hội nghị chẳng hạn sẽ có 60 bài thuyết trình cần được xem xét, thực hành và chuẩn bị. Và người tổ chức các buổi gặp mặt có một, hai hoặc ba nên đương nhiên bạn sẽ nhận được nhiều sự chú ý hơn.
Ngoài ra, việc nhận phản hồi từ các cuộc gặp mặt ở địa phương sẽ dễ dàng hơn nhiều. Bạn đã hoàn thành báo cáo của mình và bây giờ bạn và khán giả đang trao đổi và thảo luận về điều gì đó liên quan đến báo cáo của bạn. Đối với các hội nghị lớn, điều này thường không xảy ra. Bạn đã báo cáo và thế là xong. Khán giả, vốn là một khối xám xịt trong báo cáo của bạn, đã rời đi và bạn không còn biết gì về họ nữa, bạn không nghe thấy gì, bạn sẽ không nhận được bất kỳ phản hồi nào.
Dù người ta có thể nói gì thì các cuộc gặp gỡ tại địa phương là một chủ đề tuyệt vời nói chung và dành cho những người mới bắt đầu nói riêng.
Baruch sẽ phát biểu tại hội nghị vào ngày 7 tháng XNUMX . Trong báo cáo của mình, Baruch sẽ phân tích những lỗi thực sự xảy ra hàng ngày và ở mọi nơi khi cập nhật phần mềm. Nó sẽ cho thấy tất cả các loại mẫu DevOps phù hợp với các tình huống khác nhau như thế nào và việc áp dụng chúng một cách chính xác có thể giúp bạn tiết kiệm như thế nào.
Cũng tham gia chương trình: Alexander Chistykov (vdsina.ru), Mikhail Chinkov (AMBOSS), Roman Boyko (AWS), Pavel Selivanov (Southbridge), Rodion Nagornov (Kaspersky Lab), Andrey Shorin (cố vấn DevOps).
Hãy đến làm quen nhé!
Nguồn: www.habr.com