CIA’den tavsiyeler: Bir girişim, bir şirket veya bir organizasyon nasıl sabote edilir!1944 yılında, CIA tarafından yayınlanan “bir girişim nasıl sabote edilir!” başlıklı yazı, bugün bir çok ciddi şirketin çalışma prensibi olarak karşımıza çıkabiliyor. Kendini sabote eden şirketlerin kurtuluş mücadelesinin modern ismi: Çevik Dönüşüm.

Çevik dönüşüme neden ihtiyaç olduğunu (ITIL 4 gibi) çok güzel anlatan bir yazı.
Aşağıdaki yazının Türkçe tercümesi şöyle olabilir:
(11) Bir girişim, kurum veya üretim ile ilgili genel etkileşim prensipleri
(a) Organizasyon/Girişim/Şirket veya bir Konferans
(1) Herşeyin “resmi kanallar” (süreçler) üzerinden yapılmasında ısrar edin. Kararları hızlandırmak için kısa yollara gidilmesine hiç bir zaman izin vermeyin. 
(2) “Konuşmalar” yapın. Sık sık ve çok uzun konuşun. “Fikirlerinizi” göstermek için uzun hikayeler kullanın, kişisel tecrübelerinizi de anlatarak açıklayın. Vatansever yorumlarda bulunmaktan hiç çekinmeyin.  
(3) Mümkün olduğunca, her konuda, konunun daha iyi araştırılması ve incelenmesi için, bir komite kurun. Komiteleri olduğunca kalabalık yapmaya çalışın, en az beş kişiden oluşsunlar.  
(4) Alakasız sorunları sık sık gündeme getirin.  
(5) Konuşmalar, toplantı tutanakları, ve çözümler hakkında kelimelere takılın, her kelime için uzun uzun tartışın.  
(6) En son toplantıda alınan kararları tekrar gündeme getirin ve kararların geçerliliğini/doğruluğunu/yanlışlığını sorgulayın.
(7) “Temkinli” olmayı öğütleyin. Mantıklı olun ve çalışma arkadaşlarınızın da mantıklı olmasını isteyin. “İleride pişman olacağınız, düzeltmesi zor, utanç verici hatalar yapmamak için acele karar vermekten kaçınmak gerek” deyin.  
(8) Alınan kararların “uygun” olduğundan kaygılanın. Verilen kararların grubun yetkisi içinde olup olmadığını veya kararlın yüksek mevkilerdekiler ile çelişip çelişmediğini sorgulayın.
In 1944 the CIA published a secret manifesto on how to “sabotage” an organization. Reads like the “management principals” of many companies today. Well worth a read.

ITIL 4 eğitimlerimde geçen bir kavram.  Karpuz etkisine dikkat etmek.  Kısaca, sayılar bizi yanıltabilir.  İlk bakışda "iyi" (yeşil) gibi görünen bir sayı aslında öyle olmayabilir.  

Biliyorsunuz, karpuzun dışı yeşildir.  Yeşil de raporlarda İYİ bir renk olarak kullanılır.  Yeşil ile işaretlenen şeyler konusunda işler iyi gidiyor anlamına gelir.   Kırmızı ise tam tersi, kırmızı ile işaretlenen yerlerde sıkıntı var demektir.  

Dolayısı ile karpuz etkisi ile anlatılmaya çalışan:  Karpuzun dışının yeşil olması gibi, ilk bakışda güzel görünen bir rakam, sonrasında aslında o kadar da iyi olmayabilir, karpuzun içinden kırmızı çıkması gibi, KIRMIZI olabilir.  

Nasıl yani?  Bir sayı hem iyi hem kötü nasıl olabilir?  

Bir örnek üzerinden bakalım.  Aşağıdaki youtube video'da da anlattığım gibi.  Bir odanın sıcaklığı ortalama 21 derece ise bu rakam birçok kişi tarafından gayet sağlıklı bir sıcaklık olarak kabul edilir.  Ama aslında, bu odada bir insanı öldürecek kadar sağlıksız olabilir.  Mesela, odanın sıcaklığı bir saat -18 derece olsa ve ardından bir saat boyunca +60 derece olsa, bir  insanın yaşaması için uygun bir ortam olmadığı halde, odanın ortalama sıcaklığı 21 derece çıkacaktır.  

