เหตุใดจึงต้องทำงานในที่เปิด?

Image by : opensource.com

โดย Heiko R. Rupp

อะไรบ้างที่สกัดกั้นไม่ให้คุณทำงานในที่เปิด?

    ผมทำงานให้กับบริษัทโอเพนซอร์สเกี่ยวกับโปรเจกต์โอเพนซอร์ส และกระนั้น ก็ยังพบอยู่ทุกวันว่าคนที่ทำงานกับซอฟต์แวร์โอเพนซอร์สนิยมที่จะทำงานส่วนตัวลำพังมากกว่าในบางครั้ง คนเหล่านี้ไม่ค่อยจะพูดคุยถกเถียงเกี่ยวกับประเด็นทางเทคนิคใน public mailing list สักเท่าไหร่ หากจะสนทนากันก็มักจะทำในห้องสนทนาภายในมากกว่าที่จะสนทนาทาง public IRC และหากมีฟีเจอร์ใหม่ๆออกมา ก็มักจะทำเป็นเดโมทาง video conference ส่วนตัว มากกว่าช่องทางอื่นเช่น Hangout on Air

    แน่นอนว่ามีเหตุผลดีๆอยู่ที่ว่าเหตุใดการสื่อสารต้องกระทำในรูปแบบที่ส่วนตัว เพราะว่าหากมีลุกค้าหรือข้อมูลลูกค้าเข้ามาเกี่ยวข้องเมื่อใด การสนทนาติดต่อสื่อสารที่เป็นส่วนตัวยิ่งจำเป็นมากขึ้นเท่านั้น ซึ่งเป็นจริงๆสำหรับเรื่องยอดขายหรือประเด็นอื่นๆด้านการเงินด้วย แต่ประเด็นก็คือว่า จริงๆแล้วอย่างวิศวกรเองก็ไม่ได้รับรู้เรื่องยอดขายสักเท่าไหร่ ประเด็นเกี่ยวกับลูกค้าเองส่วนใหญ่ก็เป็นปัญหาทั่วๆผด้านซอฟท์แวร์ที่สามารถพูดคุยหารือกันได้อย่างเปิดเผยโดยไม่จำเป็นต้องเอ่ยชื่อลูกค้าออกมาด้วยซ้ำ นี่ทำให้ผมอยากจะพูดถึงคำถามว่าเหตุใดผู้คนจึงไม่ค่อยให้ความร่วมมือกันในที่เปิด โดยเฉพาะอย่างยิ่งเมื่อ source code ในตอนท้ายก็ต้องนำไปสู่แหล่งสาธารณะอย่าง GitHub อยู่ดี

ความกลัวว่าข้อมูลจะรั่วไหล

    เมื่อคุณร่วมงานกับลูกค้า จะมีบางกลุ่มเสมอ เช่น กลุ่มสนับสนุนลูกค้า ที่ไม่สามารถถกประเด็นต่างๆในที่สาธารณะได้ ซึ่งหมายความว่าไม่สามารถร่วมสนทนาใน public IRC ได้ ต้องเป็นการสนทนาแบบส่วนตัวเพื่อปกปิดข้อมูลของลูกค้า วิศวกรที่ทำงานกับลูกค้าเองก็อาจจะมีความกลัวอยู่ลึกๆว่าการหารือถกประเด็นต่างๆอาจจะเป็นการทำให้ข้อมูลรั่วไหลในช่องทางภายใน ไม่ว่าจะมีการพูดถึงประเด็นเฉพาะของลูกค้าหรือไม่ก็ตาม ซึ่งนำไปสู่ประเด็นต่อไป

ความพยายามในการเลือกและการสลับเปลี่ยน

    เมื่อคุณทำงานเกี่ยวกับข้อมูลลูกค้าผ่านทางช่องทางภายใน (และอาจจะเพราะว่าบุคลากรที่เกี่ยวข้องสามารถติดต่อได้ผ่านทางช่องทางนี้เท่านั้น) คุณจะต้องคิดและตัดสินใจอยู่เสมอว่าข้อความหรือข้อมูลบางอย่างสามารถเผยแพร่สู่ช่องทางสาธารณะภายนอกได้หรือไม่ บางคนอาจจะเข้าใจว่าหากมีการสนทนาเกิดขึ้นในช่องทางภายใน ก็ควรให้มันอยู่ภายในเพื่อคงรักษาความเป็นเอกภาพของเนื้อหาสาระ ไม่ให้ขาดตอน ส่วนการพูดคุยเกี่ยวกับประเด็นที่ไม่เกี่ยวกับลูกค้า ก็ควรจะอยู่ในช่องทางสาธารณะ และนี่หมายถึงการที่ต้องสลับเปลี่ยนช่องทางไปมาอยู่ตลอด แน่นอน การสลับเปลี่ยนช่องทางการสื่อสารไปมาแบบนี้ เป็นสิ่งที่คนมักจะเลี่ยง

