สรุปบางส่วนจากงาน Code mania 1001

เมื่อวันเสาร์ที่ผ่านมาได้มีโอกาสไปงาน Code mania ซึ่งปีนี้จัดขึ้นที่ True Digital Park การเดินทางง่ายมากๆ แค่นั่ง BTS มาลงสถานีปุณณวิถีแล้วเดินต่ออีกนิดก็ถึงแล้ววว ก่อนอื่นอยากจะบอกว่า ทุก sessionในงานน่าสนใจมาก แต่มี Session ที่รู้สึกชอบมากเป็นพิเศษจนอยากจะแชร์ให้คนที่ไม่ได้ไปงานนี้ได้มาอ่านกันด้วย มาดูกันเลย~

“เรารอดมาได้ยังไงนะ”
By Pathompon Jirawanidchakorn

ครั้งแรกที่เห็นหัวข้อนี้ในตารางงานก็รู้สึกว่ามันดู survival ดีนะ อยากรู้ว่าเค้าผ่านมาอะไรมาถึงได้ตั้งชื่อแบบนี้ ก็เลยเป็นเหตุผลว่าทำไมถึงเลือกเข้าฟัง Session นี้ ซึ่งใน Session นี้ เค้าได้แชร์ประสบการณ์เกี่ยวกับการทำเว็บจองตั๋ว ซึ่งก็คือเว็บ Eventpop นั่นเอง โดยจะแบ่งเป็น 4 หัวข้อดังนี้

1. ความหลากหลายของลูกค้า
   เพราะ User มีตั้งแต่เด็กไปจนถึงผู้สูงอายุ วิธีการแก้ปัญหาในเรื่องนี้คือต้องทำ UX ให้ดีที่สุด เพื่อให้เกิดคำถามน้อยที่สุด
2. Traffic Spike
   ในช่วงที่เปิดขายบัตร BNK48 แล้ว Web ล่ม Auto scale ทำงานไม่ทัน จึงมีระบบ Queue เพื่อควบคุมให้คนเข้ามาตามคิวที่ได้รับ และมีระบบ Monitoring คอยแจ้งเตือนผ่านทาง Slack และ SMS
3. People Unhappy
   อาจจะไม่เกี่ยวกับ Eventpop โดยตรง คือในช่วงขายบัตร BNK แล้วมีคนที่กดบัตรไม่ได้ หรือคนที่กดบัตรได้แล้วเอาไปขายอัพราคา คนที่กดบัตรไม่ได้ก็ feedback มาที่ Eventpop ว่า ทำไมเปิดน้อยจัง ทำไมเต็มไว ทำไมมีบัตรผี บลาๆ ซึ่งข้อนี้ควรคุยกันในทีมและสื่อสารกับลูกค้าให้เข้าใจ
4. The Highest Traffic
   ในการเปิดขายบัตรรอบที่ 2 ทีม Eventpop ได้นำระบบ Pre-Queue มาใช้ สงสัยไหมว่า Pre-Queue คืออะไร ? Pre-Queue ก็คือระบบสุ่มคิวนั่นเอง ซึ่งหมายความว่าคนที่เน็ตช้าก็ยังจะมีสิทธิ์ได้ลุ้นเป็นคิวต้นๆเหมือนกันกับคนที่เน็ตเร็วขอแค่มาในช่วงเวลาที่กำหนด แล้วคนที่มาหลังจากช่วงเวลาที่เค้ากำหนดก็จะได้คิวปกติตามลำดับ เราในฐานะคนที่เคยจองตั๋วคอนมาหลายครั้ง เคยเจอระบบ Pre-Queueด้วย ตอนนั้นไม่เข้าใจเลยว่า จะสุ่มคิวทำไม รู้สึกไม่โอเคเท่าไหร่ รีบตื่นมาตอน 10 โมงดันได้คิวท้ายๆ คนที่มาช้ากว่าเราดันได้คิวต้นๆตอนนี้ก็ได้รู้เหตุผลจริงๆจากคนที่ทำจริงๆก็รู้สึกว่าเหตุผลก็พอเข้าใจได้ล่ะมั้งงง ฮ่าๆ และในช่วงระหว่างที่รอคิวเพื่อซื้อตั๋วเราจะเห็นรูปคนเดิน รูปคนเดินเนี้ยได้ feedback ที่ไม่ค่อยดีเท่าไหร่ แล้วก็มีคนในทีมเค้าเสนอให้ใช้รูปคนเต้นระหว่างรอคิวแทน ซึ่งพอเปลี่ยนแล้วก็ได้ feedback ที่ดีขึ้น อย่างน้อยตอนที่เค้ารอคิวก็มีอะไรตลกมาให้ดูเพลินๆ อันนี้เป็นเรื่องที่รู้สึกประทับใจดีนะเพราะเค้าสามารถพลิกวิกฤติให้เป็นโอกาสได้เพียงแค่เปลี่ยนนิดเดียวเอง อีกเรื่องที่รู้สึกชอบก็คือ ระบบ Fake Queue เพื่อกัน user ที่ inspect เว็บเพื่อพยายามที่จะลัดคิว โดยให้ Link ปลอมนั้น redirect ไปที่เพลง Never Gonna Give You Up ที่ Youtube https://www.youtube.com/watch?v=dQw4w9WgXcQ 😁

รูปคนเต้นระหว่างรอคิว

