by

Release Early, Release Often

Our ideas suck

เวลาเราทำ software หรือ product ต่างๆ เราควร release เนิ่นๆ, release ถี่ๆ แล้วเรียนรู้ feedback จากผู้ใช้ให้เร็วๆ มากๆ …

หลายคนเห็นขัดแย้งกับแนวคิดนี้ พยายามคิดฝัน, ออกแบบ product ขึ้นมาตามความคิดและประสบการณ์ของตัวเองโดยเชื่ออย่างแรงกล้าว่าผู้ใช้ทั้งโลกต้องการ software แบบนี้แหละ, product แบบนี้มันต้องเจ๋งแน่ๆ แล้วพวกเค้าก็ใช้เวลายาวนาน พัฒนา software นั้นออกมา แล้วจึงปล่อยออกให้ผู้ใช้ได้ใช้งาน ซึ่งส่วนใหญ่งานเหล่านั้นจะ fail คนถึงพูดกันว่า startup ส่วนใหญ่ fail ไปก็เป็นเรื่องธรรมดา

มีหลากหลายเหตุผลที่เราควร release software ตั้งแต่เนิ่นๆ

เราไม่มีทางรู้เลยว่า idea ของเรานั้นมันเวิร์คจริงรึเปล่า วันแรกๆ ของการออกแบบ product นั้น ทีมของเราจะได้ไอเดียจากทุกคนในทีมมาเป็น list ของ feature ยาวเหยียด ในดงของ feature เหล่านั้น มีบางอันที่ work, บางอันไม่ work, บางอันต้องทำ, บางอันไม่ต้องทำก็ได้, บางอันทำเท่ๆ, บางอันทำแล้วยอดขายกระจุยกระจาย ทางที่เราจะรู้ก็คือการเอาไปให้ลูกค้า หรือผู้ใช้ได้ทดลอง ถ้าเราไม่ release เนิ่นๆ เราจะไม่มีทางรู้เลยว่า product ของเราควรมี feature อะไรอยู่ และอะไรควรตัดออกไป เราควร validate idea กับ ผู้ใช้ ไม่ใช่ validate idea กับคนที่อาวุโสสูงสุดในห้องประชุม

มันดีกว่าแน่ ถ้าเรารีบ release แล้วเห็นว่า feature นี้มันไม่ work เราจะตัด series ของ feature ลูกของมันทั้งยวงออกได้หมดอย่างสบายใจ

เมื่อเรา release ถี่ๆ เราก็จะได้เรียนรู้จากผู้ใช้ถี่ๆ นั่นทำให้เรามีโอกาสได้ feedback เด็ดๆ จากผู้ใช้เร็วๆ และถ้า idea ไหนไม่ work เราก็จะ fail เร็วกว่าคนอื่น จะได้เอาเวลาไปคิดทำอย่างอื่น (ในขณะที่คู่แข่งกำลังง่วนกับ feature list ยาวเหยียดที่ผู้ใช้ไม่เคยได้เห็น)

โลกมันหมุนไปเร็วมาก คุณจะเห็นว่าเกมหลายๆ เกม, service หลายๆ อย่าง มักจะ release feature ใหม่ออกมาให้คนกลุ่มเล็กๆ ลองเล่น ถึงแม้จะยังมี bug อยู่มาก แต่ถ้ามันไม่ work เค้าจะได้หยุดทำซะ ไม่ต้องเทพลังไปทำให้มันเนียนกริ๊ปให้เปลืองเปล่าๆ หรือบางคนใช้แนวคิดที่ว่า “ขอให้มีสายตาเฝ้ามองมากพอ บั๊กทั้งหมดก็เป็นเรื่องง่าย” ครับ, เราจะจ้าง QA มาเยอะแยะทำไมให้เปลือง ในเมื่อเกมของเรามีผู้เล่นมากมายยินดีจะเล่นเกมด่านใหม่ๆ ตัวละครใหม่ๆ ก่อนใคร แม้ว่าจะเจอ bug/glitch หน่อยก็ไม่เป็นไร(ลองนึกถึง Ragnarok server Sakray นะครับ) ผู้เล่นกลุ่มนี้มักจะเป็นพวก early adopter ซะด้วย เผลอๆ คนทำเกมจะได้ feedback จากคนกลุ่มนี้ด้วย และถ้าเกมมันเจ๋ง คนกลุ่มนี้พร้อมจะเป็น influencer คอยบอกต่อความเจ๋งให้เราได้อีกด้วย

ถ้าเราสังเกต app ที่เหล่า startup เจ้าใหม่ๆ release version แรกๆ ออกมาจะพบว่า ปุ่มหลายๆ ปุ่ม กดไปแล้วก็ไม่เกิดอะไรขึ้นมา, ครับ, เค้าตั้งใจทำปุ่มที่กดแล้วไม่เกิดอะไร, ไม่ใช่ bug แต่เพราะว่าเค้าติด analytic tools ไว้ เช่น ปุ่มของ feature นี้คนกดเยอะกว่าปุ่มของอีก feature, ใน release ต่อๆ ไปเราก็ควรจะทำ feature นี้, ปุ่มของ feature นี้ไม่มีคนกดเลย เราก็จะเรียนรู้แล้วว่า อย่าไปทำมันเลย feature นี้

เราจะเห็นปุ่ม feedback มากมายใน app ใหม่ๆ นั่นก็เพราะเค้าอยากได้ feedback จากผู้ใช้ยังไงล่ะครับ (และแน่นอน startup บางเจ้ารีบ release จัด, release โดยที่ปุ่ม  feedback ยังเป็นแค่ mockup ก็มี 😀 )

โชคดีที่ผมมีโอกาสอ่านเรื่องนี้ครั้งแรกในบทความ The Cathedral and the Bazaar ของ Eric Steven Raymond ตั้งแต่สมัยที่ยังเรียนอยู่ และพยายามนำมาใช้เป็นหลักคิดมาตลอด

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

ก่อนอื่น เราต้องยอมรับความจริงข้อแรกก่อนว่าเราไม่มีทางรู้ใจคนทั้งโลกได้ด้วยการนั่งคิดเฉยๆ ถ้าเราอยากรู้ว่าอะไร work ไม่ work ก็ต้องทำออกมา แล้วเอาไป validate แล้วเราค่อยเรียนรู้ว่าต้องทำอย่างนั้น อย่างนี้

วันก่อนผมเพิ่ง release Pantip Plus มันเป็น extension ของ Google Chrome เอาไว้ให้เราอ่าน Pantip ได้สบายขึ้น

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

คนที่เป็น perfectionist ควรเริ่มเปลี่ยนแนวคิด จากที่อะไรที่ออกมาต้อง  perfect, กลายเป็นเดี๋ยวมันออกไปแล้ว เราปรับปรุงไปมันก็จะ perfect เองนั่นแหละ ทั้งนี้ทั้งนั้นประเด็นอยู่ที่มัน perfect ในสายตาเรา หรือ perfect ในสายตาผู้ใช้ ถ้าตามหลักคิดของศาสนา Agile คือ ต้องคุยกับ PO บ่อยๆ, เอา software ไปให้ PO จิ้มบ่อยๆ ไงครับ

นั่นแหละ บางทีโลกก็หมุนเร็วเกินไป

Photo Credit: @Photo. via Compfight cc

Comments

comments

Page 1 of 11