Yani dikkat etmez isek sayılar bizi yanıltabilir.  O yüzden Deming'in de dediği gibi her yöneticinin öğrenmesi gereken 14 maddeden biri İSTATİSTİK dir.  

Daha detaylı açıklama için youtube video mu tavsiye ederim. :) 

https://youtu.be/p2Ur79sa-Yw 

ITIL 4 - Uzaktan - $393 - 16, 17 Mayis - Cmts, Pzr %100 basari ortalamasi
www.EnUcuzSertifika.com

Benden bir sure once DevOps egitimi alan bir ogrencim, bir kac gun once beni aradi.  Sirketlerinde PMO'nun bir "dokuman listesi yayinladigini ama listeyi begenmedini, benim fikrimi almak istedigini" soyledi.  Liste surec grublari bazinda olusturulmus; gereksinim dokumani yurutme altina konmus.  Ben de kendisine hak verdim; gereksinim dokumanin planlama altinda netlestirilmesi gerekli.  Eger PMP sinavinda sorarlarsa, gereksinim dokumani nerede netlestirilir diye ilk bariz cevap planlama altinda olur.  Ancak, yine hemen hatirlayalim; planlamanin dalgalar halinde asamali gelistirilmesi gerektigini de unutmayalim.  

O zaman soyle soylemek daha dogru olur:  Selale hayat dongusunu ilk yazan kisi de oyle demis (selale hayat dongusunu anlatan ilk makalesinde).  Her bir projenin en az bir kac fazdan olusmasi gerekli. 

Benim yorumum soyle:
Cevik olmayan; klasik projelerin hepsi, en az 3 fazdan olusmali.  

Faz 1 - Gereksinimleri netlestir - fazin sonunda musteriye bir prototip goster ve musterinin ne istedigini anladigindan emin ol.

Faz 2 -  Tasarim zorluklarini kontrol et.  Her projenin tasariminda bir zorluk olur.  Kimi projede entegrasyon zorluklari olma ihtimali (risk) olabilir; baska bir projede yeni bir teknoloji kullanilacaktir; ekibin teknolojiyi ogrenme zorlugu olabilir, vb.  Projelerin bu cesit tasarim/teknik zorluklarinin belirlenmesi ve yine mini-bir-proje ile denenmesi (PoC - Proof of Concept / Pilot proje / vb) 

Faz 3 - Projenin buyuk/genis Kick-off toplantisinin yapilarak asil projenin baslamasi.  

Faz 1 ve 2 'de mini-kick-off lar yapilabilir ama projenin gercek hakiki kick-off toplantisi faz 2 sonunda projenin gereksinimlerinin netlesmesi ve teknik zorluklarin asilmis oldugu noktadan sonra yapilmasi KLASIK projeler icin en saglikli yaklasim olacaktir.

Proje yonetiminin klasik 5 surec grubu (basla/planla/yurut/izle/kapat) basliklari, yukaridaki 3 faz icin tekrar tekrar yasanmasi gerekli.  Yani faz 1, 2 ve 3 icin ayri ayri basla (hedef), planla, yurut, izle, kapat yapilmasi gerekli.  

Projenin tam olgunlasmis WBS (Work Breakdown Structure) Is Kirilim Yapisi Faz 2 sonunda cikabilir...

Detayli gereksinim dokumani - Faz 1 icin yurutme, Faz 2 ve 3 icin planlama asamasinda calisilir.  

Kisaca ozetlemek gerekirse:

5 surec grubu (basla/planla/yurut/izle/kapat) asagidaki her faz icin tekrarlariz:

Faz 1 - ANLA - Gereksinimleri netlestir
Faz 2 - DENE - Tasarim zorluklarini gider
Faz 3 - YAP - Sonuc uzerine odaklan 

​

Proje planları yaparken süre, kaynak ve maliyet tahminleri kadar önemli bir konu daha var:  Kapasite tahminleri.  

Kapasite tahminlerinden kastım:  Yeni bir projeye atanmış kişilerin vakitlerinin yüzde kaçını gerçekten yeni projeye ayırabilecekleri.  Eski projeler için harcanan ama kayıtlarda görülmeyen (kayıt dışı) destek ihtiyaçları, yeni projenin süre, kaynak, maliyet tahminlerini ne kadar iyi  yapsak da geç kalmalara veya bütçe aşmalara neden olabilir.  

