Görkem'in blog girdisi ve benim yorumum üzerine sevgili Erhan Ekici de bir yazı hazırlayıvermiş. Üstelik benden daha çok çalışmış, çeşitli pazar araştırmalarına da referans vermiş. Eline sağlık.

Ben de onun kaldığı yerden devam edip, ekonomik kriz Ö/AKK için ne gibi bir etki yaratır bunu tartışmaya devam etmek istiyorum.

Erhan'ın da çok net vurguladığı biçimde, bilişim harcamalarında danışmanlık ve benzeri hizmet alımları ağırlık kazandığı için, Ö/AKK yazılımların sıfır lisans maliyeti içermesi çoğu kez o kadar da belirleyici bir karar verme kriteri oluşturmuyor. Satın almayı yapan kişi toplam maliyeti gözlemleyebiliyorsa, o zaman toplama dönük diğer katma değerleri irdeliyor. Burada istisna oluşturabilecek bir iki yer var - o da hizmet alımını fazla yapamayan bazı kamu kurumları ve çoğu kez bilişim şirketleri. Ama o konuya başka yerde girmek gerekli. Konumuz dağılmasın.

Bunların hepsi iyi güzel hoş değil mi? Ancak krizi hep aynı yönden bakarak irdelerseniz eksik bakmış olursunuz. Ekonomistler de dahil olarak, konuları insanlara kolayca açıklamak için sadeleştirmekten hoşlanıyoruz. Bir kriz varsa o krizi hemen arz krizi yada talep krizi olarak sınıflandırmak da bunlardan birisi. Bazılarına göre şu andaki kriz bir talep kriziymiş. Çünkü piyasalarda talep - nakit eksikliğinden dolayı - daralıyormuş.

Bu kadar düz bir bakış belki ülkeleri birer kalem olarak gören düz bir ekonomik modelde doğru olabilir. Ancak, ne yazık ki ekonomi o kadar basit bir şey değil. Ne tek bir ürün var, ne tek bir pazar ne de tek türde müşteri. Yani ECON1xx derslerinde bize anlatılan, mühendislere de tek dönemlik sıkıştırılmış ekonomik dersinde gösterilen şeyler sadece teorik temeli anlamak için gereken öğretim modelleri. Biz makro ekonomik gelişmenin belli sektörlerdeki etkisini inceleyip, sonra da tersten bakarak bu etkinin mikro sonuçlarını toplayarak makro ölçeğe olan tepkiyi görmek durumundayız.

Şimdi talep daralmasını temel düzeyde incelersek, bunun arzı oluşturan şirketlere olan etkisini üretimin durdurulması olarak görüyoruz. Üretim durunca, stoktaki ürünlerin satılması ve bu sayede stoğun eritilerek idare edilmesi hedefleniyor. Bu arada enerji, hammadde, nakliyat gibi giderler azaltıldığı için de daralan nakit akışı ile dahi idare edebiliyorsunuz. Burada üretimin ertelenmesinin etkisini çeşitli biçimlerde irdelemek mümkün. Yine temel ekonomik kuram bize üretimin 1) girişimci, 2) sermaye, 3) işçi, 4) hammadde ile yapıldığını, daha gelişmiş kuramlar bunlara 5) teknoloji ve belki de 6) pazarlama becerisinin eklenebileceğini söylüyorlar. Yani temel dörtlü ve ek ikiliden hepsinin az az olması gerekli ki üretim olsun. Herhangi birisini yok ederseniz üretim asla olmaz.

İşte tipik hata da burada oluyor. Temel dört girdiden birisi ile diğerlerinin ikame edilebileceği var sayılabilir mi? Örneğin girişimciler işçileri ikame edebilir mi? Lokantada mutfağa geçen bir patron söz konusu ise evet ikame eder. Ama fabrikada özel bir cihazı tamir eden usta işçinin yerine geçen bir holding patronu söz konusu ise etmez. Benzeri biçimde, sermaye de hammadeyi satın alabildiği, fazladan işçileri işe alabildiği için bir yere kadar diğerlerini ikame edebilir. Ama bir yere kadar. İşte o bir yerin nerede olduğu sektörden sektöre - ekonmistleri deyişi ile üretim kipine göre - değişkenlik arz eder.

Hizmet sektöründe çalışan bir şirketin stok tutma şansı yoktur. Hizmet üretimi için en azından bazı anahtar personelini sürekli olarak elinde tutması gerekir. Ayrıca anahtar olmayan personel içinde de çok hızlı isim değişiklikleri verimliliği öldürür. Çok basit ancak İstanbul gibi şehirler için çok geçerli bir örnek vereceğim. Falanca müşterinin adresini bulmak zor ise, her seferinde farklı insan yollamak işgücü israfıdır. Bu nedenle hizmet şirketleri için personelini elinde tutmak önemlidir.

Dolayısı ile hizmet şirketlerinde ve hizmet şirketleri ağırlıklı olarak çalışan sektörlerde başlangıç sermayesi gerektiren makina parkı alımları gibi maliyetler az olurken, sürekli olarak yapılan harcamalar yani faaliyet giderleri çok olur. Ö/AKK iş modellerinde de bu böyledir. En temel Ö/AKK iş modelleri daima hizmet sunumu üzerine kurguludur. Genelde hizmet üretimi ile elde edilen birikim ile daha sonra ürün geliştirilmesine dönük çalışmalar yapılması beklenir.

İşte şimdi krizden dolayı hizmet alımları azaltılırken, projeler - şimdilik - üç ila altı ay süreler ile ertelenirken, belirgin biçimde hizmet ağırlıklı gelirleri olan Ö/AKK şirketleri için önemli sorunlar oluşuyor. Çünkü ilerideki iş sürekliliği için anahtar personeli elde tutmak gerekirken, bir yandan da bu şirketlerin işletme giderlerini nasıl karşılayacakları sorusu ortaya çıkıyor. Kiralar, personel giderleri ve benzeri giderler için belli bir süreyi kaldıracak bir nakit stokları olduğunu düşünürsek o süre boyunca sorunsuz ayakta kalabileceklerdir. Ancak o süre aşılırsa ciddi sorunlar yaşanacaktır.

Bazılarının tipik bir var sayımı vardır. Sermayenin durduğu yerde bekleyebileceğini ve zamandan bağımsız olduğunu düşünürler. Halbuki sermaye durduğu yerde bir güzel aşınır. Enflasyon olmasa dahi aşınır ve eksilir. Hizmet şirketlerinde sermayenin diğer temel varlıkları ikame etme kapasitesi üretime göre - bence - daha sınırlı olduğu için sermayenin aşınması da daha hızlı olur.

Uzun lafın kısası, tıpkı diğer hizmet şirketleri gibi hizmet ağırlıklı gelirleri olan Ö/AKK şirketlerinin de ayrıca dikkatli olması gerekiyor.

