บริษัทบริการนักพัฒนาจำนวนมากขึ้นกำลังลงทุนอย่างหนัก สร้างทีม DevRel ของบริษัทตนเองโดยห้อมล้อมผลิตภัณฑ์ บริการ API และอื่นๆ
แต่บริษัทต่างๆ มีความเข้าใจ DevRel แตกต่างกัน: บางบริษัทจ้าง “วิศวกรส่งเสริมเทคโนโลยี (Developer Advocate)” เต็มเวลา บางบริษัทจ้าง “ผู้เผยแพร่เทคโนโลยี (Developer Evangelists)” บางบริษัทคิดว่า DevRel คือ “การตลาดที่มุ่งเป้าไปที่นักพัฒนา” บางคนมอง DevRel เป็นกุญแจสำคัญในการรับข้อเสนอแนะผลิตภัณฑ์และส่งเสริมความสำเร็จของผลิตภัณฑ์ จะตัดสินได้อย่างไรว่าบทบาทและรูปแบบกิจกรรมใดเหมาะสมกับบริษัทของคุณมากที่สุด? ความแตกต่างของตำแหน่งต่างๆ คืออะไร?
“ความสัมพันธ์นักพัฒนา” หมายถึงอะไรสำหรับบริษัท? ขึ้นอยู่กับเป้าหมายของบริษัท เพื่ออธิบายสถานการณ์ ให้เราอ้างอิงภารกิจของแผนก DevRel ของ Google และ Twilio แต่โปรดทราบว่าประโยคสั้นๆ อาจไม่สามารถแสดงทุกสิ่งที่ทีม DevRel ทำจริงได้
บทบาทของความสัมพันธ์นักพัฒนาคือการสร้างระบบนิเวศนักพัฒนาบุคคลที่สามที่มีชีวิตชีวาผ่านการสื่อสารสองทางระหว่างนักพัฒนากับแพลตฟอร์ม วิศวกรรม และการออกแบบของบริษัท
Twilio
งานของเราคือสร้างแรงบันดาลใจและช่วยเหลือนักพัฒนาให้สร้างแอปพลิเคชันที่น่าทึ่งรุ่นถัดไป หมายถึงการเข้าใจว่าพวกเขาพยายามทำอะไร ชี้ทางเครื่องมือและให้การฝึกอบรม และช่วยให้พวกเขาประสบความสำเร็จ
Google ใช้คำว่า “the interface between” แสดงให้เห็นว่า DevRel คาดหวังให้สร้างสะพานเชื่อมการสื่อสารสองทางระหว่างผู้ตัดสินใจเรื่องผลิตภัณฑ์และนักพัฒนา (ผู้ใช้ผลิตภัณฑ์) ทัศนคติของ Twilio แสดงให้เห็นว่า DevRel เหมือนเป็น “บทบาททางการศึกษา” แบบทางเดียว ช่วยนักพัฒนาใช้ผลิตภัณฑ์ Twilio
Michael Mahemoff เพิ่งเขียนบทความ Developer Relations: A Five-Level Maturity Model ในบทความนี้เขาอธิบายขั้นตอนการพัฒนาของแผนก DevRel ในบริษัท จากไม่มีแผนก DevRel ไปจนถึงสามารถวัดค่ากลยุทธ์ได้อย่างสมบูรณ์
ในบริบทของ “วางกลยุทธ์ DevRel ของบริษัทอย่างไร” ฉันต้องปรับนิยามของ Michael:
- ไม่มี (None) ภายในบริษัทไม่มีกลไกสนับสนุนนักพัฒนาหรือรวบรวมข้อเสนอแนะจากนักพัฒนา
- ไม่เป็นทางการ (Informal) แผนกอื่นของบริษัทรับผิดชอบบทบาทบางส่วนของ DevRel PR รับผิดชอบการส่งเสริมแบรนด์ BD รับผิดชอบบางส่วนในการสนับสนุนนักพัฒนา และนักพัฒนาประจำของผลิตภัณฑ์ก็ต้องรับผิดชอบการบรรยายในชุมชนบางส่วน
- พันธมิตร (Partnerships) ความสัมพันธ์กับพันธมิตรที่มีค่า มักซ่อนอยู่ (มักเป็นบริษัทใหญ่ มีทรัพยากรเพียงพอที่จะสร้างคุณสมบัติผลิตภัณฑ์ใหม่)
- ผู้เผยแพร่ (Evangelism) ส่งเสริมและสนับสนุนผลิตภัณฑ์ของบริษัทอย่างกว้างขวางผ่านการประชุม พันธมิตร และสื่อออนไลน์
- วิศวกรส่งเสริม (Advocacy) ความสัมพันธ์แบบสองทาง ไม่เพียงแต่มีส่วนร่วมในการพัฒนาผลิตภัณฑ์ แต่ยังส่งเสริมให้นักพัฒนาภายนอกใช้ผลิตภัณฑ์ของบริษัท รวบรวมข้อเสนอแนะบั๊กและคำขอคุณสมบัติใหม่ ในขณะเดียวกันพัฒนาเครื่องมือสนับสนุนเพื่อปรับปรุงประสบการณ์การใช้งานของนักพัฒนา
จากการวิเคราะห์ข้างต้น สรุป: Twilio ดำเนินงาน DevRel แบบ “ผู้เผยแพร่เทคโนโลยี” ในขณะที่ Google ใช้แบบ “วิศวกรส่งเสริม”
Michael ชี้ให้เห็นว่า: วิธีดำเนินงาน DevRel ที่ถูกต้องขึ้นอยู่กับเป้าหมายของโครงการ DevRel ของบริษัท ตัวอย่างเช่น ถ้าบริษัทคาดหวังเพียงการเพิ่มการรับรู้แบรนด์ หรือเข้าร่วมกิจกรรมเล็กน้อยเพื่อลดต้นทุน บริษัทควรใช้แนวทาง “ผู้เผยแพร่เทคโนโลยี” ในการดำเนินงาน DevRel ถ้าให้ความสำคัญกับการรวบรวมข้อเสนอแนะการใช้งานผลิตภัณฑ์จากนักพัฒนาบุคคลที่สาม การใช้แนวทาง “วิศวกรส่งเสริม” อาจได้ผลดีที่สุด
โดยสรุป การลงทุนใน DevRel ส่งเสริมธุรกิจต่างๆ ของบริษัท ดังนั้น เป้าหมายของกลยุทธ์คุณคืออะไร จึงมีความสำคัญเป็นพิเศษ โมเดล AARRR ของ Dave McClure สามารถใช้เป็นรากฐานสำหรับกำหนดกลยุทธ์ DevRel
อย่างไรก็ตาม ฉันแนะนำให้ปรับเปลี่ยนสองประการ:
เนื่องจาก DevRel สามารถเพิ่มการรับรู้ของนักพัฒนาต่อผลิตภัณฑ์หนึ่ง ตามนิสัยการตลาดแบบดั้งเดิม ให้เพิ่ม ‘A’ หนึ่งตัวก่อนตัวย่อ AARRR
ในกิจกรรมประจำวันของทีม DevRel อาจเกี่ยวข้องกับข้อเสนอแนะของนักพัฒนาต่อผลิตภัณฑ์ เพื่อแสดงสิ่งนี้ให้เพิ่ม ‘P’ หลังตัวย่อ AARRR
ดังนั้นจึงเกิดโมเดลใหม่: โมเดล AAARRRP แทนที่จะถือว่านี่เป็นเพียงตัวชี้วัด DevRel ควรมองว่าเป็นเป้าหมายที่เป็นไปได้ของโครงการ DevRel ของคุณ (แม้ว่า ‘จะวัดตัวชี้วัดเหล่านี้อย่างไร’ ก็ต้องพิจารณา ดูรายละเอียดที่ What’s the ROI of Developer Relations):
- การรับรู้ (Awareness) การรับรู้แพลตฟอร์มผลิตภัณฑ์
- การเข้าถึง (Acquisition) จำนวนการลงทะเบียน ดาวน์โหลด ติดตั้ง
- การเปิดใช้งาน (Activation) ระดับการใช้งานแพลตฟอร์ม
- การรักษา (Retention) การใช้แพลตฟอร์มอย่างต่อเนื่อง ใช้คุณสมบัติใหม่
- รายได้ (Revenue) การชำระเงินสำหรับแพลตฟอร์ม
- การแนะนำ (Referral) บอกคนอื่นเกี่ยวกับแพลตฟอร์ม
- ผลิตภัณฑ์ (Product) เกี่ยวข้องกับการสร้างและรวบรวมข้อเสนอแนะผลิตภัณฑ์
ในการดำเนินงานประจำวันของ DevRel มีรูปแบบกิจกรรมต่างๆ แต่ละประเภทของกิจกรรมสอดคล้องกับตัวชี้วัด DevRel หนึ่งหรือหลายตัว ดังนั้นจึงบรรลุเป้าหมาย AAARRRP หนึ่งหรือหลายเป้าหมาย เช่น:
| เขียนเอกสาร (กรณีศึกษา คู่มือเริ่มต้น ฯลฯ) | การเข้าถึง การเปิดใช้งาน ผลิตภัณฑ์ | |||
| พัฒนาไลบรารี | การเปิดใช้งาน ผลิตภัณฑ์ | |||
| แอปเริ่มต้นอย่างรวดเร็ว | การเปิดใช้งาน ผลิตภัณฑ์ | |||
| บทความบล็อก (บทช่วยสอน เทคนิค ความเป็นผู้นำทางความคิด ฯลฯ) | การรับรู้ การเข้าถึง การเปิดใช้งาน การรักษา | |||
| สัมมนาออนไลน์ | การรับรู้ การเข้าถึง การเปิดใช้งาน การรักษา | |||
| สปอนเซอร์กิจกรรม (สปอนเซอร์ Meetup บูธการประชุม ฯลฯ) | การรับรู้ การเข้าถึง | |||
| การบรรยาย (Meetup การประชุม กลุ่ม ฯลฯ) | การรับรู้ การเข้าถึง | |||
| การสนับสนุนผลิตภัณฑ์ (Zendesk, StackOverflow, ฟอรั่มอื่นๆ ฯลฯ) | การเปิดใช้งาน การรักษา ผลิตภัณฑ์ | |||
| การสนทนาทางเทคนิคก่อนขาย (โทรศัพท์ อีเมล การสนับสนุน ฯลฯ) | การเข้าถึง การเปิดใช้งาน | |||
| ฟอรั่มเฉพาะ (Google Groups, Discourse ฯลฯ) | การเปิดใช้งาน การรักษา | |||
| โปรแกรม Alpha/Beta | การรักษา ผลิตภัณฑ์ | |||
| เวลาทำการ | การเปิดใช้งาน การรักษา | |||
| รวบรวมข้อเสนอแนะจากนักพัฒนา | การรักษา ผลิตภัณฑ์ | |||
| ช่วยบริษัทรับสมัครงาน | การรับรู้ |
การรับประกันผลลัพธ์ของพฤติกรรมเหล่านี้จะมีความหมายเชิงบวกต่อนักพัฒนา ชื่อเสียงของบริษัทจะดีขึ้น วิธีนี้จะเพิ่มความเป็นไปได้ของ “การแนะนำ” แต่ความสัมพันธ์ระหว่างนักพัฒนาและบริษัทแบบนี้ ต้องใช้เวลาสร้าง
รายได้: เห็นได้ชัดว่าถูกละเว้นจากพฤติกรรมข้างต้น รายได้ขึ้นอยู่กับระดับการใช้ผลิตภัณฑ์โดยนักพัฒนา ดังนั้นจึงขึ้นอยู่กับโครงสร้างราคาผลิตภัณฑ์เป็นอย่างมาก ดังนั้น รายได้ ไม่สามารถเพิ่มเข้าไปในรายการข้างต้นได้อย่างง่ายดาย แต่สามารถยืนยันได้ว่า: ถ้าไม่พิจารณารายได้ชั่วคราว จะทำให้คุณมุ่งเน้นไปที่กิจกรรมและนักพัฒนาเป้าหมายที่มีแนวโน้มจะนำมาซึ่ง ROI จำนวนมาก
แม้ว่าฉันจะไม่เห็นด้วยกับการกำหนดบุคคลผ่านตำแหน่ง แต่ตำแหน่งสะท้อนให้เห็นการวางตำแหน่งบทบาทของเขาในทีม DevRel โดยบริษัทหรือนักพัฒนาคนอื่นๆ
ดังนั้น จากตำแหน่งทั่วไป ให้ดูว่าบทบาทต่างๆ มีส่วนร่วมในกิจกรรมใดบ้าง?
วิศวกรส่งเสริมเทคโนโลยี (Developer Advocates): รับผิดชอบหน้าที่ส่วนใหญ่ข้างต้นเป็นส่วนหนึ่งของงาน DevRel โดยเฉพาะหน้าที่ที่เกี่ยวข้องกับผลิตภัณฑ์หรือการรักษา
ผู้เผยแพร่เทคโนโลยี (Developer Evangelists): อาจมุ่งเน้นไปที่กิจกรรมที่เกี่ยวข้องกับการเข้าถึงผู้ใช้มากกว่า เช่น: เขียนเอกสาร เผยแพร่บล็อก สปอนเซอร์กิจกรรม บรรยาย ดูเพิ่มเติมเกี่ยวกับกิจกรรมที่เกี่ยวข้องกับ “การรับรู้” และการเข้าถึง
| สรุป
จะนิยาม DevRel อย่างไร? และวิธีใดเหมาะสมกับบริษัทของคุณมากที่สุด? ต่อไปนี้คือข้อเสนอแนะของฉัน:
- กำหนดเป้าหมายที่คาดหวังจากทีม DevRel ตามโมเดล AAARRRP
- เลือกรูปแบบกิจกรรมที่สอดคล้องกับเป้าหมายเหล่านั้นมากที่สุด
- จากรูปแบบกิจกรรมเหล่านั้น สามารถกำหนดได้ว่าจะรับสมัครวิศวกรส่งเสริมเทคโนโลยี (Developer Advocates) หรือผู้เผยแพร่เทคโนโลยี (Developer Evangelists)
เป็นอีกวิธีหนึ่งที่ช่วยตัวเอง หรืออย่างน้อยก็เป็นข้อเสนอแนะ สำหรับการถกเถียงเรื่องตำแหน่งที่ดำเนินต่อไปนี้ ฉันสร้างโครงการ DevRelOMeter — ตามประเภทกิจกรรมที่คุณคาดหวังให้ทีม DevRel ดำเนินการ จะแนะนำให้คุณทำการเผยแพร่เทคโนโลยีหรือส่งเสริมเทคโนโลยี?
| DevRelOMeter
คุณกำลังมีส่วนร่วมหรือกำลังพิจารณาที่จะมีส่วนร่วมในอาชีพการเผยแพร่นักพัฒนาหรือไม่?
https://leggetter.github.io/devrelometer/
ผู้เขียน: Phil Leggetter
ต้นฉบับ: Defining Developer Relations
เรียบเรียงโดย: Jack Jin
โปรดระบุแหล่งที่มา: ความสัมพันธ์นักพัฒนา »
