Yazılım kariyerimin yaklaşık 2 yılında freelance çalıştım. Bu yazıyı yazmamın amacı bugünlerde çevremde bana yöneltilen sorulara toptan bir cevap vermek. Özünde ülkemizde problemli durumda olan bu çalışma yönteminin yazılım geliştirici yanını ele alacağım. Doğal olarak bu gözden bakacağım. Tabi ki diğer taraftan bakınca da yazılım geliştiricilerden kaynaklanan problemler vardır, ama nihayetinde ben kendi açımdan konuyu ele alacağım. Ve çok kere yerli yazılım uzmanları ile problem yaşayanların, yüzlerini görmedikleri bir Hintli ile mucizevi bir disiplin içinde çalıştığına şahit olmuşumdur:) Yani yerli yazılım uzmanlarını sömürmeye çalışırken, yabancı bir yazılım uzmanına bir renk değişikliği bile yaptıramayıp yine de mutlu olmaları ve bundan bahsederken (adamlar çok disiplinli, ciddi yaklaşıyorlar vb) büyük bir keyif almaları hep ilgimi çekmiştir.

Konuyu çeşitli başlıklarda ele alacağım.

1. Proje Analizi

Ne olursa olsun amaç projeyi tamamlamak ve paramızı tam olarak almak ise, en küçük bir işte dahi proje analizine ihtiyacımız var. Proje analizi kafadan hayal kurularak yapılan bir eylem değildir. Kağıt ve kaleme dayanır. Nihayetinde bir fiyatlandırma politikası da oluşturur.  Sizden bir müşteriniz acele fiyat dahi istese çekinmeden kağıt kalemi alıp özet bir proje planı hazırlayabilirsiniz.

Bu plan için çeşitli araçlar kullanabilirsiniz. Örneğin:

Mind Map: Zihin haritası dediğimiz bu teknik ile karışık bir projeyi okunabilir hale getirip, yazılımla ilgilenmeyen bir kişi ile dahi tartışabilirsiniz. MindMeister.com, XMind, MindJet gibi farklı araçları kullanabilirsiniz. Kesinlikle kullanılmalı…

Excel: Özellikle proje sürecini yansıtmada ve ödeme takvimi için kolay anlaşılabilir bir araç olarak kullanılabilir.

ZOHO: zoho.com‘ dan ulaşacağınız güçlü hizmetler ile bir çok işinizi tek merkezde halledebilirsiniz. Zoho Business üyesi olarak 10 kullanıcıya kadar ücretsiz yararlanabilirsiniz. E-Posta, Writer (Word benzeri bir uygulama), Sheet (Excel benzeri bir araç), Task, Show (ower Point aracı), Notebook (Proje notlarını ve planlamasını yapabilirsiniz), PM (Proje yönetim aracı) ve daha bir çok web tabanlı uygulamayı kendi yararınıza kullanabilirsiniz.

Zamanla bu ve benzeri araçlarla kendinize bir proje analiz kültürü oluşturmakta ve bu kültürü sürekli güncel tutmakta fayda var. Yazılım süreci sanıldığının aksine çok karmaşık ve çok çok zor iştir. Bu iş yükümüzü mümkün olduğunca iyi analiz etmeli ve müşterimizle paylaşmalıyız. Bilgisayar karşısında oturarak 2 saatte yapılan bir eylem gibi algılandığında, hiç bir proje karşılıklı fayda ile bitirilemez.

Proje analiz sürecinde yapılacakları şu şekilde sıralayabiliriz.

Tüm proje en ince noktasına kadar analiz edilmeli

