Belki 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 sonuc  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   bi  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   kulanarak   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 malesef  profesyonel şırkette  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 bi şirkette SQL Queryleri 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  bi
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  bi  konuyu  derinleme  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 farkedebilecek 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   farkedebilir   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 farkedilmesini 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ı  olmaya  öğ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 insiyatifi 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  baglıdır. Bu ozellığın  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  bir kaç  ü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  insiyatif
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  insiyatif kullanmayı severler.  Bu onların yaptıkları  işten
duydukları tatmini  artırır. Tamamen  gönüllü bir  hobi olan  scenede 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...

[b] Nightlord/Glance [/b]