ถอด 10 บทเรียนจาก Game Development Production
สวัสดีค่ะ กลับมาพบกับไมล์อีกครั้งนะคะ blog นี้ก็เป็น blog ที่สามแล้วกับบทความเกี่ยวกับ Game Development ส่วนตัวไมล์เองก็ทำงานด้านนี้มาประมาณ 7-8 ปีแล้ว ทั้งไทยและต่างประเทศ ซึ่งในการทำงานเหล่านั้น ก็ทำให้เราได้เจออะไรเยอะเหมือนกัน วันนี้เราเลยอยากจะมาคุยกันเรื่อง บทเรียนที่ได้จากการทำงานพัฒนาเกมกันนะคะ
10 Lessons Learned from Game Development Production
ย้อนไปช่วงสองสามปีที่แล้ว ไมล์ได้ถูกส่งไปดูแลและจัดการโปรเจคที่เป็นหน้าเป็นตาของออฟฟิศที่อยู่ในตอนนั้น และได้ผ่านช่วง Launch มา ในระหว่างช่วงเวลาว่างสั้นๆ ก่อนทีมจะพัฒนาเกมกันต่อ ทางหัวหน้าไมล์ในตอนนั้นก็ได้ส่งบทความหนึ่งมาให้อ่าน แม้ว่าจะเป็นบทความที่ค่อนข้างเก่า แต่หลังจากได้อ่านก็รู้สึกประทับใจมาก และหยิบมาอ่านอยู่เรื่อยๆ
บทความที่หัวหน้าส่งมาคือ A Producer’s 10 Lessons Learned the Hard Way ที่คุณ David Manuel (อดีต Senior Producer ของ Ubisoft Blue Byte) เป็นผู้เขียน
ซึ่งบทความที่กล่าวถึงนี้ เราจะนำมาอ้างอิงใน blog พร้อมกับยกตัวอย่าง ที่ตัวเองรวมถึงคนรอบตัวเจอในช่วงการทำงานที่ผ่านมา ให้เห็นภาพง่ายขึ้นนะคะ
1. Implement Previous Recommendations
นำบทเรียนที่ได้จากครั้งที่แล้วมาใช้
ในหลายๆครั้ง เรามักจะเจอคนที่ผิดซ้ำผิดซาก ในจุดเดิม หรือในจุดใหม่ ด้วยข้อบกพร่องแบบเดิมๆ ไม่ว่าจะเป็นงานในระดับมหาวิทยาลัย หรืองานในระดับบริษัท พอปล่อยไว้ ก็เกิดการผิดพลาดแบบเดิมๆ ในงานถัดไป ทำให้เราต้องเสียเวลามาแก้ไขจุดผิดเดิมๆอีก
สำหรับวิธีการป้องกันเอาจริงๆ มันได้มีการคิดขึ้นมานานแล้ว นั่นคือ การทำ Lessons learned (การถอดบทเรียน) Lessons learned จะมีบันทึกปัญหา เหตุการณ์ต่างๆ ไม่เพียงแค่ปัญหาภายในทีมเท่านั้น แต่อาจรวมถึง bug ของ software ที่ก่อให้เกิด issue ในการพัฒนาเกมอีกด้วย
Lessons learned นี่จะเก็บข้อมูลต่อเนื่องตั้งแต่ต้นโปรเจค จนถึงจบรวมถึงการประชุม Post-mortem โดยคนรับผิดชอบจะเป็น Project Manager และจะถูกนำไปใช้ เป็นพื้นฐานในการทำโปรเจคถัดไป
สำหรับคนที่ใช้ Scrum ในการทำงานซึ่ง Game Developer หลายที่ในไทยใช้ รวมถึงไมล์เองด้วย ด้วยวิธีการทำงานแบบ Scrum นี้ เราก็จะมี Retrospective ในแต่ละรอบการทำงาน (Sprint)ซึ่งจะพูดคุยกันถึงสิ่งที่เราทำได้ดี สิ่งที่เราจะสามารถปรับปรุงได้ และเราจะปรับปรุงอะไรในรอบ Sprint หน้า
Scrum framework
แต่ต่อให้มีการบันทึกข้อผิดพลาด ไม่ว่าจะเป็น Lessons learned หรือ Retrospective report ก็ตาม หากไม่ได้มีการทำตาม ปัญหาแบบเดิมๆก็ยังสามารถเกิดขึ้นได้ เพราะฉะนั้น ในฐานะ Game Producer, Lead หรือจะ Project Manager ควรช่วยกันทำให้ทีมทำตามที่เราคุยตกลงกันไว้ให้ได้ เพื่อป้องกันปัญหา และปรับปรุงให้ดีขึ้น
2. Start Early and Start Small
เริ่มให้เร็วและเริ่มทีละเล็ก
อย่างที่บอกไปในบทความ Game Monetization ว่า การทำเกมก็คือการทำธุรกิจอย่างหนึ่ง และความเสี่ยงนั้นเป็นเรื่องที่ต้องพิจารณาในการทำธุรกิจทุกประเภท ซึ่งการทำงานหรือทำอะไรใหญ่ๆในครั้งเดียว จัดเป็นความเสี่ยงแบบหนึ่ง
ซึ่งส่วนตัวไมล์ ก็ได้ยินมาหลายครั้ง กับการที่ Investor มั่นใจกับไอเดียเกมมาก จนเริ่ม production แบบเต็มรูปแบบในครั้งเดียว และสุดท้ายกลายเป็นว่า เกมไม่ได้สนุกอย่างที่คิด ในบางเคส เกมก็ไม่ได้ Launch ออกไป หรืออีกเคส คือ Launch ออกไป แต่ไม่สามารถทำรายได้ได้ จนขาดทุน และปิดตัวลง
ทางคุณ David ได้ให้คำแนะนำว่า ให้เริ่มต้นทำเกมด้วยทีมขนาดเล็กที่จะเป็น Core team ก่อน หรือที่ไมล์และน้องในทีมชอบเรียกกันเล่นๆว่า เสาหลัก
ตัวอย่างโครงสร้างทีมเกมของบริษัทเกมแห่งหนึ่ง
โดยส่วนใหญ่ Core team ประกอบไปด้วย Lead Game Designer เพื่อกำหนดแนวทางหลักของเกม, Game Producer เพื่อกำหนด scope, budget รวมถึง timeline และ สุดท้าย Lead ของส่วนงานต่างๆ เพื่อให้เข้าใจและสื่อสาร กับ staff ส่วนอื่นๆ เมื่อเริ่มทำเกมแบบเต็มรูปแบบ
เนื่องจาก Lead Game Designer และ Game Producer มักจะเป็นเสาหลักคนแรกๆ ที่จะถูกย้ายไปเมื่อเริ่มโปรเจคใหม่ และทั้งสองตำแหน่งนี้งานค่อนข้างเยอะ และในหลายๆครั้งไม่ได้ดูแลแค่โปรเจคเดียว ทางคุณ David Manuel จึงแนะนำให้เป็นแบบไม่ประจำไปก่อน แต่ทั้งสองคนต้องคอยมาตอบคำถามและดูแลอยู่เสมอ
นอกจากทีมที่มีขนาดเล็กแล้ว เรายังสามารถเริ่มทำเกมทีละเล็กๆ มาทดสอบ idea ของเกมได้อีกด้วย โดยการทำ Prototyping ซึ่งทำให้เราสามารถมั่นใจในส่วนที่ได้รับการทดสอบก่อนนำไปพัฒนาต่อได้
3.Put Your Key People in From the Start
การใส่เสาหลักไปใส่ตั้งแต่เริ่มโปรเจค
การเริ่มต้นโปรเจคนั้นสำคัญ จึงทำให้คนที่เริ่มต้นมีความสำคัญตามไปด้วย ซึ่งหากคนเริ่มต้นไม่ได้มีความสามารถเพียงพอ สุดท้ายงานที่ทำไปอาจจะต้องเริ่มใหม่ (Redo) และให้คนใหม่เข้ามาทำแทน ซึ่งทำให้เสีย cost ในการทำไป ซึ่งในกรณีนี้ ไมล์ มีตัวอย่างความพังพินาศระดับ World class ให้เข้าใจง่ายๆคือ Final Fantasy XIV 1.0
แต่ถ้าเราเห็นว่า คนที่เราวางตัวไว้ มีความสามารถเพียงพอที่จะทำ แต่มีแค่บางอย่างที่ขาดไป เราสามารถส่งเค้าไป train หรือ research เพิ่มเติม เพื่อชดเชยส่วนที่ขาดหายไปได้ และป้องกันไม่ให้เกิดผลเสียในระยะยาว
4. Establish a Relationship with Your Clients
สร้างความสัมพันธ์กับคุณลูกค้า ❤️
การที่มีสัมพันธ์ที่ไม่ดีกับลูกค้า สร้างความวายป่วงให้แก่ทีมงานมาแล้วนักต่อนัก ไม่ว่าจะเป็น การที่ Publisher กำหนด Milestone มาไม่ว่าจะเป็น Alpha, Beta, และ Master ไม่สอดคล้องกับแผนที่เป็นไปได้ของทางทีม Developer และเลือกที่จะไม่ฟังเพราะมีความสัมพันธ์ที่ไม่ดี ทำให้ Developer ต้อง crunch หรือทำงานกันข้ามวันข้ามคืน
การจะสร้างความสัมพันธ์ที่ดีได้ การสื่อสาร (Communication) ที่ดีจึงเป็นสิ่งจำเป็น นั่งรวมถึงการมี Communication plan ที่เหมาะสมอีกด้วย โดยตัว Communication plan จำเป็นตัวบอกความถี่ และวิธีการ รวมถึงคนดูแลการสื่อสารอีกด้วย
ตัวอย่าง Communication Plan
ทางคุณ David แนะนำ ให้ใช้การประชุมแบบ Face-to-face หรือต่อหน้า ทำให้เข้าใจลูกค้ามากขึ้น เพราะได้ เห็นสีหน้า ท่าทาง อารมณ์ ทำให้การสร้างความสัมพันธ์รวมถึงการติดต่อสื่อสารครั้งถัดไป ถึงจะเป็นแค่อีเมลล์ก็จะง่ายขึ้น แต่สำหรับตอนนี้ขณะที่ COVID-19 ยังแพร่ระบาด ไมล์แนะนำเป็น VDO conference meeting ไปก่อนนะคะ
Fun fact: Project Management Institute กล่าวว่า 90% ของ Project Management คือ การสื่อสาร (Communication)
5. Clarify Everyone's Role
แจกแจงตำแหน่งแต่ละคน
การที่เรารู้ตำแหน่งของแต่ละคน ความสามารถ และความเข้ากับทีม ต่อคนในทีมกันเองหรือ กับ Lead เป็นเรื่องที่สำคัญมาก เพราะเมื่อเกิดการต้องย้ายโปรเจคเราจะสามารถปรึกษากันภายในทีมได้ว่า ใครจะเป็นคนย้ายไป แล้วสกิลเค้าเหมาะสมหรือไม่ จะมีใครในทีมที่สามารถรับงานช่วงต่อหลังจากที่เค้าย้ายไปแล้ว
ตำแหน่งต่างๆ ในการพัฒนาเกม
นอกจากนั้นคุณ David แนะนำให้ทำ รีวิวแบบ 360 degree ซึ่งเป็นการรีวิวจากผู้เกี่ยวข้อง เช่น หัวหน้า เพื่อนร่วมงาน หรือลูกน้อง เป็นต้น จะทำให้เห็นภาพในเรื่องความสามารถ และความเข้ากับทีม ของแต่ละคนได้ชัดเจนขึ้น
ในระดับ Business หรือ Lead การที่เรารู้เรื่องตำแหน่ง และความรับผิดชอบ จะทำให้การติดต่อสื่อสารง่ายขึ้น รวมถึงทำให้เข้าใจลำดับการทำงานได้ชัดเจนอีกด้วย
อย่างเช่น มีการตกลงทำแคมเปญ UA สำหรับเกมๆหนึ่งที่ประเทศ New Zealand ทาง Publisher ก็จะเข้าใจว่า ต้องติดต่อ Producer และ Game Designer ของโปรเจคนั้น เพื่อ ตกลงหากลุ่มลูกค้าเป้าหมายที่จะทำ UA เมื่อถึงเวลาที่จะทำ ก็จะต้องประสานงานกับ Analyst เตรียมการวิเคราะห์ข้อมูลในช่วงที่ทำ เป็นต้น
6.Create and Maintain a Long-Term Plan
จงวางแผนและคอยดูแลแผนระยะยาว
ตอนเริ่มโปรเจค เป็นปกติที่เราจะสับสนกันบ้าง แต่ถ้าเรามีการวางแผนระยะยาว (Long-term plan)ไว้ตั้งแต่เริ่ม ในระดับ High-level ที่เป็นแค่ภาพรวม และวันสำคัญๆหลักๆ เช่น วันที่เริ่มโปรเจคแบบเป็นทางการ วันที่สิ้นสุดช่วง Pre-production หรือวันส่งงาน จะทำให้ผู้เกี่ยวข้องทั้งหมดเห็นภาพรวมตรงกัน
และเมื่อเราสามารถกำหนด Long-term plan แปลว่า เรามี Brief คร่าวๆของเกม รวมถึง Budget และ เวลาแล้ว ทำให้เราสามารถ estimate สิ่งอื่นๆได้อีก ไม่ว่าจะเป็น จำนวนคนที่ต้องใช้ หรือ งบประมาณที่เราต้องใช้จ่ายในแต่ละเดือน
ตัวอย่าง Product Roadmap ซึ่งเป็น Long-term plan ชนิดหนึ่ง
คุณ David Manuel ได้เขียนไว้อย่างชัดเจนเลยว่า การทำ long-term plan ไม่ได้ทำเพื่อพรีเซนให้คนที่เกี่ยวข้องดู แล้วมาดูอีกทีตอนที่โปรเจคเหมือนจะไม่เป็นไปตามแพลนเท่านั้น แต่ต้องมีการปรับปรุงและคอยดูแล เมื่อมีการเปลี่ยนแปลงไปด้วย ระหว่างการพัฒนา โดยอาจจะอัพเดทแผนคู่ขนานไปกับ ตอนทำ Sprint planning เลยก็ได้
นอกจากนั้นตัว long-term plan ทำให้เห็นถึงความต่อเนื่องของฟีเจอร์ ที่มีความเกี่ยวพันกัน ซึ่งหากมองแค่เป็นราย Milestone อาจจะทำให้ขาดหายไปได้
7.Agree on Milestone Definitions
ตกลงกันถึงสิ่งที่จะส่งในแต่ละ Milestone
เชื่อว่าหลายคนอาจจะมีปัญหากับการส่งงานกันบ้างแหละ เช่น เราออกแบบโลโก้และส่งให้ลูกค้าตรวจ Shape ลูกค้าดันไปตรวจสีซะอย่างนั้น
การพัฒนาเกมก็ไม่ได้แตกต่างกัน เราควรคุยให้ชัดกับทุกคนที่เกี่ยวข้อง ว่า "แต่ละ Milestone จะมี Deliverables อะไรบ้าง" คือ การกำหนดส่งอะไรบ้าง และเป็นในลักษณะไหน ตัวอย่างเช่น เอกสาร, Prototype หรือ Vertical slice เป็นต้น
Deliverable Format ต่างๆ
ในเมื่อเราไม่มีทางรู้ว่า หน้าตาเกมทั้งหมดจะเป็นอย่างไรเพราะ Design ยังไม่ได้เสร็จทั้งหมด เราจึงต้องใช้ข้อมูลในส่วนของ Budget, เวลา และ ไอเดียคร่าวๆ ที่มีเพื่อประเมินแล้วระบุ ของที่จะส่งแบบ High-level แทน
มีอีกเหตุการณ์ยอดนิยม ในสาย Startup คือ การทำ Demo ไปเรื่อยๆ โดยไม่มีกำหนดส่งและยิ่งเมื่อเรานำไปเสนอกับ Investor และได้ Feedback จาก Investor มา แล้วต้องแก้ตามเพื่อเอาใจ Investor จนกินเวลาที่เราควรจะเข้าสู่ Production จริง เหตุการณ์นี้เรียกกันว่า “Demo Hell”
เพราะฉะนั้นการวางแผนตกลงให้เคลียร์ว่าในแต่ละ Milestone ที่จะส่งอะไรบ้าง ไว้เป็นทิศทางสำหรับทีมจึงสำคัญมาก
8.Encourage Collaboration and Alternative Ideas
สนับสนุนให้เกิดความร่วมมือ
"บอกแล้ว ว่าจะเป็นแบบนี้" เป็นอีกหนึ่งประโยคที่เกิดขึ้นหลังจากพัฒนาไปพักหนึ่งแล้วเจอปัญหา ในหลายๆที่ ที่ Product Owner/ Game Designer/ Investor เลือกที่จะไม่ฟังทีมพัฒนา และสั่งลงมาโดยตรง
การประชุมโดยมีผู้เกี่ยวข้องทุกคนเข้าร่วม จะช่วยแก้เหตุการณ์แบบข้างบนได้ โดยเฉพาะอย่างยิ่งเมื่อมีไอเดียใหม่ๆ ซึ่งทางทีม Developer จะสามารถบอกได้ถึงข้อจำกัดทั้งทางเทคนิคและการออกแบบ เพื่อตัดไอเดียที่เป็นไปไม่ได้หรือไม่ตรงตามความต้องการออก และเสนอความเป็นไปได้อื่นๆ ที่อาจจะทำให้ไปถึงตัว Objective ที่วางไว้เช่นกัน แต่คนที่จะกรองไอเดียเหล่านี้ เพื่อนำไปใช้ต่อคือ Lead Game Designer ผู้รับผิดชอบ Direction ของเกมโดยตรงอยู่ดี
ตัวอย่างการประชุม Brainstorming เพื่อหา ไอเดีย
ส่วนใหญ่ Investor หรือ Publisher ไม่เลือกที่จะลงมาประชุมระดับนี้ แต่ทางคุณ David ยังสนับสนุนให้เค้าเข้ามาร่วมประชุมด้วย ในประชุมครั้งที่สำคัญๆ เพื่อ ให้เค้ารับรู้ หรือร่วมตัดสินใจด้วย แต่ถ้าประชุมเลือกไอเดีย ก็แนะนำเป็นช่วงที่เหลือ 2–3 ไอเดีย ดีกว่าเหลือเพียงแบบเดียว เผื่อเค้าต้องการเปลี่ยนแปลงในภายหลัง ก็จะยังอยู่ในสโคปที่ทาง Investor หรือ Publisher ตัดสินใจร่วมเลือกไว้แล้ว จะได้ไม่ต้องแก้มากเท่ากับการเปลี่ยนไอเดียไปเลย
9.Appreciate and Keep To Deadlines
เห็นคุณค่าและทำตามกำหนด Deadline
การทำตามกำหนด Deadline ก็เหมือนกับการนั่งสอบ สมมติว่า มีเวลาสอบชั่วโมงนึง กับโจทย์ หกข้อ เราคงไม่เสียเวลาติดอยู่กับข้อแรกไปซักครึ่งชั่วโมงหรอกนะ
ถ้าในการพัฒนาเกม ก็เหมือนกับการทำ Pre-production ไปซักครึ่งนึงของแพลนที่วาง ซึ่งแน่นอน ผลคือ การที่ทีมที่เหลือต้องไปเร่งตอนท้ายให้ตาม Deadline ซึ่งก็มีโอกาสทั้งทำทัน หรือไม่ทันทำให้ต้อง Delay ออกไป
ซึ่งหากเกิดการ Delay อย่างต่อเนื่องในระหว่างการพัฒนายังจะทำให้ morale ของทีมตกลงและ Quality ของงานแย่ลง ผลสุดท้ายอาจจะทำให้คนทะยอยลาออกไปก็เป็นได้
การเคารพ Deadline จึงเป็นสิ่งสำคัญมากที่ทุกคนในทีมต้องเข้าใจ ไม่ใช่แค่เพียงเพื่อลูกค้าเท่านั้น แต่รวมถึงเพื่อนร่วมทีม และคนที่เกี่ยวข้องคนอื่นอีกด้วย
ตัวอย่าง Jira Dashboard ที่แสดงวันที่เหลือใน Sprint
ในบางครั้ง Producer/Project Manager จึงต้องกดดันบ้าง เพื่อให้ผลงานออกมาตรงตามเวลา แต่ Producer/ Project Manager ก็ต้องวางแผนให้ดีขึ้นควบคู่กับการกดดันไปด้วย ส่วนตัวทางคุณ David ยังแนะนำถึงวิธีที่เค้าใช้ที่ทำให้ทุกคนตระหนักถึง Deadline คือ แปะบนผนังชัดๆไปเลย พร้อมกับเอาใส่ wiki ของทีมด้วย
10. Be Decisive
ตัดสินใจซะ!
การตัดสินใจ เป็นอีก 1 หัวข้อที่เราพบกันได้เสมอเลยว่า มันกระทบกับ schedule ที่เราวางไว้ แม้ว่าจะเป็นการตัดสินใจตั้งแต่ตอนเริ่มโปรเจคก็ตาม เพราะถ้าเราไม่ตัดสินใจ เวลาก็ยังจะเดินไปเรื่อยๆ ซึ่งก็นับเป็น man hours จนเกิดเงินที่สูญเสียไปกับการรอ และโปรเจคยังต้องเดินหน้าต่อไปอีกด้วย เพราะฉะนั้น การตัดสินใจเรื่องหลักๆ ควรเกิดขึ้นในอย่างเร็ว แบบมีเหตุผล ในช่วงเวลาที่เหมาะสม
บางทีการชะลอการตัดสินใจโดยไม่มีเหตุผล ก็ไม่ได้ดี เพราะอาจจะทำให้การตัดสินใจแย่ลงกว่าเดิมอีกก็ได้ หรือแย่สุด อาจจะถูกลืมไปเลยด้วยซ้ำ แต่การเร่งการตัดสินใจก็ไม่ดีเช่นกัน จนทำให้ไม่มีเวลา วิเคราะห์หาข้อดีข้อเสีย หรือ ทางเลือกอื่นๆที่เป็นไปได้ เพราะฉะนั้นอย่างที่กล่าวไปข้างต้น ว่าควรเกิดขึ้นในเวลาเหมาะสมและมีเหตุผล
นอกจากไม่ตัดสินใจหรือตัดสินใจกระทันหัน มีอีกอย่างหนึ่งที่เป็นปัญหาเหมือนกัน คือ การเปลี่ยนใจ เพราะทำให้ morale ของทีมต่ำลง และยังเสียเวลาที่ได้ใช้ในการ develop จากการตัดสินใจไปแล้ว มันเป็นเรื่องปกติต้องมีการเปลี่ยนแปลงปรับปรุงกันเพื่อให้ดีขึ้น แต่ถ้าเกิดการเปลี่ยนใจอย่างต่อเนื่อง ก็ทำให้ Productive ลดลงได้ แทนที่จะเพิ่มขึ้น
สุดท้ายนี้ที่เขียนไปมันอาจจะดู ideal มากๆ แต่การที่เราเริ่มโปรเจคใหม่โดยมีข้อเตือนใจเหล่านี้ย่อมเป็นพื้นฐานที่ทำให้เราพัฒนาได้ดีขึ้นกว่าการที่ไม่รู้อะไรมาก่อนเลยแน่นอน แต่การที่เราจะใช้ 10 ข้อนี้นั้นควรเปลี่ยนไปตามสภาพการณ์ รวมถึงการทำงานของแต่ละทีมด้วย
สำหรับวันนี้จบแล้วค่ะ เนื้อหาอาจจะตึงๆไปหน่อยเมื่อเทียบกับสองบทความที่ผ่านมา คราวหน้าจะพยายามเบาลงนะคะ หากมีคอมเม้นท์หรือเสนอแนะอะไร คุยกันได้ตลอดเลยนะคะ ♥ ขอบคุณที่ติดตามอ่านกันนะคะ
- 25
ดูเพิ่มเติมในซีรีส์
โฆษณา
- ดาวน์โหลดแอปพลิเคชัน
- © 2024 Blockdit
