Tag Archives: Github

เล่าถึง presentation Optimizing for Happiness by Github founder

แอบตกยุคนิดหน่อย เพิ่งจะมีโอกาสนั่งดู presentation เก่าพอสมควรซัก ปีกว่าๆ 2 ปีได้ ที่ชื่อว่า Optimizing for Happiness โดย Tom Preston-Werner  หนึ่งในผู้ก่อนตั้ง Github ซึ่งเค้ามาพูดถึงการบริหารงานบริษัทที่เค้ายึดหลักความสุขเป็นสำคัญ

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

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

ถ้า search หาหัวข้อการพูดนี้ จะพบว่ามี 2 เวอร์ชั่น อันนึงพูดที่ Startup School จัดโดย YC อีกอันพูดที่คอนเฟอเรนซ์ Ruby ที่อาเจนตินา สไลด์ของอาเจนตินาอยู่ที่นี่ครับ

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

ขอยกช็อตหล่อๆ ช่วงท้ายเวอร์ชันอาเจนตินามาให้อ่านกันนะครับ

เค้าจะพิสูจน์ว่าบริษัทที่จะเจริญเติบโตไปได้อย่างดี ต้อง Optimizing for Happiness

OPTIMIZING FOR HAPPINESS = INVESTING IN HUMANS

INVESTING IN HUMANS = A HAPPY TEAM

A HAPPY TEAM = A GREAT PRODUCT

A GREAT PRODUCT = HAPPY UESRS

HAPPY UESRS = PAYING CUSTOMERS

PAYING CUSTOMERS = MORE MONEY

MORE MONEY = A BETTER ABILITY TO OPTIMIZE FOR HAPPINESS

ใครสนใจเนื้อหาเต็มๆ ก็ลองไปดูไปฟังกันนะครับ

บริษัทไหนทำได้แบบนี้ แล้วหาคนทำงานไม่ได้ เอาผมไปทำงานด้วยเลยเอ้า!

Advertisements

เข้าใกล้ Continuous Deployment ไปอีกหนึ่งก้าว

ช่วงนี้มีความสุขมากกับโปรเซสการ deploy code ขึ้น production ของบริษัทที่เริ่มเข้ารูปเข้ารอยเสียที หลังจากถกเถียงกันมาหลายเดือน ตอนนี้สามารถ deploy ได้ทุกวันแล้ว สาเหตุที่ชอบ ให้ deploy บ่อยๆ คือ

  1. ได้รับ feedback ของ feature ที่พัฒนาไปอย่างรวดเร็ว ไม่นานจนต้อง switch ไปทำอย่างอื่นจนลืม และทำให้ไม่ต้องทำงานพร้อมๆ กันหลายๆ เรื่อง
  2. ถ้ามีปัญหาอะไรหลังจาก deploy ก็สามารถหาสาเหตุได้ง่าย เพราะจำนวน change ในแต่ละรอบน้อย
  3. เวลาจะ hotfix อะไร ไม่ต้องกังวลเรื่องความต่างของ version มาก
  4. ตอบฝ่าย business และ support ได้ง่ายขึ้นว่า fix หรือ feature อะไรจะ live เมื่อไหร่

โปรเซสก็ไม่มีอะไรมาก ได้แรงบันดาลใจส่วนใหญ่มาจาก Github flow ตามนี้

  1. Dev เริ่ม implement feature ใช้เวลาเฉลี่ยต่อ story ประมาณครึ่งวัน
  2. พอทำเสร็จก็ merge master ล่าสุดเข้าที่ branch นี้
  3. จากนั้นก็ deploy ไปที่ sandbox server ให้ PM มาดูว่าตรงตามความต้องการหรือยัง ถ้ายังก็กลับไปแก้ใหม่เรื่อยๆ จนผ่าน
  4. เปิด pull-request branch ให้คนมา review ตรงนี้จะแก้เฉพาะ code style ไม่แก้ตัว behavior ของ feature แล้ว
  5. ในขณะเดียวกัน CI ก็จะดึง branch นั้นไป run test ทั้งหมด ถ้า fail ก็ fix กันไป ตรงนี้ใช้ service ของ CircleCI
  6. พอ test ผ่าน และมีคน review 2-3 คนแล้วก็จะ merge เข้า master
  7. ถ้าทุกคนทำตามขั้นตอนที่ผ่านมาทั้งหมด ก็จะทำให้ master อยู่ในสถานะพร้อม deploy เสมอ
  8. ก่อนเวลาหนึ่งชั่วโมง deploy ขึ้น staging server ให้ QA ทำ smoke test
  9. ถึงเวลาก็ deploy ขึ้น production
  10. ตรวจสอบ error log กับ performance stats

ฟีเจอร์ไหนที่ทาง business ต้องการให้มีการประกาศก่อนที่จะ release ก็จะใช้วิธีการซ่อนเอาไว้ด้วย feature toggle ซึ่งตรงนี้ใช้ rollout ช่วย ก็คือทุกอย่างจะถูก deploy ขึ้นไปบน production server หมด เมื่อถึงเวลาที่ต้องการจึงค่อย activate เจ้าตัว rollout นี้ยังช่วยในเรื่องการ activate ให้เฉพาะ staff หรือ beta user ได้ทดลองใช้ feature ก่อนจะเปิดให้ทุก user ใช้ได้อีกด้วย

