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 konular çevik yöntemlerde ve ITIL 4 prensiplerinde tavsiye edilenlerin tam tersi (anti-pattern) listesi.  Yani bunları yapmayın.  Yapmamak için çevik yöntemler kullanın!  :) 

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 (sabote etmek isteğiniz şey!) 

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

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.  :) 

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.  :) 

PMBOK 6 ile proje yöneticilerinden beklentilerimiz artıyor.  Proje yöneticilerden, içinde bulundukları şirketlerin, birlikte çalıştıkları müşterilerinin ve tedarikçilerinin governance ve management yapılarını bilmeleri bekliyoruz.   

Türkçe karşılıkları şöyle:
Governance:  Yönetişim
Management:  Yönetim

Türkçe karşılıkları çok içime sinmediği için İngilizce terimler ile devam etmek istiyorum.  

Peki bu terimlerin anlamı nedir?  Governance ne?  Management ne?

Bu iki terimi en iyi açıklayan model COBIT'dir.  

COBIT'e göre 
Governance:  Şirketin en üst düzey yönetimidir.  Yönetim kurulu, genel müdür ve genel müdür yardımcılarına denk gelen bir seviyedir.  (Genel müdür yardımcısı rolünü başka isimlerde de görüyoruz.  Ör:  Direktör, grup başkanı, CIO, CTO, CMO, COO, CFO, vb...)

Management:  Şirketin orta düzey yöneticilerine denk gelir.  Yönetim kurulu, genel müdür ve genel müdür'ün altında çalışan yönetim kadrosuna denk gelir.  


Governance fonksiyonları:  Hedef Koy (Direct), Değerlendir (Evaluate), İzle (Monitor)
Management fonksiyonları:  Planla (Plan), Yap (Build), Sahaya Sür (Deploy), İzle (Monitor).  

Ordu terimlerini kullanırsak, şirket veya proje çalışanlarını şu üç aşamada görebiliriz :
Governance:  Generaller
Management:  Subaylar
Diğer çalışanlar:  Er

Governance yani şirketin (CEO, CXO, gibi) veya projenin (Sponsor, Proje Yöneticisi) generalleri daha uzun vadeli hedefleri düşünürler böylece şirket veya proje için uzun vadeli hedefler koyarlar.  Bu hedefler genelllikle yıllar mertebesinde veya en az 3 aylık periodlar şeklindedir.  

Management yani şirketin orta düzey yöneticileri veya projeni yönetim ekibi (İş Analistleri, teknik liderler, takım liderleri, mimarlar, vb) projenin daha kısa vadeli planlarını yaparlar.  Planlanamanin ilk aşaması iş gerekçesi (business case) yazmak ile başlar.   İş gerekçesi ile governance yapısından proje için kaynak istenir.  Governance, iş gerekçesinde talep edilen kaynakların proje için verilip verilmeyeceğini DEĞERLENDİRİR.  Benzer şekilde governance yani generaller dünyada ve piyasalarda neler olup bittiğini de DEĞERLENDİRİR ve buna göre hedefler koyar.  

Generaller (governance), subayları (management) kilometre taşı seviyesinde, yaklaşık 3 ayda bir veya daha küçük projelerde ayda bir izler. 
Subaylar (management), proje çalışanlarını daha kısa aralıklarla, görev (task) veya teslim edilebilirler (deliverable) bazında ayda bir veya daha küçük projelerde haftada bir izler. 

Yukarıda anlatılan senaryo, klasik proje yönetimi bakış açısı ile anlatılmıştır.  Çevik yöntemlerde self-governing bir yapı olmalıdır. Yani, governance da management de çalışanlar da hep birlikte küçük takımlar halinde organize olurlar.  Kendi kendini hem general, hem subay, hem de çalışan olarak yöneten takımlar sayesinde çevik yöntemlerde vaad edilen yüksek hızlara ulaşılabilir.   

Her ne kadar çevik yöntemlerde herkes her rolü oynayabilir desek de klasik rollere bir eşleme yapılması gerekirse, şu şekilde bir eşleme düşünülebilir.

Sponsor [General]
Product Owner (ürün sahibi) - müşteri [General]
Scrum master - proje yönetici (servant leader) [Subay]
Team - Proje ekibi [Er]

