Browsing archives for 'Proje Felsefesi'

Freelancer Yol Haritası

Proje Felsefesi, Yazılım 3 Mart 2010 | 3 Comments

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.

Tagged in , , ,

Para Gerektiren Girişimler!

Proje Felsefesi, Yazılım 1 Temmuz 2009 | 2 Comments

Para Gerektiren Girişimler!

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….

Tagged in , , ,

Projeperestlik ve Çok Seslilik

Proje Felsefesi 23 Mart 2009 | 0 Comments

Daha önce projeperestlik kavramını işlemiş ve gerektiğinde projeperest olmamanın önemini vurgulamıştım.  Ama şunu belirtmek gerekir ki projeperesti olduğumuz her fikrin bir potansiyeli olabilir. En doğrusu fikirlerimiz içinden bulunduğumuz zaman dilimine ve sosyo-ekonomik durumumuz ile çevresel potansiyelimize uygun olan seçimi yapabilmek. İşte bu “kararı” yerinde verebilenler başarılı işler ortaya çıkarabilirler. 

Peki, verdiğimiz proje kararının projeperest olmadığını nasıl anlarız? Bunu kendi kendimize ortaya çıkarmamız zor olabilir. Bu durumda çevremizde bulunan ve size karşı fikirlerini dürüstçe söyleyip fikrinizin olgunlaşmasına yardımcı olabilecek arkadaşlarınızı kullanabilirsiniz.

Bu noktada çoğu insan fikirlerinin kopyalanabileceğinden endişe duyabilir. Burada zaten sizinle aynı seviyede olanlardan ve fikrinizi kopyalayabilecek insanlardan kesinlikle söz etmiyorum. Özellikle projelerinizi kullanma potansiyeli olanlarla bu fikir alışverişini yaparsanız çok yerinde olur. Size gelen soruları ve eleştirileri can kulağı ile dinleyip belkide not etmeniz gerekebilir. Kendi yaptığı işi iyi yapan bir kişiye birazcık yazılım proje mantığını aşıladığınızda size çok doğru fikirler verebilir.

Tagged in ,

Projeperestlik!

Proje Felsefesi 14 Şubat 2009 | 1 Comment

Gün geçmiyorki şu hayatta kendimizle ve yaşantımızla ilgili bir çok yenilik öğrenmiş olmayalım. Bahsettiğim yenilik kendi kendimize keşfettiklerimiz.

Yazılım gibi bir sektörde çalışınca kafadan onlarca yeni düşünce geçmemesi imkansız. Özellikle içinizde 1 damla girişimcilik ruhu varsa onlarca düşüncenin yanına, onlarca proje ekleniyor.

Proje, onu düşünen ve hayal eden için bir bebektir. Onu alıp, özenle büyütmek ister, mürvetini görmek ister. Fakat ben her zaman, projeyi bir canlıya benzetmeme rağmen, onu çok az, uysal bir insana benzetirim. Çünkü proje, yeri geldiğinde sizi yutacak bir canavar olabilir.

Asıl konumuz, zaman ve maddi kaynağın önemli olduğu günümüzde aklımızdan geçen onlarca projeden değerli olanını nasıl seçeceğimiz. Proje sahibi olarak, girişim sırasında hatta proje sürecinin ortasında, giriştiğimiz işin ileride bizi yutacağını farkettiğimiz de ya da artık odak noktası olmayan bir konuda proje geliştirdiğimizi anladığımızda ne yapacağız?

Bu noktada, kimi insanların projelerinin esiri olduğunu ve gözlerini bir sis bulutunun kapladığını gördüm. Hatta öyleki bu proje sahipleri çevrelerindekilerini bile kendi projelerine, bir misyoner edasıyla, taptırabilmektedirler. Ben bunlara PROJEPEREST diyorum. Bu tarz insanlarla tanıştım. Hatta beni dahi misyonlarına inandıranlar oldu!

Projeperestleri çevremizde aramak yerine, arasıra durup kendimize de bakmak lazım. Özellikle internet projeleri geliştiriyorsak, binlerce kullanıcı söz konusu demektir. Hesap edemediğimiz bir çok nokta ve bakış açısı olabilir. Atalarımızın dediği gibi, “Zararın neresinden dönülse kardır” diyebilmek için, Ben projeperestmiyim? sormamız gerekir.

Şu soru sorulabilir, Doğru bir proje de projepertlik yararlı olmaz mı? 1M$ için rus ruleti de bence benzer anlam taşıyabilir. Her şeyin fazlası zarar demişler. Ne olursa olsun özellikle projelerimizde kontrolümüzü kaybetmememiz gerekir.

Tagged in ,

Yeni Bebek: Proje!

Proje Felsefesi 11 Ocak 2009 | 0 Comments

Yeni Bebek: Proje!

Nil Timsahı! Nam-ı Değer ProjeProje Bilimi üzerine hayatını adayanlar bilir! Proje bir canlıdır! Doğar, Yaşar, Ölür(/inthar eder).