Bu adım aslında aldığımız bir işte sürecin kapsamının tam olarak sınırlarını çizer. Projeye başlamadan önce müşterimiz ile bu sınırlar üzerinde mutabık kalır ve planın bir örneğini de onaylatır sanız sorun yaşama olasılığı düşer. İnanın her projede müşterimizin aklına, yatağına yatınca ekstra fikirler gelir, buna çok müsait bir iş dalıdır yazılım, ama biz de projeperestlik yapıp bu fikirleri düşüncesizce uygulamaya kalkarsak ne kendimiz mutlu oluruz ne de müşterimiz. Burada kilit nokta, projemizi modüler (geliştirilebilir) bir yapıda tasarlayıp yeni isterleri müsait bir dille, ekstra bir faza atmaktır. Tabi belkide projeyi altüst edecek, iş yükünü veya süresini arttıracak bu istekleri müşteriniz mevcut sürece dahil etmeye çalışabilir. O zaman yapılması gereken, analiz dokümanını çıkarıp projeyi yeniden şekillendirmek ve fiyat değişikliğini açıkça bildirmektir.  Girişimci ve yazılım uzmanları asla pısırık olmamalı, sonra zaten kısa olan ömürlerini boşa harcamış olurlar. Zaten proje analizinin ana amacıda bir net duruş göstermek ve projeye karşı saygı uyandırmaktır.

Tasarım netleştirilmeli

Zorlu ama gerçekten çok çok gerekli bir adımdır. Özellikle daha önce bir web sitesi ya da proje yazdırmamış kişiler aşırı derece de kararsız olabilirler. Siz tasarım netleştirmeden bir projeye başladığınızda, müşteriniz bir arkadaşından aldığı bir eleştiriyi veya tavsiyeyi, sanki projenin tamamı yanlışmış gibi yanlış bir ifade tarzı ile anlatabilir. Öncelikle bu gibi durumlarda sakin olmalı ve müşterinizi de endişelendirmeden dinleyerek, doğru veya yanlış yönleri gerekirse uzun uzun anlatmalısınız. Bir çok kez müşterinizin bir arkadaşı, ya da belli bir zamanda birlikte olduğu 3. bir kişi sizin emeğinizi bir anda yok sayıp, çay ya da sigara sohbetinde harcayabilir. Tüm alt sayfaları ile baştan belirlenmiş bir proje tasarımı sizi bir çok tehlikeden kurtarabilir.

Ekstra durumlar belirtilmeli

Projelerin büyük bir çoğunluğu bu ekstra durumlar nedeniyle yok olur gider.  Bir yazılım uzmanı için ekstra durumlar ne kadar büyük bir problemse, müşteriniz için de o denli önemsiz olabilir. Bazen bu ekstra durumlar nedeniyle başladığınız gecekondu inşaatı, 2-3 katlı temelleri sağlam atılmamış bir apartmana dönüşebilir. Unutmayın ki bu bina çökerse tek günah keçisi siz olabilirsiniz.İşinizi sağlama alın. “İş başka, aşk başkadır”

Kapasite belirlenmeli

Her uygulama belli bir kapasitede çalışması için dizayn edilir.  Bunu belirleyen sınırlar, veritabanı yazılımı ya da boyutu, server donanım özellikleri, server bant genişliği vb olabilir. Burada sorumluluk tamamen size ait. Belli kullanıcı sayıları ile bu değişkenleri eşleyip bir plan hazırlamalısınız. Böylece müşteriniz hangi hangi durumda nasıl bir yatırım yapması gerektiğini bilir. Tabi bu limitleri belirlerken %10′luk bir tolerans koymayı unutmayın.

Platform Belirlenmeli

Yazdığını uygulama hangi tip serverda çalışır, hangi tarayıcılara destek verir, gerektiğinde client’ lar da hangi programlar kurulu olmalıdır. Bunları net olarak belirtmeli ve mümkünse yazılımınız kendisi bu kısıtlar haricinde uyarı mesajı vermelidir. Örneğin yaptığınız bir web sitesi altyapı olarak AJAX teknolojilerine bağımlı ise ve başlangıçta IE6 desteği vermeyeceğinizi müşteriniz ile konuştuysanız, ilk girişte browser versiyonunu kontrol edip kullanıcıyı yeni tip tarayıcılara yöneltmekte ve durumu uygun bir dille açıklamakta büyük fayda vardır.

Çalışacak kişi sayısı belirlenmeli

Eğer sizden başka kişilerinde çalışması gerekecekse bunu açıkça ortaya koymanızda fayda var. Böylece ücretlendirme ve proje takvimi daha net belirlenir. Eğer projenize farklı kişileri de dahil edecekseniz proje süresini %10 arttırmakta fayda var. Ve mümkün olduğunca proje temel yapısını siz tasarlayıp kodlamalısınız.

Gerekli belge ve dökümanlar belirlenmeli

