ฉันเริ่มเป็นโปรแกรมเมอร์ในวิทยาลัยปีที่สอง เป็นเลิศในหลักสูตรการเขียนโปรแกรมทั้งหมดของฉัน และพัฒนาความคิดของโปรแกรมเมอร์สำหรับการแก้ปัญหา ตอนนี้ สามปีต่อมา ในฐานะผู้ผลิตวิดีโอเกม ความคิดของโปรแกรมเมอร์ที่ฉันภูมิใจมากได้นำพาอุปสรรคมากมายมาสู่เป้าหมายสำคัญ PoCT (Proof of Concept Technology) ครั้งแรกของฉัน เป็นที่ชัดเจนว่าการเปลี่ยนแปลงความคิดเป็นสิ่งที่จำเป็น

นี่คือสิ่งที่ฉันระบุว่าเป็นความแตกต่างหลักระหว่างความคิดของโปรแกรมเมอร์และโปรดิวเซอร์:

1. โปรแกรมเมอร์ต้องให้ความสำคัญกับงานแต่ละอย่าง ในขณะที่โปรดิวเซอร์ต้องมีความหลากหลายมากขึ้นและพร้อมใช้งานสำหรับทีมของพวกเขา
2. โปรแกรมเมอร์ได้รับคำติชมในทันทีและคำตอบที่ถูกหรือผิดที่ชัดเจน ในขณะที่โปรดิวเซอร์มักจะขาดการตอบกลับทันทีและเผชิญกับสถานการณ์ที่คลุมเครือมากกว่า

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

อ้างอิงคำพูดจากโปรแกรมเมอร์คนหนึ่งในทีมของฉัน:
ในขณะที่ทำงานกับโค้ดของฉัน ปกติฉันจะใส่หูฟังตัดเสียงรบกวนและอยู่ในสมองของฉัน ฉันไม่ได้ฟังเพลง ฉันแค่ต้องการสภาพแวดล้อมที่เงียบเพื่อมุ่งเน้นไปที่รหัสของฉัน

อย่างไรก็ตาม หากโปรดิวเซอร์ใส่หูฟังตัดเสียงรบกวนในขณะที่นั่งอยู่กับทีมของเขา/เธอ นั่นถือเป็นโปรดิวเซอร์ที่ไม่ดี

ผู้ผลิตจำเป็นต้องเห็นทุกที่และได้ยินทุกที่

เป็นหน้าที่ของผู้ผลิตในการติดตามความคืบหน้าของทุกคนในทีม ตรวจสอบให้แน่ใจว่าไม่ได้กำหนดขอบเขตมากเกินไป และประสานงานกับผู้ผลิตของทีมอื่นหากจำเป็นต้องมีการทำงานร่วมกันข้ามทีม

ในฐานะโปรดิวเซอร์ SD ในระหว่าง PoCT ของฉัน ทุก ๆ สิบถึงยี่สิบนาทีหลังจากนั่งบนเก้าอี้ มีคนในทีมเรียกฉันหรือโปรดิวเซอร์การออกแบบเลเวล นักออกแบบเกม โปรดิวเซอร์หลัก ฯลฯ

เมื่อใดก็ตามที่ฉันพยายามจดจ่อกับงานใดงานหนึ่งมากขึ้น มีคนโทรหาฉัน ในระหว่าง PoCT โชคดีที่ฉันพอใจกับใครก็ตามที่พูดคุยกับฉัน ไม่ว่าพวกเขาจะต้องการคำชี้แจงในปฏิทินหรือความช่วยเหลือจากผู้เชี่ยวชาญในทีมของเรา ฯลฯ น่าเสียดายที่ฉันต้องทำงานพิเศษเพิ่มเวลาให้กับงานของตัวเองหลังจากเวลางานปกติของเรา

ผู้ผลิตจำเป็นต้องจับตาดูทีมและรับฟังความต้องการที่แตกต่างกันทั้งหมด แต่ก็ไม่ได้หมายความว่าผู้ผลิตไม่จำเป็นต้องทำอะไรเพื่อตัวเอง พวกเขาต้องรักษางานค้างของผลิตภัณฑ์ นับชั่วโมงโดยประมาณ ตรวจสอบการส่งมอบตามเป้าหมายอย่างต่อเนื่อง ฯลฯ เป็นเรื่องที่ทนไม่ได้ที่ผู้ผลิตซึ่งเก่งที่สุดในทีมในแง่ของการจัดการเวลา จะล้มเหลวในการจัดการเวลาของตนเอง ต้องมีการปรับเปลี่ยนและต้องดำเนินการ ต่อไปนี้คือข้อเสนอบางประการที่ผู้ผลิตทุกคนสามารถพิจารณาได้:

