ประสบการณ์การทำงานที่ GitLab

 (yorickpeterse.com)
1 คะแนน โดย GN⁺ 2024-02-12 | 1 ความคิดเห็น | แชร์ทาง WhatsApp

ประสบการณ์ที่ GitLab

  • ทำงานที่ GitLab ประมาณ 6 ปี ตั้งแต่เดือนตุลาคม 2015 ถึงธันวาคม 2021
  • ตัดสินใจลาออกจาก GitLab เพื่อทุ่มเทให้กับการพัฒนา Inko แต่ไม่เคยแบ่งปันประสบการณ์ที่ GitLab มาก่อน
  • เมื่อ NDA (ข้อตกลงไม่เปิดเผยข้อมูล) หมดอายุลง จึงมีพลังมากพอที่จะย้อนมองช่วงเวลาที่ GitLab ได้

ก่อน GitLab

  • ทำงานที่สตาร์ทอัพขนาดเล็กในอัมสเตอร์ดัม และพัฒนาไลบรารี parsing XML/HTML ชื่อ Rubinius และ Oga ไปพร้อมกัน
  • เลิกผลักดันการใช้งาน Rubinius ต่อเนื่องจากปัญหาด้านเงินทุนและปัญหาทางเทคนิค
  • เข้าร่วม GitLab โดยสอบถามว่าสามารถใช้เวลาสัปดาห์ละหนึ่งวันไปกับงาน Rubinius ได้หรือไม่

2015-2017

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

2017-2018

  • ประสิทธิภาพดีขึ้นอย่างมาก และ GitLab เริ่มให้ความสำคัญกับประสิทธิภาพอย่างจริงจังมากขึ้น
  • เปลี่ยนไปอยู่ใน "ทีมฐานข้อมูล" ที่มุ่งเน้นเรื่องประสิทธิภาพของฐานข้อมูล
  • สร้าง database load balancer ของ GitLab ซึ่งส่งผลเชิงบวกต่อประสิทธิภาพ
  • คัดค้านความต้องการของ GitLab เรื่อง database sharding โดยอิงจากข้อมูล

2019-2021

  • ย้ายไปทีม "Delivery" เพื่อโฟกัสกับการปรับปรุงกระบวนการรีลีสและเครื่องมือของ GitLab
  • หลังจาก commit เข้าสู่เมนบรাঞ্চแล้ว กว่าจะ deploy ไปยัง GitLab.com ใช้เวลาเฉลี่ยหลายวัน และกรณีเลวร้ายที่สุดนานถึง 3 สัปดาห์
  • เป็นผู้นำในการรวม GitLab Community Edition และ GitLab Enterprise Edition ให้เป็นหนึ่งเดียว
  • ปัญหาที่เกี่ยวข้องกับการจัดการแล็ปท็อปและการเปลี่ยนแปลงทางวัฒนธรรมทำให้แรงจูงใจและผลิตภาพลดลง
  • จากความขัดแย้งกับผู้จัดการคนใหม่ จึงมีการจัดทำ "แผนเร่งรัดผลงาน"

สิ่งที่ได้เรียนรู้

  • ความสามารถในการขยายขนาดต้องเป็นส่วนหนึ่งของวัฒนธรรมบริษัท: GitLab ไม่ได้ใส่ใจกับ scalability มากพอ
  • ทีมควรขับเคลื่อนด้วยข้อมูลและนักพัฒนามากกว่านี้: GitLab มีโครงสร้างที่ยึดผู้จัดการผลิตภัณฑ์เป็นศูนย์กลาง
  • หากไม่มีข้อมูล ก็ไม่สามารถตัดสินได้ว่าอะไรคือ 'ผลิตภัณฑ์ขั้นต่ำที่ใช้งานได้': GitLab ยึด "การเปลี่ยนแปลงฟีเจอร์ขั้นต่ำ" เป็นหลักสำคัญ แต่ในทางปฏิบัติกลับสร้างฟีเจอร์ที่ไม่ค่อยมีประโยชน์จำนวนมาก
  • SaaS กับการโฮสต์เองเข้ากันได้ไม่ดี: GitLab ให้บริการทั้งการติดตั้งแบบโฮสต์เองและ SaaS พร้อมกัน แต่แนวทางนี้ไม่ได้ผลนัก
  • คนที่มากขึ้นไม่ได้แปลว่าจะได้ผลลัพธ์ที่ดีกว่าเสมอไป: GitLab จ้างคนจำนวนมากตลอดหลายปี แต่การมีนักพัฒนามากขึ้นไม่ได้ทำให้ผลิตภาพดีขึ้นเสมอ
  • ความขัดแย้งจากการใช้ Ruby on Rails: GitLab ประสบความสำเร็จด้วย Ruby และ Ruby on Rails แต่เมื่อโครงการมีขนาดใหญ่ขึ้นก็กลายเป็นความท้าทาย
  • เวลาในการ deploy โค้ดสำคัญอย่างยิ่งต่อความสำเร็จขององค์กร: ที่ GitLab การลดเวลา deploy โค้ดเป็นเป้าหมายสำคัญ
  • เงินเดือนตามที่ตั้งเป็นการเลือกปฏิบัติ: GitLab จ่ายค่าตอบแทนต่างกันตามสถานที่ ซึ่งถือเป็นการเลือกปฏิบัติ

