- Developer Relations hoặc Developer Advocacy
→ thường là một vai trò tồn tại ở các công ty có thị trường mục tiêu chủ yếu là lập trình viên
→ thực hiện các hoạt động như xây dựng cộng đồng, tạo nội dung hoặc cải thiện trải nghiệm dành cho lập trình viên của sản phẩm để giúp các nhà phát triển biết đến một sản phẩm hoặc công nghệ cụ thể
3 kiểu DevRel
- Community Builder: DevRel tập trung vào cộng đồng
- vai trò xây dựng cộng đồng lập trình viên
- giúp lập trình viên nhận được giá trị thông qua các hoạt động như tổ chức sự kiện, livestream, vận hành Slack/Discord, trao đổi và tiếp nhận phản hồi
- Developer Educator: DevRel tập trung vào nội dung
- quảng bá sản phẩm thông qua bài viết hoặc bài thuyết trình
- blog, video, workshop, podcast, tweet, v.v.
- trong ngắn hạn có thể chạy các hoạt động quảng bá, còn về dài hạn thì thậm chí cân nhắc cả SEO
- DX Engineer: DevRel tập trung vào sản phẩm
- người chịu trách nhiệm về trải nghiệm dành cho lập trình viên của sản phẩm (cải thiện cách các lập trình viên cảm nhận về sản phẩm)
- trò chuyện trực tiếp với lập trình viên và cải thiện tài liệu cũng như hướng dẫn dựa trên ý kiến của họ
- cũng thực hiện các công việc như ví dụ mã, template, integration
Tìm việc trong DevRel
- đây là một lĩnh vực rất hot
- nhiều startup đang tìm kiếm những DevRel giỏi
- những kỹ năng chính để ứng tuyển vào DevRel
- kỹ năng lập trình: để đồng cảm với lập trình viên thì cần phải có khả năng code
- khả năng xây dựng cộng đồng: sẽ rất tốt nếu có kinh nghiệm tạo và vận hành cộng đồng, như ở trường đại học, mã nguồn mở hoặc cộng đồng trực tuyến
- khả năng tạo nội dung: khả năng thuyết trình, làm video YouTube, đăng tweet và viết blog
Lời khuyên cho DevRel
- How to engage developers
- Show, don’t tell.: đừng chỉ nói, hãy cho thấy (để họ có thể nhanh chóng dùng thử sản phẩm)
- Features not benefits: thể hiện các tính năng một cách trực quan và so sánh với sản phẩm khác.
- Be genuinely helpful: hãy đầu tư vào tài liệu chất lượng cao (tài liệu API, trang trợ giúp được duy trì tốt, video hướng dẫn, mẫu use case, v.v.). Đồng thời hãy giúp họ dễ dàng liên hệ khi cần thêm hỗ trợ
- Be Direct: hãy hiểu lập trình viên và tưởng tượng như đang viết trực tiếp cho từng người. Làm vậy sẽ giúp tạo ra nội dung thực sự hữu ích thay vì câu chữ mang tính bán hàng
- Think beyond the 9-to-5.: nhiều lập trình viên thực hiện các side project về nhiều chủ đề khác nhau, cả trong và ngoài công việc
- Repurpose Content: hãy tái sử dụng cùng một nội dung nhiều nhất có thể. Xây dựng pipeline kiểu tweet → blog → video → bài nói chuyện tại hội nghị
- Have a "breakable toy": hãy có một ứng dụng thật để có thể thử áp dụng công nghệ mới và cho thấy các chỉ số thay đổi theo đó. Nó nên nhỏ nhưng phải là thật. Ví dụ như trình theo dõi tập luyện đơn giản, công cụ lên kế hoạch ăn uống, công cụ ghi chú. Sẽ càng tốt nếu có một vài người dùng thật là bạn và bạn bè của bạn
- Các tài liệu khác liên quan đến DevRel
2 bình luận
Tôi cũng nghĩ như vậy. Khi văn hóa phát triển phần mềm phát triển, dường như đương nhiên là các loại công việc cũng cần đa dạng hơn và được phân chia chi tiết hơn. Thay vì chỉ tập trung vào việc tạo ra sản phẩm rồi chia thành vị trí phát triển và quản lý, tôi mong sẽ xuất hiện thêm nhiều vai trò đa dạng cần thiết cho việc phát triển và quảng bá sản phẩm. Việc không chỉ chia thành DevRel/Advocate mà còn bổ sung thêm DX là một điểm rất hay. Tôi không biết việc các thành viên trong đội DevRel của Chrome chuyển việc khá nhiều sang vị trí DX ở Spotify có thể xem là một ví dụ điển hình hay không. Cá nhân tôi rất quan tâm đến lĩnh vực này, nhưng vị trí thì thật sự...
Các nhân vật chính trong bài viết đó phần lớn là đội DevRel của Vercel, nên việc DevRel được định nghĩa bởi một startup mới nổi(?) thay vì từ một tổ chức DevRel lâu năm khiến tôi thấy khá thú vị.
Ở nước ngoài thì chủ đề này rất hot... nhưng ở trong nước thì... ừm... hu hu
Tuy vậy, tôi nghĩ đây là một vai trò thật sự cần thiết.