การ deploy บ่อยๆ จะเป็นไปไม่ได้เลยถ้ามี down time ระหว่าง deploy นาน ระบบที่บริษัทตอนนี้ใช้ preboot ที่ทาง Heroku มีให้ ก็เลยสะดวกหน่อย แต่ก็ยังมีปัญหาอยู่หากต้องมีการ migrate database schema

อีกสิ่งหนึ่งที่ยังทำให้หงุดหงิดใจอยู่คือ test suite นี่มัน run ทั้งหมดนานไปหน่อย บน CircleCI ใช้เวลาประมาณ 30 – 40 นาที ถ้ารัน parallel บน SSD ที่บริษัทใช้ประมาณ 15 นาที ถ้า test เร็วขึ้นกว่านี้ได้จะดีมากๆๆๆ

พูดถึง Github

ช่วงนี้ได้มีโอกาสดู presentation 2 อันติดๆโดย Zach Holman คนพูดเจ้าประจำของ Github ซึ่งเค้าพูดในเรื่องตัวบริษัทและวัฒนธรรมของ Github

ฟังไปแล้วรู้สึกเคล้ิมมาก อยากให้ environment การทำงานระดับนี้เกิดกับบริษัทในไทยบ้าง

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

ผมชอบในไอเดียที่เค้า force ให้ตัวเองเป็น distributed team ขนาดที่ว่านั่งอยู่ใกล้กัน ก็ยัง chat จริงๆ แล้วก่อนหน้านี้ผมเป็นคน anti remote และ distributed team มาก รู้สึกว่ามันทำให้เกิดความล่าช้าและความผิดพลาดด้านการสื่อสารที่ไม่ควรเกิดขึ้นมากมาย แต่ถ้ามันจะแลกด้วยการที่่เราสามารถจ้างคนเก่งๆคนไหนก็ได้บนโลก และไม่ทำให้เกิดปัญหาพนักงานต้องลาออกเนื่องจากการต้องย้ายตามครอบครัว ผมว่าโคตรคุ้มเลย (จนถึงวันนี้ Github ยังไม่มีพนักงานออกครับ)

Github ไม่มี manager หรือคนคิดเรื่อง product เลย คนที่มีหน้าที่ดูแลเรื่องนี้คือตัว developer ทั้งหลาย แต่สิ่งนี้มันเกิดขึ้นได้เพราะว่าตัว product ของ Github นั้นมันเป็น product สำหรับ developer ซึ่งเมื่อตัว developer เป็นคนใช้งานมันเองเต็มๆ แล้ว อะไรดีอะไรไม่ดีตัวเค้าเหล่านั้นจะเป็นคนที่รู้อยู่แก่ใจทั้งหมด ซึ่งจะต่างกับบริษัทที่ทำ product สำหรับ end-user ที่ตัว developer อาจจะไม่ค่อยเข้าใจผู้ใช้เหล่านั้นมากนัก

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

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

การปรับเปลี่ยน backend ให้ทำงานได้เร็วขึ้นและรองรับจำนวนผู้ใช้ได้มากขึ้นนี้ ชี้ให้เห็นว่าเค้ามองว่าจุดขายของเค้าคือความเร็ว repository server ถ้ามันช้าคงไม่มีใครอยากใช้ แต่เบื้องหลังการปรับปรุง backend นั้น ผมเชื่อว่าเค้าต้องแลกมาด้วยการ ไม่ทำ feature หลายๆอย่าง เพื่อเอาทรัพยากรบุคคลมามุ่งเน้นตรงนี้ เป็นจุดที่ผมอยากสื่อสารไปถึงคนที่ทำ product ว่าอย่าไปตกหลุมพลางการสร้าง feature ครับ การมี feature เพิ่มขึ้น ไม่ได้หมายความว่า product พัฒนาขึ้นเสมอไป ฟีเจอร์ใดที่เป็นจุดสำคัญของเราต้องเอาให้เจ๋ง

Git ซึ่งได้ชื่อว่าเป็น version control ที่ทำให้การสร้าง branch ง่ายดายมาก หลายๆ บริษัทติดกับดัก นำข้อดีข้อนี้ไปใช้ในทางที่ผิด ไปสร้าง branch มากมาย สร้าง process มากมายยุ่งอยากทำให้เสียเวลาโดยใช่เหตุ

สำหรับ Github บริษัทที่ควรจะรู้จัก Git ดีเป็นอันดับต้นๆ ของโลก เค้ากลับมี branch process ที่เรียบง่ายมาก และเป็นสาเหตุหนึ่งที่ทำให้เค้าสามารถ deploy ขึ้น production ได้หลายๆ ครั้งต่อวัน

องค์ประกอบอื่นๆ ที่ทำให้เค้าสามารถ deploy ได้บ่อยมาก คือ test ที่รันเร็วมาก, ระบบ automate deploy, ระบบ monitoring, ระบบ  rollback,  process ที่ใครในบริษัทก็ deploy ได้ และการมี staff-only feature flags

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