Peki bu durumdan etkilenmeyen kim olabilir? Yada kolay bir çıkış yolu var mıdır?

• Hizmete ek olarak ürün geliştirme çalışmaları olan ve şu yada bu şekilde ürün gelirleri de bulunan Ö/AKK şirketleri bu dengesizlikten o kadar da çok etkilenmeyecektir. Belki Red Hat yada Sun gibi firmaların krize daha umutla bakmasının arkasında bu vardır.
• Ancak hazırda bir ürünü olmayan hizmet şirketlerinin de - krizde hizmet satamadıkları için - bodoslama biçimde ürün geliştirme projeleri yapması doğru mudur onu da ayrıca tartışmak gerekli. Ne de olsa ürün geliştirmenin önemli maliyetleri var.
• Yine önemli bir diğer olgu da temelde ürün şirketi olan şirketlerin girdilerini artırmak için hizmet alanlarına da geçici girişler yapması ve bu alanda geçici oldukları için sektörün alıştığından düşük maliyetler sunmaları. Bu maliyetler alıcılar için çekici olacaktır. Aslında sürdürülebilir maliyetler olmadıkları bellidir ama kriz döneminde bir iki kez ucuz etin yahnisi yense, yavan da olsa karın doyuracağı için alıcılar bunlara yönelebilir. Bu yaklaşım sektörde oturmuş hizmet firmaları için yıkıcı olmaz ama krizin etkilerini derinleştirir ve kriz sonrası toparlanma süresini uzatır.

Geçenlerde kazara ulaştığım bir blog girdisi çok hoşuma gitti. Ben de paylaşmak istedim. Stiff blogunda, Ekim 2006'da aklına gelen bir kaç soruyu önemli gördüğü programcılara yolladığında aldığı yanıtları aktarıyor. Bu insanlar kimler mi? Aralarında Linus Torvalds'dan James Gosling'e, Guido Van Rossum'dan Bjarne Stroustrup'a çok ünlü isimler var.

Programlamayı nasıl öğrendiklerinden, boş zamanlarında ne yaptıklarına kadar değişik bir yelpazede ilgi çekici sorulara bazen şaşırtıcı yanıtlar alıyorsunuz. Kesinlikle okumaya değer.

Bir süredir sevgili Görkem'in ufak tefek notlarını Facebook üzerinden takip ediyorum. Sadece ben değil, Erkan Tekman gibi özgür yazılım camiamızda tanıdığımız isimler de takip ediyor, altına notlar düşüyor.

Bu hafta içinde Görkem, krizin Ö/AKK üzerindeki etkisini irdeleyen, biraz da kötümser bir kaç not düştü. Ben de okuduktan sonra gecikmeli de olsa bir yorum yapmak istedim. El değmişken, yorumumu buraya da kopyalayıp yapıştırasım geldi.

Ö/AKK nın bir yerde fırsat yaratması için Ö/AKK nın farklı yapısından kaynaklanan bir katma değer yaratması gerekli. Kriz ortamında salt Ö/AKK yazılım alt yapıları kullanmaya geçiş özellikle görülür bir maliyet avantajı yaratmayacaktır. Çünkü normal şartlarda sahipli yazılımlardaki güncelleme, yeni sürüm alma gibi lisans maliyeti oluşturan kararlar erteleneceği için Ö/AKK geçişi yapmayan bir rakiple görülür bir maliyet farkı oluşmayacak.

O halde Ö/AKK'yı düz bir maliyet indirici olarak görmemek gerekli. Ö/AKK'nın daha gelişmiş etkilerinden yararlanmayı becerebilen kişiler buradan fırsat çıkartabilir.

Ancak bu da genelde kişinin veya kuruluşun kendi iş yapış biçimi tarafından kısıtlanıyor. Örneğin çoğu kez önerilen kar paylaşımı modeli ile çalışmak, Ö/AKK için çok uygun bir iş ortaklığı modelidir. Bir yerde bir Ö/AKK ürünü üreten, diğer yerde onun üzerinden iş yapan iki ticari varlık kar paylaşımı üzerinden sinerji yaratabilir. Ö/AKK bu sinerjinin olmasını kolaylaştıracaktır. Bununla birlikte, varlıklardan birisi yapısı ve işleyişi gereği kar paylaşımı yapamıyorsa, o zaman iş ortaklığı böyle kurgulanamaz.

Edevlet girişimlerinde Ö/AKK'yı kullanarak yaratıcı, yenilikçi iş modelleri kurmak çok zor. Çünkü tanım gereği devlet, statükocudur. Yukarıdaki gibi modeller kurmakta, işletmekte zorlanır.

İki ifadeyi alt alt koyunca, edevlet ve kamuyu hedefleyerek krizde Ö/AKK ile fırsat yaratalım demek o kadar da kolay değil diyorum.

http://www.blogger.com/

Deneyin ve göremeyin.

2000-2001 dönemlerinde Apple'ın kendisi de derleyici olarak GCC kullanmaya başladığı için Mac OS X'de GCC kurmak oldukça kolay bir şey. Yapmanı gereken ilk şey Apple Developer Connection sitesine üye olmak. Burada geleneksel bir form dolduruyorsunuz. Apple'ın merak ettiği önemli bir şey herhangi bir üniversitede öğrenci durumunuz olup olmadığı. Arkasından geliştirici olarak ne yaptığınızı soran çok basit ve çok hoşuma giden bir anket hazırlamışlar. Programlama dili ve benzeri detaylara hiç girmemişler. Kimin için, hangi tür yazılımları hangi işletim sistemlerinde yazdığınızı öğrenmek onlara yetiyor.

Bir kez Apple Developer Connection (ADC) üyesi olunca, çok çeşitli araçları indirebiliyorsunuz. Bunlar arasında Mac OS X çekirdeği için hata ayıklayıcı gibi şeylerden türlü türlü SDK'lara kadar çok farklı paketler var. Elbette benim esas ilgimi çeken XCode aracı. Yalnız dikkat edilecek bir şey var. Bu araç ekleri vs ile yaklaşık 1.2 GB boyutundaki bir paket ile geliyor. Yani tek başına GCC kurmak isteseniz dahi, önce bütün araç paketini çekmeniz sonra da kurulum sırasında sadece GCC'yi çekmeniz gerekiyor.

Uzun bir indirme ve bir kaç tıklama sonrasında XCode'u kurunca /usr/bin/gcc adresinde GCC kurulmuş oluyor.