ความไม่แน่นอน

    อาจจะมีบางกรณีที่วิศวกรกำลังทำเกี่ยวกับการขอสร้างฟีเจอร์หรือแก้ไข bug จากลูกค้า ซึ่งไม่ได้เกี่ยวข้องเจาะจงกับลุกค้าคนใดคนหนึ่งด้วยซ้ำ แต่อย่างไรก็ตามก็ยังคงมีความไม่แน่นอนใจอยู่ว่าประเด็นเหล่านี้ควรจะนำมาหารือกันในที่สาธารณะหรือไม่ และพอสงสัย ทุกอย่างก็ย้อนกลับไปดำเนินในช่องทางส่วนตัวเช่นเดิม

ความกลัวว่าจะมีสิ่งรบกวนสมาธิ

    ในขณะที่การช่วยทำประโยชน์ต่อชุมชนผู้ใช้มักจะกล่าวกันว่าต้อนรับเปิดกว้างสำหรับทุกคน ก็ยังสามารถมองได้ว่าเป็นแหล่งของสิ่งที่รบกวนสมาธิด้วย สมาชิกหลักบางคนของโปรเจกต์หนึ่งๆอาจจะต้องหยุดพักงานของตนชั่วคราว และต้องเริ่มคิดถึงทัศนะของสมาชิกอื่นๆของชุมชน และค่อยกลับมาทำงานตนต่อในภายหลัง นี่เองที่ทำให้ความมุ่งมั่นและสมาธิการทำงานถูกรบกวน โดยเแพาะอย่างยิ่งเมื่อคุณกำหนดกรอบในการปล่อยงานของคุณเรียบร้อยแล้ว นี่อาจจะไม่น่ายินดีสักเท่าไหร่นัก

ความรู้สึกว่าขาดผลประโยชน์

    โปรเจกต์ของเรามีชุมชนผู้ใช้ที่ค่อนข้างเล็ก ซึ่งอาจจะทำให้เกิดคำถามตามมาเช่น ทำไมต้องสนทนาหารือแบบสาธารณะเล่าในเมื่อดูเหมือนไม่มีเลยสนใจด้วยซ้ำ ทำไมต้องเสียเวลากับประเด็นข้างต้นที่กล่าวมา ในเมื่อไม่มีคนมองหรือสนใจ แล้วจะมีประโยชน์อะไรที่จะต้องลงลึกในรายละเอียด