Fakat proje bir çocuktan ya da evde beslediğimiz bir kediden çok bahçemizde baktığımız Nil Timsahı‘ na benzer. Kontrol etmesi zordur. Ve dikkat etmezsek bizi yaralayabilir.

Bu makale ile projenin doğumu ve yaşam süreci boyunca gelişiminin aşamaları incelenecektir. Burada anlatılan teorik bilgidir ve uluslararası standartlarda anlatılan hikayelerin! bir özetidir. Hikaye diyorum çünkü bu standartlar oluşturulurken projeyi gerçekleştirirecek ekibin T9 cyborg’ ler varsayıldığı düşüncesindeyim. İnsan olan her işte teori işlemez. Çünkü hayatı olmasa da insanı metafizik öğeler yönetir. Projenin metafizik yanına başka bir yazıda yer vereceğim.

Proje Aşamaları


Yukarıdaki fotoğrafta bir proje sürecinin standart döngüsü yer almaktadır. Başlangıç ile başlayan fikir aşaması benim Ö.Y.P dediğim Projenin Ölümü(bitirilmesi) ya da proje ile eldeedilen değerlerin kullanılması ile başka bir projelendirmenin yapılması şeklinde son bulur. İşletme faaliyetinin gerçekleştiği bölüme “Yaşam Süreci” dememin ana amacı, hiç bir projenin sonsuza kadar devam etmeyeceği ve bir gün kesinlikle sonlandıralacağı gerçeğidir.

Şimdi işin biraz daha derinine inip bu aşamaların detaylarına bakalım.

Başlangıç

IEEE/EIA 12207 yazılım geliştirme dökümanlarında Başlangıç aşaması için şu ifadeyi kullanır: “Her proje mutlaka kullanıcının ortaya koyduğu gereksinimleri karşılamak üzere gerçekleştrilir.

Bu tanımda bir şey eksik. Girişimcilik…

Neden? Çünkü bu stadartlar klasik yazılım projeleri için yazılmıştır. Günümüz özellikle web tabanlı projelerde proje başarısı, hedef kitlenin o an farkında olmadığı ama kullandığında rating vereceği fikirlere bağlıdır!

Şimdi bu stadart tanımı ve yeni tanımı tek bir kelimeye indirgeyelim. Projenin başlangıç aşaması bir FİKİR ile başlar.

Gereksinimlerin Ortaya Koyulması

İster standart bir yazılım projesi olsun ister girişimci bir proje olsun, kendiliğinden ya da hedef kitlenin modellenmesi sonucu bazı gereksinimler ortaya çıkarılır. Projenin başarılı bir yaşam süreci sürmesinin sağlanmasında burada ortaya çıkan gereksinimler çok önemlidir.

Eğer hedef kitlemizi çok iyi tanımlayabilirsek onların gereksinimlerinide aynı netlikte ortaya koyabilmemiz gerekmektedir. Sonuçta basit düşünürsek temel mantık projeyi kullanacak insanların bir fayda sağlamasıdır.

Biz hedef kitle olarak 20-27 yaş arasındaki öğrecileri belirleyip, gereksinimlerimizi netleştirirken 20-30 yaş öğrenci ve çalışan kişileri hedef alırsak proje amacında bir sapma yaşanacaktır. Dolaylı olarak Proje Yaşam süresi daha kısa olacaktır.

Bu aşamada yapılması gereken çok iyi bir inceleme ve planlama çalışmasıdır. İnceleme ve planlamanın bir diğer yüzü de maliyet analizidir. Kısaca yapılacak bir proje maliyetinedeğecek midir? Bunun net bir şekilde ortaya koyulması gerekir. 

Maliyet analizi yapılırken dikkat edilecek etmenler şunlardır:

  1. Personel
  2. Ekip: Personelin bir bütün olarak çalışması için gerekli olan ortam ve araçların maliyeti.
  3. Uygulama: Lisans, araştırma, iletişim, güvenlik
  4. Edinme: Danışmanlık, satın alınacak betikler veya modüller. 
  5. Çalıştırma Maaliyeti: Server, Internet Hattı, Kurulum maaliyeti, İdari personel
  6. Proje Maaliyetleri: Sözleşmeler, Şirket Kurulumu gibi yasal işlem maaliyetleri
  7. Yaşam Süreci Maliyetleri: İşletici personel, entegre ticari paket maliyetleri, kiralar,enerji, bakım ve temizlik.