Özel geliştirilen bir yazılım projesi “paket uygulama” değildir. Bu çok yanlış bir tabirdir. Bu proje sahibi yaşadığı sürece ya da sahibinin beyninde canlı kaldığı sürece hayatta olacaktır ve büyüyecektir. Her yazılım uzmanının proje geliştirdiği her sektörde uzman olması söz konusu olamaz. Mutlaka içerik yönetimi ve hesaplama araçlarının sonuç kontrollerini uzman müşteri temsilcisi (müşteriniz tarafındaki) yapmalıdır.  Bu amaçla oluşturulacak içeriğin sorumluluğu her zaman müşteri dedir.

Karşılıklı görevler paylaştırılmalı

Bir proje her zaman bir ekiple bitirilir. Tek başına proje bitirmek imkansızdır. Bu nedenle müşteri, test ekibi, saha kullanıcıları gibi görev kademeleri belirlenip hangi aşamada kime ihtiyaç duyulduğu netleştirilmeli.

2. İş Planı

Sevdiğim bir söz: “İş planı hazırlamak, bilim kurgu alt türüdür.”

Kesinlikle bu kadar senelik tecrübeme dayanarak doğru diyebileceğim bir sözdür. Öncelikle Plan kavramını kendi hayatımıza oturtmamız gerekiyor. Bu kadar zor bir meslek yaparken, Amerikan filmlerindeki dağınık, ayyaş, kendinden geçmiş yazılımcı tiplerine aldanmamak gerekir. Bunların hepsi yalan. Ne kadar zeki olursanız olun o tiplemelerin altından başarı çıkmaz.(Başarı=Bitmiş proje) Belki 2-3 numara yapabilirsiniz, sohbetlerde güzel konuşmacı olabilirsiniz ama önemli olan kişisel markanızın ticari değeri olup olmadığıdır.

Kısaca iş planı kesinlikle gerekli. Yine kağıt kalemle yapılan bir eylemdir. Yukarıda saydığımız araçları kullanabilirsiniz.

Acil eylem planı yapın

Acil eylem planı nedir? Ekstra durumlar için yapılan B,C,D,E,…. planlarıdır. Madem bu kadar zor ve riskli bir iş yapıyorsunuz her zaman projeye özel veya genel acil eylem planlarınız olmalı. Öncelikle bu eylem planlarını oluştururken, proje süresinin gece ve gündüz birlikte hesaplanarak verilmemiş olması çok önemli. Her zaman insani bir çalışma temposu içermeyen süre belirlemeleri kriz yaratır. İş hayatımda bazı yöneticilerimin gece ve gündür birlikte hesap ederek iş planı yaptıklarını gördüm ve inanın hepsi başarısız oldu ya da istenilen verimde ürünler olmadı.

Takvim aksama raporu çıkarın

Bir projedeki en ufak pürüz takvimi aksatır. Geç başvurulan bir hosting üyeliği, gerekli belge ya da dokümanların gelmemesi, geç gelen tasarım ögeleri, geç gelen müşteri onayları. Bu süreçleri en ince noktasına kadar takvime yansıtmakta fayda var. Örneğin siz veritabanı tasarımını bitirdikten sonra 10 Mart’ ta tasarımın hazır ve onaylanmış olacağını düşünerek bir plan yapmışsanız ancak tasarım gelmemişse, ya tasarım gelinceye kadar geçecek sürenin takvimi öteleyeceğini belirtmeli ya da bu olasılığı düşünüp tasarım 10 Mart’ta hazır olmazsa 5 günlük veritabanı bağlantı class’larının yazılmasına geçileceğini ve ardından tekrar tasarıma ihtiyaç duyulacağını belirtmelisiniz.  Burada küçük bir not düşmek gerekirse takvim başlangıçta tarihlere bağımlı olmamalı. Süreler gün ve hafta olarak verilmelidir. Tabi olabilecek tatil ve yıllık izinlerde hesap edilmeli. Tatilde yazarım gibi yaklaşımlardan kaçınılmalıdır. Yüksek ihtimal o tatiller sadece size ait değil, aile ve dostlarınızla ortaktır.

Görev ve sorumluluklar açıkça belirtilmeli