ขาดความเชื่อมั่นในตนเอง

    เหตุผลที่เป็นไปได้อีกประการหนึ่งอาจจะเป็นเรื่องความกลัวที่จะต้องรับผิดชอบกับกลัวเรื่องการสืบต้นตอ ในตอนแรกนี่อาจจะฟังดูตลกไร้สาระดี เพราะว่า source code ทั้งหลายอย่างไรเสียก็ต้องไปรวมกันในคลังสาธารณะอยู่แล้ว สาเหตุเบื้องลึกที่แท้จริงน่าจะเป็นเรื่องของการขาดความเชื่อมั่นในตนเอง เมื่อมีการสนทนาหารือในที่สาธารณะและถูกบันทึกไว้เป็น chat log วิดีโอ หรือโพสในบล็อกต่างๆ ก็ทำให้สาธารณะชนวิพากษ์วิจารณ์ให้ความเห็น ซึ่งทำให้ขาดความมั่นใจได้

    ผมเป็นคนที่เชื่อมั่นอย่างแน่วแน่ว่าการทำงานในที่เปิดสาธารณะเป็นเรื่องดี แม้จะเป็นชุมชนขนาดเล็กก็ตาม การทำงานในที่เปิดช่วยให้คุณสามารถติดตามผลลัพธ์จากสมาชิกคนอื่นๆได้ ซึ่งเป็นการช่วยเสริมสร้างองค์ความรู้ หลายคนอาจจะมีมุมมองทัศนะที่แตกต่างโดยสิ้นเชิง และให้ประเด็นต่างๆมาขบคิดแบบที่คุณไม่เคยเจอมาก่อน นอกจากนี้แล้วหากสมาชิกของชุมชนเป็นส่วนหนึ่งของชุมชนในวงกว้างอีกทีหนึ่ง จะทำให้พวกเขารู้สึกดี มีกำลังใจ และเริ่มทำประโยชน์มากขึ้น สำหรับแนวคิดว่าจะสามารถทำประโยชน์แก่ชุมชนผู้ใช้ได้อย่างไรบ้างนอกเหนือไปจากการเขียนโค้ด สามารถดูได้ที่บทความของผม: 10 ways to contribute to an open source project without writing code

    การพบปะสมาชิกชุมชนแต่ละครั้งของผมผ่านไปด้วยดี เนื่องจากทุกคนล้วนเป็นมิตร และการไปเจอสมาชิกตัวต่อตัวนั้นน่าสนุกยิ่งนัก ดังนั้น เราจะทำอย่างไรดีเพื่อเอาชนะอุปสรรคหลายๆประการที่ผมกล่าวมาตอนต้น

• อย่างแรกเลย กำหนดนโยบายเลยว่าการสื่อสารต่างๆต้องดำเนินไปอย่างเปิดเผยในช่องทางสาธารณะ เว้นเสียแต่ว่าจะมีเหตุผลที่ดีพอที่จะไม่ทำอย่างนั้น
• เตือนตัวเองเสมอให้เริ่มทำงานแต่ละวันในช่องทางสาธารณะ เพราะเมื่อเริ่มที่นั่นแล้ว มันเหมือนเป็นการกำหนดมาตรฐานเริ่มต้นสำหรับตัวคุณเอง และกระตุ้นส่งเสริมให้สมาชิกคนอื่นๆพูดคุยสนทนาในช่องทางสาธารณะด้วย เป็นการสร้างกลุ่มคนขนาดใหญ่ให้ร่วมดำเนินการสนทนาไปด้วยกัน
• ย้ำเตือนให้สมาชิกคนอื่นๆตระหนักรู้ในนโยบายที่กำหนดขึ้นมาอยู่เสมอ
• แยกประเภทข้อมูลที่เกี่ยวข้องกับลูกค้ากับข้อมูลอื่นๆที่ไม่เกี่ยวข้อง ออกจากกัน อย่างน้อยก็เริ่มจากในระดับของการ suppport อย่าง NullPointerException ก็จะเป็น NPE เสมอ ไม่ว่าจะรายงานเข้ามาโดยลูกค้าหรือโดยสมาชิกของชุมชนเอง
• บันทึกช่องทางสาธารณะทุกครั้ง เพื่อที่สมาชิกของชุมชนจะได้มีโอกาสเข้ามาย้อนดูว่ามีการสนทนาหารืออะไรไปบ้าง
• หากต้องการทำงานเป็นส่วนตัว เงียบๆ ก็อย่าปิดเฉพาะช่องทางการสื่อสารภายนอก ให้ปิดช่องทางภายในด้วย แล้วทำงานของคุณไป เมื่อเสร็จก็กลับมา เพราะสิ่งที่จะรบกวน ยังไงก็รบกวนอยู่ดี ไม่ว่าจะเป็นจากสมาชิกของชุมชน หรือจากผู้ร่วมงานของคุณเอง
• หากคุณไม่สะดวกใจที่จะเขียน (เช่นเขียนบล็อกเกี่ยวกับฟีเจอร์ใหม่ๆที่คุณพัฒนา) ก็สามารขอให้ผู้อื่นที่คุณไว้ใจช่วยเขียนให้ ทุกโพสเป็นโพสที่ดีทั้งนั้น เว้นเสียแต่ว่าคุณไม่แม้แต่พยายามจะนำเสนอสิ่งดีๆตั้งแต่แรกแล้ว ชุมชนผู้ใช้ที่ดีนั้น จะยินดีต้อนรับข้อมูลใหม่ๆเพิ่มเติมอยู่เสมอ