Yeni bir proje başlarken, eski (kayıt dışı) projelerin kaynak ihtiyaçlarını da göz önünde bulundurmak gerekli.  Aksi takdirde, yeni proje için yaptığımız tahminler maalesef tutmayacak.  Özellikle, hemen yeni bitmiş projenin ilk dönem destek ihtiyaçları bir sonraki projenin geçikmesine yol açabilir.  Bu etki, domino taşı misali, arka arkaya bütün projelerin düzenli bir şekilde geç kalmasına neden olabilir.  

Örneğin, aşağıdaki grafik (burndown chart'ın tersi bir şekilde tasarlanmış, kalan işleri değil biten işleri gösteriyor, aşağı değil yukarı doğru gidiyor ama ana fikir aynı :) işler böyle giderse projenin ne kadar geç kalacağını veya ne kadar eksik iş ile zamanında biteceğini tahmin etmemize yardımcı oluyor.  Grafikte fark edeceğiniz gibi yaklaşık ilk 10 gün projeye tam olarak başlanamamış.  Bir önceki bitti sanılan proje aslında bitmemiş, kayıt dışı bir şekilde yeni başlayan projenin kaynaklarını kullanmış ve yeni projenin geç kalmasına sebeb olmuş.  

Tahminlerimizde dikkat etmemiz gereken şey: bu kayıt dışı projelerin ya tamamen yok olmasını sağlamak ya da yok olmalarını sağlayamıyorsak, o zaman onların yeni başlayan projelerimizin ne kadar kaynağını tüketeceğini tahmin etmek.  Projelerimizi kayıt dışı projeleri de göz önüne alarak yönetmeliyiz aksi halde tahminlerimizin tutma ihtimali giderek düşer.  Tahminlerimizin zamanla tutmamaya başlamasının bir kaç nedeninden biri:  KAYIT DIŞI projelerdir.   Diğer sebeblerden biri de TEKNİK BORÇ. Özellikle bu ikisine dikkat edelim.  

ITIL terminolojisi ile söylersek:  Bir önceki projenin, proje bittikten sonra devam etmesinin resmi ismi:  "Early Live Support"  - Türkçesini tam bilemiyorum:  belki "ilk dönem destek ihtiyacı" diyebiliriz.  

Teknik Borç ile ilgili daha önceki yazım için buraya tıklayabilirsiniz.  

ITIL 4 foundation (sinav dahil), 
CBAP ve PMP sinav hazirlik hizmetleri vermeye basladim.  :) 

Daha iyisi ve daha ucuzu yok.  :) 

STRATEJİMİZ:  PMP, CBAP, ve ITIL sorularının nasıl hazırlandığının mantığını öğrenmek ve mümkün olduğunca çok soru çözmek. 

Her öğrenci en az 100 soru hazırlayacak.  Öğrenciler, diğer öğrencilerin hazırladığı soruları ve Rita'nın meşhur kitabından mümkün olduğunca çok soru çözerek sınava hazır hale gelecek.  

Daha detayli bilgi icin:  https://enucuzsertifika.com/ 

Memduh Bayraktaroğlu youtube kanalında KAZAN-KAZAN kavramını yanlış anlatınca, dedim, kazan-kazan ın gerçek anlamını anlatmam lazım.  :)  

Memduh Bey kazan-kazan ı nasıl yanlış anlattı:  Dedi ki, kazan-kazan her iki tarafın karşılıklı taviz vermesidir ve böylece her iki tarafı da mutlu edecek bir çözüm bulunmasıdır dedi.  Kazan-kazan ile uzlaşmayı birbirine karıştırdı.  İki tarafın ortak bir noktada uzlaşmasına kazan-kazan mı denir?

Hayır, uzlaşma ile kazan-kazan aynı şey değildir. 

Peki "Kazan-kazan" ile "uzlaşma" arasında ne fark var?  :)

Şöyle ki:  Kazan kazan ile kast edilen durum her iki tarafın da %100 mutlu olmasıdır. İstediklerinden hiç bir taviz vermeden her iki tarafı da %100 mutlu edecek bir çözüm bulunmasına kazan-kazan diyoruz. 