Planladığınız gecekondunun apartman olarak ortaya çıkmaması için müşterinize sizin tam olarak hangi görev ve sorumlulukları yerine getireceğiniz belirtilmeli. Örneğin projenin adisyon kesme bölümü için bir demo yazıcıya ihtiyacınız varsa bunun hazır olmasını sağlamak müşterinizin görevi olabilir ve proje başlangıcından sonra hangi tarihte ihtiyaç duyacağınızı açık ve net olarak ortaya koymalısınız. Baştan projeyi almak için “belki şuradan bir printer ödünç alırım” ya da bir emulator bulur denerim gibi yaklaşımlara hiç girmemek lazımdır. Hem zaten mümkün olduğunca gerçek ortamda kullanılacak cihazlarla projeyi test etmelisiniz.

3. 3.Parti Etkenler

İşte başınız çok ağrıtacak bir başlık. Zamanında benim başım gerçekten ağrımıştı. Nedir bu etkenler? Hosting firması, diğer çalışma arkadaşlarınız, 3.parti veri sağlayan firmalar, donanım sağlayıcılar vs vs.

En basitinden örnek vermek gerekirse bir hosting firmasının harddiskinin yanması ve müşterinizin girdiği dataların kaybolması başınızı gerçekten ağrıtabilir.  Müşteriniz bu durumda bir günah keçisi arayacak ve çoğunlukla bu sorumluluğun satın aldığı hosting servisinde olduğunu bilmeden sizin yazılım nedeniyle bu kaybın yaşandığını düşünecektir. Bu nedenle başlangıçta 3.parti kişi ve kurumların görevleri muhatabınıza ÖĞRETİLMELİ.

Özellikle backup seçenekleri konusunda müşterinizi yönlendirmenizde fayda var. Tabi backup sadece serverda değil sizim çalıştığınız makinada da gereklidir. Sonuna gelmiş bir projenin kodlarının bozulması ya da silinmesi hayatınızı kabusa çevirebilir. Bu noktada çeşitli ücretli veya ücretsiz servisler çok işinize yarayabilir. Ben şahsen Microsoft Live Mesh kullanıyorum. İncelemenizde fayda var.

4. Hukuki Altyapı

Bu kadar emek verdiğiniz bir proje üzerindeki haklarınızı kesinlikle korumanız gerekmektedir. Burada kastettiğim yazılım kodları değil. Bence bir yazılım projesindeki en değersiz materyal yazılımın kodlarıdır.   Asıl bahsettiğim ve korunması gereken sizin emeğinizdir. Bu emeğin karşılığını almak için kendinizi hukuki olarak koruma altına almalısınız. Basit bir a4 üzerinde yazılan bir sözleşme dahi bunun için yeterli olacaktır. Piyasada başka iş yapacak müşteri yokmuş gibi bir yaklaşım sizi zaman zaman belli kişilere köle yapabilir.

5. Ödeme Takvimi

Ben ilk freelance çalıştığım sıralarda baştan bir güven oluşması amacıyla peşin ödeme almazdım. Bir takım kulakları çınla yası kişiler bunu kullanmak istediler. Kesinlikle karşı tarafa da CİDDİ bir iş yaptığını hatırlatmak adına bu ödeme alınmalı. Maksimum %40 seviyede bir ön ödeme her iki tarafa da bir iş disiplini getirecektir. Zaten bir yazılım projesine gönül vermiş bir kişinin bu ödemeyi rahatlıkla yapacağını düşünüyorum. Çok önemli bir husus fiyatlandırma dır. Daha sonrada emeğinizi almadığınız fikrine neden olacak bir miktar ya da sonraya bırakılan bir ödeme %90 başarısızlıkla sonuçlanlanacak bir proje gerektirir.

6. Tehlikeli Cümleler

Özellikle yeni iseniz bu cümlelerden kaçının:

• Biz sana daha çok müşteri buluruz…
• Daha çok iş yapacağız…
• Bu iş bir tutarsa…
• 1-2 aya uçuracağız bu projeyi…
• Bu sitenin aynısından yaptıracak en az 5 kişi var…
• Param yok beni idare et…
• Ben de para kazanmayacağım bu işten…
• Çok beklentimiz yok zaten bu projeden,… mecburiyetten…
• Ortak olalım!