Yukarıdaki gibi bir kategorisazyon yapılması mümkün olsa da, rollerin sınırları klasik yöntemler kadar net değildir.  Sırası geldiğinde bir er bir general gibi vizyonu tartışabilir ve değiştirmeyi önerebilir veya bir general bir er gibi vaktinin önemli bir kısmın takım ile birlikte geçirerek onların anlık sorularını cevaplar.  Çevik yöntemlerde ulaşılamayan general ve subaylar yoktur.  General ve subaylar korkulmaz.  Onlarda rahatlıkla fikir ayrılığına girilebilir ve tartışılır.  Bu yaklaşım özellikle generaller ve subaylar tarafından yüreklendirilir.  Ancak, bu konuda dünya genelinde alınması gereken daha çok yol olduğunu itiraf etmek gerekir.  Öte yandan, zaman giderek hızlanıyor.  Eskiden 50 yıl süren değişiklikler, artık 5 - 10 yıllara düşmüş durumda.  Yani önümüzdeki 10 yıl, dünyada çok büyük değişiklikler göreceğiz, buna çalışma şartları ve kurumsal yapılanmalar da dahildir.  Yani, önümüzdeki yıllarda generallerin, subayların ve erlerin birbirlerine giderek daha çok yaklaştıklarına şahit olucaz.  :)

Umarım, bu yazı ile governance ve management arasındaki farkı anlatabildim.  

PMP sınavınızda şimdiden başarılar dilerim,
Orhan Kalaycı
23 Mayıs 2018
İstanbul

Hangisi daha önce gelir, sorun mu çözüm mü?

Sorun olmadan çözüm olur mu?  Sizin hiç yanlış bir soruna çok iyi bir çözüm ürettiğiniz oldu mu?

Sizin olmamış olabilir ama start-up camiasında çok yaygın bir davranıştır, bu.  Start-up'ların bir çoğu hatta hemen hemen hepsi, çok iyi bir çözüm üretir ama ancak bu start-up'ların sadece %10'u çözümlerinin gerçek bir soruna karşılık geldiğini görür.  %90 start-up, ürettikleri çözümün aslında gerçek bir soruna karşılık gelmediğini oldukça pahalı bir şekilde öğrenir.  O yüzden, yalın (lean) start-up kitaplarında "önce sat, sonra yap" akımları çok yaygındır.  

"Önce sat, sonra yap", önce insanları gerçek bir derdine derman olduğuna emin ol, veya "gerçek bir sorundan bahsettiğine emin misin?" demenin başka bir yoludur.  

Sadece start-up'lar mı, yanlış sorunlara doğru çözümler üretiyorlar.  Yazılım projelerinin bir çoğu bu durumda değil mi?  Gerçek hayatta yaşayan arkadaşlar bilirler, bir çok gereksinim paydaşın dertini (sorununu) değil, bir çözümü tarif eder.  Proje çözümü başarı ile hayata geçirse bile aynen start-up'larda olduğu gibi KABUL TESTİNE gelen gerçek kullanıcı,  "bu çözüm, bir işe yaramıyor!" der.  

KABUL TESTLERİNDE bu kadar çok sorun yaşanması ile start-up'ların bu kadar büyük oranlarda başarısız olmasının arkasında ortak sebebler olduğunu hiç düşünmüş müydünüz? 

Her iki durumda da proje ekibi soruna değil maalesef çözüme odaklanmıştır ve büyük ihtimal ile anlamadıkları veya yanlış anladıkları bir soruna, kendilerince en doğru çözümü üretirler.  Ancak, ortada sorun olmadığında, hiç anlaşılmamış veya yanlış anlaşılmış bir soruna, ne kadar doğru bir çözüm üretebiliriz?

Projelerimizde ve start-up'larımızda en önemli kaygımızın ÇÖZÜMÜ değil SORUNU doğru anladığımızdan emin olmaktır.  

Bunu daha teknik terimlerle söylersek:  Şu 4 çeşit gereksinim tipinden ilk ikisi öncelikle ve hayati derecede önemlidir.  
1.  İş Gereksinimleri (Business Requirements)
2.  Paydaş Gereksinimleri (Stakeholders Requirements)
3.  Çözüm Gereksinimleri (Solution Requirements)
4.  Geçiş Gereksinimleri (Transition Requirements)

Proje yöneticisi olarak, projemizde dikkat etmemiz gereken en önemli konuların başında: Yukarıdaki gereksinim tiplerinden ilk ikisinin öncelikle dokümante edildiğinden emin olmak gelir!

İlk iki gereksinim tipi SABİT'tir; Kolay kolay değişmez.  Üçüncü tip gereksinimler yani çözüm gereksinimleri daha ESNEK'tir.  