Yani, uzlaşma ile her iki tarafı %100 mutlu edecek bir çözüm bulunmuyor mu?  Hayır, uzlaşma ile kast edilen sonuç her iki tarafında kısmen memnun olmasıdır.  Yani, mesela, bir tarafın %60 diğer tarafın %70 mutlu olması gibi.  Uzlaşma ile  her iki tarafın da %100 memnun olması hedeflenmez.

ESKİ tarz düşünce sisteminde, her iki tarafın %100 memnun olmasının mümkün olduğuna inanılmaz.  ESKİ tarz düşünme sisteminde olabilecek en iyi çözüm her iki tarafın da bir miktar taviz vererek tamamen mutsuz olmasındansa en azından  kısmen memnun olması en iyi çözümdür.   ESKİ tarz düşünmenin diğer ismi SIFIR-TOPLAM (zero-sum) denklemidir.  

SIFIR TOPLAM felsefesinde, bir tarafın kazanması için bir tarafın kaybetmesi gerekir.  Yani bir taraf +1 olursa diğer tarafın -1 olması gerekir.  

YENİ düşünce sistemin de ise her iki taraf da kazanabilir.  Her iki taraf da +1 +1 olabilir.

Her iki tarafin da (hiç bir taviz vermeden) %100 memnun olmasi yani kazan-kazan yöntemi, Marry Parker tarafindan, 1900 lu yılların ilk ceyreğinde bulunmuştur.  

Mary Parker'in klasik hikayesi şöyledir:

Bir portakal için savaşan iki kız kardeş vardır.  İkisi de, ortadaki tek portakalı ne pahasına olursa olsun almak isterler.  En sonunda araya büyükleri girer ve portakalı ikiye bölüp paylaşmaları konusunda arabuluculuk yaparlar.  Kızkardeşler %100 memnun olmasalar da hiç yoktan iyidir diye portakalın yarısına razı olurlar.  Sonra büyükler şaşkınlıkla görürler ki, kızkardeşlerden bir tanesi portakalın yarısı ile portakal suyu yapar ve kabuğunu atar, diğer ise portakalın kabuğunu soyar ve kabukları kek yapmak için kullanır.  

Mary Parker bu hikaye ile gösteriyor ki:  Tarafların AMAÇLARINI sorgulamak ve AMAÇLARINA odaklanmak her iki tarafı da mutlu edecek bir çözümün sırrıdır.  Eğer arabulucu büyükler, kızkardeşlerin portakal ile ne yapmayı AMAÇLADIKLARINI sorsalar idi:  

Kız kardeşlerden biri:  Portakalın kabuğunu istediğini çünkü yapmak istediği kek için portakalın kabuğuna ihtiyacı olduğunu söylecekti.

Diğer kız kardeş ise:  Portakalı, portakal suyu yapmak için istediğini söyleyecekti. 

Böylece, her ikisini de %100 mutlu edecek bir çözümün mümkün olduğunu anlamış olacaktık.  Kızkardeşlerden birine portakalın kabuklarını ve diğerini de portakalın içini verdiğimizde her ikisi de %100 memnun edecektik.  

Biliyorum, şimdi kendi kendinize diyorsunuz ki, peki ama, her ikisi de kabuğunu istemiş olsa idi, o zaman ne yapardık?   Bu durumda, yine portakalın kabuğu ile ne yapmayı AMAÇLADIKLARINI sorup, o doğrultuda bir çözüm üretmeye calışacaktık.  Belki elimizde her ikisi de yetecek kadar portakal kabuğu olmayacaktı belki ama yine de AMAÇLARINA hizmet edecek başka meyvelerin kabuklarını önerebilirdik: Mesela, elimizde varsa; Limon kabuğu, mandalina kabuğu, vb gibi alternatifleri önerirdik.  

Kıssadan hisse:  Bütün tarafları %100 memnun etmek mümkündür.  Artık yeni düşünce sistemi sıfır toplamlı değildir.  Birinin kazanması başka birinin kaybetmesine bağlı değildir.  Herkes kazanabilir, bu mümkündür.  Bunun yolu:  Tarafların AMAÇLARINI sorgulamaktan geçer.  :)

Proje yöneticisi olarak, projelerinizdeki paydaşların AMAÇLARINI sorgulamak yapmanız gereken en önemli şeylerden biridir.  :)

Barış, huzur, esenlik üzerinize olsun,
​Orhan

Eylul 2019 yine yoğun geçti. 