Son Söz

Kişisel tecrübelerime dayanarak yazdığım bir yazı oldu bu iş. Hem kendimin hem de ilgili muhatapların kulağına küpe olmasını diliyorum bunların. Ben dahi yakın zamanda belki dostluk ilişkilerine güvenerek bazı hatalara düşebiliyorum. Çalıştığımız insanlar isteyerek ya da istemeyerek kendilerinden beklenmeyecek şekilde davranabiliyorlar. %100 olmasa da büyük oranda sizin yararınıza gelişecek bir proje süreci için yazdım bunları. Özellikle dostluk ve akrabalık bu kuralları yok saydırabiliyor ya da esnetebiliyor. İşin ilginç yanı bu dostluk ve akrabalık ilişkilerini bozmamak için bu kurallara %100 uyulması gerektiğini düşünüyorum.

Proje Koordinatörü olarak çalışıyorum….

Doğal olarak 1 yılda 10′ larca proje elimden geçiyor. Nasıl başarılı olur nasıl olmaz bir film izler gibi görüyorum. Yakın arkadaşlarımdan Ali Bülbül ile bazen konuştuğumuz bir konu var.

Kimi girişim sahiplerinin, e-tohum vb toplantılarda  paraya gerek yok şeklinde ahkam kesmeleri, ülkemizde başarılı olması muhtemel kişileri yanlış yönlendirdiği kanaatindeyim.

Burada baştan belirtelim, babası dedesi, hastahane, tekstil atölyesi sahibi olan arkadaşlar için zaten bir sorun olmaz. Ama e-tohum’da söz alan kişiler zenginlik seviyesi belirtmediğine göre, Samsun’ dan, Adana’ dan, Ordu’ dan gelen çocukta bu öğütlerle muhattap.

Bir girişim için ne gerekli? Bir internet girişimi…

• Yazılım
• Hosting
• Tasarım
• Domain
• Lisans
• Yemek
• Ulaşım
• Telefon Konuşmaları
• Bilgisayar
• Internet Bağlantısı
• Cafe buluşmaları

evet en temel kalemler bunlar. Bu kalemlerden ücretsiz elde edebilecekleriniz ve edemeyecekleriniz var.
Ama tamamı bedava değil. Bu maddelerin çoğu günlük yaşam süreci içinde ortak kullanabileceğimiz şeyler.
Yazılımını ve tasarımını kendisi yapan bir 2 arkadaşın maaliyet tablosu nasıl olur:

• Hosting – 100 TL
• Domain – 15 TL
• Yemek – 30*12*10 TL
• Ulaşım – 30*12*5 TL
• Telefon – 12*20 TL
• Internet – 12* 30TL
• Bilgisayar – 2*1000 TL

Çok çok minimal bir hesap. Yıllık ya da ilk yıl 8.115 TL minumum bir paraya ihtiyaç var.

Tabi yazılım ve tasarımı dışarıya yaptırmanız, lisanslı ürün kullanmanız gibi durumlarda bu rakam en 30.000 TL olacaktır.
Ek olarak projeyi yapmakla da bitmediği için projeden sonraki pazarlama ve yazılımın daha kaliteli bir hosting ya da servera taşınması maliyetleri arttıracaktır.
Bu maliyetlere ek olarak, bir işte çalışmayarak kaybettiğiniz maaş ve sosyal haklarda eklenirse, “girişim için paraya ihtiyaç yok ” anlamsız kalır.

Ne yapmalı?

Sizi destekleyecek bir aile bireyi, öğrenciler için bulunmaz fırsattır. Diğer türlü belli bir süre piyasada çalışıp sizin fikirlerinize değer veren ve çevresi olan arkadaşlar edinmeniz de bulunmaz fırsatlar yaratır.
Fakat bu noktada uyanık olmakta fayda var, sizin fikilerinizi kullanmak isteyen insanlar kesinlikle çıkacaktır.
Başarılı girişimler….

Senin Mesleğin Nedir?

Belki de bir yazılım uzmanı ya da tasarımcının en çok zorlandığı şey, özellikle memleketinde ya da aile içinde mesleğini söylemektir. İçinde bilgisayar geçen bir iş tanımında bizim insanımızın anladığı genellikle bilgisayar satış ve tamiratı oluyor. Gerçekten hala meslek tanımlamada zorlanılan durumlarla karşılaşmak mümkün. 

