DEMOSCENE'İN VADETTİKLERİ
Retro bilgisayarBelki de birçok insan için ilk defa tanışılan bir kavram olan demoscene, herhangi bir hobi olmaktan ötedir. Bu hobiye sahip olmak insana, hem kendi içinde, hem de günlük yaşantısında büyük getiriler sağlayabilir. Hem teknik, hem profesyonellik adına, iş yaşantısında size değer katacak çok kritik bazı yaklaşımları kazandırabilir.
Buna karşılık demoscene ile ilgilenip bu ödülleri elde edebilmek kolay olmayabilir. Genellikle normal okul ve iş yaşantınızın dışında, boş vakitlerinizin önemli bir bölümünü, zaman zaman bu hobiyle ilgili araştırma ve çalışmalara ayırmanız gerekebilir. Bu ayırdığınız zamanda kendinizde gördüğünüz ilerleme, her zaman sabit bir hızda olmayabilir. Özellikle bir demoscene ürününü bir tarihe yetiştirmeye çalıştığınız son sıkışık dönemlerde geceli gündüzlü çalışmanız gerekebilir.
İşte bütün bu ödül ve bedelleri bir bütün olarak gördüğünüz takdirde, kendi kendinize "evet bu ödüller bu bedellere değer" diyebiliyorsanız, o zaman demoscene'e ilk adımınızı attınız demektir. Bu yazıdaki amacım özellikle Türkiye koşullarında, çeşitli büyüklüklerdeki şirketlerde çalışırken, bireylerin ve ekiplerin başarısına çok etkisi olduğunu gördüğüm ve demoscene'de kazanılabileceğini düşündüğüm iki temel alışkanlığı sizlere anlatmak. Biraz felsefi görünmekle beraber aslında bu yazıda son derece somut sebep sonuç ilişkileri ortaya koymaya çalışacağım. Çünkü bu alışkanlıklar aslında son derece mekanik yöntemlerle kazanılabilir düşüncesindeyim. Bu iki alışkanlığa ben "sonunu getirebilme" ve "takım ile çalışabilme" diyeceğim.
Sonunu Getirme Değinmek istediğim birinci alışkanlık bu. Ülkemizde en büyük eksiklerden biri olduğuna inandığım bu kavram, tahmin edebileceğiniz gibi başladığı işi bitirme alışkanlığı anlamına geliyor. Hem profesyonel şirketlerde, hem amatör hobi gruplarında herkesin bir takım projelere büyük gaz içinde başladığını görürsünüz. Şirketlerde, çeşitli birimlerden insanların toplanıp, ateşli konuşmalar yaptığı büyük toplantılar yapılır. Başlanan projenin ne kadar büyük kazançlar sağlayacağı, bol renkli Powerpoint sunumlarıyla dile getirilir. Fikir çok iyi bir fikirdir. Planlanan şey planlandığı zamanda biterse harika olacaktır. Satış grubu milyonlarca dolarlık kar öngörmektedir.
Aynı şekilde 2 üniversiteli arkadaş bir araya gelirler. Canları bir oyun yapmak istemektedir. Aralarından biri 3D Studio Max kullanarak model yapabilmektedir. Diğeri de OpenGL ile birkaç kutu göstermiştir. Biraz çalıştıktan sonra birisinin yaptığı modeli diğeri kendi 3d gösterme koduyla render edebilmeye başlar. Tamamdır artık önlerinde hiçbir engel kalmamıştır. Hemen bir de web sitesi yaparlar. Yeni FPS oyunlarını yapmaya girişirler. Oyunu bitirdiklerinde harika olacaktır.
Gelin görün ki maalesef profesyonel şirkette olaylar şöyle devam eder. Proje yapılmaya başlanır. Teknik bazı problemler çıkmaya başlar. Teknik ekip yaklaşık proje zamanının yarısı geçtiğinde hala geç kaldığının farkında bile değildir. Son çeyreğe girerken geç kaldığını bildirir. Satış ekipleri kıyameti koparır. "Time to market" kavramının çok önemli olduğu, bu deyimi bir kaç ay önce Ekonomist dergisinde ilk defa okumuş olan genç ve ateşli satış elemanlarınca savunulurken, teknik ekipler de sürekli proje speklerinin değişmesinden yakınırlar. Bu yüzden geciktiklerini söylerler. Proje ilk planlanan zamanın son çeyreğine girdiğinde, son tarih bir ay ileri atılır. Bu ileri atmalar yaklaşık 5 ila 15 kere daha yapıldıktan sonra projeden vazgeçilir. Onca para ve zaman boşa gitmiştir. Fakat daha kötüsü kimse nerede yanlış yapıldığını da tam bilememektedir. Çünkü farklı birimlerin savlarından hangilerinin doğru olduğunu bilecek kadar, değişik birimlerde yapılan işi tanıyan yöneticiler yoktur. Çünkü yönetici zaten bir birimde yükselmiş ve en sonundan yönetici olmuştur. Yani şirket bu kayıptan hiçbir şey öğrenmemiştir.
Oyun yapan iki kafadarın hikayesi ise genelde çok daha hızlı gelişir ve sonlanır. Genelde yaz tatili dönüşü başlayan proje ikinci vizeler civarı tamamen durmuştur. Zaten sonraki dönem aynı dersleri almayan ekibimiz iyice az görüşmeye başlar. Tabii web sitesi daha birkaç yıl ayakta kalabilir. Daha kötüsü bu arkadaşlar daha sonra başka arkadaşlarıyla üniversite boyunca böyle 4 oyun daha yarım bırakırlar. Sonra zaten biri bankacı olur, diğeri database uygulamaları geliştiren bir şirkette SQL Query'leri yazmaya başlar.
Neden Bu iki hikayede de çok tanıdık "sonunu getirememe" örnekleri var. Başlanan bir işin sonunun gelebilmesi birkaç şeye bağlıdır. 1- İş büyüklüğünü öngörebilmek 2- Proje yapılmaktayken, işin ne kadarının bitip ne kadarının kaldığını ölçebilmek 3- Projenin sonucuna odaklı olmak. Yani "proje esnasında çıkan bir problemi çözmek için bir araç yapmaya karar verip, o aracı yaparken çıkan başka bir problemi çözmek için başka bir araştırma yapıp, o araştırma esnasında çıkan bir konuyu derinlemesine incelemeye karar vermek..." şeklinde davranmamak.
Bir projenin büyüklüğünü öngörebilmek, çok temel bir ihtiyaçken nedense bir türlü gereken önem verilmez. Bugüne kadar gördüğüm şirket ortamlarında yöneticiler hep bu soruyu sorar. "Bu işi kaç adamla ne kadar sürede yapacaksınız". Gelin görün ki ne cevabı veren bu öngörüyü doğru yapar ne de yönetici yanlış bir öngörüyü erken fark edebilecek durumdadır.
Öngörü adı üstünde bir tahmindir ve hata payı her zaman vardır. Fakat bu hatayı azaltmanın yolları da vardır. Bunlara tasarım ve planlama denir.
Bir proje ilk önce kağıt üstünde, alt işlere ve o alt işler de kendi içlerinde sürekli daha küçük parçalara bölünebilir. Bu şekilde küçük parçalar için yapılan tahminler toplandığı zaman elde edilen sonuç, projeye kocaman bir blok olarak bakılıp yapılan tahminden çok daha gerçekçi olacaktır. Bütün olay bu kadar basittir. Ama bu basit olayı çok az insan uygulamaktadır. Bir proje küçük iş parçacıkları listesi haline getirildiğinde ekip ilk defa kafasında projeyi gerçekten görür. Bundan önce ekip kafasında projenin sadece sonucunu görebilmektedir (şanslıysa). Bir projenin bittiği zamanki halini görmek başka, projenin yapım sürecini görebilmek bambaşka şeylerdir.
Aynı bölümleme sonradan proje esnasında da ölçüm amaçlı kullanılabilir. Zaman olarak tam ne kadar işiniz kaldığını ölçemeseniz bile kalan iş kalemlerini böylelikle görebilirsiniz.
Bu ölçme size proje esnasında refleks gösterme şansı tanır. Olası değişiklikler veya bir iş parçasının beklenenden uzun sürmesi halinde bunu erken fark edebilir ve önlem alabilirsiniz. Örneğin bir ekip ile çalışıyorsanız, geciken iş parçacığına daha fazla kaynak kaydırabilir veya alternatif çözümler arayabilirsiniz. Bu "yaa nasıl olsa daha 8 ayımız var" demekten daha sağlıklıdır.
Son olarak projenin sonucuna odaklı olmak, sizin sonuca doğru ilerleyen yoldan mümkün olduğunca az saparak yürümeniz demektir. Bu özellikle teknik insanlarda sık görülen bir davranış desenidir. Teknik kişiler bazen ilgilerini çeken konularda daldan dala konarak hedeflerinden uzaklaşırlar. Amaç ile aracı karıştırırlar. Bu kişisel bir disiplini gerektirir. Düzenli aralıklarla kişinin ben ne yapıyorum ve niye yapıyorum diye kendine sorması bunu çözebilir. Ayrıca yine iş parçacıkları planında gecikme veya sürekli yeni iş parçacığı eklemek durumu, bunun fark edilmesini sağlayabilir.
Başlanılan işin sonunu getirebilme alışkanlığı, bu üç temel yaklaşımın benimsenmesi ile kazanılabilir. Demoscene bu alışkanlığı kazandırmakta rol oynar. Çünkü demoscene'de yapılan parti ve yarışmalar esnasında demo çıkarmak önemlidir. Bu da sabit ve esneyemez bir proje son tarihi demektir. Bu yüzden scenerlar genelde bir demoyu bir partiye yetiştirmeye çalışırken yaşadıklarından çok şey öğrenirler.
Belki de en temel öğrenilen şey şudur. Yazılım geliştirmek zor ve sürprizlere açık bir süreçtir. İster amatör ister profesyonel olarak yapılsın, en küçük yazılım projelerinde bile beklenmedik problemler her zaman çıkabilir. Scenerlar genelde bunu ilk intro çalışmaları esnasında öğrenirler. En küçük bir intro bile bir scenerın kendi yetilerini tanımasını sağlayan zorlu bir proje olacaktır.
Demolar genelde ard arda gelen efektlerden oluştuğu için, ekipler halinde çalışan scenerların, bir demodaki efektleri bölüşmesi de nispeten kolaydır. Efektlerdeki bu bağımsızlık genelde scenerlara, bir projeye daha küçük iş parçacıklarının bir bütünü olarak bakma alışkanlığını kazandırır.
Diğer bir temel nokta, scenerlar genelde yarı bitmiş bir şeyi yayınlamazlar. Bu yüzden de sonuca odaklı olmayı öğrenirler. Bir demoscene ürünü ancak yayınlandığında bitmiştir. Bir scener da ancak bitirdiği ürünler kadar vardır. Ürün bitirmeyen adamlar ne kadar yetenekli olurlarsa olsunlar, her zaman ürün bitirenlerin gerisinde kalırlar. Scene ortamının ürün bitirme konusundaki bu zorlayıcı havası scenerların genelde çok küçük yaşlardan itibaren sonuç odaklı olmasını sağlar.
Takım Çalışması Sonunu getirebilmek dışındaki temel bir özellik de takım halinde çalışabilmektir. Yine başta verdiğim şirket örneğinde en temel problemlerden biri buydu. Takım çalışması, ağızlarda sakız olmuş ve geyik motivasyon konuşmalarında sıkça değinilen bir konu olmasına karşın çok insan tarafından anlaşılmaktadır. İnsanların takım olarak çalışabilmesi birkaç kavrama bağlıdır
1- İletişim 2- Uzlaşabilme 3- Sorumluluk ile beraber inisiyatifi de paylaşabilme
Eğer bir takımdaki bireyler aynı dili konuşamıyorsa, bir kişinin söylediğinden iki kişi farklı şeyler anlıyorsa ortada takım olamaz. Bu iletişim konusu önce insanların dinleme yeteneklerine bağlıdır. Bu özelliğin nasıl kazanılacağı bu yazının konusu değil. İletişimin bağlı olduğu bir temel unsur daha vardır. Çok yönlülük.
Çok yönlü insanlar, yalnızca kendi uzmanı oldukları dalda değil, başkalarının uzman olduğu dallarda bile biraz olsun fikir sahibi olurlar. Böylelikle problemleri tartışırken ekip arkadaşlarının gözünden bakabilir ve daha iyi iletişim kurabilirler. İşte bu scene'de çok karşılaşılan bir durumdur. Pek çok scener birden fazla alanda aktiftir. Sadece bir alanda aktif olanlar bile diğer alanlarda pek çok şey öğrenmek zorundadır.
Bu şekilde iletişim kurabilen bireyler arasında uzlaşabilme şansı doğar. Bu şans bireyler uzlaşmaya meyilli olursa gerçeğe dönüşür. Scenerlar bir demo çıkmadıkça emeklerinin karşılığını alamadıkları için projelerde birbirlerine daha hoşgörülü ve uzlaşımcı olmayı ilk birkaç ürünlerinde öğrenirler. Bunu öğrenemeyen scenerlar yalnız kalır ve silinir. Scene tamamen gönüllü takımlardan oluştuğu için bir scene grubunun ayakta kalması o gruptakilerin birbirine hoşgörüsüne ve uzlaşımcı yaklaşımına bağlıdır.
İnsanların sıklıkla gözden kaçırdığı son konu da sorumluluk ve inisiyatif paylaşımıdır. Özellikle şirketlerde görevler insanlara dağıtılır ve o insanların makine gibi o görevleri yapması beklenir. O işle ilgili bazı seçim ve kararlar yöneticilerce alınır. Bu durum genelde çalışanların motivasyon kaybetmesine ve yaptığı işi sahiplenmemesine sebep olur.
İnsanlar makine değildir. Kendilerine verilen bir sorumluluk bölgesi içinde problem çözmeyi ve inisiyatif kullanmayı severler. Bu onların yaptıkları işten duydukları tatmini artırır. Tamamen gönüllü bir hobi olan scene'de de hiçbir scener ekip arkadaşına "sen şunu yap bunu yap tam olarak şöyle olsun" diyemez. Eğer öyle derse arkadaşı bunu yapmaz. Herkesin yaptığının zevkli ve tatminkar olmaya devam etmesi doğal bir zorunluluktur. Scenerlar bu doğal zorunlulukla daha ilk projelerinde karşılaşır ve bu çok temel dürtüyü belki de farkında olmadan kazanırlar.
Sonuç Bu yazıda ülkemizde var olduğunu ve önümüzü tıkadığını düşündüğüm "proje bitirememe" problemini analiz etmeye ve bu probleme çözüm olabilecek bazı davranış biçimlerinin demoscene'de nasıl kazanılabileceğine dair tespitler yapmaya çalıştım. Umarım hem hali hazırda scener olanlar, hem scener olmak isteyenler için bazı temel sorular üzerine düşüncelerinizi tetikleyebilmişimdir. Demoscene üyelerinin arttığı ve bunun ülkedeki üretkenliğe ve süreçlere etkilerinin yansıdığı bir Türkiye dileğiyle...