UFS biçimli diskimi Pardus'da bağlayıp verileri diskten diske taşıdıktan sonra, USB diskimi Gparted kullanarak kolayca EXT2 olarak biçimlendirdim. Şimdi hemen gelebilecek olan soru neden EXT3 olmadığı olabilir. Aslında EXT2 ve EXT3 arasında bir fark yok. Çok kabaca ele alırsan EXT3, EXT2'nin günlüklü çalışan hali ve her zaman bir EXT3 bölümünü EXT2 olarak bağlamak mümkün. Ancak bazı EXT2 araçları gene de EXT3 ile sorun yaşayabiliyor. Mac OS X üzerinde çeşitli EXT3 araçları bulsam da ben kendimi sağlama almak adına EXT2 olarak biçimlendirdim. Hem yedek almak için kullanacağım diski çok sık kullanmayacağım için günlük özelliği de çok önemli olmayacaktır.

Bu durumda ilk işim Mac OS X'in desteklediği dosya sistemlerini bulmak oldu. EXT2'yi doğrudan desteklemesini beklemiyordum ama gene de bir şansımı deneyeyim dedim. Görülen o ki, bir Max OS X kurulumunda desteklenen dosya sistemlerinin listesini elde etmek kolaymış.

BoraAir:~ boragungoren$ ls /System/Library/Filesystems/
AppleShare cd9660.fs hfs.fs ntfs.fs ufs.fs
URLMount cddafs.fs msdos.fs smbfs.fs webdav.fs
afpfs.fs ftp.fs nfs.fs udf.fs zfs.fs
BoraAir:~ boragungoren$

Fena bir liste değil ama yine de benim derdimi çözmedi. Bunlara EXT2 ve/veya EXT3 desteğini ekletmem gerekli.

İlk bulduğum proje ext2fsx projesiydi. Ama projenin belgelerini kurcalayınca OS X 10.4 ve üzeri sürümlerde desteklenmediğini öğrendim. Bu de benim 10.5 sürümlü (Leopard) OS X için çözüm olmadığını gösteriyordu.

İkinci bulduğum çözüm ise çok daha şık bir çözüm gibi gözüküyordu. Bir Google projesi olan MacFUSE

Ben de herkes gibi nasıl yaparım sayfasını referans aldım. Burada eğer projeyi koddan çekip derlemek istemiyorsanız buradaki rehberi okuyun diyordu. Oldukça komik bir durum çünkü kısa rehber çok kısaydı ve aslında istense nasıl yaparım belgesine eklenebilirdi. Böylece sadece kurulum dosyasını indirdim. Kurulum dosyası OS X'de adet olduğu üzere aslında kendinden menkul bir disk bölümü ve içinde duran MacFUSE.pkg dosyasına çift tıklayınca kurulum aracı açıldı. Toplam 2,1 MB gibi küçük bir yer kaplayan uygulama kuruldu ve aracıma sahip oldum. Bunu da aşağıdaki biçimde kontrol etmek mümkün oldu.

BoraAir:/ boragungoren$ ls /Library/Filesystems/
fusefs.fs
BoraAir:/ boragungoren$

Bütün bunlar olurken, buradaki videoyu da izledikten sonra oldukça tatmin olmuş durumdaydım. Videoda Picasa ile konuşan ve oradaki fotoğraf albümlerini birer yerel dizin gibi gösteren bir dosya sistemi bile örnekleniyordu. Mac OS X'de her şeyin kolayca kurulması da insana ayrı cesaret veriyordu.

Herhalde her şey bitmiştir diyerek hevesle USB diskimi bağladım. Mac OS X, doğal olarak EXT2 dosya sistemini tanımadığı için otomatik bağlama yapmadı. Ben de FUSE ile bağlamak için bir terminal açtım.

OS X'de değişik dosya sistemlerini bağlamak için mount_ arkasından dosya sistemi adı yazılan biçimde komutları kullanırsınız. Ben de mount_fusefs komutunu aradım. Bir şeyler eksik olmalıydı. Biraz araştırınca emin oldum. Elbette eksikti. Ext2Fuse projesi de bu eksiği gidermek içindi zaten. Linux için olan ve 2008 yılı itibarı ile SF.net içinde Alpha aşamasında olan bir proje de olsa, Mac OS X'de derlemekte ne zorluk olabilirdi ki? :)

Hemen ext2fuse-src-0.8.1.tar.gz dosyasını indirdim ve açtım. İçinde alıştığımız configure betiğine ek olarak install-sh adında bir betik ve bir de README dosyası da olan bir projeydi. Hemen biraz okuduktan sonra ./configure dedik ve ilk hata mesajlarımızı aldık.

Evet, meraklısına sürpriz. Sıfırdan kurulan Mac OS X'de awk ve C derleyicisi hazır gelmiyor. Bunları elinizle kurmanız gerekli. Ben daha çok Java ile uğraştığım için JDK ve Eclipse'i kolayca kurmuş olmam bana yetmişti ama şimdi awk ve C/C++ için araçlar kurmak da gerekecek.

Demek ki neymiş, Linux ile daima hazır kurulu gelen - yada en fazla iki satır komut ile kurulan - onlarca, yüzlerce geliştirme aracının bir nedeni varmış. :) Neyin ne zaman gerekeceği belli olmuyormuş.

Yetişecek işlerin de olduğunu düşünerek - bugünlük ara verdim.

Bir kaç gün içinde - işlerden boş vakit bulunca- bunları kurup, ext2fuse ile çalışmaya devam edeceğim. Bakalım önce Mac OS X içinde, sonra da Mac OS X'den sanallaştırarak çalıştırılan bir Linux'dan (elimin altında daima Pardus ve Ubuntu Server duruyor) erişmeye çalışacağım. Önce sıradan bir kullanımda MacFUSE ne kadar performanslı görelim, daha sonra EXT2 dosya sistemi ayarları ile denemeler de yapabilirim.

Bunları halledeyim daha neler neler yapacağım.

Hem Linux hem Mac OS X kullanırken, harici diskleri kullanmak biraz dikkat istiyor. Mac OS X'in desteklediği dosya sistemleri listesi daha çok BSD türü dosya sistemleri ve varsayılan dosya sistemi de HFS+. Linux dağıtımlarında doğrudan doğruya HFS+ desteği olmadığından, sonradan iş çıkartmasın diye bir USB diskimi UFS olarak biçimlendirmiştim.

Sonradan fark ettim ki, Apple Mac OS X'i hazırlarken UFS dosya sisteminde küçük bir değişiklik yapmış. PowerPC işlemcili eski Mac'lerde işlemcinin bitleri okuma yönü ile Intel işlemcilerdeki farklı. Birisi sağdan sola birisi soldan sağa okuyor. Apple'ın modifiye UFS'si de daima Intel ile ters yönde var saymış. Bu bir terslik değil, çok eskilerden Next işletim sisteminden alınan bir miras. Tabii Intel işlemcili Mac serileri için de bu var sayım devam etmiş. UFS biçimlendirilen USB'den bağlanan diskinizi Mac OS X'ler arası gezdirdiğiniz sürece sorun yok. Ama Linux'a bağlayıp UFS olarak bağladığınızda ilginç bir sorun çıkıyor.