En Güzel İş Bilgisayarcılık!

Bu yazıya bir süre ara vermiştim. Bir vesileyle ortaokul ve liselilerin olduğu bir ortamda mesleklerle alakalı sohbetler oldu. En çok dikkatimi çeken şey gençlerin “bilgisayarcılık” işini çok rahat ve akşama kadar oturulan bir meslek olarak görmeleri.

Sonuç olarak bu mesleği yapan herkes bilir ki gerçekten zor ve zahmetlidir. Konunun özüne dönersek, ukalalık ve kafasına göre çalışma durumuna. Bunu bu kişilerle çalışanların kesinlikle kabullenmesi gerekir. Bu mesleğin özü, zihinsel faaliyetlerin parmaklarla nakşedlmesi olduğu için doğal bir ukalalık ve çalışma yöntemi kaçınılmaz.

Ukalalık tanımının özünde, insanların bizlerin konuştuklarını anlamaması yatıyor. Eğer bir tarafın konuştuğu, ortamdakiler tarafından anlaşılmazsa, bu kişi diğerleri açısından ya saygın biridir ya da ukaladır! Ben konunun özüne bu şekilde bakıyorum, isteyerek ve kasıtlı yapılmış bir hareket olarak görmüyorum.

İlham! konusu da diğer doğal bir sonuçtur. Özellikle yaratıcı faaliyetlerin zorlamayla ortaya çıkması mümkün değil. Bir ressamın kafasına silah dayayarak, şahaserler yapmasını bekleyemezsiniz.  Bu “Programcılık Sanatı” çinde böyledir.

Bu işin br çözümü yok, zamanla tarafların birbirini anlaması ve empati kurması sonucu, tahmin edilesi davranışların benimsenmesi ile çözülemeyecek sorun göremiyorum.

Baştan bilmekte fayda var. Türkiye’ de Yazılım ve buna bağlı kollar bir sektör değildir. Ticaret odasında sektör olarak ayrı geçmez. Türkiye’ de yazılım ile ilgili standartlar yoktur.(/Dünya standartları bilinmez,uygulanmaz)

Durum böyle olunca bir çok alt birimi bünyesinde barındıran yazılım sektöründe, bu birimlerin varlıkları ve bu birimlerde görev yapanların ünvanları kayıptır. Bu da çoğu projede bir görev karmaşası oluşturur.

Yazılımda Görev Tanımları Neden Net Olmalıdır?

Bu iş ve süreçleri doğal olarak zor bir süreç olduğundan en ufak karmaşa bile işin/projenin gidişatına balta vurur. Bu işin tamamı yüksek oranda beyin eforu ve odaklanma gerektirdiği için, kanıtlanmış insan beyni teorilerine göre, beyin sadece ve net ortamda daha sağlıklı karar verebilmekte ve bireyler verimli olabilmektedirler.Şimdi yazılım alt birimleri ve yardımcı brimleri arasındaki karmaşa nedenlerine bakalım.

Yazılım Uzmanı-Tasarımcı İlişkişi

İşte sürekli tartışılan bir ikili. Biri yuvarlak tasarımlar yaptıkça diğeri isyanları oynardı 10 sene önce. Ek olarak 10 sene önce tasarımcılar kendilerini daha çok bir desinatör olarak görür html, css yapısına karışmazlardı. Bu zamanlarda programcılık,  windows tabanlı ilerlediği için programcılar da html ve css kodlamasına girmek istemezlerdi.

Bugün her iki kesim de html ve css işine girmek zorundalar. Artık desinatör tasarımcılardan Web Master tasarımcılara bir geçiş yaşadık. Win. programlamadan web programlamaya da bir geçişte kaçınılmaz oldu ve her iki taraf html ve css paydasında ortak çalışablir duruma geldi. 

Genel olarak tecrübelerime baktığımda desinatör ruhlu tasarımcıların html ve css kodlama da başarısız olduklarını görüyorum. Kendini kodlama da geliştirmeye hevesli tasarımcıların kod kalitesi bakımından daha başarılı olduğuda bir gerçek. 

