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

Bu ayki film tavsiyem:  Internship.  

Google, bence, iş ilanı yani başvuran potansiyel çalışanlarda görmek istediği özellikleri, 2 saatlik bir film şeklinde ilan etmiş .    

Google'un istediği çalışan profili:  İnsan odaklı, büyük resmi merak eden ve görebilen çalışan.  Teknik yetkinliklerimiz elbette yine önemli ama yeterli değil.  Esas fark yaratan yetkinlik, müşterinin ne istediğini anlamaya çalışmak.  Müşterinin ne istediğini anlamak pek mümkün değil ama yine de anlamaya çalışmak değerli bir emek.  Doğruyu, yanıla yanıla buluyoruz.   DevOps eğitimlerinde sürekli söylediğim gibi:  DevOps 'un en büyük amacı, hata yapmayı, müşteriyi yanlış anlamanın maliyetini azaltmak ve hızlandırmak.  DevOps 'u başarı ile uygulayan şirketler diğerlerine göre 200 kat daha hızlı hareket edebiliyor.  Start-up gibi çalıştığımızda, start-up başarı oranlarının %5 yani başarısızlık oranlarının %95 civarında dolaştığını gördüğümüzde moralimiz çok bozumasın.  DevOps ile 200 kat hıza ulaştığımızda %5 başarı oranı ile bile hedefi 10 kere vurma şansımız var.  

Proje yönetimi açısından bakarsak:  Proje yöneticisinin ve çalışanların büyük resmi kaybetmemesi, projenin amaçına odaklanması projenin başarı ile tamamlanması açısından önemli.  

Proje yönetici veya iş analisti gözü ile bakarsak, çevik yöntemler hatta DevOps bile kullansak, yapılması gereken en önemli şey:  Projemizin müşterileri (paydaşları)  ile teker teker yüz yüze görüşerek projeden beklentilerini ilk ağızdan duymak.  Eğer paydaş sayımız hepsi ile tek tek yüz yüze görüşmemize pratik olarak izin vermeyecek kadar çok fazla sayıda ise, bu sefer, örneklendirme ve persona çalışmalarımız ile en az sayıda paydaş ile görüşüp en yüksek faydayı yakalamak hedeflenmelidir.... :) 

Gereksinim yönetimi açısından da bakarsak:
Kaç çeşit gereksinim sayabilirsiniz?
Proje Yönetimi (PMBOK v6) bakış açısına göre 6 çeşit gereksimden bahsedebiliriz:
1.  İş Gereksinimleri  - Esas AMAÇ -  Projenin HEDEFİ
2.  Paydaş Gereksinimleri  - PAYDAŞ İHTİYAÇLARI - daha sabit
3.  Çözüm Gereksinimleri    - değişken - 
4.  Geçiş Dönemi (Transition) Gereksinimleri
5.  Proje Gereksinimleri (PMO tarafından istenenler)
6.  Kalite Gereksinimleri (Standartlar, vb)

Bu hiyerarşi doğru bir şekilde İş Analistinin yardımı ile oluşturulursa, Kapsam (İş gereksinimleri ve paydaş gereksinimleri) sabit kalmak kaydı ile diğer çözüm, vb... gereksinimler tartışmaya açıktır.  

İş ve Paydaş gereksimlerinin büyük resme odaklanması ve müşteriyi düşünmesi esastır.  Internship filminde olduğu gibi.  :)