Aşağıdaki sınıflarda, Eylül ayında, akıllarda en çok kalan benzetmelerden biri "Hamburger'in TURŞUSU da EKSİK Kalsın" idi.  :) 

Logo Yazılım (CBAP), Halkbank (COBIT, Temel Yazılım, CBAP), Havelsan Teknoloji Radar, Türkiye Bankalar Birliği, BT Akademi CBAP Açık sınıf derken Eylül ayı bitmiş.  Akıllarda Turşu kalmış.  Tabi, eğitimlerime katılanlar bilir esas SUÇUK önemli.  :) 

"Hamburger'in TURŞUSU da EKSİK Kalsın" ile ne kast ediyoruz?  Bunu çevik yöntemler ile klasik yöntemler arasındaki farkı anlatmak için kullanıyorum.

Klasik yöntemlerde Kapsamdan taviz verilmez.  Onun yerine zamandan taviz verilir.  Yani, gereksinimlerin hepsi eksiksiz olsun ama bunun karşılığında gerekirse geç kalınsın.  Klasik yöntemlerde geç kalmak normal olmuş artık, sebeb gereksinimlerden taviz verilmez, verilemez.  Halbuki, geç kalmaya değmeyecek gereksinimler de olabilir (Hamburgerin içindeki turşu gibi...  :)  

Öte yandan, Çevik yöntemlerde ise zamandan taviz verilmez (buna TIMEBOX denir.  Timebox yerine "zaman konservesi" de denebilir.)  Diğer bir deyişle, zamandan taviz vermemek için kapsamdan taviz vermeyi tercih ederiz (çevik yöntemlerde)...  Yukarıdaki resimde hamburger projenin beklenen çıktısını temsil ediyor.  Gereksinimleri, ÖNCELİKLENDİRMEK çevik yöntemlerde daha bir anlamlı oluyor çünkü vakit yetmediğinde bazı gereksinimlerden vaz geçmek, geç kalmaktan daha iyi olabilir (çoğu zaman geç kalmaktansa eksik çıkmak daha iyi olur).  O yüzden hangi gereksinimlerin "olmazsa olmaz", hangi gereksinimlerin "olmasa da olur" olduğunu en baştan ayırt etmek gerekli.  Bu çevik yöntemlerin ruhunda var.  Kısaca, geç kalmaktansa Hamburgerin TURŞUSU da eksik olsun.  :) 

Önceliklendirme için kullanılan yöntemlerden biri MOSCOW dur:
Must - Birinci öncelikliler
Should - İkinci öncelikliler
Could - Olmasa da olurlar
Won't - Kapsamdan hali hazırda çıkarttığımız gereksinimleri temsil ederler.  

Bunu daha iyi anlamak için EXCEL kullanırken bir düşünün, excel in yüzde kaçını kullanıyorsunuz.  Excel'de olmasa da fark etmeyeceğiniz ne kadar çok fonksiyon var dimi...  Bir excel projesi yaptırdığınızı düşünün ve bu kullanmadığınız fonksiyonlar için projenin aylarca geç kaldığını hayal edin, böyle bir şey ister misiniz?  Yoksa TURŞUSU da eksik kalsın mı dersiniz?  :) 

Barış, huzur, esenlik üzerinize olsun,
Orhan