İş css standartları ve programlama mantığına geldiğinde tasarımcı altyapısına sahip kitlenin nedense büyük bir başarısızlık içinde olduğunu düşünüyorum. Şöyle ki iki farklı sayfada birbirinin aynı olan bir üyelik ve yardım alanı için farklı css tanımlaması yapılabiliyor. Halbuki programcılık mantığında baktığında bu tekrar eden kesimler bir şekilde koda include edilir ve fazla kodlamadan kaçılır. Bu php,asp ya da asp.net farketmez.Böyledir.

Şu an yaşandığına inandığım bir karmaşa ise erişilebilirlik. Erişilebilirlik özünde daha sade ve anlaşılabilir bir yapıyı barındırdığı halde, bazen tasarımsal değerlerle çakışmaktadır. Bu çakışma tasarımların içerik olarak flash gerektirmesinden, zor yüklenen yüklü sayfalara kadar kendini gösterebilir.

Yazılım Uzmanı – Proje Yöneticisi İlişkisi

Ben genellikle programcıları ikiye ayırırım. “Şahin Programcı” dediğim ne söylense yapan birazda memur davranışı sergleyen kesim ve ne söylersen yapmayan önce düşünen “Aykırı Programcılar”.

Bu bahsettiğimiz PY ile ilşkide sorun genellikle Aykırı Programcılar ile yaşanmaktadır. Her ne kadar tanım için “sorun” metnini kullansakta aslında bu bahsettiğimiz bildiğimiz anlamda sorun değil. Kastettiğim süreçte bir pazarlık katmanının oluştuğu. PY çoğu şey için AP(aykırı programcı)’ yi ikna etmesi gerekiyor. Bu da iş sürecine yen bir katman eklemektedir. Ben bu olayı her zaman olumlu gören bir insanım. Özellikle arge gerektiren işlerde çok önemli bir süreçtir.

Fazla uzatmadan bu yazının ana konusuna dönersek, yazılım sektörüne! iş gücü yetiştiren eğitim kurumlarının, olayın disiplininden uzak bir eğitim verdiğine inanıyorum. Bu, sektörde çalışanları bilinçsiz olarak kariyer basamaklarına itmekte ve kişi kendini beğenmeyeceği ummadık bir yerde bulabilmektedir.

Peki bu sorunu çözmek kimin işi. Öncelikle her zaman dediğimiz gibi eğitim sistemini adam etmek gerekir. Bunun içinde şu an piyasada çalışanlarla işbirliği yapılmalı. Diğer taraftan, var olan çalışanlar içnde sertifika ve seminerler düzenlenmeli, olayın bilinci aşılanmalıdır.

Belirtmeden geçmekte fayda var, yazılım sektöründe çalışan kişileri belli alışkanlıklardan vazgeçirmek zordur. Bu işin kaynağına inmekte, eğitimide bazı standartları aşılamakta fayda var.

İşini iyi yaptığını düşünen insanların ara sıra kapıldığı bir duygu ya da iş yapış yöntemi vardır: Sanat için sanat!

Bir yazılım uzmanı da kendine has aralıklarla, bu deyimin bir sonucu olarak, sürekli yeni bir başlangıç yapmak ister.

Neden?

Bunun özünde yazılım mesleğinin bazı gereklilikleri mevcuttur. Bahsedeceğim bu gereksinimler kimi zaman kişiyi yanlış yönlendirerek hatalara sevk edebilir.

Peki nedir bu gereklilikler? İş görüşmelerinde aranan, güçlü bir kriter olan bu şartlar nasıl oluyorda bu şekilde olumsuz bir geri dönüş sağlıyor?

Bu mesleğin kaçınılmaz şartı sürekli yeni teknolojilere uyum sağlamak için bilgi ve bakış açısı olarak yenilenmektir. Bu yenilenme ihtiyacı/şartı özellikle günümüzde belli bir noktadan sonra saplantı haline gelmektedir. İşte tam da bu noktada, bu saplantı bir bağımlılık halini aldığında projelerde sorunlar başlar. Bu sorunlar:

• Yazılım uzmanının başka bir çalışan tarafından üretilen kod üzerinde çalışmak istememesi
• Sürekli yeni proje yapma isteği
• Daha üzerinden 1 ay geçmeden kendi yaptığı projenin kaynak kodlarına yabancılaşıp yenisini yazmak istemesi