Geliştirme Süreci
Ekibin düşünceleri uzman bir sisteme dönüştürme aşaması. Metafizikle iç içe olduğunu düşündüğüm süreç. İnsan faktörünün en belirgin şekilde hissedildiği aşamadır.
Geliştirme sürecinin temel ihtyacı kontrollü yapılasıdır. Buna neden ihtiyaç dedim? Bir ihtiyaç karşılanmazsa huzursuzluk! ve başarısızlık baş gösterir.
Yazılım geliştirme için internette bir çok deneyimli! arkadaşın aslında uygullamadıkları bir çok fikir öbeklerini bulabilirsiniz. Ama pratikte başarısız (özellikle ülkemizde) olan bu sistemlerin temel eksikliği ekibi bir makina gibi görmekten geçer.
Sadece düşünce kullanılarak üretilen bir sistemin, bu düşüncelerle iç içe olan duygulardan etkilenmemesini beklemek, en masum haliyle, bir çarpıtmadır.
Bu geliştirme sürecinde ekibin kontrol altına alınması için astrolojiden yararlanmak bile doğru bir yöntemdir. 
Yazılım geliştirme teknikleri hakkında daha detaylı ve ülkemiz gerçekleriyle örtüşen bir makaleyi daha sonra yazmayı planlıyorum.
Risk Yönetimi
Ülkemizde yazılımın başka sektörlerden etkilendiğinin en somut belirtisi risk yönetimidir. Ülkemizde insanlar riskin, kaba tabirle, projenin tutup tutmayacağında olduğu fikrinden bir türlü kopamazlar. Ama asıl risk projenin büyütülmesi, 18 yaşına getirilmesi aşamasındadır.
Bu fikrimi kanıtlayan en büyük dayanağım, ülkemizde bilgisayar gören, bilgisayara dokunan her bir vatandaşımızın neredeyse bir proje fikrinin olması, hatta büyük çoğunluğunun gerçekleştirmeye çabalaması ama gece rüyalarına giren risklerin “tutar mı tutmaz mı” olmasıdır.
Risk olarak proje geliştren ekibin görülmemesinin en büyük nedeni, bir bilgisayarın başında günde 8-10 SAAT OTURAN RAHATI YERİNDE! BİR EKİBİN NASIL RİSK OLUŞTURULACAĞININ KESTİRİLMEMESİDİR.
Bu sektörde yapılan risk analizlerinin, yazılımı bir ev inşaatı gibi elealması son bulmadıkça, yazılım bir sektör olmaz, başarılı proje oranı da artamaz.
Riskin bir diğer tarafını da aslında projeyi düşünen ve planlayan, hayata geçmesi için finansör olan kişilerin niteliği aslında yazılım açısından niteliksiği oluşturmaktadır. Ve şu aşamada bu riskin kağıt üzerine aktarılması çok çok zordur. Ego’ dan muaf olmak ve mikro yönetici yapısında olmamak şarttır.
Sonuç:
Şu anda dünyada proje yönetim standartlarındaki asıl sorun eski usül projelerle yeni girişimci projelerinin  teorik örtüşmemesidir.
Ülkemizde ise sorunun kaynağı sektör olamayan yazılım ile başlamakta. Ekip risk analizi ve maaliyet analizi sorunları ile devam etmektedir.
Sonraki makalelerimde, özellikle yazılım sektörü ve risk analizleri hakkında denemelerime yer vereceğim.
>devam edecek<

Tagged in , , ,

Yazılım Uzmanlarında “Eski Kod” sendromu

Proje Felsefesi, Yazılım 8 Ocak 2009 | 1 Comment

İş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….

Tagged in , ,

Yazılım Projelerinde Parayı Projeden Kazanmayanlar!

Proje Felsefesi 7 Aralık 2008 | 2 Comments

Hayatımın 2 yılında freelance çalıştım ve bu blog’ ta anlatacak çok malzemem var. Bu malzemeleri yazdığımda herhalde en fazla, parayı projeden değilde yazılımcının emeğinden kazanmaya çalışanlardan söz ederim.

Bir yazılım projesinde en büyük yatırım, başlangıçta iş gücüdür. Cebinde 10-15 bin ytl parası olan “girişimciler” hepsiburada ya da gittigidiyor kopyası yaptırmak için harekete geçer. Bu büyük gider kaleminden dolayı sözüm ona girişimciler, bir bilgisayarın başında oturularak yapılan bir işi çok basit ve o kadar paraya değmez olarak nitelendirebilirler.

Artık geriye çeşitli bahanelerle söz verilen parayı vermemek için kafa yormak kalır. Bu tip insanlar özellikle parlayan başarılı internet işlerinden sonra ortaya çıkar ve ellerindeki 10-15 bin ytl (belki daha az) ile bu firmalara kafa tutma yanlışlığında bulunurlar.

Sonuç istatistiksel olarak kesindir. Başarısızlık!

Yazılım mesleğine gönül vermiş olanlara buradan sesleniyorum. Bu tarz bir işte güzel bir sözleşme imzalayın ve paranın yarısını da peşin alıp, verdiğiniz sürenin 3′ te 1′ inde projeyi beta olarak açın. Ve size verilen en ufak bir teminatın ya da sözün yerine getirilmemesi durumunda gerekli yasal ihtarı yapın.

Kendinizi bu köle tüccarlarından uzak tutun….