ความสัมพันธ์นักพัฒนาเป็นสาขาที่ค่อนข้างใหม่ หลายคนเพิ่งเริ่มสัมผัส แต่เมื่อคุณตัดสินใจรับงานนี้ มีรายละเอียดอะไรที่คุณยังไม่ได้พิจารณา?
ผมใช้เวลานานคิดว่าคนแบบไหนเหมาะสมที่สุดกับงานความสัมพันธ์นักพัฒนา ผมไม่ได้ใช้คำว่าผู้เผยแพร่ ผู้สนับสนุน หรือ “พระสันตปาปานักพัฒนา” (Michael Ludden) เพราะผมเชื่อว่าไม่ว่าตำแหน่งงานของเราจะเรียกว่าอะไร เราต่างเผชิญกับงานเดียวกัน ผู้มีส่วนได้ส่วนเสียคล้ายคลึงกัน และชุมชนนักพัฒนาเดียวกัน
ผมดำรงตำแหน่งผู้สนับสนุนนักพัฒนาของแพลตฟอร์มข้อมูล IBM Watson (เดิมคือ IBM Cloudant) มากว่าสองปีแล้ว ในสองปีก่อนหน้านี้ ผมอยากทำงานด้านความสัมพันธ์นักพัฒนามากเป็นพิเศษ ผมเริ่มปรึกษาเพื่อนร่วมงานที่ทำความสัมพันธ์นักพัฒนามาก่อน ถามเกี่ยวกับภูมิหลังและประสบการณ์ของพวกเขา โชคดีสำหรับผมที่ก่อนหน้านี้ผมจัดกิจกรรมเล็กๆ ชื่อ Hackference ผ่านกิจกรรมนี้ผมได้รู้จักคนหลายคน รวมถึงคนที่เพิ่งเริ่มงานและคนที่มีประสบการณ์หลายปี เกือบทุกคนก่อนทำความสัมพันธ์นักพัฒนาเคยเป็นนักพัฒนา (เป็นงานเต็มเวลาหรืองานอดิเรก) แล้วจึงขึ้นรถไฟความสัมพันธ์นักพัฒนา
ความสัมพันธ์นักพัฒนาต้องการทักษะอะไร
ในช่วงสี่ปีที่ผ่านมา หลายสิ่งเปลี่ยนแปลงไป มีเพียงสิ่งเดียวที่ไม่เปลี่ยน ซึ่งถูกมองว่าเป็น “ทักษะที่จำเป็น” สำหรับงานความสัมพันธ์นักพัฒนา สำหรับจุดนี้ โดยทั่วไปมีข้อกำหนดคร่าวๆ ดังนี้:
- ทำงานในอุตสาหกรรมการพัฒนาซอฟต์แวร์ X ปี ดำรงตำแหน่ง CTO หรือตำแหน่งที่คล้ายคลึงกัน
- ใช้ภาษาโปรแกรม XYZ
- เขียนเทคนิค (ผู้เขียนของสำนักพิมพ์ O’Reilly มีคะแนนพิเศษ)
- เคยบรรยายในที่สาธารณะ
ปัจจุบันข้อกำหนดเหล่านี้ยังจำเป็นมากในกรณีส่วนใหญ่ แต่นี่ไม่ได้หมายความว่าทุกอย่าง และหลายบริษัทก็สังเกตเห็นสิ่งนี้เมื่อรับสมัคร ผมเคยเข้าร่วม [การประชุมสุดยอดความสัมพันธ์นักพัฒนา] เมื่อเร็วๆ นี้ และนำเสนอสไลด์นี้ร่วมกับ Machael Ludden ซึ่งมีตารางที่ละเอียดครบถ้วน ระบุงานที่คนทำความสัมพันธ์นักพัฒนาอาจต้องทำ
แต่แม้ตารางนี้จะครอบคลุมกว่าเนื้อหางานจริงของความสัมพันธ์นักพัฒนาส่วนใหญ่ มันก็ไม่ได้บอกเราว่าคนต้องมีคุณภาพอย่างไรจึงจะเป็นผู้ทำความสัมพันธ์นักพัฒนาที่โดดเด่น
ความเข้าใจผู้อื่นเป็นกุญแจสำคัญ
ในช่วงสองปีที่ผ่านมา ผมก็เคยเห็นผู้ทำความสัมพันธ์นักพัฒนาที่ยอดเยี่ยมบางคนที่ไม่เคยเผยแพร่โค้ดระดับผลิตภัณฑ์ พวกเขาบางคนมาจากสาขาการเขียนเทคนิค หรือเพิ่งจบมหาวิทยาลัย แต่ก็กลายเป็นบัณฑิตในความสัมพันธ์นักพัฒนาแล้ว ดังนั้น นอกเหนือจากสิ่งที่ผมกล่าวไปข้างต้น ข้อกำหนดเพิ่มเติมที่ไม่โดดเด่นเหล่านั้นคืออะไร?
ไม่ว่าคุณจะทำอะไรในงานความสัมพันธ์นักพัฒนา คุณต้องทำให้ผู้ใช้ผลิตภัณฑ์ของคุณเข้าใจได้ ไม่ว่าจะจากมุมมองเทคนิคและโค้ด หรือจากมุมมองการแก้ปัญหา ถ้าคุณสามารถคิดจากมุมมองของผู้ใช้ผลิตภัณฑ์ ชีวิตจะง่ายขึ้นมาก
การทำให้คนเข้าใจได้ช่วยได้มากจริงๆ โดยเฉพาะสำหรับคนที่สร้างเครือข่ายแลกเปลี่ยนข้อมูล (เพื่อส่งเสริมการพัฒนาอาชีพ) ผมสาบานได้เลยว่าผมใช้เวลานานมากกับเรื่อง “สมัครตำแหน่งงาน” ไม่ว่าจะออฟไลน์หรือออนไลน์ ถ้ามีเรื่องใดที่คุณช่วยโดยตรงไม่ได้ การส่งต่อปัญหาให้คนที่ช่วยได้ก็ทำให้รู้สึกดีเช่นกัน นี่อาจทำผ่านผลิตภัณฑ์ของคุณ บริษัทของคุณ ภาษาหนึ่ง API หนึ่ง หรือชุมชนนักพัฒนาหนึ่ง Rey Bango มีสไลด์ที่ยอดเยี่ยมแสดงสิ่งนี้:
มีส่วนร่วม
เข้าใจกิจกรรมที่คุณจัด ส่วนสำคัญอย่างหนึ่งของงานความสัมพันธ์นักพัฒนาคือการค้นหาชุมชนนักพัฒนาและกิจกรรมนักพัฒนา และมีส่วนร่วม ผลิตภัณฑ์ของคุณอาจใหม่ หรือคุณอาจเพิ่งเริ่มทำงานความสัมพันธ์นักพัฒนา ดังนั้นการมีความเข้าใจคร่าวๆ เกี่ยวกับวิธีการทำงานและสร้างชื่อเสียงที่ดีเป็นจุดเริ่มต้นที่ดี
ส่งต่อความปรารถนาดี
สุดท้าย โปรดเป็นพลเมืองที่ดี ส่งต่อความปรารถนาดีของคุณ โปรดจำไว้ว่าสาขาความสัมพันธ์นักพัฒนายังใหม่ ทุกคนกำลังสำรวจวิธีที่เหมาะสมที่สุดในการทำงาน ถ้าคุณต้องการความช่วยเหลือ โปรดถามคำถาม คนอื่นจะพยายามช่วยตอบ Rey Bango มีอีกสไลด์หนึ่งอธิบายเรื่องนี้:
ทุกคนที่สนใจเทคโนโลยีและเต็มใจช่วยเหลือผู้อื่นสามารถทำสิ่งที่กล่าวไปข้างต้นได้ ใครๆ ก็สามารถเรียนรู้ตรรกะการแก้ปัญหา และตราบใดที่รู้วิธีหาวิธีแก้ปัญหา คุณก็สามารถเป็นผู้ทำความสัมพันธ์นักพัฒนาที่ยอดเยี่ยมได้ ก้าวไปข้างหน้าเถอะ เริ่มงานที่น่าทึ่งในขณะที่ช่วยเหลือผู้อื่นที่ยอดเยี่ยม บรรลุผลสำเร็จที่น่าอัศจรรย์!
ผู้เขียน: Mike Elsmore (Developer Advocate for the IBM Watson Data Platform)
ต้นฉบับ: Starting in Developer Relations: the non-obvious bits
โพสต์ซ้ำจาก: Starting in Developer Relations: the non-obvious bitsDevRel 开发者关系–那些并非显而易见的细节
ผู้แปล: สวี่เฉียนเฉียน@CMU
โปรดระบุแหล่งที่มา: ความสัมพันธ์นักพัฒนา »