mount -r -t ufs /dev/sdc2 /root/ufs-disk2

Yukarıdaki komut diski bağlıyor bağlamasına ama içerisindeki verilere erişemiyorsunuz. Okuma hatası alıyorsunuz. Ancak bu dünyanın sonu değil. Linux'daki mount komutunun UFS türleri arasında farklılıkları ayırt edebilmesi için parametre alma şansı var.

mount -r -t ufs -o ufstype=openstep /dev/sdc2 /root/ufs-disk2

Buradaki ufstype parametresi için ufs, ufs2, 44bsd, sunufs, openstep gibi seçenekler var. Yani Sparc işlemcili - ve aynı uyumsuzluğa aday - bir Sun OS bilgisayardaki UFS diski Linux'da bağlamaya çalışsak, benzeri sorunu görebiliriz; ama usfstype parametresi ile çözebiliriz. de.

Bakalım her seferinde bu kadar dert olmasın diyerek sanırım bu sefer diskin içeriğini kopyalayıp diski ext3 olarak biçimlendireceğim ve Mac OS X'de ext3 nasıl yazma / okuma bağlanır onu çözeceğim.

Bugünlerde sosyal ağlarda bir şeyler ararken (evet aranabiliyor) tematik blogu olanlar daha da çok dikkatimi çekiyor. Bu sefer de çok güzel bir pazarlama blogu dikkatimi çekti.

Memleketim insanı yapar tabii.

Bu seferki öykü özellikle 2000 krizini yaşayanların bazılarına tanıdık gelecektir herhalde. Mevcut ekonomik durum için de öğretici olur diye düşünüyorum.

Genç girişimcimizin şirketi çok ciddi bir kaç kamu projesi aldıktan sonra kendisi şirketin büyütülmesi için yatırım yapılması gerektiğine karar verir. Henüz bu projeler teslim de edilmemiştir ama son derece iyi teklif metinleri yazıldığına göre, elbette o metinlerin de gerçekleşeceğine inanır ve çalışmaya başlar.

Bilindiği gibi bir yazılım şirketinin en önemli demirbaşlarından birisi en az 2, mümkünse 3 aracın otopark alanına zorlukla sığan bir makam arabası olmalıdır. Bu nedenle girişimcimiz bu demirbaş araçlardan en az 2 tane alır. Kendisi tek yöneticidir ama kapının önünde 2 araç gerçekten çok güzel gözükecektir.

Arkasından toplamda en fazla 10 sözleşme yöneten, yılda en fazla 10 tane proje için 10 tane fatura kesen, ve onlarca çalışan da olsa hepsi her ay aynı maaşları alan kişilerin bordrolarını dökmek için idari - mali işler bölümüne genç ve dinamik bir kadro kurmak gerekir. Bu bölüme önce 5, sonra bir 5 daha derken 10 kişi işe alınır. Bu 10 kişinin telefon açması uygun olmadığından bu arkadaşlara bir de ön büro kurulur.

Bu kadar kalabalık bir finans departmanı oluşunca, bankalardan kredi almak, teminat mektubu elde etmek gibi konularda önemli bir avantaj elde edilir. Artık kendisi 1-2 banka ile muhatap olacağına, ülkemizdeki hemen her banka ve hatta her bankada birden fazla şube ile muhatap olacak bir kadro olduğundan, her şubede hesaplar açılır. Her şubeye her ay güncel mizanlar yollanarak ne kadar büyük ve güçlü bir şirket olunduğu gösterilir. Her bir seferinde en az 10 bankadan kredi teklifi istenir. Hatta teklifler gerekmese de istenir. Bazen bir bankanın mevduata verdiği faiz öyle çekici gelir ki - öteki bankadan kredi çekilip ilk bankaya faize yatırılarak para kazanılır. Bu sayede şirket iş yapmadan para kazanmanın keyfine varmaya başlar.

Tabii şirketin aylık gelirleri giderleri aşağı yukarı sabit olduğu için bu kadar kalabalık idari kadro nedeni ile teknik kadro hızlı genişleyemez. Ancak yeni iş alındıkça genişleme sağlanır. Böylece şirketin gerçek iş gücünün büyümesi yavaşlar. Bu da doğal karşılanır - zaten 50 bin kişiyi geçen ABD'li şirketlerin hala hızla büyümesi de ancak yalandır.

Büyüme yavaşlarken, elbette ters giden işler ve müşterilerden geciken ödemeler de olur. Şirketin kuvvetli bir idari mali işler kadrosu olduğu için hemen bankalardan proje finansmanları alınmaya başlanır. Bu projelerde dışarıdan yaptırılan işler için de rahatlıkla ileri vadeli çekler ve diğer finansal araçlar ile gün kurtarılır. Böylece kapsamlı bir finansal yönetim başlamış olur.

Elbette bu finansal yönetim toplamı yönetmektedir. Ama neyin toplamının yönetildiği tartışmalıdır. Eldeki proje portföyü içinde hangi projelerin zararda olduğunu ifade etmek zor gelir. Muhasebe ekibi zaten onlarca bankadaki hesaplar, çekler, krediler ve bunların faizleri ile meşguldür. Tek düzen muhasebede bunların hepsinin ayrı hesap kodu vardır ve bu kadar hesap kodu içinde yanlış işlem yaparak Maliye'ye yanlış beyan vermek istemezler. Bu nedenle örneğin bir personelin bordrosundan çıkabilecek maliyet kalemlerini yarı yarıya çalıştığı iki projeye eşit bölüştürmek için proje muhasebe hesabı açacak zaman olmaz.

An gelir, finansal yönetim, muhasebeden yardım istemeye başlar. Bankaların bazı rasyoları güzel görmesi için muhasebenin o şekilde değil de bu şekilde tutulması gerekmektedir. Ayrıca fasıllar arası aktarımlar da önerilir. Ani sermaye artırımları ve indirimleri, demirbaş alımları ve satışları başlar. Bankalardan krediler geldiği sürece, genç girişimcimiz bunları umursamaz.

Bu arada teminat mektubu alabilmek için arsa, apartman dairesi gibi taşınmaz malların alınması salık verilir. Zaten yazılım şirketi makina sanayinde bir fabrika olduğu için ileride depo ve ek bina yapılabilecek geniş bir arazi içinde bina yapma mantığı geçerlidir. Hemen gidilir, şehrin dışında bir yerde geniş arsalar alınır. Arsa başı boş kalmasın diye bir de bina yapılır. O binada hiç bir yazılımcı çalışmayacak istemez ama bir kaç idari personel ve bazı yazılımcılar rotasyon usulü oraya gider gelirler. Ayrıca binanın güvenliği, temizliği gibi ek masraflar çıkar. Binaya gidecek personel için servis aracı satın alınır. Araç için şoför işe alınır.

