Tag Archives: Presentation Review

เล่าถึง 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

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

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

พูดถึง 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 ที่มีลูกค้าเป็นคนทั่วไปหรอก แต่สำหรับผม ผมคิดว่าทำได้แค่นี้ก็ถือว่าประสบความสำเร็จเพียงพอแล้วครับ

[Presentation review] How To Approach Refactoring

เนื้อความไม่มีอะไรใหม่ แต่ผู้พูด พูดได้ดี สนุกและเข้าใจง่ายมาก

ข้างล่างนี้ เป็นข้อความที่ฟังแล้วโดนใจ

To write a good code, we need to understand that we can’t write a good code at the first sit.

– ลด Ego ตัวเองให้หมด รับฟัง comment คนอื่นอยู่เสมอ แล้ว code คุณจะออกมาดี

A software that need to be maintained is a successful software, otherwise you threw it away.

I became a programmer because scientific programming, I’m still a programmer today because the art of programming.

– อันนี้ส่วนตัวโดนเต็มๆ สำหรับผมการเขียนโปรแกรมยังสนุกอยู่เพราะมันไม่มีวิธีการตายตัว

ช่วงตั้งแต่นาทีที่ 34:20 เค้าอธิบายถึงเรื่อง long method มีวิธีการอธิบายกับเพื่อนร่วมงานที่ชอบเขียน method ยาวๆ ได้น่าสนใจทีเดียว