ถาม: “งานสร้างชุมชนนักพัฒนาต้องทำโดยนักพัฒนาหรือไม่?”
คำถามแบบนี้ ฉันได้ยินมานับครั้งไม่ถ้วนแล้ว คำถามนี้จะปรากฏในทุกกลุ่มชุมชน และคนที่ถามคำถามนี้มักเป็นคนที่ต้องการสร้างชื่อในอุตสาหกรรมเทคโนโลยี แต่ตัวเองไม่มีพื้นฐานทางเทคนิค พวกเขาไม่แน่ใจว่าตัวเองจะอยู่รอดในอุตสาหกรรมเทคโนโลยีได้หรือไม่
ฉันไม่เคยเขียนโค้ดสักบรรทัดเดียว แต่ฉันก็ประสบความสำเร็จในการเป็นผู้เผยแพร่ชุมชนของ Estimote เราเป็นบริษัทสตาร์ทอัพที่มุ่งเน้นนักพัฒนามือถือ ตลอดทางที่ผ่านมา ฉันได้เรียนรู้ประสบการณ์มากมาย ทุกคนที่มีอาชีพด้านการดำเนินงานชุมชนจะพบว่าประสบการณ์เหล่านี้มีประโยชน์มาก เราทุกคนมุ่งเน้นไปที่ผลิตภัณฑ์ รวบรวมนักพัฒนาให้มากขึ้น เราไม่เพียงแต่สามารถใช้ประสบการณ์เหล่านี้ แต่ยังสามารถอภิปราย ส่งเสริม และมีส่วนร่วมอย่างต่อเนื่อง ทำให้ประสบการณ์มีความหลากหลายมากขึ้น ชุมชนที่มุ่งเน้นผลิตภัณฑ์เหมือนรังผึ้ง ทุกคนมีส่วนร่วมเพื่อเป้าหมายร่วมกัน ส่วนใหญ่แล้ว จุดเน้นของงานของเราไม่ใช่ตัวเทคโนโลยีเอง
ฉันก็ไม่ใช่ตัวอย่างเดียวที่ไม่มีพื้นฐานทางเทคนิค แม้แต่บริษัทอย่าง SendGrid และ Twilio ที่มีชื่อเสียงในการสร้างชุมชนนักพัฒนา ทีมชุมชนของพวกเขาก็มีสมาชิกที่ไม่ใช่นักพัฒนา (สวัสดี Tim, สวัสดี Lisa!)
เรามาอภิปรายคำถามนี้อีกครั้ง: หากต้องการสร้างชุมชนนักพัฒนา คุณต้องเป็นนักพัฒนาหรือไม่?
ไม่ แต่คุณต้องเรียนรู้ที่จะคิดเหมือนนักพัฒนา
แม้ว่าคุณจะไม่สามารถคิดด้วยโค้ด แต่คุณควรเรียนรู้ที่จะคิดเหมือนนักพัฒนา
คนในทุกอาชีพมีนิสัย คำศัพท์เฉพาะ และวิธีมองโลกที่พิเศษ ภารกิจของคุณคือสร้างสถานที่ที่นักพัฒนารู้สึกเหมือนอยู่บ้าน แน่นอนว่านักพัฒนาทุกคนมีลักษณะเฉพาะของตัวเอง แต่ยิ่งคุณพบนักพัฒนามากเท่าไหร่ คุณจะยิ่งเห็นจุดร่วมมากขึ้นเท่านั้น พวกเขามักจะพูดถึงสิ่งเดียวกัน เช่น pull request, forked repos และ API tokens ใช่แล้ว คุณต้องเรียนรู้สิ่งเหล่านี้ อย่าหาข้ออ้างเพื่อหลีกเลี่ยง
นักพัฒนาหลายคนหลงใหลในประสิทธิภาพ พวกเขาคิดถึงระบบ การระบุรูปแบบ และการวิเคราะห์ปัญหาต่างๆ อย่างละเอียด
คำอธิบายนี้กว้างเกินไปหรือไม่? ถูกต้อง ในระดับปริมาณหนึ่ง คำอธิบายนี้แม่นยำ แต่ถ้ามีคนบอกคุณว่าเขาสามารถอธิบายวิธีคิดของนักพัฒนา (หรือนักออกแบบ/นักข่าว/คนงานก่อสร้าง) ได้ในไม่กี่ประโยค โปรดอย่าเชื่อเขา
การเรียนรู้วิธีคิดของนักพัฒนาไม่มีทางลัด วิธีเดียวคือการสนทนากับนักพัฒนา
กินข้าวกับทีมเทคนิคในบริษัท เข้าร่วมการประชุมของพวกเขา ติดตามความเคลื่อนไหวใหม่ๆ ในช่อง Slack/HipChat อภิปรายกับคนที่รับผิดชอบข้อเสนอแนะจากผู้ใช้ คุณยังสามารถหาโอกาสเรียนรู้ภายนอกบริษัท เช่น เข้าร่วมการประชุมเทคโนโลยีในเมืองของคุณ ติดตามแท็กหัวข้อที่เกี่ยวข้องกับชุมชนของคุณบน Stack Overflow
บางหัวข้อคุณอาจไม่เข้าใจเลย เช่น “โค้ด C ที่ซับซ้อนที่สุดที่คุณเคยสร้างคืออะไร?” คุณไม่จำเป็นต้องเข้าใจคำถามนี้อย่างลึกซึ้ง ขณะอ่าน คุณเพียงแค่ดูรายละเอียดที่คนอื่นอภิปราย และหาความสุขจากนั้น การปฏิบัติเหล่านี้สามารถทำให้คุณเป็นผู้ดำเนินงานชุมชนและผู้เผยแพร่เทคโนโลยีที่ดีขึ้น
ไม่ แต่คุณต้องรู้จักผลิตภัณฑ์
แกนกลางของทุกชุมชนคือคน แต่แกนกลางของชุมชนนักพัฒนานอกจากคนแล้วยังมีผลิตภัณฑ์ ชุมชนนักพัฒนาดึงดูดนักพัฒนาให้มารวมตัวกันด้วยเครื่องมือหรือวัตถุประสงค์พิเศษ แม้ว่าคุณจะไม่สามารถเป็นผู้เชี่ยวชาญในการใช้เครื่องมือเหล่านี้ แต่คุณควรเป็นผู้เชี่ยวชาญในการอธิบายพวกมัน
คุณสามารถอ่านเรื่องราวความสำเร็จเพื่อทำความเข้าใจแนวทางปฏิบัติที่ดีที่สุด และสถานการณ์ที่นักพัฒนาจะใช้เครื่องมือของคุณ: หากบริษัทของคุณยังไม่ได้เผยแพร่เนื้อหาเหล่านี้ คุณสามารถขอให้ทีมความสำเร็จของลูกค้า/ทีมพัฒนาธุรกิจ/ผู้ดำเนินงานชุมชนอื่นแบ่งปันกับคุณ คุณยังต้องเข้าใจกระบวนการวิวัฒนาการของผลิตภัณฑ์: ดูโพสต์เก่า และอ่านบันทึกการอัปเดตผลิตภัณฑ์
เมื่อเข้าใจผลิตภัณฑ์และผู้ใช้แล้ว คุณสามารถแสดงกรณีศึกษาที่เกี่ยวข้อง ตอบคำถามทั่วไป และส่งเสริมให้คนเขียนเนื้อหาเองเพื่อมีส่วนร่วมกับชุมชน การส่งเสริมให้ผู้อื่นมีส่วนร่วมเป็นสิ่งสำคัญที่สุด เมื่อสมาชิกชุมชนรู้สึกว่าคุณใส่ใจพวกเขา พวกเขาจะเขียนคู่มือสำหรับเครื่องมือของคุณ จัดการพบปะสำหรับผลิตภัณฑ์ของคุณ หากผลิตภัณฑ์ของคุณเป็นโอเพนซอร์ส พวกเขาอาจช่วยคุณแก้ไขบัก พวกเขาจะเปลี่ยนมานับถือผลิตภัณฑ์ของคุณ
จะรู้ได้อย่างไรว่าตัวเองเข้าใจ SDK และ API ของบริษัทเพียงพอแล้ว? วิธีที่ดีวิธีหนึ่งคือดูว่าเมื่อคนประสบปัญหาในการปรับใช้ฟีเจอร์ผลิตภัณฑ์บางอย่าง คุณสามารถบอกเขาได้หรือไม่ว่าจะหาคำตอบได้ในหน้าไหนของเอกสารผลิตภัณฑ์ นี่หมายความว่าแม้คุณจะไม่สามารถใช้ผลิตภัณฑ์เองได้ แต่คุณก็คุ้นเคยกับผลิตภัณฑ์แล้ว และรู้ว่ารากฐานของปัญหาอยู่ที่ไหน ชัดเจนว่าหากคุณทำได้ ก็พิสูจน์ได้ว่าคุณไม่ได้แก้ปัญหาด้วยโชค ซอฟต์แวร์เปลี่ยนแปลงตลอดเวลา โดยเฉพาะในยุคที่ทุกคนเน้นความคล่องตัวและอัปเดตรายวัน กล่าวคือ สิ่งที่คุณเรียนรู้มาจะล้าสมัยทันที ดังนั้นคุณต้องเรียนรู้อย่างต่อเนื่อง
ภายใน Estimote เราสร้างกิจกรรม “stack review” ทุกสองสัปดาห์: เปิดประชุมสั้นๆ เพื่อให้แน่ใจว่าทุกคนได้เรียนรู้การเผยแพร่ผลิตภัณฑ์ครั้งล่าสุด การประชุมนี้ใช้เวลาไม่เกิน 20 นาที แต่ช่วยให้เรามั่นใจว่าทุกคนก้าวตามจังหวะเดียวกัน
เนื่องจากผลิตภัณฑ์ซอฟต์แวร์เปลี่ยนแปลงเร็ว ดังนั้นเมื่อคุณไม่เข้าใจหรือจำบางสิ่งไม่ได้ อย่าท้อแท้ ในบริษัทหนึ่ง แม้แต่นักพัฒนาก็ไม่สามารถเข้าใจรายละเอียดทั้งหมดของผลิตภัณฑ์ได้ แม้ว่าพวกเขาจะพัฒนามันเอง ไม่มีอะไรต้องอับอาย ผลิตภัณฑ์ซอฟต์แวร์ซับซ้อนเกินไป คนคนเดียวไม่สามารถจำโค้ดเบสขนาดใหญ่ได้ด้วยสมอง เมื่อคุณประสบปัญหา คุณเพียงแค่ต้องรู้ว่าจะถามใคร
หากบริษัทของคุณใช้เครื่องมือการทำงานร่วมกันอย่าง Confluence หรือ Asana คุณควรดูแลเอกสารที่มีรายละเอียดทางเทคนิคและ FAQ สำหรับผลิตภัณฑ์
หากบริษัทของคุณไม่ใช้เครื่องมือการทำงานร่วมกัน คุณสามารถใช้ Google Doc สิ่งสำคัญคือต้องมีคนรับผิดชอบอัปเดตมัน เอกสารที่หมดอายุแย่กว่าไม่มีเอกสาร
ไม่ แต่ทีมต้องมีนักพัฒนา
ในโลกที่มุ่งเน้นนักพัฒนา ทีมชุมชนใดๆ ต้องมีนักพัฒนาอย่างน้อยหนึ่งคน ในตอนแรก ทีมของเราไม่มีนักพัฒนาเต็มเวลา โมเดลนี้ดำเนินไปได้ระยะหนึ่ง เรามีการเปิดเผยในกิจกรรมทั่วโลก เราปรับปรุงเนื้อหาอย่างต่อเนื่อง และให้บริการลูกค้าที่มีคุณภาพสูง
แต่เราก็เจอคอขวดทันที ความสามารถของเราในการสนับสนุนกิจกรรมแฮกกาธอนมีจำกัด การเขียนเนื้อหาทางเทคนิคก็รู้สึกลำบาก คำขอการสนับสนุนที่ยากจะล่าช้าหลายวัน เพราะทีมให้ความสำคัญกับการ shipping ก่อน จึงจะถึง troubleshooting คำขอการสนับสนุนเหล่านี้คิดเป็น 10% ของคำขอทั้งหมด
หลังจากเราหาผู้เผยแพร่เทคนิคที่เขียนโค้ดได้มา ทีมทั้งหมดมีประสิทธิภาพมากขึ้น: การสนับสนุนลูกค้า เนื้อหา กิจกรรม การรวบรวมข้อเสนอแนะ ความสัมพันธ์นักพัฒนา ในสายตาชุมชน เรากลายเป็นฝ่ายริเริ่มและเข้าถึงได้มากขึ้น
การจัดหาสมาชิกที่มีความสามารถระดับมืออาชีพให้ทีมสามารถเพิ่มประสิทธิภาพของทีมแบบทวีคูณ หากคุณต้องการให้ทีมชุมชนนักพัฒนาของคุณพัฒนาจาก “ดี” เป็น “ยอดเยี่ยม” คุณต้องจัดหาผู้เผยแพร่เทคนิคที่เป็นนักพัฒนาให้ทีม
ทีมชุมชน Estimote (จากซ้ายไปขวา), Wojtek, Witek (หัวหน้าทีม), Ula (ผู้จัดการชุมชน), Piotr (ผู้เผยแพร่เทคนิค)
ไม่ แต่การเรียนเขียนโปรแกรมเองก็ไม่เสียหายอะไร
คุณอาจคิดว่าฉันพูดเก่ง ท้ายที่สุด ฉันก็ยอมรับแล้วว่าไม่เคยเขียนโค้ด จะพูดอย่างไร? เรามักจะให้คำแนะนำคนอื่น แต่ตัวเองกลับไม่ค่อยทำจริง ดังนั้นฉันขอแนะนำให้ทุกคนไปเรียนรู้ อย่าทำผิดพลาดเหมือนฉัน
เป็นไปได้มากว่าผ่านการเรียนรู้ คุณก็ไม่สามารถเป็นนักพัฒนาที่ยอดเยี่ยมได้ แต่คุณไม่จำเป็นต้องเป็นนักพัฒนาที่ยอดเยี่ยม
คุณไม่จำเป็นต้องพัฒนาผลิตภัณฑ์ด้วยตัวเอง คุณเรียนเขียนโปรแกรมเพื่อให้คุณสร้างชุมชนนักพัฒนา และให้คุณคิดเหมือนนักพัฒนาได้ดีขึ้น แม้แต่ความรู้การเขียนโปรแกรมพื้นฐานก็สามารถช่วยให้คุณเข้าใจชุมชนและความหมายของผลิตภัณฑ์ของคุณได้มาก นี่เป็นความรู้พื้นฐานที่สุดที่จะมีส่วนร่วมในชุมชนนักพัฒนา
นอกจากการเขียนโปรแกรม คุณยังสามารถเรียนรู้สิ่งอื่นได้ ผู้ใช้ผลิตภัณฑ์ที่มุ่งเน้นนักพัฒนา นอกจากเขียนโค้ดแล้ว ยังทำอย่างอื่นอีกมาก หากคุณเหมือนฉัน ไม่ชอบโลกของ Xcode และ Android Studio คุณสามารถเรียนรู้ในสาขาอื่น อ่านหนังสือเกี่ยวกับการจัดการผลิตภัณฑ์ เรียนคอร์สการออกแบบ UI เรียน UX โลกนี้มีสิ่งที่รอให้คุณเรียนรู้ไม่รู้จบ Coursera, Udemy, iTunes U และบล็อกจำนวนมากมอบภูมิปัญญาหลากหลายให้คุณ สิ่งเหล่านี้คือเนื้อหาการเรียนรู้ที่คุณใฝ่ฝัน คุณต้องเรียนรู้ที่จะใช้มันให้เกิดประโยชน์
สิ่งสำคัญที่สุด: เรียนรู้ความรู้ในสาขา ตราบใดที่เปิดใจ ไม่จำกัดเฉพาะความรู้การสร้างชุมชน การเรียนรู้ความรู้อื่นๆ จะช่วยให้คุณสร้างชุมชนนักพัฒนาได้ง่ายขึ้น การขยายคลังความรู้ของคุณในสาขาที่เกี่ยวข้องจะช่วยให้คุณสนทนากับสมาชิกชุมชนได้อย่างลื่นไหลมากขึ้น
มีข้อยกเว้นหรือไม่?
มีทีมชุมชนนักพัฒนาบางทีมที่ในตอนแรกฉันคิดว่าพวกเขาต้องมีประสบการณ์นักพัฒนาอย่างหลากหลาย เช่น บริษัทอย่าง Docker หรือ MongoDB ผลิตภัณฑ์ของพวกเขามีความเป็นเทคนิคสูงมาก เมื่อพูดถึงพวกเขา คุณจะนึกถึงโค้ดเทคนิคทันที เหมือนกับเมื่อพูดถึง Estimote จะนึกถึงไมโครโลเคชัน พูดถึง Twilio จะนึกถึงข้อความ หรือพูดถึง Oculus จะนึกถึงวิดีโอเกม
แต่หลังจากศึกษาความต้องการสำหรับตำแหน่ง “การจัดการชุมชน” ของพวกเขา ฉันพบว่าตำแหน่งเหล่านี้ไม่ต้องการพื้นฐานทางเทคนิค บางทีอาจไม่น่าแปลกใจ หากคุณต้องการสร้างชุมชนนักพัฒนา ก็ทำไปเลย คุณไม่จำเป็นต้องเป็น Linus Torvalds ก็สามารถประสบความสำเร็จได้
ผู้เขียน: Wojtek Borowicz (Wojtek is the community evangelist at Estimote in Krakow, Poland.)
ต้นฉบับ: How to Become An Awesome Developer Evangelist When You’re Not a Developer
โพสต์ใหม่จาก: DevRel 开发者关系－非开发者如何成为优秀的技术布道者
แปลโดย: หลู ซิงยวิ่น
โปรดระบุแหล่งที่มา: ความสัมพันธ์นักพัฒนา »