Gün gelir, ülkede finansal sıkıntılar patlak verir. Bazı bankalar batar. Diğer bankalar da kendi durumlarını sağlama almak için kredi borcu olan firmalardan bu kredileri kapatmalarını rica ederler. Bizim girişimci tam da bu sırada arka arkaya bazı işlerinde alacaklarını alamaz. Kendisine verilen bazı çekler de karşılıksız çıkar ve sıkıntıya düşer. Derhal kendisinin dışarıya olan borçları sınıflandırılır.

Öncelikte banka borçları vardır çünkü bankalar en önemli iş ortaklarıdır. Sonra şirketin güçlü görünmesini sağlayan yan masraflar - özellikle de beylik ifadeler ile ne kadar güçlü olduklarını vurgulayan reklam maliyetleri kenara ayrılır. Sonra da kısıntılar başlar. Personel maaşları aylarca eksik ödenir. Taşeron firmaların ödemeleri sudan nedenlerle geciktirilir. Örneğin her gün işe gelen bir müdür tam da o ara hasta olur ve onun dışındaki müdürler de nezaketsizlik olacağı gerekçesi ile belgelere uzun süre imza atmazlar.

Bu şekilde bazı taşeronlar batırılır ki onların alacaklarını tahsil etme şansı kalmasın. Bazı elemanların istifa etmesi sağlanır ki tazminat alamasın.

Ancak bu arada kötü bir şey olur. Hiç kimse bu şirkette çalışmak istemez, ayrıca kimse bu şirketin taşeronu olmak da istemez. Giderek nitelikli insanların şirkete girişi kısıtlanır. Ayrılanlar içinde de ilk ayrılanlar en nitelikli insanlar olur. Genç girişimcimiz bunu da önemsemez. Bilanço ve aylık mizanlarda harika rasyolar vardır. Daha tahsil edemese de ileride alacağı paraları koyunca harika sayılar oluşmaktadır. Zaten finansal performans en önemli performanstır.

Bu arada ortaya çıkan banka krizleri sonrası ülkede yeni yasalar çıkar. Bankaların başka bazı rasyolara da bakması istenir. Bu rasyolar, önceki rasyoları iyi göstermek için oynanmış bilançolarda hassaslaşan yerleri gıdıklamaktadır. Rasyo sayısı artınca, arkadaşın bilançosu da o kadar sağlam gözükmez. Bu yeni teknik yüzünden ahbaplık gelişmiş olan banka şube müdürlerinin de eli kolu bağlanır.

Şirket tüm odağını soruna çözmeye verir. Tüm idareciler sürekli bankalara gidip kredi aramaktadır. Kredi sağlayabilen idareci ödüllendirilir. Bu arada projelerdeki aksaklıklar raporlansa dahi dinlenmez ve müşterlerden gelecek ödemeler daha da çok gecikir. Müşteriden gelecek olan gerçekten hak edilmiş para yerine bankadan gelen borç işe süreç yürütme alışkanlığı daha da derinleşir.

Gün gelir, şirketin rasyoları o kadar zayıflar ki şirketin borç ödeme kapasitesini doldurduğu anlaşılır. O an şirket yeni kredi alamaz olur ve müşterilerine odaklanması gerektiğini anlar.

Ancak müşterilerin bazıları için olan olmuş, iş işten geçmiştir. Bu müşteriler ile artık insani konuşma değil de sözleşme maddeleri üzerinden tartışma geçerlidir Bu ortam altında müşteri ödemeleri alınamaz, bankalardan ek kredi alınamaz. Şirket iflasa sürüklenir. Ancak dışarıya bu hissettirilmez.

Tam bu sırada genç girişimcimize uluslar arası bir ödül gelir. İki yıl önceki oynanmış bilançoları örnek göstererek, en hızlı büyüyen şirketlerden birisinin kurucusu olarak bir ödüle aday gösterilmiştir ve yıllar süren süreç sonunda bir şekilde seçilmiştir. Bu ödül bankaların ve yatırımcıların şirkete bakışını değiştirir - kredi muslukları açılır, hatta şirketin hisselerinin bir bölümü oldukça iyi bir bedel karşılığı satılır.

Şirket iflastan dönmüştür. Bu sırada büyük emekleri geçen idari mali kadroya derhal ikramiyeler verilir. Ancak o dar zamanda maaşlarını eksik alarak projeleri zamanında tamamlayan esas çalışanlar unutulur. Şirket iflastan kurtulmuştur ama personeli ile olan barışı bozulmuştur bir kere.

Genç girişimcimizin bu krizden çıkarttığı ders ise, finans departmanını güçlendirmek olur ve 10 kişi daha işe alarak 20 kişilik bir finans departmanı kurulur.

Az önce okuduğum bir yazıya göre arada bir masanızın düzenini değiştirmek, sizi rutinden çıkarttığı için olaylara dikkatinizi verme becerinizi artırıyormuş.

O zaman, masası hep dağınık olan kişiler acaba size en çok dikkatini veren kişiler mi? :)

Bugün Rusya, Ukrayna ve diğer kuzey komşularımızı değişik bir gözle anlatan iki blog keşfettim. Bağlantılarını da burada paylaşmak istedim. Dinç Arslan ve Ulaş Ergin'in blogları kesinlikle okunmaya değer.

Yıllardır anlam veremem, bilişim sektöründe yapılan işlerin %60'ı yılın son 3 ayına, hatta tam olarak 1 Ekim - 15 Aralık arasına sıkışır. Tabii bunu bütçelerin açılması, yaz tatilleri, kurumsal planlama gib bir çok şey ile açıklamak mümkün ama bunların hiç biri bir işin belli başka aylara planlanmasına engel değildir.

Bu sabah resmen 2008 yılı son çeyreği başladı ve benim telefonlarım da çalmaya başlayrak kendisini ilan etti. Yani anlamamak elde değildi. İnsanlarda iç güdü olmuş herhalde. Ekim ayının ilk pazartesi günü telefona sarılıyorlar.

Uzun uzun bir şey anlatacak durumum yok bu sefer, sadece paylaşmak istedim.

Malumunuz ülkemizde kapanan web sitesi web sitesine.

Hal böyleyken artık türlü türlü tepkiler de doğmaya başladı. Bir tanesi de burada.

Geçen aylarda bir arkadaşımın şirketi web portallarını yaptıracak bir şirket arıyordu. Ankara dışında oldukları için sadece arada bir telefonla veya sohbet sırasında akıl veriyordum ve sonunda bir şirket buldular. Arkadaşımın aktardığı kadarı ile karı koca bilgisayar mühendisi bir ekibin işlettiği küçük bir şirketti.

