Bu sayfadaki yazılar
Sayfanın metni
Sayfa 65
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.
Klavyeyle gezinmek için ← ve → tuşları.
Sayfa 64
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.