ในช่วง Q&A มีคนถามคำถามนึงซึ่งคำตอบน่าสนใจดี เพราะมันเป็นเรื่องเล็กๆที่เราคิดว่าไม่น่าจะมีอะไรแต่จริงๆก็มันมีนะ คือ มีช่วงที่เปิดขายบัตรที่เป็นบัตรฟรี ตอนช่วงที่กดเอาบัตร Wordingตรงปุ่มมันเขียนว่า ‘BUY TICKET’ แล้วคนก็งงว่าตกลงงานนี้ฟรีหรือป่าวนะ ทำไมต้อง Buy ด้วยไหนบอกฟรี แล้วก็โทรมาถามกันเยอะมาก เค้าเลยทำ A/B Testing โดยมี 2 wording คือ ‘BUY TICKET’ กับ ‘GET TICKET’ ปรากฏว่าพอเปลี่ยนเป็น ‘GET TICKET’ คนก็เข้าใจมากขึ้นไม่ได้มีคำถามเหมือน ‘BUY TICKET’ เลยรู้สึกว่าเรื่อง wording มันก็เป็นเรื่องที่สำคัญมากๆเรื่องนึงเลย
ปล. ที่เล่ามาทั้งหมดเนี้ย ทีม Eventpop มีคนทำ 4 คนเองนะ แทบไม่ได้นอนเลย สุดยอดมาก ด้วยจำนวนคนและเวลาที่จำกัดแล้วทำออกมาได้ขนาดนี้ ปรบมือเลย

“Lesson learned from year of building development team”
By Chakrit Likitkhajorn

จากหัวข้อนี้พี่เค้าได้รวบรวมประสบการณ์ทั้งหมดที่พี่เค้าเจอทั้งสิ่งที่ดีและไม่ดีมาแชร์ โดยเรียงลำดับจากสิ่งที่สำคัญมากสุดๆ ตามลำดับตามนี้เลย

1. Culture book works
   Culture book คือข้อกำหนดที่ตั้งเอาไว้เวลาที่ต้องมีการตัดสินใจ เราก็ใช้ Culture book นี้แหละมาตัดสินใจว่าเราจะเลือกทางไหน ยกตัวอย่างเช่น ถ้าเราได้รับมอบหมายงานมาภายในเวลาที่จำกัด เราต้องการงานที่มีคุณภาพ หรืองานที่ทำครบทุก Feature (Quality VS Professional) การตั้ง Culture ที่เหมาะสมจะทำให้ได้คนที่เหมาะสมกับทีมเราและคัดคนที่ไม่เหมาะสมออกไป ทั้งหมดที่กล่าวมานั้นสิ่งสำคัญก็คือ Culture ต้องมาจาก inner belief ของตัวเอง (ต้องซื่อสัตย์กับตัวเอง)
2. Create a safe space
   ความลังเลทำให้ทีมทำงานช้าลง ถ้าไม่มีความลังเลจะทำให้งานไปไวมากๆ เพราะฉะนั้นเราจึงต้องหาแนวทางกำจัดมัน ในทาง Technical มีแนวทางดังนี้
   - Automated test
   การมี test ทำให้ developer มั่นใจที่จะแก้ code มากขึ้น
   - Clear layouting and responsibility
   ควรสื่อสารให้ชัดเจนว่า code นี้ควรจะอยู่ส่วนไหน มีหน้าที่ทำอะไร
   - Practical domain separation
   แต่ละคนสามารถจบงานได้โดยไม่ต้องรอกัน
3. Priority over completeness
   ทำสิ่งสำคัญดีกว่าทำให้ครบ หลีกเลี่ยงการทำงานตาม Queue แต่ควรทำตาม Priority ซึ่งพี่เค้าเล่าว่า list ทุก feature มาแล้วใส่กล่องสุ่มๆเอา
4. Never give requirement without context
   อย่ารับ requirement โดยที่ไม่รู้ context ควรทำความเข้าใจ requirement ว่ามาจากไหน, ทำอะไร, persona เป็นยังไง เพราะถ้าเราไม่ clear ตั้งแต่แรกแล้วเกิดติดปัญหาอะไร มันอาจจะต้องผ่าน process มากมายกว่าที่จะได้คำตอบ ทำให้งานเกิดความล่าช้า ดังนั้นเราจึงควรเข้าใจปัญหา เข้าใจส่ิงที่เค้าต้องการตั้งแต่แรก จะทำให้ทำงานไวขึ้น
5. 10X developers has a say in requirement
   ถ้า user มี requirement มาแล้ว developer ฟังแล้วอาจจะมีส่วนเสริมหรือมีสิ่งที่คิดว่าแนวทางนี้ดีกว่าก็สามารถที่จะเสนอออกไปได้ ซึ่งถ้าสิ่งที่เราเสนอไปแล้วมัน work user เค้าจะ trust เรา พอต่อไป user มี requirement อะไรมา เราก็สามารถเสนอได้ และเค้าก็จะเชื่อถือเรามากขึ้น
6. Priority of improving technical team (เรียงตามลำดับจากความสำคัญมากกกสุดไปน้อยนะ)
   - Code review
   - Monitoring
   - Automated tests
   - Align coding pattern and Architecture
   - Technical knowledge and capability

น่าเสียดายมากๆที่เวลาหมดก่อน แต่ว่ายังมีเรื่องที่ไม่ได้พูดอีกหลายเรื่องเลย

จบแล้วสำหรับการแชร์ ถ้าใครมี comment อะไรเพิ่มเติม สามารถ comment เข้ามาได้เลยนะคะ ส่วนคนที่ไม่ได้ไปในปีนี้ก็ไม่ต้องรู้สึกเสียดายนะคะ เพราะแค่อ่านมาถึงตรงนี้ได้ก็เหมือนกับว่าได้ไปนั่งฟังแล้ว ฮ่าๆ สุดท้ายนี้อยากจะบอกว่าใครที่ยังไม่เคยไปงานแบบนี้ก็ควรลองไปสักครั้งนะคะ รับรองว่าได้อะไรติดไม้ติดมือกลับมาแน่ๆ