Gel zaman git zaman, portalın yapılışı uzadıkça uzadı. Portal için hem oldukça kapsamlı bir güvenlik hem de çok çeşitli özellikleri bir arada isteyen arkadaşımı işin uzayabileceği konusunda uyarmıştım. Biraz da o yazılım müşterisi olarak acemi olduğundan işin uzamasına neden olabilir diye düşünüyordum. Ama bir gün bozuştuklarını aktardı. Tamam dedim sana başka bir servis sağlayıcı ayarlarız. Ne olacak ki değil mi? Ama kazın ayağı öyle değilmiş.

Önce arkadaşımın iş modeli için oldukça önemli olan müşteri bilgilerinin çalınmış olabileceği şüphesi ortaya çıktı. Daha sonra kişisel bilgisayarına uzaktan erişildiğini fark ettik. Bunları engelledikten sonra servis sağlayıcıyı değiştirmeye karar verdik. Arkadaşımda kaynak kodu bulunmadığı için portalın deneme sürümünü FTP'den erişerek çektik ve kurcalamaya karar verdik. Bu kurcalama işinin esas çoğunluğunu ben yapmadım ama durumun vehametini görecek kadar da kodlara baktım.

• Kapsamlı güvenlik modeli mümkün olduğunca çok sayfanın statik içeriğe sahip olmasına dayalıymış. Şirketin bir çok değişikliği elle yapmakta diretmesinde ve işi geç yapmasında neden buymuş.
• Sitenin içindeki bazı işlevsellikler başka sitelerdeki formların üzerinden yürütülüyormuş. Yani örneğin portalın kendisine ait bir eposta hizmeti yok. Başka bir sitedeki eposta atma formunu doldurup atıyor. O eposta formu da her türlü tacize açık - bu nedenle bağlandığı sunucu kısa sürede spam kara listelerine girebilir. Ayrıca formun olduğu alan adı da müstehcen içerik sunmakla meşgul bir site.
• Biz sistemin içini az çok temizledikten sonra arayüzleri kolay kullanılabilecek bir servis sağlayıcıdan barındırma hizmeti almasını sağlayıp sonra da portalın yamanmış halini orada devreye aldık.

Durum burada kalmadı tabi. İş elinden alınan şirket arkadaşı taciz edercesine arayıp sormaya başladı. Haliyle adamların da bir iş planı var ve aniden müşteri kaybetmek hoş olmuyor. Kabul ediyorum. Bununla birlikte, yaptıkları işe de biraz saygı göstermek gerekir. Bu arada arkadaş yaptığı avans ödemeler için fatura isteyince bir kaç şey daha çorap söküğü gibi geldi.

• Meğer bu karı kocanın web sitesindeki ticari ünvanda bir şirketleri yokmuş. Orada kullandıkları isim marka da değilmiş. Bir ahbaplarının şirketinden fatura kestirip idareten verebilirlermiş. Yani aslında serbest çalışıyorlarmış. Buna ancak "e anacım serbest çalışıyoruz desen olmaz mıydı" denir. Yani serbest çalışmanın kötü bir yanı yok ki. Hepi topu şirket olarak vereceği gelir vergisi yerine tahsilat makbuzundan stopaj adında vergi kesilecek, büyük işler söz konusu değilken çok da fark söz konusu değil.
• Ama daha kötüsü çıktı sonra. Arkadaşların bilgisayar mühendisi olması, "geniş anlamda" geçerliymiş. Yani aslında mühendis falan değillermiş. Bilgisayar ve yazılım işi yapınca kendiliklerinden mühendis oluvermişler. Diplomayı göster deyince yok ama zaten kim soruyor ki. Birden şunu anladım, doktorların duvara asması misali mühendisler de mi duvara asmalı diplomalarını. Aynı şekilde şirketlerin vergi levhaları vb evraklarını duvara asmaları da anlamlı oluverdi.

Şirketleşmeyi planlayan bir girişim başlarda bir süre idareten iş görebilir. Örneğin faturalarını şirket kurduktan sonra kesme sözü ile iş yapabilir. Bunları anlayışla karşılıyorum. Yani o kadar da mevzuatçı, evrakçı değilim - umarım olmam da. Ama bunu müşteriye söylemek gerekir - ki ürkerek söylememeyi dahi hoş görüyorum. Esas mesele ötekisi. Ortalıkta "geniş anlamda" mühendis olduğunu ifade etmek başka bir şey. Elbette yazılı bir şey yok. Sadece konuşurken yanlış bir ifade olmuş. Ama mühendislik ünvanı, hele bilgisayar mühendisliği gibi sabahlara kadar çalışılarak hak edilen bir ünvanı bu şekilde "geniş anlamda" sahiplenivermek çok farklı bir şey.

Eminim ki bu durumda bir sürü insan olabilir. Kötü niyet içermeyen, kendiliğinden gelişen yanlış anlaşmalar da olabilir. Ama düzeltmek gerek. Ben kendim sık sık yanlış ifade olunca "Bilgisayar Mühendisi değil Elektrik Elektronik Mühendisiyim" diyorum. Bir kaç ay önce yanlış aktarıldığını fark edince "Makina Mühendisi değilim" demem bile gerekli oldu. :)

Bu kadar basit bir konuyu yanlış aktarmakta sakınca görmeyen kişi projenizin neden aksadığı konusunu da çeşitli sebeplerle yanlış aktarmakta sakınca görmeyebilir değil mi? Müşterinize asla yalan söylememelisiniz. Çünkü bunu anladığı anda sizden temelli soğur.

Bakalım ara ara bu öykülere devam etmemi isteyenler çoğunlukta, biraz daha detay vermemi isteyenler var, yada tersi biraz daha az detay vermemi isteyenler var. Ama şunu farkettim bu "bodoslama" serisinde yazdıklarım okuyanlar için en az teknik bir şey yazmak kadar yararlı.

Başka bir şey okurken şans eseri Joel Spolsky'nin 2001'de nokta com balonu söndüğünde yaptığı yorumlardan birisine rastladım. Kendimce Türkçe'ye çevirmek istedim ve bir parçasını buraya yazasın geldi:

"Özür dilerim işibitmişşirket.com. Bir ay kadar bir süre için eğlenceliydin ama şimdi sadece acınılası bir durumdasın. Biz ürünümüzü iyileştirmekle uğraşacağız ve faaliyetimize devam etmeye çalışacağız. Bunu da müşterilerimizi dinleyerek ve kendi ürettiklerimizi kullanarak yapacağız; risk sermayesi bulmak için ülkenin dört her yanına uçakla gidip gelerek değil. "

Herhangi bir kişi yok aklımda. Herhalde Joel Spolsky'nin de yoktu. Ama hitap tarzındaki sertliği bir kenara koyarsak, ifade edilen bakış açısı, yaklaşım net. İşini yapan, işini daha iyi yapmak için çabalayan, daima hayatta kalır.

