startup หลายคนอาจเคยได้ยินคำว่า “อไจล์” (Agile) ผ่านหูกันมาบ้าง และหลายคนก็สงสัยว่าจริงๆ แล้วมันคืออะไรกันแน่ เป็นทางสายเทคนิคเท่านั้นที่ต้องเข้าใจหรือเปล่า หรือว่าคนที่ทำสาย Business ใน Startup เองก็ควรทำความเข้าใจด้วย วันนี้ thumbsup มีผู้เชี่ยวชาญด้านอไจล์โดยตรงมาเล่ารายละเอียดให้ฟัง รวมถึงทำไม Startup ต้องแค์สิ่งนี้ด้วย?
Editorial note: บทความนี้คือบทความพิเศษที่เราเรียกว่า Guest Post จากคุณกุล
บทความนี้ถือเป็นทรัพย์สินทางปัญญาของผู้เขียน ซึ่งมี thumbsup เป็นผู้เผยแพร่เดียวที่ได้รับอนุญาตอย่างเป็นทางการ หากต้องการนำบทความไปใช้กรุณาให้เกียรติด้วยการอ้างอิงชื่อผู้เขียนและลิงก์ กลับมายังบทความต้นฉบับ
ในช่วงสามสี่เดือนที่ผ่านมานี้ ทีมอไจล์โค้ชจาก Proteus Agility ได้มีโอกาสไปเป็น mentor ในหัวข้ออไจล์ให้ startup accelerator มาบ้าง ได้มีโอกาสพูดคุยกับทีม startup ที่ถือได้ว่าฝ่าฟันผู้คนนับร้อยเข้ามารอบสุดท้าย ร่วมสิบทีม ทุกทีมล้วนมีไอเดียและแนวทางธุรกิจที่น่าสนใจและน่าตื่นเต้น แต่สิ่งที่พวกเราเป็นห่วงและตกใจคือช่องว่างของความสามารถในการพัฒนาซอฟต์แวร์ของทีมที่เราเจอนั้นกว้างมาก เรียกได้ว่ามีตั้งแต่ระดับโปรไปจนถึงเตรียมอนุบาลเลยทีเดียว บอกตรงๆว่าพวกเราช๊อคมากที่บางทีมไม่มีแม้แต้สิ่งจำเป็นพื้นฐานอย่าง version control system ที่เอาไว้บันทึกการเปลี่ยนแปลงของ source code บางทีมยังเก็บ code ไว้ใน hard disk เฉยๆ
ผมเคยขู่ไปว่า ถ้าผมเป็นนักลงทุนที่บังเอิญเคยมีความรู้ทางการพัฒนาซอฟต์แวร์อยู่บ้างแล้วมารู้ว่าทีมคุณไม่ใช้ version control, ผมไม่มีทางให้เงินกับ startup อย่างพวกคุณหรอกนะ มันเหมือนคุณเป็นหมอผ่าตัดที่ไม่ล้างมือ มันเหมือนคุณไม่มีความรับผิดชอบในวิชาชีพของคุณเลย
ยิ่งเรื่องอไจล์ยิ่งไม่ต้องพูดถึง ผมไม่แปลกใจนะครับ ที่หลายๆทีมไม่รู้จักอไจล์มาก่อนเลย สำหรับบ้านเราก็เรียกได้ว่าค่อนข้างใหม่ แม้ว่าโลกเขาจะเพิ่งฉลองอไจล์ครบรอบสิบปีไปไม่นาน และฝั่งอเมริกาก็เรียกได้ว่าใช้กันจนคนไม่ใช้ต่างห่างที่เรียกว่าแปลกไปแล้ว การไม่มีโครงสร้างพื้นฐานที่จำเป็นเหล่านี้มันก็เหมือนเอาของเสปกต่ำไปทำตึกสูง ตอนสร้างเสร็จใหม่ๆก็สวยงามหน้าตาดี พอคนอยู่เยอะๆเริ่มร้าว พอต่อเติมเท่านั้นก็ถล่มลงมาทับกันตายเกลื่อน ถ้า startup ไม่มีพื้นฐานเหล่านี้ เราจะไม่มีวัน scale ไปไม่ได้ไกล (ตึกถล่มก่อน)
พล่ามมาตั้งนานแล้ว ตกลงอไจล์มันคืออัลไล? ถ้าคุณไปถามคนสิบคนว่า เขาคิดว่าศาสนาพุทธ คืออะไร เชื่อได้เลยว่าคุณจะได้คำตอบที่แทบไม่เหมือนกันเลยสิบคำตอบ ตั้งแต่ สติ นิพพาน ไปยัน พระเครื่อง ซึ่งก็ทำนองเดียวกับอไจล์เนื่องจากอไจล์เป็นแนวคิด ไม่ใช่ process ไม่ใช่ methodology ไม่ใช่ framework ที่มีข้อกำหนดชัดเจน คำนิยามของอไจล์จึงไม่ตายตัว สำหรับผมถ้าพูดโดยภาพรวมแล้ว อไจล์คือแนวคิดเชิงประจักษ์ (empirical) ในการพัฒนาซอฟต์แวร์ โดยยอมรับธรรมชาติของการทำซอฟต์แวร์ที่ว่า เราไม่รู้ว่ามันจะใช้เวลาเท่าไหร่เป๊ะๆ เราไม่รู้ว่ามันจะต้องทำยังไงเป๊ะๆ เราต้องลงมือทำมันดูก่อน แล้วภาพมันจะชัดขึ้นเรื่อยๆ ฟังดูอาจจะเหมือนนี่มันมั่วไปเรื่อยๆรึเปล่า จริงๆแล้วไม่ใช่นะครับ มันคือการลองผิดลองถูกอย่างมีวินัย จริงๆถ้าจะเปรียบวิธีแบบนี้กับวิธีแบบเดิมๆ ที่มักจะเริ่มต้นด้วยการวางแผนละเอียดยิบใหญ่โตยาวนาน แล้วก็มานั่งเทียนทำนาย (predictive) ว่างานจะเสร็จเมื่อไหร่ มันเหมือนอไจล์เป็นวิทยาศาสตร์และวิธีแบบเดิมที่เราเรียกกันว่า Waterfall นั้นเป็นไสยศาสตร์ซะมากกว่า อาจจะเคยได้ยินคำว่า Scrum หรือ Extreme Programming หรือ Kanban มาบ้าง ซึ่งก็เป็นแนวทางปฏิบัตแบบอไจล์ที่มีข้อกำหนดชัดเจนขึ้น(แต่ก็ยังไม่ชัดเป๊ะอยู่ดี) มีรายละเอียดต่างๆกันไปแต่ก็เป็นแนวเชิงประจักษ์เหมือนกัน จะเทียบได้ว่าเป็นลัทธิของอไจล์ก็คิดว่าไม่ผิดอะไร
การทำซอฟต์แวร์สมัยก่อนด้วย Waterfall (และเป็นที่น่าเศร้าว่าหลายๆคนก็ยังใช้กันอยู่) ที่เริ่มต้นด้วยการวางแผนงานละเอียดทุกขั้นตอน แล้วเริ่มเก็บ requirement ทุกเม็ด ต่อด้วยการออกแบบซอฟต์แวร์ การโปรแกรม การทดสอบ และ การส่งมอบนั้น สิ่งที่มักจะเจอกันประจำคือ แผนที่วางใว้หลุดตลอดและไม่เคยทำได้ตามแผน ปัญหาเพิ่มขึ้นเรื่อยๆเหมือนดินพอกหางหมูแต่ก็ต้องหมกไว้ รีบทำให้จบๆไป โยนอุจจาระกันเป็นทอดๆ ลูกค้าเพิ่งมารู้ตัวตอนส่งมอบว่าที่ขอไว้ทำได้ทันไม่ถึงครึ่ง หนำซ้ำยังใช้ไม่ได้เต็มที่เพราะตั้งแต่คุยกันไว้เมื่อปีที่แล้วนั้นความต้องการทางธุรกิจเปลี่ยนไปหมดแล้ว วิธีการแบบนี้เคยเป็นวิธีการที่เหมาะสมที่สุดในการพัฒนาซอฟต์แวร์เมื่อหลายสิบปีก่อน เพราะสมัยโน้นการแก้โปรแกรมเป็นเรื่องที่มีค่าใช้จ่ายสูง สมัยโน้นเราเขียนโปรแกรมลงบนบัตรเจาะรู และความต้องการทางธุรกิจก็ไม่ได้มีความเปลี่ยนแปลงรวดเร็วนัก สมัยนี้บัตรเจาะรูมีให้ดูได้แต่ในพิพิธภัณฑ์ แต่วิธีการทำซอฟต์แวร์แบบดึกดำบรรพ์ยังมีให้เห็นอยู่ทั่วไป
อไจล์ยอมรับอย่างหน้าชื่นตาบานว่าไม่มีใครเป๊ะ ลูกค้าก็ไม่รู้ว่าฉันต้องการอะไรเป๊ะๆ คนทำก็ยังไม่รู้ว่าต้องทำยังไงเป๊ะๆ งั้นก็มาค่อยๆช่วยกันทำ แต่ทว่าเราเชื่อใจกันนะ เราให้ความสำคัญกับเรื่องเทคนิคนะ เรามาเจอกันบ่อยๆนะ คุยกันสั้นๆแต่คุยกันทุกวัน ทุกสองอาทิตย์ก็มาส่งมอบซอฟต์แวร์และมาประชุมกันทีว่าที่ทำมาใช่ไหม ถ้าไม่ใช่จะเปลี่ยนเป็นยังไง อะไรที่สำคัญที่สุดเอามาทำก่อนนะ แต่ทว่าสิ่งที่ส่งมอบให้ลูกค้านั้นคือซอฟต์แวร์ที่ใช้งานได้จริง ถ้าเป็นบ้านก็คือส่งเป็นห้องจริงๆ อาจเป็นห้องน้ำก่อนถ้ามันสำคัญที่สุดสำหรับเขา แต่ใช้ได้จริง ถ่ายหนักถ่ายเบาได้จริงๆ ไม่ใช่ส่งแต่พื้นบ้านครบทุกห้องแต่ยังใช้ไม่ได้จริงซักห้องเลย ใช้ๆห้องน้ำไปสองสามวันเกิดไม่รู้อะไรดลใจ เอาชุดทดสอบการตั้งครรภ์มาทดสอบก็อัศจรรย์พบว่าท้อง ชีวิตเปลี่ยนทันที โชคดีที่ห้องโฮมเธียร์เตอร์ยังไม่สร้าง เลยเปลี่ยนแผนเป็นห้องนอนลูกแทนได้ทัน (เสียดายชีวิตจริงบ้านผมเปลี่ยนอย่างนี้ไม่ได้ตอนรู้ตัวว่าภรรยาท้อง!)
อ่านมาตรงนี้บางคนคงเริ่มบ่นในใจแล้วว่า เอ่อ … แล้วตกลงอไจล์มันเกี่ยวอะไรกับ startup นะครับ
อ้าว startup เราทำซอฟต์แวร์ไหมละครับ แล้วเรารู้ไหมครับว่าจริงๆลูกค้าอยากได้ feature อะไร พอเขาเล่นแล้วบ่นอุบจนคุณถึงบางอ้อเราจะปรับตัวรื้อใหม่ทันไหม แล้วคู่แข่งอีก 10 เจ้าที่ก๊อบไอเดียเราไปทำแล้วทำได้สวยกว่าเด็ดกว่าคุณจะทำยังไง ถ้าเรายังตอบตัวเองกันว่ารู้สิ ขอให้ตอบแบบไม่หลอกตัวเองนะครับ
จริงๆแล้ว startup ต้องการอไจล์มากกว่า enterprise software เป็นไหนๆเพราะ startup ต้องเผชิญกับความไม่แน่นอนอย่างยิ่งยวดในทุกๆด้าน ด้วยทุนที่จำกัด ข่าวดีคือด้วยความที่ startup เราส่วนมากเป็นทีมเล็กๆที่ทำงานตาม common sense อยู่แล้ว ไม่ต้องมานั่งใส่หัวโขนไร้สาระให้เสียเวลาเหมือนการทำงานในบริษัทใหญ่ การทำ startup จึงมีความพร้อมที่จะเป็นอไจล์กว่า enterprise software มาก
แต่ทว่าเราต้องแยกให้ออกระหว่างมั่วแบบลูกทุ่งกับลองผิดลองถูกแบบมีวินัยนะครับ เราอยากสร้างตึกที่สวยแล้วอยู่ได้นานหรือว่าต่อเติมแล้วล่มครับ? โอยบางคนบอกว่าตอนนี้ผมต้องเร่งทำ MVP ให้เสร็จก่อน Scaling เป็นเรื่องที่ค่อยกังวลที่หลังอไจล์เอาไว้ก่อนก็ได้ ผมเห็นด้วยอย่างมากนะครับเรื่องกังวลเรื่อง Scaling ทีหลัง แต่ลองนึกภาพตามนะครับว่า จังหวะที่คุณรู้ตัวว่าจะต้องต่อเติมเพิ่มขยายตึกละ แต่ทว่ามันดันใช้เหล็กเส้นลดเสป๊กไปแล้ว คุณจะทำยังไงกับตึกของคุณในตอนนั้น?