Sổ tay Developer Advocacy
(developer-advocacy.com)Phiên bản mới nhất của “Sổ tay Developer Evangelist” mà Christian Heilmann đã công bố cách đây 15 năm
- Developer Advocacy / Evangelism là gì?
→ Định nghĩa
→ Tư duy đúng đắn: người tạo ra thay đổi cho nhà phát triển
→ Vai trò và phát huy điểm mạnh
- Hợp tác với chính công ty của bạn
→ Chuẩn bị trước định kiến: một vai trò độc đáo trải rộng qua nhiều chức năng. Đừng nản lòng
→ Ứng phó với thay đổi trong công ty: tuân thủ quy trình pháp lý. Không có chuyện “off-the-record”. Đừng hành động theo cảm xúc hay tự suy diễn
→ Ở bên các nhà phát triển nội bộ: hãy lắng nghe
→ Phối hợp với PR và marketing: không phải đối thủ, hãy giao tiếp liên tục
→ Được nhận diện là kênh đối ngoại: cho các thành viên biết bạn đang kết nối với những kênh nào
→ Đào tạo các Advocate khác và đội ngũ developer: tổ chức đào tạo, chia sẻ nội bộ và phản hồi từ bên ngoài
→ Chia sẻ kỹ thuật hữu ích: trao đổi nội bộ về những kỹ thuật đã học được
→ Cân bằng giữa kênh cá nhân và kênh chính thức
→ Gỡ bỏ thương hiệu cá nhân khỏi thương hiệu công ty: tách bản thân khỏi brand của công ty. Chỉ tập trung vào việc giúp developer có thể thử nghiệm và khám phá sản phẩm
- Hợp tác với đối thủ cạnh tranh
→ Khi làm việc cùng đối thủ:
✓ Hãy là người độc lập, quan tâm đến những gì thú vị bất kể đó là sản phẩm của công ty nào
✓ Luôn làm quen với cái mới
→ Tôn trọng đối thủ: không thể vừa là một DA xuất sắc vừa là người hiếu chiến.
→ Thừa nhận khi sản phẩm của đối thủ tốt hơn: hãy là người đánh giá cao công nghệ tốt, không sợ cạnh tranh mà còn chào đón nó, đồng thời có thể phản hồi lại cho đội nội bộ
→ Hiểu về đối thủ: muốn so sánh thì trước hết phải hiểu họ
→ Tạo và thử dùng ví dụ bằng sản phẩm cạnh tranh: có thể so sánh và nắm được điểm khác biệt
- Chuẩn bị Outreach
→ Nắm chính xác sự thật: hỏi kỹ đội sản phẩm về đặc tả chính xác, tính năng, và cả những gì sản phẩm không làm được
→ Hiểu khán giả và nhu cầu của họ
→ Chuẩn bị chuyên gia hỗ trợ:
✓ Ghi lại những câu hỏi không trả lời được để follow-up sau
✓ Đừng hứa những điều mà bạn không chắc đội sản phẩm có thể cung cấp
→ Chọn phương tiện phù hợp: slide, video, audio, live coding, ví dụ từng bước trực tuyến...
→ Chuẩn bị cho thất bại:
✓ Bản sao cục bộ và trực tuyến của slide.
✓ Lưu riêng vào USB.
✓ Nếu không dùng được slide thì vẫn có thể chuyển sang Q&A
✓ Luôn giả định online có thể không dùng được, nên chuẩn bị bản local hoặc hotspot
- Tìm kiếm cơ hội phát biểu
→ Tham gia podcast
→ Tham gia panel: trở thành chuyên gia về một chủ đề cụ thể hoặc là thành viên của một nhóm
→ Tham dự barcamp/meetup: các bài nói ngắn
→ Viết bài cho tạp chí online và các kênh tương tự
→ Tổ chức brown bag session: seminar giờ trưa
→ Đặt câu hỏi tại conference
→ Trở thành diễn giả mà người ta muốn mời: công khai & đăng các chủ đề nói chuyện (term) của bạn
✓ Thông tin cá nhân, tiểu sử mới nhất, slide/video các bài nói gần đây
✓ Chủ đề bạn muốn trình bày, công nghệ bạn sử dụng
✓ Những điều bạn mong muốn từ conference organizer, v.v.
- Công tác và tham dự conference
→ Mẹo đi công tác: chừa một ngày đệm, đi lại tiết kiệm
→ Ai sẽ chi trả chi phí?
→ Tại conference, hãy tham dự nhiều sự kiện khác nhau và giao lưu với các diễn giả khác
→ Tận dụng social media khi tham gia sự kiện:
✓ Để lại thông tin liên hệ mạng xã hội trong slide
✓ Chia sẻ việc tham dự conference bằng hashtag, v.v.
✓ Chia sẻ nội dung thú vị hoặc các bài nói hay
✓ Chia sẻ lại tin tức từ conference organizer
✓ Đăng slide online và cho mọi người biết
→ Xây dựng network thông qua sự kiện
→ Tạo calendar để theo dõi việc tham dự sự kiện và lưu lại lịch sử
→ Tận dụng conference buzz
→ Trở thành một phần của conference mà bạn phát biểu
→ Phát hành ngay bài nói và tài liệu liên quan
→ Viết bài về conference
- Trình bày talk và workshop
→ Hãy là chính mình: tài sản lớn nhất là niềm tin vào bản thân.
→ Mời gọi giao tiếp
→ Chuẩn bị các tài liệu mang về (takeaways) cho người tham dự
→ Chuẩn bị phần QA và kiểm soát nó thật tốt
→ Trung thực, chỉ nói sự thật: đừng đoán mò khi không biết câu trả lời
→ Follow-up trao đổi sau bài nói
- Mẹo thuyết trình: giữ thời gian và nhiều thứ khác
→ Làm sao nhét tất cả những điều này vào X phút
→ Less is More: bắt đầu bằng một điều quan trọng (insight, kết quả nghiên cứu, hiện trạng của X, tính năng mới của sản phẩm X). Mọi người sẽ nhớ điều gì sau bài nói này?
→ Bài trình bày của bạn chỉ cực kỳ quan trọng với chính bạn
✓ Bài nói của bạn chỉ là một trong vô số thứ khác
✓ Bài nói của bạn sẽ được ghi hình và lan truyền nhiều nơi
✓ Mọi người sẽ không nhớ toàn bộ nội dung bài nói
✓ Mọi người không cần bạn chỉ để lấy thông tin. Họ có thể dễ dàng tìm thấy thông tin đó online
→ Sắp xếp thêm thông tin bổ sung
→ Live coding? Những điều cần cẩn trọng
→ Tránh câu hỏi
→ Những thứ nên cắt bớt: slide mục lục, thông tin công ty, giới thiệu cá nhân, trò đùa và meme
→ Những thứ có thể dùng làm filler trong lúc trình bày: nơi đặt tài liệu, cách liên hệ, đồng nghiệp và chuyên gia khác để liên hệ...
→ Chuẩn bị phần tóm tắt bài nói
- Những điều không nên nói trên sân khấu và cách thay thế
→ “Cái này dễ lắm”: “Để làm việc này, chỉ cần đi qua vài bước như sau”, “Các công cụ này có tài liệu rất tốt nên bạn cũng có thể...”
→ “Xin nhắc lại ngắn gọn cho những ai chưa biết”: “Nói lại thì X là...”, “Như bạn đã biết, X là...”
→ “Ai cũng làm được”: “Làm như vậy sẽ giúp phần việc còn lại trở nên thú vị hơn”, “Vì nó rất hiệu quả nên hãy thử và chia sẻ với người khác”
→ “X sẽ giải quyết vấn đề này nên đừng lo”: “Vì X xử lý được các vấn đề liên quan đến Y nên bạn có thể tạo ra Z”
“X được tạo ra để giúp việc Y dễ hơn và đã được dùng thực tế. Kết quả cũng rất đáng khích lệ”
→ “Như mọi người đều biết”: “Gần đây chủ đề này được nói đến nhiều và X (link) giải thích rất rõ...”..
→ “Như chúng ta đã học ở trường”: “Đây là một phần của chương trình khoa học máy tính và có lý do để nó được dạy như vậy”
→ “Y (sản phẩm của chúng tôi) tốt hơn (đối thủ) X rất nhiều.”: “Đây là cách làm bằng X. Chúng tôi chọn cách khác và đây là lý do.”
“Có nhiều cách giải quyết việc này. Chúng tôi biết rằng X thiếu một vài tính năng có thể giúp hiệu quả hơn...”
→ “Chỉ cần vài dòng code là xong”: “Như bạn thấy, có thể bắt đầu chỉ với vài dòng code. Tôi đã đơn giản hóa để demo ở đây và source code nằm tại X”
→ “Muốn trở thành chuyên gia (professional), hãy làm X”: “Điểm mạnh của X là Y, vì thế nó trở thành một công cụ chuyên nghiệp để sử dụng.
→ Ngoài ra, hãy xem lại bài nói/video của chính bạn rồi nghĩ rằng “Nếu mình chưa biết điều này, nghe câu này sẽ cảm thấy thế nào”, sau đó bỏ bớt hoặc diễn đạt lại
- Viết bài và bài báo thật tốt
→ Simple is not stupid: viết dễ hiểu và đơn giản là việc rất khó. Hãy dùng từ ngữ dễ, thuật ngữ mà nhiều người đọc có thể hiểu, và câu văn ngắn gọn
→ Hãy nói vào bản chất. Đừng sugar-coat
→ Độ dài bài viết rất quan trọng. Bài kỹ thuật cho online nên ngắn và đi thẳng vào cốt lõi. Nếu quá dài, hãy tách thành nhiều bài
→ Bổ sung nhiều media liên quan. Video, audio, slide, hình ảnh, v.v.
→ Cấu trúc nội dung bằng heading theo cấp bậc, v.v.
→ Nội dung cũng cần có thời hạn hiệu lực.
→ Trích dẫn tài liệu khác để chứng minh
→ Viết bài mang tính pre-emptive - hãy khiến sản phẩm của bạn thu hút sự quan tâm của developer. Việc “bán hàng” là của đội sales
- Viết code sample xuất sắc
→ Giải quyết vấn đề thông qua ví dụ
→ Cho thấy ví dụ có chạy được
→ Giải thích môi trường cần thiết
→ Viết code có thể copy & paste được
→ Cung cấp file tải về cho ví dụ
→ Viết ví dụ gọn gàng và thông minh
→ Hosting code và demo
✓ Quản lý version là bạn đồng hành của bạn
✓ Tự động hosting
✓ Dùng code sandbox
✓ Môi trường live coding
- Chuẩn bị slide thuyết trình thật tốt
→ Biết rõ chính xác những gì bạn biết
→ Bắt đầu từ bản thân nội dung thay vì từ slide
→ Bắt đầu viết bằng định dạng văn bản có tính portable
→ Mẹo tạo slide nhanh: tách nhỏ các bullet
→ Chọn và chuẩn bị công cụ trình bày phù hợp cho việc thuyết trình
✓ Có thể thay đổi được bất kể là 16:9 hay 4:3
✓ Dễ cắt và resize hình ảnh
✓ Có thể tự do di chuyển đối tượng trên màn hình
✓ Có thể điều khiển từ xa
✓ Chuyển đổi mượt mà sang tài liệu trình bày khác
✓ Hỗ trợ toàn màn hình
✓ Có thể hiện từng phần một
- Tạo slide thật tốt cho thuyết trình
→ Đừng ghi chép lại nguyên văn lời nói, hãy giải thích bằng câu ngắn/hình ảnh/screenshot/biểu đồ
→ Tìm và dùng hình ảnh tốt
→ Làm cho code sample dễ nhìn
→ Mẹo tận dụng âm thanh và video
→ Chỉ dùng animation khi cần (đừng quá lòe loẹt)
→ Ngắn gọn - nếu có thể chỉ bao phủ một topic
→ Cân nhắc khán giả
→ Khi có template của công ty hoặc conference
→ Cá nhân hóa (nội hóa) mọi tài liệu trước khi dùng: đừng tái sử dụng nguyên xi tài liệu nhận từ người khác
→ Chia sẻ và tận hưởng
→ Các mẹo thuyết trình bổ sung
✓ Giới thiệu bản thân: vì sao tôi là người phù hợp để trình bày chủ đề này, và vì sao/tôi muốn nói điều gì
✓ Dùng hài hước: cẩn thận đừng công kích người khác
✓ Tạo kết nối với thực tế
✓ Điều chỉnh tốc độ, đừng quá nhanh: những khoảng dừng ngắn có lợi cho khán giả
✓ Tránh “Hello World”
✓ Nếu có thể, hãy dùng slide mới. Cập nhật lên phiên bản mới nhất
- Checklist để có bài trình bày dễ hiểu hơn, dễ tiếp cận hơn và dễ chuyển thành hành động hơn
→ Tài liệu trình bày
✓ Là HTML/PPTX/PDF chứ?
✓ Code có ở online không?
✓ Video/audio nhúng có phát được bất kể OS nào và cả khi offline không?
→ Định dạng
✓ Media nhúng có hỗ trợ accessibility không? (caption, chuỗi thay thế, transcript, v.v.)
✓ Font có đủ lớn không?
✓ Kích thước có phù hợp với conference không? 16x9, 4x3
✓ Độ tương phản (contrast) có đủ để vẫn nhìn rõ ngay cả khi máy chiếu có vấn đề không?
✓ Có lề an toàn đủ rộng để dù máy chiếu cắt bớt vẫn không sao không?
✓ Có cần font thay thế khi trình bày trên máy không phải máy của bạn không?
→ Nội dung
✓ Có chứa nội dung công kích hoặc có thể gây kích hoạt tiêu cực không?
✓ Có thể hiểu được mà không cần bối cảnh cụ thể không?
✓ Có thuật ngữ nào mà người phiên dịch/thông dịch cần biết trước không?
✓ Nếu chỉ một phần/một slide bị tách ra và chia sẻ riêng thì có gây hiểu nhầm không?
✓ Tất cả media và tài liệu đã ghi nguồn và kiểm tra bản quyền chưa?
→ Theo dõi
✓ Có thể biết ai đã tải tài liệu trình bày không?
✓ Ở slide cuối có Call-to-Action và link tải xuống không?
→ Bảo hiểm
✓ Mọi tài liệu có thể truy cập offline bất kể máy tính nào không? (bao gồm slide/ví dụ/media, tất cả đều có trong USB)
✓ Khi video/audio không chạy đúng, có tài liệu giải thích thay thế đã chuẩn bị sẵn không?
- Ghi chép lại mọi công việc
→ Ghi âm tất cả các bài nói
→ Nếu có thể, ghi hình video
→ Gom toàn bộ link đã dùng trong bài nói vào một chỗ và lưu lại
→ Ghi lại danh sách tất cả conference đã tham dự/sẽ tham dự: gồm slide/blog/link/video link
- Hiểu và sử dụng web (social)
→ Tìm nội dung web chất lượng
→ Phân phối lại nội dung web: viết blog, lưu vào các trang social bookmarking, dùng trong slide, trích dẫn trong mailing list hoặc forum, đăng Twitter
✓ Nhất định phải attribution cho tác giả gốc
→ Quảng bá bản thân trên web
→ Dùng các website và sản phẩm social mạnh mẽ: Flickr, YouTube, Vimeo, Archive.org, GitHub, LinkedIn, Facebook, Meetup, Twitter
→ Dùng web như kho lưu trữ, kênh phân phối và công cụ cross-promotion
→ Đưa gợi ý về sản phẩm, tease và công bố preview
→ Theo dõi hiệu quả: thêm telemetry vào tài liệu/blog, subscribe comment feed, dùng URL shortener có tracking
→ Xây dựng network
→ Tạo hoặc tham gia newsletter
→ Tạo hoặc tham gia podcast
- Làm việc trên máy tính của tôi
→ Thiết bị: microphone ngoài, monitor, camera, ánh sáng
→ Ghi screencast và screenshot
→ Streaming
→ Tham gia chat online thời gian thực
→ Những điều cần lưu ý và mẹo khi tham gia sự kiện online thời gian thực
- Mẹo ghi hình bài trình bày online của tôi
4 bình luận
Tên ở các phiên bản trước là Developer Evangelist Handbook, nhưng dạo gần đây người ta dùng từ Advocacy thay cho Evangelist/Evangelism nên tôi đã phản ánh điều đó.
Đây cũng là cuốn sách mà khi tôi làm Developer Evangelist vào năm 2010, tôi đã tham khảo gần như một cuốn kinh thánh.
Tác giả là một người kỳ cựu, đã làm lập trình viên 20 năm và trong hơn 10 năm qua đã làm công việc này tại Yahoo, Mozilla và Microsoft.
Có nhiều cách gọi như Developer Advocate/Evangelist/Relations, nhưng tôi nghĩ sẽ rất hữu ích cho tất cả những ai làm công việc liên quan, cũng như các lập trình viên thường xuyên thuyết trình bên ngoài, nếu tham khảo cuốn này.
Trong việc làm slide thuyết trình, câu “không cá nhân hóa thì đừng tái sử dụng - Don't reuse without personalising” cũng là điều tôi đặc biệt nhấn mạnh.
Nếu dùng hình ảnh/sơ đồ lấy từ đâu đó, sẽ có nhiều chỗ không khớp, và cũng thường có trường hợp chính bản thân người dùng lại chưa hiểu hết sơ đồ đó.
Nếu có thể, tôi khuyên nên vẽ lại và sử dụng theo đúng cách bạn diễn giải, phù hợp với concept bài thuyết trình của chính mình.
Cảm ơn vì phần tổng hợp rất hay. Câu “đừng cá nhân hóa, đừng tái sử dụng - Don't reuse without personalising” nghe khá sát nghĩa từng chữ, nên trong ngữ cảnh anh/chị nói thì diễn đạt kiểu như “nội hóa rồi tái sử dụng” có lẽ sẽ dễ hiểu hơn.
Đúng là khi viết ra mới thấy vậy ^^; mình đã phản ánh nhẹ vào rồi. Cảm ơn bạn
@_@)b