Ölçümbilim (metroloji) bazılarının bildiği gibi bir şeyi nasıl doğru biliriz üzerine kurulu koca bir bilim dalı. Ölçüm çok önemli çünkü ölçemediğiniz şey üzerinde net fikir yürütemiyorsunuz. Net fikir yürütemediğiniz şey hakkında da karar alamıyorsunuz.

Yazılım projeleri de bundan muaf değil. Eğer bir yazılım projenizin nasıl gittiğini sorarlarsa ve iyi derseniz arkasından size neden bu yanıtı verdin diye sorabilirler. Bunun bir ölçümü olması gerekli. Elbette ki nihai ölçüm memnun müşterilerdir ama acaba aynı memnun müşterileri elde etmenin daha iyi bir yolu olamaz mı? İşte sayısal değerleri kullanarak proje yönetmek yada projelerin giderek daha iyi yürümesi için süreç iyileştirme yapmak gibi amaçlarınız olunca siz de eliniz mahkum bir şeyleri ölçmek durumundasınız.

Bu açıdan bakınca yazılım ölçümünü (İng. software metric) bir yazılımın yada yazılım projesinin ölçebildiğimiz herhangi bir özelliği olarak tanımlayabiliriz. Örneğin ben yazılımcıların stres seviyesini ölçmek istesem - ki bu aslında uyku seviyesi, kandaki adrenalin, kan basıncı, nabız gibi tıbbi ölçümlerden çıkartabilecek bir şey - buna da "yumurta kapı indeksi" desem bu da bir ölçüm olacaktır.

Tabii yumurta kapı indeksini almak ne fayda sağlayacak sorusu ortaya çıkacak. Demek ki, bir ölçüm ancak bir şeye yararlı olacaksa alınmalı. Yani neyi ölçeceğimi düşünmekten önce neden ölçeceğimi düşünmek gerekli. Eğer yumurta kapı indeksine dayanarak bir karar alacaksak ve bu projeye yararlı bir işe yarayacaksa o zaman yumurta kapı indeksini ölçmek anlamlıdır.

Peki insanlar ne gibi şeyleri ölçmeyi anlamlı bulmuşlar? İlk akla gelen ölçümler şu türde ölçümler

• Yazılan satır sayısı bir projenin büyüklüğü için geçerli bir ölçüm. Elbette bunu elma ile armutu karşılaştırmadan yapmak gerekli. Çünkü özellikle bileşen tabanlı çalışılan araçlarda, bir bileşenin nasıl kullanılacağını belirlemek, onun çevresi ile olan etkileşimini ayarlamak gibi işlemler çok fazla satır üretmese dahi çok fazla zaman alabiliyor. Bu nedenle bir Python projesinin satır sayısı ile bir diğer Python projesini karşılaştırmak anlamlı. Benzeri biçimde bir iş yazılımı bir diğer iş yazılımı, bir gömülü yazılım da bir başka gömülü yazılım ile karşılaştırılabilir. Bu ön kabulü yapmadan, satır sayısı (line of code - LOC) ölçümünü temel alan diğer ölçümleri tartışmak anlamını yitiriyor.
• Satır sayısından sonra en çok tartışılan ama en çok referans alınan ikinci ölçüm de kodun karmaşıklığı üzerine. Kodun karmaşıklığı (İng. cyclomatic complexity) o kodun bakımının ne kadar zor olduğunu ortaya koyduğu için önemli. Karmaşıklığı yüksek kod parçalarını tespit edip daha sonra bunları daha anlaşılır ve daha kolay bakım yapılır kodlarla değiştirmek de önemli. Bu karmaşıklık oldukça karmaşık bir matematiksel teknik ile hesaplanıyor. Ancak bize çok basit bir sonuç veriyor. Bir kod parçasını test etmek için biribirinden bağımsız en az kaç test durumu (İng. test case) yazmamız gerektiğini bu karmaşıklık ölçümünden öğrenebiliriz. Elbette hiç bir ölçüm bize bu testlerin hangileri olduğunu söylemez yada iki testin bağımlılığını nasıl saptayacağımızı belirtmez. Ama en azından bir sayıyı elde etmiş oluruz.
• Satır sayısından elde ettiğimiz bir diğer türetilmiş ölçüm de her bin satır (KLOC) başına düşen hata (bug) sayısıdır. Örneğin 100 KLOC uzunluğunda ve her KLOC başına tespit edilen 1.2 hata düşen bir projede 120 tane hata olduğunu anlamış oluruz. Burada önemli bir şey de bu sayının bir yerden sonra kestirilebilir olduğudur. Örneğin 80 KLOC uzunluğu için 1.2 hata bölü KLOC metriğini elde etmiş isek, ve projenin 120 KLOC'a büyüyeceğini de (başka bir şekilde) tahmin ediyorsak, o zaman geri kalan zamanda 120 - 96 = 24 tane daha hata olacağını tahmin edebiliriz. Bu da bizi bir anlamda hazır kılar.
• Hazır hata demişken. Bir hata tespit edildiğinde onu düzeltmenin ne kadar zaman aldığı da önemli bir ölçüm olabilir. Buradaki zaman harcanan zaman değil, hatanın tespitinden kapatıldığının test edilerek onaylandığı zamana kadar geçen süreyi kast ediyoruz. Yani belki bir hatayı düzeltmek için yapılan iş 1 saat almıştır ama o 1 saatin gelmesi için 2 ay beklenmiş olabilir. Bu durumda hata 2 ay açık kaldığına göre, ortalama çıkartılırken de bu 2 ay göze alınmalıdır. Bu tür bir ölçümün o hatadan etkilenen insan sayısı, hatanın önemi gibi sayılarla çarpılarak ağırlıklandırılmış biçimde kullanılması da mümkün olabilir. Ama benim gördüğüm hata takip sistemleri düz zaman ortalamasını veriyor.
• Hatanın kapatıldığının onaylanması demişken test sözcüğünü kullandım. Madem test yapıyoruz, acaba testler toplam geliştirme zamanının ne kadarını alıyor? Bunu ölçebilir miyiz? Örneğin bir sistemin entegrasyon ve kabul testlerini işletmek 12 saat alıyorsa ve bu süre pek de inecek gibi değilse o zaman bizim için günlük inşa almak anlamlı olmaz. Çünkü işin felsefesi gereği günlük inşa, her gün alınır ve kabul testinden geçer. O zaman haftalık inşa almaya karar verebiliriz. Bakın bir ölçümü kullanarak bir karar verdik.

Benim için önemli bir ölçüm de ölçüm yapmanın maliyeti ile ölçüm yaparak kazanılanların oranı. Eğer bu oran 1'den küçükse, maliyetin, faydadan az olduğunu görüyoruz. Bu da ölçüm yaparak kazanç elde ettiğimizi gösteriyor. Eğer bu oran 1'den büyükse, bu sefer acaba ölçüm yapmasak ne olurdu sorusunu sormak mümkün.