• พยายามสร้างรายการที่ต้องทำสำหรับทุกวันทำงานพร้อมชั่วโมงโดยประมาณ และทำตามรายการอย่างระมัดระวังเพื่อหลีกเลี่ยงการกระทืบ
• กำหนดกรอบเวลาสำหรับการสนทนาแต่ละครั้งและปฏิบัติตามกรอบเวลานั้นอย่างเคร่งครัด (สิบนาทีอาจดี)

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

นอกจากนี้ยังง่ายสำหรับโปรแกรมเมอร์ที่จะบอกได้ว่าถูกหรือผิด ตัวอย่างเช่น
· ถูกต้องแล้วที่จะเพิ่มประสิทธิภาพโค้ดเพื่อใช้ทรัพยากรหน่วยความจำน้อยลง
· มันถูกต้องที่จะเขียนโค้ดสะอาดพร้อมความคิดเห็นที่เหมาะสม เพื่อให้ผู้อื่นเข้าใจโค้ดของพวกเขา
· มันผิดเมื่อพฤติกรรมการดีบั๊กทำให้เกิดบั๊กมากขึ้น
· เป็นเรื่องผิดหากใช้ฟังก์ชันที่ไม่ดี

อย่างไรก็ตาม มันเป็นเรื่องที่แตกต่างอย่างสิ้นเชิงสำหรับโปรดิวเซอร์ บางครั้งทีมรู้สึกดีกับการปรับเปลี่ยนของโปรดิวเซอร์ แต่ในความเป็นจริงแล้ว แย่ต่อประสิทธิภาพการทำงาน บางครั้งทีมอาจบ่นเกี่ยวกับการปรับเปลี่ยนแต่ช่วยเพิ่มประสิทธิภาพการทำงานและทีมยอมรับการปรับเปลี่ยนหลังจากได้ลองใช้งานมาระยะหนึ่ง

มันทำให้ฉันแทบคลั่งในจุดแรกที่รู้ว่าต้องปรับวิธีการจัดการแต่ไม่รู้ว่าต้องทำอย่างไร ฉันพยายามจัดสรรทีมย่อย เช่น ทีม AI ทีมฟิสิกส์ ทีมตรรกะเกม ฯลฯ เพื่อแบ่งหัวข้อกว้างๆ ออกเป็นส่วนย่อยๆ แต่วันหลังเหมือนต่างคนต่างห่างเหินกันไป นอกจากนี้ เราแทบไม่มีการสื่อสารแบบข้ามสาขาใน PoCT เราผู้ผลิตคิดหาวิธีที่จะปรับเปลี่ยน แต่เราไม่รู้ว่าอะไรจะเกิดขึ้นในเหตุการณ์สำคัญครั้งต่อไป

นอกจากนี้.

ตามแนวคิดผู้นำผู้รับใช้ สิ่งที่ถูกต้องที่ผู้ผลิตควรทำคือ “รับใช้ทีม” และพร้อมที่จะให้การสนับสนุนเมื่อทีมต้องการ แต่การเป็นผู้นำผู้รับใช้หมายถึงอะไรกันแน่? ทีมงานคาดหวังอะไรจากผู้ผลิตบ้าง? ปัญหาประเภทใดที่พวกเขาไม่สามารถแก้ไขได้หากไม่มีผู้ผลิต ตรวจสอบบล็อกในอนาคตของฉันในหัวข้อนี้โดยเฉพาะ!

อ้างอิง:

[1]: ความคิดในการเรียนรู้: ทำอย่างไรจึงจะเสริมการเรียนรู้อะไรก็ได้

[2]: 18 ทักษะที่โปรแกรมเมอร์ทุกคนต้องมี

[3]: ความสำคัญของคำติชมที่ทันท่วงทีและมีประสิทธิภาพ