วิธี Ship โปรเจกต์ในบริษัท Big Tech

ทำไมการเปิดตัว (Shipping) ถึงยาก

• หลายคนเข้าใจผิดว่าการ ‘เปิดตัว’ เป็นเรื่องง่าย แต่ในความเป็นจริง สถานะปกติคือการเปิดตัวมักล่าช้า ถูกยกเลิก หรือมีปัญหาเพราะคุณภาพงานยังไม่สมบูรณ์
• การเขียนโค้ดเสร็จทั้งหมดหรือปิด Jira ticket ครบทั้งหมด ไม่ได้แปลว่าจะเปิดตัวได้โดยอัตโนมัติ สำหรับการเปิดตัวต้องมีใครสักคนรับบทเป็นผู้นำ
• การเปิดตัวต้องเป็นงานที่มีความสำคัญสูงสุด หากโฟกัสกับประสบการณ์ผู้ใช้ (UX) มากเกินไป กลับอาจทำให้การเปิดตัวล่าช้า
• หากต้องการเปิดตัวโปรเจกต์ให้สำเร็จ จำเป็นต้องมีผู้นำทางเทคนิคหรือ DRI (Directly Responsible Individual) ทีมที่มีวิศวกรรับบทบาทนี้จะมีโอกาสสำเร็จสูงกว่า

‘การเปิดตัว’ คืออะไร?

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

ความสำคัญของการสื่อสาร

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

การแก้ปัญหาระหว่าง deploy สู่ production

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

ตอนนี้สามารถเปิดตัวได้เลยหรือไม่?

• สิ่งสำคัญคือต้องถามตัวเองว่า ตอนนี้สามารถเปิดตัวได้ทันทีหรือไม่ หากไม่ได้ ต้องคิดต่อว่าอะไรต้องเปลี่ยนจึงจะทำได้
• ควรใช้ feature flag และสภาพแวดล้อม staging เพื่อให้ได้รับฟีดแบ็กให้เร็วที่สุด
• ช่วงก่อนเปิดตัวจริงควรลดงานเทคนิคใหม่ ๆ ลง และเตรียมพร้อมให้สามารถตอบสนองได้อย่างรวดเร็วเมื่อเกิดปัญหา

สรุป

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

[GN⁺]

ความคิดเห็นบน Hacker News

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

[signaling]

ได้คัดข้อความเห็นที่น่าประทับใจมาบางส่วน

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

“วิธีชนะเกมนี้คือไม่เล่นเกมนี้”