Eğer, çözüm gereksinimleri esnek değil ise bu projenizde iş ve paydaş gereksinimlerinin kayıp olduğuna dair bir işaret olabilir.  

HEDEF:  İş gereksinimleri ve paydaş gereksinimlerinden taviz vermeden; alternatif çözüm önerileri arasından en uygununu seçmektir. 

Çözüm gereksinimlerinin ESNEK olması projenin maliyet ve süre aşımlarına engel olmak için çok önemli bir rahatlık sağlar.  

Projenizin başarısı için iş ve paydaş gereksinimlerinin eksiksiz ve hatasız dokümante edildiğinden emin olmanız çok değerli....  Gerçek hayatta ve PMP sınavında buna dikkat!  :) 

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

PMBOK 6 ile gelen yeniliklerden en önemlisi çevik yöntemlere yapılan büyük vurgu.  

Neden çevik yöntemler bu kadar popüler?  

Çünkü, müşteriler isteklerini yeterince detaylı ve net bir şekilde açıklayamıyorlar,  hatta ne istediğini kendisinin de bilmediği müşterilerin sayısı hiç de az değil.  O yüzden, en başarılı yöntem, müşterinin önüne hızlıca bir ürün ile çıkmak ve müşteriye ürünü göstermek ve bunu mu istediniz diye sormak.  

Çevik yöntemlerin bir çok iyi yönü ve faydalı özellikleri var ama dikkat edilmez ise tehlikeli tarafları da var.  Tehlikeli taraflarından biri de:  Teknik Borç (Tech Debt)

Teknik Borç konusunda daha önce bir makale yazmıştım:  buradan okuyabilirsiniz.  
Bu yazının amacı, teknik borcun temizlenmesi için vakte ihtiyacı olduğunun proje yöneticileri (business) tarafından bilinmesi gerektiğidir.  

Proje yöneticisi olarak göreviniz:   çevik yöntemlerin başlangıçta tasarım için vakit ayırmadığı için hızlı yol alıyormuş gibi görünen çevik yöntemlerin arada bir teknik borç temizlemek için yavaşlamak zorunda olduğunu anlamak.  

Teknik borcun temizlenme işlemine ingilizce REFACTORING denir.  Turkçesi herhalde, yeniden düzenlemek veya yeniden tasarlamak olabilir.   İsmini ne olursa, olsun:  Yapılan şey, kirlenen kodun temizlenmesi işlemidir.  Kod makinenin aklı gibidir.  Aklımızı temizlemek için düşüncelerimizi terleyip toplamak iyi fikir olabilir.  Daha iyi düşünmek için kitaplar var.   Bu kitaplar daha iyi düşünmenin sırrının basit düşünmek olduğunu söyler.  Kafa karışıklığını gidermek için de kodumuzu temizlemek için de aynı yöntem kullanılır:  BASİTLEŞTİRMEK!  :)  İşte refactoring in yapması gereken şey bu:  Kodu temizlemek yani KODU BASİTLEŞTİRMEK.  Basitleştirmek için yapılması gereken kavramları gruplandırıp sayılarını azaltmak.  Ör:  50 maddelik listeyi hatırlayamazsınız ama 10 maddelik 5 grubu hatırlanamanız daha kolay olabilir.  

Çevik yöntemlerde, tasarım için haftalarca tasarım için vakit ayrılmaz.  Bu başlanğıçta ayrılmayan zaman sprint'lerin arasında kademeli olarak ayrılmak zorunda.  

Aşağıdaki şekil, en geç 5 sprint'de bir kodu temizlemek için bir sprint ayırmak iyi bir pratik olabilir.  Proje yöneticisi olarak göreviniz:   çevik yöntemlerin başlangıçta tasarım için vakit ayırmadığı için hızlı yol alıyormuş gibi görünen çevik yöntemlerin arada bir teknik borç temizlemek için yavaşlamak zorunda olduğunu anlamak.  

Çevik yöntemler birçok konuda değerli sonuçlar verebilir ama hiç bir şey bedava değildir.  Çevik yöntemlerin bu kadar hızlı ve güzel sonuçlar almasının bedellerinden biri:  Teknik Borç.  Teknik borç kavramının farkında olmak ve temizlenmesi için vakit ayrılması gerektiğinin bilinmesi başarılı sonuçlar için önemlidir.  

PMP sınavında ve gerçek hayatta faydalı olması dileğiyle,

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