ความเห็นของ GN⁺

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

บทความที่เกี่ยวข้อง

1 ความคิดเห็น

 
GN⁺ 2024-02-12
ความคิดเห็นจาก Hacker News

  • ข้ออ้างที่ว่าค่าจ้างตามพื้นที่ตั้งเป็นการเลือกปฏิบัติ

    • การนำค่าจ้างตามพื้นที่ตั้งไปเปรียบเทียบกับการเลือกปฏิบัติจากสีผิวหรือเพศนั้นไม่เหมาะสม เพราะสีผิวและเพศเป็นสิ่งที่เปลี่ยนไม่ได้ แต่ที่อยู่อาศัยสามารถเปลี่ยนได้
    • พื้นที่อยู่อาศัยเชื่อมโยงกับประเด็นเชิงปฏิบัติที่เกี่ยวข้องกับงาน เช่น ข้อกฎหมาย ภาษี เขตเวลา และค่าเดินทางที่บริษัทต้องเผชิญ
    • จะถกเถียงเรื่องการเลือกปฏิบัติจากค่าจ้างตามพื้นที่ตั้งก็ได้ แต่การมองว่าเหมือนกับการเลือกปฏิบัติทางเชื้อชาติหรือเพศอาจทำให้การถกเถียงจบลงทันที

  • เริ่มต้นด้วยหมายเลขพนักงาน 28 แล้วค่อย ๆ มีผู้จัดการจำนวนมากถูกวางไว้เหนือเขา

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

  • ความเห็นเกี่ยวกับการที่พนักงานใช้คอมพิวเตอร์ส่วนตัว

    • ไม่ว่าองค์กรจะมีขนาดเท่าใด ก็ควรให้ใช้คอมพิวเตอร์ที่บริษัทจัดให้
    • เรื่องนี้มีข้อดีมากทั้งในการควบคุมทรัพย์สินทางปัญญาของบริษัท และแยกเวลางานออกจากเวลาส่วนตัว อีกทั้งก็ไม่ได้มีค่าใช้จ่ายสูงมาก

  • ความเห็นเกี่ยวกับผู้จัดการที่แย่

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

  • มุมมองที่เปลี่ยนไปต่อค่าจ้างตามพื้นที่ตั้ง

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

  • ความเห็นเกี่ยวกับการใช้ Ruby/Rails

    • Ruby ถูกออกแบบมาบนสมมติฐานที่ว่าความเร็วของภาษาไม่ใช่เรื่องสำคัญ แต่ปัจจุบันมีโมเดลการเขียนโปรแกรมบน Node.js และ JVM ที่ใช้การประมวลผลแบบอะซิงโครนัสเพื่อทำงานอื่นระหว่างรอ I/O/เครือข่ายได้
    • Ruby/Rails อาจยังมีประโยชน์ในบางสถานการณ์ แต่เมื่อเวลาผ่านไปอาจดูแลรักษาได้ยาก

  • ความเห็นเกี่ยวกับนโยบายค่าจ้างในบริษัทระดับโลก

    • หากนักพัฒนาในอัมสเตอร์ดัมสร้างคุณค่าได้เท่ากับนักพัฒนาใน Bay Area ก็ควรได้รับค่าจ้างเท่ากัน
    • ในฐานะบริษัทระดับโลกที่แข่งขันกับบริษัทระดับโลกอื่น ๆ ระยะยาวแล้ว การจ่ายค่าตอบแทนให้สอดคล้องกับคุณค่าของบุคลากรโดยไม่ขึ้นกับพื้นที่ตั้งเป็นสิ่งสำคัญ

  • คำถามเกี่ยวกับนโยบายราคา GitLab

    • มีคำถามว่าจะเลือกการตั้งราคาตามพื้นที่ตั้งได้อย่างไรในหน้าราคาของ GitLab

  • ปัญหาด้านการบริหารเกี่ยวกับความสามารถในการขยายตัวของ GitLab

    • GitLab สร้างรายได้หลักจาก GitLab Enterprise Edition แบบโฮสต์เอง ส่วน GitLab.com มีต้นทุนสูงแต่สร้างรายได้ไม่มาก
    • การที่บริษัทลงทุนในส่วนที่สร้างรายได้ย่อมสมเหตุสมผล แต่ก็ควรคำนึงด้วยว่าการปรับปรุงประสิทธิภาพของ GitLab.com อาจช่วยดึงดูดลูกค้าเพิ่มและสร้างชื่อเสียงที่แข็งแกร่งขึ้นได้

  • ความเห็นเกี่ยวกับการเติบโตของบริษัทและบทบาทของพนักงานยุคแรก

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