Üniversitenin ikinci yılında bir programcı oldum, tüm programlama derslerimde başarılı oldum ve problem çözme konusunda bir programcı zihniyeti geliştirdim. Şimdi, üç yıl sonra, bir video oyun yapımcısı olarak, gurur duyduğum programcı zihniyeti, ilk PoCT (Kavram Kanıtı Teknolojisi) dönüm noktamda bana birçok engel getirdi. Zihniyette bir değişimin gerekli olduğu açık hale geldi.

Programcı ve yapımcı zihniyetleri arasındaki temel fark olarak belirlediklerim şunlardır:

1. Programcıların bireysel görevlere odaklanması gerekirken, yapımcıların daha çok yönlü olması ve ekiplerinin kullanımına açık olması gerekir.
2. Programcılar anında geri bildirim alır ve doğru veya yanlış yanıtları netleştirirken, üreticiler genellikle anında geri bildirimden yoksun kalır ve daha belirsiz durumlarla karşı karşıya kalır.

Programcılara uygulamaları gereken özellikler verildiğinde, kodlarının mimarisini düşünür ve mevcut işlevlerine dayalı olarak özellikleri gerçekleştirip gerçekleştiremeyeceklerine bakarlar. Ve yapamazlarsa, gereksinimleri karşılamak için yeni işlevler (büyük olasılıkla mimariler oluşturma, mantık tanımlama ve test etme ve hata ayıklama dahil) bulmaları gerekir.

Ekibimdeki programcılardan birinin sözlerini aktarıyorum:
Kodum üzerinde çalışırken normalde gürültü önleyici kulaklıklarımı takar ve beynimde kalırdım. Müzik dinlemiyordum; Kodlarıma odaklanmak için sadece sessiz ortama ihtiyacım vardı.

Ancak bir yapımcı, ekibiyle otururken gürültü önleyici bir kulaklık takarsa, bu kötü bir yapımcıdır.

Yapımcıların her yeri görmesi ve her yerde duyması gerekiyor.

Ekiplerindeki herkesin ilerlemesini takip etmek, sınırları aşmadıklarından emin olmak ve ekipler arası işbirliği gerekliyse diğer ekibin yapımcılarıyla koordinasyon sağlamak yapımcıların görevidir.

Bir SD yapımcısı olarak, PoCT'm sırasında, sandalyeme oturduktan sonra her on ila yirmi dakikada bir, ekibimden biri veya Seviye Tasarım yapımcımız, oyun tasarımcımız, baş yapımcımız vb. tarafından arandım.

Ne zaman belirli bir göreve odaklanmaya çalışsam, biri beni aradı. PoCT sırasında, neyse ki, takvimde açıklamaya veya ekibimizdeki bir uzmanın yardımına vb. ihtiyaç duyup duymadıkları konusunda benimle konuşan herkesi memnun ettim; ne yazık ki normal çalışma süremizden sonra kendi işlerim üzerinde fazladan çalışmam gerekiyor.

Yapımcıların ekibe göz kulak olması ve tüm farklı talepleri duyması gerektiği doğru, ancak bu, yapımcıların kendileri için yapacak hiçbir şeyleri olmadığı anlamına gelmiyor. Ürün biriktirme listesini tutmalı, tahmini saatleri saymalı, kilometre taşı teslimatlarını sürekli kontrol etmelidir, vb. Takımda zaman yönetimi açısından en iyi olan bir üreticinin kendi zamanını yönetmede başarısız olması kabul edilemez. Düzeltmeler yapılmalı ve önlemler alınmalıdır. İşte her yapımcının dikkate alabileceği bazı öneriler:

• Her iş günü için tahmini saatlerle bir yapılması gerekenler listesi oluşturmaya çalışın ve egzersizi önlemek için listeyi dikkatlice takip edin.
• Her görüşme için bir zaman çerçevesi belirleyin ve bu süreye kesinlikle uyun (On dakika iyi bir dakika olabilir).

Programcılar anında geri bildirim almaya alışkındır. Kodlarının özelliği gerçekleştirip gerçekleştirmediğini/gereksinimi karşılayıp karşılamadığını "Çalıştır" düğmesine bastıktan hemen sonra anlarlar. Bununla birlikte, üreticilerin hızlı yanıt alma olasılığı daha düşüktür. Ayarlamalarının sorunu çözüp çözmediğini anında söyleyemezler. Ayarlamalarının neyle sonuçlandığını bilmek günler, haftalar ve hatta bir sonraki dönüm noktasına kadar sürebilir.

Programcıların bunun doğru mu yanlış mı olduğunu söylemesi de kolaydır. Örneğin,
· Kodları daha az bellek kaynağı kullanacak şekilde optimize etmek doğrudur.
· Başkalarının kodlarını anlaması için uygun yorumlarla temiz kodlar yazmak doğrudur.
· Hata ayıklama davranışları daha fazla hataya neden olduğunda yanlıştır.
· Kötü işlevler uygularlarsa yanlıştır.

Ancak, yapımcılar için tamamen farklı bir hikaye. Bazen ekip, üreticinin ayarlamaları konusunda iyi hisseder, ancak bu aslında üretkenlik için kötüdür. Bazen ekip uyumdan şikayet edebilir ama bu, verimliliği artırır ve ekip, uyarlamayı bir süre deneyimledikten sonra kabul eder.

İlk noktada yönetim tarzımı değiştirmem gerektiğini fark ettiğimde ama nasıl yapacağımı bilmediğimde neredeyse deliriyordum. Daha geniş konuyu daha küçük parçalara bölmek için AI ekibi, fizik ekibi, Oyun mantığı ekibi vb. gibi alt ekipler ayırmaya çalışıyorum. Ama günler sonra herkes birbirinden biraz ayrı gibi görünüyor. Ayrıca, PoCT'de neredeyse disiplinler arası iletişimimiz yok, biz üreticiler uyum sağlamanın yollarını bulduk, ancak bunun bir sonraki kilometre taşında neye yol açacağı hakkında hiçbir fikrimiz yoktu.

Üstelik.

Hizmetkâr liderlik fikrine göre. Üreticilerin yapması gereken doğru şey “ekibe hizmet etmek” ve takımın ihtiyacı olduğunda destek sağlamaya hazır olmaktır. Ancak hizmetkar liderlik tam olarak ne anlama geliyor? Takımın yapımcılardan beklentileri nelerdir? Üreticiler olmadan hangi sorunları çözemezler? Özellikle bu konuyla ilgili gelecekteki bloguma göz atın!

Referans:

[1]: Öğrenme zihniyeti: Herhangi bir şeyi öğrenmek nasıl geliştirilir?

[2]: Tüm Programcıların Sahip Olması Gereken 18 Beceri

[3]: Zamanında ve Etkili Geri Bildirimin Önemi