Garson:  Is Analistini (BA - Business Analyst ' i)  temsil ediyor.

Mutfak:  Yazilim gelistirme ekibini (Development team ' i) temsil ediyor.

Eger, garson (BA) siparisi yanlis alirsa (ki musterinin ne istedigini bilmedigi gercegini simdilik bir kenara koyalim) mutfak naparsa, yapsin musteri gelen yemekten memnun olmayacaktir. 

Dolayisi ile, garson 'un musteri memnuniyetinde cok onemli bir rol oynadigi asikar.  

Musterinin ne istedigini bilmedigi durumda, musterinin istediklerini parca parca masaya getirerek bir yanlislik varsa, bunu hizlica ogrenmeye calismaya CEVIK yontemler diyoruz.  

Siparisin tamaminin hazirlanmasini beklemeden, hemen masaya icecekleri vb birseyler getirmek ve en azindan masaya gelenler konusunda musterinin tepkisini hizlica almak birseylerin yanlis anlasilmis olma ihtimalini azaltabilir.  (karniyarik isteyen musterine (MVP = minimum viable product) modunda hemen hizlica bir karniyarikimsi birsey getirmek zor olabilir.  ==  Asagida bir e-ticaret sitesinin kismen hizlica nasil yapilabilecegine bir ornek vermeye calisicam = yemek yapmak, insaat yapmak, kopru yapmak gibi, biraz yap, sonra yik tekrar yap seklinde ilerlemeye musait olmayabilir)

Garson'un siparisi yanlis almasi konusunda bir nokta daha var.  Siparisi kimden aldigi... ?!!!

Soyle bir senaryoya ne dersiniz?  

Restaurant'a gelen bir ailede anne-baba tuvalete gitmis, masada cocuklar oturuyor.  Garson geliyor ve anne-babanin da ne yiyecegini cocuklara soruyor. Cocuklar anne-babalari ve kendileri icin siparis veriyor.  Bu durumda garson, siparisi cocuklardan dogru almis olsa bile, cocuklarin anne-babanin ne yemek istedigini dogru bildiklerinden emin miyiz?  Is hayatinda aslinda siklikla karsilasilan bir duruma benzemiyor mu?  Esas ihtiyac sahibi projeye bilgi vermek icin BA ile konusmak icin vakti olmaz, birileri gorevlendirilir.  Gorevlendirilirken TAHMIN ETTIKLERI kadariyla projenin ne yapmasi gerektigini anlatirlar;  onlarin da yanlis anlasilmasi; onlarin yanlis anlatmasi ihtimalleri hep var.  Ama, eger ne istendigini tarif eden kisiler ilk agizdan ne istendigini gercekten bilmiyor ise, bu da klasik buyuk bir sorun degil mi?  

Siparis veren kisilerin tecrubelileri garson'a sorar degil mi?  Ne tavsiye edersin diye?  

Mesela, soyle der "kirmizi et yiycez, ne tavsiye edersin?"  Yani siparisi verenin direk yemek ismini soylemesi yerine garson'a sormasi daha basarili sonuclara yol acabilir.  Garson soyle diyebilir.  Bu aksam su yemek cok iyi, onu tavsiye ederim.  

Musterinin DERTine odaklanip, cozumu garsona birakmasi daha iyi olur.  

Hem PMP hem CBAP icin 4 temel gereksinimler:

Is gereksinileri (Business requirements  = Dert = Projenin AMACI) 
Paydas gereksinimleri (Stakeholder requirements = Paydaslarin ihtiyaclari) 
Cozum gereksinimleri (Solution requirements) 
Gecis gereksinimleri (Transition requirements) = mesela 1000 ATM de birseyler degisecek, degisimin 1000 ATM de hepsinde birden aniden mi yapilmasi daha iyi olur, yoksa 1 -> 10 -> 100 -> 200 ->  500 -> 1000 seklinde mi GECIS (Transition) yapilmasi daha iyi olur.  Bazen guvenlik (security) aciklarini gidermek icin 1000 ATM ye hepsine aniden bir kerede GECIS yapilmasi gerekebilir ancak genellikler acil bir durum yoksa asamali gecis daha az risklidir. 

Sonuc olarak:
Lokantanin basarisi takim olarak herkesin gorevini yerinde ve iyi yapmasi ile mumkun.  Ancak, eger Garson siparisi (is analisti gereksinimleri) dogru alamaz ise, mutfak (gelistirme (development) ekibi caresiz kalir.  Dolayisi ile projelerimizde gereksinimlerin dogru alindigindan emin olmak cok onemli bir konu.  Gereksinimleri soyleyenlerin dogru/gercek/oz/hakiki musteri olmasina (anne-baba yerine siparis veren cocuklara) dikkat!!! 

CEVIK yontemlerin calismasi icin OZ, HAKIKI, GERCEK musteriyi bulmak ve sik sik or: 2 haftada bir calisan yazilimi OZ, HAKIKI, GERCEK musteriye gostermek cok onemli.  

Is analistinin en onemli gorevlerinden biri de:  Musteriyi dogrudan COZUMe odaklanmaktan alip AMAC ve ihtiyac 'a cekmek....  Soylemesi kolay tabi...  :)  

Not:  yukarida monolizayi anlaticam demistim ama yazi cok uzadi, onu bir sonraki yazima birakayim....  Parmaktan sonra...  gelecek yazimda, monaliza'yi kisim kisim (CEVIK) yapmayi anlatirim.  :)