Hemen kısaca özgür yazılımlara değinecek olursak durum nedir? Sourceforge gibi siteler, aslında özgür yazılım projelerine çeşitli ölçüm becerileri veriyorlar. Ancak bu becerilerin ne derece kullanıldığından emin değilim. Apache projeleri gibi daha sağlam yürütülen projelerde ise ölçüm alınması ve değerlendirilmesi rutin bir iş. Yani bir heterojenlik söz konusu. Öte yandan ticari yazılım projelerine baktığımız zaman da kapalı kapılar ardında kimin ne derece ölçüm yaptığı da tartışılır.

TVQ içinde makul miktarda ölçüm becerileri için iki iterasyon - yani dört ay - süre olacak. İterasyon planına gelmeden önce, gereksinim belirleme aşamasında bu ölçümler hakkında tek tek tartışıp bir sürü fikir üreteceğiz. Ekiptekiler de bloglarından mümkün olduğunca bu fikirleri paylaşacaklar. Bakalım - hayırlısı diyelim.

Malum bu aralar Erhan Ekici ile ben karşılıklı blog yazarak bir nevi proje yönetimi aşık atışması yapıyoruz. :) Geçenlerde onun bir diğer blog girdisine yorum yazarken, hümanist bir proje yöneticisi ve bunu anlayabilecek nitelikte bir proje ekibinden bahsetmiştim. Erhan da bir diğer girdisinde bu idealde var olan hümanist proje yöneticisini irdelemişti.

Ben de el değmişken bu sefer bu yöneticinin ekibi nasıl olmalı diye laf gevelemek istedim. Ama bu sefer biraz tembellik edip kopya çekeceğim. Kopyamı Alistair Cockburn'den çekeceğimi de utanmadan sıkılmadan belirteceğim. Cockburn'ün (İskoçca'da okunuşu ka-bürn gibi bir şey) geliştirdiği Crystal serisi yöntembilimlerden en küçük boy ekiplere uygun olan Crystal Clear, yönteminde ekiple ilgili bazı ön kabuller yapmış. Bu kabuller neler?

• İnsanlar iletişim kuran varlıklardır. Bunu da en iyi gerçekten yüz yüze gelerek yaparlar.
• İnsanlar zaman içinde sürekli tutarlı davranmakta zorluk çekerler.
• İnsanların bir günü öbürüne uymayabilir.
• İnsanlar genellikle iyi niyetlidir ve projenin ilerlemesi için gerekeni yapmaya çalışırlar.

İşte buradan hareketle, Cockburn bu kabullere dayanan bazı proje yönetim yaklaşımları geliştirmiş.

Bu dört ön kabul çevremizdeki her iş yerinde tutuyor mudur acaba? Ne dersiniz?

Apple iPhone 3G, bugün piyasaya çıkacakmış. Apple her ülkede nereden alınır konulu birer sayfa yapmıştı. Bugün kontrol ettiğimde Türkiye sayfası'nda Vodafone ve Turkcell'e bağlantılar gördüm. İki operatör daha önceden ön başvuru toplamışlardı. Ben de 16GB siyah bir iPhone 3G için başvurmuştum. Bakalım bugünlerde geri arayacaklar mı? Dememe kalmadı Turkcell'den "gelin dükkanlardan alın" diye bir SMS geldi.

Esas merak ettiğim şeylerden birisi de bu zaten. Apple olağan üstü bir pazarlama çalışması ile iPhone'un ABD satışlarını patlatmıştı. iPhone 3G için de önemli bir beklenti var. Gel gelelim bunun dünyanın bir sürü yerinde satışını organize ederken aynı başarı yok. Kitle iletişimine, televizyon reklamlarına, İnternet sitelerine ne kadar güvenirsek güvenelim, eğer bir malın yada hizmetin satışı bildiğimiz dükkanlardan yapılacaksa o zaman ikisi arasında bir uyum olması gerekli değil mi?

Yaz ayları içinde TOBB ETÜ'den gelen üç uzun süreli stajyerimiz, Halil'in koordinasyonu altında, TVQ'nun belli bölümleri için çalışıp oldukça güzel çalışan bir görev yönetimi sistemi kurmuştu. Daha sonra da ODTÜ Bilgisayar Mühendisliği'nden gelen stajyerlerimiz bazı grafik öğelerin, örneğin bir Gannt şemasının kurgulanması için uğraşmışlardı.

Halil bir kaç haftadır diğer işlerinin arasında TVQ'nun var olan kodlarını temizledi ve düzenledi. Şu anda örnek bir Struts2 / Hibernate uygulaması olmuş durumda. Önümüzdeki günlerde SVN'deki kopyasını genel erişime açacağız. Böylece küçük de olsa bir özgür yazılım hayata geçmiş olacak.

Bununla birlikte TVQ cephesindeki esas gelişme önümüzdeki 15 ay içinde yaşanacak. Yaz aylarındaki deneyimimizden elde ettiğimiz bilgiler ile çok daha kapsamlı bir geliştirme projesini ölçüp biçerek kestirme şansımız oldu. Toplam 75 adam-ay maliyeti olacağını öngördüğümüz, bir geliştirme projesi olarak TVQ'yu daha kapsamlı bir hale getireceğiz.

TVQ böylece bizim kendi içimizdeki yazılım mühendisliği ve yönetimi girişimimiz için bir bayrak gemisi ürün haline gelirken (böylece kendi içimizde yazılım mühendisliği alıcı bulurken), özgür yazılım ürünleri arasında doğrudan yazılım kalitesine dönük araç eksikliğini de giderecek. Projeye resmi başlangıcı Ekim ayı başında, Ramazan Bayramı dönüşü vereceğiz. Projenin kendi yürütülmesi için kendi iç ağımızdaki araçlara ek olarak, kullanıcılar, katkıcılar ve dışarıdan destek verebilecek olan geliştiriciler için ayrı bir site ve arayüzleri de Ekim - Kasım aylarında devreye alacağız. Aynı arayüzler içinde TVQ'nun periyodik inşalarını da alıp kurmak mümkün olacak. Şimdilik herhalde haftalık inşa alırız. Daha sonra projedeki Maven işleri oturdukça, yavaş yavaş gecelik inşaya kadar ilerleriz.

Bu arada TVQ'nun test edilmesi sırasında oldukça kapsamlı test durumları yazmayı planlıyoruz. Bu durumların test edilmesi için test planlaması ve işletimini de dikkatli yürütmek gerekli. Daha önce kullanmadığımız bir iki Alphaworks ve Tigris projesi kullansak fena olmaz.

TVQ konusunda önümüzdeki aylarda benden, Halil'den ama henüz bloglarını çok da aktif kullanmayan Cansu ve Billur'dan yada Gülşah'dan da çok yazı görebilirsiniz. Bakalım. hayırlısı diyelim.