şeklinde ortaya çıkar. Eğer bu eğilimler ortaya çıkıyorsa üretilecek işin kalitesi ve şevk katsayısı azalır.
Bu yabancılaşma sürecini tetikleyen diğer bir güçlü eylem de günümüzde kalınan aşırı bilgi bombardımanı içinde kişinin kendi zihninde karşılaştığı eski ya da diğer projeleri canlandıramayıp, çözemediği düğümü kesme yoluna girme kolaylığına kaçmasıdır.
Genellikle standart sendromlarda etkenleri ortadan kaldırınca sorunda çözülür. Fakat burada etken olarak gördüklerimiz bu mesleğin en önemli kriterleri olunca bu yola girmek bir yazılım uzmanı için en fazla 9 ay içinde emeklilik getirir. Ve, çoğu kendi içinde bulunduğu durumu göremeyen meslektaşlar, bu yöntemi denerken, aynı anda çalışmaya devam ettikleri için de bir süre sonra kendi kendilerini tedavi etme yöntemleri ile iş yaşamları çatışmaya girer. Sonuçta kimse karlı çıkmaz bu işten.
Bu kadar zihin eforu harcanan bir meslekte sadelik bir denge unsurudur. Bu sadelik masamızda, arabamızda, evimizde hatta baktığımız gökyüzünde olabilir. Ama asıl olması gereken yer düşünme şeklimizdedir. Düşünürken sade yollar izlemeli, kargaşa ve umutsuzluğa yer vermemeliyiz. (Ve spor! Her yazılımcı spor yapmalıdır!)
Karşımızda açılan kod penceresi, ister bizim eski kodumuz olsun ister başkasının daha önce yazdığı, bunu sakin bir şekilde karşılamalı ve şu soruları sormalıyız:
Eğer kod bizimse:

1. Bunu yazdığım anda çalışacağına inanmamış mıydım?
2. Şu anki durumda ne değişti?
3. Yeniden yazmak MADDİ anlamda ne kazandıracak? (En iyi kod çalışan kod’dur./UB)

Kod bizim değilse:

1. Bu kodu yazanla kendimi neden kıyaslıyorum?
2. Bu kod bana ne katacak? (her zaman en kötü kodlamalar bile bir katmadeğer sağlar)
3. Bu kodla projeyi btirmek analiz yeteneğimi arttırmaz mı?

Bu sorulara gerçekçi yanıtlar vermeli ve gerekirse objektif görüşte olduğuna inandığınız arkadaşlarınızdan fikir almalısınız.

Bu sendromlarla başa çıkmada izleyeceğimiz diğer bir yol, etkenleri kontrol altına almaktır. Internet dünyası mağlum, hertürlü içerik mevcut, fakat asıl sorun bilginin sistematik olmamasıdır. Bizi en çok zorlayan nokta budur.
İşte bu aşamada kendimizi google arama mühendisliği hakkında biraz daha bilgilendirmemiz gerekiyor. Çoğu zaman çıkan hatayı google’a yazmak çözüm getirebilir ama bazı durumlarda en basitinden programlama dilini de eklemek daha iyi sonuç almamızı sağlar.
Bir diğer baş edilmesi gereken konu, yeni programlama dilleri ya da betiklerini öğrenme direncidir. Bu noktada şu aklımızdan hiç çıkmamalı. Yazılan bu diller ya da betikler, her zaman daha kolay öğrenilsin ve geliştirici grup daha rahat işine devam etsin diye başka bir dil ya da betikten türetilir. Örneğin JQuery’ i ele alalım. JQuery ilk bakışta çok farklı gibi görünse de aslında CSS işaretçileri kullanır ve bir süre sonra gerçekten kullanımının kolay olduğu görülür.
Baştan şunu kabul edelim bu meslek zor. Dışarıdan görüldüğü gibi değil.
Bu mesleği yaparken bir maden işçisi kadar tetikte ve zihni açık olunmalı. Sürekli bir kendini yenileme durumu içinde olduğumuzdan bedensel olarakta zihnimize yakın bir performansa ihtiyacımız olacaktır.
Farkındalıklar dileğiyle….