เลิกพังในงานแข่ง! ใช้ Agile จัดทัพ Hackathon ให้ส่งงานสำเร็จแม้เวลาจำกัด เคล็ดลับทีมชนะที่ทุกคนต้องรู้!
หลายคนเดินเข้าสู่สมรภูมิ Hackathon ด้วยไฟที่ลุกโชน หอบไอเดียระดับเปลี่ยนโลกไปเต็มกระเป๋า แต่พอผ่านไป 24 ชั่วโมง กลับพบว่าโค้ดพัง พรีเซนต์ไม่เสร็จ และทีมทะเลาะกันเอง... ปัญหาไม่ได้อยู่ที่ไอเดียไม่ดี หรือเขียนโค้ดไม่เก่ง แต่อยู่ที่ "การจัดการเวลาและทีม" ที่ผิดพลาดต่างหาก cหากคุณเคยหยิบจับแนวคิดจากคัมภีร์ The Agile Samurai มาใช้ในการทำโปรดักต์จริง คุณจะรู้ว่าหัวใจของมันคือ "การส่งมอบงานได้จริงและพร้อมรับความเปลี่ยนแปลง" ซึ่งนั่นแหละคืออาวุธที่ทรงพลังที่สุดในสนามรบ Hackathon!
เลิกแข่ง Hackathon เถอะ ถ้ายังทำแบบนี้ในงาน
ถ้าคุณและทีมยังมีพฤติกรรมเหล่านี้ เตรียมตัวเก็บกระเป๋ากลับบ้านมือเปล่าได้เลย:
- มุดหัวเขียนโค้ดโดยไม่คุยกับใคร: ปิดหูปิดตาเขียนโค้ดไป 48 ชั่วโมงเต็ม โดยไม่เดินไปขอ Feedback จาก Mentor หรือกรรมการเลย ถือว่า ลืมกฎ The Engaged Customer ไปสนิท พอถึงเวลาพรีเซนต์ สิ่งที่ทำมากลับไม่ตอบโจทย์ Business Model หรือหัวข้อของงานเลยแม้แต่น้อย
- ทำสโคปใหญ่เกินตัว: พยายามยัดทุกฟีเจอร์ลงไปราวกับมีเวลาพัฒนา 3 เดือน ลืมการทำ "The NOT List" หรือ สิ่งที่ไม่อยู่ในสโคป ทำให้สุดท้ายไม่ได้ Working Software ที่ทำงานได้จริงเลยสักชิ้น มีแต่ UI ที่กดอะไรไม่ได้
- แบ่งแยกชนชั้นในทีม: "ฉันเป็น Dev หน้าที่ฉันคือเขียนโค้ด แกเป็น Business ก็ไปทำสไลด์สิ" การทำงานแบบโยนงานข้ามกำแพงในเวลาที่จำกัดคือหายนะ หากสไลด์พัง โค้ดดีแค่ไหนก็แพ้
Scrum Team กับ Agile ไม่ได้เหมือนกัน (อย่าสับสน!)
หลายคนพยายามเอาพิธีกรรมของ Scrum มาใช้ในงาน Hackathon ซึ่งเป็นเรื่องที่ผิดฝาผิดตัวมาก!
- Scrum คือ Framework หรือกรอบการทำงานที่มีกฎเกณฑ์ มีรอบ Sprint มีการทำ Daily Standup Meeting ซึ่งมันเหมาะกับการรันโปรเจกต์ระยะยาว
- Agile คือ Mindset ที่เน้นความยืดหยุ่น การตอบสนองต่อความเปลี่ยนแปลง และการส่งมอบสิ่งที่มีคุณค่า
ในงานแข่งที่มีเวลาแค่ข้ามคืน ไม่จำเป็นต้องมี Scrum Master หรือบอร์ดตั้ง Task ที่ยุ่งยาก สิ่งที่คุณต้องการคือ Agile Mindset ล้วนๆ กล้าที่จะหั่นฟีเจอร์ที่ไม่จำเป็นทิ้งกลางทาง และโฟกัสไปที่ชิ้นส่วนที่สร้าง Impact สูงสุดให้ทันเวลา
Agile ไม่จำเป็นต้องใหญ่ ในระดับ "ชั่วโมง" หรือ "วัน" ก็ทำได้!!!
วิถีซามูไรไม่ได้จำกัดอยู่แค่ในโปรเจกต์ระยะยาว ในสนาม Hackathon เราสามารถบีบอัด Agile ให้เล็กลงมาในระดับชั่วโมงได้:
- Micro-Iterations (รอบการทำงานระดับชั่วโมง): แทนที่จะตั้งเป้าว่า "พรุ่งนี้เช้าแอปต้องเสร็จ" ให้ซอยเป้าหมายเป็น "ภายใน 2 ชั่วโมงนี้ ระบบ Login หน้าแรกต้องใช้งานได้จริง"
- Fast Feedback Loop: ทุก ๆ 2-3 ชั่วโมง ทีมต้องเงยหน้าจากหน้าจอมาคุยกันสั้น ๆ ว่า พร้อมให้แต่ละคนเล่าสั้น ๆ ว่า "เราทำอะไรเสร็จแล้ว?", "เราจะทำอะไรต่อ?", "เรากำลังติดปัญหาอะไร?" คนละ 1-2 นาที ถ้าเริ่มหลงทาง ต้อง Embrace Change กล้าที่จะรื้อแผนและหาทางออกใหม่ทันที
- Quality is Built-in (แม้จะรีบก็ตาม): แม้จะเป็นโค้ดเผา แต่โครงสร้างต้องไม่เละจนต่อยอดตอนใกล้จบไม่ได้ การจัดระเบียบความคิดและโฟกัสแค่แก่นสำคัญของระบบ จะทำให้คุณมี Working Software ไปโชว์กรรมการได้เสมอ
ทำงานแบบ "ทีม" ไม่ใช่แค่ทำงานแบบ "กลุ่ม"
สิ่งสำคัญที่แยกระหว่างผู้ชนะกับทีมที่ทำโปรเจกต์ไม่เสร็จ คือรูปแบบการประสานงาน:
- ทำงานแบบกลุ่ม: คือการแบ่งงานกันไปทำแบบแยกส่วน "เธอไปทำดีไซน์นะ เดี๋ยวฉันทำหลังบ้าน ส่วนนายไปคิดแผนธุรกิจ" แล้วต่างคนต่างแยกย้ายไปทำ หวังว่าจะเอาผลงานมา "ประกอบร่าง" กันได้ในชั่วโมงสุดท้าย... ซึ่งผลลัพธ์มักจบลงด้วยหายนะ API เชื่อมกันไม่ได้ หน้าตาแอปไปคนละทิศทาง หรือฟีเจอร์ไม่ตรงกับสไลด์นำเสนอ
- ทำงานแบบทีม: คือวิถีของ Agile Team อย่างแท้จริง มีการแชร์บริบทร่วมกันตลอดเวลา หากคนหนึ่งติดปัญหา อีกคนต้องพร้อมกระโดดเข้าไปช่วย ไม่ใช่ปล่อยให้เพื่อนจมน้ำตายอยู่คนเดียวเพราะคิดว่า "ไม่ใช่หน้าที่" การทำงานแบบทีมคือการยึดเป้าหมายสูงสุดร่วมกัน ชนะก็ชนะด้วยกัน พังก็พังด้วยกัน!
แข่ง Hackathon ต้องจัดการทีมแบบนี้ (The Cross-Functional Strike Force)
ทีมที่จะชนะในงาน Hackathon ไม่ใช่ทีมที่มี Dev เก่งที่สุด 5 คน แต่คือ หน่วยรบพิเศษ ที่ผสานทักษะกันได้อย่างลงตัว:
- ไม่มีกำแพงหน้าที่: ทุกคนต้องพร้อมลุยไปด้วยกัน ถ้าช่วงแรกฝั่ง Dev ยังไม่ต้องขึ้นโครง ฝั่ง Tech ต้องลงมาช่วย Business ตบไอเดียและ Flow ให้เคลียร์ และในขอบโค้งสุดท้าย ถ้าโค้ดมีบั๊ก ฝั่ง Business/Design ก็ต้องพร้อมมาช่วย QA กดเทสต์ระบบเพื่อหาจุดบอด
- มองเห็นเป้าหมายเดียวกัน (Align the team): ใช้เวลา 15 นาทีแรกของงาน ทำ Agile Inception Deck ฉบับย่อ ตอบให้ได้ว่า "เรามาแข่งทำไม?", "อะไรคือจุดขายของเรา?", และ "ความเสี่ยงอะไรที่จะทำให้เราพรีเซนต์ไม่ทัน?"
- รับผิดชอบร่วมกัน: ไม่มีการหาคนผิดเมื่อโค้ดพังตอนตี 3 มีแต่การระดมสมองเพื่อหา Workaround ที่เร็วที่สุดให้ระบบกลับมาทำงานได้ทันตอนเช้า
การเอาชนะในงาน Hackathon ไม่ใช่แค่การอดนอนเขียนโค้ดมาราธอน แต่คือการบริหารเวลาอันมีค่า การผสานพลังแบบ "ทีมเวิร์ก" ที่แท้จริง และดึงศักยภาพของทุกคนออกมาให้ได้มากที่สุด การหยิบเอาแนวคิดการโฟกัสไปที่ Working Software และความกล้าที่จะเปลี่ยนแผนแบบ Agile มาใช้ จะช่วยให้คุณสามารถนำพาทีมรอดพ้นจากสมรภูมินี้ และก้าวไปคว้ารางวัลได้อย่างสง่างาม!