การประชุม OpenStack Summit ที่ออสตินกลายเป็นแพลตฟอร์มที่ยอดเยี่ยมในการแลกเปลี่ยนประสบการณ์การจัดการโครงการโอเพนซอร์ส พิสูจน์แล้วว่าหลังจากมีส่วนร่วมในชุมชนและมีส่วนร่วมในโครงการมาหลายปี ฉันมีสิทธิ์พูดในเรื่องนี้บ้าง
อย่างไรก็ตาม ในบทความวันนี้ ฉันตั้งใจจะตีความหัวข้อนี้จากมุมมองตรงกันข้าม คือการพูดคุยเกี่ยวกับแนวปฏิบัติที่ไม่ควรทำในการจัดการโครงการโอเพนซอร์ส
1. สร้างความรำคาญให้ผู้มีส่วนร่วม
นักพัฒนาและผู้ดูแลซอฟต์แวร์มีภาระงานมากอยู่แล้ว ดังนั้นการมอบหมายงานมากเกินไปจะทำให้พวกเขารู้สึกแย่ ความเข้าใจผิดที่ใหญ่ที่สุดอย่างหนึ่งในโลกโอเพนซอร์สคือ ผู้จัดการมักคิดว่างานที่มากมายจะเพิ่มความรู้สึกมีส่วนร่วมของสมาชิก พูดให้ตรงไป ถ้างานเยอะเกินไป คนอาจจะไปเลยก็ได้
ฉันมีเพื่อนสนิทคนหนึ่งที่มีส่วนร่วมกับ Ceilometer ตั้งแต่ปี 2013 ระดับการตรวจสอบโค้ดของเขาสูงมาก แม้แต่สามารถค้นพบข้อผิดพลาดที่คนอื่นไม่รู้ตัวได้หลายอย่าง ทีมจัดการโครงการในที่สุดก็เลื่อนตำแหน่งให้เขาเป็นผู้ตรวจสอบหลัก — แทนที่จะมอบหมายงานเพิ่มให้เขา จงเชื่อฉันสิ ความรู้สึกประสบความสำเร็จนี้แหละที่ทำให้นักเทคนิคที่มีความสามารถระดับสูงยังคงอยู่ในโครงการต่อไป
2. ให้คนมีส่วนร่วมแค่งานน่าเบื่อ
เมื่อมีคนใหม่เข้าร่วม แรงจูงใจของพวกเขามักจะแตกต่างกัน ผู้ใช้บางคนหวังที่จะบรรลุคุณค่าของตัวเองผ่านการมีส่วนร่วม บางคนก็มีจุดประสงค์เพื่อเรียนรู้ แต่โดยทั่วไปแล้ว คนมักจะต่อต้านการสัมผัสงานระดับล่างที่น่าเบื่อตลอดเวลา ถ้าผู้จัดการไม่แคร์ความรู้สึกของผู้มีส่วนร่วมระดับล่าง เนื้อหาที่น่าเบื่อรวมกับความเข้มข้นของงานที่กล่าวถึงข้างต้น จะทำให้เพื่อนที่ตั้งใจจะมีส่วนร่วมในโอเพนซอร์สจำนวนมากถอยตัวออกไปอย่างรวดเร็ว
3. ไม่ให้ความสำคัญกับการมีส่วนร่วมเล็กน้อย
แก้ไขคำผิดก็นับเป็นการมีส่วนร่วม? จัดเรียงเอกสารใหม่ก็นับเป็นการมีส่วนร่วม? ทัศนคติแบบนี้พบได้บ่อยในโครงการโอเพนซอร์ส แต่พิสูจน์แล้วว่างานประเภทนี้มีคุณค่าเช่นกัน
ฉันเคยรับผิดชอบแก้ไขข้อผิดพลาดในเอกสารในโครงการหนึ่ง และเผยแพร่แพตช์ 56 รายการในเวลาอันสั้น แก้ไขบั๊กบางส่วนและเพิ่มฟังก์ชันเพิ่มเติม ไม่มีใครดูถูกฉันเพราะเป็นเรื่องเล็กน้อย และฉันก็เชื่อว่างานของฉันมีคุณค่าจริงๆ
4. ตั้งค่าความยากสูงเกินไปสำหรับผู้มาใหม่
เมื่อผู้มาใหม่มีส่วนร่วมในโครงการโอเพนซอร์ส ระดับทักษะและประสบการณ์การทำงานของพวกเขามักแตกต่างกันมาก และผู้จัดการหลายคนก็มอบหมายงานที่ซับซ้อนเกินไปให้พวกเขาทันที ซึ่งจะทำให้หลายคนรู้สึกผิดหวัง หรือแม้แต่คิดว่าตัวเองโง่เกินไปและถอยตัวออกไปอย่างเงียบๆ
ความจริงคือ เราควรประเมินระดับทักษะของผู้มาใหม่ (การสื่อสารแบบง่ายๆ ควรสามารถประมาณระดับได้) แล้วจึงมอบหมายงานที่ทำได้แต่มีความท้าทายบ้าง
5. คาดหวังให้คนเสียสละชีวิตส่วนตัว
ผู้เข้าร่วมส่วนใหญ่จะใช้เวลาว่างในการมีส่วนร่วมกับโอเพนซอร์ส ซึ่งเป็นวิธีการพัฒนาที่แข็งแรงมาก โปรดทราบว่า อย่าคาดหวังให้สมาชิกโครงการเสียสละชีวิตส่วนตัวเพื่อมีส่วนร่วม นั่นไม่สมจริงและไม่เป็นผลดีต่อการพัฒนาโครงการในระยะยาว
นอกจากนี้ การประชุมทางวิดีโอหรือการประชุม IRC บ่อยเกินไปก็ทำให้คนรู้สึกเบื่อหน่าย โครงการโอเพนซอร์สควรมีมนุษย์เป็นศูนย์กลาง และใช้วิธีการสื่อสารและการมีส่วนร่วมที่แตกต่างกันสำหรับสมาชิกที่แตกต่างกัน
6. หลักเกณฑ์พฤติกรรมที่ซ่อนอยู่ยากที่จะปรับตัว
เมื่อชุมชนเติบโตขึ้น จะมีสไตล์หรือวิธีการทำงานที่ซ่อนอยู่กลายเป็นเอกลักษณ์ของมัน แม้ว่านี่จะทำให้คนเก่าๆ สนุก แต่ก็อาจทำให้คนใหม่รู้สึกกลัว
แน่นอนว่า เราไม่จำเป็นต้องจัดทำคู่มือหลักเกณฑ์พฤติกรรม แต่ในฐานะผู้จัดการโครงการ ทุกคนควรทำให้ทีมรักษาบุคลิกของตัวเองไว้ ในขณะเดียวกันก็คำนึงถึงความรู้สึกของคนใหม่ การโยนคำศัพท์ภายในหรือ “มีม” ออกมามากมาย นอกจากจะขัดขวางการขยายขนาดขององค์กรแล้ว ไม่มีประโยชน์อะไรเลย
7. ทำให้ผู้พูดที่ไม่ได้ใช้ภาษาอังกฤษเป็นภาษาแม่รู้สึกไม่มีส่วนร่วม
ชุมชนโครงการโอเพนซอร์สส่วนใหญ่จะสื่อสารกันเป็นภาษาอังกฤษ ซึ่งเป็นข้อกำหนดสำคัญสำหรับการทำงานร่วมกัน อย่างไรก็ตาม เราควรพิจารณาว่านักเทคนิคบางคนมาจากประเทศที่ไม่ได้ใช้ภาษาอังกฤษเป็นภาษาแม่ ซึ่งหมายความว่าพวกเขาอาจมีปัญหาในการสื่อสารกับสมาชิกเดิมอย่างราบรื่น และอาจรู้สึกท้อแท้จากเรื่องนี้
เมื่อเผชิญกับสถานการณ์แบบนี้ เราสามารถคิดหาวิธีอื่นมาทดแทนได้ เช่น การใช้การสื่อสารแบบอะซิงโครนัส ส่งเนื้อหาการสื่อสารในรูปแบบข้อความ ด้วยวิธีนี้ อีกฝ่ายสามารถใช้ซอฟต์แวร์แปลเพื่อเข้าใจความหมายโดยประมาณ และยังหลีกเลี่ยงความตึงเครียดจากการพูดภาษาต่างประเทศได้อีกด้วย
8. ขาดวิสัยทัศน์ ไม่ยอมปล่อยอำนาจ
ข้อผิดพลาดสองประการนี้พบได้บ่อยในโครงการโอเพนซอร์สทุกประเภท ความจริงคือ หลังจากผู้มีส่วนร่วมบางคนเข้าร่วม พวกเขาจะพัฒนาฟังก์ชันใหม่และขอความคิดเห็นจากสมาชิกเดิม ในขณะนี้ ผู้จัดการที่รับผิดชอบอาจรู้ตัวว่าไม่คุ้นเคยกับเทคโนโลยีส่วนนี้ และอาจตัดสินใจถอนตัว ต้องเน้นว่า วิสัยทัศน์การพัฒนาโครงการและการสื่อสารรอบๆ ประเด็นนี้มีความสำคัญมาก ด้วยวิธีนี้เราจะสามารถทำให้สมาชิกทุกคนมีการตัดสินใจเหมือนกันและเข้าใจว่าควรอยู่ในทีมเพื่อมีบทบาทหรือไม่
นอกจากนี้ ควรมอบหมายความรับผิดชอบบางส่วนให้สมาชิกคนอื่นอย่างสบายใจ แทนที่จะควบคุมทั้งหมดด้วยตัวเอง การตรวจสอบแพตช์ การออกแบบระบบย่อย การแก้ไขข้อผิดพลาด และการเขียนเอกสารสามารถให้คนเฉพาะทางรับผิดชอบได้ ด้วยวิธีนี้ สมาชิกทุกคนจะรู้สึกถึงบทบาทและคุณค่าของตัวเอง และมีความกระตือรือร้นที่จะอยู่ในทีมโครงการต่อไป
9. ไม่ยอมรับความสำเร็จของผู้มีส่วนร่วม
มีหลายวิธีในการมีส่วนร่วมกับโครงการโอเพนซอร์ส ไม่จำกัดเพียงการเขียนโค้ด เอกสาร การดีบั๊ก การสนับสนุนผู้ใช้ การออกแบบประสบการณ์ การเผยแพร่ และการแปล ฯลฯ ทั้งหมดนี้เป็นงานที่สำคัญมาก
ดังนั้น เราควรให้ความสำคัญกับการมีส่วนร่วมที่ไม่ใช่ด้านเทคนิคอย่างเพียงพอ และระมัดระวังเมื่อสร้างระดับสมาชิกทีม เพื่อไม่ให้พลาดผู้มีความสามารถประเภทใดเลย
10. ขาดความรู้สึกขอบคุณ
ในตอนท้าย ฉันต้องเน้นความสำคัญของความรู้สึกขอบคุณในโครงการโอเพนซอร์ส โครงการประเภทนี้มักถูกสร้างขึ้นโดยผู้เข้าร่วมโดยไม่ได้รับค่าตอบแทน ในฐานะผู้จัดการ เราต้องชื่นชมจิตวิญญาณการแบ่งปันของทุกคน — แน่นอนว่าต้องทำในทางที่พวกเขารู้สึกได้!
โปรดระบุแหล่งที่มา: ความสัมพันธ์นักพัฒนา »
